Visite também: Currículo ·  Efetividade BR-Mac

O que é LinuxDownload LinuxApostila LinuxEnviar notícia


Locaweb diz que Red Hat proporcionou invasão

Leia também: Bug: Canonical lança versões corrigidas do kernel, Red Hat está analisando soluções

Trechos da nota da Info, da qual reproduzi também o título:

Três dias após a invasão de um cracker nos servidores da Locaweb, clientes da empresa ainda reclamam dos serviços prestados.

Segundo o diretor de arte Daniel Canton, alguns dos sites que ele mantém na Locaweb voltaram, porém em versões antigas.

“Tenho 15 sites de clientes armazenadas no serviço. Alguns deles voltaram a partir de backups antigos. Porém as atualizações que tinha feito na sexta-feira foram perdidas”, aponta Canton, que é cliente da empresa há cerca de dez anos, segundo ele. (…) Cantom também reclama do atendimento prestado pela empresa. “É demorado e algumas solicitações não são respondidas. Quem trabalha com programação complexa frequentemente fica na mão”, afirma o diretor de arte.

(…) Procurada, a Locaweb afirmou que apenas “uma pequena parcela dos clientes que utilizam plataforma Linux foram atingidos.” Segundo a empresa, todos os serviços já foram restabelecidos.

Sobre a invasão, a empresa diz que foi alvo de uma vulnerabilidade do sistema operacional Red Hat Linux, documentada em https://access.redhat.com/kb/docs/DOC-40265, para qual o fornecedor ainda não tem solução. A falha foi solucionada por uma equipe da empresa no sábado. (via info.abril.com.br)


• Publicado por Augusto Campos em 2010-09-21

Comentários dos leitores

Os comentários são responsabilidade de seus autores, e não são analisados ou aprovados pelo BR-Linux. Leia os Termos de uso do BR-Linux.

    devnull (usuário não registrado) em 21/09/2010 às 8:21 am

    Argh! Ser cliente de uma empresa a dez anos achando o serviço ruim mostra que ele é preguiçoso e já deveria ter procurado outro fornecedor que atenda melhor a muito tempo.
    Simples assim.

    Piter (usuário não registrado) em 21/09/2010 às 8:25 am

    Depois que a cagada ta feita é facil empurrar a responsabilidade pra outro.

    Zé (usuário não registrado) em 21/09/2010 às 8:29 am

    Querem apostar quanto que vai aparecer um dizendo: “Pra que pagar por uma distro Linux? se eles não corrigem problemas, só falam qual são” ¨¬¬

    Adilson dos Santos Dantas (usuário não registrado) em 21/09/2010 às 8:36 am

    Com certeza não leram a notícia: http://br-linux.org/2010/escalada-de-privilegios-no-kernel/ e não se preocuparam em aplicar nenhum patch ou workaround. As vezes podem ser pego por algum outro bug em outro aplicativo que não atualizaram e culpam a Red Hat.

    Ou seja, foram lentos demais e nem se preocuparam em se prevenir.

    Dorival Boege Júnior (usuário não registrado) em 21/09/2010 às 8:37 am

    e dale nuvem …. muito obrigado … to fora !!!

    Victor (usuário não registrado) em 21/09/2010 às 8:58 am

    Estou convencido eles erraram, pois só aconteceu com alguns clientes… E é muito fácil pra eles escolherem um bug qualquer e culpar o Linux por isso. Ela queimou o filme comigo.

    Ricardo (usuário não registrado) em 21/09/2010 às 9:06 am

    Não exista nenhum sistema inviolável ou 100% seguro, apenas alguns são mais trabalhosos que outros. A prova está aí. Talvez a suposta garantia de segurança tenha feito o pessoal “baixar a guarda” e expor os pontos fracos.
    Não façam da tecnologia e da ciência uma religião. Cada coisa no seu lugar.

    João Medrado (usuário não registrado) em 21/09/2010 às 9:21 am

    Nessas horas controle de versão e backups feitos idependentemente do host mostram a que vieram.

    Lucas Timm (usuário não registrado) em 21/09/2010 às 10:46 am

    @Adilson

    Não entendi seu comentário, mas esse exploit não afeta o RHEL nem o CentOS 5.4 e 5.5, onde testei. Compilei e executei os exploits em meus ambientes de testes (com as referidas distribuições) e não deu certo (até falei isso na thread que tu postou).

    O que realmente mostrou (outra vez) um descaso com o profissionalismo foi a data dos backups. Problemas acontecem no Linux, no Windows, onde for. Mas não ter um backup atualizado, pra mim, seria a gota d’agua se eu ainda fosse cliente deles. Já tive péssimas experiências com a Locaweb em algumas empresas que trabalhei e esse é apenas mais um motivo pra eu não recomendar.

    Andrei (usuário não registrado) em 21/09/2010 às 11:13 am

    100% seguro não existe mesmo não no entanto é fato que existem outros Sistemas operacionais bem INseguros, que lançam suas versões “estáveis” repletas de furos e nós sysadmins temos que garimpar soluções no google.

    Alessandro (usuário não registrado) em 21/09/2010 às 11:35 am

    O pessoal da Locaweb são espertos eim? Atribuindo a EXTREMA incompetência deles para um bug. Todo mundo sabe que a Locaweb está próxima do caos. Conheci várias pessoas que trabalharam lá, e todas falaram que a empresa é muito desorganizada, muitos profissionais incompetentes, gestores que não sabem o que estão fazendo (É só lembrar do Alex Glikas – Diretor Comercial da Locaweb, que ofendeu a torcida do São Paulo, e olha que eles estavam patrocinando a clube. E todos os gestores técnicos seguem o mesmo molde da besta do Diretor Comercial). Agora querem tirar a culpa das costas deles e passar para uma empresa séria como a Red Hat. E além de usar software livre, sem contribuírem com nada, ainda querem exigir alguma coisa. Um de meus clientes perdeu o seu banco de dados inteiro na Locaweb e eles falaram que foi um ataque, e que não tinham nada a ver, e que o problema era do cliente. Locaweb, vocês não enganam ninguém mais no Brasil!!! É bom mesmo começar a atuar na Argentina, Chile, etc, pois ainda eles não conhecem a má fama que vocês tem no território Nacional.

    J (usuário não registrado) em 21/09/2010 às 11:48 am

    O bug deve ser explorar localmente, então alguém deve acesso ao servidor…

    Alexandre Bars (usuário não registrado) em 21/09/2010 às 12:08 pm

    Faz tempo que usava eles agora mesmo cancelar meu contrato!!

    Kleber (usuário não registrado) em 21/09/2010 às 12:08 pm

    Estranho, a vulnerabilidade do kernel é de elevar privilégios localmente, e como ele teve acesso como usuário comum? exploit em servidores de ftp? ssh? e por que outros hosts como hostgator ou até mesmo uol não tiveram este problema?

    Estranho…

    Alex Piaz (usuário não registrado) em 21/09/2010 às 12:11 pm

    Gente se vocês lerem o report da RH, vão perceber que as versões do kernel afetadas são 2.6.26-rc1 até 2.6.36-rc4. Ou seja, a locaweb está usando versões RC (Release Candidate) em seus servidores de PRODUÇÃO! Isso é uma falha de gerenciamento para a qual não há desculpa. Jogar a culpa na Red Hat é de uma ridicularidade maior ainda. Fujam da locaweb se puderem.

    Rodrigo (usuário não registrado) em 21/09/2010 às 12:18 pm

    Kleber, isto nao é estranho, e eh muito facil de acontecer em varios servidores linux. Um atacante pode aproveitar qualquer falha em software ou programacao usado por algum cliente da localweb para dar upload de algum script, digamos php, em um diretorio que o apache execute e com isto ter um shell para executar qq coisa localmente no servidor…
    Com isto uma falha q nescessita de acesso local eh facilmente executada.
    Isto é mais facil de conseguir do q os falam q o linux muito mais seguro do q o windows acham, soh q a falha para no acesso a usuario local. Por isto um bug de escalonamento eh gravissimo.

    Alessandro (usuário não registrado) em 21/09/2010 às 12:20 pm

    Alex Piaz,

    De fato a Locaweb é um laboratório experimental. Uma corja de incompetentes oferecendo um serviço péssimo para empresas sérias. SIGAM O CONSELHO do Alex Piaz: FUJAM DA LOCAWEB!!!

    Kleber (usuário não registrado) em 21/09/2010 às 12:21 pm

    Rodrigo, concordo plenamente, o que acho estranho é, existiu uma falha muito seria de gerenciamento que proporcionou o uso desta vulnerabilidade localmente, que seja configuração na execução do PHP, ou algum outro serviço com problema. o estranho é que a Locaweb jogou a bola pra RedHat e pronto.

    o (usuário não registrado) em 21/09/2010 às 12:54 pm

    Pessoal,

    A empresa ksplice criou um programa que verifica se o bug já foi ou não explorado na sua máquina linux 64 bits

    https://www.ksplice.com/uptrack/cve-2010-3081

    Mais detalhes em

    http://blog.ksplice.com/2010/09/cve-2010-3081/

    Wancley Mucchi (usuário não registrado) em 21/09/2010 às 1:01 pm

    Tenho sites hospedados em diversas empresas como UOL e SimpleWeb, e nenhuma delas sofreu ataque.

    E todas rodam em cima de RedHat… mas é lógico, que não é beta nem rc…

    Rodrigo (usuário não registrado) em 21/09/2010 às 3:11 pm

    @Kleber,

    Nao é falha de gerenciamento, pode ser de configuracao e nem é tao dificil de acontecer.
    Caso simples, imagina que eu faca locacao de hospedagem em site e EU faca um blog onde permita as pessoas mandarem fotos. O meu blog tem um script custom de upload que joga os arquivos em um subdiretorio diretorio imagens, e eu jogue um script.php. Se eu acessar depois imagens/script.php tenho um “programa” qq ja rodando local sobre o usuario do apache onde poderia inclusive baixar um binario da web e dar um shell execute.

    Este eh um exemplo, que ja vi acontece em um servidor que ajudo a manter. Apartir dai é rodar um exploit de elevacao, instalar rootkit, etc, etc a ponto que as vezes vc ta infectado, sem ter dano nenhum causado e nem sabe.

    Ta certo que isto é barrado por algumas configuracoes, como nao chroot, bloquear shellexecute a diretorio especifico, etc só que nao eh incomum muitas pessoas em servers q dao liberdade nas configuracoes, deixarem isto nao restrito, ate pq isto dificulta a programacao.

    @Rodrigo

    Foi o que o pessoal aqui desconfiava: falha de configuração ou falha de estouro de buffer possivelmente no PureFTPD.

    Nesse caso, foi configuração mesmo.

    Ja que não dá pra depender de usuário dono de site fazer tudo certo, deve-se barrar a execução de shell em qualquer máquina dessas, por parte de usuários que não sejam o próprio root e/ou outros usuários do próprio provedor.

    Deve se usar e abusar também do chroot.

    Deve-se configurar o usuário php para não rodar shell também.

    Falhas ocorrem. Essa foi uma falha da Locaweb que aproveitou outra falha do kernel.

    Uma sucessão de falhas que deu no que deu (isso se a Locaweb está dizendo a verdade e vai ser difícil de confirmar).

    Mas bola pra frente.

    Fora que deixar execução de 32 bits habilitada em servidores 64 bits (esse é o foco da falha) é meio bobo.

    Será que a Locaweb precisa rodar algo de 32 bits em servidores de produção 64 bits?

    Acho que não.

    Fabio Luiz (falcon_dark) (usuário não registrado) em 21/09/2010 às 4:13 pm

    Eu vou me arrepender do que vou falar… mas vou falar assim mesmo. O que vocês estariam dizendo da Microsoft se esse bug e a Locaweb rodassem sobre Windows?

    É fácil dizer que a culpa é da Locaweb. Mas lembrem-se que muito provavelmente cada licença de RHEL custou caro e que ainda não há correção oficial da RH disponível para o bug que teria originado o problema. Não entendo porque uma empresa que compra uma licença de um SO precisa se responsabilizar por corrigir bugs nele. Se foi um problema da RH ou da Locaweb, tanto faz. Mas muitos de vocês estão sendo levianos em assumir como fato suas suposições (algumas muito forçadas) e em descatar qualquer culpabilidade da RH sendo que a MS seria cricificada se estivesse nesta mesma posição.

    Dêem à Cesar o que for de Cesar… nem mais, nem menos! Sejam sensatos, por favor!!!

    Joaquim Petiz (usuário não registrado) em 21/09/2010 às 4:39 pm

    Bom, não vejo culpa da Red Hat nesse caso, primeiro porque (não li toda a doc do bug, estou me baseando na notícia e nos comentários acima) o bug é para versões do kernel RC, servidores expostos na web não deveriam rodar versões desse tipo, se o cara compra Red Hat é porque precisa de estabilidade, segurança e suporte, se for para rodar versões beta ou RC, usa o Fedora mesmo..
    Segundo, como comentado acima, existem diversas boa práticas de segurança que poderiam e deveriam serem utilizadas, além do motivo de não confiar que o programador irá fazer tudo da maneira correta, estamos tratando de um grande provedor que o foco do negocio é hospedar conteúdo exposto a web.

    @Fabio Luiz

    Você tem razão: a Locaweb possui culpa e a RH também.

    A Locaweb por não seguir boas práticas de configuração e a RH por não corrigir o bug rapidamente. (a Canonical, por exemplo, corrigiu na sexta-feira mesmo)

    Na sexta a tarde, caso a Locaweb estivesse usando Ubuntu Server, não teria sido afetada como foi nesse episódio.

    Mas, essa é a vida.

    Sobre a Microsoft, não precisa nem falar né?! Ela entrega correções muitas vezes apenas semanas depois que os primeiros danos causados por exploits aparecem à tona.

    Nisso a RH não ganhou ainda. Esta demorando, mas não semanas até o momento.

    Lucas Timm (usuário não registrado) em 21/09/2010 às 5:30 pm

    @falcon_dark

    É uma coisa que eu costumo repetir. Realmente se acontecesse no Windows a culpa seria da Microsoft, e claro, “Linux FTW”.

    Eu não sou cliente da Locaweb há algum tempo, e pra mim o verdadeiro problema foi a ausência de backups atualizados. Problemas todos os SOs tem, até minha AIX apresenta de vez em quando. A diferença é a frequência com que eles ocorrem e a maneira que o administrador os corrige. :)

    Anderson Faria (usuário não registrado) em 21/09/2010 às 6:05 pm

    Se o problema é da Locaweb, pq então os sites hospedados em Win Servers não tiveram problemas ??

    CaFeCrAfT (usuário não registrado) em 21/09/2010 às 7:29 pm

    André Luis Pereira dos Santos,

    Redhat e CentOS faz uma salada com pacotes x86 e x86_64, tem até pacotes dependentes 64 de pacotes de 32.

    Aline Freitas (usuário não registrado) em 21/09/2010 às 7:36 pm

    Sem querer por mais lenha na fogueira, mas já pondo, a Red Hat respondeu dizendo que a Locaweb não é sua cliente e que um patch corrigindo a falha já foi disponibilizado há mais de um mês:

    http://tecnoblog.net/40970/red-hat-diz-que-locaweb-nao-e-sua-cliente/

    Augusto, se puder atualizar a notícia com a resposta acima.

    Aline, conversei com a Red hat a respeito, e recebi também o relato deles diretamente, confirmando esta informação (mas não a parte sobre haver fix há mais de 1 mês). Amanhã publico na capa do site, com o destaque merecido. Se publicar agora à noite, bem menos gente vai ver…

    CaFeCrAfT (usuário não registrado) em 21/09/2010 às 7:51 pm

    Aline Freitas,

    o estranho é que se o fix foi disponibilizado a mais de 1 mês então me expliquem isso:

    https://access.redhat.com/kb/docs/DOC-40265

    Renyer (usuário não registrado) em 21/09/2010 às 9:16 pm

    Lamentável jogar a culpa em cima de uma empresa séria como a Red Hat.

    Piero Ferraz (usuário não registrado) em 21/09/2010 às 10:23 pm

    Locaweb rebate afirmações da Red Hat
    .
    http://info.abril.com.br/noticias/seguranca/locaweb-rebate-afirmacoes-da-red-hat-21092010-54.shl
    .
    .
    .
    acho que isso ta longe de acabar, porém gostaria que alguém me esclarecesse uma coisa:
    .
    no bug anunciado aqui
    https://access.redhat.com/kb/docs/DOC-40265
    .
    fala que as versões do kernel afetada é 2.6.26-rc1 to 2.6.36-rc4.

    quem usa Red Hat ou CentOS até nas últimas versões 5.5 sabe que o kernel é o 2.6.18 e mesmo se rodar o yum upgrade continua no 2.6.18-xxx

    diferente disso é BETA, então… a Locaweb está usando versões beta do kernel em produção ?

    no fix anunciado, por quê esta apotando como afetado o 2.6.18…
    https://rhn.redhat.com/errata/RHSA-2010-0705.html ????????

Este post é antigo (2010-09-21) e foi arquivado. O envio de novos comentários a este post já expirou.