Unpacking ASIC firmware: AntMiner Exploited

Introduction

Experts say cryptocurrencies (such as Bitcoin, Monero, and Ethereum) will be the protagonists of the future decentralized and distributed economic system. If this is true then one of the most debated topics in the field of cryptocurrency, how to verify payments while spending as little as possible in terms of resources, is especially important for cryptosecurity.

There are many verification methods. “Proof of Work” is an easy verification method to execute yet it’s extremely difficult to create. Once the miner has received transactions, they solve a math puzzle in order to add the new block to the blockchain. Since this task necessitates a lot of resources, both economically (energy bills) and technically (CPU, RAM..), advantages arise from building a specific circuit used to circumvent these costs.

An application specific integrated circuit (ASIC) is an integrated circuit created to solve a very specific calculation. A given example could be the Bitcoin ASIC which are specialized in mining Bitcoin using algorithm hash SHA-256. Being programmed and developed specifically for mining, there are very few companies that produce and create ASIC circuits. Even further, there is a gap between those who mine with CPUs or GPUs and those who mine with ASICs and this restriction creates a point of failure since governments can press development teams to include backdoors or exploits.

Monero is one of the few cryptocurrencies that advocate ASIC resistance. According to their post, ASIC could lead to centralization of mining that can conduct to execution of potential attacks such as 50+1% attack. In this article, I am going to explain why and provide readers one example that is the exploitation of “Antminer”— an ASIC produced by Bitmain.

Unpacking Antminers Firmware

One boring afternoon, I decided to prove that ASICs are not secure. Since ASICs are being produced by few companies around the world. I looked for one firmware via search engines and discovered the BitMain company which provides a firmware download.

Out of curiosity, I downloaded the Antminer-X firmware Version 201904231321.

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:23c2a2d78c0d20ec069097d7d20c4392

As 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>&1

Then 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?