ser@hack:~/asic# file Antminer-X-fixed-718M-201904231321-sig.tar.gz
Antminer-Z11-fixed-718M-201904231321-sig.tar.gz: gzip compressed data, last modified: Tue Apr 23 06:45:00 2019, from Unix, original size 12748800 We have bin folder which contains all of the binaries for the system
(such as ls, file etc..). First, lets take a deep dive into etc
folder which contains “Host-specific system-wide configuration files”. A
file called os-release shows us some information about Operating
System.
PRETTY_NAME="The Ångström Distribution"The firmware is based on Angstrom Distribution, and more in detail as hostname can confirm, the firmware has been developed with beaglebone utility.
I also discovered an old repository of BitMain on Github which contains the instructions for building firmware with sources. However, I checked this repository for one simple reason: it has not been updated since 2015. Therefore, it has some security issues needing to be fixed. Surely, that repository is not secure and I wouldn’t advise building firmware image based on it.
The file lighttpd-htdigest.user include the details for default accounts.
root:antMiner Configuration:23c2a2d78c0d20ec069097d7d20c4392As reported in this thread on Bitcointalk, the hash “23c2a2d78c0d20ec069097d7d20c4392” is an md5 hash of “root:antMiner Configuration:root” (without quotes) the :root in the end is the password for the web interface.
The file shadow.factory contains the SHA-512 hash for root account.
root:$6$saaYvC9T$PqLC9JWHDZsWYmpB0b0Zf.34b1m5/r9U6A8PPig2qzxAyUN78pyI/vi7OZrCA0T2y1fT5UNFtPiBYuCyBTA610:15975:0:99999:7:::Some might criticize me and explain that it is obvious that there are default passwords in the device. However, my goal was not to highlight the fact that there were default credentials and the setup of device does not require the immediate changing of root password.
Continuing the exploration, we can observe the folder ‘www’ which has the files for the Web Api used to set up the miner.
Digging into web interface
ASIC miner could be configured via a simple Web interface. The pages are served by lighttpd version 1.4.32, an old version of the popular and lightweight web server.
The old version has the following security vulnerabilities among many others:
- CVE-2013-4508 - lighttpd, when SNI is enabled, configures weak SSL ciphers, which makes it easier for remote attackers to hijack sessions by inserting packets into the client-server data stream or obtain sensitive information by sniffing the network;
- CVE-2013-4559 - lighttpd does not check the return value of the setuid, setgid, o setgroups functions, which might cause lighttpd to run as root if it is restarted and allows remote attackers to gain privileges, as demonstrated by multiple calls to the clone function that cause setuid to fail when the user process limit is reached;
- CVE-2013-4560 - Use-after-free vulnerability allows remote attackers to cause a denial of service (segmentation fault and crash) via unspecified vectors.
- CVE-2014-2323 - SQL injection vulnerability in mod_mysql_vhost.c allows remote attackers to execute arbitrary SQL commands via the host name;
- CVE-2014-2324 - Multiple directory traversal vulnerabilities allow remote attackers to read arbitrary files via a .. in the host name;
Since I do not have an Antminer at home, I patched my lighttp local installation with the CGI scripts presented in firmware.
The interface is based on CGI scripts ran into /bin/sh (bash shell). This is very interesting since all the scripts are ran as root user, then all the commands injected are executed with the highest privileges.
Discovering issues
One of the files I’m going to analyze is called “upgrade.cgi”. This file is for upgrading or replacing firmware with a custom one. I thought this was a nice point to start the investigation since it’s a critical-script for the process.
In fact, during the upgrade, there must be a parallel system which can guarantee the minimal functionalities of the Operating system (such as the supporting of copying functions) in order to switch between the old and new firmwares.
During my research, I found a CVE report 2018-11220 which describes a potential security issue. When a tar archive is uploaded into web interface, the antminer will extract it and will try to run the file called restoreConfig.sh. I decided to investigate more.
First of all, the upgrade.cgi receives a POST response from the user which contains the file name and content of the file. The file will not check the signature (if the uploaded one is a tar, a txt or a pdf), but instead, it will create the file under the /tmp/ directory. The following commands are executed for extracting the archive.
mkdir $file
cd $file
tar zxf -It seems CVE 2018-11220 was fixed introducing two file signature checkers using the tool openssl and the public key bitmain-pub.pem. Here, the Bitmain company added a check since theoretically flashing the device with a unofficial and untrusted firmware breaks the agreement between the company and the final user.
openssl dgst -sha256 -verify /etc/bitmain-pub.pem -signature runme.sh.sig runme.sh >/dev/null 2>&1Then the script will run bash runme.sh. Inside the file runme.sh another check will be executed in order to check the content of uramdisk_image which is the image that contain the folder ‘ext-root’ that I showed you before. To execute the checkup, OpenSSL will be called to analyze the “fileinfo” that includes the hashes for part of files.
md5hashmd5hashmd5hashmd5hashmd5hashmd5hash fileinfo
shmd5hashmd5hashmd5hashmd5hashmd5hashmd5ha runme.sh
hashmd5hashmd5hashmd5hashmd5hashmd5hashmd5 runme.sh.sig
[no hashes are present for .bin files]Is bypassing this file signature check possible? Of course! Remember that there are no hashes for .bin files! This is the part of the content of runme.sh. Can you spot the issue?
...
if [ -e BOOT.bin ]; then
flash_erase /dev/mtd0 0x0 0x40 >/dev/null 2>&1
nandwrite -p -s 0x0 /dev/mtd0 BOOT.bin >/dev/null 2>&1
fi
if [ -e devicetree.dtb ]; then
flash_erase /dev/mtd0 0x1A00000 0x1 >/dev/null 2>&1
nandwrite -p -s 0x1A00000 /dev/mtd0 devicetree.dtb >/dev/null 2>&1
fi
if [ -e uImage ]; then
flash_erase /dev/mtd0 0x2000000 0x40 >/dev/null 2>&1
nandwrite -p -s 0x2000000 /dev/mtd0 uImage >/dev/null 2>&1
fi
..No checks are performed on the bin files. First, per each file, the flash_erase command will delete the part inside the partition specified (given example, for devicetree.dtb it’ll delete from 0x1A00000 to 0x200000 -1). Second, all the files will be mounted in the same partition.
Theoretically, you can mount any kernel you want, even a malicious one! You do not need to edit any particular files, simply add the bin files modified but with the same name “boot.bin” will be “boot.bin”.
The problem is the control which is performed only in the file called “fileinfo” and in the files described in it.
This shows how you can break file signature and possibly how you can inject malicious software by rebuilding the firmware image. However, these do not seem the only problems that affect the Antminer Z11 since some versions still has the firmware upgrading feature without checking of signature.
A given example of a possible attack could be changing the miner address with yours. Combining this attack with some precautions (such as rendering fake transactions to your target), you could steal all the earnings from ASIC. Injecting malicious programs is also possible!
Conclusion
Bugs and defects are intrinsic characteristics of software development. At the moment of creation software have issues. The art of fixing bugs is the art of delaying as much as possible the probability that bugs occur. In critical infrastructure development, the problems could affect availability and stability of the program.
ASICs are critical tools to manage the consensus of a cryptocurrency. Imagine if we discovered a new bug in which we could switch off all the devices in the same network, meaning that we are not able to mine through them. That would be disruptive and amplify attacks on blockchains.
Does Bitmain have security in mind as a prime objective? Should a cryptocurrency ban specific hardware for mining? Are ASICs secure for the cryptocurrency network?
Comments
Post a Comment