moolticute
moolticute copied to clipboard
mooltipass
Pairing between moolticuted and clients
Context: for the next mooltipass mini, users will have the option to not approve any credential prompt on the device. In this mode, the device will simply output any credential that has been asked by moolticuted. Therefore, we need to now be very strict about who can prompt moolticuted for credentials and do operations in general. @cwaazywabbit put together a very nice proof of concept where a simple web page could request any credential to moolticuted by sending the correct websocket message.
We therefore need to authenticate moolticuted clients for the next device. However, simple solutions such as WSS aren't an option as browser extensions won't allow WSS connections to "servers" using a self signed certificate for localhost. Knowing that and that local connections to localhost can't be proxied, we want to setup authentication tokens.
When a new moolticuted client appears (extension, etc), it therefore needs to request moolticuted an authentication token. This token is issued after the user clicks a button, confirming that this connection attempt is from a legitimate source. This token is then used by the client every time it needs to request something from moolticuted.
This token could obviously be sniffed by a program running on a compromised computer (even inside the browser itself), but this is not what this mitigation is for: "standard" websocket connections on a non compromised browser. In case a browser vulnerability is discovered allowing extension memory contents reads, a moolticute update will disable the device "no prompt functionality".
In order to authenticate moolticute GUI with moolticuted, I suggest starting both processes at boot with a random command parameter generated during the installation process (the token) so they don't need that authentication stage.
From a user point of view: the suggestion would work. The manual confirmation would prevent malicious connections from communicating with moolticuted if they are not authorized beforehand to do so.
From a security point of view: why disable the manual confirmation and give users a dangerous option in the first place?
Regarding current moolticute: please check the Origin header, so that connections originating from remote untrusted sources e.g. websites, can not communicate with moolticuted. Read more.
From a security point of view: why disable the manual confirmation and give users a dangerous option in the first place?
simply because it's easier for the end user.... security and ease of use always is a trade-off..
tagging @deXol for origin header checks
Unfortunately Qt Websocket API does not export HTTP headers to be used. They are only kept internally...
Unfortunately Qt Websocket API does not export HTTP headers to be used. They are only kept internally...
I am not a programmer (anymore :)), but what about this?
CVE-2019-12967 has been obtained for this. Will be public after 90 days (on September 19, 2019).
I've just opened #470 and this issue seems related. I'm not a security expert, but in the article pointed by #470 , the author explain that indeed, WebSockets should be avoided in place to Native Messaging to do browser integration.
As I've written in #470, I think at the moment that's not an issue for moolticute, as we always have to manually confirm on the device access to any password.
If I've well understood the idea of the pairing, it's to avoid to always manually confirm access of password, but instead confirm some extensions can access to the whole passwords automatically.
If so, maybe Native Messaging could be part of a solution here ?
For some reason I'm not getting notifications for this thread :/... Why we can't use native messaging: because moolticuted receives requests from different clients (browser extensions, CLI tools). @deXol may implement QWebSocketCorsAuthenticator as a first implementation step :)
The PoC is now public: https://securiteam.io/2019/10/20/cve-2019-12967-moolticute-improper-access-control/
very nice writeup ! thanks for the foot notes :)
I confirm it's absolutely necessary to fix that issue before releasing our next gen device.
@cwaazywabbit : i'm afraid you wouldn't be able to fetch the encrypted database though... when the device is in MMM other clients can't scan the DB.
Another thing to add to this PoC: if the user do not validate the prompt and enter his PIN code on the device, nothing is extracted at all. And as @limpkin said already, if one client app asks moolticute to put the device in memory management mode (to be able to export something) then moolticute do not process any other client's requets (such as the PoC request).
@cwaazywabbit : i'm afraid you wouldn't be able to fetch the encrypted database though... when the device is in MMM other clients can't scan the DB.
On the Mooltipass mini it would be possible to extract a copy of the encrypted database when the user has confirmed the operation on the device after being presented with too many confirmations. How does it look like on the next gen given that users are given the option to disable notifications? I am afraid I cannot confirm or deny the behavior on the next gen since I didn't manage to enter the beta-testing program :)
I see what you mean... but the chances of your program prompting for MMM a few moments before the user legitimately wanting to enter MMM are slim to say the least... your post may be reworded to reflect that.
Next gen device: we plan on implementing the mitigation described in the first post and approved by yourself.
The PoC doesn't actually depend on prompting users to enter MMM while they are legitimately trying to. It will simply attempt to connect to a device (this works even if the device is locked) and then simply spams it with requests to enter MMM. A non-suspecting user would cancel that once or twice but eventually will either disconnect the device or simply consider it a bug and unlock it to check what's going on or whether it would disappear. By that time, the damage is done.
I've updated the post, added a comment and a video.
Origin header is now validated upon connection. 078ea4712069a1682f49ec8d9ddb1cf53e302867
@limpkin Only works for browsers. Local apps can put any Origin header they like.
As for Opera I don't have it, but i expect it to work.
I will try to get my hands on a Mooltipass to re-test this. The scrolling wheel of mine started acting funny so I gave it away.
The PoC website is still up, so testing it against the original PoC should enable you to test it on differnet browsers.
there's a simple fix for the wheel issue: isopropyl alcohol :)
it's not in the manual :-P
Better late than never..
I have examined this again using Moolticute v0.43.12-testing and can confirm it's working in the current implementation.
I have also modified the PoC to send a a "null" origin, ~hoping~ checking if I could bypass it, but "null" isn't allowed so it's good so far.
From the screenshot posted by @raoulh
Any extension on the computer would be able to talk to Moolticute. It boils down to this: it cannot be exploited remotely but any program or browser extension on the computer can abuse it for the time being.
Let's hope no one comes up with a vulnerability to send an empty origin header. But then that would lead to all sorts of havoc and we'd care less about moolticute compared to the rest of the evil.
Appears in https://github.com/mooltipass/moolticute/commit/078ea4712069a1682f49ec8d9ddb1cf53e302867 according to @raoulh's reply from Nov 18, 2019.