Rory.Blog

DNS vulnerability - are there any other mitigations apart from patching?

Well as I'm sure everyone is aware the details of the DNS flaw that Dan Kaminsky found have been disseminated round the 'net a bit early.

I'm not going to get into the politics of whether that's a good thing/bad thing or how urgent patching is as it's been done to death elsewhere...

I was thinking though about how it may be possible to mitigate this in other ways than patching...

Having heard the detailed explanation from matasano on the vulnerability, wouldn't it be possible to mitigate this by changing the behaviour of the authoritative name server..?

If I'm understandning things correctly as the authoritative name server for a domain you'd see a whole load of requests for invalid subdomains to your domain (eg, AAAA.MYDOMAIN.COM AAAB.MYDOMAIN.COM) and usually you just respond with NXDOMAIN. Now the attacker is relying on you responding NXDOMAIN so he can respond with the additional RR of your real website, say, WWW.MYDOMAIN.COM.

Would it be possible to change your behaviour to respond as the attacker would do with the RR for your valid hosts, so causing the caching DNS server to cache them on the first attempt and preventing the attacker from getting the incorrect entries in first..? The attacker is relying on guessing port and transaction ID so won't get there in the first attempt, so it would seem that this would potentially mitigate the problem..

That said I'm no DNS expert so this may well be off base...

More virtualization fun..

There's an interesting post at Hoffs blog around virtualization and DMZs and to what level it's "ok" to virtualize a given DMZ environment, following on from a white paper by VMware on the subject

As Hoff mentions you need to understand the wider context in any risk assessment, but I actually think that in the scenarios that VMware have painted out, I'd agree with Alessandro, that the fully collapsed DMZs talked about in the paper are a no-no.

And there's a nice risk assessment reasoning here, it's not just a "ooh hypervisors scary" kind of reaction, honest :) ..

So here's how it works. In the diagrams they've used they've laid out a picture of a number of security controls. The main one being separate firewalls segregating the Internet from each of the DMZs in turn. This would indicate to me that the risk assessment dictated that no one device should be a point of failure for the security being provided by the environment (a more cost effective, but traditionally seen as more risky design would be a single firewall with multiple interfaces, one for each network.)

So if we then introduce virtualization to this scenario then it seems that the option of a "partially collapsed" DMZ meets the security requirements as each DMZ has it's own VMware ESX instance and a compromise of the hypervisor won't result in a breach of DMZ segregation.

I think that in a lot of cases it's easy to look at virtualization as something new but it should be possible to look at the current risk appetite in an environment (are you using separate devices to segregate things, are you relying on VLAN tagging for separation) and then apply that to come up with the appropriate virtualization design.

Avoiding controls which are "designed to fail"

One of the great problems and frustrations of working in security is when those darned users don't follow the nice policies that people have spent so much time working on.

But here's the thing, security professionals actually indoctrinate users not to follow policies!

How do they do this? Well people like following patterns, and so when the pattern "It's okay not to actually follow this" is established in relation to security , people will apply that pattern the next time they run into a security policy that's potentially difficult or hard to follow.

I'm sure there's a lot of security people saying "No idea what he's talking about, all my policies were made to be followed!"....

O'Rly..

Here's an example that I'll bet is familiar to a lot of people. Password policy. Does anyone actually follow their companies password policy? I'll bet it looks something like

• Passwords must be 8 or more characters with upper, lower, numeric and special characters
• Passwords must not be based on dictionary words
• Passwords must be rotated every 30 days
• You must have a different password for every system (including not using the same passwords for personal websites
• Oh yeah and once you've got this list of 40 or so random strings that are really tricky to remember and you might not use very often, don't you dare write them down

We're setting ourselves up for failure, and study after study shows that users will write down their passwords, or use sequences or many other tricks to make them more memorable.

This example (which may be a users main interaction with "security") sets the expectation that security policies can be ignored, because they're unrealistic.

So what's the answer..

Well when designing controls, I think that it's not enough to just look at the technical security properties in abstract. We've got to consider the psychological/sociological elements of the people we're expecting to execute the controls, and maybe take a path that isn't the best abstract solution but may well be the one that will work best in real life...

After all once users are set on the path of ignoring security it becomes pretty difficult to get them back on the one true way!

When is a debian user not a debian user?

So lots of people have commented on the potentially very nasty crypto bug in OpenSSL on debian Linux (and derivatives, including Ubuntu) with the good advice of patching and regenerating your SSH keys...

Only thing is, what if you don't have access to the shell to do exactly that....? What if you don't even know you run debian Linux...?

Over the last several years there has been a proliferation of computing "appliances" which almost inevitably run a cut-down Linux underneath the main software stack and in many cases, that's going to be debian Linux.

The thing is, in some cases the vendor won't even explicitly mention what the underlying software is, so the end customer may be blissfully unaware that they have vulnerable machines...

Are we Secure yet? (Part 1)

One of the questions that a Information Security person dreads most is someone from the business asking "Are we secure?".

You can be torn between the urge to explain in detail why that question can't be easily answered and the details of the controls in place and residual risks (and sending them to sleep) or a flippant "yes" which may well come back to haunt you...

One of the reasons why the answer could be so long is the obvious question "Secure from what". A set of controls which may be reasonable tight when faced with a non-targeted threat from malware may be totally inadequate against a motivated knowledgeable insider threat.

So, perhaps one way to help is to break down the "secure" question a bit in to categories of threat.

For example: -

• Non-Targeted Threats


• Internal Targeted Threats


• External Targeted Threats

This way you can classify your controls as to how well they target each threat category, giving a better picture as to what level of risk your organisation is actually running.

Non-Targeted Threats

First off is probably the easiest one, "Non-Targeted Threats". This category includes a lot of the "traditional" threats to your security and is also probably the easiest one to mitigate, as the attacker isn't intelligently looking for a way to attack you they're just randomly interested in getting access to assets.

Examples of this category of threat are

• Malware - Most malware isn't targeted and is just looking to compromise a machine (any machine) for the purposes of using its resources or getting access to information held on it or entered into it (eg, users banking credentials).
• Laptop Thefts - The majority of laptop thefts are not targeted, they're just carried out by someone who sees the laptop as a portable asset that can be easily resold.
• Internet Attacks - A large portion of "script kiddy" style attacks again, aren't targeted at a particular company, they're just looking to compromise servers on the Internet for (mis)use.

Looking at these sample threats, we can see that it's likely that more automated controls will be effective against them. We don't need to be absolutely flawless in our execution of security to defeat them but we need to be "good enough" that the attack moves on to someone else.

So controls which are likely to be effective in this space could be :-

• A-V/Anti-Spyware - Whilst there's a diminishing return on these as attackers work harder to bypass them, signature based A-V still adds a lot of value in cutting out the "noise" of malware attacks
• Patching - Again we're not dealing with attackers who are likely to use a zero-day exploit here, so vendor patching will likely be an effective control to mitigate some of these threats.
• Laptop encryption - Whilst it could be argued that this isn't a perfect control (with the cold boot http://www.freedom-to-tinker.com/?p=1257 attacks that have emerged), it's likely to be an effective control for a random laptop theft.
• Network (and Web Application) Firewalls - Until recently you could have argued that non-targeted attacks rarely use application level techniques, the recent mass SQL Injection attack (doubtless the first of many) show that firewalling at the network and application level is necessary to keep you safe('ish) on the Internet.

So far, so good. Next up we'll look at the trickier area of Internal Targeted Threats.

The dangers of jumping to conclusions

I've been reading quite a few posts about Microsofts COFEE toolkit which seems to be designed to help forensics investigators get evidence from (presumably windows based) PCs.

It's amazing to see how many sources on the Internet took the original article here from the Seattle times and came to the conclusion that this was some magical box of tricks that would instantly bypass windows security, as opposed to just being a useful collection of forensics tools, examples of this response are here, here, here and here

Luckily someone at the Seattle Times did some follow-up with Microsoft to confirm that it's actually just a collection of forensics tools and doesn't bypass windows security here

PCI 6.6 clarification - Am I missing something?

Recently there have been some clarifications around a couple of sections of the PCI-DSS, in particular one on section 6.6 .

This update has created some comment and articles but none of the ones I've read has focused on the main point, as far as I can see...

Previously there were two options for satisfying Section 6.6

• A Code Review (either manual or tool assisted) of in-scope web applications, or
• Placement of an appropriately configured Web Application Firewall to protect the application

Now (unless I'm reading this incorrectly) there's an additional one

Completion of a manual or assisted web application vulnerability review...

The confusing part is that this third option isn't split out but is listed under the "application code review" section.

My feeling is that this'll affect a lot of merchants (and vendors) if they were planning on either spending money on WAFs or Code reviews and will now use a standard web application review (which they may already be undertaking as part of other security work....)

Another interesting point which I don't know the answer to is whether a single review which covered both penetration testing techniques and web application assessment techniques could be used to satisfy 6.6 and 11.3...