Developer - Security engineer[email protected]
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.
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.
[email protected]:~/asic# ls && 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
Using tar, I decompressed the tar.gz archive.
[email protected]:~/asic# tar xzvf Antminer-X-fixed-718M-201904231321-sig.tar.gz ... uramdisk.image.gz
As we can see, after archive decompression, we obtained a uramdisk.image.gz . However, this does not contain only a GZ file. File utility showed that it's a RAMdisk image compressed with gzip and u-boot legacy uImage.
uramdisk.image.gz: u-boot legacy uImage, , Linux/ARM, RAMDisk Image (gzip), 12739696 bytes, Tue Apr 23 05:22:28 2019, Load Address: 0x00000000, Entry Point: 0x00000000, Header CRC: 0xEAEC1837, Data CRC: 0xEF02B3B3
Since my goal is not to show you how to manually extract the file I would like to introduce Binwalk — an utility software for analyzing, disassembling, and extracting firmware images. Binwalk can be initiated as a python module and signature scanning is its most utilized feature. Simply put, it checks the file signature and decompacts the file using analytical software. Finally, Binwalk is not only limited to firmware development. It is also helpful for other file types.
[email protected]:~/asic# binwalk uramdisk.image.gz DECIMAL HEXADECIMAL DESCRIPTION ----------------------------------------------------------------------------- 0 0x0 uImage header, header size: 64 bytes, header CRC: 0xEAEC1837, created: 2019-04-23 05:22:28, image size: 12739696 bytes, Data Address: 0x0, Entry Point: 0x0, data CRC: 0xEF02B3B3, OS: Linux, CPU: ARM, image type: RAMDisk Image, compression type: gzip, image name: "" 64 0x40 gzip compressed data, has original file name: "ramdisk.image", from Unix, last modified: 2019-04-23 05:22:26
You can extract the firmware image by adding the flag "e" (note that you have to install determinate softwares based on scanning of binwalk as specified on Installation guide).
[email protected]:~/asic# binwalk -e uramdisk.image.gz
In fact, when a specified file has been found inside the firmware image, binwalk tries to extract that using the utilities installed before.
After that, we get the
ext-root folder where the firmware has been unpacked.
Since we already extracted the firmware, let's start to understand how AntMiner works. In the folder, we have the basic structure of a Unix-based firmware image and all the functionalities work in the same way as in Linux or any Unix-distribution.
[email protected]:~/asic/_extracted# ls bin etc lib mnt sbin usr var www
We have bin folder which contains all of the binaries for the system (such as ls, file etc..). First, let's 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.
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.
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.
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:
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.
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!
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 a cryptocurrency network?