SANS Network Security 2008

I will be heading to Las Vegas for SANS Network Security 2008. I will be attending Kevin Johnson's Web Application Penetration Testing In-Depth course. Johnson is of Intelguardians fame, the founder of the Basic Analysis and Security Engine project. BASE is a Snort analysis database and front end. Johnson is also the driver of Samurai, the web application penetration testing LiveCD I wish I'd had three months ago so I would not have cluttered my base OS with so many tools.

I'm psyched about going to NS2008. The last time I was in Vegas was for Black Hat 2006.

If I've met you online via Twitter or through the PaulDotCom.com IRC channel and you're going to be in Vegas, let's meet up and grab a beer. And if you're Kevin Johnson or Ed Skoudis, I've already promised you a round.

Security at your table?

Information security professionals are a disgusting lot. They chew loudly and with their mouths open. They slurp when they drink and talk with their mouths full. They make no attempts to politely cover belches and they fart at the table. They don't wash their hands before or after eating, in fact, they rarely bathe at all.

How else do we explain the fact that security is often not invited to the table? Or if they are allowed a spot at the table, it is all too often so that they can bus the dirty dishes and clean up everyone else's mess.

If your organization is serious about security, give infosec a seat at the table at the start of the project planning process. Much has been written about the cost of adding security or fixing bugs late in the software development process. This is not new information.

If your company wants to develop more secure software, bring qualified security personnel to the table during the requirements gathering phase. Ask them to contribute to the project from start to finish. They should have input every step of the way. In addition to reviewing the customer's functional requirements, they should provide input on the system's security requirements.

After requirements have been gathered, include security in the planning phase of your project. Don't just ask security to review your plans, ask them to contribute to the planning process. Invite them to the planning meetings.

Ask security to help you with testing along the way. If you have a static code analysis tool use it early and often. You may save yourself days or weeks of refactoring if you discover insecure coding techniques early in the development process. Whether you have a static code analysis tool or not, you need to include security in your code review process.

Finishing your code and handing it off to security for a comprehensive review at the end without their involvement along the way is better than nothing, but it is less than ideal. Often as a project nears completion, delivery schedules are being made. Too often these delivery schedules are made without input from the security team. Developers and their managers underestimate the amount of time that will be required to review code. Do not make this mistake in your organization. Do your code reviews along the way and include security in that process as you go.

Once your development nears completion, begin planning your application penetration test. Obviously security needs to be included in the planning for the penetration test. I recently worked an application pen test where I was tasked with testing some changes to an existing application. Testing the changed functionality required three different types of accounts, yet when I was brought in to look at it, I hadn't been given a single account in the system. Due to the nature of the application, getting accounts created and properly setup took several days. All the while the clock was ticking on a scheduled delivery date. Fortunately for this organization, the test was completed successfully a day before the scheduled delivery date.

One more thing you should know, a successful penetration test will prove that your application has security problems. A failed penetration test does not prove that the application is secure. The best chance of building secure systems is to invite security to the table early and keep them engaged throughout the process.

Don't worry, when your system is compromised and someone makes a mess of things, you can still call security to have them clean up the mess.

Touch on Windows via PowerShell

A forensic investigator recently inquired about a touch equivalent for the Windows environment. If you don't know touch is a command in the *nix environment that allows you to modify file timestamps arbitrarily.

My first thought was that maybe wmic could accomplish the task. Turns out wmic can only read timestamps, not set them.

More digging revealed that Microsoft's PowerShell could be used to modify file timestamps.

Below is the nitty and the gritty.

From within powershell:

$(Get-Item ).creationtime=$(Get-Date "mm/dd/yyyy hh:mm am/pm")
$(Get-Item ).lastaccesstime=$(Get-Date "mm/dd/yyyy hh:mm am/pm")
$(Get-Item ).lastwritetime=$(Get-Date "mm/dd/yyyy hh:mm am/pm")

There are also utc timestamp attributes (CreationTimeUtc, etc.). I
haven't touched (no pun intended) those.

Here's a sample run from my PowerShell prompt (PS>):

PS > date

Thursday, August 14, 2008 9:38:47 am

PS> echo > test.txt

PS> dir
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 8/14/2008 9:38 AM 0 test.txt

PS>$(get-item test.txt).lastwritetime=$(get-date "08/31/2012")

PS>dir
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 8/31/2012 12:00 AM 0 test.txt


You can use these commands to change timestamps such that their
CreationTime is later than their other timestamps.

Fun stuff.

Blended attacks for pen testers

When Dan Kaminsky microblogs about a security advisory, CVE-2008-3280 and says "brainmelt", you have to think it's something particularly good. He did destroy the internet after all.

If you haven't read CVE-2008-3280 it discusses findings by Ben Laurie and his team at Google in cooperation with Dr. Richard Clayton. In short, the advisory discusses awesomely powerful blended attacks that leverage Kaminsky's DNS findings and the entropy issues Debian suffered earlier this year and the lack of CRL checking by browsers. See (CVE-2008-0166).

Will this be the year of the blended attack? Recall CVE-2008-2540, the blended attack that relied on Safari's saving downloaded files to the desktop and the way Windows desktop deals with executables.

Along these lines, I am looking forward to the insights Ed Skoudis and Kevin Johnson will share at SANS Network Security 2008. Skoudis and Johnson are teaming up to deliver the keynote titled "The Ultimate Pen Test: Combining Network and Web App Techniques for World Domination."

In my own experience conducting web app pen tests, I've found command injection flaws that allowed me to execute arbitrary system commands as the Apache user. Granted running commands with Apache's privilege level isn't as good as being root (unless the box is misconfigured), but the Apache user can cat /etc/passwd, see who frequent users are via the last command, or depending on egress filtering, may be able to run traceroute from the web server to help map the network from the inside out, or download a pen tester's agent to facilitate deeper penetration. Ahem.

Or consider a web application that contains a Cross Site Request Forgery (CSRF or XSRF depending on who you ask) vulnerability. If such a flaw exists in the web based management interface for a network security device, we have a pen testing situation that will benefit from the skills of both the web app pen tester and the traditional pen tester. Sharpen your spears for a little targeted phishing. Use Google to find postings by the firewall administrator for the organization. What are the odds that admin will be logged into the firewall web gui for hours at a time each day? Craft a good email message with a tempting link for that admin, get him to click it while logged into the vulnerabe web app and you're way.

If someone like me with limited pen testing experience can think up simple ways like this to use a web app pen test as a force multiplier for a network pen test, imagine what Skoudis and Johnson, both experts in the field will have to say on the subject. Their keynote in Vegas will be one of the best infosec talks of the year.