Kamis, 10 Mei 2007

Vulnerability-Centric Security

The vehicle pictured at left is a Mine Resistant Ambush Protected vehicle, the US Army's replacement for the Hummvee. I read about this vehicle in Army Times. That article said:

At a meeting to be held this week, according to a Pentagon source who spoke on condition of anonymity, the Army’s leadership is expected to request $9 billion for 9,000 MRAPs to be fielded through fiscal year 2008, with another 8,700 for fiscal 2009.

That's $1 million per vehicle.

I have a sinking feeling that although the new vehicle is "Mine Resistant," the "Ambush Protected" part will be tested by unpredictable, creative adversaries.

What does this teach us about digital security?

Frequently I hear people refer to the "if cars were like Windows" analogy. Let's take a look at cars and PCs, given the MRAP is really just a fancy car.

  1. A car that doesn't start may be like a PC that doesn't boot. It could be the fault of the manufacturer or the owner, depending on maintenance, etc. If it's the manufacturer's fault, they could be held responsible for the problem.

  2. A car that behaves erratically or in an unsafe manner while being driven may be like a PC that behaves erratically or crashes. It could be the fault of the manufacturer or the owner, depending on maintenance, etc. If it's the manufacturer's fault, they could be held responsible for the problem.

  3. A car that gets hit by a boulder dropped from a bridge may be like a PC that is attacked by an exploit. This is not the fault of the driver or PC operator -- it's the fault of the threat dropping the boulder and the intruder launching the exploit. (Even if the PC is not patched, it's not the victim's "fault." If you can't accept that, consider the PC fully patched and the vulnerability a zero-day.)


In cases 1 and 2, we could hold either the owner or the manufacturer responsible for the problem, depending on the circumstances. In case 3, the threat is responsible.

Unfortunately, few owners are in a position to do anything about threats. If we take a vulnerability-centric approach, we end up driving vehicles like the MRAP and building layers of security around PCs (anti-virus, network firewalls, etc.) In both cases the mitigation is costly and ultimately ineffective, because the threat remains free to devise new and ingenious ways to inflict his will against the target.

Thinking we can build "invulnerable" vehicles like the MRAP is like Bruce Schneier thinking we can build invulnerable software. Sure, you can make more attack-resistant vehicles and software, but for what cost? Ultimately the threat must be directly addressed. No one thinks the way to peace in Iraq is by giving every Iraqi a bunker in which to live and a MRAP to drive. Why do people think we can do that with software?

Rabu, 09 Mei 2007

USENIX Santa Clara Update

Last month USENIX posted details on USENIX Annual 2007 in Santa Clara, CA, 17-22 June 2007. I'll be teaching Network Security Monitoring with Open Source Tools and TCP/IP Weapons School (layers 2-3) day one and day two.

I just finished uploading my slides for the three days of training. It seemed everyone liked the NSM course, but I received feedback concerning the coverage of layer 1 in TWS. Therefore, I axed 80% of the layer 1 material (probably 50-60 slides) and created a lot more new material. Specifically, I added sections on IP protocol scanning, Cisco Discovery Protocol use and abuse, and a big section on ICMPv6 Neighbor Discovery and IPv6. These last sections are an introduction really, but it's cool to see the traffic and walk through what it all means.

I will most likely teach layers 4-7 for USENIX at USENIX Security in Boston, MA, 6-10 August 2007. I plan to update the material to cover Metasploit 3 and some of its evasion methods. I'll also cover the traffic begind the Best April Fool's Joke this year.

Register before 1 June to get the best deal.

If you can't make it to Santa Clara for TCP/IP Weapons School (Layers 2-3), I'll be teaching the same material at Techno Security 2007 a few weeks earlier in Myrtle Beach, SC. That class is filling fast though.

I hope to see you there or at another training event this year!

Web Application Security Consortium Publishes Honeypot Report

Ryan Barnett was kind enough to point me toward this announcement Distributed Open Proxy Honeypot Project Data Released. It states in part:

The Web Application Security Consortium (WASC) is pleased to announce the inital release of data collected by the Distributed Open Proxy Honeypot Project. This first release of information is for data gathered from January - April, 2007. During this timeframe, we had 7 internationally placed honeypot sensors deployed and sending their data back to our central logging host.

I recommend reading the report (it's a slide presentation) to get a sense of what these Web honeypots are seeing.

Selasa, 08 Mei 2007

Metasploit 3 on FreeBSD

I've wanted to try Metasploit 3 since it was released in late March. I noticed the metasploit/devel FreeBSD port, but it wanted me to install framework-3.0-beta-3-svn.tar.gz. I decided to install Metasploit 3 (gold) manually, using the FreeBSD port dependencies for guidance.

I installed the following via the ports tree:

  • devel/subversion

  • devel/ruby-gems

  • databases/rubygem-activerecord

  • lang/ruby18


Then I extracted the framework-3.0.tar.gz I downloaded to /usr/local/src.

When I tried to run msfweb, I got this error:

Cannot find gem for Rails ~> 1.2.2.0:
Install the missing gem with “gem install - v=1.2.2 rails”,
or change environment.rb to define RAILS_GEM_VERSION with
your desired version.

Hmm. First I decided I needed to install www/rubygem-rails, which I did. Next I looked in framework-3.0/data/msfweb/config and found environment.rb, with these lines which I added to specify 1.2.3 instead of 1.2.2:

# Specifies gem version of Rails to use when vendor/rails is not present
#RAILS_GEM_VERSION = '1.2.2' unless defined? RAILS_GEM_VERSION
RAILS_GEM_VERSION = '1.2.3' unless defined? RAILS_GEM_VERSION

Next I started msfweb and told it to bind to an IP I could reach.

neely-bsd:/usr/local/src/framework-3.0# ruby ./msfweb -a 192.168.2.9

[*] Starting msfweb v3.0 on http://192.168.2.9:55555/

=> Booting WEBrick...
=> Rails application started on http://192.168.2.9:55555
=> Ctrl-C to shutdown server; call with --help for options

When I connected to the specified IP and port with a Web browser, I was able to exploit a demo Windows target without issue. The new interface is slick. It looks like most of the evasion options are for layer 4 and higher.

Freenet6 on FreeBSD

Last year I wrote IPv6 Only FreeBSD Scenario. I described using the net/tspc2 port and registering with Hexago/Freenet6. On Friday the net/tspc2 port will be deprecated. I spoke with the port maintainer and he said that he deprecated the port because the source code was no longer available at hexago.com. I looked around and found that I could download gw6c4_2_2src.tar.gz from go6.net, an IPv6 portal sponsored by Hexago. Furthermore, I found the FreeBSD port net/freenet6 -- which appears to be the same thing as the net/tspc2 port. In fact, the net/freenet6 maintainer just updated the port to point to the go6.net download location for gw6c4_2_2src.tar.gz.

I decided to remove the net/tspc2 port from my gateway and replace it with net/freenet6.

mwmicro:/usr/local/tbz# pkg_add -v freenet6-2.1.1_6.tbz
Requested space: 154796 bytes, free space: 881494016 bytes in
/var/tmp/instmp.qCS7Fo
extract: Package name is freenet6-2.1.1_6
extract: CWD to /usr/local
extract: /usr/local/man/man5/tspc.conf.5.gz
extract: /usr/local/man/man8/tspc.8.gz
extract: /usr/local/bin/tspc
extract: /usr/local/share/examples/freenet6/tspc.conf.sample
extract: /usr/local/bin/tspc-freebsd.sh
extract: /usr/local/bin/checktunnel.sh
extract: /usr/local/etc/rc.d/freenet6.sh
extract: CWD to .
Running mtree for freenet6-2.1.1_6..
mtree -U -f +MTREE_DIRS -d -e -p /usr/local >/dev/null
Attempting to record package into /var/db/pkg/freenet6-2.1.1_6..
Package freenet6-2.1.1_6 registered in /var/db/pkg/freenet6-2.1.1_6

Now that the package is installed, please finish it with the following steps:

- Copy /usr/local/share/examples/freenet6/tspc.conf.sample to /usr/local/etc/tspc.conf
- Check the values of /usr/local/etc/tspc.conf. If you have registered at
the website, fill in your userid and password there.
- Run /usr/local/etc/rc.d/freenet6.sh to start the tunnel.
- Try to ping a IPv6 host, for example: ping6 www.jp.freebsd.org

Please note that tsps[12].freenet6.net are not in service anymore,
please use broker.freenet6.net instead.

Net/freenet6 now supports rc.subr.
Please add 'freenet6_enable="YES"' to your /etc/rc.conf to make it
start autoamtically at startup.

I made the changes as noted below to the tspc.conf file:

mwmicro:/usr/local/etc# diff -u /usr/local/share/examples/freenet6/
tspc.conf.sample /usr/local/etc/tspc.conf

--- /usr/local/share/examples/freenet6/tspc.conf.sample Sat Sep 2 16:11:17 2006
+++ /usr/local/etc/tspc.conf Tue May 8 13:38:39 2007
@@ -54,7 +54,8 @@
# your_userid means the userid you registered to the broker. The userid
# must be using only legal dns label names (eg: [a-zA-Z0-9-] ) since
# the userid is used inside your user hostname.
-userid=anonymous
+#userid=anonymous
+userid=taosecurity

#
# password:
@@ -62,7 +63,8 @@
# leave empty if userid=anonymous
# your_password means the password you have been assigned with your
# userid
-passwd=
+#passwd=
+passwd=OBSCURED

#
# Name of the script:
@@ -106,7 +108,8 @@
#
# The default value is the Freenet6 tunnel broker for
# anonymous accounts (anon.freenet6.net)
-server=anon.freenet6.net
+#server=anon.freenet6.net
+server=broker.freenet6.net

#
#
@@ -175,20 +178,20 @@
#
# host_type=host|router
# default = host.
-#host_type=router
+host_type=router

#
# prefixlen specifies the required prefix length for the TSP client
# network. Valid values are 64 or 48. 64 is for one link. 48 is for
# a whole enterprise network (65K links).
-#prefixlen=48
+prefixlen=48

#
# if_prefix is the name of the OS interface that will be configured
# with the first /64 of the received prefix from the broker and the
# router advertisement daemon is started to advertise that prefix
# on the if_prefix interface.
-#if_prefix=
+if_prefix=sf3

#
# For reverse DNS delegation of the prefix, define the following:

Next I added this

freenet6_enable="YES"

to /etc/rc.conf.

Finally I started the client.

mwmicro:/root# /usr/local/etc/rc.d/freenet6.sh start
Starting freenet6.
tspc - Tunnel Setup Protocol Client v2.1.1
Initializing (use -h for help)

Connecting to server with reliable udp
Got tunnel parameters from server, setting up local tunnel
Going daemon, check tspc.log for tunnel creation status

The client creates gif0 for use in tunneling.

mwmicro:/root# ifconfig gif0
gif0: flags=8051 mtu 1280
tunnel inet 69.143.202.28 --> 64.86.88.116
inet6 2001:5c0:8fff:fffe::5889 --> 2001:5c0:8fff:fffe::5888
prefixlen 128
inet6 fe80::204:e2ff:fe29:4c3c%gif0 prefixlen 64 scopeid 0x9

mwmicro:/root# netstat -nr -f inet6 | grep gif
default 2001:5c0:8fff:fffe::5888 UGS gif0
2001:5c0:8fff:fffe::5888 link#9 UHL gif0
fe80::%gif0/64 link#9 UC gif0
fe80::204:e2ff:fe29:4c3c%gif0 link#9 UHL lo0
ff01:9::/32 link#9 UC gif0
ff02::%gif0/32 link#9 UC gif0

With gif0 set up to tunnel IPv6 in IPv4, I was able to ping6 www.kame.net.

mwmicro:/root# ping6 -c 1 www.kame.net
PING6(56=40+8+8 bytes) 2001:5c0:8fff:fffe::5889 --> 2001:200:0:8002:203:47ff:fea5:3085
16 bytes from 2001:200:0:8002:203:47ff:fea5:3085, icmp_seq=0 hlim=49
time=228.016 ms

--- www.kame.net ping6 statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/std-dev = 228.016/228.016/228.016/0.000 ms

I was also able to ping6 www.kame.net from an IPv6-only host behind the gateway.

How about this for coolness -- this version of Freenet6 also supports working on an IPv4 client behind NAT. To test this I installed net/freenet6 on VMware, copied /usr/local/share/examples/freenet6/tspc.conf.sample to /usr/local/etc/tspc.conf, added the "enable" statement to /etc/rc.conf, and started freenet6.sh. The VM now had a tun1 interface:

tun1: flags=8051 mtu 1280
inet6 2001:5c0:8fff:ffff::133 --> 2001:5c0:8fff:ffff::132
prefixlen 128
Opened by PID 580

And this routing table:

neely-bsd# netstat -nr -f inet6 | grep tun1
default 2001:5c0:8fff:ffff::132 UGS tun1
2001:5c0:8fff:ffff::132 link#5 UHL tun1
ff01:5::/32 link#5 UC tun1
ff02::%tun1/32 link#5 UC tun1

I was able to ping6 www.kame.net.

neely-bsd# ping6 -c 2 www.kame.net
PING6(56=40+8+8 bytes) 2001:5c0:8fff:ffff::133 -->
2001:200:0:8002:203:47ff:fea5:3085
16 bytes from 2001:200:0:8002:203:47ff:fea5:3085, icmp_seq=0 hlim=50
time=295.101 ms
16 bytes from 2001:200:0:8002:203:47ff:fea5:3085, icmp_seq=1 hlim=50
time=292.508 ms

In fact, from the VM I could ping6 the gateway's public address:

neely-bsd# ping6 -c 2 2001:5c0:8fff:fffe::5889
PING6(56=40+8+8 bytes) 2001:5c0:8fff:ffff::133 -->
2001:5c0:8fff:fffe::5889
16 bytes from 2001:5c0:8fff:fffe::5889, icmp_seq=0 hlim=63
time=127.114 ms
16 bytes from 2001:5c0:8fff:fffe::5889, icmp_seq=1 hlim=63
time=132.455 m

The difference between these implementations is the encapsulation. For the gateway, Freenet6 uses IP protocol 41, like this:

richard@neely:~$ tcpdump -n -r ipv6.lpc ip proto 41

reading from file ipv6.lpc, link-type EN10MB (Ethernet)
14:14:01.775391 IP 69.143.202.28 > 64.86.88.116: IP6 2001:5c0:8fff:fffe::5889
> 2001:5c0:8fff:fffe::5888: ICMP6, neighbor solicitation, who has
2001:5c0:8fff:fffe::5888, length 24

14:14:01.838210 IP 64.86.88.116 > 69.143.202.28: IP6 2001:5c0:8fff:fffe::5888
> 2001:5c0:8fff:fffe::5889: ICMP6, neighbor advertisement, tgt is
2001:5c0:8fff:fffe::5888, length 24

14:14:17.083741 IP 69.143.202.28 > 64.86.88.116: IP6 2001:5c0:8fff:fffe::5889
> 2001:200:0:8002:203:47ff:fea5:3085: ICMP6, echo request, seq 0, length 16

14:14:17.317006 IP 64.86.88.116 > 69.143.202.28: IP6
2001:200:0:8002:203:47ff:fea5:3085 > 2001:5c0:8fff:fffe::5889:
ICMP6, echo reply, seq 0, length 16


For the client behind NAT, Freenet6 uses IPv6 in UDP port 3653. In this example I send two ICMPv6 echo packets to www.kame.net. Tshark decodes it like this:

richard@neely:~$ tshark -n -r udp.lpc udp.port==3653

1 0.000000 192.168.2.9 -> 64.86.88.117 UDP Source port: 49454
Destination port: 3653
2 0.000017 192.168.2.9 -> 64.86.88.117 UDP Source port: 49454
Destination port: 3653
3 0.051616 64.86.88.117 -> 192.168.2.9 UDP Source port: 3653
Destination port: 49454
7 0.080622 192.168.2.9 -> 64.86.88.117 UDP Source port: 49454
Destination port: 3653
8 0.080641 192.168.2.9 -> 64.86.88.117 UDP Source port: 49454
Destination port: 3653
9 0.314504 64.86.88.117 -> 192.168.2.9 UDP Source port: 3653
Destination port: 49454
10 0.947704 192.168.2.9 -> 64.86.88.117 UDP Source port: 49454
Destination port: 3653
11 0.947737 192.168.2.9 -> 64.86.88.117 UDP Source port: 49454
Destination port: 3653
12 1.175285 64.86.88.117 -> 192.168.2.9 UDP Source port: 3653
Destination port: 49454

If I tell Tshark to decode the protocol as Teredo (which implies IPv6 in UDP) I see this.

richard@neely:~$ tshark -n -r udp.lpc udp.port==3653 -d
udp.port==3653,teredo

1 0.000000 2001:5c0:8fff:ffff::133 -> 2001:5c0:8fff:ffff::132
ICMPv6 Echo request
2 0.000017 2001:5c0:8fff:ffff::133 -> 2001:5c0:8fff:ffff::132
ICMPv6 Echo request
3 0.051616 2001:5c0:8fff:ffff::132 -> 2001:5c0:8fff:ffff::133
ICMPv6 Echo reply
7 0.080622 2001:5c0:8fff:ffff::133 ->
2001:200:0:8002:203:47ff:fea5:3085 ICMPv6 Echo request
8 0.080641 2001:5c0:8fff:ffff::133 ->
2001:200:0:8002:203:47ff:fea5:3085 ICMPv6 Echo request
9 0.314504 2001:200:0:8002:203:47ff:fea5:3085 ->
2001:5c0:8fff:ffff::133 ICMPv6 Echo reply
10 0.947704 2001:5c0:8fff:ffff::133 ->
2001:200:0:8002:203:47ff:fea5:3085 ICMPv6 Echo request
11 0.947737 2001:5c0:8fff:ffff::133 ->
2001:200:0:8002:203:47ff:fea5:3085 ICMPv6 Echo request
12 1.175285 2001:200:0:8002:203:47ff:fea5:3085 ->
2001:5c0:8fff:ffff::133 ICMPv6 Echo reply

What's interesting about that is the ICMPv6 used earlier in the trace to 2001:5c0:8fff:ffff::132, the other side of the tun1 tunnel, to prepare to carry the ICMPv6 traffic to 2001:200:0:8002:203:47ff:fea5:3085 (www.kame.net), e.g.:

$ host 2001:200:0:8002:203:47ff:fea5:3085
5.8.0.3.5.a.e.f.f.f.7.4.3.0.2.0.2.0.0.8.0.0.0.0.0.0.2.0.1.0.0.2.ip6.arpa
domain name pointer orange.kame.net.

Look at that result. IPv6 is a pain.

Bejtlich on Extrusion for SearchSecurity.com

If you visit searchsecurity.com/dataprotection you'll be redirected to a new SearchSecurity School on "data protection." I was asked to create the content for the Data Leakage sections, including a Webcast that airs 0900 EDT (1300 GMT) Thursday 10 May, a podcast, a tech tip, and a quiz to test your mad extrusion skills. I didn't write the "white paper."

Minggu, 06 Mei 2007

Reviews of IT Auditing, Hacking Exposed: VoIP, and Hacking Exposed: Wireless Posted

I am happy to report that I just posted three book reviews to Amazon.com. The first is IT Auditing by Chris Davis, Mike Schiller, and Kevin Wheeler. From the four star review:

I have no experience with auditing in the formal sense described by IT Auditing. I am familiar with the technical aspects of host and network security, but I wanted to know more about the goals and views of those who audit enterprises from a security standpoint. IT Auditing succeeds when it discusses the profession of auditing but I found some of the technical details lacking. Therefore, I recommend focusing on chapters 1-3 and 12-15, while using the technical chapters as indicators for outside research.

The second book is Hacking Exposed: VoIP by David Endler and Mark Collier. This book is so much better than Practical VoIP Security it's not even funny. From my five star review:

Hacking Exposed: VoIP (HE:V) is the sort of HE book I like. It's fashionable to think HE books are only suitable for script kiddies who run tools they don't understand against vulnerable services they don't recognize. I like HE books because the good ones explain a technology from a security standpoint, how to exploit it, and how to defend it. I thought HE:V did well in all three areas, even featuring original research and experiments to document and validate the authors' claims.

The last book is Hacking Exposed: Wireless by Johnny Cache and Vincent Liu. Both are great guys, but I wrote a four star review:

When I read and reviewed Wi-Foo: The Secrets of Wireless Hacking three years ago, I was really impressed. Wi-Foo is obviously showing its age now, but a second edition is in the works. I was excited to see Hacking Exposed: Wireless (HE:W), green cover and all, because I hoped it would be just as good as Wi-Foo but covering newer topics. Overall I think the next Wi-Foo will be better than HE:W, but HE:W is currently the most up-to-date book on wireless security available.

I have more flying in store this and next month, so I expect to read and review many more books soon.