TCP/IP Weapons School Will Rock

Are you attending TCP/IP Weapons School at USENIX Security 2006 In Vancouver on 31 July and 1 August 2006? If yes, these are the topics I will cover:

• Hardware and Network Design




• Bridges


• Hubs


• Switches


• Routers


• Duplex and Domains


• Layer-X Switches


• Middleboxes


• Local Area Networks


• xANs, VPNs, and WLANs


• VLANs




• Layer 1




• What is Layer 1?


• Ethernet


• Raw Ethernet (Nemesis)


• UTP


• Ethernet over UTP


• Fiber Optics


• Ethernet over Fiber Optics


• Ethernet Emulation over FireWire


• IP over FireWire


• IP over Wireless




• Layer 1 Attack




• Rogue Access Point




• Layer 2




• What is Layer 2?


• Ethernet Revisited


• Revisiting What is Layer 2?


• Test Network Layout


• Packet Delivery on the LAN


• Ethernet Interfaces


• ARP Basics


• ARP Request/Reply


• ARP Cache


• Arping


• Arpdig


• Arpwatch


• Dynamic Trunking Protocol




• Layer 2 Attacks




• Test LAN Reference


• Changing MAC Addresses


• MAC Flooding (Macof)


• ARP Denial of Service (Arp-sk)


• Port Stealing (Ettercap)


• Layer 2 Man-In-The-Middle (Ettercap)


• Dynamic Trunking Protocol Attack (Yersinia)




• Layer 3




• What is Layer 3?


• Internet Protocol


• Raw IP (Nemesis)


• IP Options (Fragtest)


• IP Time-To-Live (Traceroute)


• Internet Control Message Protocol (Sing)


• ICMP Error Messages (Gnetcat)




• Layer 3 Attacks




• IP Spoofing


• Gont ICMP Attacks


• ICMP Shell

I am really excited by this class. If you read the class description posted at USENIX, you'll notice it goes through levels 1-7. After creating 312 slides for a two-day class, I realized I needed to stop with level 3. I originally envisioned this class being a four-day affair, and once I develop material for levels 4-7 I can see it being a new four-day class.

One of the reasons I think this class will be special is that I generated Libpcap traces of all of the interesting traffic discussed in the class. Students can load them into Wireshark and follow along as we learn what they mean.

Developing the class was absolutely grueling (well, not like digging a ditch), but still fun. I had never used Yersinia to fake a trunk line and get access to VLAN traffic on a Cisco switch, but it's in the class now.

The USENIX class description recommends students bring some version of VMware to class so they can run a VM I will provide. I will indeed provide a FreeBSD VM including all of the tools I used on FreeBSD. I'll probably also include a Debian VM for those tools that didn't run on FreeBSD. However, you will not be able to duplicate all of the attacks I ran while developing this class. VMware is nice, but it cannot simulate conditions in a real hardware lab, especially when mucking around with layer 2.

If you have any questions, please post them here.

I am probably going to offer this same two-day class at USENIX LISA on 3-4 December 2006 in Washington, DC. I am contemplating offering additional material independent of USENIX, perhaps before the conference (which runs 3-8 December) or after the conference. That means Saturday 2 December or Saturday 9 December. These would be paid events separate from USENIX. If you would have any interest in attending training while you are in town, email me (richard at taosecurity dot com) with your ideas.

Read More

Of Course Insiders Cause Fewer Security Incidents

Today's SANS NewsBites points to this eWeek article, which in turn summarizes this Computer Associates press release. It claims "more than 84% [of survey respondents] experienced a security incident over the past 12 months and that the number of breaches continues to rise."

The SANS editor piqued my interest with this comment: "(Honan): It is interesting to note that this survey highlights the external threat is becoming more prevalent than the internal one." (emphasis added)

"Becoming more prevalent?" This is Mr. Honan's answer to this part of the CA story: "Of the organizations which experienced a security breach, 38% suffered an internal breach of security." That means 62% experienced an external breach, or perhaps less if one could not determine the source of the breach.

I highlight "becoming more prevalent" because it indicates the speaker (like countless others) fell for the "80% myth," which is a statement claiming that 80% of all security incidents are caused by insiders. I document in Tao the history of this myth. I challenge anyone who believes the 80% myth to trace it back to some definitive source. If you do you will find it leads nowhere reputable.

If the 80% myth were true, security would be a fairly easy problem to solve. The biggest problem I see with modern digital security is the inability to remove threats from the risk equation. In other words, victims of secuirty incidents lack the personal power to eliminate threats; only the police or military can really remove threats from the picture. Since the police is ill-equipped and overwhelmed, and the military similarly not well-positioned to eliminate threats, attackers continue to assault with impunity.

However, if the majority (the vast majority, if you believe the 80% myth) of threats are internal, this completely changes the situation. To immediately and irrevocably alter the risk equation, all an employer or organization needs to do is identify and fire or remove the internal bad apples. Problem solved. "Oh, that's too hard," I'm going to hear. Maybe, but compare that option (which happens every day) to identifying, apprehending, prosecuting, and jailing a Romanian.

Since organizations have the tools to largely remove the insider threat, but security incidents continue to be a problem, insiders must be dwarfed by the size of the outsider threat community. However, as I've said elsewhere, insiders will always be better informed and positioned to cause the most damage to their victims. They know where to hurt, how to hurt, and may already have all the access they need to hurt, their victim.

The bottom line is that the number of external attackers far exceeds the number of internal attackers.

Read More

Control-Compliant vs Field-Assessed Security

Last month's ISSA-NoVA meeting featured Dennis Heretick, CISO of the US Department of Justice. Mr. Heretick seemed like a sincere, devoted government employee, so I hope no one interprets the following remarks as a personal attack. Instead, I'd like to comment on the security mindset prevalent in the US government. Mr. Heretick's talk sharpened my thoughts on this matter.

Imagine a football (American-style) team that wants to measure their success during a particular season. Team management decides to measure the height and weight of each player. They time how fast the player runs the 40 yard dash. They note the college from which each player graduated. They collect many other statistics as well, then spend time debating which ones best indicate how successful the football team is. Should the center weigh over 300 pounds? Should the wide receivers have a shoe size of 11 or greater? Should players from the north-west be on the starting line-up? All of this seems perfectly rational to this team.

An outsider looks at the situation and says: "Check the scoreboard! You're down 42-7 and you have a 1-6 record. You guys are losers!"

In my opinion, this summarizes the mindset of US government information security managers.

Here are some examples from Mr. Heretick's talk. He showed a "dashboard" with various "metrics" that supposedly indicate improved DoJ security. The dashboard listed items like:

• IRP Reporting: meaning Incident Response Plan reporting, i.e., does the DoJ unit have an incident response plan? This says nothing about the quality of the IRP.


• IRP Exercised: has the DoJ unit exercised its IRP? This says nothing about the effectiveness of the IRT in the exercise.


• CP Developed: meaning Contingency Plan developed, i.e, does the DoJ unit have a contingency plan should disaster strike? This also says nothing about the quality of the CP.


• CP Exercised: has the DoJ unit exercised its CP? Same story as the IRP.

Imagine a dashboard, then, with all "green" for these items. They say absolutely nothing about the "score of the game."

How should the score be measured then? Here are a few ideas, which are neither mutually exclusive nor exceedingly well-thought-out:

• Days since last compromise of type X: This is similar to a manufacturing plant's "days since an accident" report or a highway's "days since a fatality" report. For some sites this number may stay zero if the organization is always compromised. The higher the number, the better.


• System-days compromised: This looks at the number of systems compromised, and for how many days, during a specified period. The lower, the better.


• Time for a pen testing team of [low/high] skill with [internal/external] access to obtain unauthorized [unstealthy/stealthy] access to a specified asset using [public/custom] tools and [complete/zero] target knowledge: This is from my earlier penetration testing story.

These are just a few ideas, but the common theme is they relate to the actual question management should care about: are we compromised, and how easy is it for us to be compromised?

I explained my football analogy to Mr. Heretick and asked if he would adopt it. He replied that my metrics would discourage DoJ units from reporting incidents, and that reporting incidents was more important to him than anything else. This is ridiculous, and it indicates to me that organizations like this (and probably the whole government) need independent, Inspector General-style units that roam freely to assess networks and discover intruders.

In short, the style of "security" advocated by government managers seems to be "control-compliant." I prefer "field-assessed" security, although I would be happy to replace that term with something more descriptive. In the latest SANS NewsBites (link will work shortly) Alan Paller used the term "attack-based metrics," saying the following about the VA laptop fiasco: "if the VA security policies are imprecise and untestable, if the VA doesn't monitor attack-based metrics, and if there are no repercussions for employees who ignore the important policies, then this move [giving authority to CISOs] will have no impact at all."

PS: Mr. Heretick shared an interesting risk equation model. He uses the following to measure risk.

• Vulnerability is measured by assessing exploitability (0-5), along with countermeasure effectiveness (0-2). Total vulnerability is exploitability minus countermeasures.


• Threat is measured by assessing capability (1-2), history (1-2), gain (1-2), attributability (1-2), and detectability (1-2). Total threat is capability plus history plus gain minus attributability minus detectability.


• Significance (i.e., impact or cost) is measured by assessing loss of life (0 or 4), sensitivity (0 or 4), operational impact (0 or 2), and equipment loss (0 or 2). Total significance is loss plus op impact plus sensitivity plus equipment loss.


• Total risk is vulnerability times threat times significance, with < 6 very low, 6-18 low, 19-54 medium, 55-75 high, and >75 very high.

Read More

Tao Is One of Information Security's Top Ten Books

The July 2006 issue of Information Security magazine features my first book The Tao of Network Security Monitoring as one of their Top Ten Books. That's pretty cool. I see some overlap with my Top Ten Books, published last year.

Read More

The One-Minute Wireless Bridge

I am aware of the several fake access point projects available, like Rfakeap. Since one of the main purposes of my blog is to document how I configure applications for my personal future reference, I am listing the steps I performed to set up a wireless access point on FreeBSD.

The FreeBSD WAP laptop will receive its Internet connectivity via DHCP and a WEP-protected wireless network, from, say a conference. The laptop WAP will provide an encryption-free wireless connection to anyone who cares to connect.

I use two wireless NICs for this project.

First I connect the laptop to the local wireless network.

orr:/root# ifconfig wi0
wi0: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        ether 00:02:2d:4c:ae:de
        media: IEEE 802.11 Wireless Ethernet autoselect (none)
        status: no carrier
        ssid "" channel 1
        stationname "FreeBSD WaveLAN/IEEE node"
        authmode OPEN privacy OFF txpowmax 100
orr:/root# kldload wlan_wep
orr:/root# ifconfig wi0 ssid shaolin wepkey 0x[WEP key here] deftxkey 1 wepmode on up
orr:/root# dhclient wi0
DHCPDISCOVER on wi0 to 255.255.255.255 port 67 interval 3
DHCPOFFER from 192.168.2.1
DHCPREQUEST on wi0 to 255.255.255.255 port 67
DHCPACK from 192.168.2.1
bound to 192.168.2.102 -- renewal in 43200 seconds.
orr:/root# ifconfig wi0
wi0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::202:2dff:fe4c:aede%wi0 prefixlen 64 scopeid 0x4 
        inet 192.168.2.102 netmask 0xffffff00 broadcast 192.168.2.255
        ether 00:02:2d:4c:ae:de
        media: IEEE 802.11 Wireless Ethernet autoselect (DS/2Mbps)
        status: associated
        ssid shaolin channel 6 bssid 00:13:10:65:2f:ad
        stationname "FreeBSD WaveLAN/IEEE node"
        authmode OPEN privacy MIXED deftxkey 1 wepkey 1:104-bit txpowmax 100
        bintval 100
orr:/root# ping -c 1 www.google.com
PING www.l.google.com (64.233.161.104): 56 data bytes
64 bytes from 64.233.161.104: icmp_seq=0 ttl=229 time=61.857 ms

--- www.l.google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 61.857/61.857/61.857/0.000 ms

The laptop wi0 wireless NIC has been assigned 192.168.2.102 via DHCP and it can reach the outside world.

Next I set up wi1 to be the wireless NIC for the WAP.

orr:/root# ifconfig wi1
wi1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
        ether 00:04:e2:29:3b:ba
        media: IEEE 802.11 Wireless Ethernet autoselect (none)
        status: no carrier
        ssid "" channel 1
        stationname "FreeBSD WaveLAN/IEEE node"
        authmode OPEN privacy OFF txpowmax 100
orr:/root# kldload bridge
orr:/root# sysctl net.link.ether.bridge.enable=1
net.link.ether.bridge.enable: 0 -> 1
orr:/root# sysctl net.link.ether.bridge.config="wi0 wi1"
net.link.ether.bridge.config:  -> wi0 wi1
orr:/root# sysctl net.inet.ip.forwarding=1
net.inet.ip.forwarding: 0 -> 1
orr:/root# ifconfig wi1 ssid bejnet channel 11 media DS/11Mbps mediaopt hostap up stationname "BejNet AP"
orr:/root# ifconfig wi1 inet 10.10.10.1 netmask 255.255.255.0 up
orr:/root# ifconfig wi1
wi1: flags=8943 mtu 1500
        inet6 fe80::204:e2ff:fe29:3bba%wi1 prefixlen 64 scopeid 0x5 
        inet 10.10.10.1 netmask 0xffffff00 broadcast 10.10.10.255
        ether 00:04:e2:29:3b:ba
        media: IEEE 802.11 Wireless Ethernet DS/11Mbps  (DS/2Mbps )
        status: associated
        ssid bejnet channel 11 bssid 00:04:e2:29:3b:ba
        stationname "BejNet AP"
        authmode OPEN privacy OFF txpowmax 100 dtimperiod 1 bintval 100

At this point the WAP can transmit packets from wi1 to wi0 and vice-versa. However, it would be a good idea for the clients that associate with the WAP to get addresses via DHCP, preferably from a range not in use (e.g., not 192.168.2.0/24). This requires DHCP, which I set up in /etc/rc.conf:

dhcpd_enable="YES"                          # dhcpd enabled?
dhcpd_flags="-q"                            # command option(s)
dhcpd_conf="/usr/local/etc/dhcpd.conf"      # configuration file
dhcpd_ifaces="wi1"                          # ethernet interface(s)

and /usr/local/etc/dhcpd.conf:

option domain-name "taosecurity.com";
option domain-name-servers 192.168.2.1;

default-lease-time 6000;
max-lease-time 72000;

ddns-update-style ad-hoc;
log-facility local7;

subnet 10.10.10.0 netmask 255.255.255.0 {
  range 10.10.10.128 10.10.10.192;
  option routers 10.10.10.1;
}

I'm being a little lazy here. I should replace the "legitimate" name server, 192.168.2.1, with 10.10.10.1 (my WAP), and configure a caching name server on my WAP. I'm going to avoid that step here, but I would probably do it elsewhere.

At this point you might think I am good to go. I have a rogue WAP on wi1 with IP 10.10.10.1 ready to serve IP addresses once I start dhcpd. The problem is I doubt the legitimate conference WAP knows how to reach my 10.10.10.0/24 network. Clients who associate with my laptop WAP will send traffic with source IPs like 10.10.10.192, but the conference WAP gateway at 192.168.2.1 will not know how to reach the 10.10.10.0/24 network.

The answer is to set up NAT on the laptop WAP.

orr:/root# kldload ipfw
orr:/root# kldload ipdivert
orr:/root# natd -dynamic -n wi0
orr:/root# ipfw add divert natd ip from any to any via wi0
00100 divert 8668 ip from any to any via wi0
orr:/root# ipfw add allow ip from any to any
00200 allow ip from any to any

Now the laptop WAP will NAT for connections on the wi1 network. Remember wi0 is closer to the "Internet" so the 192.168.2.0/24 network will see hosts on the 10.10.10.0/24 network coming from 192.168.2.102.

Last I start dhcpd.

orr:/root# /usr/local/etc/rc.d/isc-dhcpd.sh start
Starting dhcpd.
orr:/root# sockstat -4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS      
dhcpd    dhcpd      1047  5  udp4   *:67                  *:*
root     natd       976   3  div4   *:8668                *:*
root     sendmail   474   4  tcp4   127.0.0.1:25          *:*
root     sshd       468   4  tcp4   *:22                  *:*
root     syslogd    320   7  udp4   *:514                 *:*

That's it. Now I can watch the wi1 interface for traffic from anyone who associates with my laptop WAP. I check /var/db/dhcpd/dhcpd.leases and see the following:

lease 10.10.10.192 {
  starts 3 2006/07/05 15:56:21;
  ends 3 2006/07/05 17:36:21;
  binding state active;
  next binding state free;
  hardware ethernet 00:13:02:4c:30:2d;
  uid "\001\000\023\002L0-";
  client-hostname "neely";
}

I got someone using host neely to associate with my BejNet laptop WAP. Now I watch for traffic.

orr:/root# tcpdump -n -i wi1 -s 1515
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wi1, link-type EN10MB (Ethernet), capture size 1515 bytes
11:55:21.201914 arp who-has 10.10.10.1 tell 10.10.10.192
11:55:21.202170 arp who-has 10.10.10.1 tell 10.10.10.192
11:55:21.202372 arp reply 10.10.10.1 is-at 00:04:e2:29:3b:ba
11:55:21.204930 IP 10.10.10.192.1025 > 192.168.2.1.53:  9367+ A? www.google.com. (32)
11:55:21.484230 IP 192.168.2.1.53 > 10.10.10.192.1025:  
 9367 3/0/0 CNAME www.l.google.com., A 216.239.37.99, A 216.239.37.104 (84)
11:55:22.195205 IP 10.10.10.192.1025 > 192.168.2.1.53:  9367+ A? www.google.com. (32)
11:55:22.198575 IP 192.168.2.1.53 > 10.10.10.192.1025:  
 9367 2/0/0 A 216.239.37.99, A 216.239.37.104 (64)
11:55:22.203729 IP 10.10.10.192 > 216.239.37.99: ICMP echo request, id 1024, seq 2304, length 40
11:55:22.246182 IP 216.239.37.99 > 10.10.10.192: ICMP echo reply, id 1024, seq 2304, length 40

There we are. 10.10.10.192 is pinging Google. Here is the view from the other side of the NAT.

orr:/root# tcpdump -n -i wi0 -s 1515
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wi0, link-type EN10MB (Ethernet), capture size 1515 bytes
11:55:21.202186 arp who-has 10.10.10.1 tell 10.10.10.192
11:55:21.205067 IP 192.168.2.102.1025 > 192.168.2.1.53:  9367+ A? www.google.com. (32)
11:55:21.484044 IP 192.168.2.1.53 > 192.168.2.102.1025: 
 9367 3/0/0 CNAME www.l.google.com., A 216.239.37.99, A 216.239.37.104 (84)
11:55:22.195388 IP 192.168.2.102.1025 > 192.168.2.1.53:  9367+ A? www.google.com. (32)
11:55:22.198491 IP 192.168.2.1.53 > 192.168.2.102.1025: 
 9367 2/0/0 A 216.239.37.99, A 216.239.37.104 (64)
11:55:22.203809 IP 192.168.2.102 > 216.239.37.99: ICMP echo request, id 1024, seq 2304, length 40
11:55:22.246099 IP 216.239.37.99 > 192.168.2.102: ICMP echo reply, id 1024, seq 2304, length 40

As far as the 192.168.2.0/24 network is concerned, 192.168.2.102 is making the request -- not 10.10.10.192.

That's it. Obviously this is exactly how to set up your own wireless access point for legitimate purposes. It's also how anyone could set up a WAP to watch traffic from anyone who decides to associate with my laptop WAP. This is the reason 802.11i and other systems are needed, although arbitrarily trusting wireless access points is more of a social problem than a technical problem.

Update: There appear to be some problems with comments, so I'll post additional thoughts here.

Chris asked about dispensing with DHCP and NAT.

I tried two approaches along those lines, but neither worked.

First I tried simply removing DHCP and NAT, but leaving wi0 with an IP address and assigning no IP address to wi1. In this scenario, I could see ARP traffic from an associated client for the DHCP server on the "conference" WAP (who has 192.168.2.1?) but the DHCP server on the conference WAP did not respond.

Next I tried doing nothing but setting up wi0 and wi1 as a pure bridge. wi0 associated with the conference WAP, and wi1 set up as an access point. Again, I could not get the DHCP server on the conference WAP to respond.

By the way, when I say "conference" I really mean the Linksys WRT54G WAP in my lab.

Remember that NAT is not strictly necessary if the conference WAP gateway knows how to reach the wi1 segment. This is not realistic, however, because it requires setting a static route for the wi1 segment on the conference WAP.

I also just renamed this article to be "The One Minute Wireless Bridge," since that is more in the spirit of what I'm doing -- providing one WAP to access another WAP.

Read More

VMWare Switch Is a Hub

While preparing materials for my new class TCP/IP Weapons School I needed to test how the virtual switch in VMware Server behaves. I started three VMs. All had lnc0 interfaces bridged to the host's physical NIC. Two VMs had IPs 192.168.2.51 and 192.168.2.52 assigned. The third VM had no IP assigned. When 192.168.2.51 pinged 192.168.2.52, the third VM was able to see the ICMP traffic. This means the virtual switch in VMware Server appears to behave like a hub. This makes monitoring traffic easier.

Read More

Bejtlich Cited in Patch Management Thesis

Dominic White cited me in his master's thesis: Limiting Vulnerability Exposure through effective Patch Management. My blog post Cool Site Unfortunately Miscategorizes Threats influenced his thinking on the terms threat, vulnerability, and risk.

Read More