Recently in Vulnerability Management Category

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...

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...

Security Scanners Comparison Test Results | SecGuru

Why do organisations persist in comparing tools that aren't in the same market...

Lets look at this little list

We've got O/S Vulnerabilty scanners, Port scanners and Website Vulnerability scanners... how can you compare a network portscanner to a tool that looks for SQL unjection vulns in websites...

There's some information on a very nasty Solaris telnet vulnerability over at the Computer Defense blog.

Now hopefully this'll have limited impact 'cause all the solaris admins out there are running SSH already...

Doubt it though, I've heard quite a few unix/router guys argue against dropping telnet in the past, so there's probably quite a few boxes out there using it...

This advisory on Cisco's site could be very nasty.

It appears that there's a vulnerability in IOS that can be exploited by sending crafted packets, and can result in DoS or remote code execution.

If an exploit for this becomes available then expect a lot of problems...

SecuriTeam Blogs » Anonymizing RFI Attacks Through Google

Interesting post at the Securiteam blog, giving some more details on the idea of using google to hack for you by causing it to spider links which contain exploits.

Of course in addition to the RFI (remote file inclusion) vulnerabilities they're talking about, it would be possible to do SQL injection this way, although you'd need to either understand the app well before the attack or leave footprints all over the site as you work out the correct injection string.

As the comments on the blog point out, this isn't a new attack, but there is some good detail including solid information about this being exploited in the wild, which is interesting as I wasn't aware of it as anything more than a concept...

I wonder how long it is before someone tries to sue Google for "hacking their site" !

There's some more data on comparing Oracle and MS SQL server vulnerability levels over at michael Howards blog.

There's a link to a study by David Litchfield on the numbers here which pretty much comes to a similar conclusion to looking at the secunia numbers, but does a more accurate job of analysing the findings by looking at a number of sources.

The clear point to be made is that Microsoft have done a very good job on the security of MS SQL server 2005 and if someone were to ask me about a choice between these two "enterprise database" vendors in terms of security, it would be a bit of a no-brainer!

One thing you can see is that this study, whilst still coming to the same conclusion (that MS SQL server is more secure than Oracle) actually has quite different numbers from the ESG study that was quoted in Michael's earlier blog posting here

At a rough count the NGS paper lists ~58 MS SQL vulnerabilities whilst the ESG one lists less than 10 (there's no background data so it's kinda hard to tell), and a similar story for the Oracle one with well over a hundred in the NGS paper and only 70 in the ESG one.

IMO a good reason to actually dig a bit deeper on these things rather than go with something like CVE which isn't really designed for the purpose. The same result has come out but by being able to see what's being counted it becomes more believable and less likely to have people be able to argue the stats....