CronRAT: O perigoso malware Linux que está agendado para correr no dia 31 de fevereiro
O Linux, por norma, está muito mais protegido que a maioria dos sistemas e não tem falhas a serem exploradas. Este cenário acontece ao longo dos últimos anos, ainda que com algumas falhas pontuais, que se revelaram graves e perigosas.
Um novo momento destes aconteceu, com mais uma chegada de malware ao Linux. Chama-se CronRAT e tem algumas particularidades, sendo a que mais chama à atenção estar preparado para correr no dia 31 de fevereiro.
O malware tem estado a ganhar cada vez mais espaço e a ocupar áreas em que até agora estava longe e sem impacto. É isso o que agora se vê com o CronRAT, uma ameaça bem perigosa e que está a minar o universo Linux.
Detetado pela empresa Sansec, este novo RAT (remote access trojan) usa técnicas para se esconder que até agora eram desconhecidas. O seu objetivo é o roubo de informações de cartões de crédito, usado para isso os conhecidos ataques Magecart, focados em lojas online.
Isto leva a que código seja injetado nas páginas de pagamento e permite o roubo de dados dos cartões de crédito. A piorar a situação, o CronRAT consegue passar despercebido para a grande maioria das soluções de segurança para Linux.
Para o fazer usa a conhecida CRON, mas com um pormenor muito simples. Agenda todo o seu código malicioso neste elemento de controlo do Linux, mas em datas que não existem. Semanticamente está correto, mas para datas incorretas, como o dia 31 de fevereiro.
Claro que depois da recolha dos dados, o CronRAT comunica com um servidor externo, para transmitir informação. Este passo leva a que seja descarregada e usada uma biblioteca específica, ficando assim mais visível, mas acessível para o atacante correr comandos Linux remotamente.
Este é mais um caso em que a segurança do Linux é colocada em causa. Este malware tem um comportamento totalmente diferente do habitual e como tal é difícil de detetar, o que o torna mais perigoso. Infelizmente, o dia 31 não existe e isso está a ser aproveitado para esconder o CronRAT e deixar que faça o seu papel destrutivo.
Este artigo tem mais de um ano
Proponha uma correção, faça uma sugestão
Loading ...
31 de Fevereiro ? Lol, nunca vai la chegar 😀
era teres lido tudo para teres percebido, mas “lol, nunca vai la chegar” [facepalm]
31 de fev. ? 😀
Creio que se devem ter enganado queriam dizer 32 de Fevereiro
Ahahah
Se utilizar o contador temporal numérico que o linux utiliza, pode executar dia 3 de março, ou dia 2 de março em anos bissextos.
Poderia ter sido útil, este tipo de artigo, deixar indicações para como cada um pode perceber se tem o RAT e o que fazer nessas situações.
Será um novo artigo a caminho?
concordo
Será que alguém leu a matéria?
Sexto Parágrafo:
“Para o fazer usa a conhecida CRON, mas com um pormenor muito simples. Agenda todo o seu código malicioso neste elemento de controlo do Linux, mas em datas que não existe. Semanticamente está correto, mas para datas incorretas, como o dia 31 de fevereiro.”
É o problema de muita gente…comentam sem sequer ler o(s) artigo(s)!
Olha! Um homónimo!
Essas instruções são fáceis de driblar… basta injectarem um mail em que a data seja 31 de Fevereiro, o computador irá tentar identificar a data, activa o programa, porque é o único que tem referência a essa data.
Voltando a 1995, o Barrotes possuía uma configuração parecida e bastava um programa receber uma data (ou era 31 de Junho ou 31 de Setembro) para o activar e espalhar. Até esse momento, ficava lá quietinho da pasta do MS-Dos. Era muito usado para assustar pessoas que usavam computadores.
Uso muito o CRON para fazer coisas a 31 de Abril
Uma forma de ultrapassar esta problemática é:
sudo apt-get remove cron Uninstall cron
E eliminar todas as dependências.
Óbvio que nenhum job cron irá ser executado, e será aguardar por uma solução de desinfecção.
Isso é se for debian based…
Pensa mais à frente.
LOL!! Nada de CRON ou CronRAT 🙂
Bem, pelo artigo não vejo qualquer falha do linux. Um trojan para ser “instalado” o atacante precisa de ter acesso ao sistema. Este artigo, bem como todos os outros que li na internet, que são todos práticamente cópias uns dos outros e não dizem como se consegue o acesso para adicionar este cron e scripts associados.
Pode realmente ser uma falha do linux (ou de outro SO), ou de uma app, ou outra coisa qualquer, mas só quando se mostrar a real “porta de entrada”, até lá, é apenas um “simlpes script malicioso” que foi colocado/configurado por alguém que tem acesso root no computador.
Acertaste e bem no alvo!! É mesmo apenas um script malicioso que é colocado na pasta do cron mas sem privilégios root o script nunca vai lá parar!! Resultado: um malware que de malware não tem nada 😛
Depende qual a pasta onde vá parar o malware. Se a pasta tiver direitos 777 (Root) pode ser executado por outro script não malicioso e a partir daí fica instalado (seguramente noutra pasta até possivelmente escondida) e pode ser executado remotamente.
Não sei se me fiz compreender. Há malware que recorre a scripts e software legítimo para fazer instalar o malware. Os ficheiros do malware até são mais suscetíveis de entrar num sistema se os ficheiros não estiverem agregados ou compostos por forma a despistar os sistemas de segurança, contudo quando o script legítimo ou software é executado o malware é compilado e executado.
Pronto, foi descoberto malwarzeco para linux que na prática nem faz nada por ora. Comparativamente aos milhões de malware para windows, continuo imensamente tranquilo.
A ignorância faz as pessoas felizes
O Linux, por norma, está muito mais protegido que a maioria dos sistemas e não tem falhas a serem exploradas.
Quem escreveu isto? Que coisa mais ignorante….
ht tps://cve.mitre.o rg/cgi-bin/cve key.cgi?keyw ord=lin ux