Well, in case you don’t subscribe, I’m now the official editor of the Microsoft Technical Audience Security Newsletter. It’s nice to actually get a security professional as the actual owner of the newsletter, and hopefully I’ll be able to weed out the material that’s not related to our topic. That being said, we also want to start including some material that is pertinent to you not only in a “hard skill, how do I install/configure Microsoft’s Product X?”, but we also want to be sure that we have some good information out there that will assist you in the current economic situation that we now find ourselves. Yes, even the once booming world of information security has been hit by the bad economy. To that end, I would like to start covering some things like professional career advice, how to build those business skills, how to tweak your resume, etc. I think these will all be of great benefit.
Also, I want to hear your valid feedback. Don’t email me about how you ‘re sent in money to some Nigerian prince and you haven’t seen your money since. Also, don’t fire up an email to ask me why your machine tends to BSOD with a STOP 0x7E when you install that driver you wrote in your garage. If I don’t see valid suggestions about topics to discuss or ways to make this security newsletter better….it’s getting deleted.
This month we’re talking about database security. Good ‘ol SQL Injection. Get ready….it’s going to be a fun ride.
- Kai
Those of you that have been reading my blog a while know that part of my interest in security metrics is in trying to find ways to measure if Microsoft efforts to improve fundamental in security products is bearing fruit. Central to the Microsoft efforts is the Security Development Lifecycle process.
One of the cool efforts that has been happening over the past couple of years is that the SDL team (read their blog!) has been taking tools and technology that was developed internally to support the Microsoft SDL process and releasing it, cost free, to the community so that the tools could be leveraged by all types of developers. (I say “all types” and that’s true, though in some cases the tools either do more or were designed to work primarily with Visual Studio projects. Tools like MiniFuzz, though, can be used to fuzz applications regardless of the development tools used.)
Today the SDL team are making available BinScope Binary Analyzer and MiniFuzz File Fuzzer as no cost downloads.
We put together a couple of demo videos also. You can find them on edge.technet.com on this links (BinScope video, MiniFuzz video) or you can watched the embedded videos directly in this post below.
BinScope Binary Analyzer
The BinScope Binary Analyzer is an SDL-required security tool that has been used by Microsoft teams since the early days of the SDL. It analyzes your binaries for a wide variety of security protections with a very straightforward and easy-to-use interface. At Microsoft, developers and testers are required to use this tool in the Verification Phase of the SDL to ensure that they have built their code using the compiler/linker protections required by the Microsoft SDL.
The analyzer performs a diverse set of security checks. These checks include:
- /GS flag is being set to detect stack-based buffer overflows
- /SafeSEH flag is being set to enable and ensure safe exception handling
- /NXCOMPAT flag is being set to enforce data execution prevention (NX)
- /DYNAMICBASE flag is being set to enable Address Space Layout Randomization (ASLR)
- .NET Strong-Named Assemblies are being used to ensure unique key pairs and strong integrity checks are in place
- Known good ATL headers are being used
- Up-to-date compiler and linker versions are being used (minimum Visual Studio 2005 SP2)
- Reports on dangerous constructs that are prohibited/discouraged by the SDL (e.g. read/write shared sections, global function pointers).
Watch this video to get an overview and see a demonstration of BinScope in action:
MiniFuzz File Fuzzer
The MiniFuzz File Fuzzer is a very simple fuzzer designed to ease adoption of fuzz testing by non-security people who are unfamiliar with file fuzzing tools or have never used them in their software development processes. A less capable and non-graphical version of this tool was originally published on the CD that came with the book The Security Development Lifecycle by Steve Lipner and Michael Howard. Since that tool was effective at finding quality bugs, we wanted to offer it more widely along with our other SDL tools, improve the user experience, and provide integration with Visual Studio and Team foundation Server.
Because we have found fuzzing to be effective at finding bugs, it is a required activity in the Verification Phase of the Microsoft Security Development Lifecycle (SDL). With the release of the MiniFuzz File Fuzzer, we have made a simple file fuzzer available to assist developer efforts to find and address more security bugs in code before it ships to customers. Simply provide the tool with a set of correctly formed files to serve as templates, and it will generate corrupted versions for testing. The effectiveness of fuzz testing can be increased by providing more variation in the template files.
Watch this video to get an overview and see a demonstration of BinScope in action:
Resources and Other Information
These tools are not the first ones that the SDL team has made available. Check out the SDL Tools Repository to download BinScope Binary Analyzer and MiniFuzz File Fuzzer, as well as other tools like FxCop, the SDL Process Template for Visual Studio Team System, the SDL Threat Modeling tool, CAT.NET and the Anti-XSS library.
Best regards ~ Jeff
Well, I've been in the Xbox Live team for the past 3 days and my head is swimming! I had never thought about all the work that goes into keeping Xbox Live up and operational, but now that I'm here and get to see it, it's pretty remarkable. There is a large team working around the clock to make sure that gamers around the world can get on their Xboxes and have a troublefree experience whenever they want to.
Anyway, I'll have more to post down the road, but right now I'm still focusing on getting my feet underneath me so I can start contributing.
I recently attended BlueHat for the second time and spoke about the SMS vulnerabilities Collin Mulliner and I discovered and exploited this summer. BlueHat is an interesting speaking venue because the audience consists entirely of Microsoft employees. Some people might think security researchers speaking at Microsoft is like speaking before the enemy, but that is not the case (an actual example of that would have been when I talked about exploit sales at CERT a few years ago). The people I spoke with at Microsoft seemed genuinely interested in listening to what I had to say, learning how I look for bugs, and generally, how the adversary thinks. I think this is a good sign they take security pretty seriously, at least on some level. Hopefully, they got some value in listening to how I attack applications.
From my perspective, BlueHat is always very rewarding. I get a chance to speak with the folks at Microsoft who are in charge of product security. This year, I sat down with a large group responsible for the security of Windows Mobile. It’s always fascinating to hear what they are planning to do, what they were thinking when they made various decisions, what tools they have at their disposal, etc. However, just like I don't tell them all my secrets, I'm sure they keep a few of their own, but I got the feeling that they were willing to tell me more about how they work than the last time I was out there, which is another positive sign.
There is the old Sun Tzu quote that goes 'know thy enemy'. It’s not clear that this is entirely appropriate here, but BlueHat does provide a way for Microsoft employees to sit down and talk with top security researchers and I think both groups benefit from it by gaining insight into how the other group thinks. Now if only I could get them to stop automatically rebooting my computer and corrupting my IDA Pro databases....
-Charlie Miller, Independent Security Evaluators
Billy Rios here. I’m giving a talk this week along with Nate McFeters entitled, “Sharing the Cloud with Your Enemy.” It’s a fun, realistic talk on security in the cloud. Why cloud computing?
Cloud computing, software as a service, infrastructure as a service, platform as a service… with so many different terms and so much hype, this cloud computing stuff can be confusing and understanding security in the cloud can be even more confusing! Nate and I will break down some of the most relevant security challenges we see for the cloud “Barney” style so that even my nine-month old daughter (or your average everyday CSO) can understand them. How are we going to do this, you may ask? Well, up until this point, we’ve seen a lot of theoretical scenarios related to cloud security.
In our presentation, we’ll cover some important cloud security concepts and back them up with some real-life vulnerabilities we’ve discovered. These vulnerabilities are neat but more importantly, they highlight some hard hitting, real-life issues anyone considering adopting a cloud computing platform needs to consider. We’ll cover some questions that every business should be asking their cloud provider and we’ll also use some of the vulnerabilities we’ve discovered to highlight areas cloud providers can improve on (there are plenty of areas). The content we’ve put together is appropriate for all audiences, but especially geared towards cloud providers and those wishing to implement cloud solutions for their business.
Come in from the Seattle rain, grab a cup of coffee, and join us for an entertaining, yet stimulating talk on cloud security. The cloud providers we’ve chosen to highlight are some of the biggest in the industry, the vulnerabilities are real, and the presenters are some of the sexiest on the planet… what more could you ask for?
This year at BlackHat USA in Las Vegas, we presented on the topic of attacking Short Message Service (SMS). Our presentation focused on the different ways in which SMS can be used to compromise mobile security. We’re excited to give an updated version of our talk at the upcoming BlueHat v9 conference later this month, and thought the BlueHat blog readers who will not be able to attend might enjoy an overview of some key material from the presentation.
Why attack SMS – When we first started looking at SMS, two things immediately leapt out to us that made it an interesting attack surface. The first was that there is far more functionality delivered via SMS than the simple text messages that everyone is familiar with. For example, SMS can be used to reach other rich attack surfaces such as graphic libraries and video codecs. These are two areas which have contained extensive vulnerabilities in the past. The second item which makes SMS interesting to analyze is that it is always turned on (and ready to be attacked). SMS messages are delivered to mobile phones via the paging channel that the network uses to notify the phone of important information such as an incoming call. Therefore, it is extremely difficult to tell a mobile phone to not receive an incoming SMS as the phone always needs to listen on this interface. Additionally, the network is built to make a best effort to deliver an SMS to a recipient, which makes attacking even easier. If the target is offline or out of range it does not matter to the attacker, as the network will typically store the attack message until the target comes online and then will deliver it.
Attacks – In our presentation, we break down the attacks we discuss into three categories: Implementation, Configuration, and Architecture.
The first category of attacks we discuss is implementation flaws in the messaging software on mobile phones. We started with the assumption that any crash we triggered would likely be localized to the messaging application. We were surprised to find that crashes commonly occurred at a much lower layer that would knock the phone's radio interface offline. This would then prevent the phone from placing or receiving calls and SMS traffic, sometimes even across multiple reboots of the device.
The second category of attacks we discuss is a case study of a configuration flaw that affected a number of mobile devices. Those of us working in application security are used to one vendor having direct responsibility for a product. In the mobile world, things operate differently. Instead of each application being the responsibility of a single vendor, there are three main players: the carrier, the hardware OEM who makes the device, and the operating system vendor. When a vulnerability is found in a given piece of software, the responsible vendor ships a patch for that vulnerability. As has been shown with multiple real-world devices, one of the parties can make a change to the configuration of the device that results in the final product shipping with an insecure configuration.
The final category of attacks we discuss relates to the security architecture of SMS. As we mentioned before, there is a lot of administrative functionality on mobile phones that makes use of SMS. A straightforward example of this functionality is voicemail notifications - a carrier can notify a subscriber that they have a voicemail message waiting by sending a specially crafted SMS to their mobile phone. Most phones respond to this message by executing an administrative action, such as popping up a notification to the user. Obviously, an administrative message type such as this should only be generated and sent by the carrier’s equipment. During the course of our research, we found that there are a number of administrative SMS message types that we were able to send as a peer device on the carrier network. Some of these message types can have significant security implications to the mobile phone, unlike a simple voicemail notification.
Conclusion - SMS and mobile devices in general offer an intriguing area for future security research, especially as mobile devices store increasingly sensitive information. We are looking forward to spending time at BlueHat doing a much deeper dive into the topics we have begun to introduce in this blog post.
- Zane Lackey (iSEC Partners), Luis Miras (Independent Security Researcher)
Hello world! Remember Mad Libs? How about Scrabble, when you'd try making up words that sound legit just to be de-bluffed by your friend. Playing these games provides endless hours of fun with words and letters. In software and the Internet, words, letters, and text are everything. Whether you're up in the cloud, down in the code, or consuming the content—written language is the information that’s central to it all.
Unicode provides a set of standards for representing most of the world's languages and scripts within a single framework. It’s pretty awesome really—the ability to capture the world’s scripts past, present, and future. Where else would you find a character set that encodes everything from ASCII (Latin) to the symbols of the ancient Phaistos Disc, such as this PLUMED HEAD: 
Unicode has come to be the de facto system for representing and encoding characters across any computing platform. It's central to most modern operating systems, programming languages, and applications. But, similar to a networking protocol stack, most software developers don't want to wrangle with the details. It should be good enough to know that your strings are handled as Unicode, so you can build your software without sorting out the complex details of charset transcoding, normalization, etc.
Still, there are attacks and countermeasures that should be known. In my BlueHat presentation I intend to cover two broad categories—one around visual perception attacks, and the other around character transformations. In the cloud, URL's rule. Okay, URI has superseded URL and, with Unicode, we should be talking about IRI (Internationalized Resource Identifier). But anyway, with the growth of Internationalized Domain Names (IDNs), IRIs have just as much a place as do URIs. What I'm really concerned with are the domain names, the IDNs. We saw early visual spoofing attacks as early as 2002, and again with Eric Johanson’s Paypal spoof in 2005. Times have changed since then and the browser vendors and registrars have gotten smarter about IDN.
However, the attack vectors continue to emerge. I plan to demo some of these and describe the current landscape of IDN, especially as it relates to the IDN revisions that are soon to be standardized. These revisions, dubbed IDNA 2008, bring important changes, both good and dangerous. On the one hand, we've moved to an inclusion-based model, from exclusion-based for allowed characters. On the other hand, we'll have edge cases where a single domain name could resolve to two different IP addresses under the new and old IDN standards. Can your cloud-based services be spoofed?
Moving along, we'll take a closer look at how character transformations can be used to exploit software. Some characters really do have split personalities much like Dr. Jekyll and Mr. Hyde, which affect you whether your product parses text and wants to prevent buffer overflows, or its a Web-app looking to defend against XSS attacks. Through subtle manipulations, attackers could send you strings that expand by factors up to 18x when normalized. In attempts to evade XSS filters, an attacker could inject characters such as the U+0130 LATIN CAPITAL LETTER I WITH DOT ABOVE which when lower-cased change to a U+0069 LATIN SMALL LETTER I.
In other situations, processing of special Unicode characters such as the BOM might also open up exploits. Because many assigned characters have special meaning and properties, their usage outside of their intended scope may require closer attention.
I’m happy to be going over these issues with you and the Blue Hat crowd at my talk, Character Transformations: Finding Hidden Vulnerabilities, aimed at developers and testers. I want developers to see some of the issues, and I want testers to see some new inputs and test cases.
-Chris Weber
Co-Founder, Casaba Security
A single Web page may be a composite of the efforts of many different development teams, each utilizing different technologies. If you are responsible for the overall security of a site, then you need to have a clear picture of how content will interact in order to understand the risks. Without a clear mapping of permissions granted to each piece of content, an attacker might be able to find subtle paths through your defenses.
For example, I have been looking at many of the newly developed cross-domain permissions and hypothesizing how developers might make mistakes in deployment. My co-presenter, Jesse Collins, has already published on how cross-site scripting attacks due to coding flaws can lead to attacks on cross-domain XHR2/XDR implementations. On the other hand, I have been researching how architectural designs might lead to unintentional cross-site permissions. For instance, let's say that woodgrovebank.com provides cross-domain XMLHttpRequest Level 2 (XHR2) permissions for their site to adatum.com. The adatum.com site also serves interactive third-party SWF advertisements that are provided with JavaScript access via the allowScriptAccess parameter. If the third-party SWF advertisement has access to the JavaScript on adatum.com and adatum.com’s JavaScript has cross-domain access to woodgrovebank.com, then the third-party advertisement has access to woodgrovebank.com. This may not have been what woodgrovebank.com had in mind when they provided cross-domain access to adatum.com.
As part of our research, we are supplementing our concepts with real world examples. For instance, the hypothetical example above is an abstracted variant of the recent renren.com worm. The writers of the Renren worm started with sharing a link to a malicious SWF file hosted on a third-party domain. Unfortunately, the renren.com HTML was providing that remote SWF with an allowScriptAccess permission of “always”. The “always” permissions allowed the remote SWF to have script access into the renren.com HTML. The SWF itself would do nothing more than play a Pink Floyd video (Rick Astley would be too obvious) and use its scripting permission to inject a SCRIPT tag into the hosting HTML. The SCRIPT tag would then load the malicious JavaScript that was responsible for driving the complex attack. The worm propagated by sending messages to the victim’s friends. To accomplish that task, the malicious JavaScript needed to collect information from different sub-domains of renren.com. Fortunately for the attackers, renren.com already utilizes cross-domain AJAX calls to those sub-domains as part of their architecture. Therefore, the attackers were able to initiate the attack by taking advantage of the excess permissions granted to the SWF content. They then leveraged the existing cross-domain AJAX infrastructure to collect all the information necessary to identify the victim's friends and propagate the attack.
Combining research makes it easier to communicate common risks with deploying RIA technologies. The attacks in the above examples could also occur if the content were based on Silverlight and granted the EnableHTMLAccess permission. As the webmaster responsible for the overall site, you may not be an expert on each RIA technology. However, if you understand the common risks shared across RIA technologies, then you will know to ask whether the SWF or Silverlight content has access to your HTML’s DOM during your security review. Understanding the common risks will allow you to draft security requirements that can be flexible enough to address different RIA technologies.
During the presentation we will be providing guidance on how to secure your site against these and other RIA attacks. It is our goal to communicate some of the important commonalities and differences between RIA platforms to enable developers to understand the breadth of RIA's capabilities Architectures that mix content from diverse sources will need to build holistic views of their content. Data flow diagrams detailing where cross-domain communication occurs can help identify where unintended paths into sensitive areas may exist. By understanding the capabilities of RIA technologies and by tracking the flow of those permissions, developers will be able to accurately manage their risks and provide users with a rich Web experience.
Peleus Uhley
Senior Security Researcher
Adobe Systems, Inc.
[Editor's note: Check out Bryan Sullivan's post on the SDL blog titled "Cross-Domain Security" discussing the existing SDL requirements around cross-domain access security and the implications of Peleus' research on these requirements - coming soon.]
