ClearNet Security

Back when I switched from SLS Linux to slackware about 12 years ago I learned a critical lesson: don't just screw around with your C library.

The second lesson came when I jumped ship to Redhat and ran out of disk space so I cleared out that RPM stuff in /var that was taking up a lot of room...

Now, I'm going to go ahead and throw udev in to the list of RPMs that one is not to screw with unless you've got a good backup and a few hours to kill.

We often talk about how much exploits really go for on the market; here is another data point for this topic. 

“For the current quarter, iDefense Labs will pay $10,000 for each vulnerability submission that results in the publication of a Microsoft Security Bulletin with a severity rating of critical. In order to qualify, the submission must be received by midnight EST on March 31, 2006. The $10,000 prizes will be paid out following the publication of the Microsoft Security Bulletin and will be paid in addition to any amount paid for the vulnerability when it is initially accepted.”

Wouldn’t that suck if MS decided it was really an ‘Important’ severity (i.e. not ‘Critical’) and you lose.  That could easily happen given MS’s definition of ‘Important’:

“A vulnerability whose exploitation could result in compromise of the confidentiality, integrity, or availability of users data, or of the integrity or availability of processing resources.”

Anyway, I can’t see too many holders of a valuable 0day MS exploit selling it for that price, especially if they must relegate to MS on what severity they think it is.

We are at the RSA 2006 Security Conference in San Jose and we'll be posting pictures here soon.

Update: Put a bunch of photos up on flickr from one camera. More to come.

So what can you do to set up a firewall in a more intelligent way?   First thing is, just like in coding, use some comments and documentation.  If you're blocking a host or adding a special allow rule for something, it never hurts to have a little note explaining why.    I'm going to go about this in what might  be a round about sort of way.

First, like in good programming it's nice to have single entry points and single exit points.  IPTables makes this very easy.  I use a table named "KILLED" and any traffic I wish to be blocked or some how altered in a negative way I send to this table.


/sbin/iptables --flush KILLED
/sbin/iptables -N KILLED
/sbin/iptables -I KILLED -j DROP
/sbin/iptables -I KILLED -p tcp -j REJECT --reject-with tcp-reset
/sbin/iptables -I KILLED -p udp -j REJECT --reject-with icmp-port-unreachable
/sbin/iptables -I KILLED  -j LOG --log-prefix "firewall killed   "


This creates a new table named "KILLED". The first rule I insert into it, which is the final rule in the table is to drop everything.   It's kind of a safety.  The rules that are inserted before it (which then run before it) do rejects.   Personally, I am a strong believer that you should properly terminate traffic that you reject.  When TCP traffic is dropped, the client machine continues to follow to TCP protocol and do retries which creates more traffic for you to drop.  There may be other upstream devices that maintain state and so it's nice to be a good network citizen.   I also think that DROPs do nothing to actually increase security or deny the existence of a device,  you might be able to make some sort of argument but I equate it to security through obscurity. 

So anywhere you wish to deny traffic, jump it to the "KILLED" chain and then it will be properly terminated and a log message will be created which is kind of nice for a security device.

If you are looking for an easy on-line tool to help with project management, check out Basecamp. We just subscribed to the service and setup a few of our on-going projects. It is already obvious this is going to help us communicate with each other and clients better. Click on a project you've added and you can view all the people involved, the different 'to-do' lists, message postings, recent updates, and more. You can even setup a RSS feed per project. For the price (we chose the $49 per month plan) it is a very good.

I attended a webinar Friday hosted by Watchfire which covered their web application scanner titled AppScan 6.0. The two big competitors I've run across in this space are Watchfire (formerly Sanctum) and SPI Dynamics. SPI Dynamics' web application scanner is titled WebInspect.

These scanners are great at capturing all the low-hanging fruit (i.e. vulnerabilities) if they can successfully crawl the target website. The problem, one the can cause a consultant considerable pain, is when you hit a site which uses technology that 'builds' URLs dynamically (e.g. JavaScript).

A JavaScript Example:
<script language="JavaScript">
function goToPage(element_name) {
  window.location = "http://www.mysite.com?tracking=" + getelementbyname(element_name).value;
}
</script>

As you can read above, the complete URL is generated using the value of a variable.

Let's take a quick look at a recent feature comparison from a September 2005 review of web application scanners by Secure Enterprise (link to the article)

If you look at the chart, it says all three of these scanners perform JavaScript parsing. Have you ever wondered why they don't seem to discover all the possible links in a web application? There is kind of a trick word here; can you guess which it is? It is the word 'parsing'. This is the word which makes us think these scanners can blaze through dynamic web applications. What they really mean by this is they can search through all the code and locate static URL paths like http://www.mysite.com. But, if the target site builds their entire menu system, or navigation, or forms, or whatever via JavaScript (or VBScript), then you are likely out of luck. Execution is what is needed, not just parsing. The scanner must execute code (e.g. window.location = "http://www.mysite.com?tracking=" + getelementbyname(element_name).value;) to generate all the potentially valid URL paths within an application.

Now all of these web application scanners support a work-around - what do you think that is? Here is a hint: You better have an excellent idea of how the site works and what all the application can do. The work-around is you must crawl the entire site for the scanner. No problem you say? Well, that may be true, but our experience often results in pain. Like the time we were covering for another consultant and realized we had to manually enumerate one of the largest web-based business performance management (BPM) systems on the market in two days. It was one of those types of experiences you grow stronger from.

So, if you are unfamiliar with all the different views a web application can generate and you are counting on a commericial web application scanner to do most of the heavy lifting, then be cautious. The time it would take to really do a good job may easily be 10x longer than you estimated.

Note: To be fair, WatchFire did say in their webinar they would be adding execution capabilities in their next release in 9 to 12 months. It'll be interesting to see how much they execute.

I'm catching up on the new features in Nmap 4.00 from this Security Focus interview with Fyodor. Some good things to remember:

• press [enter] anytime to get an estimate of when nmap will finish
• press 'v' anytime to enable verbose mode / press 'V' anytime to disable verbose mode
• there are now 3,153 signatures to detect an application or service (and possibly version) of a listening port
• there is a new --version-intensity option which specifies how hard nmap will interrogate a listening port
• new --badsum option which tells nmap to use invalid TCP or UDP checksums (can give you more information about a FW/IPS)
  • Here is the link to Phrack #60 which gives the why and how of this new feature (written by Ed3f)
• much faster (although this depends on things like bandwidth, latency, and which command line options you specified)
• better OS detection (uses more tests to gain accuracy)

Here is a link to the official quick list of options for Nmap 4.00