[GTER] RES: Ubiquiti Virus! NOVO!

[Elizandro Pacheco [ Pacheco Tecnologia ]]

Pelo tempo que ví e até onde ví..  e foi muito pouco tempo mesmo…

O script segue uma lógica inteligente…

Fatos a serem considerados:

- Ele vai entrar OBRIGATORIAMENTE por um dispositivo que tenha IP público ( E sim, por porta web: OU 80 ou 443 ).

// https://hackerone.com/reports/73480
// curl -F "file=@./passwd;filename=../../etc/passwd" -H "Expect:" 'https://192.168.1.20/login.cgi' <https://192.168.1.20/login.cgi'> -k

- Ele envia uma chave do ssh vis POST em uma url que NÃO VALIDA que tipo de arquivo e nem PRA ONDE ele está sendo enviado.

// curl -F "file=@.ssh/id_rsa.pub;filename=../../etc/dropbear/authorized_keys" -H "Expect:" 'https://192.168.1.20/login.cgi' -k


- Loga via ssh com as novas credenciais, e aí a brincadeira começa.

- O download, garante que o curl funcione e se não funcionar, baixa do site do openwrt outra versão

- A validação dos firmwares se dão somente no frontend, o cgi do backend não faz a validação, então quando o POST é direto pro cgi, ele simplemente aceita! Assim é possível sobrescrever qualquer arquivo ou criar um novo em qualquer lugar ( e aí, quando tiveram a ideia de sobrescrever as chaves do ssh… )

- Ele envia o curl, bem com as libs necessárias para tal ( maiores informações via ldd ) e caso não rode, baixa do site do openwrt outra versão.

- Ao rodar um dos diversos scripts, ele pega, via ifconfig os ips das interfaces ( ath0, br0 e pppoe0 ) e dá um scan nos blocos dos ips de todas essas interfaces e assim, consegue scanear os blocos do teu pppoe, e das demais interfaces.

ip=$(ifconfig ath0 2>/dev/null | grep 'inet ' | sed "s/.*inet addr:\([^ ]*\).*/\1/g")
if [ -z "$ip" ] ; then
ip=$(ifconfig br0 2>/dev/null | grep 'inet ' | sed "s/.*inet addr:\([^ ]*\).*/\1/g")
fi
if [ -z "$ip" ] ; then
ip=$(ifconfig ppp0 2>/dev/null | grep 'inet ' | sed "s/.*inet addr:\([^ ]*\).*/\1/g")
fi


- Nesse ponto do scan, ele é bem burro, pois não mede cidr, pega apenas o /24 do ip que estiver setado em qualquer interface.

- Blocos privados estão sendo afetados justamente por esse SCAN. Se a rede for em bridge ( MUITO PIOR! ) pois com o scan da classe da br0, a chance dele pegar os ips dos demais dispositivos da rede é amplificado.

- Ele adiciona regras no iptables bloqueando acesso a 80 e 443, assim você perde acesso web e dificulta a identificação do equipamento infectado ( já que a maioria tem como primeiro procedimento tentar acessar o dispositivo ), via ssh o acesso continua ok.

- Ele adiciona 2 usuários, então alguns dos scripts que apagam apenas o usuário mother, são ineficientes.


Enfim, até onde ví..  é isso.. 

Pra qualquer um que entende, ainda que o básico, de shell script ou quem acompanhou a época de injections de php, isso não é grande novidade.

O que me espanta, é a quantidade de bobagem que se cria em torno de achismos.

Não aqui, mas essa internet, as vezes passa do limite mesmo.


Um abraço, pros desenvolvedores backend da ubnt! Não que medidas não tenham sido tomadas pra corrigir, o que não torna o problema menos pior.

O outro abraço, vai pra quem não faz o tema de casa e deixa o firewall facilitando tais acessos e que acabam resultado nisso.

“Operadoras” sofrendo com isso, é demais pra minha cabeça.


Elizandro Pacheco



> Em 14 de mai de 2016, à(s) 19:05, João Lyma. <lyma at itsbrasil.net> escreveu:
> 
> Diego,
> 
> Em seu script esta linha:
> cat /tmp/system2.cfg >> /tmp/system.cfg
> 
> Não deveria ser:
> 
> cat /tmp/system2.cfg > /tmp/system.cfg
> 
> Assim acho que não duplicaria algumas linhas.
> 
> 
> Muito obrigado por disponibilizar o script!
> 
> 
> 
> ---
> JOÃO LYMA
> Analista de Redes
> ITS Telecomunicações
> +55 71 3177 5050
> www.itsbrasil.net
> 
> Em 14/05/2016 16:35, Diego Canton de Brito escreveu:
>> Acredito que comecei a tomar ações antes de sair essa variante. Só
>> tive reset de um PTP.
>> --
>> Enviado do aplicativo myMail para Android sábado, 14 maio 2016,
>> 03:15PM -03:00 de Márcio Elias Hahn do Nascimento <
>> marcio at sulonline.net> :
>>> Detalhe, esses equipamentos infectados tem suas configurações todas
>>> alteradas (SSID, Channel, etc) não aparecendo mais conectados as AP's!
>>> Com vcs é isso também? Estão batendo de porta em porta para
>>> reconfigurar e atualizar cada equipamento?
>>> Tivemos cerca de 500
>>> infecções! Tudo começou as 23:55 de ontem também, não dá pra dizer que
>>> não foi sincronizado o ataque.
>>> ---
>>> Att
>>> Márcio Elias Hahn do
>>> Nascimento
>>> (48) 8469-1819 / 3524-0700 -  marcio at sulonline.net
>>> INOC-BR:
>>> 52977*100
>>> GERÊNCIA DE RECURSOS DE TIC - Sul Internet [2]
>>>  [2]
>>> Em
>>> 14/05/2016 13:32, Rodrigo Baldasso escreveu:
>>>> Não, a vulnerabilidade
>>> permite acesso a cpe sem usuário/senha.. De acordo com o fórum da
>>> ubiquiti.
>>>> Sent from my iPhone
>>>>> On May 14, 2016, at 09:28,
>>> Robson mendes de souza < robsonzmendes at gmail.com > wrote: Estavam com
>>> senha padrão? Em 14 de mai de 2016 9:17 AM, "Alexandre Martini - Tecwave
>>> Telecom" <  tecwave at tecwave.com.br > escreveu:
>>>>>> Bom dia Resetando
>>> para as configurações default, atualizando o firmware e mudando a senha,
>>> resolverá o problema? Aqui tivemos todos Access Points resetados esta
>>> madrugada, especificamente 5 para a meia noite. -- []s Alexandre Martini
>>> -- gter list  https://eng.registro.br/mailman/listinfo/gter [1]
>>>>> --
>>> gter list  https://eng.registro.br/mailman/listinfo/gter [1]
>>>> --
>>> gter list  https://eng.registro.br/mailman/listinfo/gter [1]
>>> Links:
>>> ------
>>> [1]  https://eng.registro.br/mailman/listinfo/gter
>>> [2]
>>> http://www.sulinternet.net
>>> --
>>> gter list  https://eng.registro.br/mailman/listinfo/gter
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter