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
quarta-feira, 8 de setembro de 2010
quinta-feira, 2 de setembro de 2010
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_
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Five GET without http_method and only content";content:"GET";sid:
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_
Result: NoCheck 654321 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Two - POST";content:"POST";http_
Result: NoCheck 23465324 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Three GET without http_method";content:"GET";
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";
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:
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/
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.
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.
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.
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.
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_
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Two - POST";content:"POST";http_
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Three GET without
http_method";content:"GET";
http_method";content:"GET";
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Four GET without http_method but using fast_pattern";content:"GET";
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Five GET without http_method and only content";content:"GET";sid:
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_
Result: NoCheck 654321 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Two - POST";content:"POST";http_
Result: NoCheck 23465324 alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"New Rule Three GET without http_method";content:"GET";
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";
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:
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/
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.
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.
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"
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.
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
quarta-feira, 1 de setembro de 2010
(IN)Secure Magazine Issue 17 released
New release of this awesome digital and free magazine
To download it: http://www.net-security.org/insecuremag.php
Regards,
Rodrigo "Sp0oKeR" Montoro
- 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
Assinar:
Postagens (Atom)