[MASOCH-L] RES: RES: Locaweb - Problemas com E-mails - Locaweb sofre ataque cracker

Mon Sep 20 12:05:45 -03 2010

  talvez o atacante não usou ssh, simplesmente um script php com o 
shell_exec("gcc -m32 /tmp/arquivo.c -o /tmp/arquivo"); 
shell_exec("/tmp/arquivo; whoami;");

ja resolvia o problema..

Em 20/09/2010 11:38, Cleber @ Listas escreveu:
> Alexandre,
> Concordo contigo. Essa falha do exploit todos que utilizam 64bits e o modo
> de compatibilidade com o mesmo Kernel e permitem SSH remoto para o usuário,
> estão vulneráveis. Infelizmente, o caso tomou essa proporção pelo simples
> motivo deles terem muitos clientes nos ambientes compartilhados.
> Sinceramente, para nossos clientes não permitidos acesso SSH, tentamos dar o
> maximo de ferramentas para o cliente fazê-lo via painel de controle.
>
> -----Mensagem original-----
> De: masoch-l-bounces at eng.registro.br
> [mailto:masoch-l-bounces at eng.registro.br] Em nome de Alexandre J. Correa -
> Onda Internet
> Enviada em: domingo, 19 de setembro de 2010 16:17
> Para: Mail Aid and Succor, On-line Comfort and Help
> Assunto: Re: [MASOCH-L] RES: Locaweb - Problemas com E-mails - Locaweb sofre
> ataque cracker
>
>    Em algum ponto a LocaWeb falhou sim, mas sacrafica-la como tem sido feito,
> não é "justo" (digamos assim).
>
> A falha da locaweb é comum em várias empresas de hosting:
>
> - deixar os compiladores acessiveis aos usuarios.
> - alguns binarios como wget, nc, etc ficam disponiveis para execucao de
> qualquer usuario..
> - permitir a execucao de scripts.
> - deixar algumas funcoes do php ativas (dl_open, shell_exec, etc)
>
> consegui o exploit e fiz testes em varios servidores..
>
> [alexandre at xxx aaa]$ gcc Ac1dB1tch3z.c -m32 -o Ac1dB1tch3z [alexandre at xxx
> aaa]$ ./Ac1dB1tch3z Ac1dB1tCh3z VS Linux kernel 2.6 kernel 0d4y $$$ Kallsyms
> +r $$$ K3rn3l r3l3as3:
> $$$ prepare_creds->ffffffff8024b626
> $$$ override_creds->ffffffff8024b755
> $$$ revert_creds->ffffffff8024bbf4
> $$$ Kernel Credentials detected
> ??? Trying the F0PPPPPPPPPPPPPPPPpppppppppp_____ m3th34d $$$
> timer_list_fops->ffffffff806bbb80 $$$ w34p0n 0f ch01c3: F0PZzZzzz $$$
> Bu1ld1ng r1ngzer0c00l sh3llc0d3 - F0PZzzZzZZ/LSD(M) m3th34d $$$ Prepare:
> m0rn1ng w0rk0ut b1tch3z $$$ Us1ng cr3d s3ash3llc0d3z $$$ 0p3n1ng th3 m4giq
> p0rt4l $$$ m4q1c p0rt4l l3n f0und: 0x7fa4543c $$$ 0v3r thr0w f0ps g0v3rnm3nt
> $$$ bl1ng bl1ng n1gg4 :PppPpPPpPPPpP sh-3.2# whoami; id root
> uid=0(root) gid=500(alexandre) groups=10(wheel),500(alexandre)
>
>
>    a fallha é no sistema de compatibilidade 32bits, veja que forcei o gcc
> compilar o exploit em 32bits..
>
> em um lik ja publicado aqui,
> (http://blog.tehospedo.com.br/novidades/2010-09-17/locaweb-nao-teve-culpa/)
> tem um codigo para desligar a compatibilidade 32bits... se  nao rodar nenhum
> software que seja 32bits.. o melhor eh desativar definitivamente a
> compatibilidade !!
>
> :)
>
>
>
> Em 19/09/2010 15:09, Marcelo M. Fleury escreveu:
>> È muita prepotência dizer que a locaweb é amadora. Um dos serviços da
>> locaweb foi comprometido, em questão de horas os serviços foram
>> normalizados e isso sim é bom.
>>
>> Procure por domínios de grandes provedores aqui:
>> http://www.zone-h.com/archive
>>
>> terra, uol... todos já foram vitimas. O que a locaweb passou, qualquer
>> um pode passar, tal como já aconteceu com nasa, m$ e etc(e estamos
>> falando apenas de ataques que se tornaram públicos...).
>>
>> O importante é que eles busquem aprender com o ocorrido, e com certeza
>> isso deve acontecer, elevando ainda mais a sua maturidade.
>>
>> []s
>>
>> Em 18 de setembro de 2010 17:57, Guilherme
> Boing<kolt at frag.com.br>escreveu:
>>> Roberto,
>>>
>>> Sim, a discussão pode ser gigante, mas a culpa, independente do que
>>> houve, é da Locaweb, que é a responsável pela hospedagem desses sites
>>> que foram 'defaceados'.
>>>
>>> Não podemos por a culpa na RedHat, pois alem de ter sido uma escolha
>>> da própria Locaweb, utilizando o kernel deles, poderia ter aplicado
>>> correções e métodos de segurança que inibiriam qualquer tipo de
>>> exploit local a nível de kernel.
>>> Você não precisa dar permissão para o cliente rodar arquivo binário
>>> algum, se tratando de plataforma web. Muito menos, garantir acesso SSH.
>>>
>>> Se a Locaweb deseja garantir, por comodidade e como um diferencial,
>>> acesso SSH aos clientes, deveria prezar primeiramente pela segurança
>>> dos servidores, para depois sim, tomar um passo deste.
>>> De qualquer forma, é possível manter seu sistema seguro, independente
>>> de prover o acesso SSH aos clientes ou não.
>>>
>>> Essa historia se resume em amadorismo.
>>>
>>> 2010/9/18 Roberto Bertó<roberto.berto at gmail.com>
>>>
>>>> Ola Guilherme,
>>>>
>>>> Pelos horarios que aconteceram os eventos e as informacoes no twitter.
>>> Pode
>>>> ter sido outra coisa, mas duvido muito.
>>>>
>>>> Olha, a discussao de quem é a culpa é gigante. Podemos por a culpa
>>>> no pessoal que escreveu o codigo do kernel, podemos por a culpa na
>>>> redhat
>>> por
>>>> nao ter auditado, podemos por a culpa nos pesquisadores que
>>>> descobriram a falha, ou nos que divulgaram a falha na internet junto
>>>> com o exploit, ou até mesmo nos legisladores do mundo todo por nao
>>>> termos leis que criem um metodo seguro de divulgar falhas de
>>>> seguranca primeiro para as empresas que
>>> podem
>>>> corrigir e depois abertamente. Enfim... é enorme mesmo a discussao.
>>>>
>>>> Nao é bug de chroot de ftp.
>>>>
>>>> Em ambiente de hospedagem voce da acesso aos clientes a SSH e tambem
>>>> a execucao de comados, porque tem  php, perl, etc. Entao bastava
>>>> subir um binario compilado e executar ele e voce virava root. Eu
>>>> reproduzi isso
>>> num
>>>> ambiente de testes.
>>>>
>>>>
>>>>
>>>> 2010/9/18 Guilherme Boing<kolt at frag.com.br>
>>>>
>>>>> Desculpe, mas, baseado em quais fatos você relaciona o exploit '0day'
>>> que
>>>>> foi publicado com o acontecido na Locaweb ?
>>>>>
>>>>> E também, como você me diz que a Locaweb não teve culpa ? A culpa é
>>>>> de quem, dos usuários ?
>>>>> Uma falha no kernel não garante acesso privilegiado algum, se o
>>>>> sistema
>>>> for
>>>>> bem protegido e bem administrado.
>>>>>
>>>>> Pra começo de conversa, nem deveria ser possível tal exploit ser
>>>> executado
>>>>> em um ambiente de webhosting, ainda mais, em cima de um usuário web.
>>>>>
>>>>> Sendo um bug de chroot de ftp, um exploit local que elevou os
>>> privilégios
>>>>> do
>>>>> invasor, ou qualquer outra coisa, a Locaweb é responsável e culpada
>>> pelo
>>>>> ocorrido, pois era de sua responsabilidade, manter o sistema tanto
>>>>> atualizado como bem protegido.
>>>>>
>>>>> 2010/9/18 Roberto Bertó<roberto.berto at gmail.com>
>>>>>
>>>>>> Viu pessoal, aproveito para divulgar o workaround e a falha, na
>>> segunda
>>>>>> parte do artigo tem info de como proteger. Foi bem grave mesmo
>>>>>>
>>> http://blog.tehospedo.com.br/novidades/2010-09-17/locaweb-nao-teve-cu
>>> lpa/
>>>>>>    <
>>>>>>
>>> http://blog.tehospedo.com.br/novidades/2010-09-17/locaweb-nao-teve-cu
>>> lpa/>
>>>> __
>>>> masoch-l list
>>>> https://eng.registro.br/mailman/listinfo/masoch-l
>>>>
>>> __
>>> masoch-l list
>>> https://eng.registro.br/mailman/listinfo/masoch-l
>>>
>>
>
> --
> Sds.
>
> Alexandre Jeronimo Correa
> Sócio-Administrador
>
> Onda Internet
> www.onda.net.br
>
> IPV6 Ready !
> www.ipv6.onda.net.br
>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>

-- 
Sds.

Alexandre Jeronimo Correa
Sócio-Administrador

Onda Internet
www.onda.net.br

IPV6 Ready !
www.ipv6.onda.net.br