MS06-053 revisited ?
When we first read MS06-053 we ended up discussing and not fully understanding what Microsoft was trying to say (or hide, depending on your level of trust). It seemed like every time we thought we had it, the confusion crept in again.
Well, the confusion is still not fully gone, but some seem to have developed the thing to a point where there is no ignoring that you do not need an Indexing Service, nor an IIS server in the picture, in fact all you need is Microsoft's browser.
CVE-2006-0032 seems to indicate in its description that it indeed is a problem in the server allowing UTF-7 encoding.
Wait a second, "+ADw-" is supposed to represent "<" ? How many application developers know of this encoding?
UTF-7 is defined in RFC2152, titled "Mail-Safe Transformation Format of Unicode". How many of those developers do really care about something designed for email when writing their application for the web?
Ok, back to the core of the problem: this UTF-7 XSS vulnerability in the indexing service, was that it? Or was it just the tip of the iceberg, and is there something wrong in MSIE (as well)?
Not giving encoding back and including some seemingly innocent strings ([A-Za-z0-9+\-] is enough) -based on user input- is enough to create a XSS vulnerability for visitors using MSIE.
The "ouch" part are e.g. custom error pages that might not include any character set information but might include (part of) the requested URL: CVE-2006-5152.
Conclusion
Swa Frantzen -- Section 66
0 comment(s)
Well, the confusion is still not fully gone, but some seem to have developed the thing to a point where there is no ignoring that you do not need an Indexing Service, nor an IIS server in the picture, in fact all you need is Microsoft's browser.
Back to the start
MS06-053 is about a vulnerability in the Indexing Service it seems. The title is "Vulnerability in Indexing Service Could Allow Cross-Site Scripting (920685)". It references to CVE-2006-0032. And has hidden deep inside the workarounds: "Disable page encoding auto-detection in Internet Explorer". So the confusion is really if this is a server problem or a client problem and it somehow seems we're not the only confused ones out there. Now with XSS it's the client that's abused by trusting a vulnerable server. Yet it seems that making the client do things differently the server is saved?CVE-2006-0032 seems to indicate in its description that it indeed is a problem in the server allowing UTF-7 encoding.
Now what does that encoding look like?
+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-
Wait a second, "+ADw-" is supposed to represent "<" ? How many application developers know of this encoding?
UTF-7 is defined in RFC2152, titled "Mail-Safe Transformation Format of Unicode". How many of those developers do really care about something designed for email when writing their application for the web?
Ok, back to the core of the problem: this UTF-7 XSS vulnerability in the indexing service, was that it? Or was it just the tip of the iceberg, and is there something wrong in MSIE (as well)?
MSIE
Well it seems that if MSIE is not given a character set, it will autoselect one, and might just choose UTF-7. I'm sure somebody must have found it a cool feature, just like having a flight simulator in excel is cool.Not giving encoding back and including some seemingly innocent strings ([A-Za-z0-9+\-] is enough) -based on user input- is enough to create a XSS vulnerability for visitors using MSIE.
The "ouch" part are e.g. custom error pages that might not include any character set information but might include (part of) the requested URL: CVE-2006-5152.
Conclusion
- Well we could put on the recorded message of not using MSIE. It does sound broken, doesn't it? But those that would listen will have done so already by now.
- We could urge people to change the settings of MSIE:
- Launch Internet Explorer
- Click on View;
- Click on Encoding;
- Deselect Auto-select if it is selected.
- We can ask people to take care of their visitors and make the applications stronger in authenticating users before taking actions and in not storing authentication, sensitive information etc. in cookies and the like.
- If you develop web applications, make sure you always set the encoding, don't ever let MSIE guess as perfectly innocent looking strings might cause XSS problems.
- We could urge people to look at their errorlog and find 404 results and see if there was recon on using UTF-7 in it, but the recon can be very subtle. So at least check if your custom 404 web pages return the requested URL and stop doing that.
Swa Frantzen -- Section 66
There are no more Passive Exploits
The class of so-called "passive exploits" are more serious than previously considered. In the past, you would have to "trick" users to visit webpages or otherwise go to the exploit. This has shown to be easy enough, some users will click on anything. However, with the ubiquity of wireless, it is not only easy to get around the passive part of the exploit with wireless man-in-the-middle attacks, it allows for targetting the exploits to certain classes of people or organizations for maximum impact.
Wireless man-in-the-middle attacks are pretty trivial and can take several forms. For instance, "airpwn" which debuted at DefCon some time ago would focus on replacing images when victim machines would surf the web. It would be easy, for instance, to inject harmful malware into innocuous web traffic and infect machines unknowingly to the user. The Intel wireless driver vulnerability suggests that it is possible to exploit wireless drivers directly. The mindless expansion of wireless availability without thinking of the security implications means we need to play a little catch up.
The downside of using wireless exploits is that it ties the hacker to a geographical area. The upside is that it allows you to highly target your victims without "spamming the world". This helps malware developers avoid their malware getting detected by AV/Anti-Spyware applications.
It is trivial to determine if your malware is detected by these applications, you can simply scan the file yourself. If your malware doesn't trip the heuristics or the signatures, the malware will slip past anything used to defend a PC. If you spead this malware on a local basis, it makes it that much more difficult for AV/Anti-Spyware vendors to find the malware, reverse engineer it, and develop a signature. The malware has to find the AV/Anti-Spyware companies, in a sense, before it can be examined. It's not impossible, but it is another large barrier of defense. Anti-Virus/Anti-Spyware applications are, by design, set up for maximum privilege (as opposed to least privilege). Anything that doesn't trip their rules is allowed.
The particular application here isn't the general script kiddie, mass identity theft stunts that are all too common. The application is corporate espionage or espionage proper. Here's an example:
Alpha Industries has invested massive amounts of R&D and developed products far ahead of the competition, Zulu, Inc. Zulu, realizing they are being left in the dust and suffering from a bout of "moral flexibility" decides to try to spy on Alpha Industries. They know the headquearters is near a popular coffee shop with wireless that many Alpha employees frequent. They pay a hacker to sit in the coffee shop and silently inject malware onto any machine that connects.
This malware is pretty simply. All it does is search a desktop machine for any "office files" that it sees, takes a few, zips them with a password, and then silently mails them to a dropbox read by Zulu, Inc. employees. Those employees then take the, hopefully, proprietary information and starts to get a leg-up.
The basic point here is that it became much more important to patch even those "passive exploits" if you have information to protect, to start thinking about how to layer defense against malware, and to develop policies and procedures to protect confidential information especially if laptops containing it "go on the road."
---
John Bambenek, bambenek (at) gmail [dot] com
University of Illinois - Urbana-Champaign
0 comment(s)
Wireless man-in-the-middle attacks are pretty trivial and can take several forms. For instance, "airpwn" which debuted at DefCon some time ago would focus on replacing images when victim machines would surf the web. It would be easy, for instance, to inject harmful malware into innocuous web traffic and infect machines unknowingly to the user. The Intel wireless driver vulnerability suggests that it is possible to exploit wireless drivers directly. The mindless expansion of wireless availability without thinking of the security implications means we need to play a little catch up.
The downside of using wireless exploits is that it ties the hacker to a geographical area. The upside is that it allows you to highly target your victims without "spamming the world". This helps malware developers avoid their malware getting detected by AV/Anti-Spyware applications.
It is trivial to determine if your malware is detected by these applications, you can simply scan the file yourself. If your malware doesn't trip the heuristics or the signatures, the malware will slip past anything used to defend a PC. If you spead this malware on a local basis, it makes it that much more difficult for AV/Anti-Spyware vendors to find the malware, reverse engineer it, and develop a signature. The malware has to find the AV/Anti-Spyware companies, in a sense, before it can be examined. It's not impossible, but it is another large barrier of defense. Anti-Virus/Anti-Spyware applications are, by design, set up for maximum privilege (as opposed to least privilege). Anything that doesn't trip their rules is allowed.
The particular application here isn't the general script kiddie, mass identity theft stunts that are all too common. The application is corporate espionage or espionage proper. Here's an example:
Alpha Industries has invested massive amounts of R&D and developed products far ahead of the competition, Zulu, Inc. Zulu, realizing they are being left in the dust and suffering from a bout of "moral flexibility" decides to try to spy on Alpha Industries. They know the headquearters is near a popular coffee shop with wireless that many Alpha employees frequent. They pay a hacker to sit in the coffee shop and silently inject malware onto any machine that connects.
This malware is pretty simply. All it does is search a desktop machine for any "office files" that it sees, takes a few, zips them with a password, and then silently mails them to a dropbox read by Zulu, Inc. employees. Those employees then take the, hopefully, proprietary information and starts to get a leg-up.
The basic point here is that it became much more important to patch even those "passive exploits" if you have information to protect, to start thinking about how to layer defense against malware, and to develop policies and procedures to protect confidential information especially if laptops containing it "go on the road."
---
John Bambenek, bambenek (at) gmail [dot] com
University of Illinois - Urbana-Champaign
Microsoft Advance Notice Out - 11 Patches
This months Advance Bulletin is out. The breakdown is 6 Windows with critical(s), 4 Office with critical(s) and 1 .NET patch that's moderate. More details as we get them but it looks to be an active day of patching with (hopefully) some pretty important patches (like this one).
UPDATE (3:21PM Central) - To clarify, that's not 6 criticals; that's somewhere between 1 and 6 criticals.
--
John Bambenek , bambenek (at) gmail [dot] com
University of Illinois - Urbana-Champaign
UPDATE (3:21PM Central) - To clarify, that's not 6 criticals; that's somewhere between 1 and 6 criticals.
--
John Bambenek , bambenek (at) gmail [dot] com
University of Illinois - Urbana-Champaign
Keywords:
0 comment(s)
×
Diary Archives
Comments