IIS Vulnerability Documented by Microsoft - Includes Workarounds
Microsoft has just put out an advisory for a privilege escalation vulnerability in Windows that affects IIS and potential SQL server (951306). Basically, authenticated users can use this vulnerability to become LocalSystem. This is probably more of a problem for shared hosting environments were clients could upload malicious code to the webserver and run the exploit to gain additional rights. SQL is less of a problem because permissions have to be explicitly given to allow a SQL user to run code.
The advisory contains workarounds for IIS 6 and 7 that is claimed to blunt this vulnerability. The only negative impact of those workarounds is to add some extra work when adding users but does block the vector of attack.
There is a public report of this, but apparently no exploits yet. More when we get additional information, but refer to MSFT's advisory with details on how to workaround.
Update
Cesar's paper has been released and you can see it here
--
John Bambenek / bambenek {at} gmail [dot] com
Neither ran, nor sleet, nor earthquakes shaking my office will stop the ISC
The Patch Window is Gone: Automated Patch-Based Exploit Generation
For some time, many researchers have been pointing to the fact that the "patch window" (the time between a patch being released and an exploit being developed) has been decreasing. A few years ago, the ISC's Johannes Ullrich did a presentation on this subject which showed the patch window decreasing to a few days. Today, another Handler, Mari Nichols, pointed me to this research from a joint project between Berkeley, University of Pittsburgh and Carnegie Mellon.
For some time, it has been known that the patch can be reverse-engineer to help attackers write an exploit for a vulnerability that might not be fully detailed in public accounts (for good reason). The bad guys have gotten pretty good at this where they can turn around an exploit in a day or so after a patch is released. What is interesting about this research is that they developed means partly using off-the-shelf tools to make this process automatic.
In some of the cases they tried, they claimed to be able to create an exploit in minutes after receiving the patch and comparing the patched version of the application with the unpatched version. To be fair, their process seemed "dirty" such that more often than not the exploit created crashes or DoS type exploits and several attempts were needed to get something closer to viable. The process often took minutes so when/if the method is improved it could be trivial to create something that grabbed patches ASAP, turn an exploit in minutes and start infected vulnerable machines before 3am during the monthly patch dump with automated patching.
A solution suggested by the authors is "secure distribution of patches". To me, this is meaningless. You need to get patches out to people with a minimum amount of effort. This is why automated patching was such a good thing. But even if you encrypt, require passwords and logins, etc... you are going to delay the time for legitimate people to patch, and attackers (who are perfectly able to buy Windows legit) will grab the patches quickly anyway. You'd only make the window of vulnerability longer by making things secure without a tangible benefit.
Solution: Not much, we've known the window was closing for awhile. Responding quickly and proactively to threats is still a must and the use of temporary workarounds will probably raise in value. Thoughts? Send them my way.
--
John Bambenek / bambenek {at} gmail [dot] com
EV SSL Certificates - Just once, why can't one of our poorly considered quick fixes work?
PayPal has announced some of its strategies against phishing against their users. Some of this is good stuff and since PayPal is a larger target, they should be commended in taking a proactive role. However, the requirement that browsers using PayPal must support EV SSL Certs and that they must have built-in anti-phishing protection simply do no good. First, an analysis on EV SSL certificates:
EV SSL Certificates - Twice the Effort, 10 times the Cost, No tangible benefit
Extended Validation Certificates are basically SSL certs that require a more detailed background examination of the requesting entity. They require an establishment of a legal identity, that the applicant owns the domain and that all the required documents are signed by an authorized official. In short, it requires the sort of thing that any SSL certificate should have required in the first place. If you think about it, a general SSL certificate should "prove" that you are seeing an authentic website. The reality is, that pretty much anyone can get an SSL cert (for free) without proving anything. The only validation is that the FQDN in the cert matches what the browser says. Net result, attackers buy domains and then gets certs for them, because no real validation occurs. www-paypal.com can get an SSL certificate too that will show up as valid to a user. All an SSL certificate proves is that the URL matches the certificate.
Now comes EV Certs which are supposed to provide that background check that should have taken place before issuing a normal SSL certificate to begin with. Generally, they require the requesting entity to be: a government entity, a legal corporation, a general partnership, a sole proprietorship, or an unincorporated association. This level of "authentication" only makes criminals simply jump through some more hoops... hoops they may have jumped through already (more on that later).
Here is how you can become a legal corporation in less than 24 hours (this is US-Centric, sorry I don't know how to form companies in another nation, but foreign entities can apply for FEINs by fax here). Step one, go to the IRS and apply for a FEIN. You can pretty much enter any values you want here, they just have to pass the smell-test. For instance, create a FEIN for "Al Qaeda in America". (NB, realize you're probably never going to be able to get on a plane in the US again without a thorough prostate exam). You get your FEIN back instantly.
Step two, let's say you want to incorporate in Illinois. Go here to the Secretary of State's website, fill out the form, and you get your articles of incorporation in 24 hours. Congratulations, you are now incorporated and eligible for an EV Cert.
These steps may not be necessary because many spam outfits and other nefarious groups are already incorporated. In short, this process doesn't keep the Internet's bottom-feeders out, it just makes them jump through a few more hoops and toss some cash towards the Certificate Authorities. For that matter, many outright mob outfits are properly organized in the legal sense.
While it is important to note that the list of CAs that can issue EV Certs is smaller than the general list of CAs, I have little faith this will remain so. Many CAs came to be simply to lower the bar to getting a certificate, there will be the same demand to lower the bar to get EV Certs and companies that are willing to service the less-than-honest among us. The bar was lowered once, it'll be lowered again.
So an EV certificate only proves that the website owner can fill out a few webforms, cough up some money, and cough up some more money to pay the CAs for doing the job they should have done in the first place (i.e. verify the identity of the requestor of a cert).
All this said, it doesn't protect against website content that is made to look like another website (i.e. forgery). A user may not see the full green bar, but the content can be made to look and feel the same. Even worse, a normal SSL certificate can still work and display content that is malicious. Or for that matter, a website that isn't encrypted at all. The question remains, is a user able to discern an EV Signed site from other SSL signed sites to know the difference. Academic research indicates that, no, EV certificates make no impact on users spotting fraudulent sites or not.
The purpose of EV SSL Certs - PayPal isn't Using them Correctly
The purpose of an EV SSL certificate is to authenticate a website to a user, period. PayPal, however, is wanting to use EV SSL support as a way of authenticated a user to PayPal. That makes no sense. PayPal has an interest in authenticating people who want to use their service are valid. The presence or absence of EV SSL support in their browser is irrelevant. Does anyone really think that say, the Russian Mob, won't be able to use IE to process PayPal transactions with stolen credentials?
This stance won't, for instance, prevent users from getting keyloggers on their machines to steal the information, being infected with a trojan that will silently process transactions while the user is logged-in, money mules from doing the heavy lifting for malicious individuals, cross-site scripting, or from a user giving up their credentials in a phishing attack to another website. In short, an EV SSL enabled browser proves nothing.
How to Properly Authenticate a User for Online Transactions With Proven Technology
There are already existing and proven ways to authenticate a user for online transactions in a way that mitigates the phishing problem. Many banks do this already as well. Two-factor authentication limits the ability to use stolen information for online fraud (though it does not prevent the trojan problem mentioned above, but neither does EV SSL or "anti-phishing" browsers). Requiring a hardware token to enter another piece of data to send money is something that is shown to work and is economical considering the cost for fraud.
Part of the phishing problem with paypal is the amount of emails they send to their customers and the difficulty of users in determining authenticity. Signed e-mail would help. Reducing e-mail or at least sending email with no clickable links would be better. Both would be great.
Anti-phishing support in a browser proves nothing, there are plenty of fine solutions out there that provide anti-phishing protection. Simply attacking Safari smacks of Anti-Apple bias. And while I'm not fan of the ham-handed way they do security, Mac users simply aren't the phishing victims we need to worry about right now.
Remote Validation of Secure Systems
I have argued that the fundamental problem with phishing, and in fact, all online fraud is the fundamental assumption that consumer PCs can be secured and/or are trustworthy. We need to accommodate ourselves to this fact: consumer PCs are insecure and insecurable. We must treat them as such, just like we treat communication over the internet as insecure and susceptible to interception. This goes back to the absolute necessity of two-factor authentication for "important" transactions and the elimination of typing in sensitive data into a web browser. For instance, the U.S. Department of Education still uses the **Social Security Number** as a **username** to log in to their student loan system. Keyloggers everywhere are happily stealing college students' SSNs and stealing their identities as we speak.
There is a place for remote validation for consumer PCs and denying them access if they are insecure (and I've argued as such). However, simply validating default broswer features is not it. It would be far better to ensure up-to-date AV signatures, up-to-date patches, up-to-date spyware/malware protection and secure OS configuration. Failing any of these, the site in question can provide instructions (or better yet, send the user a CD) to secure and harden their machine.
Basing your security posture based on superficial differentiators provides no real security, and really only creates a headache. This takes work, laziness will only get more people 0wned.
--
John Bambenek /at/ gmail {dot} com
Comments