I'm sure you've heard the saying "you wouldn't buy a car that had the hood sealed shut would you?" - Followed up by an open source zealot fanatic person explaining to you why that analogy works for software. Well I actually do agree with that analogy. Anton Chuvakin put it into better words then I ever could in this blog post.
Every single day very large and important organizations rely on software to keep themselves running (hospitals, infrastructure control, intelligence agencies, the military ... and so on). Yet nearly none of these organizations are legally allowed to see the source code of that software. There is just absolute blind trust in its ability to work correctly and be reliable. Not to mention secure.
Where is the proof this software isn't full of backdoors, vulnerabilities, logic bugs or more. Organizations such as those above need to start asking (demanding) their vendors provide some real proof that the source code or binary was audited by a third party - i.e. not the original developers of the software. This proof works both ways. It gives the company the chance to say "hey - we can't catch all the bugs, but we did our best, and thats why you should choose us over our competition". And customers are given a little more trust in the investment they just made. Because now they know their vendor went further then the competition to produce a better quality product.
Lets take Windows Vista for example - many hackers have audited its source code on while on Microsoft's payroll. This is a good thing, and Microsoft can now say to customers "YES we did audit our code after development". Which is a lot more then most other vendors out there can say. The flip side to this argument is open source. Just because the source is open doesn't mean people have reviewed it for vulnerabilities (download a random sourceforge project and you will understand what I mean). But on the other hand, it does give the customer/user the ability to inspect the software they are relying so heavily on.
How many of you can honestly say the software products your company relies on have been audited by a third party?
With high profile VMWare vulnerabilities just hitting the news its easy to find some mainstream articles covering the subject. This post isn't about hypervisor rootkits (because were all tired of hearing about that), but more about the assumption in corporations and academia that (virtualization == security). This is just plain WRONG. Virtualization environments are extremely complex pieces of software - and with complexity comes insecurity. In fact I would venture as far as to say that by default (virtualization == insecurity); running two operating systems within the same machine just creates more attack surface. Considering the high degree of interaction the host and guest OS must have you inherently create greater possibility of vulnerability then if they were on separate hardware. And just because VM's are easy to create and re-create doesn't mean they shouldn't be secured as well. As we have seen from this latest VMWare vulnerability, theres always the possibility your guest VM can compromise your host OS. It should also be noted that once the host OS has been hijacked ALL of your guest VM's should be considered compromised and untrusted. In order for the attacker to completely own your virtualization environment he/she has to know exactly what host OS is being used. There needs to be more fool-proof research into this area before wide spread panic can begin. There will also hopefully be more utilization of the host OS/virtualizer as an Virtual IDS (VIDS) of sorts - to tell us when our virtual machines have been compromised. This use hasnlt been explored enough in my opinion.
Now its true some virtualization technologies were designed with security in mind and others were meant to increase efficiency and productivity of hardware. This fact should be noted when trying to decide which virtualization strategy to use. But companies should also be aware of the security issues they may be introducing by improperly implementing a virtualization strategy as they may be causing more harm then its worth.
I just read a pretty good presentation by FX (Felix Lindner) called "Security and Attack Surface of Modern Applications". He presented it at HITB 2007 (I did not attend). As FX describes it his presentation is not about hex and 0day ;( but more about how security problems are not being fixed and things are rapidly progressing down hill. He makes some very good points such as "Respect that software is there to solve real problems for people, security isn’t one of them. ". And this is very true, the security community tends to forget this detail most of the time. His presentation has some excellent numbers associated with vulnerability classes and what attackers focused on since the late nineties to today.
One subject he touches on which is of interest to me is perimeter security. While its true most attackers focus on client side exploits today, perimeter security should not be forgotten just because we tunnel %50 of our applications over HTTP. Client side exploits allow attackers to create larger botnets. But client side vulnerabilities aren't always the first pick in a targeted attack. Well they can be (MS Office parsing vulns - google for what I mean). But targeted attacks can involve something specific to that target, a mis-configured web server or email server etc... To FX's point, combining all of these different technologies (VPN Termination, LDAP, SSL etc) into the firewall is _not_ the way to do perimeter security. Defense in depth is still entirely relevant and will be for a long time to come. And if done correctly, at the very least, can stop some successful client side exploits from calling home, which can minimize their impact to your network.
On slide 13 FX also talks about 'Skill and Time'. He seems to put far more skill+time on finding vulnerabilities as opposed to writing exploits, which he states 'requires little skills but quite some time'. Im not sure how I feel about that slide yet. Others certainly do not agree with him.
I recommend reading it. You can grab FX's presentation and others from HITB 2007 here
(FX's take on the 'self defending network' is priceless)
**Update: New version is out (v06), supports a fuzzing template file - source is hereIts a very basic C program that utilizes the libnetfilter_queue library to turn any networked application into a fuzzer. It basically works like this:
- You set a specific iptables QUEUE rule like so:
$iptables -A OUTPUT -p tcp --dport 110 -j QUEUE
- Start it like so:
'$./quefuzz -a -v -c USER'
or
'$./quefuzz -b -v -f 3'
- Open your POP3 client and connect to the POP server you want to fuzz
- QueFuzz picks up your packets using libnetfilter_queue, fuzzes them and sends them on the wire
This works with any protocol/port. If netfilter/iptables can queue it, QueFuzz can fuzz it.
QueFuzz has no protocol awareness, it expects to receive a proper packet. It has minimal command line flags such as whether or not the protocol you want to fuzz is binary or ascii, or both. If the protocol is TCP or UDP, QueFuzz will skip those headers appropriately and start fuzzing the packet data. If the protocol is not TCP or UDP then it starts fuzzing immediately after the IP header.
A lot of work is needed on the tool. It was never meant to be protocol aware or intelligent, but it could certainly be cleaner. It is BETA code at best, so use at your own risk. I can guarantee its full of bugs (probably some bad ones) - so be careful! I literally whipped it up in a couple of hours. Ill be refining it over the next few weeks and releasing updates. Feel free to send me patches and suggestions by email.
QueFuzz is released under the GPLv2 as is libnetfilter_queue. Some checksum routines are released under BSD-3 license from various sources.
You can download the beta code here Enjoy
I just had to blog on how much I love ngrep. Despite all the advances in security, we are still left with a huge problem called data leakage. If you work in any type of operational security role, its one of your worst nightmares. I have used ngrep for a couple of years, as I'm sure most of you have too. I had a (legal) need for ngrep again over the past week while trying to assess the state of security in a specific network I protect and monitor and I thought I would post some of my more use-able ngrep queries for you. I am not a regular expression guru like some people I know, sorry.
Looking for social security numbers:
$ngrep -q -d eth0 -w '[0-9]{3}\-[0-9]{2}\-[0-9]{4}'
Almost the same as above but searching for credit card number patterns (this one can lead some false positives if searching through http conversations):
$ngrep -q -d eth0 '[0-9]{4}\-[0-9]{4}\-[0-9]{4}\-[0-9]{4}'
Looking for 'password=':
$ngrep -q -d eth0 -i 'password='
Some storm worm executable names (this could be expanded easily):
ngrep -q -d eth0 -i '(ecard|postcard|youtube|FullClip|MoreHere|FullVideo|greeting|ClickHere|NFLSeasonTracker).exe' 'port 80'
Detect an HTTP connection to a server by IP address not FQDN (this is how bleedingthreats new storm worm download rules look):
ngrep -q -d eth0 -i 'Host\: [0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' 'port 80'
Look for basic http login:
ngrep -q -d eth0 -i 'Authorization: Basic' 'port 80'
These are just smaller examples of what expensive 'data leak prevention' boxes do. Hopefully they perform the regular expression look ups on reassembled packet flows, not individual packets. Otherwise its a waste of time as the data can be chunked up between different packets. Data leakage continues to be an issue to this day. And unfortunately I don't see it going away anytime soon. And thats mostly because its a human problem, and user education is a loosing battle : \
Sorry this post was soooo 2001 - please resist the urge to remove me from your RSS reader
