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
With more and more business customers deciding between client, cloud, or both for their computing environments, security guidance must be dynamic and evolve along with the community. Because security and privacy are key concerns affecting adoption of cloud computing, the industry has an opportunity to assure customers that web applications running on cloud platforms can operate in a safe and trusted environment.
Microsoft has made a series of moves to take its secure development best practices beyond its borders to the broader developer community. This has included a body of guidance, an SDL Optimization Model, the creation of a network of certified service providers through the SDL Pro Network and a no-cost SDL Threat Modeling tool. All of these, plus subsequent releases of SDL programs, tools, guidance and technologies have better enabled software developers and industry partners to build security and privacy directly into software applications and provide their users with a more trusted computing experience.
Yesterday at the Tech·Ed Conference in Berlin, Germany, Microsoft announced two new SDL offerings
Security Considerations for Client and Cloud. Download a whitepaper from the SDL team that discusses security issues associated with “client and cloud” applications, and the steps Microsoft has taken to evolve SDL to address those security issues in Microsoft services.
SDL 4.1a, expanded to include Agile Development processes. Download the latest SDL process guidance that includes SDL for Agile Development, a streamlined approach that melds Agile methods and security. Comprehensive yet flexible, the SDL for Agile guidance includes all SDL requirements, but provides guidance on how to apply them even for very short release cycles.
Let me briefly expand on each of these.
Security Considerations for Client and Cloud
As the computing industry considers Cloud Computing, customer are concerned with how data will be protected. In a September 2009 online survey of IT Pros, about 51% cited security and data privacy concerns as the biggest impediment to adopting cloud services.
In Security Considerations for Client and Cloud, Microsoft takes a look at security from the point of view of development organizations that may be considering hosting their application with a 3rd-party infrastructure (ie. “cloud”) provider.
If you are to host your well-coded application on a 3rd-party infrastructure, at a high level, you should be asking questions (of potential cloud providers) concerning two general areas of security:
- Operational Security and Compliance. If you have regulations governing your industry (e.g. healthcare), what does the provider do to make sure you are in compliance? What have they done to demonstrate their operational security?
- Security Features and Service Level. Additionally, different providers may offer different cloud security features (e.g. supporting certain types of authentication) and different security service levels in their SLA. Ask for details to ensure that you know exactly what they will provide you (from a security perspective) as your partner in delivering services to your customers.
Of course, fundamentally, application software, whether traditional or for the cloud, still needs a structured security development process such as SDL. So, make sure you are using a structured security development process like SDL for your application.
What? You say you have a 2 week release process and use an Agile development process? No problem, read on…
SDL for Agile Development
If you are using an Agile development process, you are not alone. Agile development methods are being adopted more and more frequently in enterprises around the world. According to a recent independent analyst report, 85 percent of technology industry professionals have adopted Agile development methods at some level of maturity.
Note: if you are not familiar with Agile development and would like to know more, you may want to read a bit more on http://www.agilemanifesto.org. Wikipedia defines it as:
Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.
(also)
Notable early Agile methods include Scrum (1995), Crystal Clear, Extreme Programming (1996), Adaptive Software Development, Feature Driven Development, and Dynamic Systems Development Method (DSDM) (1995). These are now typically referred to as Agile Methodologies, after the Agile Manifesto published in 2001.
If you take a look at Bryan Sullivan’s SDL Blog post concerning SDL for Agile, he gives a great description of how the team approached the task of taking the comprehensive SDL requirements and processes and organizing the guidance into an Agile-friendly structure that can be flexibly applied to long or short agile development projects. I’ll give a quick summary of his post.
If you look at the Security Development Lifecycle and how it is described by phases, you can see that it was originally developed to integrate with the spiral-based product development process used by Microsoft to develop Windows and other business products. Though there are many differences between spiral and Agile methodologies, two key differences stand out to me:
- Agile development methodologies don’t have defined phases, and
- Agile releases tend to be much shorter, in some cases only a week or two
To address these differences, SDL for Agile breaks the SDL into three categories of requirements: every-sprint requirements, the requirements so important that they must be completed every iteration; one-time requirements, the requirements that only have to be completed once per project no matter how long it runs; and bucket requirements, the requirements that still need to be completed regularly but are not so important that they need to be completed every sprint.
SDL for Agile also provides guidance for adapting many of the core SDL activities to Agile. Threat modeling is a perfect example: a team could easily spend an entire week-long sprint performing threat modeling, but this may not be the best use of their time. SDL-Agile describes how a team can spend an appropriate amount of time modeling new features as well as how to build up a baseline of threat models for existing functionality.
To get the full SDL for Agile guidance, download SDL 4.1a, expanded to include Agile Development processes, and read through the new sections on Agile.
Final Thoughts
As the computing industry evolves, Microsoft continues to invest in security and privacy fundamentals and ensures its software development processes, best practices and technologies extend from Client to Cloud environments. The release of SDL for Agile and the cloud security white paper highlights Microsoft’s continued efforts to meet the changing needs of the development community and ultimately will help create a more trusted online computing experience.
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.]
