LOIC DDoS Analysis and Detection

Caros,

Fiz uma analise basica do LOIC,  ferramenta utilizada para os ataques de DDoS/DoS em prol do Wikileaks . Postwi alguns pontos e regras do snort no blog do Spiderlabs.

http://blog.spiderlabs.com/2011/01/loic-ddos-analysis-and-detection.html

Happy Snorting!

Rodrigo Montoro (Sp0oKeR)

[Owasp-brazilian] OWASP - Encontro do Capítulo São Paulo - 17 de Janeiro 2011

Pessoal,

Quero convidar a todos para participar do primeiro encontro do capítulo São Paulo da OWASP.

O espaço foi gentilmente cedido pela Editora Abril e o objetivo é discutir as ações do capítulo.

Data: 17 de Janeiro de 2011 das 19:30 às 22:00 hrs.

Endereço: Avenida das Nações Unidas, 7221 Sala Contigo no espaço Victor Civita.

Estacionamento:  Rua Sumidouro ou Gilberto Sabino.

Aproveito para pedir a todos interessados que assinem a lista de discussão do capítulo São Paulo.

https://lists.owasp.org/mailman/listinfo/owasp-Sao_Paulo

Por favor, mande um e-mail confirmando a presença para o email: wagner.elias@owasp.org

Dados: Nome e RG

Isto é para autorizar a entrada na Editora Abril.

Grato

--
Wagner Elias - OWASP Chapter Leader São Paulo

Emerging Threats x VRT Rules - Enable versus Classtype

Playing with bot ruleset I start to analyze some differences between them in special enable x disable rules based on classtype or category . As base I'm using VRT tarball from Nov 23th and ET emerging-all from Dec 22nd .


About VRT (I only analyzed plain-text rules):


Total Plain-text Rules: 16301
Total Enable: 4597
Total Disable: 11704


Enable rules x Category/Classtype


   1370 Status: Enable Category: attempted-user
    925 Status: Enable Category: misc-activity
    646 Status: Enable Category: trojan-activity
    419 Status: Enable Category: attempted-admin
    287 Status: Enable Category: successful-recon-limited
    249 Status: Enable Category: protocol-command-decode
    114 Status: Enable Category: attempted-dos
    111 Status: Enable Category: misc-attack
    108 Status: Enable Category: rpc-portmap-decode
    106 Status: Enable Category: policy-violation
     77 Status: Enable Category: attempted-recon
     42 Status: Enable Category: shellcode-detect
     34 Status: Enable Category: bad-unknown
     32 Status: Enable Category: web-application-attack
     16 Status: Enable Category: denial-of-service
     13 Status: Enable Category: suspicious-filename-detect
     12 Status: Enable Category: suspicious-login
     10 Status: Enable Category: unsuccessful-user
      6 Status: Enable Category: web-application-activity
      5 Status: Enable Category: successful-admin
      4 Status: Enable Category: system-call-detect
      4 Status: Enable Category: string-detect
      4 Status: Enable Category: network-scan
      1 Status: Enable Category: unknown
      1 Status: Enable Category: successful-user
      1 Status: Enable Category: not-suspicious


General Category/Classtype


   3764  attempted-user
   3612  attempted-admin
   3516  protocol-command-decode
   1228  misc-activity
   1119  trojan-activity
    520  web-application-activity
    425  web-application-attack
    358  attempted-recon
    328  bad-unknown
    308  successful-recon-limited
    301  policy-violation
    266  attempted-dos
    198  misc-attack
    133  rpc-portmap-decode
     67  shellcode-detect
     35  suspicious-filename-detect
     32  denial-of-service
     19  suspicious-login
     15  not-suspicious
     12  unsuccessful-user
      9  successful-admin
      8  non-standard-protocol
      6  default-login-attempt
      5  system-call-detect
      5  network-scan
      4  unknown
      4  string-detect
      3  unusual-client-port-connection
      1  successful-user


About ET 


Total Plain-text Rules: 11517
Total Enable: 9644
Total Disable: 1873


Enable rules x Category/Classtype


   5049 Status: Enable Category: web-application-attack
   1617 Status: Enable Category: trojan-activity
    474 Status: Enable Category: attempted-user
    376 Status: Enable Category:  trojan-activity
    339 Status: Enable Category: protocol-command-decode
    295 Status: Enable Category: attempted-admin
    265 Status: Enable Category: policy-violation
    206 Status: Enable Category:  policy-violation
    176 Status: Enable Category: attempted-recon
    167 Status: Enable Category: bad-unknown
    102 Status: Enable Category: misc-attack
     81 Status: Enable Category: misc-activity
     81 Status: Enable Category: attempted-dos
     80 Status: Enable Category: rpc-portmap-decode
     54 Status: Enable Category: web-application-activity
     40 Status: Enable Category:  misc-activity
     32 Status: Enable Category:  web-application-attack
     30 Status: Enable Category: shellcode-detect
     16 Status: Enable Category: denial-of-service
     16 Status: Enable Category:  attempted-recon
     13 Status: Enable Category: not-suspicious
     12 Status: Enable Category: suspicious-filename-detect
     12 Status: Enable Category:  attempted-admin
     11 Status: Enable Category: unsuccessful-user
     11 Status: Enable Category:  misc-attack
     10 Status: Enable Category: successful-admin
     10 Status: Enable Category:  string-detect
     10 Status: Enable Category:  attempted-dos
      9 Status: Enable Category: suspicious-login
      5 Status: Enable Category: default-login-attempt
      4 Status: Enable Category: unknown
      4 Status: Enable Category:  suspicious-login
      4 Status: Enable Category: successful-user
      4 Status: Enable Category: non-standard-protocol
      4 Status: Enable Category: network-scan
      3 Status: Enable Category:  web-application-activity
      3 Status: Enable Category: system-call-detect
      3 Status: Enable Category: successful-recon-limited
      3 Status: Enable Category: successful-dos
      3 Status: Enable Category:  bad-unknown
      2 Status: Enable Category: unusual-client-port-connection
      2 Status: Enable Category:  not-suspicious
      1 Status: Enable Category:  successful-admin
      1 Status: Enable Category: string-detect
      1 Status: Enable Category:  shellcode-detect
      1 Status: Enable Category:  denial-of-service
      1 Status: Enable Category:  attempted-user


General Category/Classtype


   5213  web-application-attack
   1799  trojan-activity
    643  attempted-user
    568  policy-violation
    410   trojan-activity
    384  protocol-command-decode
    373  attempted-admin
    300  misc-activity
    276  attempted-recon
    268   policy-violation
    238  bad-unknown
    137  shellcode-detect
    136  attempted-dos
    134  misc-attack
     95  web-application-activity
     88  rpc-portmap-decode
     80   misc-activity
     39  not-suspicious
     36   web-application-attack
     27  successful-user
     25   attempted-recon
     20  unusual-client-port-connection
     17   misc-attack
     17  denial-of-service
     16  suspicious-filename-detect
     16   attempted-admin
     14  successful-admin
     13   attempted-dos
     12   bad-unknown
     11  unsuccessful-user
     11  unknown
     11  suspicious-login
     11   string-detect
     10   not-suspicious
     10  non-standard-protocol
      7  default-login-attempt
      5  system-call-detect
      5  successful-recon-limited
      5  network-scan
      4   web-application-activity
      4   suspicious-login
      4   suspicious-filename-detect
      4   shellcode-detect
      4   attempted-user
      3  successful-dos
      2  string-detect
      2   denial-of-service
      1   successful-admin
      1   non-standard-protocol


In summary:


- ET has almost double rules enable by default
- VRT most enable rules focus on attempted-user
- ET most enable rules focus on web-application-attack and trojan-activity
- Rules from ET and VRT target different protections what you should analyze where you will seat your sensor for best decision or using both and mixing them


I just did some basic scripting and my numbers could not be accurate but it's a good base .


Happy Snorting!


Rodrigo Montoro (Sp0oKeR)

Palestras no Brasil - OWASP e H2HC

Caros,

Faz um tempo desde o último post mas a vida anda corrida por esses lados .  Faço esse post para comentar mais 2 palestras aceitas só que agora no Brasil felizmente .

A primeira ocorrerá no OWASP AppSec Brasil que acontecerá em Campinas onde falarei do uso do Modsecurity WAF para Virtual Patching ( http://www.owasp.org/index.php/AppSec_Brasil_2010#tab=Speakers)

Mais info: http://www.owasp.org/index.php/AppSec_Brasil_2010#tab=Calls

Outra que tive o prazer de ser aceito e falarei pela primeira vez sera a Hackers to Hackers Conference aka H2HC . Nela falarei sobre minha pdf de scoring da estrutura do pdf o que me deixa bem feliz de falar sobre ela por aqui também. 

Mais info: http://www.h2hc.com.br

Espero encontrar com vocês lá .

Happy Hacking!

Rodrigo "Sp0oKeR" Montoro

PDF Talk Accepted at Toorcon San Diego

I'm very excited that my talk was accepted at Toorcon San Diego. About the conference:

Who:    Hackers Like You.
What:   ToorCon 12
When:   OCT 22rd-24th
Where:  San Diego Convention Center
Why:    What Could possibly go wrong?

I'll be talking about part of my research at Trustwave Spiderlabs Research where we are doing a new way to detect malicious pdf files . The title for my talk: "Scoring PDF structure to detect malicious files"

Preliminary Agenda for Toorcon: http://sandiego.toorcon.org/index.php?option=com_content&task=section&id=3&Itemid=9#lineup

Hope to see you there!

Rodrigo "Sp0oKeR" Montoro

Snort Rules - Using content:"GET "; or not ?

I'm doing some tests with different rules since I'm creating a rules test labs and based on some old read/thread and one simple test here I started to look why do we use content:"GET "; in a lot of rules since it'll not be the first match mostly.

My first test that I started to notice what I read before was about using http_method or not with engine 2.8.6 .

My pcap I created a very simple GET / (packet  5)

$ tshark -r get-NoHost.pcap
 1   0.000000 192.168.21.1 -> 192.168.21.131 TCP 61599 > http [SYN]
Seq=0 Win=65535 Len=0 MSS=1460 WS=3 TSV=534894464 TSER=0
 
2   0.001384 192.168.21.1 -> 192.168.21.131 TCP 61599 > http [ACK]
Seq=1 Ack=1 Win=524280 Len=0 TSV=534894464 TSER=134793051
 
 3   3.798825 192.168.21.1 -> 192.168.21.131 TCP [TCP Dup ACK 2#1]
61599 > http [ACK] Seq=1 Ack=1 Win=524280 Len=0 TSV=534894502
TSER=134794001
 
 4   7.348575 192.168.21.1 -> 192.168.21.131 TCP [TCP segment of a
reassembled PDU]
 
 5   7.892566 192.168.21.1 -> 192.168.21.131 HTTP GET / HTTP/1.0
 
 6   8.197800 192.168.21.1 -> 192.168.21.131 TCP 61599 > http [ACK]
Seq=19 Ack=325 Win=524280 Len=0 TSV=534894546 TSER=134795100
 
 7   8.202863 192.168.21.1 -> 192.168.21.131 TCP 61599 > http [ACK]
Seq=19 Ack=326 Win=524280 Len=0 TSV=534894546 TSER=134795102
 
 8   8.202895 192.168.21.1 -> 192.168.21.131 TCP 61599 > http [FIN,
ACK] Seq=19 Ack=326 Win=524280 Len=0 TSV=534894546 TSER=134795102

I used those rules for testing the basics in my lab:

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule One - GET";content:"GET";http_

method;content:"attack";sid:123456;)
 

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Two - POST";content:"POST";http_method;content:"index";sid:654321;)
 

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Three GET without
http_method";content:"GET";content:"ABCDE";sid:23465324;)
 

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Four GET without http_method but using fast_pattern";content:"GET";fast_pattern;content:"ABCDE";sid:9845324;)

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Five GET without http_method and only content";content:"GET";sid:4365324;)

And as result I got

$ perl rule-test-check.pl get-NoHost.pcap rules-samples/rules-new.rules snort.conf

SpiderLabs Rules Test version 0.1 Alpha

Result: Checked 123456 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule One - GET";content:"GET";http_ method;content:"attack";sid:123456;)

Result: NoCheck 654321 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Two - POST";content:"POST";http_ method;content:"index";sid:654321;)

Result: NoCheck 23465324 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Three GET without http_method";content:"GET"; content:"ABCDE";sid:23465324;)

Result: Checked 9845324 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Four GET without http_method but using fast_pattern";content:"GET"; fast_pattern;content:"ABCDE";sid:9845324;)

Result: Checked 4365324 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Five GET without http_method and only content";content:"GET";sid: 4365324;)

Count Summary

Checked: 3
NotChecked: 2

Where:

Checked means that there is some output for this sid for one basic check at least (I'm using as base content GET since we have the packet number 5 with it) .

Based on that I remembered a good thread where Will Metacalf and Steve discuss some new features and http_modifiers use http://sourceforge.net/mailarchive/message.php?msg_name=c13e433a1003092015v2d86f9a7x2eb73a2528df09f3%40mail.gmail.com .

So I tested based on some very basic grep at emerging-all.rules  "grep content:"GET " emerging-all.rules " . Using the rules that were output I ran my test against those rules (around 1047 rules) and the summary results:

Checked: 4
NotChecked: 1043

I started to figured out that content:"GET "; when we use that is tobe the first match BUT if you don't specify fast_pattern by default it'll be the bigger content to match ( http://vrt-sourcefire.blogspot.com/2009/07/rule-performance-part-one-content.html ) . So with another basic sed I changed the rules a little bit " sed -e 's/content:"GET ";/content:"GET ";fast_pattern;/g' " where it change for example:

Original

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT_EVENTS Zeus Bot / Zbot Checkin (/us01d/in.php)"; flow:established,to_server; content:"GET "; nocase; depth:4; uricontent:"/us01d/in.php"; reference:url,garwarner.blogspot.com/2010/01/american-bankers-association-version-of.html; reference:url,doc.emergingthreats.net/2010729; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/CURRENT_EVENTS/CURRENT_Zeus; classtype:trojan-activity; sid:2010729; rev:3;)

fast_pattern debug choosing the biggest content found

 Fast pattern matcher: URI content
 Fast pattern set: no
 Fast pattern only: no
 Negated: no
 Pattern offset,length: none
 Pattern truncated: no
 Original pattern
   "/us01d/in.php"
 Final pattern
   "/us01d/in.php"

After sed

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"ET CURRENT_EVENTS Zeus Bot / Zbot Checkin (/us01d/in.php)"; flow:established,to_server; content:"GET ";fast_pattern; nocase; depth:4; uricontent:"/us01d/in.php"; reference:url,garwarner.blogspot.com/2010/01/american-bankers-association-version-of.html; reference:url,doc.emergingthreats.net/2010729; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/CURRENT_EVENTS/CURRENT_Zeus; classtype:trojan-activity; sid:2010729; rev:3;)

Rules fast_pattern debug using this option

 Fast pattern matcher: Content
 Fast pattern set: yes
 Fast pattern only: no
 Negated: no
 Pattern offset,length: none
 Pattern truncated: no
 Original pattern
   "GET|20|"
 Final pattern
   "GET|20|"

I rerun the same test and I got:

Checked: 976
NotChecked: 71

* Where NotChecked are mostly some GET content in a different way since I'm doing pretty basic grep/sed and not being so accurate =) .

The last test I changed fast_pattern to http_method but http_method only receive the normalize buffer but the default fast_pattern is the same , that's mean bigger content  so no change from the first result.

So my question is:  do we really need to analyze GET or POST (probably the same behavior since it's a short name) ? Did somebody try/test something like this before ? am I getting nuts talking about this? =D

In my opinion we could remove content:"GET ";  from the rules since it'll only use some checks and "decrease" the performance . I think we already have lot of point that make sure that it's a http traffic since using $HTTP_PORTS , flow , uricontent that comes from http_inspect and so on.

Some friends that I discussed about this told some point as : "maybe the attack can only be done using GET so it's good to specify since using POST will generate a false positive". My argument is the opposite since most rules we are not sure if that works with GET and/or POST only if we don't use them as part of the rule we will mitigate False Negatives and maybe save lot of CPU's cycle (but we need test to make sure about that) . I really prefer couple of FP than FN's .

What do you think ?

Regards,

Rodrigo "Sp0oKeR" Montoro

(IN)Secure Magazine Issue 17 released

New release of this awesome digital and free magazine

• Review: BlockMaster SafeStick secure USB flash drive
• The devil is in the details: Securing the enterprise against the cloud
• Cybercrime may be on the rise, but authentication evolves to defeat it
• Learning from bruteforcers
• PCI DSS v1.3: Vital to the emerging demand for virtualization and cloud security
• Security testing - the key to software quality
• A brief history of security and the mobile enterprise
• Payment card security: Risk and control assessments
• Security as a process: Does your security team fuzz?
• Book review: Designing Network Security, 2nd Edition
• Intelligent security: Countering sophisticated fraud

To download it:  http://www.net-security.org/insecuremag.php

Regards,

Rodrigo "Sp0oKeR" Montoro