MS Giving Exploit Writers Clues To Flaws 63
In the IT trench writes "How's this for a new twist on the old responsible disclosure debate? Hackers are using clues from Microsoft's pre-patch security advisories to create and publish proof-of-concept exploits. The latest zero-day flaw in the Windows DNS Server RPC interface implementation is a perfect example of the tug-o-war within the Microsoft Security Response Center about how much information should be included in the pre-patch advisory."
When in doubt provide more information (Score:2, Interesting)
IT admins will be the most affected
Hackers that RTFM
Tick tock tick tock... (Score:1, Interesting)
How hard is it for Microsoft to push out a new update for a change this minor (and important)?
This is a critical problem for any intranet (Universities come to mind as the largest target) running Microsoft servers. And it can also affect a whole load of dedicated servers running the basic versions of Microsoft server software.
What are they waiting for?!
Remember how XP was cracked? (Score:3, Interesting)
Re:I can see open vs closed source (Score:2, Interesting)
Of course, going halfway on either ideology, closed or open source sets you up for trouble. Which is why it is a bad idea for Microsoft to release any details about their patches at all. Yes, I said it. If they are going to try and make a blackbox OS, they shouldn't do it half way.
I'd rather have half-and-half (Score:1, Interesting)
Now, it's true that it is still in the favor of the virus writers in that hardly 100% of sys admins keep up to date on this stuff (wheres the time?) but it is scary that they can exploit a specific bug base on a vague explanation in the first place..... (scary in that Windows is really that bad...)
Chaffing (Score:4, Interesting)
If they wanted to get more diabolical, they could even put some honey pots into the code itself. For example, something that emulates a buffer overflow crash when a certain malfromed word is injected. Or maybe something more tantilizing but useless like a 1 second pause in Internet explorer when a certain tag combination appears followed by a page reload to make them think IE just belched but managed to somehow recover. Hint at this in the pre-pub or leak it on the web (post it in a slashdot comment). they can validate it's existence so they believe the bug really exists too.
Each time they patch the real security hole they can preload ten new honeypots for the next round of spoofing the hackers and eradicate the old ones so it looks like they are patching real bugs and the hackers never catch on.
Why am I posting this under this parent? Well because you could only get away with this in closed source. Open source would make this a give-away.
Re:Chaffing (Score:3, Interesting)
I personally think that there are uses for both. Its natural to have both in place.
One example is if I am the Coca Cola company, and I wan't to keep the formula a secret. I might go to great lengths in securing the room, in which you can read the formula. You owuld need to know the security, in order to access it in the first place.
If I had $20,000 in cash at my house, in the basement, and not tell anyone that it is there. If I accidentally leave the door open at night, I would assume that the chances of my house being robbed, are no different then any other night.
If I decide to protect the house with some motion lights, would I not also be served better with hidden cameras to take a picture of what-ever it was that triggered the light?
If I use infra-red sensors in a room, should I also use motion detection as well? THat way any attempts at getting past the first will immediately set off the second?
Aren't all these reasonable 'security by obscurity' examples that work ok?
Re:There was already exploit code before the advis (Score:3, Interesting)
Put another way - it was actually initially discovered by the black hats, and an exploitation tool released and used, not confidentially reported to Microsoft under the "Responsible Disclosure" programme, or even publically posted to somewhere like Full-Disclosure.
The article is talking obvious stuff. Obviously lame stuff. Just saying "There's a flaw in the RPC management protocol of Windows' DNS server" is enough to clue you in, because the bug is sitting in about the first place you'd look, a nice juicy classic stack overflow. That's also absolutely critical information that is required to effectively mitigate the attacks in the wild before they get any worse, and mitigation shouldn't normally be a problem (RPC management of DNS isn't that widespread).
As a black hat, guessing details of upcoming patches by looking at the pre-patch advisories is a poor idea:
1. They'll be patched, and not even a week later if you're looking at the regular notifications. That's a pretty limited timeframe to exploit the bug.
2. Even worse, MS can push it out early if they really have to, because generally by that time the patch has already been completed for a month or so and is, in fact, sitting in testing (go ahead, check the dates on the digital signatures if you don't believe me). And the development/fixing QFE branch is quite a bit ahead of the stable GDR branch. Sometimes you find that by analysing the differences between them, interesting changes pop up.
You're better off looking at past exploits and trying variations on them, because MS have a habit of incompletely fixing a bug by fixing one code branch, but missing another closely related one on the very same page. For example, patching a length buffer overflow in the first ANIH chunk of a RIFF file, but forgetting they have another parser (that hasn't been patched) for handling subsequent ANIH chunks. (If this sounds familiar now, it should.)
You're even better off looking for novel exploits in the old-fashioned way; target any code that parses or handles data in any form that you can manipulate, figure out which of the potential targets represents the juiciest opportunity for a vector, and start either disassembling and looking for oversights, or blindly fuzzing boundary conditions and trying to make it break.
In that way you can stumble upon entirely original high-value exploits that bear little similarity to an existing issue and so are unlikely to be picked up by AV signatures or IDS until after the exploit is fairly well known or unless it hits one of the larger honeypots like dshield and they figure out what's going on.
Compare the facts: open source patching is FAST (Score:4, Interesting)
Julien Tinnes reported [immunitysec.com] it at 13:48:00 EST on December 7, 2006.
At 14:17:50 on the same day the patch [madwifi.org] was available in the main source code repository.
A little while later at 17:08:26 the vulnerability is officially confirmed [madwifi.org] by Madwifi and advisories had been prepared.
Looking downstream, the response times for an official fixes/advisories by distribution specific security teams were:
Gentoo: December 10 [gentoo.org]
SUSE: Confirmed December 8 [novell.com], Fixed December 11 [novell.com]
Ubuntu: January 9 [ubuntu.com]
There is certainly some room for improvement here with distribution specific fixes, but that also includes time spent testing the changes to the driver. To be fair to Microsoft (actually, I'm just being overly optimistic), they probably had a patch ready within 30 minutes of the initial vulnerability report as was the case with Madwifi. But instead of giving the customer the option of trying the "beta" patch so they can test it themselves, it is kept private. Days tick by at Microsoft HQ and nothing appears to happen. Eventually, a patch is released on the patch Tuesday of the next month (or the month after that). System administrators get no choice and no chance to test it themselves.
Re:Chaffing (Score:4, Interesting)
Having an element or elements in your security setup which are irregular is a good part of a complete security picture, but don't for a moment assume that these will even slow down someone who knows what to do and is determined to get into your network. Only real security measures will do that. If you leave an unsecured FTP server on port 12056 facing the internet, someone will eventually find it and exploit it. If you leave phpmyadmin with no root password hidden in your website somewhere with no outside links, they still might find it, and then you are toast. Obscurity just stops most script kiddies. That's not bad, though, is it?