Tweet
Quanto tempo não nos vemos :')
Sério, saudades de todos!
Pra lembrar um pouco os velhos tempos (a "Era de Prata" do GH, inesquecíveis anos de 2011-2012), vou mostrar hoje um ataque no qual levamos embora 2 websites de uma só vez.
O diferencial é que enfrentaremos problemas... teremos alguns problemas. Mas solucionaremos a todos e sairemos vitoriosos!
Vamos ver?
Vamos levar em conta que você já explorou uma vulnerabilidade em algum website (não importa qual) e já está com shell enviada (ensinar como faz isso não é o propósito deste tutorial, mas há outros. Utilize a busca!).
Envie o arquivo symlinkbypass.php que segue Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar....
Acesse esse arquivo...
...e clique em "Domains & Script". Esta opção obtém os usuários e procura, em suas pastas, via symlink bypass, arquivos de configuração para as CMS mais famosas (Wordpress e Joomla).
Note que achamos um único website usando uma dessas CMS (explore a ferramenta. Pelo Bypass Read, por exemplo, você consegue ler arquivos, desde que saiba sua localização exata. Excelente para CMSs que você conhece, mas que a ferramenta não reconhece, como Drupal etc).
Clique em Wordpress...
...e perceba que você terá o arquivo de configuração do Wordpress deste site. Mas não temos privilégio de escrita, só de leitura. Assim, vamos acessar o banco de dados para ver se há algo interessante (sempre há!).
Envie, para o servidor, uma cópia do Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar.... É algo como um phpMyAdmin, mas tudo em um único arquivo (como uma webshell). Claro que poderíamos utilizar o próprio gerenciador MySQL da webshell, mas o Adminer é muito mais fácil e prático (e tem menos bugs).
Acesse o Adminer enviado (note que eu não fecho nada, apenas crio abas. Isso é essencial) e preencha-o com as informações do arquivo de configuração obtido, conforme indiquei na imagem abaixo:
Assim, temos acesso ao banco de dados do website.
Vamos abrir o website para ver por onde podemos inserir códigos. Precisamos achar uma área do website onde apareça alguma informação buscada no banco de dados.
Bons exemplos são: o título ou a descrição da página, títulos e textos de postagens e páginas etc.
Este foi o website que encontramos:
Não vou mentir... achei é um pouco estranho para um blog. Mas, como Wordpress permite tudo, tudo bem. Mas não encontrei nada que se assemelhe a páginas ou blogs.
Mas havia uma esperança... no título
Ótimo, vamos alterá-lo e inserir códigos Javascript, explorando XSS Stored/Permanent!
O título do blog fica na tabela algumacoisa_options (na maioria das vezes (mas não nessa), wp_options, porém o prefixo das tabelas é personalizável).
Selecione os dados.
Edite a linha onde option_name = blogname. Note que há vários outros interessantes, como blogdescription.
Qualquer um que saiba o básico do HTML sabe que o título da página é inserido dentro das tags <TITLE>. Este é o código-fonte da página do site:
Assim, precisamos fechar a tag <TITLE> antes de inserir nossos códigos. Não obstante, precisamos também inserir a tag <NOSCRIPT> ao final. Isso indica que, a partir dali, tudo o que estiver deverá ser executado apenas se o navegador estiver com o Javascript desativado, o que é bem raro. Isso fará com que o conteúdo original do site "suma".
Serelepes e saltitantes, vamos ver o estrago que fizemos no site.
Isso deveria estar hackeado...
Problema! Por que o site não foi modificado e o título continua lá, intocado?
Se voltarmos à tabela *_options, podemos ver:
Note que o blog está no subdiretório "blog", e não na index. Inclusive, se visitarmos este diretório, veremos que está modificado:
Mas "ownar subdir" não nos dá a flag "H" (home) no Zone-H. Pleiteamos a página inicial do website!
Como a base de dados não nos ajudou muito (e dificilmente um INTO OUTFILE teria privilégio para podermos escrever uma webshell no diretório do site), vamos ver o que existe no painel administrativo. Para isso, acesse a tabela *_users.
Temos apenas um usuário na tabela, e é ele quem vamos acessar. Para alterar a senha, devemos editar essa linha e inserí-la na coluna user_pass. Claro que MD5 não é a criptografia do WordPress. Mas, não se preocupe. Isso funciona.
Vou usar o Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... para criptografar a senha "huebr" para MD5, afinal, a zoeira não tem fim (ou tem?).
Certo? Vamos colar a hash MD5 na tabela de usuários.
Agora, vamos acessar com o usuário da tabela (você pode alterar, se quiser) e a senha que inserimos. O painel administrativo do WordPress sempre fica no diretório "wp-admin".
Note que o painel administrativo também está alterado...
Vamos voltar para a tabela *_options e retirar nossos códigos do título. Insira qualquer coisa (até mesmo "qualquer coisa"), mas lembre-se: nenhuma tag HTML!
Volte ao painel e pressione F5. Note que pudemos abrir o painel de controle.
Acesse Aparência > Editor para abrir o editor de temas do Wordpress.
Edite a página 404.php, por ser uma página que outros usuários terão menor possibilidade de acessar (em relação às demais).
Insira todo o código da sua webshell preferida. Recomendo veemente a Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... por não criar parâmetros adicionais na URL e funcionar apenas com requests AJAX de método POST, o que não atrapalha a URL e promove uma navegação sem refresh (como o Facebook).
Acesse qualquer página do site. Mas lembre-se: digite um nome de página que você sabe que não existe. Queremos provocar um erro 404 (arquivo não encontrado), pois nossa webshell está justamente na página deste erro.
Ué?..
Problema! Por que foi exibida uma página genérica?
Simples. O website não faz uso de URL amigável (RewriteModule). Dessa forma, precisamos seguir um dos links da página e modificá-lo. Acesse o blog normalmente e abra um de seus posts.
Altere o parâmetro "p" da URL para um número que você sabe que não possui um post relacionado (utilizei vários 5. Dificilmente um blog tem essa quantidade de postagens, provocando o erro 404). Note que nossa webshell abriu.
Basta-nos alterar a index.
E ver os estragos que fizemos.
Mas... essa página deveria ser preta com letras brancas... e por que os links não funcionam?
Problema! Por que os estilos e links não foram aplicados?
Uma rápida olhada no código-fonte da página que editamos nos mostra o porquê:
Note que as aspas foram escapadas, isto é, adicionou-se uma barra invertida antes de cada uma delas. O HTML não entendeu isso muito bem.
Isto é um recurso talvez do Wordpress ou mesmo do servidor (Magic quotes), para proteger contra SQL Injection. Tudo o que precisamos fazer é remover todas as aspas. Nâo se preocupe, a sintaxe XML continuará funcionando.
Resultado.
Não nos esqueçamos de invadir o website que nos abriu as portas para este outro website. Afinal, ele merece, não é mesmo?
E, claro...
E é isso!
Dicas:
Espero que possam me ver mais vezes em outros tutoriais!
Sério, saudades de todos!
Pra lembrar um pouco os velhos tempos (a "Era de Prata" do GH, inesquecíveis anos de 2011-2012), vou mostrar hoje um ataque no qual levamos embora 2 websites de uma só vez.
O diferencial é que enfrentaremos problemas... teremos alguns problemas. Mas solucionaremos a todos e sairemos vitoriosos!
Vamos ver?
Vamos levar em conta que você já explorou uma vulnerabilidade em algum website (não importa qual) e já está com shell enviada (ensinar como faz isso não é o propósito deste tutorial, mas há outros. Utilize a busca!).
Envie o arquivo symlinkbypass.php que segue Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar....
Acesse esse arquivo...
...e clique em "Domains & Script". Esta opção obtém os usuários e procura, em suas pastas, via symlink bypass, arquivos de configuração para as CMS mais famosas (Wordpress e Joomla).
Note que achamos um único website usando uma dessas CMS (explore a ferramenta. Pelo Bypass Read, por exemplo, você consegue ler arquivos, desde que saiba sua localização exata. Excelente para CMSs que você conhece, mas que a ferramenta não reconhece, como Drupal etc).
Clique em Wordpress...
...e perceba que você terá o arquivo de configuração do Wordpress deste site. Mas não temos privilégio de escrita, só de leitura. Assim, vamos acessar o banco de dados para ver se há algo interessante (sempre há!).
Envie, para o servidor, uma cópia do Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar.... É algo como um phpMyAdmin, mas tudo em um único arquivo (como uma webshell). Claro que poderíamos utilizar o próprio gerenciador MySQL da webshell, mas o Adminer é muito mais fácil e prático (e tem menos bugs).
Acesse o Adminer enviado (note que eu não fecho nada, apenas crio abas. Isso é essencial) e preencha-o com as informações do arquivo de configuração obtido, conforme indiquei na imagem abaixo:
Assim, temos acesso ao banco de dados do website.
Nota: Você tem grandes chances de conseguir acessar o phpMyAdmin do próprio website, acessando /phpmyadmin no domínio. Mas, sinceramente, prefiro o Adminer (até mesmo em meus servidores) pela sua praticidade.
Vamos abrir o website para ver por onde podemos inserir códigos. Precisamos achar uma área do website onde apareça alguma informação buscada no banco de dados.
Bons exemplos são: o título ou a descrição da página, títulos e textos de postagens e páginas etc.
Este foi o website que encontramos:
Não vou mentir... achei é um pouco estranho para um blog. Mas, como Wordpress permite tudo, tudo bem. Mas não encontrei nada que se assemelhe a páginas ou blogs.
Mas havia uma esperança... no título
Ótimo, vamos alterá-lo e inserir códigos Javascript, explorando XSS Stored/Permanent!
O título do blog fica na tabela algumacoisa_options (na maioria das vezes (mas não nessa), wp_options, porém o prefixo das tabelas é personalizável).
Selecione os dados.
Edite a linha onde option_name = blogname. Note que há vários outros interessantes, como blogdescription.
Qualquer um que saiba o básico do HTML sabe que o título da página é inserido dentro das tags <TITLE>. Este é o código-fonte da página do site:
Assim, precisamos fechar a tag <TITLE> antes de inserir nossos códigos. Não obstante, precisamos também inserir a tag <NOSCRIPT> ao final. Isso indica que, a partir dali, tudo o que estiver deverá ser executado apenas se o navegador estiver com o Javascript desativado, o que é bem raro. Isso fará com que o conteúdo original do site "suma".
Serelepes e saltitantes, vamos ver o estrago que fizemos no site.
Isso deveria estar hackeado...
Problema! Por que o site não foi modificado e o título continua lá, intocado?
Se voltarmos à tabela *_options, podemos ver:
Note que o blog está no subdiretório "blog", e não na index. Inclusive, se visitarmos este diretório, veremos que está modificado:
Mas "ownar subdir" não nos dá a flag "H" (home) no Zone-H. Pleiteamos a página inicial do website!
Como a base de dados não nos ajudou muito (e dificilmente um INTO OUTFILE teria privilégio para podermos escrever uma webshell no diretório do site), vamos ver o que existe no painel administrativo. Para isso, acesse a tabela *_users.
Temos apenas um usuário na tabela, e é ele quem vamos acessar. Para alterar a senha, devemos editar essa linha e inserí-la na coluna user_pass. Claro que MD5 não é a criptografia do WordPress. Mas, não se preocupe. Isso funciona.
Vou usar o Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... para criptografar a senha "huebr" para MD5, afinal, a zoeira não tem fim (ou tem?).
Certo? Vamos colar a hash MD5 na tabela de usuários.
Agora, vamos acessar com o usuário da tabela (você pode alterar, se quiser) e a senha que inserimos. O painel administrativo do WordPress sempre fica no diretório "wp-admin".
Note que o painel administrativo também está alterado...
Vamos voltar para a tabela *_options e retirar nossos códigos do título. Insira qualquer coisa (até mesmo "qualquer coisa"), mas lembre-se: nenhuma tag HTML!
Volte ao painel e pressione F5. Note que pudemos abrir o painel de controle.
Acesse Aparência > Editor para abrir o editor de temas do Wordpress.
Edite a página 404.php, por ser uma página que outros usuários terão menor possibilidade de acessar (em relação às demais).
Insira todo o código da sua webshell preferida. Recomendo veemente a Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar... por não criar parâmetros adicionais na URL e funcionar apenas com requests AJAX de método POST, o que não atrapalha a URL e promove uma navegação sem refresh (como o Facebook).
Acesse qualquer página do site. Mas lembre-se: digite um nome de página que você sabe que não existe. Queremos provocar um erro 404 (arquivo não encontrado), pois nossa webshell está justamente na página deste erro.
Ué?..
Problema! Por que foi exibida uma página genérica?
Simples. O website não faz uso de URL amigável (RewriteModule). Dessa forma, precisamos seguir um dos links da página e modificá-lo. Acesse o blog normalmente e abra um de seus posts.
Altere o parâmetro "p" da URL para um número que você sabe que não possui um post relacionado (utilizei vários 5. Dificilmente um blog tem essa quantidade de postagens, provocando o erro 404). Note que nossa webshell abriu.
Basta-nos alterar a index.
E ver os estragos que fizemos.
Mas... essa página deveria ser preta com letras brancas... e por que os links não funcionam?
Problema! Por que os estilos e links não foram aplicados?
Uma rápida olhada no código-fonte da página que editamos nos mostra o porquê:
Note que as aspas foram escapadas, isto é, adicionou-se uma barra invertida antes de cada uma delas. O HTML não entendeu isso muito bem.
Isto é um recurso talvez do Wordpress ou mesmo do servidor (Magic quotes), para proteger contra SQL Injection. Tudo o que precisamos fazer é remover todas as aspas. Nâo se preocupe, a sintaxe XML continuará funcionando.
Resultado.
Não nos esqueçamos de invadir o website que nos abriu as portas para este outro website. Afinal, ele merece, não é mesmo?
E, claro...
E é isso!
Dicas:
- Não se preocupe. É absolutamente normal encontrar servidores com mais instalações de Wordpress e Joomla. Este teve apenas 1, mas foi azar.
- A ferramenta symlinkbypass.php é obsoleta. Sua função "Mass Joomla" altera o login e senha de todos os sites Joomla do servidor, mas a função "Mass Wordpress" não funciona bem. Se conhecerem uma ferramenta melhor ou mais atualizada, compartilhem ;-)
- Se o site que você quiser invadir for Wordpress/Joomla, poderá descobrir outros websites vulneráveis no mesmo servidor (obtendo o IP do servidor pelo "ping" ou "resolveip" do terminal/MS-DOS) e utilizando a dork "ip:" no Bing (o Google não suporta). Exemplo: ip:127.0.0.1. Encontrando um vulnerável, apenas execute os processos deste tutorial.
Espero que possam me ver mais vezes em outros tutoriais!
Comment