ClearNet Security

To put it in simple terms I feel sorry for many businesses, especially start-up and small, which must conform to the computer and network security demands listed in some regulations. We're doing policy work for a young startup; their IT staff consists of a few developers and one outside contractor. They have been damned, err, deemed a Service Provider Level 1 entity by Visa’s CISP program. That means they'll have to spend lots of money on high maintenance activities which are usually reserved for much larger organizations.

I’m all for best practices and doing things right, but the cost of playing and doing business in this context is skyrocketing.  If I had a good business idea, I likely would feel very depressed when realizing I must combine the risks of trying something new with the enormous costs of meeting regulatory requirements.  For me, the motivation to operate securely is already there – if you fail, your company will suffer damage or be shut down.  Like with all things that go this way, we get less market choices and more expensive services.

PIX 7.x…. This long awaited release of the Cisco Firewall OS has finally been released and has had time to bake. I have had a chance to use some of its new features and definitely learned a few things. Of course the features of 7.0 were pretty large in itself with the advent of “Bridging Mode” and "Virtual Firewalls" PIX 7.0 is trying to be the all in one firewall. So when you upgrade the firewall a few things become apparent right away. First off the 7.0 command line is much more like a router than it is a traditional PIX. I think this is Cisco further assimilating the PIX technology into the Cisco technology collective. I am personally divided on this approach as it is now important to remember what mode you are in for certain commands where in the old days of PIX slinging you could execute almost all commands in the config mode. Having to traverse config levels like a router makes half your commands in a config file deal with moving around the OS and not real configuration commands.

Here is an example of old vs. new:

Changing interface details on PIX 6.x:



Changing interface details on PIX 7.x:



We had an interesting situation that would warrant the use of PIX 7.0. We had two external internet address spaces on the same physical link. Now the logistics of this project is that one space needs to be administered by one individual and the other by someone else. Now if this was the old days, it would be difficult to allow each person to administer the access list for its space only as the access lists are ultimately the same in PIX 6.x. Enter in Virtual Firewalls… Virtual firewalls was the answer here. Basically you create multiple images of the PIX OS and have each instance administered by the prospective admin. The virtual firewalls bind virtual interfaces to physical interfaces but for security they cannot affect the physical properties of the interfaces. This means that if an admin were to shutdown his virtual interface it would not affect any other virtual interface nor would it affect the physical interface. Also since each virtual firewall is separate each access list is wholly controlled by the virtual firewall admin.

Later I will show how to configure and use this virtual firewall and discuss the drawbacks of it as well.

We use 1and1 for domain registration. It is cheap. The consequence is spending 4 days attempting to contact their support (3x waiting around an hour on the phone only to get dropped), finally getting through, and then receiving the response 'We can't help you because our Administrators in the US are not available'. Lovely. 24x7 support is really 8x5 for help of any value. We'll be switching ASAP.

When I'm ready to spend money on upgrading a computer or purchasing a new one it is always tough for me to decide whether to spend the money on a high-end portable system or to keep my primary workstation in top shape. 90% of my work happens on my workstation, but when I need power on the road, it sucks to work on my antique Dell Inspiron 8100. We have run into several gigs whereby we need to have some portable powerhouses to run the tools we use at any reasonable speed. So now I'm going on the hunt for the best portable 'tools' box to run things like WebInspect, Paros, Nessus, Burp Spider, and other power hungry things. Those vendors selling the more sexy and expensive are:

• Alienware Aurora m7700 laptops
• Voodoo Laptops
• Falcon Northwest
• Hypersonic Laptops

The coolness factor is hip, for sure, but the price is steep for the models sporting workstation like performance - upwards of $5000 or more. Now, Hypersonic offers an option to airbrush your corporate logo on the top - that would be a fun prop.

By the way, these CPU charts are great to help make buying decisions: Intel CPU Chart / AMD CPU Chart.

I just spent a few minutes checking out the guest speakers for the upcoming RSA 2006 Conference in San Jose. This will be my 5th RSA Conference and I've learned it is best to create an agenda around speakers you know to be good versus picking sessions based on a title only. Regardless of topic, I like to see:

Dan Geer, Paul Kocher, Bruce Schneier, Whitfield Diffie (speaker details are here: https://cm.rsaconference.com/US06/catalog/speakers.do)

Around the beginning of 2005 Cory and I offered to help Richard Bejtlich with authoring material for his 'Extrusion Detection' book. Unfortunately our schedule got super heavy and we were unable to commit full energy to it, but I see Richard is speaking this year at RSA so hopefully we'll have a chance to meet in person.

Session topics that look interesting for 2006 are:

• Detecting Security Vulnerabilities through Automated Binary Analysis
• The Inevitability of Security at the Point of Use (Dan Geer)
• How to Break Software Security
• Managing Business Risk via Information Classification
• Beyond "Black Box" Security Penetration Testing
• Tools for Security Risk Assessments (NIST methodologies)

(session abstracts are here: https://cm.rsaconference.com/US06/catalog/eventguide/publicSchedule.jsp)

We recently performed a relatively large TCP port scan for a client; a full 65k SYN scan of ~70,000 IP addresses.  Nmap is a great port scanner and was our first choice.  We had two new and beautiful Sun quad v40z dual core opteron servers (16GB of RAM each) dedicated to the task.  We were under a restrictive change control window and time was the limiting factor.  We broke the scans down like this:

• Executed 8 unique nmap instances on each system (one for each ‘virtual’ processor)
• Divided the scans on /24 blocks (the optimal breakdown would’ve been on a 100 boundary, but we ran with this)
• Set min_hostgroup to 100 (minimum number of devices to scan in parallel)
• Set min_parallelism to 100 (minimum number or ports to scan in parallel)
• Set max_rtt_timeout to 1250 (wait a maximum of 1.25 seconds to receive a reply from a port query)
• Other command line options used (-vv: verbose, -sS: SYN Scan, -P0: no ICMP, -p: port range)

All together, a single nmap statement looked like the following:
/usr/local/bin/nmap -vv -sS -P0 -p 1-65535 -n --min_hostgroup 100 --max_rtt_timeout 1250 --min_parallelism 100 <a_/24_block>

We paid close attention to the number of outbound pps (packets per second) using iptraf for a couple reasons:  To watch our bandwidth utilizations to avoid ISP overage charges and to gain a rough baseline so we could detect a problem.

If I remember right, the outbound pps initially was between 2k and 4k per server.  Things were rocking and it looked like we would sail through the port scans.  Alas, when doing a quick check after ~30 hours of scanning, we noticed the pps had slowed to ~550 per server.  We deduced nmap had some memory management issues when used the way we crafted.  Each nmap instance was consuming ~1.2GBytes of RAM, appeared to be increasing, and the CPU idle time for all processors was a continuous 0.  This caught us off guard somewhat because we had successfully performed an nmap TCP services scan (~1668 ports) of the 70,000 IP addresses in less than 40 hours.  This was all on SuSE Linux Enterprise Server 9 (x86_64) with nmap version 3.93.  We knew now this was not going to be easy.  The number of SYN requests to do this is big, roughly:  65,535 hosts x 65535 ports x 2 (number of port query attempts) = 8,589,672,450 outbound SYN packets.  If we could sustain ~3,500 outbound pps on each server, then we could finish in approximately 15 days (within the change control window).  At 1,100 total pps, it is ~90 days, ouch! 

In the mix of this engagement, there was a timely posting on the network security pen-test newsgroup asking about scanning a large network with nmap in which I posted a reply.  I subsequently received a response from Fyodor (the author of nmap) which not only confirmed our experiences but also contained a link to an updated version to better enable nmap to handle this scenario (thanks Fyodor!!).  I haven’t had a chance to use this updated version yet, but I’m excited to check it out.  Also I am going to explore some home grown scanners we used while building a vulnerability scan engine and play around with the scanrand and unicorn scanners.  This ended up being a great experience and a wake-up call to verify the tools we depend on work at the scale we need before accepting the next job.

A while back, I knew a couple friends in a somewhat compromised situation. They had been breaking the rules and running LC5 at work and were running the risk of getting caught, being sued and maybe worse. Due to some scheduling mishaps, they found themselves with a program running on a machine they no longer had access to clean up. I won’t get into the specifics just: don’t do that. It’s unethical and once you’re upset enough to do something like that at work you should just quit because you’re not going to learn anything that will make you happy. Worse, rather than control your own destiny you risk getting terminated and like I said before, maybe a lot worse and there is no way having that on your record or in your past makes you a more desirable IT professional to employ. . 

LC5 is Symantec's password cracker, originally developed by l0pht which was acquired by @stake and then eventually @stake was bought by Symantec.  LC5 is frightening, it can sniff LM hashes off the wire and crack them at frightening rate. If you don't have the 10 to 20 hours to wait for the brute force on an old computer, you can pay to use someone's rainbow tables or create your own and "recover passwords" much much more quickly. There is nothing terribly complex or difficult to understand about how LC5 works, it has a set of tools for capturing windows password hashes either from the local machine or as they cross the network and then it has a set of tools for finding a password that creates the same hash either by brute force or by looking it up in a database. There are free tools that are similar for cracking password hashes, such as ophcrack.  

A more captivating problem is how do you actually capture the password hashes in the first place and do so undetected. Now this is all hypothetical but how difficult is it to capture a stream of data which may contain password hashes and then replay it back through LC5?

Screenshots of LC5: