1. The OWASP testing guide. This is without a doubt the best resource. It’s designed for the person who is actually doing the testing, and contains all the details, the explanations, and contains all the testing you can think of. The only downside is that the current version is 349 pages long. (V4 is due out very soon, and will likely be longer). This is far more detail than most people want, and far longer than what most people can handle.
2. I’ve been looking for a sort of “cliff notes” version of the testing guide for a while, and I think I’ve found one that’s workable (sort of). The OWASP Application Security Verification Standards are clearly not designed to be a comprehensive list of things to test for a web app, and doesn’t contain any of the “how” aspects of testing, but it provides a quick list of things to check. At only a few pages long it’s much easier to read, and the verification requirements themselves are even shorter. Because it also provides standard for different levels of assurance, you can decide just how important security is to this particular app and review the appropriate controls.

135 – By Category
36 – View A
31 – All
26 – Main
23 – Categorized
22 – Main View
13 – All Documents
6 – Topics
4 – By Author
3 – By Date\Ascending By Main Topic
3 – People
3 – Boots
2 – Products
2 – My View
2 – folderName
2 – CategoryView
2 – By Subject
2 – All Documents by CustomerNumber
2 – All documents
1 – XML
1 – Work Schedule
1 – viewName
1 – Transportation
1 – Stock
1 – Setup
1 – Sales Records
1 – Sales Leads
1 – Phone book
1 – My Favorites
1 – Locations
1 – Internet Profile
1 – Folder1
1 – Employees
1 – Discussion
1 – Days by Key
1 – Christmas
1 – By Category and Author
1 – By Category
1 – By category
1 – Authors
1 – All by Status & Project
1 – Open\By Project & Priority
1 – Open\By Due Date

First, a little background on geolocation for those who haven’t heard of this before:

1. Google has been collecting wifi data while doing streetview. One of the things they collect is MAC addresses of wireless networks.
2. Google, using the above MAC addresses and GPS data, is now offering a geolocation service. You just send in the MAC addresses of any wireless networks in range, and Google will helpfully tell you where you are.
3. While a browser is supposed to prompt a user before sending the MAC addresses off to Google, it is certainly possible for anyone to submit any MAC address they know of to Google. Sam Kamkar has a proof of concept for this.

The summary of the above is this: If you have a MAC address, google will tell you where it has seen that MAC address.

Now for the kicker. IPV6 autoconfig, by default, loads the mac address into the last 64 bits of the IP address. (Not directly – technically the bytes FFFE are added to the middle, and 1 bit is flipped, but this is all easily reversed. Suffice it to say obtaining a MAC address from this sort of IP address is trivial). See where this is going yet? If you want to know where an IPv6 address is located in the real world, just traceroute to the device, pull the MAC address from the device immediately prior to your target, and see if Google has a record of it. If your target is behind NAT, you can skip even this simple step. This attack is probably mostly theoretical right now since the vast majority of wireless networks are still IPv4, but if IPv6 ever does take off, this will become a real worry.

Credit where credit is due: I got this idea while watching the video of Samy Kamkar’s presentation entitled “How I met your girlfriend“. Samy goes from end to end, showing how to get a person’s real life location. He only talks about IPv4, so for the last steps he convinces the target to click a link, exploits their home router, and pulls the MAC address from there using the default credentials. I basically take this attack and consider it in the IPv6 world, where none of the technical wizardry is necessary and the attack difficulty is significantly lower.

To prove my point, I decided to look at the 10 largest banks in the US and discovered that four of the ten exhibited this flaw. (Bank of NY Mellon does not seem to have a login on their main domain, and therefore don’t utilize SSL period). One would think that for a large financial institution like one of these, getting a multiple domain certificate would be a simple task, but apparently they never thought to do it. In the mean time, they’re training their users for poor security practices.

Since this blog is coming back from a long hiatus, I think perhaps it’s appropriate to do so by bringing back an old vulnerability from a long hiatus as well. Format String Vulnerabilities have been around since around 1999. The short explanation is that when a C program doesn’t use format specifiers (you know, all those %s things you learned about way back when), but rather just prints a buffer directly, an attacker could put in format specifiers (like %x and %n). %x will just print the next hex number on the stack, so an attacker can view the stack. %n is more insidious – it is used to count the number of characters printed so far and copy that number into an arbitrary memory array. An attacker can use this to overwrite a given memory location (like, say, a return pointer) and execute arbitrary code.

In August of 2004 it was revealed that Windows’ sort.exe had a format string vulnerability. Like most people, I assumed that since the fix for this is trivial (just use a format specifier instead of printing the buffer directly), Microsoft would have fixed it in the next patch release or service pack. Lo and behold, they haven’t. This is a copy and paste from the command shell of my Windows XP machine.

 Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\>ver

Microsoft Windows XP [Version 5.1.2600]

C:\>sort %x
7c812f39The system cannot find the file specified.

C:\>sort %x%x
7c812f390The system cannot find the file specified.

C:\>sort %x%x%x
7c812f3900The system cannot find the file specified.

C:\>sort %x%x%x%x
7c812f390078257825The system cannot find the file specified.

C:\>sort %x%x%x%x%x
7c812f39007825782578257825The system cannot find the file specified.

C:\>sort %x%n

(sort.exe crashes as I’ve tried to write data to some random place in memory)

Everyone knows that Microsoft has a reputation for not fixing vulnerabilities unless forced to, but this is bad even by their standards. 4+ years and they haven’t fixed a know format string vulnerability.

]]> http://angelsofsecurity.com/blog/2009/01/26/format-string-attacks-in-windows-and-sortexe/feed/ 0 http://angelsofsecurity.com/blog/2008/07/25/dns-cache-poisoning/ http://angelsofsecurity.com/blog/2008/07/25/dns-cache-poisoning/#comments Fri, 25 Jul 2008 18:53:55 +0000 admin http://angelsofsecurity.com/blog/2008/07/25/dns-cache-poisoning/ It was of course inevitable that once Dan Geer found a vulnerability in DNS, someone else would find it too, even if Dan asked people not to publicize it. It was also inevitable that someone would quickly write a metasploit plugin for it. What amazes me is the fact that despite all the fuss over this, everyone who was security conscious should have had this problem fixed years ago. Yes, I know it was only “discovered” recently, but what people are failing to highlight is that to exploit this against a DNS server, you have to allow recursive queries from third parties. I’ve been telling my clients for years to turn that off (the ones that had it on that is). This falls under the old security rule of “if you don’t need it, turn it off”, which is perhaps the single most important, and yet often ignored, security rule there is.

Since cache poisoning became a worry it has been well known that leaving recursive queries on was allowing an attacker an avenue to force your DNS server to make specific and known queries. This is a necessary step in almost any poisoning attack. In 2007, a study found that about half the DNS servers on the net still allowed recursive queries. Even after repeated warnings and previous DNS vulnerabilities, you would think that most people would have disabled recursive queries, but it doesn’t look like that’s the case. (Furthermore, the response has universally been to patch, rather than to turn off recursive queries). The solution to this and almost all other cache poisoning attacks is very simple:

If you don’t use it, TURN IT OFF!

]]> http://angelsofsecurity.com/blog/2008/07/25/dns-cache-poisoning/feed/ 2