Unlock SSH access on Bobcat Miner 300

Introduction

I’ve always been a cryptocurrency enthusiast, one day I discovered this crypto called Helium (HNT), which is a very particular crypto and different from the usual, is a crypto designed for IoT applications via LoRaWAN network. The token is not generated through PoW like BTC but through PoC whit this device called “Hotspots” which are basically the mining part of the Network.

Hotspots provide miles of wireless network coverage for millions of devices around you using Helium LongFi, and you are rewarded in HNT for doing this. And because of an innovative proof-of-work model (we call it “Proof-of-Coverage”), your Hotspot only uses 5W of energy.https://www.helium.com/mine

Obviously, the function is quite complex and articulated, I am not the best person to explain it, but I invite you to inform yourselves because it is very interesting and could be a really good technology for the future of the IoT.

all very nice right? But one of the first things that disappointed me is that to do this mining currently you cannot use your computer connected to a simple LoRa card or create your own miner like with a Rasperry pi, but you must necessarily use a dedicated miner manufactured by a company authorized by the company managing the project.

Why?..

But despite this, taken by the hype, I decided to try this “revolution” of cryptocurrencies, not wanting to wait 6 months for delivery by ordering from official sites, I went to Ebay and bought one with shipping in 24h, spending practically double the original price. I bought a Bobcat miner 300, which should be one of the best miners on the market.

I also bought a nice powerful antenna, installed everything on the roof of my house, created a VPN system in my network to publicly expose a specific port needed for mining.

At the beginning everything worked quite well and the first mining gains arrived, not very high and lower than what I expected, but it was acceptable ..

But after a few months, the mining earnings went practically below zero, it seems that everyone in my area has decided to mine HNT too. In short, among so many problems and ridiculous earnings I realized that I will never make up for my investment, so at least let’s see what I got ..

Device and Security Concerns

The HNT miner in general needs to have publicly open the TCP port 44158 to communicate whit the HNT Blockchain, so to work properly a Port forward is needed, and doing so we will expose our private IP, which is not a good thing, but we can use a VPN whit a VPS, that’s should be the best practise

But wo really make this device?

After some deep digging, I found this photo of an early model, where “EasyLinkin” is written as the manufacturer on the back: https://fccid.io/2AZCK-MINER300/External-Photos/External-Photos-5413181

So the real manufactory is this Chinese company: http://www.easylinkin.net/ , we can see on the Homepage there is a Device that is identical to our Bobcat 300 This product is used on an industrial level for different applications and modes, for this reason on the motherboard we find different slots for things not related to the HNT or empty such as GPS etc.

On internet they are scary stories of people who also opened the port 22 and found themselves in their own compromised network.

Screen from the Official Support page

So clearly Bobcat support can access our device remotely if port 22 is exposed …
So unknown people, from an unknown country (probably China), can access our personal device and do any operation .. but above all this device is an access point to our internal home network, once inside the device it is possible to enumerate all other devices in the network, try to hack them, steal private data or in general compromise our network. Or whoever has this SSH key can use these devices to create a botnet and perform malicious attacks from our ISP.

This raises several questions .. Who has access to the SSH keys? Are these keys unique for each device or it is just one for all? How are these keys stored? who has access to it?

So with all these security concerns, it’s time to take full control of this miner and prevent anyone from accessing it without permission. But before continuing with this reading, please check that your Bobcat is not exposing port 22 on the internet at this time.

Exploit

Warning: the following procedure can invalidate the warranty of the device and potentially break it or compromise its behavior.Proceed at your own risk, I will not take any responsibility for any damage you may cause.

Before starting:

  • This guide tries to be as simple and clear as possible to everyone, but some assumptions of IT knowledge are taken for granted, especially on how to use a Unix shell
  • I’m not sure if the technique below works on every Bobcat 300, as there are several hardware releases and revisions so this may not work on your device or the exploit was patched whit a firmware update
  • This was performed on Board: TU-GM1002Z, CPU RockChip RK3566, Firmware version: V.1.0.2.91
  • Pro tips: If there is no recovery button on the motherboard of your device, but there are ‘pin holes’ where it should be or somewhere there is just a similar shape, if you have the skills, try soldering a button 🙂

The device offers a few open TCP ports, we have port 22 for SSH, port 80 for the Web interface and port 44158, which is the main port for the HNT protocol.

The web server doesn’t expose many particular features or pages that may be vulnerable to an exploit and the other ports it doesn’t offer anything of interest.

So, it’s time to see what’s behind the hood. The interesting parts are the “recovery” button and the 2 micro USB ports “USB_OTG” and “DEBUG”. initially, I thought the debugging was the most important one, but in reality, it is the “USB_OTG” that interests us. The “DEBUG” port can probably be used to upload and download the firmware, but the drivers and applications of the manufacturer are needed.

Internal board of the Device

Disconnect all cables from the device including the power supply, hold down the “recovery” button, while inserting the power cable, and wait a couple of seconds with the button pressed before releasing it.

If after this the light on the LoRa board for the antenna turns on and the main LED remains off, this means that we have successfully entered the recovery mode.

Now, just insert a micro USB cable to the “USB_OTG” port (the one exposed in the panel, not the internal “debug” port) and connect it to your computer. In the device manager of the computer we will find an “Android ADB interface” device connected.

If no device is found or the computer cannot identify the type of device, it could be useful to install the RockChip driver or other useful drivers for ADB interface.

The Android Debug Bridge (ADB) is a versatile command-line tool that lets you communicate with a device, basically is a tool that creates a UNIX type shell on an Android/ARM-based device that is in listening. We just need to download the Android SDK tool from here and open the cmd in the directory that contains adb.exe.

First of all, use the command “adb devices” to get the list of devices, if everything worked we should have a device in the results. And now just simply run the “adb shell” command and as a result we will have a UNIX like shell directly on the miner as we can see from “admin@bobcatminer”

This shell is whit the Unix user called ‘admin’ and we have root permissions but it is an incomplete operating system, this is recovery it is a fake O.S. used for debugging purposes. We can have fun exploring the file system but there isn’t much, the only interesting things are inside the /userdata directory where are present scripts and test results made in the factory to check the operation of the device, and also keys/certificates(generated based on the MAC address of the device) which appear at first sight to be used for OpenVPN(maybe for OTA update(?), very interesting … but that’s not what we’re interested in to unlock this device, maybe we’ll come back another time to take a closer look in this folder…

After some exploration, I find that the disk is partitioned and divided into multiple sectors to check this just use the command fdisk - l to see the partitions inside the disk.

Certainly, the most interesting partition is the one called “rootfs” which should contain the complete file system and none of them implement any security check or encryption, so .. why not try to simply mount them ??

Use the command “mount /dev/block/by-name/rootfs /mnt/sdcard” to mount the sector “rootfs” in the /mnt/sdcard folder (can use any empty folder instead).

Now in this folder, we have mounted the real file system of the device that will be used in its normal operation and we have completely read and write permissions so we can modify it as we like. There are several interesting files and folders, but our goal is to take control of the device and we can explore the file system later once we have established solid access.

So I’ll go straight to the point.

As we said before there is an SSH port, let’s check who has access to this port with the command “cat /mnt/sdcard/home/admin/.ssh/authorized_keys”

SSH key on the device

This file contains a public key basically anyone who has the corresponding private key can enter directly from SSH and have full control of the device, this should only be the manufacturing company for support reasons, I’m right?

Also, it would be interesting to know if the keys are generated uniquely for each device or if it is the same for every device so that whoever finds this key could possibly compromise all the miners and create a botnet.

If we replace this key whit one under our control we will have access to the SSH service whit the user admin. To do this we can use PuttyGen to create our set of keys and use the echo command to replace it to the authorized host. You can also just append it after the one that is already in use if you want to maintain it for support (or if you like the idea that a stranger can connect to your device 😀 ) or just make a backup and change it if needed.

After generating the keys, use the “echo "ssh-rsa AAAAB3Nza…….." > /mnt/sdcard/home/admin/.ssh/authorized_keys” command by inserting in it the putty gen output which is the public key but already structured for this file, and save the corresponding private key with the button “Save private key”.

To enter the device it is set that in addition to the private key, the user password is also required, so in this case the password of the admin user, we can try to Bruteforce the password of the user present in the shadow file .. or we can just modify the file /mnt/sdcard/home/admin/.ssh/authorized_keys changes the last string from “AuthenticationMethods publickey,password” to “AuthenticationMethods publickey

In doing so we have modified the configuration file of the SSH service, setting as the authentication method only the exchange of certificates without the password.

And now reboot the device and connect it back like normal, it will start its normal work without difference.. But now you can use Putty, or your favorite remote connection tool, to connect whit SSH to is normal IP and set the authentication method passing it the private key generated by us and as an admin user.

In doing so we have complete control of the device as root user, we can see everything and control it completely, so if in the event that the mining of HNT is no longer profitable one day, at least we can use this device as a personal mini server 🙂

Conclusion

Unfortunately for lack of time and expertise on this type of device I have not deepened the exploration of the file system, it will be interesting to see if someone finds something interesting inside or finds ways to improve the device. Surely it will be interesting to see what the community can come up with.

And please, before putting any strange device on the home network, check carefully what it is and if it can be a vector of cyberattack, and above all never expose ports (such as 22) freely on the Internet if you do not have full control of it.

If you have any problems or are unable to follow this guide, you can contact me directly, I will try to reply as soon as possible.

Thanks for reading.

CRLF Injection – Sercomm VD625 CVE-2021-27132

An issue was discovered in Sercomm AGCOMBO VD625-Smart Modem – Firmware version: AGSOT_2.1.0, there is a CRLF Injection vulnerability via the header field “Content-Disposition“.

The Sercomm AGCOMBO VD625-Smart Modem is a CPE (Customer-premises equipment) made by Sercomm for the various ISPs (Internet service providers). The device in which the vulnerability was found is the one for TIM (Telecom Italia).

The vulnerability described below refers specifically to the firmware version: AGSOT_2.1.0 in the image below there are complete information of the device where the vulnerability was found.

The device expose a web interface for management, it is possible to create a modified http request to the web server, just putting a .txt or other type of extension in the url of GET request, the device thinks it is a download request. Then the system takes the contents of the url that we insert and puts it in the header field “Content-Disposition” and the system will try to download this file.

This header field is not properly sanitized, so it is possible to use the CRLF technique(\r\n) to force the header to wrap by inserting a new line and then insert other header fields as desired in the http response.

As we can see in the image, we were able to inject the CRLFInjection cookie using the CRLF technique (encoding the values \r\n with %0d%0a) in the GET request with the url test.txt. In short, the system takes the url as input and puts it in the “Content-Disposition” field and it tries to download the selected “file”, but when it finds the CRLF field it wraps the header and adds other header fields that we have concatenated in the url.

While it does not appear to be a serious impact on the system, theoretically a possible attacker could find a way to use it to compromise the system by loading malicious code or it could even lead to an XSS.

The Common Vulnerabilities and Exposures (CVE) Program has assigned the ID CVE-2021-27132 to this issue. This is a record on the CVE List, which standardizes names for security problems.

For more info about CRLF injection: https://www.acunetix.com/websitesecurity/crlf-injection/

Vulnerability timeline :

  • 8/1/2021: I discovered the Vulnerability.
  • 13/1/2021: The vendor was informed about the vulnerability using PSIRT@sercomm.com .
  • 8/2/2021: The vendor confirmed the vulnerability, and said will fix it in the next release.
  • 9/2/2021: Request CVE ID.
  • 18/02/2021: Assigned CVE-2021-27132.
  • 25/02/2021: Public post.