0xC0DE Shop

SANS Security Laboratory

Stephen Northcutt at the SANS Technology Institute is running a series of interviews and articles under the "Security Laboratory" banner. He's assembled a lot of very interesting material that is not only educational, but also provides an excellent picture of the diversity of the information security field. While you're perusing the site you might notice that last week he published an interview with yours truly on database encryption in the Security Laboratory: Thought Leaders series.

March OWASP News

A couple of OWASP related announcements:

Summer of Code 2008

The Summer of Code 2008 is soliciting application proposals. From the press release: "The SoC 2008 is an open sponsorship program where participants/developers are paid to work on OWASP (and web security) related projects." March 25 is the deadline for project applications. Check out the site and submit a proposal!

Eugene Meeting

Our next meeting is next week, Wednesday, March 26, 6:00pm-8:00pm at Symantec in the Vista Room (no relation to the OS). The address is 555 International Way, Springfield, OR. The topic is "Defending Against Cross-Site Scripting." Read more about the meeting at OWASP's Eugene Chapter site.

SAO Meeting Tonight

If you're a software or technology professional in Lane County, come on by the Software Association of Oregon's Lane County Chapter meeting this evening. As described in the press release, Dan White, the CTO of Pipeworks Software will be speaking. Pipeworks is part of Foundation 9 Entertainment, the largest independent game developer in North America. Should be an interesting talk. I wonder what they're doing for security? If you're in the area, come on by and meet more of your local colleagues.

The Risks of Risk

A while ago I wrote about my concern that introducing the idea of risk into information security discussions too often leads to more analysis rather than productive action.

Over at BlogInfoSec.com Frank Cassano echoes similar thoughts: "The biggest mistake risk management professionals make today is that they over think their programs and forget the core truth of risk, stay alive." He describes how risk management pros can get caught up in "endless analysis" and not get on with the business of keeping the business alive.

It's the first post in "The Risk Rack" column, and I'm interested in seeing where he takes it.

Fraud and Network Monitoring

Richard Bejtlich writes about fraud, waste, and abuse (FWA) being beyond the purview of network security monitoring. I tend to agree, but the situation, as Bejtlich notes, isn't clear cut.

It is important to keep in mind that part of the reason organizations fund information security departments is to help with fraud, waste, and abuse as well as "sexier" problems such as espionage, theft, and destruction. As I've written previously, information security should focus on preventing and detecting unauthorized access. When fraud, waste, or abuse is carried out by gaining and exploiting unauthorized access, then the organization should rightfully expect the security monitoring team to detect it and alert the incident response or investigation team.

However, detecting FWA carried out by folks using authorized access in inappropriate ways is typically beyond the capabilities of most security monitoring teams. Expecting your monitoring team to detect improper entries in an expense report is rather unreasonable.

XKCD

I know these are a bit old, but I still like them.

364: Promiscuous key use...

327: Little Bobby Tables...

Email Recycling

For a good number of us, a large part of our online identity is tied to our email address. Many places use email addresses as account names or identifiers, and for the most part this works fairly well. As time goes on, though, we tend to leave behind us a trail of email addresses that we no longer own.

We move from one ISP to another, we graduate from schools, change jobs, join and quite organizations. Email addresses come and go, and we generally manage just fine. What happens, though, when those email addresses are recycled? For instance, perhaps you were [email protected]; when will that email address be assigned to a new student?

This becomes a concern when you consider that password reset functionality often uses access to your email as de facto authentication. That is, when you tell a web site that you've forgotten your password, it will send a "reset" code to your (previously entered) email address. Using that reset code gives you full access to your account. Or it gives whomever now owns that email address full access to your account.

Here's some FUD to sleep on:

How much spam today is geared to watch for "abandoned" accounts? Email that is sent to an account that does not exist will often generate a bounce telling the sender that delivery failed. Email addressed to an actual account, barring gateway spam filters, does not generate a bounce. A spammer could watch the bounce backs his spam generates (through a bot, of course), and when an account that never generated bounces before suddenly starts bouncing his email, he might conclude that the account has been canceled.

The spammer could then try to establish a new account with that name. Or perhaps the domain expired and the spammer buys it and reinstates the email address. If successful, the spammer now has a piece of someone else's identity. Then he starts using that email address in requests to reset passwords at major sites. Should he get lucky, he might find himself in possession of a fully functioning Amazon or eBay account complete with stored credit card numbers and 1-click-buy functionality.

$100 Q&A: How can I protect my users from having their deleted accounts hijacked?

Context: Rsnake posts about hijacking deleted accounts.

The exploit described by Rsnake depends on two bad practices:

1. New members are not guaranteed new (as in never-before-used) accounts
2. Sensitive information is not deleted when an account is deleted

The idea is that if both of those conditions hold, then an attacker might be able to create new membership requests that end up linked to already existing accounts. The attacker can then use his "new" account to access stored sensitive information.

The particular scenario Rsnake outlines involves using cross-site request forgeries to delete an account and then hijack it, but the fundamental issues are as described above. There are a few good points to discuss about this issue.

Database Encryption and Key Management, Part 1

Key management is nearly always the most difficult part of implementing any cryptosystem. As I mentioned in a previous post, encryption changes the problem of protecting a lot of secrets into the problem of protecting a single secret. That single secret is the key. If the bad guys can get your key, the game's over.

When approaching the key management problem for a database encryption system, you have to keep four requirements in mind: your system will need to store the key, use the key, back-up the key, and periodically change the key. Storage is exactly what you think. The key has to be written to a file or a database table. The trick, of course, is how to keep the key itself safe when it is stored.