Showing posts with label Intrusion Detection. Show all posts
Showing posts with label Intrusion Detection. Show all posts

Sunday, May 19, 2013

Detecting Evil: Network Security Monitoring

Trying to clear out the backlog of posts in my Drafts folder and this one is long over due...

News Headlines

These are just a couple of the new stories that caught my eye [in the hopefully not too distant past].

BofA Confirms Third-Party Breach

"Bank of America systems were not compromised. Our customer data is secure." Mark Pipitone, BofA Spokesman

Evernote Security Notice

"Evernote’s Operations & Security team has discovered and blocked suspicious activity on the Evernote network that appears to have been a coordinated attempt to access secure areas of the Evernote Service."


LA Times Serving Up Malware

"To ensure safety, the Offers & Deals platform has been rebuilt and further secured. The sub-domain generates only advertising content and does not contain any customer information."

So What's Going On?

When ever I read headlines like this, they almost always come with some disclaimer that "There is no evidence that the intruders gained access to..." and rightly so.  A lot of companies don't have the ability to detect the breach in the first place, and then when they are notified about it by some third party (customers, law enforcement or the attackers themselves) they most certainly don't have any way to tell what information was stolen, so they claim that customers need not worry because there isn't any evidence of their information being stolen.

"Is it just me or am I the only one who thinks how can these attackers be so good as to break into the networks of companies yet those companies always seem to stop the attack just before the attackers gain access to sensitive information?" Brian Honan, SANS NewsBites Vol 15 Issue18.
 

Assessing the Damage

Because of all of the cover-up attempts by companies to minimize the negative publicity falls out from disclosing a data breach, it can be difficult to find relevant data to use to education the decision makers in your organization about the importance of good Network Security Monitoring.  Here are some resources that I have found useful in describing the impact of a security breach to executives and senior management:
 
And some other interesting statistics in regards to the accuracy of claims that companies caught the bad guys "just in the nick of time".
  • Trustwave 2012 GSR states breach to detection was 173.5 days within the victim’s environment before detection occurred. 
  • In the Trustwave 2013 GSR breach to detection window widened to 210 days. 
  • The Mandiant 2012 Annual Threat Report on Advanced Targeted Attacks sites a much larger window, "The median number of days from the first evidence of compromise to when the attack was identified was 416 days." 
  • The more recent Mandiant APT1 Report states "[attackers] were inside victim systems for avg of 356 days; longest observed: 1764 days"
  • The Verizon DBIR 2012 states, "It saddens us to report that, yet again, breach victims could have circumnavigated the globe in a pirogue (not from the bayou? Look it up.) before discovering they were owned. In over half of the incidents investigated, it took months—sometimes even years—for this realization to dawn. That’s a long time for customer data, IP, and other sensitive information to be at the disposal of criminals without the owners being aware of it."
  • The Verizon DBIR 2013 concludes that it still takes on average 221 from breach to discovery.
These numbers seem to echo a common sentiment that there are two kinds of companies out there; those who know they've been breached and those who have been breached and just don't know it yet.

Saturday, March 9, 2013

Just Some Notes On TCPDump Filters

Well I'm sitting here in Orlando at the SANS 2013 conference.  I have a few hours until registration opens up and I was looking through some of my notes from previous SANS conferences.  Here are some tcpdump examples and notes I had accumulated while studying for the GCIA exam.  Some of these are examples I've found from various other sources* and some of them I added for my own reference.  Enjoy!

Expression Description
[x:y] start at offset x from the beginning of packet and read y bytes
[x] abbreviation for [x:1]
proto[x:y] start at offset x into the proto header and read y bytes
p[x:y] & z = 0 p[x:y] has none of the bits selected by z
p[x:y] & z != 0 p[x:y] has any of the bits selected by z
p[x:y] & z = z p[x:y] has all of the bits selected by z
p[x:y] = z p[x:y] has only the bits selected by z
The usual rules about operator precedence apply; nesting things inside brackets is probably a good plan. you'll probably want to put the filter into a file or at least single-quote it on the commandline to stop the shell from interpreting the metacharacters. !([:])&


Parts of an IP Packet
ip[0] & 0xf0 High order nibble: IP version (4 = IPv4, 6 = IPv6)
ip[0] & 0x0f Low order nibble: Header Length (Common Value = 5, Multiplier 4, 20 byte header)
ip[1] Type of Service/QoS/DiffServ
ip[2:2] Total length of datagram in octets
ip[4:2] IP ID number
ip[6] & 0x80 Reserved (Evil bit)
ip[6] & 128 != 0 Evil bit set (RFC 3514 defines the evil bit as April Fools joke)
ip[6] & 0x40 Don't Fragment bit
ip[6] & 0x20 More Fragments bit
ip[6:2] & 0x1fff Fragment Offset (number of 8 octet blocks)
ip[6:2] & 0x1fff != 0x000 Fragment Offset is not 0
ip[6:2] & 0x3fff != 0 Look for ALL fragmented ip packets
ip[6] &0x20 = 0x20 or ip[6:2] &0x1fff != 0 Look for more fragment bit set or fragment offset greater than 0 (Look for ALL fragmented ip packets)
ip[6] &0x20 = 0 and ip[6:2] &0x1fff != 0 Look for more fragment bit not set and fragment offset greater than 0 (Last fragment packets)
ip[8] TTL
ip[9] Protocol
ip[9] = 0x01 1 = ICMP
ip[9] = 0x02 2 = IGMP
ip[9] = 0x06 6 = TCP
ip[9] = 0x09 9 = IGRP
ip[9] = 0x11 17 = UDP
ip[9] = 0x2F 47 = GRE
ip[9] = 0x32 50 = ESP
ip[9] = 0x33 51 = AH
ip[10:2] Header Checksum
ip[12:4] Source IP
ip[16:4] Destination IP
ip[20..60] No IP Header Options


Parts of an ICMP Packet
icmp[0] Type
icmp[1] Code
icmp[2:2] Checksum
icmp[4...] Payload


Parts of a UDP Packet
udp[0:2] source port
udp[2:2] destination port
udp[4:2] datagram length
udp[6:2] UDP checksum


Parts of a TCP Packet
tcp[0:2] source port
tcp[2:2] destination port
tcp[4:4] sequence number
tcp[8:4] acknowledgement number
tcp[12] header length (Multiplier 4)
tcp[13] tcp flags
tcp[14:2] window size
tcp[16:2] checksum
tcp[18:2] urgent pointer
tcp[20..60] options or data


Other Examples
(tcp[13] & 0x02) != 0 Contains SYN (maybe other stuff as well)
(tcp[13] & 0x03) = 3 SYN / FIN
ip[12:4] = ip[16:4] Land Attack
(tcp[2:2] = 139) && (tcp[13] & 0x20 != 0) && (tcp[19] & 0x01 = 1) Winnuke
(tcp[13] & 0xe7) != 0 Things other than ACK/PSH
(ip[6] & 0x20 != 0) && (ip[6:2] & 0x1fff = 0) Initial fragments
(ip[6] & 0x20 != 0) && (ip[6:2] & 0x1fff != 0) Intervening fragments
(ip[6] & 0x20 = 0) && (ip[6:2] & 0x1fff != 0) End of the fragment train
(ip[0] & 0x0f) != 5 Has IP Options (or is truncated, or is just some sort of freak...)
((ip[6] & 0x20 = 0) && (ip[6:2] & 0x1fff != 0)) && ((65535 < (ip[2:2] + 8*(ip[6:2] & 0x1fff)) Ping-O-Death (any oversized IP-transported data...)


TCP Flags (Control Bits)
CWR | ECE | URG | ACK | PSH | RST | SYN | FIN



FIN = Finish
SYN = Synchronize
RST = Reset
PSH = Push
ACK = Acknowledgment
URG = Urgent
ECE = Explicit Congestion Notification Echo
CWR = Congestion Window Reduced




Filter Flags Binary      Hex Description
tcp[13] = 0x01 ---- ---F 0000 0001 = 0x01 FIN only
tcp[13] = 0x02 ---- --S- 0000 0010 = 0x02 SYN only
tcp[13] = 0x03 ---- --SF 0000 0011 = 0x03 SYN-FIN
tcp[13] = 0x04 ---- -R-- 0000 0100 = 0x04 RST only
tcp[13] = 0x05 ---- -R-F 0000 0101 = 0x05 RST-FIN
tcp[13] = 0x06 ---- -RS- 0000 0110 = 0x06 SYN-RST
tcp[13] = 0x07 ---- -RSF 0000 0111 = 0x07 SYN-FIN-RST
tcp[13] = 0x08 ---- P--- 0000 1000 = 0x08 PSH only
tcp[13] = 0x10 ---A ---- 0001 0000 = 0x10 ACK only
tcp[13] = 0x12 ---A --S- 0001 0010 = 0x12 SYN-ACK
tcp[13] = 0x14 ---A -R-- 0001 0100 = 0x14 RST-ACK (it happens)
tcp[13] = 0x18 ---A P--- 0001 1000 = 0x18 PSH-ACK
tcp[13] = 0x20 --U- ---- 0010 0000 = 0x20 URG only
tcp[13] = 0x29 --U- P--F 0010 1001 = 0x29 URG-PSH-FIN (nmap fingerprint packet)
tcp[13] = 0x38 --UA P--- 0011 1000 = 0x38 PSH-URG-ACK interactive stuff like ssh
tcp[13] = 0x40 -Y-- ---- 0100 0000 = 0x40 anything >= 0x40 has a reserved bit set
Tcp[13] = 0x80 X--- ---- 1000 0000 = 0x80 CWR only
tcp[13] = 0xC0 XY-- ---- 1100 0000 = 0xC0 Both ECN flags set
tcp[13] = 0xFF XYUA PRSF 1111 1111 = 0xFF FULL_XMAS scan




tcp[13] & 1 != 0 ---- ---F 0000 0001 = 0x01 FIN set
tcp[13] & 2 != 0 ---- --S- 0000 0010 = 0x02 SYN set
tcp[13] & 4 != 0 ---- -R-- 0000 0100 = 0x04 RST set
tcp[13] & 8 != 0 ---- P--- 0000 1000 = 0x08 PSH set
tcp[13] & 16 != 0 ---A ---- 0001 0000 = 0x10 ACK set
tcp[13] & 32 != 0 --U- ---- 0010 0000 = 0x20 URG set
tcp[13] & 64 != 0 -Y-- ---- 0100 0000 = 0x40 ECE set
tcp[13] & 128 != 0 X--- ---- 1000 0000 = 0x80 CWR set

*Some examples are from
http://staff.washington.edu/dittrich/talks/core02/tools/tcpdump-filters.txt and reformatted into a table.  This site also has some other useful info and examples.

Friday, November 9, 2012

GCIA Exam Prep

So, I attended the SANS Rocky Mountain Conference in Denver last June.  It was an odd venue at The Curtis.  My room was on the 13th floor, and every time the elevator doors opened up I was greeted by Jack Nicholson’s voice saying “Here’s Johnny!”  Accommodations aside, I took the SEC503, Intrusion Detection course with the master Mike Poor guiding the class through a week of deep dive into the world of decoding Binary to Hex to Decimal to Binary to Decimal to Portuguese to Hex to Russian to, well you get the idea.

Things I learned

Packet Analysis isn’t that difficult if you understand a few basics.  (Note: I didn’t say good analysis.)

There are plenty of tools out there to make your job easier, but there are times when the tools aren’t going to work as expected.  In those cases (often the most critical if dealing with a new 0-Day exploit or crafted packets that bypass known signatures), it is imperative to understand how to manually decode packets to find where the evil is hiding.

A determined attacker can always find a way in.  The really good attacker does so with very minimal noise.  For example, on day 6 during the PCAP analysis challenge, one of the things that really stood out to me was that there were several various attempts to compromise the honeypot we were asked to analyze, but the successful attacker was able to gain root access and do so by generating less than 1% of all the alerts that were triggered by the snort signatures we were using.  Talk about finding the smallest needle in the needle-stack!

Review your logs!  This is one of those things that every admin knows he ought to do, but never seems to find the time to do it right.  The key to managing your time for reviewing logs and alerts for Intrusion Analysts is minimizing the number of false positives.  This involves knowing how to build an IDS in such a way as to detect the attacks that are most likely to succeed in the environment you are trying to protect.  Is there really a point in alerting on the fact that someone just tried to port scan your network?  Maybe, but it depends on how much time you are really going to spend researching that event.  Are you really getting any value out of that snort alert letting you know that SQL Slammer is still probing port 1434, even though your firewall doesn’t allow any traffic from the outside in to port 1434?

Regrets

I wish I would have spent a little more time before class studying up on some of the material to have a better foundation to build on.  For example, my *nix-fu is less than stellar.  I’ll admit, I’m still in grasshopper mode when it comes to chaining command line tools together like cut, uniq, sort, awk, and sed.


I wish the class would have spent at least a half day or so walking though the Security Onion (SO) disto.  The Packetrix VM has enough tools to complete the PCAP analysis challenge for day six, but it would have been fun to use tcpreplay to feed the pcap into SO and use Squil to drill into the details of the attack.  I really wish that we could have spent just little bit of time on a quick into to Bro-IDS.  Mike mentioned OSSEC a few times in class, but I wish we could have spent some time looking at how it works.

I wish I would have read Network Intrusion Detection (NID) by Stephen Northcutt and Judy Novak before taking the class.  The course materials were written by Judy, and NID covers a lot of the same material and has somewhat the same approach to the material that the class had.  I highly recommend for anyone getting ready to take SEC503, read NID.

Studying for the GCIA Exam

Came home.  Went back to work.  Played catch up on all the requests piling up while I was gone.  Finally got around to taking the first practice exam a few weeks later.  I found out I was actually pretty interested in learning more about blue team operations so I order a few books and spun up a few VMs and started playing around. 

Below is a list of materials I used to study for the exam and polish up my intrusion analysis skills. 



SANS SEC503 Course Material






Network Intrusion Detection by Stephen Northcutt and Judy Novak


TCP/IP Illustrated, Vol. 1 by W. Richard Stevens
 













Practical Packet Analysis by Chris Sanders
 













Snort IDS and IPS Toolkit by Jay Beale, Brian Caswell and Andrew Baker
 












OSSEC Host-Based Intrusion Detection Guide by Andrew Hay, Daniel Cid and Rory Bray













So how did I do on the exam?

This was a tough exam.  I poured a lot of hours into studying for this.  It was getting close to the deadline to take the exam, so I signed up at the closest PearsonVUE testing center, only to have them call be back after 5 PM on the Friday night before I was scheduled to take the exam on Monday morning to tell me that my scheduled exam was canceled due to technical difficulties.  Contacted GIAC right away and they work everything out, which gave me a couple of extra weeks to cram.  In the end, all of the extra study paid off.  I aced the exam.