Analyzing minerbabe suspicious IP traffic

hi guys,

i would like to warn all miners about using the minerbabe OS and their grin miner - kbminer, since the miner is a closed source shady code that sends some data to their website before it starts the mining process

you can grab the miner from here: https://cdn2.minerbabe.com/miners/kbminer_0.5.2.tar.gz

if you start the miner with strace, you will find out that miner will not start to mine until it is able to connect to IP address 8.208.31.48 and sends some data there (who knows what)

you can easily verify this, by adding a nat rule on minerbabe os
/sbin/iptables -t nat -A OUTPUT -p tcp -d 8.208.31.48 --dport 443 -j DNAT --to-destination 127.0.0.1:443
if the miner is unable to connect to their IP address, it returns a kind of nonsense - out of memory error

strace -f -e trace=network -s 10000 ./kbminer --pool eu.stratum.grin-pool.org:3416 --user f*ckchina --pass test --algorithm=grin-cuckaroo29

strace: Process 24899 attached
[pid 24896] socket(PF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 5
[pid 24896] setsockopt(5, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
[pid 24896] connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr(“192.168.99.1”)}, 16) = 0
[pid 24896] getsockname(5, {sa_family=AF_INET, sin_port=htons(38837), sin_addr=inet_addr(“192.168.99.96”)}, [16]) = 0
[pid 24896] getpeername(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr(“192.168.99.1”)}, [16]) = 0
[pid 24899] socket(PF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 10
[pid 24899] setsockopt(10, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
[pid 24899] connect(10, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr(“192.168.99.1”)}, 16) = 0
[pid 24899] getsockname(10, {sa_family=AF_INET, sin_port=htons(50241), sin_addr=inet_addr(“192.168.99.96”)}, [16]) = 0
[pid 24899] getpeername(10, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr(“192.168.99.1”)}, [16]) = 0
[pid 24896] socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 5
[pid 24896] setsockopt(5, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
[pid 24896] connect(5, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr(“8.208.31.48”)}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 24899] getsockopt(5, SOL_SOCKET, SO_ERROR, [0], [4]) = 0
[pid 24899] getpeername(5, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr(“8.208.31.48”)}, [16]) = 0
[pid 24899] getsockname(5, {sa_family=AF_INET, sin_port=htons(34578), sin_addr=inet_addr(“192.168.99.96”)}, [16]) = 0
[pid 24899] setsockopt(5, SOL_TCP, TCP_NODELAY, [1], 4) = 0
[pid 24899] setsockopt(5, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
[pid 24899] setsockopt(5, SOL_TCP, TCP_KEEPINTVL, [30], 4) = 0
[pid 24899] setsockopt(5, SOL_TCP, TCP_KEEPIDLE, [30], 4) = 0

This is somewhat expected behaviour, since they announced they have a 3% fee. The only way to enforce such a fee is by contacting some external server. Not saying they arent doing else that is shady, but at face value i can understand this.

kbminer will get the configure which is set by the user (such as the pool address, email and so on) from www.minerbabe.com before mining. During mining kbminer may connect to a pool to mine for the dev fee.

dewminer76,

While it’s good that you scrutinize the traffic from the kbminer,
your claims of trojan/malware are not supported by your findings.

Jie’s explanation of fetching miner configurations set on http://www.minerbabe.com/ makes sense.

Please adjust your post title to something like
“Analyzing minerbabe IP traffic” and don’t use terms like “shady” unless you have convincing evidence.

at this moment, i know at least that the minerbabe os collects the rig mac address, registers it at their site if one has a user account created.
when the miner starts, it checks the registration and if the rig mac address is not registered, the miner will not start.

the miner itself allows you to specify the connection details
miner@miner:/opt/kbminer_0.5.2$ ./kbminer --help
Usage: kbminer [–verbose] --pool POOL --user USER [–pass PASS] [–agent AGENT] [–gpu GPU] [–params PARAMS] [–enableapi] [–apiaddr APIADDR] [–disablewatchdog] [–algorithm ALGORITHM] [–timeout TIMEOUT] [–connecttimeout CONNECTTIMEOUT] [–readtimeout READTIMEOUT] [–writetimeout WRITETIMEOUT] [–retryinterval RETRYINTERVAL] [–maxretry MAXRETRY]

Options:
–verbose, -v
–pool POOL
–user USER
–pass PASS [default: x]
–agent AGENT [default: kbminer]
–gpu GPU
–params PARAMS
–enableapi [default: true]
–apiaddr APIADDR [default: :3333]
–disablewatchdog
–algorithm ALGORITHM [default: grin-cuckaroo29]
–timeout TIMEOUT [default: 1m0s]
–connecttimeout CONNECTTIMEOUT
–readtimeout READTIMEOUT [default: 5m0s]
–writetimeout WRITETIMEOUT
–retryinterval RETRYINTERVAL [default: 10s]
–maxretry MAXRETRY [default: 10]
–help, -h display this help and exit

There’s another nice “feature” of minerbabe: it comes preconfigured out of the box with a preloaded /mnt/usb/work/.ssh/authorized_keys file (where /mnt/usb/work is the home directory of the work user via a /home/work symlink) with a nice pre-loaded ssh login key:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDiuI8bHis0f9UJM2qZhrw25+n2fCXWsHV20h+UTbc6rrATaDEUonSbRfEbliysjZpcRxqhZXCzSE9pXKqFnIq54uGIiPXFufg53/NCuPlqO1t/6JAj3qt0txE/mu1yw2QgpWIFpeMsdtdF9yARiaJCgitzsM1mAI9MxNONiJgdbDtblkp903SKPtm7nQfUuP//oJ5iHFKKP8cnTV7JQbPxpt0AbtBuLxeAJvh5wnyTyKSH1VuXMdloJrnK+DD/oEzlpsRAMgEKQjgWRdhHXmHYG3e4OXWihKRo6a8J2ARhLd8OFWVi6jg3fZ5ZKPgCf8SFf6QvtklWvA4x+rw9mhlv work@diagnostic

Oh and the work user of course has root access via the nice work ALL=(miner) NOPASSWD: ALL in /etc/sudoers.

Nah, I’m sure this is legit for… um… something something about being needed for the dev fee.

The miner download link we are talking about,
https://cdn2.minerbabe.com/miners/kbminer_0.0.4.tar.gz

https://cdn2.minerbabe.com/miners/kbminer_0.0.5.tar.gz

I’m guessing that is used to troubleshoot for customers. Considering the optimizations he has made for mining he would be smart enough to add a less obvious vector for shenanigans… If in doubt isolate it to its own network and kill it if it stops submitting the expected work.

the latest miner is here:
https://cdn2.minerbabe.com/miners/kbminer_0.6.4.tar.gz

to be able to use the miner without installing the whole os, you have to:

  • create your account at minerbabe site
  • install the minerbabe OS in VM
  • set the VM’s mac address to the mac address of your rig
  • repeat for each rig (shutdown the VM, change the mac address to second rig, start the VM again…)

how to upgrade to 0.6.4 ?
thanks

Why minerbabe? I get with original grin-miner for c31 a 0,583 gps per 1080ti and minerbabe 0,551

Better worry about all the ASICs coming out this summer and october!
The rewards will even fall further for us!

Why kbminer ? > Does oryginal grin-miner support c31 on AMD ? Kbminer does, very good hashrate.

HiveOS + kbminer integration needed. Someone managed to do it ?

I’ve tried doing this and still get “failed to retrieve minerbabe user info”. What version of linux were you using for the vm?

you have to enter your account name in the /rig_info/account.txt file

I have already copied a modified account.txt to /rig_info/ on the machine i’m getting the error. What version of linux were you able to run kbminer standalone on? I’m on 18.04, I see minerbabe is using 16.04.5 4.4 #116 kernel. Did you have to match this?

kbminer works on both, ubuntu 16.04.5 or 18.04.1. you have to modify the account.txt on the VM that runs minerbabe os, not on the mining rig you want to run kbminer.
again, when kbminer starts, it is connecting to minerbabe “platform” and checking if the mac address of the machine you’ve started kbminer is “registered”

I’ve registered the machine through the vm with the spoofed mac address and it shows in the mb dash. I’ve also booted the physical machine with that mac address with the full image and it shows up the same in mb dash. /rig_info/ appears to be the mount point of the first partition. Must be something else i’m missing. Thanks for the input.

I think they’ve modified how it checks now. strace is not showing any external sockets. tcpdump ran though wireshark doesn’t show anything either. :frowning:

i don’t think they’ve changed something, make sure that the miner is able to connect to 8.208.31.48:443