Depth Security

Obtaining Host/Domain Names Through SSL Certificates

2012-01-19T07:04:00.000-08:00

During vulnerability and penetration assessments one common beginning task is taking a given IP address space and identifying domain and host names that operate within. It's always helpful to know these names because a lot of web servers operate using host headers to direct web requests to the correct site content, i.e. you need the name to get to the right site. It's pretty easy to find a target company's domain by looking at their website or email addresses. Similarly it's pretty easy to append a "www." or "mail." to a company's domain name to find some basic host names. However, if you stopped there chances are you're missing something.

I always want to know what other domains and alternate host names are being hosted and specifically what web apps are running within those additional domain/host names. This is because I tend to get more mileage from web application vulnerabilities than I do from classic network vulnerabilities.

There are myriad ways of finding out this information. You might start with attempting zone transfers on the domains you do know to dump all host names. This rarely works so you might use a tool to identify host names based on a dictionary of potential values. This will work somewhat but those DNS records must be in your dictionary and you'll invariably miss some. For additional domain names, you might start performing reverse DNS lookups on the IP address space that's in scope for the assessment. Accurate reverse DNS zones are often not available so you might use a tool like Maltego which uses other information sources to identify those other domain names.

Yet another way of identifying straggling domain/host names is to grab SSL certificates on the network and look at the "commonName" attributes. Then you can take any new domain names identified and run them through the same process you already went through for the names you already knew. This may seem arcane but I've personally been in situations where I was unaware of a domain, obtained it through an SSL certificate, performed dictionary-based enumeration of the domain, and identified a hostname for a vulnerable web application listening on a site with host headers. The point is that I would have never known the app existed by just connecting to the web server's IP address without a name. Thorough coverage is the name of the game.

NMAP has a nice script built in to do just this:

nmap -p 443,444,8443,8080,8088 --script=ssl-cert --open A.B.C.D/XY

Tool Review - Fierce by RSnake

2011-09-27T09:15:00.000-07:00

Fierce is a simple but very useful DNS reconnaissance tool written by Robert Hansen (RSnake) that I use on virtually every pentest, vuln assessment, or application security assessment I'm involved in. There's nothing fancy or super-technical about this tool; it's just useful and deserves some mention. It combines the functionality of a handful of recon tools into one. It's original purpose was to identify targets for blind pentests for which the address space of the target is not known. However, it's also great way to enumerate DNS records on targets for which you do know the address space.

Fierce first identifies authoritative DNS servers for the target domain specified. The next thing it attempts is a zone transfer, or, a dump of all domain records from each authoritative DNS server. While nice (from a pen-tester's perspective), anonymous DNS zone transfers are rarely allowed these days.

If zone transfer fails then the real usefulness of Fierce becomes apparent. Fierce next brute-force DNS records using a dictionary of common hostnames. This will find DNS records such as www.depthsecurity.com, dev01.depthsecurity.com, cctv.depthsecurity.com and the like. There are other tools that do this but Fierce comes with an already-decent dictionary and does so much more. The real benefit of this, in my opinion, is finding host header names. When multiple, unique websites share the same IP address and port, a port scan will simply identify the single HTTP instance as open. Without the individual websites' hostnames, a pentester will miss the potentially vulnerable code/content of all those websites.

Fierce also has some interesting reverse DNS lookup options. Specifying the "-wide" option will cause Fierce to query PTR records for the entire class C space of any unique /24-bit networks it identifies.

Using the "-range" option along with either the "-dnsserver" or "-dnsfile" will perform reverse lookups for the range specified using the DNS server(s) included.

New Details on CitiGroup Compromise

2011-06-14T19:11:00.000-07:00

The Daily Mail has a short article about how the recent compromise of 200,000+ Citigroup accounts occurred. Of course there is not much technical detail but the vulnerability and exploit are pretty obvious if what the article says is correct:

"They simply logged on to the part of the group's site reserved for credit card customers - and substituted their account numbers which appeared in the browser's address bar with other numbers."

Seriously? This sounds like a plain old parameter tampering attack (forceful browsing, or whatever you want to call it). This wasn't even SQL injection which is easy enough. Even worse than that, the parameter in question sounds like it was an account number and that it was included in the URL of the request rather than within the body in a POST request. Straight out of Hacme Bank:

This attack might sound complicated to the masses who may not be familiar with application security but I assure you it is not. It's one of those "attacks" that anyone with basic knowledge of a browser is capable of successfully pulling off. It's an attack so easy that it almost gives some level of credibility to the way Hollywood portrays "hackers." I just change:

http://www.depthsecuritybank.com/home/?acct=MY_ACCOUNT_NUMBER

http://www.depthsecuritybank.com/home/?acct=YOUR_ACCOUNT_NUMBER

I guess I'm not that surprised since I continually run across applications in 2011 that are still vulnerable in a 1999 sort of way. So fair enough, it was an obvious vulnerability just waiting to be exploited by someone who noticed it. But wait, the article then contradicts itself by quoting an "expert" who is "part of the investigation." "He said: 'It would have been hard to prepare for this type of vulnerability.'" That's nonsense. The article also begins with, "It has been called 'one of the most brazen bank hacking attacks' in recent years." Brazen like fuzzing a small integer parameter in a URL until you harvest 200 thousand accounts? I guess so but maybe damaging was the adjective they should have used.

You don't "prepare" for vulnerabilities; you securely code your applications so that they don't contain them. You assume developers are going to create security flaws so you continually assess the security of sensitive applications to find and fix these vulnerabilities, especially low-hanging fruit like this one.

Ironically, this is one of those types of vulnerabilities that's all but impossible for an automated web application vulnerability scanner to find but incredibly easy for even a savvy 12-year-old to discover. Can the security of any system be guaranteed? No way. Can a large bank be expected to prevent these types of vulnerabilities and compromises? Yep.

Some advice to avoid this type of an issue follows:

Enforce authorization for every user request. When a user associated with account 0000001 makes a request for account 0256022, politely decline with a generic error message.
Don't use direct object references whenever possible. Retrieve information like account numbers by accessing users' session objects rather than requiring that they be sent to the server. Think about it, why take from the user what you can get with a higher level of reliability from the server or database? If an 'id' is necessary for some reason then map a temporary value to the account number rather than using the actual account number in users' requests.
Don't send sensitive information in the URL of a request. When in doubt, send parameters within the body of a POST request. This won't protect you from this type of attack but it makes the flaw slightly less obvious.

How to Get Properly Owned

2011-05-20T11:43:00.000-07:00

Here is some sage advice on how to be quickly and effectively compromised:

Expose unnecessary ports via NAT and firewall rules to your DMZ. I'm talking SSH, telnet, HTTP/S, SNMP, MS-SQL, MySQL, YourSQL, NetBIOS.... everything. If you're really serious about getting compromised, NAT public addresses to your internal Active Directory servers and database.If you don't have a firewall or a DMZ, all the better.
Make sure no effective firewall policies exist between networks of different types like Users > Servers or DMZ > databases. Such policies cause network connectivity issues and make troubleshooting take an extra second or two. Just put them all on one VLAN. Use VLAN 1 because it's easy to remember. For instance, you only have one brain, you probably only had one sandwich today, and it also exactly one half of two. VLAN 1 is not the default native VLAN for naught; use it.
Never patch any software. Pay particular attention to avoid checking for patches pertaining to commercial, off-the-shelf web applications or web application/server platforms. Flash and other Adobe products never need patching.
Do not perform network or web application security assessments. If you've had one performed before but your network/applications have changed significantly, rest assured that the last assessment covers your now completely different, current security posture.
Do not enforce password complexity or password change/age policies on users. If it is necessary to do so, ensure you exempt higher-ups like CEOs, CFOs, COOs, and the like when they complain about the policies. They can always be trusted to create a secure password on their own volition, plus no attacker would want access to their accounts anyway.
Conduct regular security awareness training for your users encouraging them to share passwords among the various applications they use like FaceBook, Amazon, eBay, PayPal, and Twitter. It makes it easier for them to stay logged in and avoids help desk calls for password resets.
Always leave default passwords the same. Some good username/password combinations are admin/admin, cisco/cisco, root/root, it's all secure enough.
If you use WEP for wireless encryption, make sure you keep using it. If you use WPA-PSK, make sure the key is simple and never changes. You might check the /pentest/passwords/wordlists/ dictionaries in BackTrack for some examples of PSKs to use. If you use 802.1x, make sure and uncheck "Validate Certificate Authority" and again, make sure no password complexity policies are enforced. Never concern yourself about rogue wireless access points that may be bleeding internal network access out into your parking-lot and surrounding streets. You want good coverage.
No matter the source, whether it be a website or an email from ch35pv!4gRa@spambot.cn, always click a link if it sounds interesting. If the description above the link seems seedy, invokes emotion, makes a pop culture reference, or expounds a deal that seems too good to be true, click it last year. Use that index finger.
Ignore all software and browser security warnings. They are simply a nuisance and you should click "run" when it says "warning" and "accept certificate" when it says "certificate cannot be verified."
Never run AntiVirus and if you do make sure you disable auto-update for virus definitions. Having a larger virus definitions file slows down your system. On the topic, always disable Auto-update features on all software.
Leave all switch ports that support dynamic trunking protocol in desirable mode if they are not being used as trunks. Ensure that VTP is used so that it's easy for a single switch to push VLAN database updates to all other switches in the VTP domain. While you're at it, enable CDP network-wide.
Disable SSL always; it's CPU intensive. If you must use SSL, use untrusted, self-signed certificates. It saves money and time.
Enable anonymous zone transfers on your external DNS servers. This makes it easier to find all of those pesky old hostnames like dev1.yourcompany.com and old_vulnerable_app.yourbusiness.org that might not otherwise be discoverable.

Blind SQL Injection & BurpSuite - Like a Boss

2011-04-22T12:54:00.000-07:00

Data extraction with SQL injection used to be a lot easier a few years ago when it was less known, web application security was less mature, and errors were often exposed. It's very easy to use a variety of methods to cause errors to display database names, table names, column names, and even row values... when errors are enabled. These days, the SQL injection flaws that I am finding are largely of the "blind" type. To take a rough guess, I'd estimate this to be the case at least 8 out of 10 times. That is fine because blind SQL injection is still relatively easy to exploit.... with SQL injection in general still being used to great success in the wild.

There are plenty of SQL Injection tools out there that will work with blind or error-based vulnerabilities. Many of these are installed and ready to run on the BackTrack 4 R2. SQLMap is a good one but there are a lot and your success will vary. These tools can do more than just extract database data. They can get you root. Sometimes this just isn't in the cards for a variety of reasons and you just want to show proof of concept that you can pull back sensitive data through the web server. I love Burp's Intruder tool for this. I'll demonstrate some techniques below and use HacmeBank as a target even though errors are completely visible in this purposefully vulnerable app and blind techniques are not necessary.

The first thing we do is identify the vulnerable request:

We can send this request to the Repeater tool and inject the SQL syntax, " ' waitfor delay '0:0:30'-- " (omit the double quotes). The vulnerable web application will pass this SQL command directly to the login query causing a 30-second pause.

That's all just great but we want to do better than just pause the database during our login query. Let's set the HTTP timeout length from 60 seconds to 29 seconds in Burp's timeout options.

Ok, now we'll send our delay injection request over to the Intruder tool. This time the SQL syntax, " 'if (len(user)=1) waitfor delay '00:00:30'-- ." It's also necessary to now mark our payload position in Intruder. Put it where the "1" is.

Now that the payload position is marked, we need to define the payload. The SQL question is "How long is the USER variable?" Using a numeric payload, we'll guess 1 through 30, a wide margin indeed.

One more thing to do is to set the Intruder threads to 1, otherwise when one thread delays the SQL database, the others will be delayed as well and false positives will abound.

Now we should get the length of the "USER" variable in the SQL server when this Intruder attack is started. When the correct payload number is guessed, the application will pause for 30 seconds, expiring our 29-second Burp timeout value.

At this point a good thing to know is what those 3 characters are that comprise the "USER" variable's length. Just open another Intruder tab and we'll change the attack quite a bit. This time the SQL syntax will be " ' if (ascii(lower(substring((user),1,1)))=100) waitfor delay '00:00:30'-- " and there are actually two changing payloads (highlighted in bold). One is the position of the character and the second is the ASCII decimal code of the character in that position.

The first payload needs to be numeric and range from 1 to 3 since we know that's the number of the character positions whose ASCII codes we want to guess.

For the next payload, we look up our ASCII codes and ponder a bit. 48-126 will get us 0-9, A-Z, and a-z. In our SQL syntax above, you'll notice that we're using the "lower()" function to reduce the number of ASCII code values to guess but our number range will include them anyway so we're not saving any time there. Since we're asking for a username, I doubt there are any special characters (32-47) in it so we'll just be lazy and use 48-126.

Running this attack should yield the three ASCII codes for the SQL "USER" variable. Sorting the results by length will put all of the 0-length, timed out, "true," responses in line.

Reading the timed out (true) values:

Payload 1 value 1 = payload 2 value 100 which is "d"
Payload 1 value 2 = payload 2 value 98 which is "b"
Payload 1 value 3 = payload 2 value 111 which is "o"

Dbo, a good proof of concept but we could have guessed it. Now let's go after some data. How about the SQL syntax, " ' if (ascii(lower(substring((select top 1 name from sysobjects where xtype=char(85) and name like '%user%'),1,1)))=100) waitfor delay '00:00:30'-- ?" This looks for a table that has the word "user" anywhere within. I'm not trying to be sneaky, and blind SQL injection is inherently not sneaky, so I'm just going to guess the length and set the first payload to 1 through 10. Hopefully the table is 10 characters or less in length. I'll keep the second payload at 48-126 (0-9, A-Z, a-z).

Running this attack should produce the ASCII codes for the first table that contains the word "user."

That looks like 102=fs, 98=b, 95=_, 117=u, 115=s, 101=e, 114=r, 115=s (fsb_users). Right on, so now we want the column names for this "fsb_users" table. For that we need to query the native Microsoft SQL "information_schema.columns" table. To do that, we'll use the following SQL syntax: " ' if (ascii(lower(substring((select top 1 column_name from information_schema.columns where table_name='fsb_users'),1,1)))=100) waitfor delay '00:00:30'-- ." Again we'll use two payloads, one for character position and the other for ASCII decimal code.

Running this attack will enumerate the first column in the "fsb_users" table.

That spells "user_id" which is not very important to me but it does mean that the syntax for the next column in the "fsb_users" table will be, " ' if (ascii(lower(substring((select top 1 column_name from information_schema.columns where table_name='fsb_users' and column_name > 'user_id'),1,1)))=100) waitfor delay '00:00:30'-- ."

Running this attack yields the second column name of the "fsb_users" table.

That's better because this looks like a column name for which I would be interested in row values. The "user_name" table can be used again, iteratively, to retrieve the third column using the following syntax, " ' if (ascii(lower(substring((select top 1 column_name from information_schema.columns where table_name='fsb_users' and column_name > 'user_name'),1,1)))=100) waitfor delay '00:00:30'-- "

However, let's take a leap of faith and guess at the password column using the "like" operative: " ' if (ascii(lower(substring((select top 1 column_name from information_schema.columns where table_name='fsb_users' and column_name like '%pass%'),1,1)))=100) waitfor delay '00:00:30'-- "

Running this will give us the name of the first column in the "fsb_users" table that contains the string, "pass."

So now we have the predictable, "password" column which we can pair with the "user_name" column to start pulling some rows out. The SQL syntax will be, " ' if (ascii(substring((select top 1 user_name from fsb_users),1,1))=100) waitfor delay '00:00:30'-- ." I took the "lower()" function out just in case the usernames are case-sensitive in the login function.

I want to make sure we account for enough characters that might comprise the first user_name value so I'll bump payload 1 up to the range, 1 - 15. We'll leave the second payload the same as before.

Running this attack should output the first "user_name" value in the "fsb_users" table.

So the first "user_name" is "Jake_Reynolds." The next query will target this user's password. The SQL syntax is, " ' if (ascii(substring((select top 1 password from fsb_users where user_name = 'Jake_Reynolds'),1,1))=100) waitfor delay '00:00:30'-- ." The payload settings can be left alone assuming the user's password is 15 characters or less in length.

Running this attack should reveal the password for the user, "Jake_Reynolds." Any web application worth it's salt is going to hash the password columns and use salt so that collision attacks are difficult. HacmeBank contains an unhashed database column. The following screenshot illustrates why you should make sure and encrypt or hash your password columns:

"Jake_Reynolds/P@55w0rd" it is then. Let's test it out of course.

Works for me. Let's take it a little further though. I have run up against web applications that filter for various SQL syntax like "select" and other basic SQL key words whilst still using vulnerable dynamic SQL statements on the back end. I've always maintained that input validation is not a very effective means of preventing SQL injection and that real remediation means changing your database access layer to use parameterized/precompiled queries.

One way I've bypassed input filters that look for common words like "if" and "select" is to create a variable, cast it as hex, and execute it. Take the following SQL syntax for instance:

" ';declare @P varchar(4000);set @P=cast(0x69662028617363696928737562737472696e67282873656c65637420746f7020312070617

373776f72642066726f6d206673625f757365727320776865726520757365725f6e616d65203d20274a6

16b655f5265796e6f6c647327292c312c3129293d313030292077616974666f722064656c6179202

730303a30303a333027 AS varchar(4000));exec(@P);-- "

The 0x69662028617363696928737562737472696e67282873656c65637420746f7020312070617

373776f72642066726f6d206673625f757365727320776865726520757365725f6e616d65203d20274a6

16b655f5265796e6f6c647327292c312c3129293d313030292077616974666f722064656c6179202

730303a30303a333027 is simply a hex-encoded version of the string, " if (ascii(substring((select top 1 password from fsb_users where user_name = 'Jake_Reynolds'),1,1))=100) waitfor delay '00:00:30' . "

One extra thing we need to do is to add payload processing rules in Intruder to hex-encode both of our payloads since they occur within the hex cast.

Now when we run this attack, we get the same results as before and we retrieve the password for "Jake_Reynolds" with one exception. Our values are now ASCII-hex-encoded values of ASCII-decimal codes.

This time, our results are hexadecimal values for our decimal ASCII codes. So if you follow it:

Payload 1 value 0x31 = 1 = Payload 2 value 0x38 0x30 = 80 = "P"
Payload 1 value 0x32 = 2 = Payload 2 value 0x36 0x34 = 64 = "@"
Payload 1 value 0x33 = 3 = Payload 2 value 0x35 0x33 = 53 = "5"

and so on until you get "P@55w0rd," an admittedly bad password to use on my precious FoundStone bank account. Anyway, that's blind, delay-based, SQL injection data extraction the hard way using BurpSuite to make it easier.

More SQL Injection: Barracuda Networks Hacked

2011-04-12T13:35:00.000-07:00

Barracuda Networks is latest on the list of security vendors/service providers to be compromised. The Malaysian group, "HMSec," used blind SQL injection to retrieve database contents including emails, CMS logins, and MD5-hashed passwords. A post on barracudalabs.com titled "Learning the Importance of WAF Technology – the Hard Way" explains that, "The Barracuda Web Application Firewall in front of the Barracuda Networks Web site was unintentionally placed in passive monitoring mode and was offline through a maintenance window that started Friday night (April 8 ) after close of business Pacific time." It goes on to state that no financial information was stored on this database and that users' password hashes were salted.

I think the title of that barracudalabs.com post is a little bit off. I think it should read, "Learning the Importance of Secure Software Development – the Hard Way." This just goes to show that WAFs, while great for certain things, are merely a secondary security control. Secure application development best practices (like not string-concatenating user input with database queries) are a primary security control. A WAF can shield certain issues from exploitation before you have a chance to fix them at their source but you should not rely on the WAF to protect you from severe flaws like SQL injection. After all, what happens when the WAF becomes disabled or gets put into monitor-only mode?

RSA Breached by Advanced Persistent Threat

2011-03-18T08:05:00.000-07:00

RSA has announced that they have been compromised by an "extremely sophisticated cyber attack" of which details are not clear. All that is known is that RSA's two-factor authentication seems to be affected. The degree to which this breach impacts their two-factor authentication solutions is not known and RSA has filed an 8-K with the SEC so don't expect too many details while the investigation is ongoing.

HBGary Incident - Anatomy of the Attack

2011-02-22T13:41:00.000-08:00

ArsTechnica has a great article that outlines the recent hack of HBGary by WikiLeaks activists. While a great read, it plays out this way:

CEO Aaron Barr decided to unmask who he thought was behind the leadership of attacks against MasterCard, Visa, and other perceived enemies of WikiLeaks.
Before unmasking this individual, Barr spilled the beans and communicated his intended actions to this person.
A custom written CMS application (http://www.hbgaryfederal.com) suffered from SQL injection, SQL injection in a URL parameter no less. This site is down now but the same exact, vulnerable, parameters are visible in Google queries (https://encrypted.google.com/search?q=inurl:http://www.hbgaryfederal.com/pages.php%3F&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a)
This was exploited and the usernames/passwords were dumped from the users table.
The passwords were hashed with MD5 but not salted so simple rainbow tables cracked some of the passwords.
One non C-level accounts cracked had SSH non-root access to support.hbgary.com.

This was elevated to root access using a known local privilege-escalation vulnerability for which written exploits were already available. Root was gained on support.hbgary.com.
Gigabytes of support and research-related information was removed promptly.

As is typical, two of the passwords cracked were the CEO's and COO's. Executives often have a rather demanding way of being exempted from password complexity policies =). To be specific, these passwords were six lower-case letters and two numbers.

Again, as is typical, these passwords were used all over the place including in Google, Twitter, and LinkedIn. Now the attackers had access to the CMS plus other applications like email.
The CEO's credentials became of use when it was noticed he was the administrator for the company's Google Apps Mail services and that access to other employees mail accounts could easily be gained by resetting their passwords. This was done to Greg Hoglund's mail account.
Greg Hoglund's account disclosed two potential root account passwords to a rootkit.com server as well as the fact that a Nokia employee had SSH access to that server. Since SSH as root wasn't allowed to the server, as it shouldn't be, the attackers still needed a non-root user to SSH with and then elevate to root. That's where some SMTP-based social engineering comes in.
The correspondence between the attacker impersonating "Greg Hoglund" and the Nokia employee with SSH pretty much tells the rest of the story.

So I guess the morals of the story are..... the same morals you'd learn from a lot of security incidents.... the same thing the security community, HBGary included, has been touting:

Assess your web applications, especially those exposed publicly. SQL injection is a serious flaw and there is no excuse in 2011 to have a single instance of it exposed to the internet.
Hash your passwords column but salt the values as well.
Patch your systems, especially those that are public. Even local privilege escalation vulnerabilities that don't seem like a threat, can be a threat.
Enforce the use of strong password complexity and change requirements, even, well, especially for V-I-Ps.
Don't reuse your passwords across organizations, applications, etc. Just don't reuse them. Don't iterate through your 5 passwords, add a number by 9 to the end, or use some ROT13 scheme that you think is going to protect one password from an attacker who owns another.
Ironically, hosting mail in the "cloud" with Google, didn't play a part in this incident. It could have been any mail system. Credentials are credentials. Reuse is Reuse. I guess it at least, by using a publicly accessible interface, allowed the attackers to skip having to visit an Exchange Server and open the MMC up.

As always, I'm not bashing on anyone. The folks at rootkit.com are no slouches, no doubt. Everyone has a vulnerability in their closet but there are lessons to be learned from candor where there is any these days.

Video: Hacking WEP-128, WPA2-PSK, and 802.1x/PEAP in Under 5 Minutes

2011-01-21T11:40:00.000-08:00

Although this doesn't prove anything that hasn't already been proven, seeing often cements belief much more effectively than reading. In this video, I compromise access to three separate wireless networks using three separate authentication and encryption schemes.

Test Networks - The Victims:

ClientCorporate: 802.1x/PEAP
ClientVendor: WPA2-PSK/AES
ClientGuest: WEP-128 PSK

Full Disclosure - This video is different than a real-world attack in the following ways:

For the 802.1x compromise, I used supplicants that are either not configured to validate the RADIUS certificate or bypassed the warning screen that discloses that the RADIUS server is serving an untrusted certificate.
Also for the 802.1x compromise I authenticated with test victim users using passwords pulled from my password list.
For the WPA compromise, I used pre-computed a hash table using CoWPAtty's "genpmk" since the SSID of a WPA network is factored into the handshake. A huge torrent exists with pre-computed hashes of the top 1000 SSID names using a very large dictionary. I didn't check, but I doubted "ClientVendor" would be included so I made my own.
Also for the WPA compromise, I used a PSK that was pulled from my password list.
I wasn't smooth enough to pull this off in one take so it's chopped up. The attacks, however, are not sped up.

Perspectives - The AP used in this video was either an attacking or victim AP depending on the attack utilized.

The DD-WRT'd Linksys wireless router I used can be considered a victim AP for the WEP and WPA-PSK attacks.
However, my AP should be considered an attacker AP for the 802.1x attack since I am actively trying to use it along with a fake RADIUS server to attract victims of the legitimate 802.1x wireless network that I am attacking.

Mitigating Wireless Risk - So what do I do about this?

WEP: Don't use WEP.
WPA-PSK: Use a complex PSK like "R$g2Gn#~qzZ4@" (rather than "MyBank123", "HomeWiFi! or "CoolDude1993"). If your PSK is in my dictionary, then I can crack your PSK.
802.1x:

Ensure a trusted RADIUS certificate is deployed, but not too trusted. An internal CA works fine as long as its root cert is in your clients cert stores.
Ensure that clients are configured to validate the RADIUS server cert as specifically as possible.
Only trust the CA that generated the cert.
Don't rely on users to get it right, use GPOs or more advanced tools that give you central administration like Juniper Odyssey Access Client.
Helpdesk and other folks commonly called on to fix wireless problems will likely resort to unchecking "Validate Server Certificate" so watch them and train them.
Ensure that your password complexity policies are sufficient on whatever credential stores the RADIUS talks to. Again, if a users' password is in my dictionary, and I obtain an MSCHAPV2 challenge/response pair from that user, I've got their credentials and access to whatever they have access to.

Tools Used / Props -

The fine tools listed below were absolutely required to make it this easy to test and penetration wireless networks. Like a lot of technology, they are very powerful and can do a lot of positive and negative things in the right (wrong) hands.

10 Security Tools You May Not Know About

2011-01-15T08:14:00.000-08:00

I figured I'd give a brief synopsis of some tools that I use fairly consistently for various types of vulnerability and penetration assessments. These utilities are all over the place in purpose so there isn't a really consistent use-case theme. My only goal for this entry is to have at least one tool in this list that the reader hasn't heard of or at least hasn't used.

Fierce: Fierce is one of the best DNS enumeration tools I've ever used. It's great for DNS servers that do not allow anonymous zone transfer as it includes dictionary-based hostname enumeration.
SSLTest:A Perl script that enumerates an HTTPS instances supported SSL versions and ciphers.
Web Developer: The best FireFox extension, hands down, for manual web application security assessments. Quick access to client-side information such as forms, cookies, images, links, JavaScript, CSS, etc.
User-Agent Switcher: Quickly switch from the default Firefox user agent, to any string you like. It's good for testing certain mobile web interfaces when you're not using a mobile simulator. It's also good to trick sites that "think" that you need IE but work 98% with Firefox.
FireBug: FireBug is a great JavaScript debugger implemented as a Firefox extension.
POW: A small, simple, light-weight web server that supports SJS dynamic pages and even database connections if you need them. It's great for quick, web-based proof-of-concept exploits. I know, I know, "Do you really want a web server running in your browser?" Well, it's enabled/disabled with a single click and, no I don't recommend you build your enterprise client portal site based on it.
DirBuster: DirBuster is a web spider and file/directory enumerator from the fine folks at OWASP. It's a Java utility that will run in Windows, OSX, Linux, whatever. It comes with some decent dictionaries and has a slick GUI interface.
BurpSuite Pro: My favorite web application security assessment tool. BurpSuite Pro is not only cheap and extensible, it has the best web proxy I've used plus a suite of other great tools. The Scanner, when used properly, is on par with the best commercial web application scanners. The Intruder tool is an easy-to-use web fuzzing tool with very powerful features. Spider is a simple web spider. Repeater is a tool to manually edit and send HTTP requests and evaluate their responses. Sequencer is a quick way of grabbing session tokens and evaluating their entropy. Decoder has common encoding/decoding/hash functions that are essential. Comparer is a tool to do a byte or word diff on two different HTTP requests or responses. Just don't be using the Spider or Scanner tool with the default form field values that this tool comes with. You'll see what I mean if you download it.
FreeRADIUS Wireless Pwnage Edition: This is a patch for FreeRADIUS that configures it for 802.1x wireless authentication and adds a log that spits out 802.1x usernames plus MSCHAPV2 challenge/response pairs which can be cracked with ASLEAP or JTR. This is a very underrated and powerful tool that, when combine with the appropriate tools and knowledge, is capable of compromising improperly configured wireless 802.1x networks.
SSLStrip: SSLStrip works as a forward web proxy watching HTTP traffic and actively rewriting HTTPS:// links to HTTP://. This allows MiTM tools like EtterCap to compromise SSL HTTP traffic without forging a certificate and creating SSL certificate errors in victims' browsers.
DD-WRT: DD-WRT enhances the capability of many home wireless routers by replacing their firmware with a more powerful Linux-derived OS. Added features include RADIUS/802.1x/EAP support, virtual wireless interfaces (multiple SSIDs), and much more.

SMS (Short Message Severance)

2011-01-06T13:33:00.000-08:00

Collin Mulliner and Nico Golde gave a very interesting SMS DOS presentation at the 27th Choas Communication Congress. The just of it is that "feature phones," cheaper, less-feature-rich phones sold by providers, as opposed to "smart phones" can accept and execute certain binary code from incoming SMS text messages. Networks often use this functionality to roll out configuration changes to their subscribers. By properly crafting the right message based on the phone manufacturer, these phones can be made to disconnect from their respective wireless network.
What's interesting is that of the 5-6 billion estimated world-wide mobile phone users, around 16% use "smart phones." That leaves a good portion of those phones, world-wide, that are likely vulnerable to this type of attack. The presenters looked up various mobile feature phone manufactures based on their market-share per global region. They then took the top 5 manufactures by market-share and bought test phones cheaply on eBay. By creating attack vector's for each manufacturer, they ensured that a quick burst of 5 SMS messages had a high likelihood of success against a given mobile phone number. While DOS is not the biggest threat facing most organizations, depending on context of course, this certainly has the possibility of disrupting communications for organizations that utilize vulnerable feature phones to any significant extent. There are a multitude of websites that allow anonymous internet users to send SMS messages to any phone number. What input validation and other security controls are in place, I do not know. Organizations also often get blocks of mobile phone numbers or even just a set of numbers with the same area code and prefix, which means if an attacker knows one number they have a high probability of easily guessing other valid mobile numbers for that same organization. Reflecting from the recent attacks by WikiLeaks supporters against organizations that were alleged to have shunned or otherwise harmed WikiLeaks, this got me thinking. Tools such as Low Orbit Ion Cannon were set up with predetermined targets on sites around the world so that unskilled WikiLeaks supporters could contribute to DDOS attacks with a single click. It would be pretty easy to do the same thing but target mobile feature phones using widely available downloadable executables, simple off-site form submissions, integrating it into botnets, smart phone applications, or even using browser technologies like Java Applets, SilverLight, or Flash. See the presentation here.

When 802.1x/PEAP/EAP-TTLS is Worse Than No Wireless Security

2010-11-19T14:00:00.000-08:00

What? How can you possibly defend the statement that 802.1x with PEAP or EAP-TTLS can be worse than open wireless with no authentication or encryption? Remember the old Cisco LEAP implementation that was vulnerable to offline brute-force attacks due to sending users' MS CHAP v2 challenge/response outside of a secure connection? Joshua Wright has documented this in detail and even wrote a very popular tool, ASLEAP to exploit the issue. ASLEAP captures MS CHAP v2 challenge/response pairs and/or can be used to crack users' passwords via dictionary attacks or even brute-force when combined with tools like John The Ripper (JTR).

A wireless network that is open with no authentication or encryption provides an attacker one thing: Network access. It's up to the attacker to then use that network access to do what he or she wants to do. That's bad enough but a network running LEAP without a sufficiently complex and uniformly enforced password complexity policy nets an attacker two things:

Network access plus
The exploited user(s) credentials, usually Active Directory

So enough about LEAP; the world moved past LEAP and on to other EAP variants such as PEAP, EAP-TTLS, and EAP-TLS that "protect" inner EAP authentication within SSL/TLS sessions. Yay, SSL saves the day. Sure, SSL provides encryption, but what's encryption worth if you're actually connected to an attacker and not your legitimate destination? That's why SSL uses trust chains and relationships to provide authentication. SSL supports user to server authentication with client certificates but that's not what I'm talking about. I'm talking about server to client authentication, which is to say, "I am indeed the server you intend to connect to and here's the certificate to prove it."

Your machine has a certificate store with certificates from trusted certificate authorities, most public, some possibly internal or intermediate. Applications that use SSL can be configured to trust all or certain authorities in the store. Properly configured at both the client and server levels, 802.1x with PEAP or EAP-TTLS is solid. Improperly configured, 802.1x using PEAP or EAP-TTLS can give an attacker internal access to your network from outside your building along with user credentials to actually login to internal network resources.

Here's how:

An attacker sets up a fake (well, real to the attacker) RADIUS instance. In this case, FreeRADIUS - Wireless Pwnage Edition is used, which is totally embarrassing to say so I'll say use FreeRADIUS WPE from now on. FreeRADIUS WPE is a patch for FreeRADIUS that configures it to automatically allow authenticators (APs) from all private address ranges, automatically accept any EAP-type, automatically accept any user credentials, and automatically log MS CHAP v2 challenges and responses.

The attacker sets up a fake AP that supports 802.1x authentication and points it to the fake RADIUS server. The attacker can impersonate a target SSID or look for SSID probes with monitoring tools like airodump-ng, kismet, kismac, netstumbler, and etc to target suspected 802.1x SSIDs. The attacker can spoof the legitimate APs MAC address if they'd like or not.

The attacker sets up in a location near users of the wireless network and waits for clients to authenticate to the fake AP and RADIUS server.

The attacker obtains user names and MSCHAPv2 challenge/response pairs.

The attacker cracks the victim users' passwords using a variety of methods.

The attacker now has not only internal, remote network access but likely has Active Directory credentials from some user. These may work on external websites, remote access VPNs, OWA, internal file shares, etc.

Here's why:

Self-signed SSL certificates that are not trusted by wireless clients are often installed on RADIUS servers in 802.1x environments. Wireless clients are then forced to trust any certificate presented to them.

802.1x supplicants (wireless clients) are often configured to not validate RADIUS server certificates.

802.1x supplicants are often configured to trust public CAs from which an attacker can obtain a fake certificate.

802.1x supplicants often prompt the user as to whether a RADIUS certificate is trustworthy. Leaving it up to the user is never a winning bet.

What to do?

If you're ok with and understanding of the overhead of managing client certificates, implement EAP-TLS as it is not vulnerable to these types of attacks.
Install a certificate signed by an internal CA that is trusted by all wireless users on the RADIUS server.
Avoid using RADIUS certificates signed by public CAs.
Enforce validation of RADIUS certificates and manually select the internal CA to be trusted. Do this centrally, via tools like Active Directory Wireless Group Policies if possible. Ensure help-desk personnel and users are not capable of modifying this configuration since it has a way of becoming disabled when people are troubleshooting wireless issues.
As always, ensure that a strong password complexity policy is uniformly applied to all users, with no exceptions.

HTTP PUT Worm Concept

2010-10-29T17:25:00.000-07:00

As a web application security assessor, I've seen my fair share of "owned" web servers. The vector and severity of these attacks vary from complete ownage via remote code execution to client ownage via SQL injection of malware content on many pages to simple hacker guest-book entries via low-hanging fruit like HTTP PUT enabled or FTP anonymous write access to the web servers' roots.

We've all heard of the infamous (and relatively harmless) Samy worm on Facebook which spread via stored cross-site scripting, the injection of malicious HTML and JavaScript that is stored and executed in every users' browser viewing the infected page. We've all heard of more complex worms that utilize remote code execution vulnerabilities, often those that have been disclosed and patched for years. But seeing backdoor ASPX or PHP pages added to a webroot via simple HTTP PUT or anonymous WebDAV method PUT (pre-IIS7) vectors made me think of an entirely different type of potential "web worm." During blackbox testing, these are often unlinked files, the existence of which is only discernible via web root dictionary-style attacks, effectively guessing the malicious file name. That is unless you have the luck of directory indexing being enabled to identify the often oddly named backdoor file.

I'll lay out some premises before discussing the concept I envision:

It's very easy / common to scan a given network for instances of web servers. This is even possible for web servers running on non-standard (8080, 8088, 8443) ports given that HTTP is an easily identifiable ASCII-based protocol.
It's very easy to ascertain the availability of anonymous PUT or WEBDAV methods by analyzing the HTTP response to requests using those methods.
Putting the prior two concepts together, it should be relatively easy on a large enough network to find several web servers that have anonymous PUT enabled. On a /16 public network these chances are huge, on a /24 internal network, these chances are reduced by some order(s) of magnitude.
Even if PUT is enabled but requires authentication, there are some username/password combinations that could be attempted with a certain, relatively low but not insignificant likelihood of success.
You can PUT a file on a web server that can have devastating effects on security as long as it is compatible with the application server(s) running. For instance, PHP servers could be affected by .PHP backdoors, classic ASP could be affected by .ASP backdoors, ASP.NET could be affected by .ASPX backdoors, Java could be affected by .JSP backdoors. By affect, I mean, remote access to the filesystem, database connection strings, command execution, etc.
These backdoor files can easily issue their own web requests using each application server's HTTP Request/Response APIs to reinfect other internal or external hosts.

With these things in mind, lets envision a web worm / backdoor / botnet hybrid with three primary components:

A spreader that executes on any given machine that is not a web server, that starts scanning for web servers with either anonymous PUT enabled or weakly authenticated PUT enabled. It then decides which application server(s) is/are installed by fingerprinting them, and thus the backdoor/worm payload out of an array of payloads to PUT on the vulnerable web servers. If successful with the PUT, it then invokes the backdoor/worm by simply requesting it, triggering an onload method or something like that to start the infected web server's nastiness.
A backdoor/worm that gets PUT to a vulnerable web server, enables remote access, but also can be made to act as a spreader, scanning for other (external OR internal) web servers with similarly vulnerable PUT options. This also writes a reference to the spreader on other pages within the web root to "spread the spreader to web users" so to speak.
A command/control web application that could either request (might as well since inbound HTTP is obviously enabled on the infected public web servers) or get polled for commands (outbound HTTP is almost universally allowed even though it's an obvious best practice to prevent it in DMZs) from internal web servers and infected spreaders. This application could collect a given set of sensitive information from each backdoor/worm or spreader in addition to assigning internal or external network segments to scan and subsequently infect.

The result could be very devastating to the Internet. You're not going to find anonymous PUT enabled on many heavily-used or popular websites, but there are plenty of web instances out there with this vulnerability. Web server uplink bandwidth is considerably higher on average than your typical bot-infected windows XP SP1 machine, which makes DDOS attacks an obvious possibility, and makes backdoored web servers perform better at infecting other external hosts than even the spreader.

The worm vector is simple, really simple, with success/failure easily determined. The web portion could be dangerous in one platform (.NET) or even more if it's designed for many platforms (.CFM, .NET, .ASP, .JSP, .PHP, .CGI, .PL, .DO, and etc). The spreader is no different as the threat increases proportionally as supported operating systems increase. This worm would be simple to stop, just disable anonymous PUT at the web server or even IPS, or require more secure PUT credentials, but how far would it get before people caught on? It seems so simple so why is it not out there?

FireSheep FF Extension Makes for Easy Session Hijacking

2010-10-27T13:54:00.000-07:00

FireSheep is a Firefox browser extension written by Eric Butler and released at Toorcon 12. It allows anyone to hijack users' sessions from a large list of popular sites including FaceBook, Google, and Salesforce. It does so by sniffing session cookies from cleartext (non-HTTPS) web connections to the target sites. It currently operates on shared-medium networks like wireless and Ethernet hubs but a little ARP-poisoning would probably make it work on most switched LANs.

Web application security best practices mandate the use of SSL for the transfer of any sensitive information and this includes session cookies. The problem is that many popular sites allow cleartext HTTP connections in addition to HTTPS connections. All it takes is one cleartext HTTP request containing a user's session cookie to impersonate that user on a site.

There have been a lot of suggestions about how to prevent one's sessions from being stolen via FireSheep or other tools that use the same attack method. ForceTLS is a Firefox extension that allows users to configure which domains they want to automatically enforce SSL connections to. Good luck to all of you IE users on that one.

I'm surprised that there haven't been more conversations about how to secure web applications to protect users from these attacks... you know... so they don't have to protect themselves. Here are a list of suggestions that web developers should follow in order to accomplish this:

If possible, only support HTTPS and make users explicitly enter https://a.b.c to access the site.
The last suggestion isn't possible due to business requirements in a lot of applications. Cleartext requests should be redirected to secure connections in this case.
Developers should ensure that sensitive cookies have their paths and domains configured such that they are only sent to URLs where session cookies are needed. For instance: Set a path of "/auth/" rather than "/" so that cookies are only sent with requests to "/auth/whatever" and not to "/javascripts/script.js."
Use "Secure" cookies so that browsers will not send them out insecure (non-HTTPS) channels.

Of course, this is all kind of a moot point since man-in-the-middle attacks succeed most of the time even in the presence of SSL. This is because users are usually willing to accept browser certificate warnings. Still, FireSheep is a very cool extension and helps shed light on a ubiquitous problem.

Super-Persistent Cookies - evercookie JavaScript API

2010-09-23T13:13:00.000-07:00

As if HTTP cookies, Local Shared Objects (Flash cookies), and web developer's understanding of them wasn't a big enough security issue, Samy Kamkar has written a JavaScript API for "virtually irrevocable persistent cookies."

Want to keep track of users even after they remove their cookies, switch browsers, clear cache, or whatever? No problem, just throw a reference to evercookie in your site's pages and you're good to go. The evercookie API will set cookies using 10 different storage mechanisms from straight-up HTTP cookies, to LSOs, to browser history, to forcefully cached, encoded PNG images, and even HTML5 storage areas.

I haven't played with it yet and I'm sure there are plenty of ways around it, but it's an interesting concept for sure.

Twitter Input Validation Issues (XSS)

2010-09-21T07:56:00.000-07:00

So someone started a re-tweet XSS worm on Twitter. They were able to embed a span class and provide an "Onmouseover" event that causes the post to be re-tweeted when hovered over. Twitter has "patched" but I still see lots of folks trying to prove them wrong.

There's some better analysis about the whole thing on Zscaler including the following JavaScript payload:

Multiple Context XSS Vector

2010-09-15T13:53:00.000-07:00

Gareth Heyes of The Spanner came up with an XSS payload that works in multiple contexts and browsers. As always mileage will vary by vector and browser but I thought it was universal/cool enough to mention.

javascript:/*--></marquee></script></title></textarea></noscript></style></xmp>">[img=1]<img -/style=-=expression&#40/*’/-/*',/**/eval(name)//);width:100%;height:100%;position:absolute;behavior:url(#default#VML);-o-link:javascript:eval(title);-o-link-source:current name=alert(1) onerror=eval(name) src=1 autofocus onfocus=eval(name) onclick=eval(name) onmouseover=eval(name) background=javascript:eval(name)//>"

Why Perform Authenticated Web Application Security Assessments?

2010-08-04T11:08:00.000-07:00

The main difference between our Basic and Standard web application security assessment services is that for Basic assessments, we only perform unauthenticated testing, unless of course we gain authenticated access through exploitation of some vulnerability. Our standard application security assessments test the application from both unauthenticated perspectives and authenticated perspectives of user roles in scope. Let's briefly describe what I mean by unauthenticated and authenticated perspectives as well as authenticated roles.

Unauthenticated: Application content (pages) available to a user without credentials e.g. /index.aspx, /products.jsp, etc
Authenticated: Content only available to a user with credentials e.g. /admin.php, /change_password.aspx, etc
Authenticated Role: A group of users with access to a particular subset of the application's entire authenticated content. For example, a "helpdesk" role might only have access to create and close tickets but a "helpdesk_manager" role might also have access to ticket reporting functionality.

While there are many reasons an organization may wish to identify vulnerabilities that exist from an unauthenticated perspective, there are many more reasons organizations should consider testing from both unauthenticated and authenticated perspectives.

One of the most compelling reasons to test from an authenticated user's perspective is that some vulnerabilities are exploitable without credentials but are only discoverable with credentials. Furthermore, a certain vulnerability may reside in a page only accessible by a certain authenticated role. Consider the following example scenarios:

SQL injection is possible within an application but only on a page that requires authentication. Without actually authenticating, an assessor would be unable to identify this major vulnerability.
A web application assigns predictable session identifier values but only sets them after successful authentication. Without authenticated testing a serious external weakness which would allow user impersonation would go unnoticed. Furthermore, since it is a best practice to only provide session IDs after successful authentication, the application would appear perfectly secure to the unauthenticated assessor.
A web application redirects users to pages that are not linked to from an unauthenticated perspective. Authorization is not enforced, allowing anyone who forcefully browses to these pages, authenticated access. Without credentials, and depending on the complexity of the pages' directory structure and file names, unauthenticated testing may very well leave this serious external weakness unrevealed.
A web application is vulnerable to cross-site request forgery (CSRF) and allows an attacker to force users to order checks to an address of the attacker's choice. Without authenticated testing, the check order functionality would not have been touched by the assessor even though CSRF is an externally-initiated attack, relying on the users' own session cookies.
A web application allows a normal authenticated user to obtain administrative user privileges based on the presence of an "admin" parameter or cookie. Without testing from both the user and administrator perspectives, this flaw may not be discovered.

Obviously a vulnerability has to be discovered before it can be exploited, but many applications have a more exposed unauthenticated attack surface due to the triviality of gaining an account. Authenticated testing may not add the same value for applications which have a small amount of users, do not have sensitive authenticated functionality, have strict out-of-band user registration, or have a high level of trust for their users. However, for those applications that do have sensitive authenticated functionality, many users, or a low level of trust for their users, authenticated testing is usually recommended.

Our Standard web application security assessment service categorizes findings based on severity and whether they are discoverable and exploitable from authenticated or unauthenticated perspectives. Authenticated testing is performed for a variety of security roles if requested, which allows us to rigorously assess applications' authorization, authentication, and session management mechanisms.

Another interesting, and sometimes confusing subject that should influence testing methodology is regulation. For example the Payment Card Industry's (PCI) Data Security Standard (DSS) mandates in 6.5 that all (internal and external) web applications are developed based on secure coding guidelines so as to prevent the ten types of vulnerabilities outlined in the Open Web Application Security Community (OWASP) Top Ten list. DSS 6.6 goes further and mandates that all publicly accessible web applications be either assessed for the presence of OWASP Top Ten vulnerabilities or actively managed by a web application firewalls that can prevent exploitation of the OWASP Top Ten vulnerabilities. An entire separate document clarifying what is meant by "Application Reviews" and "Web Application Firewalls" attempts to shed light on what testing is required for an "Application Review". It mentions that manual or automated testing may suffice but it does not spell out that unless authenticated testing is performed from multiple security roles along with unauthenticated content testing, OWASP Top Ten vulnerabilities won't be detected.

I personally think authenticated security assessments from multiple security roles is an implicit requirement in the PCI DSS (unless you deploy a WAF) given that it specifies identifying OWASP Top Ten vulnerabilities. The fact is, you can't say you tested thoroughly for vulnerabilities if you failed to test half the application's content. If I'm right, this means that companies that have purchased unauthenticated web application security assessments, knowingly or inadvertently, have not fulfilled the DSS 6.6 requirement.

Assessing the Multiple Security Postures of Targets

2010-08-04T07:40:00.000-07:00

The majority of our assessment clients choose a full-disclosure approach to security assessments. They realize that this helps us maximize results in terms of vulnerabilities discovered thus providing the most value for a given cost. Other times assessment clients are interested in zero-knowledge assessments that simulate an attack from an outside threat with minimal knowledge of a target. Although both scenarios are valid we don’t think they have to be mutually exclusive. Why not have your cake and eat it too? And with that we now offer the testing of primary and secondary security controls separately in order to gain knowledge of a target’s multiple security postures.

For example, in the realm of web application security, an example of a primary security control might be parameterized database access to prevent SQL injection attacks or strict output encoding to prevent cross-site scripting (XSS) attacks. An example of a secondary security control might be a web application firewall (WAF) that also attempts to prevent such attacks before they reach the web application. Under these circumstances, a web application security assessment might be more of an assessment of the WAF’s security posture than an assessment of the web application’s security posture. Only those attacks that are not blocked by the WAF would actually reach the web application. The results of such an assessment would likely miss flaws that reside in the actual assessment target, the web application.

“So what? That’s what the WAF is for right?” you might ask. Well…

Can your web application firewall policies become disabled inadvertently?
Could future WAF policy changes negate some WAF protection?
Could the hidden flaws in your web application be replicated by your development staff in other applications, possibly applications not protected by a WAF?
Do you have public staging and test environments also protected with the same WAF policies?
What about simple due diligence to make sure that your application defends itself?
Could new methods of attack obfuscation bypass WAF policies in the future?

I’m not saying that it isn’t important to measure the effectiveness of secondary security controls like WAFs. To the contrary, I’ve seen too many WAFs deployed in such a way that they are all but worthless. I’ve seen security personnel who were quite certain their WAF would stop my attacks during an assessment only to find out that the WAF was still in “learning mode,” the way it was left when the WAF vendor did the initial installation. The dead-bolt doesn’t help you much if you leave the key stuck in it.

What I am saying is, if it doesn’t cost any extra, why not test both primary and secondary security controls? Assess the application’s “naked” security posture without WAF protection. Then enable the WAF protection and see which vulnerabilities are still vulnerabilities. Since it doesn’t take much time to re-validate what’s already been identified, we offer this additional service to those clients who desire it for no additional charge.

This way you get a clear picture of two different application security postures, the bare application, and the application with WAF protection. You also get to measure the true effectiveness of the secondary security controls you paid so dearly for, which might actually surprise you. Finally, you can remediate vulnerabilities at their source, in your application, so that if your WAF fails or becomes disabled, your more sensitive database content stays on your side of the firewall. These flaws are then known by your development staff and best practices to prevent them are integrated into future development efforts.

This concept goes beyond application security assessments and WAFs. Consider the following scenarios:

A network vulnerability or penetration assessment will test any Intrusion Prevention System (IPS) protecting the assessment targets. Based on the client's needs, Depth Security might start the assessment exempt from preventative IPS policies to get an actual assessment of the security posture of the “naked” target hosts. Then once the "worst case scenario" results are documented, the IPS exemptions could be removed to determine which vulnerabilities are exploitable and which are mitigated by the IPS. Again, the point is to assess the "pure" security posture of the target and the "real world" security posture of the target plus any secondary security controls. For those clients with managed IPS services, this process really identifies the value (or more typically, lack thereof) that their vendor is providing. In the event that the IPS failed open or was improperly configured, the client would also have a solid idea of their network security posture without IPS protection.
A social engineering scenario is requested that targets help-desk members with phishing attacks in an attempt to obtain their credentials or other sensitive information. The first control that this assessment would test would be any anti-spam functionality. In the case that anti-spam system fails to stop the phishing emails from being delivered, the next step would be to make anti-phishing exemptions to actually test the help-desk members susceptibility to any phishing emails that might make it through anti-spam controls. The first test verifies a secondary control, anti-spam; the second test targets a primary control, help desk members’ common sense.

Thinking in terms of multiple security posture or security “states” fosters a better understanding of a target’s total vulnerabilities and the effectiveness of secondary security controls. Furthermore, this method of thinking leads to a better idea of what to expect in the event of a failure or improper configuration in these secondary security controls.