[MASOCH-L] RES: Locaweb - Problemas com E-mails - Locaweb sofre ataque cracker
Alexandre Gorges
algorges at gmail.com
Mon Sep 20 14:17:32 -03 2010
No php eu desligo algumas coisas
disable_functions
escapeshellarg, escapeshellcmd, exec, passthru, proc_close, proc_open, shell
_exec, system, dl, popen, php_check_syntax, php_strip_whitespace, symlink, l
ink, openlog, apache_child_terminate, apache_get_modules, apache_get_version
, apache_getenv, apache_note, apache_sentenv, virtual
E limito o opendir para o home onde fica o site:
open_basedir /home/sites/xxxx.com.br:/usr/share/pear
doc_root /home/sites/xxxx.com.br
Alguma outra sugestao para o php?
[]'s
Alexandre Gorges
http://www.google.com.br/profiles/algorges
MSN/Skype: alexandre at dag.net.br
ICQ: 2031408
> From: Egberto Monteiro <egbertomonteiro at gmail.com>
> Reply-To: Lista Masoch <masoch-l at eng.registro.br>
> Date: Mon, 20 Sep 2010 14:10:55 -0300
> To: Lista Masoch <masoch-l at eng.registro.br>
> Subject: Re: [MASOCH-L] RES: Locaweb - Problemas com E-mails - Locaweb sofre
> ataque cracker
>
> O buraco é mais embaixo, se o cara envia o arquivo já compilado?
>
> Deve-se dificultar/impossibilitar a execução de arquivos arbitrarios e
> para isso existem N possibilidades.
>
> Att,
> Egberto Monteiro
>
> Em 09/20/2010 01:20 PM, Alexandre Gorges escreveu:
>> Chmod 700 /usr/bin/gcc apenas root pode usar.
>>
>>
>> []'s
>> Alexandre Gorges
>> http://www.google.com.br/profiles/algorges
>> MSN/Skype: alexandre at dag.net.br
>> ICQ: 2031408
>>
>>
>>
>>
>>> From: "Alexandre J. Correa - Onda Internet"<alexandre at onda.psi.br>
>>> Organization: Onda Internet Ltda.
>>> Reply-To: Lista Masoch<masoch-l at eng.registro.br>
>>> Date: Mon, 20 Sep 2010 12:07:16 -0300
>>> To: Lista Masoch<masoch-l at eng.registro.br>
>>> Subject: Re: [MASOCH-L] RES: Locaweb - Problemas com E-mails - Locaweb sofre
>>> ataque cracker
>>>
>>> mas se o php for bloqueado (extensoes/funoces de execução).. ja
>>> dificulta..
>>>
>>> manter o /tmp e outras pastas de escrita "publica" com permissoes de
>>> noexec no "mount" ...
>>>
>>>
>>> Em 20/09/2010 12:03, Marcelo Coelho escreveu:
>>>> Alexandre,
>>>>
>>>> Estas medidas apenas criam alguma dificuldade, mas não resolvem o problema:
>>>>
>>>> - o invasor pode compilar o exploit remotamente e enviar para o servidor.
>>>> - limitações de acesso ao wget, nc, shell_exec etc podem ser contornadas
>>>> com
>>>> scripts perl e php.
>>>>
>>>>
>>>>
>>>> On Sep 19, 2010, at 4:16 PM, Alexandre J. Correa - Onda Internet wrote:
>>>>
>>>>> 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-culpa>>>>>>>
/
>>>>>>>>>> <
>>>>>>>>>>
>>>>>>> http://blog.tehospedo.com.br/novidades/2010-09-17/locaweb-nao-teve-culpa
>>>>>>> />
>>>>>>>> __
>>>>>>>> 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
>>>
>>> __
>>> masoch-l list
>>> https://eng.registro.br/mailman/listinfo/masoch-l
>>
>> __
>> masoch-l list
>> https://eng.registro.br/mailman/listinfo/masoch-l
>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
More information about the masoch-l
mailing list