by Antonio Requena, Gabriel Gonzalez and Sergio Ruiz.
Nowadays, Bitcoin and cryptocurrencies might look lees popular than they did just a few years ago. However, it is still quite common to find Bitcoin ATMs in numerous locations.
IOActive had access to few of these machines, specifically to Lamassu’s Douro ATM (https://lamassu.is). This provided us with the opportunity to assess the security of these devices – more specifically, to attempt to achieve full control over them.
In this post, we’ll explain all the steps we followed to identify a series of vulnerabilities (CVE-2024-0175, CVE-2024-0176 and CVE-2024-0177) that allows full control over these ATMs. For this exercise, we are assuming the role of an attacker with the same physical access to the device that a regular customer might have.
Don’t Touch Me
After booting up, the screen displays the the UI for the kiosk’s primary application. However, during boot, for a few seconds the user can interact with the Linux operative system's window manager, as illustrated in Figure 2.
|Figure 2. Accessing Applications during boot
During this time, it was possible to pop up a terminal window or run any other installed application as a low-privilege user.
Look at the Camera!
In order to obtain full control over the device, the next step was to perform a privilege escalation. To achieve this, we exploited the software update mechanism by creating a file named /tmp/extract/package/updatescript.js with the following payload:
cp = require(“child_process”)
cp.exec(“cp /bin/sh /tmp/shuid; chmod +sx /tmp/shuid”)
How did we create these files? Well, that’s an interesting question, as although we gained access to the graphical interface and the terminal, there was no keyboard plugged in. While we did have physical access to the devices, so that opening them and plugging in a keyboard would be too easy, the goal was to gain control without invasive physical access, therefore we explored a different approach.
The ATM supports a feature that enables it to read QR codes, and the binary located at /usr/bin/zbarcam could be executed using the touch controls, so we only had to use a custom QR code containing our payload. Once the payload was read, a root shell was popped.
The following video illustrates the paths we followed to exploit the vulnerability.
- 11th July 2023 – Initial contact to report the vulnerabilities.
- 9th October 2023 – The vendor confirmed the issues were fixed.
- 25th October 2023 – The vendor asked us to delay publishing details about the vulnerabilities.
- 22nd November 2023 – The vendor contacted us and published an advisory mentioning the issues were fixed.
- 18th January 2024 – CVEs have been published by the corresponding CNA.