Mooltipass is a hardware-based password manager that is simple to use and provides an added layer of security (say no more to passwords-reuse). The passwords that are stored on the device are encrypted with AES-256, where the encryption key is stored on an external card, that works as a 2FA-token. The key on the card is protected with a 4-digits PIN that is within the range of [0-9A-F].
To manage the passwords on the device, an open source application called Moolticute is provided.
In addition, browser plugin(s) are available for an added ease of use.
While using Mooltipass/Moolticute, I was wondering how the plugin is communicating with Moolticute, which works as a proxy between the plugin and Mooltipass. Checking that revealed that Moolticute uses a daemon moolticuted that listens for connections on port 30035 locally (except on OSX, where users reported it accepting remote connections). The daemon provided a WebSocket interface where the server receives commands from clients. Cool 😈 !
In a nutshell: this basically means that any website on the Internet can, while visiting it, open a WebSocket channel with the daemon and start interacting with your device through it, and CVE-2019-12967 was born.
CVE-2019-12967
The vulnerability affects the latest version of Moolticute, v0.42.1 (and possibly earlier).
The vulnerability allows an attacker, who is able to trick a user into visiting a malicious page, to communicate with Mooltipass remotely without authentication.
By abusing the vulnerability, the attacker would be able to obtain information from the device and/or execute actions on it. Under certain conditions, the attacker is able to orchestrate an attack to obtain a copy of the on-device-encrypted database or steal plaintext credentials from unsuspecting users.
The vulnerability exists due to the way Moolticute create a local listener through the moolticuted daemon that accepts unauthenticated/unauthorized WebSockets data. With a computer connected to the Internet where Moolticute is running; an attacker would be able to communicate with the Mooltipass over the Internet by sending data to the WebSocket listener via a malicious webpage.
The vendor has confirmed the vulnerability which also affects the nextgen version of Mooltipass with a higher severity where users will be given the option to disable confirmations, which would have made it possible for attackers to extract every password that is stored on the Mooltipass.
On a final note: this cannot be used to extract plaintext passwords. In a worst case scenario, this can be used to extract a copy of the encrypted passwords’ database.
Update 22.10.2019: … only after the user has confirmed entering Credentials Management mode and entered his PIN. The PoC below would keep sending requests to enter the Credentials Management mode, temp. blocking other operations, until the user approves the request and enters his PIN. If a request is denied, the PoC sends it again.. if the request times out, the PoC sends it again. I have asked fellow colleages back then about how they would react if they see their device suddenly asking to enter Credentials Management mode and they said
“we would have probably accepted and entered the PIN to see what’s going on.. probably a glitch in the hardware/software”
PoC||GTFO
http://moolticute.securiteam.io/index.html
TL;DR
Moolticute is an application that is used to manage passwords stored on a Mooltipass (a hardware-based password manager). Moolticute opens a WS listener on port 30035 which accepts unauthenticated requests from any client. This could be abused by a remote attacker to interact with Mooltipass using the available commands.
Mooltipass is a great alternative for software-based password managers that does not make it possible to enter a secure password on boot or when no supported operating system is present. I <3 Mooltipass and I highly recommend it 🙂
Pingback: Vulnerability Summary for the Week of October 21, 2019 | a
Nice work! Felix just told me about your CVE. Not just this one but also CVE-2019-18635. In an earlier version the WS was also bound to 0.0.0.0 interface but this was fixed soon for the Windows and Linux version.
Glad you liked it.
As far as I can tell, on Mac it is still bound to 0.0.0.0, not that I have checked that myself, but it’s the last memory I have of the GitHub issue that I have read.