Artigos

Cuidados com o WordPress #1 – O dia que hackeei um blog conhecido

Não sei o porquê, mas acabei me tornando referência para tentar resolver pepinos no WordPress (com “clientes” como a aniversariante do dia Lucia Freitas, Nospheratt, Bruno Dulcetti, Mulher Remédio, Júlio Câmara, etc…). “O WordPress deu pepino, chama o Jonny Ken”

Então resolvi criar um tópico com temas não muito comentados em metablogs, principalmente na área de segurança e manutenção do WordPress. E para começar…

O dia que eu hackeeu um blog conhecido…

(antes de mais nada, o texto foi autorizado pelo Leo Baiano, e o bug do plugin foi prontamente arrumado)

Todo mundo tem a idéia de que programas de código aberto são mais seguros. Isso só é verdade quanto existem milhares de pessoas trabalhando horas e horas em cima do código! Quando uma pessoa faz algum plugin sozinho e libera o código pela internet sem muitos testes, ele é algo EXTREMAMENTE inseguro.

O maior problema é que quem escreve um programa pode fuçar milhares de vezes o código-fonte e não encontrar um bugzinho (por impericia ou por imprudência). Você já deve ter escrito um texto, verificado milhares de vezes e mais tarde uma 2ª pessoa do nada acha um erro gramatical grotesco.

Quando você faz um plugin para seu próprio uso, as chances de um bug ser descoberto é bem baixo, já que hackear algo desconhecido envolve uma boa dose de conhecimento e de sorte. Porém quando você abre o código para todos, o ataque é feito de forma certeira! Foi o que aconteceu recentemente com um blogueiro bastante popular na internet – o Leo Baiano.

Outro dia ele lançou um plugin simplezinho para exibir uma mensagem do tipo “Jonny, você já assinou o feed do Blog?” usando o nome que você enviou em algum comentário. Na maior boa vontade, ele liberou o plugin para outras pessoas poderem utilizar.

Curioso como sou, dei uma olhada no script e pimba!!! Um Bug que permitia rapidamente escrever coisas no layout do site. Avisei o Leo, e para mostrar o perigo, deixei uma mensagem no blog dele, trocando a mensagem original por um merchan do Infoblog.

O maior erro nesse caso não foi de programação, e sim de liberar o código fonte de um plugin sem conhecimentos básicos de segurança.

O Bug

Para programar não basta saber simplesmente a lógica da linguagem. Você tem que conhecer também os níveis de segurança que seu programa fornece a um usuário. Por isso a minha dica é: Se você é expert em POG (programação orientada à gambiarra), JAMAIS divulgue seu código-fonte.

No caso do plugin do Leo existia o arquivo chamado gravar.php que simplesmente não era protegido pela senha do WordPress. Como o próprio nome diz, ele pega as frases fornecidos pelo administrador (“bom dia visitante, você conhece o blog XYZ”, “Você já assinou nosso Feed” ou algo do tipo) e grava em um arquivo texto.

Olhando o código:

Como o gravar.php estava desprotegido e a linha 11 não possuia nenhuma verificação de autenticidade, aproveitei para simplesmente mandar um “form” com o campo “mensagem”. Com isso gravei a mensagem do Infoblog que apareceu na página de abertura.

Vivendo e aprendendo
Além de resolver o problema do Bug, o Leo Baiano adicionou uma funcionalidade nova em seu plugin, que é colocar a foto e o nome usando a API do BlogBlogs.

Segundo o próprio Leo, “o plugin não esta disponível para download porque ainda estou mexendo no código para evitar novos bugs mas quem quiser testar é só acessar o meu blog e ver como ficou.”.

Ótima atitude…

Conclusão:
Se você vai utilizar plugins, baixe-os somente do site oficial do WordPress. Verifique se ele não tem muitas reclamações e se todos os bugs já foram corrigidos.

Se você vai desenvolver plugins, verifique várias vezes seu código e peça para outras pessoas verificarem. E somente ai lance ele na internet.

Lançar plugins não é lugar para aventureiros. Caso não se sinta seguro, não o divulgue na internet! Colocar uma frase do tipo “Não me responsabilizo por qualquer problema que a instalação do plugin venha trazer.” pode até te isentar de responsabilidade jurídica, mas não o isentará das de riscos a sua imagem.

17 comentários sobre “Cuidados com o WordPress #1 – O dia que hackeei um blog conhecido

  • O que podemos dizer no final das contas é: você é um “hacker” bonzinho, certo? rs
    🙂

    Vendo por esse lado, ele foi quem se deu bem, de ser alertado que o bug existia. Engraçado ver que quando o kmax fez isso usando de mais ironia foi retaliado em plena campus party, mas é parte da brincadeira né? 🙂

    Fala Rafael…

    O problema do kmax, tanto no caso do Campus Party quanto no orkut é que ele não divulgou o bug para os responsáveis. Eu procurei o Leo Baiano e expliquei o ocorrido…

    Mas eu não deveria ter mudado o site dele… deveria ter mostrado o bug para ele remotamente…

    Abraços

  • “Você já deve ter escrito um texto, verificado milhares de vezes e mais tarde uma 2ª pessoa do nada acha um erro gramatical grotesco.”

    Absolutamente. Veja você, por exemplo, que deve ter verificado esse texto várias vezes e ainda assim deixou passar o “O dia que eu hackeeu um blog conhecido…” 😀

    Mas acho que baixar somente plugins do site do WordPress não é exatamente uma garantia contra segurança, mesmo porque não é muito difícil adicionar um plugin lá, eles não testam um por um para procurarem por falhas de segurança.

    BTW, acho que o plugin do Leo poderia ser relançado. Bastava gravar o texto numa tabela do banco de dados usando as próprias funções do WP que as chances de haver outra falha nele seriam bastante baixas.

    Qua qua qua! boa Danillo… viu? Acabei de provar por A+B que a minha teoria da revisão estava certa! rs rs rs. Mas vou deixar o erro só pela graça do comentário!

    Eu falei para o Leo Baiano usar o banco de dados. Dar chmod 777 em um arquivo para gravar as frases também é extremamente perigoso

  • O Jonny é ráker!
    Eu vou banir seu ip pra não acessar a minha interweb senão vc tá um controlatdéu e deleta tudo do meu cpu!

    Agora, sem brincadeira, isso é real: teste, teste, teste. Eu sei que muitas vezes – e isso é verdade pra muito developer lá fora – não sobra tempo de testar seus trabalhos antes de divulgá-los (por pressão de um cliente, por exemplo). Então o jeito é se educar para quando estiver codando, escrever um código já pensando nas falhas básicas de segurança.

    Viva a segurança web! Viva o Windows (ok, ok, desculpe).

    Abraços

  • Boa Jonny, rárquer que é rárquer num faiz maldade com o site dos amiguinhos haha…

    Mais é isso mesmo, sempre que vou baixar um plugin de wp procuro pra ver se ele está relacionado na lista de plugins no site oficial do wp… e quais os comentarios sobre ele, além de que é mais seguro, dá pra ver se tal plugin vai cumprir com as minhas expectativas sobre ele.

    Abraço

  • Pingback: Meu Google Reader (08/04 - 21/04) | 30 & Alguns

  • esse é o cara do wordpress…

    chegou até a ser engraçado a repercussão que deu na lista quando você disse que tinha uma falha de segurança no plugin.

    é um dos grandes erros de alguém ou até mesmo empresa que não efetuam testes. eles evitam muitos constrangimentos e falhas ao usuários.

    parabéns meu nobre

    Com segurança não se brinca… mas o mais problemático é quando alguém desenvolve o furo de segurança e você usa sem saber. Eu prefiro não divulgar os plugins que eu faço para o meu blog

  • Ok, Jonny, demorei pra responder, mas finalmente vou morder a isca.

    Pelo que eu entendi do seu post, você defende que, a não ser que você seja um expert (ou pelo menos uma boa noção) em segurança e tenha um público grande pro seu programa, você não deve liberar o código fonte de um programa em uso, certo? O seu argumento é que fica mais difícil hackear um programa mal feito se você não tem o código fonte dele. Sem o código fonte voc6e não teria sido capaz de explorar um bug simples no programa de um colega seu.

    A premissa de que escondendo informações você está mais seguro é chamada de “segurança por obscuridade”, eu não acredito que ela funcione. Senão vejamos. O caso do leo baiano. Me responda: o site dele está mais seguro sem o bug ou com o bug escondido? Ele é um programador melhor agora, que você lhe explicou onde ele errou, como fazer pra evitar o erro, ou antes de divulgar o código, quando programava sem pensar em verificação de autencidade?

    Um programador POG “JAMAIS” deve divulgar seu código? Qual a alternativa? Ele deve continuar fazendo gambiarras inseguras, e escondendo seus erros, deixando-os dormentes, colocando cada vez mais funções e serviços rodando sob programas inseguros porque ninguém pode revisá-los? Ou é melhor expor seu código gambiarrento para que seus amigos, pessoas interessadas, o seu público (quantos leitores tem o blog do leo baiano, afinal?) revise, explore, critique e force o código a melhorar?

    Um programa de código aberto é mais seguro só quando é revisado por milhares de programadores? Se você só tem meia dúzia de usuários é melhor deixar seus bugs escondidos? Jonny, quantos usuários tinha a versão 0.0.1 do Linux, quando o Linus divulgou o código na internet? Um. O Linus. Quantos usuários tinha os utilitários GNU quando o Stallman começou a escreve-los e divulgar seu código na rede?

    Jonny, você é um cientista por formação. Você fez Bio junto comigo. A ciência é totalmente baseada em pares revisando seu trabalho. A ciência é uma prova viva de que divulgar os seus procedimentos leva ao progresso e melhoria destes. Escrever código é uma ciência.

    Jonny, você mesmo disse: quando se escreve sozinho, erros grotescos passam despercebidos. Se você divulga, as chances desses erros serem descobertos é maior. Mas descobrir bugs não é uma coisa boa, mesmo ao custo de serem explorados (você efetivamente explorou o código do leo baiano, afinal de contas)?

    eu acho que o leo só saiu ganhando nessa. O mundo ganhou um plugin útil, mais seguro e um programador melhor. Eu não sei se esconder o bug o teria impedido de ser explorado por alguém com “uma boa dose de habilidade e sorte” (acredito que não), mas eu sei, como um fato, que ao divulgar o código dele o bug foi rapidamente encontrado e corrigido.

    “Think about that for a second, because it’s not obvious. No one is qualified to analyze their own security designs, because the designer and the analyzer will be the same person, with the same
    limits. Someone else has to analyze the security, because it has to be secure against things the designers didn’t think of.

    Secrecy and security aren’t the same, even though it may seem that way. Only bad security relies on secrecy; good security works even if all the details of it are public.”

    Bruce Schneier (http://en.wikipedia.org/wiki/Bruce_Schneier).

    mestre Daniduc…

    uma coisa que você sempre me falou é que JAMAIS se deve fazer testes em ambiente de produção, certo? Ele lançou o plugin sem revisão, e já o colocou em ambiente de trabalho. Mas se eu não tivesse visto o código fonte NUNCA descobriria o tal bug. Seria como ficar chutando senha no escuro até acertar! Mas concordo que o fato do bug estar lá não impossibilita de alguém descobrir de outra maneira. Ou seja, não divulgar o código não o torna seguro…

    O problema do PHP é que quando você distribui o script, automaticamente já distribui o código-fonte, já que ele não é compilado! É muito mais simples achar um bug caçando falhas no código-fonte do que ficar tentando na força bruta! Não é verdade?

    Mas existem outros tipos de problemas, principalmente no windows… alguém está usando o windows, ai o SO dá pau. Ela tenta reproduzir o erro, vai diminuindo as possibilidades da causa a´te chegar no bug em si. Isso não é casual e também não foi força bruta… Nesse caso não divulgar o código-fonte não diminui as chances dos problemas não serem descobertos.

    Talvez então a lição de moral atualizada do texto seja “Se você for lançar um script, teste-o bastante fora do ambiente de produção e distribua-o para ser testado. Só depois lance sua versão definitiva”. E dai sim melhorar a cada nova sugestão…

    Certo?

  • Ok, aqui vai a resposta que nadei pro jonny:

    Ele lançou o plugin sem revisão, e já o colocou em ambiente de trabalho.

    Isso não é teste. Teste é assim: será que isso vai funcionar? Se eu mexer nisso, o que será que muda? Hm, será que esse procedimento aqui vai dar certo? Nunca fiz ele antes.

    O que ele fez foi: escrevi um script, acho que está bom, tanto quanto posso ver. Vou usar. Poderia ter revisado mais? Ou revisado at all? poderia. Mas ele não fez um teste. E mesmo que tivesse feito, o problema não seria divulgar o código fonte dele. teria sido fazer teste em ambiente de produção.

    Mas se eu não tivesse visto o código fonte NUNCA descobriria o tal bug.

    E-XA-TA-MEN-TE. Ninguém está discutindo isso. O que eu estou discutindo é se isso foi uma coisa boa ou ruim. Eu acho que ele divulgar o código e, assim, permitir você descobrir o bug foi uma coisa boa. Você, pelo jeito não. Você argumentou porque acha que é ruim. Eu respondi dizendo porque eu acho que é bom. Ninguém disputa de que o bug foi descoberto porque ele divulgou o código-fonte. Eu acho que divulgar o código fonte facilita achar bugs. Bugs achados são corrigidos. Bugs corrigidos são uma coisa boa, melhor do que bugs escondidos e não achados.

    É muito mais simples achar um bug caçando falhas no código-fonte do que ficar tentando na força bruta! Não é verdade?

    E-XA-TA-MEN-TE. Vide acima.

  • Pingback: [the dude's talk] › Melhorando seu código: o dia que discordei de um blog conhecido

  • Johnny, eu não concordo com algumas coisas que você disse. Apesar de você ter tido acesso à alguns comandos não foi possível você acessar por exemplo os arquivos do blog. POrtanto do Léo não era algo tão perigoso como parece ser…
    Abraço…

    Como não?
    Ele aceitava comandos em HTML sem maiores problemas… eu poderia ter colocado um site improprio inteiro dentro do TXT que ele usava de banco de dados!

    Ai falava para o Google e eles simplesmente suspenderiam a conta dele… isso não seria crítico?
    Abraços!

  • Isso também serve para a gente ficar esperto e não sair instalando qualquer plugin por ai deixando o Wp mais vulnerável do que já é!

  • Bem, sabe se existe algum manual para se criar seus proprios plugins. Embora meio arriscado, é muito irado criar seus proprios plugins, fiquei interessado. E com essas dicas de segurança que você colocou ai no post já ajuda muito os aventureiros.

  • Sim Johnny, mas pelas falhas que eu observei na época (não me lembro se tinham outras) o código não permitia acesso ao servidor e painéis wordpress. Sendo assim apagar o blog por exemplo era algo impossível.
    Se você colocasse um site inteiro da maneira que citou e avisasse o google, o site iria ficar restrito ao tamanho determinado e não necessariamente o google iria puní-lo, podiam entender que alguém agiu de má fé, não ele!
    Sem contar o fato de que ele obviamente perceberia a falha e desativaria o plugin sem maiores problemas…

    Mas eu concordo que foi uma falha e não seria difícil corrigí-la. Acho também que você agiu muito corretamente, parabéns pro Léo que aceitou o erro e pra você que foi honesto como fazia tempo que não via na blogosfera.

  • Olá, então eu conheço o Leo Baiano (somente pela net) sei que ele é um kara gente boa e lógico quiz ajudar, agora, fiquei facisnado pela sua “inteligência” pegar um arquivo que grava as informações e verificar se ele tem “senha”, para mim isso é o ser hacker, dicamos, você pensou da forma que quase ninguém pensa (mesmo sabendo programar), antes de conhecer o wordpress já baixei muitos cms que precisa dar chmod 777 em determinanda pasta ou arquivo (e não precisa de banco de dados), e estava dando uma olhada aqui, TEM O MESMO ERRO…
    kkkk
    essa que você fez foi ótima…
    parabéns…

  • Olá Alexandre!

    chmod 777 é mais perigoso quando se usa servidor compartilhado. Fica dificil acessar esse arquivo via web!
    O problema foi a falta de segurança no arquivo que guarda os dados! 🙂

    Abraços

  • Pingback: LeoBaiano.com » POG - Programação Orientada a Gambiarra

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.