Working to find bugs in the software security industry is much like prospecting for natural resources. An engineer takes a high level view of an unknown piece of territory to determine the lay of the land and narrow down the geography into a few key locations of interest using intuition, experience, and macro-scale information. Next, they use analysis instruments to collect data that eventually tells them where to apply human resources to dig for GOLD! Or Oil. Or bugs!
Now, back before there were things such as accurate soil analysis instruments, there was still prospecting. It just wasn’t all that efficient. Just like in security, we’ve been finding bugs through laborious and often gut-instinct driven processes that are simply inefficient. Lately, I’ve been thinking hard about this problem and pooling resources with professionals in the security field as well as academics in the visualization field. I recently had the honor of participating on a panel at VizSec, which is held at MIT, and had presenters and attendees that stretched the globe bringing their heads together to see where visualization is going. The observation I made was that the network security folks are thinking a lot harder about visualization than those specializing in software security and I think I understand why: network data has many concrete properties that are readily consumed by existing data analysis functions and data visualization software. That is to say, they know some of the trends they’re looking for and those values are typically very literal, such as who is sending packets where and of what type, etc. I found myself trying to create parallel scenarios that would fit software security and program analysis and there certainly are some to be found (such as reachability on a graph), however for the most part, software security analysis is facing different problems due to a lack of metrics that can be plugged into functions that find trends.
So, what does this mean to software security prospectors like us in the context of visualization? It means that we need to define metrics that can be measured and then presented visually, of course! There are some good articles you can dig up from ACM on the topic, but one basis for my work has been Matt Miller’s paper titled “Improving Software Security Analysis using Exploitation Properties”. Matt’s paper introduces the concept of exploitation properties which are specific metrics that can be interpreted together to get a sense of whether an area of code is at higher risk of exploitation if a bug is present – you’re going to exploit the stack overflow that isn’t protected by GS before you try to work around the one that is protected with GS, right? Expand this concept a bit and you can begin to collect metrics beyond exploitability that may help improve software security or maintainability.
So my upcoming talk at BlueHat will focus on two areas of concern: what do these metrics look like and what do proper visualizations of multi-dimensional data look like. We have some interesting challenges because not all of our metrics are as reliable as others. In fact, off-the-shelf bug finding tools are often heuristic based and can be highly unreliable, but that just means we have a unique opportunity to take large data sets and correlate them to find out where the real gold is buried.
-Richard Johnson, Security Software Development Engineer, Trustworthy Computing, Microsoft
Another six months has passed – must be time for BlueHat, Microsoft’s internal security conference.
This one is shaping up to be an interesting one. The early BlueHats were all about the raw technology – Shok blowing out the memory manager, Brett Moore facepalming over yet another file format vulnerability. But determining vulnerability requires more than just understanding technology. At the end of the day, there are bad guys, and bad guys don’t necessarily have to take the geekiest of routes to get what they want. So there’s an interesting thread that appears to run through many of the talks this year, linking what we are capable of doing as engineers, with what attackers have been doing as criminals.
For my part, I’ll be talking (unsurprisingly) about the DNS vulnerabilities that made a bit of noise earlier this summer. That was quite the experience, and indeed, continues to be. DNSSEC is making astonishing progress – there’s no question about that. It’s also not going to be deployed on 99% of authoritative servers anytime soon – even .GOV is looking at two years to get coverage across their bailiwick. And the numbers for the pragmatic fix (Source Port Randomization) continue to be astonishingly good. But there is indeed demand for better, and one of the interesting things I’ll be able to discuss is:
What now? What should the next interim fix look like? What is the full set of scenarios that needs to be covered, to justify going through another patch cycle? What sort of real-world deployments do we need to be compatible with?
And why do we have to fix this, anyway? Why are so many things broken, to the point that they fail trivially when attacked by a basic man-in-the-middle?
These are hard questions. The answers to them are not all to be found in DNS, or even just in technology. What has been a clear and fascinating realization is that not just this one vulnerability, but all the major vulnerabilities of 2008 have all been linked to a complete failure to authenticate. Whether it’s Mike Perry finding that many (most?) SSL sites leak their authentication cookies out to unencrypted parties, or it’s Mike Zusman finding that many (most?) SSL-VPN’s don’t actually validate that they’re encrypting their payloads to anyone in particular, or it’s Wes Hardakar finding out that SNMPv3 barely makes a user authenticate at all – a remarkable number of problems are all being found that trace back to us having no idea who we’re talking to.
Identity is not, and never will be, merely a problem of technology. It will take tech to fix – but it will take something more, too. It will take some work to figure out exactly what that something will be – but we have at least one significant data point showing a shocking number of companies expending a tremendous amount of effort, all in pursuit of doing the right thing for themselves and for their customers. We can, and should, learn from this experience, and I look forward to exploring this all at BlueHat.
Dan Kaminsky, IOActive
The Wikipedia page for Natural Language Processing (not the Darren Brown stuff) describes it as “a subfield of artificial intelligence and computational linguistics.” So why am I discussing this on the BlueHat blog? If, like me, you sucked at linguistics in school, you might think that it has no place in IT security. However, the more I play with NLP, the more excited I get about the possible applications it could have in information gathering -- and thus in IT security.
For the past 18 months or so I have been pouring my heart, my mind and my wallet into Maltego, a framework that is used for information collection. Maltego consists of ‘entities’ and ‘transforms’ – and allows you to convert (or transform) one type of entity to another. As a simple example you might think of a DNS Name entity and an IP Address entity, where a Transform would simply resolve the DNS Name to an IP Address, or the reverse, resolve the IP Address to a DNS Name. It turns out that information is a lot more connected than I originally thought and as of now we’ve created more than 100 transforms on about 15 entities types. To take the DNS/IP address example further, an IP address is located within a network which has ‘whois’ information (and geo-location information) which leads to names, e-mail addresses, and phone numbers which lead to persons, domains (from the e-mail address) and geo-locations, which in turn lead to other entities and so on and so forth – to a never ending mesh of loosely related chunks of information that can be visualized on a graph as a set of inter-connected nodes.
Anyhow – back to NLP. I spent last week fiddling with NLP transforms for Maltego, specifically building Information Extraction into Maltego. Information Extraction is a specific application of NLP and if you integrate it into a framework where automation and correlation is possible, then it becomes very interesting. For the first time I get the feeling that I can actually discover information that’s ‘hidden in plain sight’. At the moment the stuff is still unstable and eats CPUs and memory as fast as a pre-lunch snack but we’re working on making it more stable and production ready.
Information extraction is used to extract ‘entities’ from text. As an example, it will be able to look at a web page and extract all the person names from the page. It can also extract the organization names and the location names. In fact, it can extract anything that can be programmatically described from text. Given time, it will even be able to extract the ‘facts’ from the page. This means that if you have four web pages that basically say the same thing NLP will be able to connect the pages. And for the first time, I have the ability to give ‘human-like’ functionality to a transform.
Again – why is this interesting for security people?
Let’s look at a very concrete example. Suppose you are doing a footprint for a multi-national company. We all know these guys could have thousands of domains. Let’s assume that you have some method of collecting the odd 500 domains which you think might be associated with the organization. These domains are in multiple countries, each registered at a different registrar, and each registrar has its own method for formatting ‘whois’ information. So even if you manage to collect all the ‘whois’ information, you have no way of properly formatting the information so that you can easily grep for the target organization. Using NLP you don’t need to worry about it, you can tell your Information Extractor to simply extract organization names from the collected data. Without NLP, you will either need to write a parser for every format or you need to eyeball every ‘whois’ result.
Not convinced? Sure – perhaps you’ve never experienced the joys of doing a footprint. So let’s look at something else. Let’s say you want to know who are the key figures associated with a specific phrase. Your phrase could be something like “High ranking diplomats” or even a company name. You can feed the phrase to your favourite search engine and get a list of URLs where the phrase appears (in the first example you’ll want to restrict the results to a specific domain or country). Next, you can feed all the text on the resulting web pages to your Information extraction engine – it will neatly ‘parse’ the text into person names. And voila – within minutes you have a list of names. If you use something like Maltego to do this you can now get an idea who is the most prominent (or most vocal) person is – as some names will be mentioned on more than one page.
So let’s try it – the proof of the pudding etc. Let’s run the process on a phrase where we can verify the results. Using the phrase ”BlueHat conference” as a starting point, we end up with a graph that looks like this:
From the graph we quickly see all the usual suspects. Of course the program cannot give any kind of context to results. For instance it won’t tell you that Ryan Naraine is a reporter that covers IT security and that Andrew Cushman organises the conference. Also, the graph is littered with false positives, but this is a mere annoyance as it disappears as white noise when looking at the frequency of extracted entities.
You may say ”but I knew these people were key figures at BlueHat – what’s the big deal?“ Well – consider that you can enter ANY phrase into the system and minutes later know who the key players are. When we combine this kind of functionality with other gathering techniques for open source information, it becomes a bit frightening. Consider a process that subsequently looks up these people’s e-mail addresses and start sending custom crafted malware (although, the list above would hardly be good candidates) or perhaps automatically resolve social network memberships, and where possible, create fake identities. Bottom line – if you are looking to attack individuals connected to a certain ‘phrase’ in an automated fashion you first need to know who they are.
Real life, practical hacking is really all about collecting information. The people who have been doing this for a while will tell you that an exploit is really only 5% of the entire exercise. Of course you don’t need to always have the evil bit set, mining the Internet for information is very useful for law enforcement, intelligence agencies or anyone that simply wants to gain insight into a subject.
In the past you could have hoped to fool e-mail address harvesters by writing your email address as roelof at paterva dot com. With NLP you can run...but you can’t hide.
R.o.e.l.o.f T.e.m.m.i.n.g.h
PS: NLP implementations are hairy beasts that breathe fire, with sharp teeth, complex eyes and many legs. I think of it as a big black box filled with magic -- but as long as I can get a slice of magic, I am quite happy.
Andrew Cushman back again.
BlueHat v8 is October 15th, 16th and 17th on the Microsoft campus in Redmond. The BlueHat team selected content that’s especially interesting and topical for Microsoft engineers and execs. We start it off with an Exec Day on the 15th – condensed versions of the presentations – still deeply technical – just delivered faster and with fewer graphics and demos. Then two days of general sessions – the morning of day one is the, by now traditional, focus on emerging security threats and in the afternoon on state of the art hacking tools and techniques. Day two covers Security Development Lifecycle (SDL) – a whole day’s content focused on the full lifecycle of security engineering – with a progression from design, to implementation, to verification.
Over the past four years, BlueHat has expanded and grown. It’s gratifying to see the progress and the impact BlueHat has internally at Microsoft and that it’s starting to have in the larger ecosystem. The two original goals still apply and guide the conference:
- Expose senior product leaders and front line engineers to the threats, attack tools and methodologies used in the real world; take the security threat from the theoretical/intellectual level of, “I understand what a buffer overflow is,” to “OMG that’s what it’s like.” BlueHat connects with execs and engineers at a visceral level and *really* brings the message home.
- Expose security researchers (and the security community) to Microsoft engineers and business leaders. BlueHat gives us a chance to open up on our home turf and give researchers an opportunity to interact with all levels of the organization. They get to experience first-hand that Microsoft does have smart, passionate engineers that do care about security.
For the eighth edition of BlueHat we have explicitly added a new goal:
- To promote a community based defense agenda. BlueHat seeks to leverage Microsoft’s unique place in the ecosystem and our unique set of relationships to make bridging connections between diverse ecosystem constituents and to the foster dialog necessary to breathe life into mantra of “it takes a village”.
Here’s a brief overview of the talks and speakers. Full details will be available on the BlueHat web site within the week.
Day 1
We’ll start day 1 of the general sessions with a focus on crimeware. Iftach Amit from Alladin will give us a glimpse into the intricate workings of supply and demand, the pricing models, distribution models and the sophistication of the development environment.
Next up, in the “what could possibly go wrong” category, a couple talks about the unintended consequences of the social networking phenomenon and the explosion of information on the Internet. Nitesh Dhanjani (Ernst & Young) teams up with Akshay Aggarwal from Microsoft’s ACE team to talk about how your online persona and activity can be tracked, correlated and used to influence behavior.
Roelof Temming (Paterva) covers a similar topic but more broadly and (if possible) with even bigger implications to online communities. Roelof will show how the Maltego framework can collect and correlate public information and create a comprehensive profile of a person or a group / organization. He’ll also describe how the lack of true identity on the net can result in the creation of imaginary friends and wholesale fictitious virtual communities which can be used for anything from stock market manipulation to political gain.
We’ll round out the threat portion of the day with presentations on how old favorites like Cascading Style Sheets and DNS are being abused in new ways. David Lindsay (Security Innovation), Gareth Heyes & Eduardo Vela will detail how CSS can be used for a lot more than making a website look sexy – e.g., how to scan an internal network, to track visited links on third-party websites, or read the content of third-party websites. Dan Kaminsky (IOActive) also makes a return to BlueHat. Dan asked us not to disclose the details of his talk (or at least give him 30 days from the announcement), so we’re not exactly sure what Dan’s going to talk about. But we’re really glad to have him back again. <wink>
We’ll have two presentations from SWI – Richard Johnson and Ian Hellen. Richard will discuss several visualization techniques and their usability in software security. He’ll also demo internally developed processes for creating visualizations of data from static analysis. Ian will recap lessons learned from the security review process for Windows and discuss methods to identify high risk components that need special attention in the form of design and code reviews.
Day 2
We’ll start day two with a couple talks on Threat Modeling – Danny Dhillon will share EMC’s experience applying threat modeling to the EMC development process and Adam Shostack will discuss Microsoft’s approach and publicly demonstrate the new SDL Threat Modeling tool used by Microsoft development teams.
SDL day also features a return by a true leviathan in the industry – Matt Miller returns to BlueHat, this time on the SDL track to discuss the evolution of sophisticated exploitation techniques and the corresponding development of equally sophisticated mitigations such as GS, DEP, and ASLR. This presentation explores the technical details of these developments by illustrating the logical evolution of Microsoft’s mitigations and how well each mitigation has fared.
Scott Stender and Alex Vidergar from iSEC Partners kick off the afternoon, demonstrating concurrency attacks on web applications. They will provide insight into the ease with which concurrency flaws can be introduced into systems, offer guidance on evaluating the security impact of such flaws, and discuss strategies for eliminating such flaws, helping developers and testers alike.
A trio from the SWI team will discuss several aspects of fuzzing: How should I fuzz? When have I fuzzed enough? What do I do now that I’ve fuzzed? Jason Shirk, Lars Opstad and Dave Weinstein will compare fuzzing models (dumb vs. smart) and highlight the merits of several approaches. They will use real world examples to discuss the many variables at play when considering how much fuzzing is enough.
Vinnie Liu is back again – this time talking about code audits. He’ll provide a thorough and objective review of the benefits, shortcomings, and trade‑offs of static code analysis tools, black box application scanners and provide recommendations for which activities are best done by machine.
And we’ll wrap the SDL day, and the conference, with a panel discussion that asks, “Is all of this SDL stuff really necessary? Why not just slap a Web Application Firewall on all of our online properties and avoid the muss and fuss of 100+ SDL requirements?” This is not a rhetorical question! Our panelists, Arian Evans of White Hat Security, Mike Andrews of Foundstone, the SDL team’s Bryan Sullivan, and Nate McFeters from Ernst & Young will seriously discuss this issue and come to a conclusion.
We continue to expand the BlueHat blog and the TechNet site to keep you up-to-date on the happenings at the conference. We’ll update both regularly with new blog entries and video podcasts.
-Andrew
Hi, Amit Klein from Trusteer here.
Awhile ago, David Ross from Microsoft SWI contacted me and asked me if I would like to review the new Internet Explorer 8 XSS Filter. Does a chicken like to peck? ;-) Of course I volunteered. My review was conducted in a rather interesting manner. I did not have access to the filter itself. Not sure whether this was intentional or not, but it turned out well, in my opinion. Instead of banging my head against the live filter, David and I engaged in a series of discussions (mostly me asking questions and David answering them) around the filter’s architecture and algorithms. At some point David gave me the architecture overview (which is now publicly available). Based on the information David provided, I came up with potential issues/vulnerabilities/attacks, which we then discussed, and through these discussions I learned a bit more, leading me to revise my mental model of the filter, and in turn leading to more potential attacks, and so forth. I was much impressed with the work already conducted by Microsoft around securing the XSS Filter. While the beta 2 filter is not perfect, keep in mind that the full version (in IE 8) of the filter will be based on a slightly different implementation, as well as (I hope) on the feedback gathered by Microsoft from all the individuals who reviewed the beta filter. I do believe this will enable Microsoft to deliver a very powerful filter for the full IE 8 version.
The good
Overall, I think the XSS Filter is a great move from Microsoft in reducing the attack surface of the most prevalent XSS flavor. And as I said, I’m impressed with the extent of work Microsoft invested in it, and the coverage of the filter. It was apparent from my discussions with David that the Microsoft folks are well versed in the current corpus of knowledge around XSS – they sure did their homework over in Redmond. Now, I’m confident that deficiencies in the filter will crop up, but think of it this way: without the filter, XSS (I’m talking type-1 only here) exploitation depends solely on the existence of the XSS vulnerability in the application. Find it, and you’re golden. With an IE 8 client (victim), you need to find the XSS vulnerability in the application, and hope that it will be aligned with the vulnerability in the filter. How likely is that? Probably not too likely. So XSS exploitability is drastically reduced. It’s a classic 80-20-rule decision.
The bad
The XSS Filter only attempts to filter “type-1” (AKA “non-persistent”/”reflective”) XSS. It doesn’t handle “type-0” (AKA “DOM based”) XSS and “type-2” (AKA “persistent”/“stored”) XSS. I want to stress that this is clearly stated by Microsoft (‘The Internet Explorer 8 XSS Filter is intended to mitigate reflected / “Type-1” XSS vulnerabilities’). So handling type-1 XSS (only) is by design. And justly so, as type-0 and type-2 do not necessarily reflect the injected string into the response page. Handling them would have required a totally different architecture.
My fear though is that people (the slightly less technical) will read the title “XSS Filter” for what it is, and as such it will be considered a solution for all types of XSS. In turn, this may lead to frustration and misunderstanding.
In other words, my concern here is more with messaging/positioning, than in the actual performance of the filter.
The ugly
The filter can selectively deactivate client side scripting, which is a bit of a concern to me. The reference threat is a malicious site framing another (victim) site. By carefully crafting the frame URL, the attacker can deactivate some (perhaps all) script tags in the frame. This makes me a bit uncomfortable. However, David righteously commented that this “feature” already exists in a way in the form of setting the frame’s security attribute to “restricted”. So there’s no news here…
Summary
The IE 8 XSS Filter is a great step forward in web security. However, it’s not (at least currently) a conclusive solution to the XSS problem, so web developers are still advised to follow secure programming practices when coding their applications.
I truly enjoyed reviewing the filter and working with Microsoft (and particularly with David Ross) on improving it. And while we’re there - I see Microsoft’s openness and reaching out to non-Microsoft security researchers an indication of our web security community getting mature. So there’s still hope after all ;-)
Thanks for reading,
-Amit
The sniper
Normal fuzzing is like shooting a machine gun in the dark and having no idea where the target is. You might hit the target a number of times, but you also miss an awful lot, and it takes a lot of rounds. Using targeted fuzzing, on the other hand, is a bit like a sniper observing the targets and picking them off one by one. I prefer the sniper approach because, although you may not get a wide range of results, you will often get more meaningful data and let’s face it, snipers are cool. :)
XSS Filter and the javascript protocol
I contract for Microsoft testing the security of the XSS Filter, which is due to be released soon in the next version of Internet Explorer. Part of this work involves making sure that XSS Filter successfully detects javascript protocol injections in various ways. I saw this as an ideal opportunity to perform some targeted fuzzing to obtain every possible combination.
The first task was to gather as many known inputs as possible, javascript: can be represented in various ways as I'm sure you're aware of like javascript:, for example. Then you gather any unknown input combinations. So in this case you can traverse the amount of characters from 0 to 65535 or more, and either replace part of the string or add to it. In addition to this, you can also encode the character in different ways as mentioned previously, �  etc. The standard way of performing such a fuzz would be to use iframes because this allows you to execute javascript: automatically, however, I encountered a problem using this method; It's very slow and takes up too much memory for the amount of data I wanted to test.
Making a targeted fuzzer is about understanding how to achieve your goal in the quickest possible time and finding your targets quickly. To do this, I decided to use the browser to my advantage, when creating links in any browser it is possible to find if that link uses a certain protocol like HTTP and also javascript:. I decided to let the browser tell me if my fuzz was successful. Using normal <A> links makes the fuzzer much faster and it was possible to scan around 10,000 links at once. Using this speed, it was possible to scan characters 0 to 65535, and if they were URL encoded, HTML entities, replace or add in every combination in only a few minutes.
If you found the Javascript protocol fuzzer interesting, the source code can be found here:
http://www.businessinfo.co.uk/labs/javascript_protocol_fuzzer/javascript_protocol_fuzzer.phps
A demo of the final result can be viewed here:-
http://www.businessinfo.co.uk/labs/javascript_protocol_fuzzer/javascript_protocol_fuzzer.php
Logging the results
The protocol fuzzer I described had a huge advantage over traditional fuzzing, because the data didn't cause a browser crash, it was possible to log all results without any problems. I did this using a standard JavaScript logger, which involves creating a dynamic image in JavaScript and sending the results to a server side script like the following code:
var logger = new Image();
logger.src='yoururl.php?link='+yourdata;
What if your goal is to crash the browser? I came across this exact problem when working on another project for Microsoft. There are two ways to achieve this, one is to log the results before sending the output and the other is to remotely control the target and have the fuzzing code sent to the target. I decided because I was interested in how to crash the browser once with the code I supplied, I would log the results first before sending the output to the browser. You can do this in PHP by using output buffering; other languages may have similar features. Output buffering works by constructing the page before sending it to the browser, this is ideal because you can log the results and then send the data and see what happens. Here is a simple code snippet that I used:-
<?php
function saveCache($buffer) {
$fp = fopen('cache.txt', 'w') or die('unable to open');
fwrite($fp, $buffer); // Log the results
fclose($fp);
return $buffer;
}
ob_start("saveCache"); // Don't send it to the browser yet
?>
Your fuzz output here
ob_end_flush(); // Send the output to the browser
My fuzzer proved very successful and enabled me to perform some rigorous testing on the XSS filter to make sure it detected many javascript protocol injections. Because the code I wrote worked across browsers it also found some interesting cross browser issues which was an added bonus. Here's a small sample of some interesting results it found in Firefox 2.0.0.14:-
Char: 56320, link: jav�ascript:
Char: 56321, link: jav�ascript:
Char: 56322, link: jav�ascript:
I hope you enjoyed my article and I hope to see you all at BlueHat this October. Happy sniping.
-Gareth Heyes, Independent Security Researcher
Let me tell you about a great business plan I ran into recently. It’s not the traditional “we’re all going to make millions” operation, but it has some characteristics you’ll relate to if you have ever tried to pitch a startup idea to a VC …
This is a business that has remarkably innovative financing and sales/marketing operations. Almost a bootstrapping model, getting the business started does not require any more than an initial investment of let’s say $1,000 (now that is something you don’t see a lot of with VC pitches). Are you interested yet? This $1,000 goes into the basics – infrastructure and the initial “wages” for your sales channels. (Yes – we are building on a pure channel partner program, as we are not that great in direct sales….) You’ll plan on recovering these in a short term of let’s say a couple of months, if not doubling your investment by then.
Okay, I’m not going to keep you waiting for too long – the business I’m talking about is one that I have spent days (and nights) researching and analyzing over the past year. It’s the business of making money online – e-crime. This business is really close to you – you’ve seen it on sites such as CNN, eBay, your online banking provider, and other major news/finance/entertainment portals. You’re closer to it than you may realize, as the “channels” I have mentioned earlier are in full utilization and can get to YOUR favorites list. And this is not all sci-fi – I have had a chance to spend some quality time with a few law enforcement agencies and correlate my data with their findings. There’s nothing like seeing an organization chart of the national organized crime at a police intelligence office, and overlapping it with the e-crime data brought in from the security research side!
Covering this area is an intriguing mix of business, finance, and a lot of technical forensics that really provides a view of the big picture. From understanding and following the distribution payout business models, through the internal update mechanisms of custom toolkits (and their “phone home” licensing mechanisms – see the image below showing how Neosploit is contacting it’s licensing server as seen from an IDA disassembly of the toolkit).
All in all, I would say that this area of research is one of the most challenging I have had a chance to be involved with. The variety of skills required (technical, business, finance and sometimes social…) is what I perceive would be required from any modern security researcher getting into this field (and us veterans know that the adaptation is fun!). Getting into the details of the kind of operation that has such a direct impact on how web security is perceived by the general public, by corporations who get hit by targeted ROI-driven attacks, and by security vendors and researchers trying to find the right solutions and stay ahead of the curve, has proven to be a real eye-opener. And this is coming from a guy that used to do UNIX security, then network stuff, application security in the heyday of 2000, and now business/technical of e-crime.
Looking forward to seeing a lot of old (and new) friends while I’ll be presenting at BlueHat v8 this October, and until then – promise to keep collecting anecdotes and code for what I hope will be an entertaining and informational talk.
Iftach Ian Amit
Director, Security Research, Aladdin
…and says “Make me one with everything.” Aside from that fact that most hot dog vendors don’t carry Tofu Pups, we’re taking this joke seriously for the next iteration of BlueHat, and giving you some attack content as well as talking about proactive defense.
Coming this October, the BlueHat team will partner with the SDL team to create two full days of content, the first day focusing on new attacks and the emerging threat horizon, and the second day focusing on steps we can take as software architects, developers, testers, and maintainers to make code more secure in the first place.
Stay tuned for guest blog posts here and on the SDL blog from both sets of speakers, with topics ranging from attack to defense. It’s about changing the balance between attackers and defenders; it’s about showing both sides of the same coin; and it’s about time.
Katie Moussouris, Security Strategist II
Bryan Sullivan, Security Program Manager
Hello everyone, this is Robert "RSnake" Hansen. It’s been a while since I’ve talked with the BlueHat folks but only because I’ve been busy behind the scenes working on some cool stuff with the Microsofties. I was pleasantly surprised to hear I am now allowed to talk about one of the things I have helped work on. David Ross mentioned it in a blog post he wrote some time ago, but it has come a long way from that point. He called it “XSS-Focused Attack Surface Reduction goodness” for lack of a better term, but now I think we’ve happily settled on a shorter and more memorable name - “XSSFilter.”
In Internet Explorer 8.0, users will be protected from the vast majority of real world XSS attacks. David spent a lot of time analyzing the most common variants and has built a tool to isolate and protect against those attacks for the vast majority of Internet users out there. The tool protects against reflected XSS in particular, and not against the lesser common DOM or persistent XSS varieties. XSSFilter is certainly not a panacea and it’s still recommended that developers follow good programming practices, but this comes as welcome news to me personally and the vast majority of Internet users who will be protected from an attack they probably couldn’t even spell. And best of all, it will be by default – asking consumers to install security plug-ins has never worked well. Taking it out of the consumer’s hands is a huge leap forward.
I’ve been talking about browser security for quite a while in my speeches and on my site – we can’t expect programmers to fix all their flaws, especially in legacy applications. The browser is one of the few important choke points on the Internet, where client side issues can be heavily mitigated and we can begin to get ahead of the problem. Indeed, XSS is a prime example of what can happen when attackers start using the browser as a conduit for attacks against web applications and consumers. Since we know it’ll be a long time (or maybe even never) until we see every critical web application protecting itself, this is a great short term stop-gap for the vast majority of XSS issues against the Internet Explorer browser.
Only time will tell how attackers move and adjust to these changes, but in the near term, I’m happy to have played a small part in adding one more weapon in the fight to protect consumers.
After a whirlwind trip to beautiful Honolulu, Hawaii to give the Day 2 keynote at ShakaCon, I am finally back to reality here at Microsoft. More on that shortly, from another blog...
Right here, right now, BlueHat video interviews with the speakers are available. From "Bad Sushi: Beating Phishers at Their Own Game" with our own Billy Rios to "Token Kidnapping" with Cesar Cerrudo of Argeniss -- get an exclusive sneak peek into what really happened at BlueHat v7.
Or play a game with your friends: How many times do Dan Kaminsky and I say "RickRoll" during his interview? Submit your answer in the comments of this blog. First correct answer will receive a prize if you come see me, Mike Reavey, and Captain Steve Adegbite at Black Hat this July! Be sure to also see Billy Rios, Bryan Sullivan, Bruce Dang, and David Weston.
Aloha!
Katie Moussouris, Security Strategist