BlueHat Security Briefings

Cesar Cerrudo of Argeniss here. I was thinking what to write about in this blog post and I decided that this would be a good opportunity to acknowledge Microsoft security efforts by highlighting Microsoft improvements, and also to compare how security is currently handled by the other big software vendors.

While I don't like some Microsoft policies and how some security issues are handled by Microsoft sometimes, Microsoft is currently the software vendor that cares the most about security, and this can be seen in the increased security of their software. It has improved a lot in the last few years. Of course nobody is perfect, and Microsoft software will continue to have security vulnerabilities, but they will continue improving.

My team and I have been finding and reporting hundreds of vulnerabilities to major vendors for the last 6 years, so I guess I have some experience in the subject.

Let’s talk about two of the biggest software vendors. I’m not going to mention their real names. Let’s just say they are Vendor A and Vendor B.

First we have Vendor A. This vendor talks more than it acts. They are always talking about how much they train developers in security, how much they care about security, how they use these wonderful products that find all security issues, and even make and serve coffee while doing it, and blah, blah, blah. But reality is far different from what they say.

Let’s take an example: You report X vulnerability in Y functionality to them, and they will take their time to fix it (and it could take a couple of years sometimes). Furthermore, they just fix the X vulnerability in Y functionality. They don't investigate whether the same vulnerability is present in Z functionality. But that's not all, they only fix your reported attack vector. They don't look for other attack vectors. But wait, that's not all -- the developer will produce a fix that can't even prevent a variation of the reported attack and this fix goes straight to production. I really wonder how this vendor determines when a fix is ready to go into production, since not enough testing seems to have been done.

Nobody seems to notice that the fix sucks, then when the fix is ready, the vendor will inform you they have produced a fix for the vulnerability in software version 1a, 2a, and 2b, and that they will release it at some future date. When the fix is released, you test the fix in the corresponding versions and then you realize that there is no fix at all in version 1a and that the fix on version 2a and 2b only works when trying to exploit the vulnerability in the exact way you reported. If you change the exploit slightly, then the fix doesn't work, so you contact them again.

You go through the same process one more time, and then a new fix is released. With the new fix, you find out again that the fix in version 1a is not present, and the fix in version 2a works well, but the fix on version 2b still doesn't work with exploit variations. The same process goes on again and again, until some day after 2, 3, or 4 fixes, the vulnerability is finally fixed on all the affected software versions.

Unbelievable, eh? Well, that is how Vendor A is currently producing security fixes. Vendor A is clearly many years behind Microsoft when it comes to security.

Let’s talk now about Vendor B. This vendor has a lot of experience producing software, and like Vendor A, it is one of the big vendors. Vendor B seems to produce good fixes for security vulnerabilities, but they have a bigger problem. It seems their developers are not very familiar with security.

For instance, the latest version of one of their most popular software packages still has stack overflows that you can find in 5 minutes. It also has everything open by default, and by changing just one byte in software protocol packets you can easily crash the software.

You can tell that some developers don't really get security and that they have the final decision when to produce a fix. If you report a vulnerability related to some functionality that's accessible to all users by default, and that can be abused to perform evil actions, they will just respond that the functionality is used by their customers and that it can't be abused. And that's it, developers don't realize that their competitors’ software has restricted the same functionality by default for security reasons a long time ago. Vendor B doesn't seem to have a security response team, since most of the time, reports are handled directly by developers or software managers. I could continue with more examples, but I think you get the picture. What is weird is that Vendor B some time ago acquired an important security consulting company that had really skilled people. I wonder why these people are not helping to improve their own software security, instead of doing cool research on new attacks on software from other vendors and providing external consulting services in order to help other companies. Weird.

Again Vendor B is clearly many years behind Microsoft when it comes to security.

I have criticized and pointed out Microsoft security problems many times and I will continue doing it when it's necessary, but I really think that Microsoft is ahead by many years in security, compared to other vendors. Microsoft is leading security efforts in the software industry.

I have seen Microsoft make huge improvements over time. Some Microsoft products’ previous versions had dozens of vulnerabilities, but now the newest version has almost no vulnerabilities. I haven't seen that in any other products from other vendors, and this is something really amazing that nobody seems to notice.

I think other vendors will improve over time and that Microsoft is indirectly helping them with the knowledge and research it generates. By looking at Microsoft, these other vendors could get an idea on how to get better at security.

BlueHat is another innovative way Microsoft has developed to improve security. If you have something to say that will help to improve security in its products, then Microsoft will listen to you.

As I always say: “Vendor A and Vendor B are very lucky because they never had a worm.”

-Cesar

Hello, this is Rob Hensing. I work with the SWI team at Microsoft. One focus of my job is looking for mitigations and workarounds that we can use to protect our customers against vulnerabilities and exploits. Part of this involves testing out the mitigation technologies that we’ve baked into a lot of our products as part of the SDL process, such as buffer overflow protection like /GS, execution prevention via DEP, and address space randomization via ASLR.  As a result, I spend a lot of time studying responsibly (and irresponsibly) disclosed vulnerabilities in a debugger and looking for crazy things our customers can do to protect themselves from attempts to exploit those vulnerabilities. Something that has been on my mind a lot lately is the battle for the browser and the attack surface the browser represents to the average user. And what I really mean is the battle for control of your PC by bad guys via your browser. J Obviously this is nothing new, bad guys have been pwning average users’ PCs for years using browsers, but things are about to change and I wanted to share some of my thoughts on this.

The battle for the browser was thrust into the limelight (again) this year by Shane Macaulay at CanSecWest when on Day 3 of the pwn2own festivities he and another researcher, Alexander Sotirov, were successfully able to claim the prize for pwning the Vista box using an Adobe Flash 0-day vulnerability. I was pretty sure it would be over within minutes, and when it wasn’t, I found myself checking in on their progress throughout the day. The reason I thought it would be over in minutes, is that because once you have some buggy AX control with a vulnerability running inside of IE, since about 2004, it has been almost trivial to code up a reliable exploit for it that makes use of a technique known as Heap Spray (pioneered AFAIK by Skylined), which requires nothing more than some clever JavaScript used to prepare the process’s memory to make exploitation of vulnerabilities more reliable. 

You may recall that Sotirov is someone who did even more work in the area of heap spray, culminating in presentations at BlackHat on “Heap Feng Shui” and a JavaScript library that makes exploit development using heap spray even easier. But to my surprise, instead of taking minutes, it took the better part of a day before the judges declared them the winners. (In fact it took so long that I didn’t even get to see them win, as I was busy presenting on targeted attacks in one of the final sessions of the last day!). For some reason, throughout the day the exploit wasn’t working properly and IE was just crashing instead of running the shellcode. At the time, the working theory was that in Vista SP1 we must have marked the heap pages as non-executable or more accurately, Vista SP1 started enforcing no execution of instructions out of pages of memory that were not marked as executable via a concept known as DEP (Data Execution Prevention). However, this was not the case – IE7 on XPSP2 and Vista SP0/SP1 does not ”opt-in” to DEP (…yet, and more on that later). More intriguing (to me) was that, operating on the assumption that they were up against DEP, Macaulay and Sotirov set off trying to bypass DEP protection using another technique, which I don’t think was the one discussed by Skape and Skywing in this Uninformed article.

During the day, the use of a Java VM was mentioned, so I’m guessing that instead of using JavaScript to do the heap spray, Macaulay and Sotirov may have used a Java class file and a Java VM to spray memory with NOPs and shellcode. The difference? Our JavaScript library will allocate heap memory pages with PAGE_READWRITE protection (and so attempts to execute code from them can be stopped by enabling DEP) and a Java VM may allocate memory as PAGE_EXECUTE_READWRITE (rendering DEP powerless to stop code execution, since the pages are marked as being intended for code execution!). Clever. If that’s what indeed happened. (I don’t know for sure – I’m only speculating).

So why did this under-reported piece of information grab my attention? There were two reasons:

1.       The fact that the researchers went after Adobe and found a code execution vulnerability is a big deal. Flash is a cross-platform application and is more ubiquitous than even IE or Windows. It is virtually guaranteed that Flash will be installed on a given machine connected to the Internet.

2.       It demonstrated that researchers (and more than likely, malware or exploit writers) are actively looking for ways to bypass DEP, should it be enabled for the process they are trying to exploit.

Today, IE doesn’t use DEP by default and it would seem that researchers are already looking for ways to bypass it, anticipating a day when it might. Right now, you can make IE use DEP by following the instructions in Mike Howard’s blog (or by using the .REG file at the end of my blog post on DEP in Vista), but I suspect the vast majority of people haven’t done that and so there hasn’t been a lot of focus on bypassing DEP because there hasn’t really been the need. So why not create that need? Why haven’t we made more effort to make IE use DEP by default? For the same reason we do most things that seem counterintuitive, for application compatibility reasons. J We haven’t made IE use DEP by default yet, because it’s only in the last year or so that major 3^rd party AX controls like Flash were able to run in a process using DEP without crashing the process! Remember, it was only a couple of weeks ago that Apple released an update to QuickTime that finally allows some of the key QuickTime libraries to use DEP and ASLR on Windows (which was is a very big deal!). Oh and for the record, that ”someday when IE might use DEP by default” I mentioned earlier is coming soon! In fact, recently Eric Lawrence (an IE Program Manager) went on record last week as saying that IE8 will opt-in to DEP by default on Vista using a new API that we made available in Vista SP1!

In more signs of the times: just this week, Mark Dowd, an Aussie security researcher with IBM-ISS rocked the security researcher world and blew a lot of minds with his pretty impressive work exploiting yet another Flash vulnerability (Ptacek’s write-up is a great summary if you don’t want to read the 25 page write-up from Mark). In essence, Mark found a vulnerability in Flash that allowed him to perform an arbitrary 4-byte write to a location in memory. That in and of itself isn’t necessarily what’s interesting; what’s interesting is the way he chose to leverage that vulnerability (by patching some bytes used by the ActionScript Virtual Machine, which allowed him to run dangerous ActionScript bytecode