Um ataque em massa está agendado para essa próxima quarta-feira, 20 de junho, contra diversos sites que participam do evento RIO+20. O mais interessante disso tudo é que foi confirmada a …. Esta parte foi censurada para não gerar problemas ao blog. Digamos que será uma surpresa e tanto para todos os envolvidos

E aí, o que fazer ? Pois bem, sabemos que se defender de ataques DDoS não é uma das coisas mais simples do mundo. Você precisa de muito link para conseguir isso. Eu sugiro migrarem os principais sites para debaixo da Amazon.

E para a surpresa (parte censurada para não gerar problemas ao blog) ? Well, a coisa é bem mais complicada. (parte censurada para não gerar problemas ao blog) – Lembram do ataque contra o coruja nas vésperas do H2HC do ano passado ? Pois bem, o pessoal teve um trabalhinho para conseguir achar (parte censurada para não gerar problemas ao blog)

O pessoal da RIO+20 deverá passar pelo (parte censurada para não gerar problemas ao blog) na quarta, boa sorte !!:(

P.S.: Tudo isso que estou reportando só será evidenciado na quarta-feira. Só escrevi essas informações para deixar o pessoal que administra os portais do evento ligados, espertos, antenados e preparados.

P.S.S.: O pessoal sabe que não sou de publicar hoax por aqui, então, acompanhem….

Atualizações mais tarde…

Atualização.

Então, o pessoal encontrou um 0-day no Joomla que você consegue simplesmente criar uma conta de administrador, ok ? Blz, então. Daí, a mesma galera descobriu que o site do RIO+20 está hospedado no mesmo servidor do Incra. Até aí tudo bem, né?

Então veja o printscreen abaixo:

Bom, isso aí é um pulo para subir uma Wshell, correto ?!

Well, as cenas dos próximos capítulos serão divulgadas nas próximas horas — to vendo que isso vai dar merda..

Atualização fresquinha – já instalaram uma Wshell no servidor do incra e conseqüentemente, no rio+20 — agora ferrou de vez..

P.S.:  Acabaram de me informar que um e-mail com a falha/vulnerabilidade foi enviado aos administradores responsáveis pelo site e que nenhum dado e informação foram alterados, até agora.

Este tipo de vulnerabilidade, quando encontrada e explorada, deve ser reportada imediatamente aos administradores do site, isso porque os seus descobridores são pesquisadores.

Compartilhar:

Este post tem 34 comentários

  1. Nao entendi nada devido aos “(parte censurada para não gerar problemas ao blog)”

  2. fui informado que posso sofrer severas sanções caso os dados sejam publicados..

  3. Eita agora a coisa ta ficando boa…

  4. Mas se você está publicando justamente para evitarem o dano, e tomarem medidas preventivas ao ataque, onde está a lógica de você sofrer as sanções? Nao deveria ser para os envolvidos em derrubar o site?

  5. Tem maluco para tudo, sabes disso..

  6. ¬¬’ rsrs vdd..

  7. Que dó que dó que dó…..
    Nego fica postando coisa pra atrair atenção ao Blog.
    Tenta estudar primeiro as informações pra depois publicar alguma coisa.
    pra começar o endereço público do Incra não tem nada haver com o endereço público do Rio + 20.

    NOOOOOOBBB

  8. Revolt, se você não gosta do cara pq visita o blog dele então?
    Cheiro de Inveja no ar.

  9. Boa pergunta e a resposta também foi excelente..

  10. Querido Revolt, a OYS está com excelentes cursos focados em segurança da informação e que lhe darão uma excelente base sobre o assunto. Pesquise mais à respeito e acesse o site deles.

    vistualhost é uma máquina virtual instalada na bunda de alguém, só pode né..

  11. Muito bom a publicação!!! sou um dos admin do site do MDA.
    estamos atentos, mas sabemos da impossibilidade se o ataque realmente surgir.

    OYS muito bons cursos

  12. Quem disse que eu não gosto do site. Coruja de Ti é um bom site, mas as vezes peca na Teoria da Conspiração….
    Estou me baseando em fatos.

    IP INCRA diferente de IP RIO+20

    Simples assim…

    Se bem que blog, não precisa ter informação verdadeira né….. compra quem quer…

  13. Parado de novo.

  14. Meu nome é Emerson Rocha Luiz, sou um brasileiros voluntários que é membro do Joomla Bug Squad, e, não só em respeito aos usuários deste CMS como aos visitantes do seu site, solicito educadamente que arrume o post e o corrija do ponto de vista técnico.

    A falha que está falando, não é 0-day: para se-lo, teria que ter sido exposta no mesmo dia de uma correção de segurança ou mesmo antes disso [1]. A falha que você cita é referente ao #20120303 [1], disponibilizada em um dos canais oficiais que a o Joomla PLT disponibiliza para citar questões relativas a segurança.

    Apenas para deixar claro, tanto a respeito do site como da falha:
    – O que você como 0-day é, na verdade “90-day+”. É uma falha velha, conhecida abertamente na internet
    – O site (rio20.gov.br ?) não é Joomla!, mas sim Plone, logo NÃO é vunerável ao #20120303, aka o seu “90-day+”
    – O site do Incra (incra.gov.br), segundo o generator, é versão Joomla! 1.7.x, está entre 135 a 335 dias desatualizado, logo é vunerável ao #20120303, aka o seu “90-day+” caso o administrador do site não tenha desligado registro automático de usuário. Um botão via interface administrativa.

    Quer culpar algo? Culpe administradores preguiçosos. Eles merecem. Agora, vir a publico, e falar uma inverdade, e mudar o foco para o software, que é livre, goza de uma base de código de mais de uma década, você não está atacando a entidade, mas pessoas como eu que não ganham nada para manter a web mais segura. Posso entender que houve falha na comunicação e o local aonde obteve o “script pronto” para invasão explicou ela de modo errado, e entendo que o que tenha falado é até aonde conhece. Agora, se mesmo sabendo a verdade, insistir em manter essa versão, vou compreender sua posição como antiética e sentir vergonha de se considerar um profissional de segurança. Defendo e concordo que tenha o direito de falar esse tipo de coisa, mas você deve ser razoável.

    att.
    Emerson Rocha Luiz
    @fititnt

    [1] http://en.wikipedia.org/wiki/Zero-day_attack
    [2] http://developer.joomla.org/security/news/395-20120303-core-privilege-escalation

    PS1: Não trabalho para nenhum dos sites mencionados, direta ou indiretamente;
    PS2: Na onda massiva de ataques de 2011 à sites do governo, nenhum site Joomla! foi porta de entrada, e o mais próximo disso foi um servidor do exércio invadido por Kernel desatualizada e um site politico que usava versão de Joomla 1.0, vários anos desatualizada.
    PS3: Vou postar esse mesmo comentário em nos demais posts que faz referência a esse ataque “0-day”

  15. Emerson,

    muito obrigado pelos esclarecimentos, mas aqui vão alguns meus.

    O post foi feito baseando-me em um e-mail. Não fui afundo e não é do meu feitio – sei que estou errado, mas juro, eu não tenho tempo para isso. Conserto os posts e as infos contidas neles de acordo com o que recebo, como estou fazendo agora.

    O fato é que o Joomla é um dos CMSs mais vulneráveis do mercado quando o assunto é segurança. Administradores e WebDesigners possuem a mesma sensação, isso porque demoram um tempo muito maior para configurar um mínimo de segurança para ele do que para o WordPress. Isso não podemos negar.

    Em momento nenhum eu coloquei a culpa no software livre e acho que você deveria ler os outros posts antes de falar isso. Outro ponto importante é que há sim um 0-day sendo explorado para Joomla e ele foi utilizado em alguns dos ataques. Infelizmente eu não tenho mais detalhes quanto a ele porque não me foi passado quais informações.

    Eu não culpo só administradores preguiçosos, eu também culpa o mal desenvolvimento em cima da plataforma, o mesmo é valido para wordpress ou qualquer outra solução que venham possuir centenas de vulnerabilidades.

    Publiquei a informação dias antes do ataque, passei mais detalhes aos responsáveis que administravam os portais afetados, então não venha me julgar se sou ou não sou ético, até porque não lhe devo qualquer satisfação.

    P.S.1: Este blog não é democrático, quer dizer, todos os comentários são analisados antes de serem publicados e quem o faz pode simplesmente jogar o que não gostar na lixeira, então não diga que fará um control+c + control+V neste tipo de post, porque uma das pessoas que analisa os comentários fará o delete do mesmo com dois cliques de mouse.
    P.S.2.: Darei a seguinte oportunidade à você como membro do time de desenvolvimento do Joomla, escrever um artigo que explique o ocorrido, as vulnerabilidades exploradas e um ponto de vista, defendendo ou não, o porque de tantos problemas de segurança encontrados no Joomla. Eu nunca li algo à respeito em site ou fórum algum.
    P.S.3.: Eu não trabalho com segurança, no máximo um entusiasta e sabe porquê ? não tenho tempo e saco para ficar tendo que provar se sei mais ou menos sobre um determinado assunto, deixo isso para quem gosta e precisa. Então não venha me ameaçar. Seja mais diplomático, como o que fiz agora publicando o seu comentário. Não se esqueça, eu poderia muito bem ter simplesmente apagado o seu comentário, não ter perdido 5 minutos escrevendo esta réplica e estar andando no pq. do Ibirapuera.

  16. Bom..
    Emerson, acho que rolou um equivoco da sua parte, a bug que creio que estejam explorando seja o http://developer.joomla.org/security/news/470-20120601-core-privilege-escalation.html , que como você pode ver, teve correção somente no dia 18 deste mês.

    Realmente pode não ser um 0day, mas não encontrei nenhuma informação mais detalhada deste bug pela equipe do joomla,( ao menos eu não encontrei, pode ter sido vacilo meu na hora de usar o google.) Mas temos que considerar que a falha ficou sem correção bom um BOM tempo concorda? (:

    O site do Rio+20 eu realmente não olhei, mas os outros quase 15 sites ou mais invadidos, são todos joomla, os robots.txt não me deixam mentir.

    Não estou escrevendo pra defender o Gustavo e muito menos para atacar, você e/ou ferramenta, mesmo porque, sou um grande fã do opensource, somente não concordei com alguns pontos escritos.

  17. Mesmo não sendo um “site democrático” – como o próprio Coruja fala, ele publica as mensagens e realiza as réplicas, onde quem realmente ganha são os leitores do Blog.

    Valeu Coruja!!!!!

  18. Tento disponibilizar o máximo de conhecimento possível para galera. Esse é o objetivo do blog. Conhecimento é algo que deve ser adquirido e compartilhado, e se possível, por um custo zero. Peco, erro, faço merda e assumo, hora bolas, eu sou humano – mas isso tudo me dá uma coisa muito importante, conhecimento.

  19. Crash, mais uma vez eu agradeço pela sua grande contribuição, sempre ponderada e me corrigindo. Gosto disso e sei muito bem que cometo erros.

    O pessoal levantou algumas das informações passadas pelo post e viu que há algo de podre no reino do Joomla. Vejam, ele é uma boa ferramenta opensource, mas não estou errado em dizer que ele parece um queijo suíço quando o assunto é segurança.

    Veremos as cenas dos próximos capítulos..

  20. A falha de Joomla realmente não é um 0day e posso falar abertamente sobre essa exploração.
    O criador dessa falha fui eu, e por diversas vezes já efetuei treinamentos para exploração dessa falha e posso dizer que por um acaso, descobri essa falha quando o Joomla estava na versão 1.6, sendo assim só foi arrumada na versão 2.5.3 depois de enviar dezenas de e-mails para a equipe de desenvolvimento Joomla.
    Grito aos quatro cantos que o Joomla é uma excelente ferramenta, mas precisa ser bem ajustada para que funcione bem, assim como é o site da eSecurity hoje.
    Não é a preguiça de administradores, afinal, a falha que rola hoje, explora o Joomla 1.6 a 2.5.2, mesmo que nessa época os admins fizessem as atualizações, a falha ainda persiste.

    Amo Joomla, mas é uma vergonha ignorarem meus e-mails durante tanto tempo.
    Por isso eu (através do ASHACK) resolvi distribuir essa falha.. Agora negada… Se virem…
    Alan Sanches

  21. Ah! e tem mais..
    Tenho falhas do joomla 2.5.5 em mãos.. Se a equipe Joomla desta vez não ler meus e-mails, então, lançarei novos cursos para apresenta-las ao público.

  22. @Crash O #20120601 que citou não permite invasão. Você está confundindo uma falha que foi uma das mais graves dos ultimos dois anos, a #20120303

    Só para deixar claro sobre a #20120601, que vocês provavelmente não vão encontrar documentado na web como explorar porque é até irrelevante, além do Nils Rückmann que reportou primeiro ao JBS, um colega brasileiro, o @_danielcorrea também reportou semanas atrás. Mais pessoas do JBS sabiam dela, e foi de comum acordo que daqueles que sabiam, não havia interesse ei deixar publico.

    Essa “falha”, ainda que o nome pareça ponposo, permitia que um usuário administrador elevasse o próprio nível de acesso para superadministrador usando o comando batch da tela de listagem de usuários na administração. Mas, cá entre nós, isso é realmente grave se você considerar que um administrador pode instalar extensões e, com isso, com alguma malícia alterar a própria ACL ou resetar a senha de superadministrador. Por questões históricas, no CMS Joomla um o que diferencia um administrador de um superadministrador é a habilidade de não ser removido pela interface administrativa e poder alterar algumas configurações adicionais do sistema.

    Ainda que o CMS Joomla lance atualizações de segurança a cada uns 2 ou três meses, a maioria absoluta das falhas são XSS, uma e outra coisa que revela qual o path aonde o CMS foi instalado ou algo como com título “SQL Injection”, porém em vez de conseguir efetivamente exececutar uma querie que retorne dados ou que escreva dados, vá no máximo gerar um erro que exibe qual é o prefixo da tabela.

    Diferente de outros CMSs, o Joomla roda em cima do JPlatform. TODAS as queries são filtradas por padrão, e é preciso explicitar quando quer permitir uma entrada de dados diferente. E fica tão “fora do padrão” que até usos legítimos é comum o desenvolvedor penar até encontrar como fazer. E mesmo que o dev faça uma gambiarra enorme, ele raramente vai ser aceito no repositório oficial, cujos editores verificam se não há algum erro gritante.

    E, quanto as falhas que do Joomla, tem uma grande diferença entre o CMS Joomla, e as extensões para ele. Se levar em consideração que agora tem mais de 9 mil do repositório oficial, fora as que nem estão no repositório, é razoável que volta e meia alguma delas tenha alguma falha, mas dai não estamos falando de Joomla.

  23. Alan Sanches disse:

    “O criador dessa falha fui eu, e por diversas vezes já efetuei treinamentos para exploração dessa falha e posso dizer que por um acaso…”

    *Criador*? Como assim, criador? Você enviou código que foi aceito e plantou “a bomba”? Não. Eu sei a linha exata do erro do #20120303 e no git blame não aparece teu nome.

    “…de enviar dezenas de e-mails para a equipe de desenvolvimento Joomla.”

    Tu cita “equipe de desenvolvimento” e não termos como “core” ou bug squad? Está te entregando. A falha do #20120303, por mais que depois que sabe a lógica seja relativamente fácil de ser explorada DEPOIS de conhecida, descobrir essa lógica exige uma experiência visceral da forma como a arquitetura do CMS funciona. Não existe metaexploitezinho pra ajudar a testar essa falha, nem tool genérico.

    Não te conheço, mas desde já sei que o que está falando não é verdade, e só está querendo cantar de galo e aparecer. E explico.

    Seguinte, considerando a quantidade de pessoas que tem no Joomla Bug Squad, e, a gravidade do #20120303, nem mesmo em um universo paralelo um email desse tipo seria ignorado. Todo e qualquer sinal de algo que possa ser uma falha de segurança, não só o pessoal do Bug Squad, mas até os moderadores do fórum oficial são orientados a levar muito a sério e ajudar a investigar e se não for um comportamento esperado, repassar direto para pessoas bem específicas. Coisa que nem aparece na lista de email publica. Pessoas REALMENTE estão preparadas pra fazer até ligações internacionais e parar tudo pra alguma situação em que um release tenha que ser feito imediatamente.

    Diferente do que acontece com wordpress, toda falha de segurança consistente que ocorreu nos ultimos anos em geral sempre foi reportada ao JBS e, se o risco de ser divulgada ao grande publico era pequeno, poderia não haver uma correção no mesmo dia. Agora, em situações em que falhas de segurança, mesmo as mais idiotas, apareceram em publico sem chance de resolver um patch, não me lembro de situações em que um patch de segurança não saio em menos de um dia. Em relação a outros softwares, são poucas equipes que chegam a liberar path em menos de três horas, como já aconteceu e me lembro.

    E, desculpa, cara, mas se quer ser alguém, seja por teu esforço. O que tu tá querendo chegar aqui se dizer responsável pelo foi divulgado publicamente por Jeff Channell, que, aliás, é um cara que certamente seria mais respeitoso com esse assunto. Tu pode até conseguir cantar de galo com quem não conhece de Joomla, mas na frente de macacos velhos como eu o buraco é mais embaixo.

  24. “O criador dessa falha fui eu” – Alan

    Realmente, isso é uma verdade… e achei muito legal ver a falha acontecer e aprender em menos de 10 minutos!

    “lançarei novos cursos para apresenta-las ao público.” Oba… é só falar quando 🙂

  25. Emerson, vejo que o pessoal adorará discutir com vc durante horas sobre o alto nível de conhecimento para desenvolver algo para Joomla. Menos rapaz.. Saiba que tem muita gente boa por aí..

  26. Emerson, ou macaco velho, como vc se refere..
    Neste site existem pessoas que a anos já treinaram comigo referente esta falha em Joomla, então meu querido, não são nomes bonitos que irão enganar o povo aqui.
    A quem me conhece sabe que só apresento meu CV para quem paga minhas contas e por sinal, ao menos sei quem é você.
    O que acontece é que pessoas como vc, baba ovo de gringo, não consegue entender que aqui existem pessoas que podem sim explorar uma falha, e esta, ridícula por sinal.
    Não vou prolongar muito, afinal, pelo que vc expoe, seu conhecimento é muito superior ao meu, então amigo macaco velho, volte ao seu Squad, Sdrubles ou sei lá como vc chama seu trabalho e faça do joomla um script melhor e mais seguro…

  27. Emerson,

    Entendo seu ponto de vista, só acho então que a equipe do joomla então deveria melhorar o processo de comunicação de report de falhas e afins com os usuários e pesquisadores, pois pelo que entendi do seu post, muitas ações não são claras, ou seja, trabalhando justamente como empresas de softwares proprietários.

    E eu acho que não confundi, justamente pelo citado acima, oque está escrito é sobre escalação de privilégio e nada mais, como você possui seus acessos ninjas ao projeto você sabe disso, mas quem está de fora não. Por mais que seja irrelevante, sempre tem um nerd maluco que consegue fazer algo interessante.

    E em relação ao Alan ter descoberto a falha, nos já pedimos o link do Advisory em uma lista de discussão, estamos aguardando a resposta. (:

  28. um documento apontando as vulnerabilidades do site do incra foi apresentado para o administrador do site com as devidas recomedações para mitigar as vulnerabilidades, se nenhuma ação foi tomada não se trata de um problema de segurança, mas sim de administração e da falta de conhecimento e do desinteresse do administrador.

  29. Anonimo, eu enviei essa informações no dia em que recebi a noticia que estavam planejando o ataque, sabia que não iam entender mas mandei….bom…pelo que vemos ele foi invadido e não corrigiram.

    Em questão ao que falaram lá em cima que RIO+20 não estava no mesmo server do INCRA é “verdade” …..so q o RIO+20 estava em um servidor com um site com falha no joomla e depois que o Gustavo publicou aqui que foi alterado…..

  30. Tem gente que se acha, mas uma coisa eu digo e pode ser vista nos nosso eventos!

    Todos nos juntos conseguimos fazer coisas sensacionais! Agora se você se acha o cara, não vai conseguir nada sem humildade.

    0 day ou o que seja é uma falha e nos estamos aqui para encontrar as falhas!

    Agora Emerson segura tua bola ai…. Como o Gustavo disse você não conhece o potencial da galera!

    A falha é tão grosseira que ate minha sobrinha de 6 anos conseguiu fazer! Ja que você é bom trabalha ai e arruma!

  31. Ae L3g1on

    o lance não é falta de humildade…

    a parada é que esse Alan se acha “o cara” , so que nada prova pra ninguem…..

    sai conversando besteiras ai….

    Humilde são os que fazem mostram e compartilham do seu conhecimento e não os que dizem que fazem e acontecem e não provam nada…pra mim isso é pura propaganda….

  32. Pessoal beleza? Eu andei lendo e verifiquei que vcs entendem tanto de joomla que discutem o assunto, bom com tantas informações seria possível alguém de vcs me darem um help?
    Eu uso joomla 2.5 agora e meu site foi invadido por um hacker diretamente no banco de dados e depois disso meu site ficou toatlmente bagunçado e desconfigurado desinstalei o site e começei do zero de novo depois de refazer mais de 80 páginas meu site indexou novamente no google depois sumiu, não fui punido pelo google, ele simplestemente nã indexa mais a url principal a url é http://www.rodoviariatiete.net então não sei mais o que fazer para resolver isso o suporte da hospedagem não resolve o problema em nada disse que foi por falta de sefgurança minha e tal, mas um site que tinh várias visitas por dia hoj não passa de 100, eu sei que aqui não é o local mais adequado para essa informaçao, mas devido a procurar em diversos lugares aqui foi onde eu li muita coisa sobre segurança e tal.
    Vlw e abraço!

Deixe uma resposta

Fechar Menu