Hey there, Vincenzo and Fermin here!

Next week we will be giving two talks at BlueHat. Vincenzo will be talking with Tim Kornau, Ralf Philipp Weinmann, and Thomas Dullien, about return-oriented programming and how to automate the creation of ROP payloads. Also, Fermin and Andrew Roths will be talking about EMET and how it can prevent the successful exploitation of vulnerabilities.

Since 2004, a lot of things have changed in the exploitation playground. The cat-and-mouse game between offensive and defensive researchers has brought us two important and game-changing mitigations: ASLR and DEP.

In fact, exploits targeting modern platforms and applications that support DEP and ASLR work by either leveraging weaknesses in ASLR (e.g., non randomized DLLs) or lack of DEP enforcement (e.g., JIT spaying).

Practically speaking, this means that exploits, most of the time, work as follows:

1) Find, in the process address space, a DLL that is not randomized.

2) Chain together some ROP gadgets taken from the DLL (we can consider a gadget to be a set of assembly instructions that performs a given task).

3) Disable/bypass DEP with the ROP shellcode.

4) Execute a standard (non-ROP) payload.

During our presentation, we will show you a toolkit that allows you to write a payload in a custom language that will be translated into an ROP shellcode.

Some of you might point out that most of the time an ROP payload is very tiny and therefore there might be no need for such a tool. Unfortunately, we have learned during the past few years that the exploitation playground evolves rapidly.

For example, in some mobile platforms, such as the iPhone OS, the third step of the workflow cannot be performed. Therefore, the entire payload has to consist of ROP gadgets. Furthermore, in order to defeat ASL, it is often necessary to write ROP egg-hunters to locate payload pieces in memory.

These two are common scenarios where a tool like ours can be handy.

Some research has been done on ways to permanently stop ROP payloads and probably one day we will get there, but at the moment some of the best mitigations we have are tools like EMET (Enhanced Mitigation Experience Toolkit), which makes the above exploit workflow somewhat harder.

As you probably know, EMET 2.0 was released some weeks ago. It is a tool that enables security mitigation technologies to be deployed for arbitrary applications, helping to prevent vulnerabilities in those applications (especially line-of-business and third-party apps) from being exploited successfully. For more information, see the SRD blog.

EMET offers several mitigations, even for down-level operating systems (DEP, heap pages pre-allocations, SEHOP, mandatory ASLR, and EAT filtering).

Mandatory ASLR is one of the most interesting mitigations. Even when an application has opted in to ASLR, some of the DLLs being used could be placed on predictable mappings. This is because these DLLs were not compiled with the /DYNAMICBASE linker option. EMET, when mandatory ASLR is enabled, solves this problem by forcing the relocation of these DLLs.

Let’s take the metasploit module for the latest Adobe vulnerability as an example. This exploit relies on several gadgets located on a non-ASLR-aware module, icucnv36.dll.

The first ROP gadget used places the stack at a controlled place. This can be done because the attacker can reuse these lines of assembly from the non-ASLR module.

0:000> u 0x4a80cb38 L3

icucnv36!ucnv_toUChars_3_6+0x162:

4a80cb38 81c594070000 add ebp,794h

4a80cb3e c9 leave

4a80cb3f c3 ret

0:000>

When EMET is in place and Mandatory ASLR is enabled, this DLL will get relocated to a random place. The exploit will try to jump to 0x4a80cb38 but, since the DLL was relocated, the change of ESP to a controlled place will fail.

0:001> u 0x4a80cb38 L3

4a80cb38 ?? ???

^ Memory access error in 'u 0x4a80cb38 l3'

0:001>

Even the author of the metasploit module for this vulnerability suggests installing EMET so it will be harder to successfully exploit this vulnerability.

Clearly EMET is not the definitive answer, but what we have now is a slightly more intricate workflow for exploits development:

1) Find a memory leak or another similar weakness, as shown at Pwn2Own 2010, which allows us to find the base address of a DLL.

2) Chain together some ROP gadgets taken from the DLL (we can consider a gadget a set of assembly instructions that perform a given task).

3) Disable/bypass DEP with the ROP shellcode.

4) Execute a standard (non-ROP) payload.

This workflow clearly requires significant more work on the attacker’s side in order to write reliable exploits.

At the end of the day, EMET and our tool are yet more proof that the game is evolving fast! So stay tuned and come watch our ROP talk and Fermin and Andrew's EMET talk.

- Vincenzo Iozzo and Fermin J. Serna

There are only a few days left before Black Hat USA, and we, like most other speakers, are in the midst of the last-minute push to have all the materials finalized in time for our presentation. Our presentation this year, "The Language of Trust," features a lot of material related to attacking software interoperability layers, and focuses on Web browsers as case studies. Some of the vulnerabilities we will be disclosing affect Microsoft software and have resulted in Microsoft releasing an out-of-band update on July 28^th. The updates included in this release are the result of a lengthy and largely successful collaboration between us and Microsoft, particularly individuals from MSRC including Steve Adegbite, David Midturi, and Dustin Childs. Microsoft has had the unenviable task of dealing with the issues surrounding the fixes for these problems, and they have worked diligently to do so in a timely manner. We decided to put together a blog post discussing the problems that needed to be contended with to get this update out in time, and plug our upcoming Black Hat presentation.

The update addresses some issues we uncovered in the Microsoft Active Template Library (ATL). Released in 1997, the ATL is actually distributed as source code with Visual Studio and is aimed at simplifying various programming tasks for developers. It provides, among other things, helper functionality that is utilized by most ActiveX components, which is where the vulnerabilities we are disclosing reside. Anyone who has utilized the relevant ATL code in their ActiveX controls for the past twelve years may have inadvertently incorporated these vulnerabilities into their own products. Microsoft has been getting a considerable amount of criticism for the amount of time it took to patch the Video Control vulnerability; however, the issue is much larger than it first appears and this fact, along with why detection is so difficult, will be discussed further in our presentation.

There are a few unique problems that needed to be dealt with for the ATL bugs. The first problem is efficient enumeration of vulnerable applications. When you contrast issues within the ATL against issues within application code, a number of differences become apparent. Generally, problems within application code are localized to a single source file, and require the recompilation of a single program. However, with issues in the ATL, any application that includes code from the ATL may be vulnerable. Furthermore, successful detection of vulnerable ATL code usage is a complex and error-prone process, and is difficult to achieve with standard static analysis tools. The reasons why detection is difficult will become clearer after our presentation, when we discuss the details of the bug.

The second issue that needed to be addressed was that of vendor coordination. As previously stated, other vendors that use ATL code in their ActiveX controls are potentially vulnerable. As such, Microsoft charged themselves with the arduous task of tracking down as many potentially vulnerable vendors as possible, and coordinating with each of them. Coordination involved explaining a bit about the potential problems, how to determine if a given control is vulnerable, and mitigation steps that can be taken to fix identified problem controls. This is a process that obviously takes time and effort, and Microsoft has been working around the clock with a number of vendors trying to minimize the risk to end users.

So, the mitigation work is done, the update is out and the presentation is going ahead on schedule! We would like to use the rest of this blog to shamelessly promote the presentation, which is quite broader than bypassing kill bits, and give a little insight into some of the issues we will be discussing. Primarily, our presentation intends to address three issues:

1. Interoperability layers in software do a lot of complicated work behind the scenes, and provide a vast and largely unexplored attack surface.

2. Throughout the course of our research, we discovered that unique bug classes exist due to the specialized tasks that marshalling code must perform. We intend to unveil these bug classes during the presentation. We will show how various data structures and APIs utilized for marshalling in the two dominant browser architectures lend themselves to misuse, creating the potential for subtle vulnerabilities that attackers may target. We will give practical examples for code constructs we have identified as vulnerable.

3. When two disparate components are given direct communication channels to each other, trust is implicitly extended between the two components. This trust relationship can be useful to attackers wishing to bypass various security features present in one component, by abusing features of another.

We are hoping this information will be useful for developers and security professionals alike, and look forward to seeing you all there! Our Black Hat presentation is slated for Wednesday, July 29^th, at 3:15pm PDT, in the Augustus Ballroom 5-6.

-Ryan Smith, Mark Dowd, David Dewey

Jared Pfost here.  I'm fired up to present at BlueHat. I really appreciate Noelle reaching out so it was a no brainer when asked to spin up a blog post. One thing that keeps popping up is my status as a former blue badge. Actually I'm a former twice over. One tour pre bubble and one post, or I like to think of it as pre/post the TWC memo. My tenure started in 97, two years out of UW and very much a newb on how security really worked in IT and dev teams. Much of what I do today is rooted in my Microsoft experience. Of course I didn't realize it until much later. Between dogfooding and attempting to keep up with the smart folks, I didn't notice the belief structure that formed. Here are a few I hope you'll enjoy.

Belief: We weren't as bad as we thought.

I always got a kick out of the perception from folks outside Redmond who assumed we were all rock stars. This cracked me up. I remember thinking, "if you only knew how screwed up we are..." As I left and worked with startups and other enterprises, there really were some special folks back then. Sometimes it's hard to notice when you're going 100 MPH. I hope it's still that way.

Belief: Heroes don't scale.

Burning key people out has been well documented. I'm talking about ordinary folks being asked to do heroic efforts like working 20 hours before a release. In my program manager or IT roles, I learned the hard way that quality suffers. It's usually better to take it on the chin and slip than fight another regression or outage fire. The root cause and fix is the same but a lot less painful.

Belief: Money doesn't buy happiness.

I didn’t realize it at the time but we had some big budgets in IT or dev compared to other companies. The reason I didn’t notice is because resources rarely correlated to success. We were successful when we had a solid process. For folks who don’t have money to burn, this is often the first excuse. Fact is I’ll take a solid process and two people over a team of ten any day.

Belief 4: Security isn't a technical problem, it's a management one.

After Washington Mutual collapsed, I started a software company to help security leaders manage their team and processes. It took me six months to realize I founded the company out of a belief structure. When you can define what you do, measure it, improve it, and enable your leadership to decide how much they need, life is good. Morale improves, customers are happier, and incidents are reduced. I wish I could quantify those claims for you but I can’t, yet. In my experience, great managers lead to great results. I believe it and I’m passionate about proving it so you can believe it too.

Fired up for Blue Hat!

-Jared Pfost

Jared Pfost brings 16 years of information security experience to Third Defense which he co-founded on the belief that effective management is the key to manage risk. Jared's unique career combines working in IT Security teams such as Washington Mutual and Microsoft, consulting, and designing software across startups, banking, and technology. Jared is a self-proclaimed process nut and has demonstrated you don't need unlimited resources to run a measurable, accountable, and effective security shop.

Jeremiah Grossman here. BlueHat is one of my favorite conferences of the year, and it’s one of the few I’ve consistently kept coming back to. The organizers put together an amazing event with consistently top-quality content, where the attendees are not only security people, but a legion of software developers who have a genuine interest in security -- because their employer (Microsoft) does. Interacting with the BlueHat crowd provides a unique opportunity where conversations can have huge impact. These are the people that make Windows and Internet Explorer after all. They supply development tools to millions who code on those platforms. If you want a feature or something changed relating to security, or learn how something works, these are the folks to talk to.

For me, this year just got that much better. Yesterday, there was a Web Application Security Summit, where I was asked to kick things off. I used this time to impart some of my knowledge of the space gained over the last ten years about what’s really going on out there in terms of vulnerabilities -- backed by statistical data of course. I described what issues are most common across the Web, how many of them get fixed and how quickly, which tend to get exploited and how.

This was also my chance to articulate the technology and policy challenges we currently face in such a way that those in the audience, hopefully those smarter than myself, can find new ways to overcome them. Challenges like, “how do we go about dealing with the trillions of lines of vulnerable code already in circulation?” and “how do we measurably increase the security of new code going into the system?”

As our lives become increasingly dependent on the Web, the subject of “security” is something that is important to us all.

Jeremiah Grossman is the Founder and CTO of WhiteHat Security, where he is responsible for Web security R&D and industry outreach. Mr. Grossman has written dozens of articles, white papers, and is a published author. His work has been featured in the Wall Street Journal, NY Times and many other mainstream media outlets.  As a well-known security expert and industry veteran, Mr. Grossman has been a guest speaker on five continents at hundreds of events including BlackHat, RSA, ISSA, and others. He has been invited to guest lecture at  top universities such as UC Berkeley, Stanford, Harvard, UoW Madison, UCLA, and Carnegie Mellon. Mr. Grossman is also a co-founder of the Web Application Security Consortium (WASC) and previously named one of InfoWorld's Top 25 CTOs. Before founding WhiteHat, Mr. Grossman was an information security officer at Yahoo!

Ian:
Having a mild case of "professional ADHD" is probably what got me started on this whole "cyber" thing. Having done research, development, integration and consulting in the past, I was starting to get too many unanswered questions in my mind when dealing with customers and individuals who were being compromised left and right. The main driver for me has been getting to the bottom of exactly who these aggressors are that we're dealing with and really understanding their motivations.
Having a chance to share this kind of research and finding like-minded individuals who are busy working the same angles is a real treat, and one of the major quality assurance measures we should all factor into our work… scientists call it peer-review! :-).

Fyodor:
I got into this thing through a random incident. Grugq and I have been pals for a long time. At one point, one of our "friends" was curious about the availability of "certain software" on the market. Naturally, I just went around to the groups of people I am familiar with and asked for leads. We found some sources for him at that time and referred him to a few guys offering similar software. The "friend" was surprised by our findings and suggested we do some more digging. So, we started building an automated system for gathering and indexing/tagging the information so it could be easily query-able, even for English speakers. Naturally I read Russian and Chinese, which basically helps. IMHO, the language barrier is one of the reasons why the "security crowd" doesn't always get the whole picture of the global situation. We don't have this problem.

Cyber[random_buzzword_chooser()]
-------------------------------------------------
Fyodor:
Honestly, I believe a lot of talk about "cyberwarfare" is actually coming from the U.S. (i.e., this is basically the American way of looking at things). I don't think there really is a concept of cyberwarfare in Russia or in China as it is being portrayed in the media. In my opinion, the current situation is more like the Wild West, where there are service providers and service consumers... and where some of the politically affiliated parties sometimes make use of such services. The availability and accessibility of such services makes it easy even for ordinary, otherwise patriotic people to buy a DDoS against Georgia for example.
Going back to the cyber thing, what really has been researched and analyzed in Russia is information warfare. This is not new and was one of the main priorities during the Cold War. And, in my opinion, this is actually more effective than paying a gang of geeks to hack (i.e., the Latvian and Georgian incidents were, in my view, the outcome of mass-opinion manipulation through the public media, which IS a part of information warfare strategy).

Ian:
I know, I know. There is no "cyber war" (sorry Howard, I had to use that term again). But seriously now, taking a (huge) step back from the picture that we already managed to paint, of how the criminal world operates in the online market (see how I didn't say "cyber crime"? Oops! ;-)). Some patterns were starting to appear in terms of linking more politically inclined incidents, as well as full-on nation-state-related incidents, online. That's where I started my research into it. This whole thing wouldn't have come to life if it wasn't for the amazing community we all work in. I have had a chance to get to sources and raw data that have been loosely analyzed before and take a fresh look at them from another angle. Without the people of different CERTs, organizations, and commercial companies, this would not have been possible at all.
I truly believe (and have personally witnessed) that making shortcuts on a national level to gain "cyber" capabilities ALWAYS results in using tools and techniques from the criminal side of things (with some adaptations at best), much like in the "real" world.

Attack Attribution
-------------------------
Ian & Fyodor:
At conferences, people are often more interested in actual attack attribution than they are in the concept of the attack itself. There are a couple of hints we can share on this matter. First of all, look at the tools. Different social groups develop their own habits of using or building tools in particular ways. So, analyzing the binary characteristics (compiler footprint, coding habit, AV, and anti-debugging methods) can be a good pointer to the origin of the code. Additionally, the majority of crime-related activities are done using tools produced by a small number of people, which is often another hint to an activity's origin. The third but not last interesting component is motivation.

- Crime is always about money.
- Crime is also conducted very much like a business.
- Ergo, criminals will be very inclined to use tools and techniques that are purpose-built for maximizing the effectiveness of the attack (buy tools, services).
- In terms of attribution, this makes things VERY difficult. Usually, attacks will be "seen" as originating from random places, with very little means of being traced back to a true source. And, the code used is usually from a group specializing in creating such code. Linking the evidence back to the attacker is a long reach at best, and even techniques that aim to "identify" the code origin only get you to the manufacturer, not the user (think guns).
- Carrying on the traditional forensics example, if ballistics were to point to a specific weapon, on the cyber front that weapon would have little if any fingerprint evidence on it that could be attributable to the assailant.

Future plans
-----------------
Ian:
I like to play in different fields, from the technical domains to the corporate ones, on up to the political ones (at the national level, or on the international level where I have had the fortune of starting work recently). But the bottom line is that I'm focusing on several research areas: data exfiltration techniques that avoid traditional protections (and how to detect them), linking crime and terrorism groups in terms of tool and techniques (already in the works), and countermeasures at the national and international levels in terms of political power and deterrence.
As I like to say to my clients, "Everything is fair game; everything is in scope :-).

Fyodor:
Automated Intelligence analysis is a challenging area that mixes the pure technical fields with social and psychological studies. Reverse engineering, natural language processing, and distributed systems for large-scale data mining could all come in handy in building such automated frameworks. It is basically a fun area, experimenting with non-conventional technologies, and we are looking forward to exploring more of them. Generally, it is relaxing to take a break from your daily pen-test, reverse-engineering, corporate-objective-focused activities to play with something that is fun :-).
As for the future, we are planning to move on multi-lingual supporting analysis of Chinese content and most likely are going to focus more on scaling. We are also thinking of building public servers for awesome netglub (netglub.org) transforms (along w/ Maltego), so some of the data can be publicly accessible.

...---===END POST===---...

Here I am again writing on MS BlueHat blog, this time about Token Kidnapping.

The first time I talked about Token kidnapping was a long time ago and now after a year the issues detailed in the presentation are finally fixed.

Let's see what happened.

Before the first public Token Kidnapping presentation I talked to MS about the topics it included, I mentioned that there were design issues and that some issues were already known. I gave details to them about the Windows XP and 2003 issues (the ones that were already known, at least for some people and for MS too I guess) but I didn't give to them details about the Windows Vista and 2008 issues because I didn't want to give expensive research for free to MS. They would get the research together with general public.

It's very important to have in mind that these are not critical issues; these are elevation of privileges issues that can only be exploited in certain scenarios. These issues need some level of privilege to be exploited, so it's highly unlikely that they will be exploited to mass compromise servers and home computers. It's also important to note that in the scenarios that the issues can be exploited if these issues wouldn't exist then it could be also possible to elevate privileges in a different way. Because of all of this I decided to publish the Token Kidnapping details without any patch available since for me there was no real threat. These are security issues but the impact is very low.

It was only after the presentation and the press attention that MS fully understood the issues and realized that they needed to patch them but as most of them were design issues it would take a lot of work to get a patch ready.

Token Kidnapping had (and still has) a great media coverage this is something that doesn't make MS to look good and it also scares MS customers, MS knew it so they worked hard to fix these issues in a patch instead of a service pack were it would have been more appropriate to fix most of the issues. It took them a year but hey, given the complexity of the fix I think it's not that bad.

Microsoft had a hard time and instead of giving excuses they produced a fix, a bit slowly, but hey nobody is perfect.

The moral of the story?  MS put a lot of effort to get things fixed as soon as possible. MS really cares about their customers and of course about PR too. But the PR didn’t really make the fix come faster.

-Cesar Cerrudo

Share this post :

There have been many disruptive innovations in the history of modern computing, each of them in some way impacting how we create, interact with, deliver, and consume information. The platforms and mechanisms used to process, transport, and store our information likewise endure change, some in subtle ways and others profoundly.

Cloud computing is one such disruption whose impact is rippling across the many dimensions of our computing experience. Cloud – in its various forms and guises -- represents the potential cauterization of wounds which run deep in IT; self-afflicted injuries of inflexibility, inefficiency, cost inequity, and poor responsiveness.

But cost savings, lessening the environmental footprint, and increased agility aren’t the only things cited as benefits. Some argue that cloud computing offers the potential for not only equalling what we have for security today, but bettering it. It’s an interesting argument, really, and one that deserves some attention.

To address it, it requires a shift in perspective relative to the status quo.

We’ve been at this game for nearly forty years. With each new (r)evolutionary period of technological advancement and the resultant punctuated equilibrium that follows, we’ve done relatively little to solve the security problems that plague us, including entire classes of problems we’ve known about, known how to fix, but have been unable or unwilling to fix for many reasons.

With each pendulum swing, we attempt to pay the tax for the sins of our past with technology of the future that never seems to arrive.

Here’s where the notion of doing better comes into play.

Cloud computing is an operational model that describes how combinations of technology can be utilized to better deliver service; it’s a platform shuffle that is enabling a fierce and contentious debate on the issues surrounding how we secure our information and instantiate trust in an increasingly open and assumed-hostile operating environment which is in many cases directly shared with others, including our adversaries.

Cloud computing is the natural progression of the reperimeterization, consumerization, and increasingly mobility of IT we’ve witnessed over the last ten years. Cloud computing is a forcing function that is causing us to shine light on the things we do and defend not only how we do them, but who does them, and why.

To set a little context and simplify discussion, if we break down cloud computing into a visual model that depicts bite-sized chunks, it looks like this:

At the foundation of this model is the infrastructure layer that represents the traditional computer, network and storage hardware, operating systems, and virtualization platforms familiar to us all.

Cresting the model is the infostructure layer that represents the programmatic components such as applications and service objects that produce, operate on, or interact with the content, information, and metadata.

Sitting in between infrastructure and infostructure is the metastructure layer. This layer represents the underlying set of protocols and functions such as DNS, BGP, and IP address management, which “glue” together and enable the applications and content at the infostructure layer to in turn be delivered by the infrastructure.

We’ve made incremental security progress at the infrastucture and infostructure layers, but the technology underpinnings at the metastructure layer have been weighed, measured, and found lacking. The protocols that provide the glue for our fragile Internet are showing their age; BGP, DNS, and SSL are good examples.

Ultimately the most serious cloud computing concern is presented by way of the “stacked turtles” analogy: layer upon layer of complex interdependencies predicated upon fragile trust models framed upon nothing more than politeness and with complexities and issues abstracted away with additional layers of indirection. This is "cloudifornication."

The dynamism, agility and elasticity of cloud computing is, in all its glory, still predicated upon protocols and functions that were never intended to deal with these essential characteristics of cloud.

Without re-engineering these models and implementing secure protocols and the infrastructure needed to support them, we run the risk of cloud computing simply obfuscating the fragility of the supporting layers until the stack of turtles topples as something catastrophic occurs.

There are many challenges associated with the unique derivative security issues surrounding cloud computing, but we have the ability to remedy them should we so desire.

Cloud computing is a canary in the coal mine and it’s chirping wildly. It’s time to solve the problems, not the symptoms.

I look forward to diving deeper into these details with the folks at BlueHat next month in my session titled Cloudifornication: Indiscriminate Information Intercourse Involving Internet Infrastructure.

/Hoff

Hey there,

I'm pleased to announce that the BlueHat team has partnered with the dynamic Microsoft Security Response Center (MSRC) Engineering duo of Andrew Roths and Fermin J. Serna on a training video previewing the new release, version 2.0, of the Enhanced Mitigation Experience Toolkit (EMET). This training video is currently live on the BlueHat site and available for consumption on your own viewing timetable. 

I'm sure most of you are aware that EMET was designed as a living tool with the ability to incorporate future mitigations, protect against threats and improve security processes. Well, new mitigations are nearly here with version 2.0, which should be available in the near future from the Microsoft Download Center (keep a look out on the Security Research & Defense blog for the go-live announcement). In the meantime, the training video will offer you a sneak peak at EMET 2.0 including demos and insightful discussion into current and upcoming mitigation technologies. The video also showcases EMET's updated UI that shows running processes and whether EMET is currently active for them.

For those of you attending Black Hat who would like more information on the tool, Fermin Serna will be at the Microsoft booth and can answer your in-depth questions. Any feedback would definitely contribute to our efforts to build strong community-based defense to protect customers and partners against the online threats. Go grab a refreshment and enjoy this 20 minutes of BlueHat training magic!

See you in Vegas!

Celene