 Good morning. Thank you. My name is Steve Orn, I'm director of security solutions in the software group at Intel. And today we're gonna talk about SOA and XML threats, web 2.0 threats, and a new threat model as a way of classifying them. So before we get moving, just a quick show of hands. How many in the audience are familiar with SOA? Very good. How many of you have actually played with web services, XML, or web 2.0 applications? Great. We can fly through the beginning parts. Quick agenda, we're gonna do a quick intro to web 2.0 and SOA, talk a little bit about the security challenge that we face when introducing these new technologies and architectures. Then we're gonna dive into a SOA XML threat model that I've been working on with some other folks to help classify the various kinds of attacks and the kinds of threats that we're starting to see in a normal way. Then we'll dive into some details on various threats, both some that have been around for some time, as well as some new ones that we're gonna be publishing here for the very first time. Then we'll talk about some next generation and web 2.0 threats that we're starting to see on the horizon. We'll talk about the evolving enterprise and the evolving environment and how that changes the way we need to secure these applications and then finish up with a summary and a little bit of Q&A if we have time. Otherwise we can go to the Q&A room to continue discussions. So I don't think I need to tell everyone in the room, but SOA is basically a collection of services. It's an architecture and it's a service orientation. It's a different way of deploying your applications, your functionality, your data in a form of a service or a set of services. And what SOA really is at the end of the day is a way of managing, monitoring, and deploying these services in a normalized way. Web 2.0 has got a lot of different meetings to a lot of different people. It was first coined by Tim O'Reilly back in 2004 and at the end of the day it's really about turning isolated functionality and isolated websites and web content into a collaborative environment or into a set of services that can then be consumed by other web applications, other services, and other applications. So you can almost see it. If you take Tim O'Reilly's concept it's really about taking what was already out in the web and moving it to that next level of interactivity and functionality. It's got a whole lot of other names. People call it semantic web. We're not gonna go there today. We're just gonna talk about the threats that are created by these new kinds of architectures. I'll leave it to somebody else to better define Web 2.0 for us. Just some simple numbers about the SOA world. The fact of the matter is, is that SOA is happening, XML is happening. Whether you, depending on which analyst you trust the reality is, is that a large percentage of corporate land traffic today is already XMLized. It's already Web 2.0 or web services based and this stuff is flying around our networks and in many cases is unchecked and undocumented. So a lot of people ask, well, why did we go this route? Well, the reality of most corporate enterprises, government enterprises, is that this is what it looks like. A variety of different applications, data stores, middleware, clients and servers and databases that are all deployed over a variety of reasons for over a period of time. And what we're left with is this, this cloge of various different applications. SOA is an attempt to rationalize this and to provide it as a structured set of services so we can get access to the original functionality and possibly do different things with it and do new application development. So really where do these SOA apps and Web 2.0 data come from? It comes from the things that have already existed and it's important to understand where these applications are coming from. Whether it be things like EDI replacement or a lot of the middleware decoupling of databases and client server apps that happened in the 90s, EAI and portals, that's enterprise application integration for those of you not buzzword compliant, e-commerce sites and then the big package applications like enterprise resource planning, Salesforce automation, customer relationship management, these large package custom applications, whether they be bought from someone like SAP or PeopleSoft or custom developed by, you know, with $2 million and a consulting firm are the core of the business functionality that runs a lot of corporations and it's from these various apps that web services, SOA, XMLization and ultimately a lot of the Web 2.0 functionality is gonna derive from. And it's important to understand that, that different from many of the web applications we saw in the 90s and the early 2000s where it was, you know, a web portal to maybe a banking application, but there was always a secondary database of the way. Many of the things that are being web service enabled and turning it and becoming part of our SOAs are in fact the mission critical business applications that run the very life-bud of these enterprises and companies. Therefore, any threats to these systems aren't just gonna compromise a website sitting way out in the front, but can go deep into the organization and deep into the application infrastructure. There's an analyst firm called Zampthink that is a very good one. If you wanna learn more about SOA and XML and web services, they're a really good analyst firm, a couple of guys, and they created this roadmap to show us where are we on the horizon? They created it a couple of years ago, and the reality is we're right about here now. You go back to the mid-90s that started out as web services, grassroots efforts and corporations, then we evolved and started seeing mission critical applications getting deployed as web services within the boundaries of the company. And one of the key things that started to happen back in 2002 was the deployment of these SOA pilots, taking these internal web services functionalities and applications and starting to deploy them to our business partners, deploy them to customers, ultimately leading to a full-fledged enterprise SOA build-out and deployment. And these SOA build-outs are doing more than just one or two business applications, but it's actually cross-division, cross-group, application functionality being deployed much more open than many of the applications that have ever been deployed before. And where this gets us to, the nice thing is it gets us to be able to do some really nifty things with web services like just-in-time integration, like much of the web2o stuff we see today, the location services, a lot of that comes from this enterprise SOA build-out within corporations, sort of driving the engine behind the scenes. This is an example of a web services stack that's actually been geared a little bit more for a web2o kind of environment. It may be hard to read some of the details, but in your slides in the CD you can see the information. Basically you have a series of web services tools written in a variety of languages that write on top of base-level support for web services. Things like Apache, MySQL, a lot of these are the core infrastructure that drives web services. And on top of the web services, you start to get things like these web2o concepts, whether it be rich internet applications, Ajax applications, RSS feeds, a lot of them build on this existing infrastructure that keeps building on top of the existing applications and data resources. This is just a quick overview of some of the typical kind of web2o server environments. There are a lot of different acronyms here. The most common one you will find is called LAMP, which is Linux, Apache, MySQL, and typically PHP, although it could mean Perl or Python as the language, that is probably the most common web2o environment you'll find out there. The second one is probably WAMP, which is the Microsoft version of that. And then there are a variety of others, depending on the organization that's deploying the application, what they already currently have, what they're familiar with, you can get a variety of different names for them, from LAMP to WISC to WISP. And if you wanna see the full details on the 40 or somewhat different possible combinations, you can just go to Wikipedia and they have a really good listing of them. What's interesting to note is that these web services and web2o applications and application environments are built from these various different systems. And a lot of time being built by some little marketing group that thinks, wow, we're gonna be cool and do some web2o stuff with our site, and have no connection to security, and all of the security vulnerabilities that are associated with these infrastructures will hold true, of course, in the web2o environment. Don't need to bore you with why people are doing so, I think it's pretty obvious, but what is important is to understand why is security so important or more important potentially in these environments than necessarily the stuff of before. Number one, it's a drastic and fundamental shift in the way we do authentication and authorization. No longer do we have the tight controls over who is our user domain. I can know you five people right here and give you username, passwords, or certificates, and I know you and we can communicate, and I can give you access and authorization to do transactions because I know you. In a web2o or web services world, most often I don't know who my user community is. I may know the partner that they're coming in through, but more often than not, I don't have direct access to the authentication, I don't necessarily know what your role is at that organization, and therefore the way that I have to authenticate and authorize transactions has to change. We start hearing concepts like federation of identity and federation of authorization has to occur, and that's a big difference and a big shift to a lot of the infrastructure and policies and protocols that we already have in place. The other big difference, I mentioned this before and I can't iterate it enough, real business apps are affected. To give you an example, if a large bank had its web banking portal shut down by some hacker or a rogue government, yes, it's gonna cause some damage. Yes, maybe they'll get their name in the New York Times, their stock price may take a little bit of a dump and there's some bad press, but at the end of the day, the bank still runs, money still moves. But if the cash management system is taken out because it was web service enabled and someone was able to hack in through that channel, cash management stops running, then the bank stops running. So it's real business applications that are affected here. Another key distinction in the web 2.0, web services so environment is the problem of non-repeation. We still have it completely solved it for the web world, but it's that much worse when it could be an application or a series of applications between the end user and the ultimate transaction. How do I prove that you in fact did that transaction? And it has not been solved yet. Another key difference is the externalization of the application interfaces and functionality. XML is a very powerful language and one of the key tenants of XML is this ability of SOAP and WISDOL to publish the interfaces to my transaction, to my application, to my data and give them out to the business partner, the consumer or whoever that's gonna ultimately go against them and write their own application. Well that changes the way we have to control those application interfaces. Today it's maybe four developers back in the corporation that have access to the protocols to talk to SAP. So no one really cares. Tomorrow it's 100 million people that could have access to those very same interfaces. And the controls that we have, the physical and internet security controls that we have today just don't apply those kind of models. And finally with any new technology or architecture or environment that we introduce into the enterprise, we add new threats that did not exist the day before. So of course many of the old threats will still work, but there are new threats now that we have to deal with. Don't think I need to convince this audience that risks are increasing. The problem with XML is that we have a mixed bag of standards which can be often confusing when you start trying to get applications and systems to talk to each other. One of the things about XML is that it's really powerful about ways of being able to make one system communicate with another to deal with interoperability using things like transformation. It's really powerful. A challenge comes at play when I have one mechanism to secure my XML over here and a different one. How do I rationalize those? It's not yet been solved in these communities. Of course we know about regulations. We know about liability. I don't need to convince anyone here about that. So the same before, all of the old attacks are still valid. Buffer or flows, standard injection, denial of service, all that stuff that worked in the web world, worked in our networks and our operating systems, still works when you throw XML Web 2.0 into the bucket. But there are new kinds of attacks that didn't exist before. Like entity and referral attacks, DTD and schema attacks. There are new challenges that we have to deal with separate from these legacy or existing attack, threat that we have to deal with. And finally we're starting to see the evolution and again in this environment it's quicker than we've ever seen of new or next generation style threats, multi-phase attacks. As I'll show later, one of the interesting things about XML different from the web environment is that in the web environment I transact with a bank. I do the transaction, maybe I'm exposed for that period of time, but afterwards the transaction's over. In the XML world, much of the XML content and the documents, the messages stick around. And that means that there's the possibility of sort of leaving pieces behind that can be taken advantage of at a later date and time by the attacker or being able to pepper a bunch of different pieces of an attack into an organization and then cause the failure at a later time when they have more than what they need as far as functionality that they've been able to pepper into various different XML transactions. The other key thing is that when we start marrying legacy applications and protocols that have been around for numbers of years but have been in a very tightly controlled environment with web services and XML functionality coming in over the internet, we have new exposure points that we didn't have to deal with. To give you a quick example, there are about a hundred known vulnerabilities in the BAPI protocol for SAP. No one really cares and the reason is that up until today or in these times much of that protocol has been very much hidden from anyone external from the organization. It worked between the thick clients that were inside your organization talking to the backend database on the mainframe and maybe four people in your organization had any knowledge that there was this thing BAPI protocol flowing across the wire but it never left the organization. It never existed. Even when you did things like Citrix or other things to push client functionality out it was already translated into some sort of TCP-IP based protocol like HTTP. When you web service enable your SAP now you're suddenly giving direct access to that protocol. Suddenly those hundred known vulnerabilities that no one really cared about you just have to start to care about. So it changes the way that we have to protect both not just the front end part but also the backend. So now I wanna talk about this threat model. One of the things we discovered when we started doing this research was that there were a variety of different kinds of attacks and just like we have in the web world like the OWASP top 10, we have the WASC that's web application security consortium, threat classification, there wasn't anything for XML. There was no way to sort of classify what kind of threat is this new attack that just got published and what are some of the possible mitigations for it. So some work that I did along with a group called CADS that's Center for Advanced Defense Studies we started to put together a rationalization of these different attacks and a grouping that we call the SOA XML threat model and we basically break it into four key categories. The first one is payload or content threats. This is where the web service or the XML is really a carrier. It's the mosquito carrying the malaria, not the malaria itself. And so in the case of web services there are two flavors there's backend target and then user target. In the case of a backend target, the goal is to get the attack to some sort of target application database or infrastructure component inside the organization and you're using the web service or the XML as a means of getting it there. Some of the classic things like SQL injection will work here, the thing I just talked about the BAPI protocol attack will work here. We'll discuss something called Universal Tunnel which is a way of taking one protocol and piping it using XML as a way of getting it past the firewall. The other subcategory here is in user target and that is where ultimately the XML that I'm submitting to the server or that I'm posting or the content that I'm posting will end up as XML content or as data that's gonna get consumed by an user in their browser. Think cross-site scripting is the key example here or a virus or some sort of malicious mobile code. In the case of XML many times these applications are built content is collected from a variety of resources and stored in XML documents or XML databases. And then when somebody wants to go look up the information on the website that XML is delivered to the user and then rendered locally on the browser. And therefore I can convey an XML attack like cross-site scripting today and then six weeks later someone searches for that information and the XML downloads their browser and boom the attack will occur. In the case of XML misuse and abuse this is where you're screwing around with how the XML protocols and implementations themselves work. There's a variety of new standards here like XPath and XQuery which are ways of searching for information for instance and you can misuse or abuse the functionality that's given to you in these applications to do some malicious things. It's an important point to note. XML and web services are a very powerful environment with a lot of powerful features that didn't exist in the standard HTTP, HTML and JavaScript rule. That power is great for developers and for your application functionality it also is great for the hacker. The hacker can take advantage of those advanced functions to do some really powerful attacks. It's the third category we're gonna talk about is structure manipulation. Structure manipulation is where you actually malformed the XML. And in many cases many of the parsers and processors just don't know how to handle these malformed XML documents. And if you actually do some very conscious malforming where you actually change it in certain subtle ways you can cause some serious damage. And finally talk about some infrastructure attacks. The XML web services because they're mission critical applications behind here many times they themselves become mission critical to the organization. If you shut down the servers that are supporting the web services you're causing damage ultimately to that channel or that revenue generation scheme. So quickly review some of the payload content concepts here. As I said before the backend target is really where a lot of the old attacks that we've seen continue to be viable in an XML world. SQL injection, command injection, protocol manipulation all of these things will work in an XML world where you use XML as the new carrier to get that application attack or that backend or system or command injection attack into the organization past the firewall. It's important to note that most of this communication is happening over port 80 on the web server through the firewall. So all of your network firewall functionality is basically useless to stop these kinds of attacks. I'm not saying the network firewall is completely useless someone else here I'm sure has but in the case of web services one to O it's a Swiss cheese firewall. It just doesn't help because it doesn't have the content awareness or the application layer functionality to inspect XML traffic traveling over HTTP across the wire. So your network firewall infrastructure just isn't gonna help you here you're gonna need something else. The case of misuse and abuse and we're gonna I'll dive into one example which is the X path injection when we get to the details of the threats you'll find that many of the legitimate features of these protocols and these formats actually they themselves can be used to cause some significant damage. And because many of these protocols were designed without security in mind there are no checks in many of the cases you don't need to be authenticated to the web service to actually do some of the functions of X path for instance. What's also important to know is many of the standards I'm sure you've heard of some of them WS security, XML digital signature, SAML, XACMOL and a whole bunch of other acronyms that deal with security in these environments most of them deal with authentication and authorization. In essence, how do I package up my existing authentication mechanism in an XML way so that I can use it with this XML environment? What it doesn't do is help us protect that XML environment it helps us use what we already have and try to do it in this new environment. We're starting to see some things around WS policy to actually make it a little bit better but really it doesn't address the problem of threats. It's all about how do I authenticate users that I may know or that someone else I know may know. Doesn't help us with any of the kinds of threats that we're talking about here today and piping it over ourselves doesn't help either just means you'll have an authenticated and secure transport attack coming in over the wire. Structure manipulation is a category that's got the most interest right now. This is where you'll see a lot of the newest attacks coming and we'll go through many of the ones that I'm gonna publish for the first time today are actually under this category and the reason is is that most of the parsers and XML processors and XML environments that are supporting these applications were developed without security as part of the process. They weren't hardened. They weren't built to deal with things like buffer or flows. They weren't built to deal with really good error handling in the sense of trying to prevent these kind of structured attacks. And what you'll find a lot of times, this has been a big challenge even for the XML firewall vendors that exist out there, is that a structure manipulation attack looks a lot like a legitimate XML message. And matter of fact, in many cases like the billion laughs attack that's illustrated here is one of the older ones. It isn't until you get to the 128th instance of that reference that you have a problem. At number 127, everything is cool and kosher. The process is chugging along, it's doing its job, no problem. The second it references at the 128th time, all things go to hell and actually you get a really good denial service of the system here. But up until that point, it's legitimate XML, nothing wrong. It's only after that point or in the case of some of the other attacks when you start spreading out the memory and actually getting the XML to do some functions for you, it looks exactly like a legitimate XML message and it isn't until you get down the line where it's almost too late that the parser ends up in a race condition or ends up taking up all the available resources. So that's a real challenge, but how do you identify these things? And what we'll talk about a little bit later is that some of the way of doing that is about really creating tight controls around how XML is processed, making sure you buy the right or use or download the right kinds of parsers that have been hardened. Again, some of the simple stuff we'll show later. Final category, which is infrastructure attacks is we put it here because what we're finding is that there are actually some attacks and we've seen some in the wild actually that were targeted at the web services infrastructure with the goal of subverting or allowing for some malicious activity in the web services environment but not directly attacking that web service environment. One example is where they did some DNS poisoning to be able to slip in a malicious CA server into the process so that their signed document would get verified at the time of the transaction so they can actually do the brokerage transaction they were trying to do. They didn't attack the XML environment directly but they came at it from a different angle. And so as we see more of these, they will fit into this bucket. So the same kind of security mechanisms we do to protect against DNS poisoning today will help here as well. So now we're gonna get into some of the details. And before I do, I just wanna say two things. On the bottom of each one of the attack slides, there will be a reference to either the researcher or the paper that that's came from. Several of the stuff has been around for some time and has been worked on in a collaborative environment. The new stuff is coming from work that myself and CADs did together and you can find more information about them on their website. The other thing is please do not try any of these things on any system that you don't have authorization to do so. Now that I've said that, let's dive in. So as I said before, in this first category of payload and content threats, the back and target ones, it's a lot of the old stuff we already know. SQL injection works in XML just as easily as it works in a web environment. Cross-site scripting works just as well in an XML world as it does in a typical web environment, but it works one better because oftentimes this XML document gets stored on a server and use multiple times to serve up information to an end user. Therefore, your one cross-site scripting attack as opposed to having to be sent as an email or some sort of link on some page, I can put it into this XML document, ship it up to the server that's consuming content from users and then wait for every time someone logs into the page or goes and views that page, they're gonna consume the data from this XML document and get the attack and it can last for a long period of time. Now for the XML misuse and abuse examples. First example of this is XQuery. XQuery is SQL in XML world. It's the way that you do SQL queries and look up information in an XML environment. And again, all the normal SQL kind of stuff will work here, but there's some advanced features in XQuery that didn't exist in the standard SQL that we're all used to. Allows us to do some more pointed kinds of attacks and pointed kinds of tests. So for instance here in this example, the attackers trying to access users.xml and they can actually target that specific document with their query in XQuery and ask for information and inject their XQuery injection in here to get access to all of the users. A lot easier without the painstaking effort. Just quick show of hands. How many of you have actually run a successful SQL injection tack before? How many of you felt there was a pain in the neck if you didn't know anything from the get go? How many of you are using a tool that helps to make it easier? Exactly. XQuery actually makes it much easier. You don't need a tool because all you need to do is perform a very structured query and the XQuery system will do the work for you. It gets better in XPath. Now XPath is like SQL but it's actually how you query XML documents whereas XQuery is how you do a query of a database in XML. XPath is how you query XML documents, XML data resources and XML databases. It's one of the fundamental building blocks of much of the XML processing. It's how you do transformation. It's how you find a piece of data floating around in a variety of different XML. It's how you know what to do at a given period of time. So its structure is very similar to SQL. It allows you to do all the normal kinds of SQL queries. It allows you to do all the advanced stuff that you got in XQuery as well about being able to target specific documents or target specific IDs and references within the document but it also has a really nifty novelty feature. Because typically in an XML environment you're just looking for one element and one value and you may have megabytes, not gigabytes of data to search through. There's a simple test that you can do in XPath and say does this exist? It's a query that you can ask, does this exist? Not what, don't give me the information. Just tell me if it exists before I start looking, before I start investing resources and trying to find the data. And the XPath system will go off and look and say does it exist and give you back a binary yes or no whether this piece of information exists. It's a very powerful feature. There is no authentication authorization required to do this test because when they create the protocol you didn't give away any information. You just say does something exist or not. So a meat client came up with this really nifty Perl script that actually can go through and do a blindfolded XPath injection attack where I query the XML document bit by bit by bit and I ask does this bit exist? Yes or no? I get back a yes or no answer, I know a lot of information. And in about 30 seconds he can pull down an exact replica of an XML document that's about a page in length without ever authenticating or knowing in fact what information existed there just by querying it bit by bit by bit. And you can go on the site and read his white paper, it's a really good white paper on that. Now for the fun stuff. The structure manipulation thread examples. The first one, and this is one that's been around for a long time and most of your XML gateways and firewalls and even a lot of the network firewalls say they can solve this problem. And it's not that hard. It's the schema poisoning tack. It's one of the first things that people thought about when XML came out. Schemas and whistles are the structures that tell web services applications how to process an XML document. They're the mechanism by which you define your XML application. What methods are correct? What information do I need to process this application? You know, what's the min-max size? How many instances of it is it gonna exist? What's the character set? What's the type? All that information is contained in an XML schema. And the schema is one of the fundamental things that allow you to have this interoperability and this flexibility within the XML environments. An absolutely crucial piece of the puzzle. And typically a schema will get published and that's how your business partner or your consumer can figure out how to access that application. And in there, as you can see in the example here, you have things like the type is a string. This type maybe is a date. You've got the number of instances that have to be there and the information like that. Schema poisoning is about changing the way the application is processing that XML document. One example is removing all the strictures. So if I remove the fact that it needs to be a string or it needs to be a min-max length of a certain size, now I can send an XML message in and when the system reads the schema of how to process it, my malicious content's gonna swing right by because it shows up as legitimate XML based on the schema. This is one of the classic attacks that have been around for some time. Okay, well I can still see, I hope you guys can too. Entity expansion, before I talk about the attack, let's talk about another feature of XML. In XML and web services environments, I can either give you the data. You can ask me for my name as a piece of data. I'll tell you, Steve, or I can say, go to this URL to get the data you're asking for. It's a reference to the data. So I'm actually giving you the data. I'm giving you some place to go pick it up. And that's a feature of XML that's used all the time in certain kinds of applications. There's also this concept of an entity where I can define an entity as a reference. So instead of defining a data value as a specific value, I can say I'm gonna define this as an entity and then this entity itself is in fact a reference. So one of the very first attacks that was published using these techniques was that oftentimes the web services server has got access to and privileges that you, the consumer, you, the user of the web service do not yourself have. So in this example, with a simple application that takes an input and as part of that input reflects that input back to the user, by putting in a referral to the data. Instead of giving you the information for the entity in, I give you an entity foo and I say define foo as, in this case, winnt slash winini. Now I can't go and ask the server for the winini file, typically. Unless I've already hacked it. In the case of this web service, because it's running in a privileged state, it can go off and get access to that information. So I get the web service to do the work for me as the attacker. And so the web service doing its job goes off and finds the data that I said that it, where to go get it from and returns it to me like a good boy and I get the winini file. Taking this a step further, we have an attack here called quadratic blowup. An quadratic blowup, and this is again the first, one of the key examples of where the parsers and the web service and XML processing engines, where the Bersersees, Xiland, the Saks and Donpossers that exist out there, many of them are either open source or you can buy them from the various companies like Microsoft and IBM, who are themselves not built securely. They don't deal with these exception cases well. And in the exception case that I'd illustrate here, I'd find an entity of a bunch of ACE and about a hundred K of them. And then I create a reference to that entity and I reference it about 30,000 times just by having 30,000 references to it. Now the interesting thing is this is not a very large XML document. It's maybe what, a couple hundred K in size, not a very big one by XML standards. However, by consuming this XML document, we can take a server out in a matter of seconds because we get the XML processor on the parser to do the dirty work for us. It will instantiate 30,000 instances of a hundred kilobytes of data into memory prior to even running the application. This is just parsing, getting things ready to run the application. So it does the damage all by itself. It takes itself out, in this case shuts itself down in a matter of a few seconds because the parser, one of the things that parsers do is it parses through and understands what do I have to get ready to run a transaction. In this case, I'm gonna get 30,000 instances of about a hundred K in size. I'm gonna go spawn the memory and suck up all the resources and the threads for this transaction, boom, server goes down. Another example of this is the DOS, a DOS attack using SOAP arrays. There are array structures that are available in SOAP which allow you to define a set of arrays. And by setting these arrays to about, a string of about a hundred K in size and then referencing it multiple times within a loop, you get the array function of the SOAP processor to create a denial service environment. And this one here is a little bit more gradual until we got no response from the server. And all this data by the way, if you wanna go and look at the details is in the slide deck that's on your CD. Another example here is where we take the quadratic expansion techniques that we saw earlier about referencing something really large and then having it reference multiple times. And we can do that in an array as well. In this example here, we're using the href function within a SOAP array to cause the same kind of damage. And this is one of the new attacks that CADs came up with. So combining the techniques of the last two ones together actually gets a denial service fairly quickly. Now I'm not telling you which parsers worked with but trust me when I tell you we tested this with all the ones you're gonna go play with and a large majority of them were susceptible to many of these attacks. Now we get to some of what I call stupid stuff. The reality is many of these kinds of malformations should not work. I mean, well let's face it, we're in 2007 now we think that many of the vendors and application developers out there would have learned. But sometimes the stupid stuff does still work. In this case, an unclosed tag inside of a SOAP array reference got the parser to crash and burn. A simple unclosed tag. It'd be like programming in C and not having the parentheses there. You think that would get caught? It doesn't. Another example, again, of an old attack that we've seen in a variety of other protocols works just as well in XML, really large names. So we created a very, very, very, very, very large name in an array type. And the processor basically dumped as the web services processor dumped when it got to this name and couldn't process it. It was too big for its buffer and it crashed. Now we did not do the research to see if we could do any sort of injection of functionality in here, that's for somebody else to do. But we did get the crash that would lead to some research like that. Again, we get the same kind of deal when we have a denial of service using the attribute name size. Not in an href, but attribute name size can also cause the same kind of problem. So we have here, let's see if I can show you a really large attribute name in a SOAP array causes the same kind of problem. And again, and I've talked to many of these vendors and it's really embarrassing for an industry to have these kind of problems today. But the fact is we still do. Another example is reading in blocking pipes using external entities. I can use an external entity to reference something like a blocking pipe and get that type of denial service environment as well. Here's one of my favorites. We all know, we all should know that anytime you install a new web application environment or a new web service environment, all the test scripts that come with it should be deleted from the production server, right? Raise of hands, how many believe that? Come on, I can see more hands than that. Many of the live web services environments that we've looked at, both in financial services, in government, in healthcare, they typically keep some of these tests around. The reason is because XML environments are a lot harder to test than a web one. You web one, you can go to the website and see if the webpage shows up and you're happy. Many times a test, if some of the functionality in your web server is not working right, it's a lot harder to test. So a lot of companies decided we're gonna keep some of these tests around so that we could quickly do a functionality test to make sure something's not going wrong. Problem is with the example here, this is the one with access, the array test is actually a very resource intensive test. It's a diagnostic tool that you can run to check that certain functionality around your arrays will function and work. And it didn't take that many of them, only about four instances that were referenced three times and we were able to consume the resources of a fairly high end server, mind you. All of the threads and all of the memory was consumed by this one XML document, just by sending it in because they didn't disallow access to these standard test and diagnostic tools that came with the download. There are a variety of other threats that are available out there. Wisdom scanning is one where typically a Wisdom, like a schema, is how you set up your application. There's a lot of information gathering that a hacker can do by looking at your Wisdom. If you wanna see the Wisdoms of a particular company, just Google the company's website, start at WSDL, and you'll find a lot of interesting information. There's also parsing attacks where you can try to get the parser to parse information in a specific order. Just like in the other kind of content delivery infrastructure, I can upload malicious content. Viruses can be delivered. Binary data can be delivered via XML. There's a functionality in XML called routing, and what routing is is the ability to actually tell the XML document which hops it needs to go on as it goes through its transaction by injecting into that routing statement and being able to manipulate the route it takes, you can do very creative man in the middle attacks. And all this information is available here, and if you can go look at the report that Pete Lindstrom did, he actually lists some of this information. So now let's talk about some future next generation attacks. So one thing is for sure, as more applications come online from the back end as web services, those vulnerabilities that existed back there become available to the attacker where they weren't available before. A guy named Stu Henderson every year gives a talk at the big IBM share conference. We talked about 10 ways to hack a mainframe. And for those of you not familiar with mainframes, it requires a lot of really weird things with ICPF panels and JCL to get it to work from a green screen that he does the demonstration for. One of the interesting things that we did some joint research on is to show that if you XMLize that back end mainframe database or the mainframe kicks environment, those structures allow you to perform those attacks without having to go through and learn JCL and become a green screen expert. You can actually send the attacks directly to the mainframe and target the mainframe directly. Most of them were denial of service or authentication compromise. So moving along, let's talk about Web 2.0 and RIA attacks. We've got about 10 minutes of time so I'm gonna fly through a sum of this. Ajax, basically the Ajax is a bunch of functionality running in the client. And there are three specific areas that we wanna look at here. There's a lot of vulnerabilities around Ajax. There've been some talks here at Black Hat and Defconn about them. There's more information I'm sure out there. I'm gonna concentrate on three problems. The first is information leakage. When the Ajax engine traps user commands and makes function calls against the server, these go in clear text. And so from an attacker's perspective, it provides a lot of rich information for the attacker about what types of calls, what are the variable names and elements that they're looking for on the server. And so it's a means of attacking. So if you're not using SSL and you're not obfuscating these values, you're giving information away for free to the attacker. The second is the problem of creation of requests and cross-site scripting. Because Ajax is running on the client and if I can insert malicious Ajax content into the Ajax application, there is absolutely no way for the server to know whether it was you typing the command to purchase 20 shares of that stock or some malicious code. And there's no way to prove that you didn't do it because the Ajax application is doing it on your behalf. And so if I inject malicious commands into that Ajax application, I can actually get you when you're authenticated in running the application to run my commands as well, and there'd be no way for you to prove that you didn't do it. Also because Ajax is running on the client, cross-site scripting is a major problem. And a lot of these applications are dynamically generated with content coming from a variety of resources when you go and run it on your local browser. And those resources aren't always vetted by the application server that you're getting your information from. They can go off and get the information from NASDAQ, go off and get information from Google or from MySpace or any other place. So the content that you're processing in your browser is there's limited control of what you can have and things like cross-site scripting, cross-site request forgery and the like can all come into that same channel. Finally is an interesting one which is called Ajax Bridging. Oftentimes you'll have an Ajax bridge setup for an Ajax client to talk to to be able to run things like web services because web services don't really run well in the browser today. You have to do some clues to get it to work right. And a lot of times you maybe don't have access to the authentication required to get access to those services. Many of these environments will set up an Ajax bridge and what that is is a place for the Ajax clients to go to to make a request and then that bridge will go off and make a web services call on your behalf. And they oftentimes have elevated privileges and capabilities that the client itself doesn't have. One of the challenges is that the Ajax bridge can be used as a proxy for the attacker to attack those web services because it has that elevated privilege. And without the proper controls in place on the bridge, it can be used for malicious purposes as well as for the legitimate ones that the Ajax bridge was intended for. Finally is RSS or what I call the free attack delivery service. And RSS is a scary, scary thing. You more often than not, you have no idea where the content you're getting through RSS came from. And oftentimes the aggregator is browser enabled or browser capable. So here's an example I created which is a simple process scripting attack coming in over an Ajax form. One thing to note, age, I'm sorry, RSS form. RSS can deliver all sorts of content, URLs, full fledge XML documents, full binary files. You could download a virus to your system through RSS and not even know it. So, because RSS is a nice open standard. There aren't yet good security mechanisms. The MIT is doing some research right now on how to do atom file security, but it's not yet ready. And so RSS is a very scary thing if you're going to adopt it inside your organization. Finally, in these Web 2.0 sites we're seeing things like cross-site scripting words. Jeremiah Grossman from White Hat Security did a good study on the Sammy worm and showed how the propagation associated with Sammy was unlike any other worm we'd seen before. The nice thing about it wasn't really a malicious attack. It was more of a friendly attack, but it basically ran JavaScript on a million people's browsers in a single evening. That's propagation we haven't seen. In the case of the MySpace QT worm, it was a malicious attack. And it leveraged that same MySpace infrastructure to deliver functionality to thousands of users as a script that ran alongside a QuickTime movie. Now, I don't have time to go into all the details here, but there's really good information on this on the Spy Dynamics website, as well as Burton Pickle did a really good job of documenting the code of the attack. And you can go look those things up and get more information on the MySpace QT worm. So, they're telling me I'm running low on time, so I'm gonna skip ahead here and talk about one of the other challenges, is the deprimiturization of our environment. Basically, whereas in the past, we had the network threats that were stopped by our DMZ or firewalls really nicely. XML and soap-based threats get all the way into our infrastructure. And keeping this idea of a thick, hard shell with a gushy inside is just not going to work in the XML web services world. We have to think of a new way of deploying security to deal with these new and next generation problems. About five years ago, there was about 12 companies that got funded to do web services, firewalls, security gateways and the like, and they were all basically proxy solutions. And that model just didn't work. It did not scale, it did not work with the large enterprises, and it didn't really help with the threats. It was okay for some of the authentication stuff, but then when you started to do real business across them, the challenge you ran into was you're doing all this functionality at the front door before you ever reached the application. So you really couldn't do good authorization. You didn't know whether this XML was legitimate for this back-end application because you had to verify it way out at the front of the perimeter. What we're starting to see now is a second generation of these devices coming into play where you've got XML IPS functionality being built into the perimeter, being able to detect overtly malicious XML documents. It's not gonna catch some of the stuff we talked about today, but the malformed stuff it should catch, some of the content injection things, these IPSs will detect. And if you look at some of the business models behind this, you've seen that Reactivity was recently bought by Cisco, Data Power was bought by IBM, and the like, you're seeing these, the first generation guys being bought by infrastructure plays to deploy this functionality at various points within the infrastructure. This way they can do things like the trust enablement, like authentication authorization, much closer to the actual application that knows what you're allowed to do and keep the IPS out at the front. So you get an environment that looks a little bit like this. So just quickly in summary, we've got a rapidly changing environment, new applications coming up all the time. What's interesting to note is that Ray Wagner from Gartner said that about 40% of organizations today, that's 4,000, have deployed web services that they don't have documented and they don't have control over. So the stuff is out there and it's out the door. All the, with every technology evolution and technology infrastructure that we put in play, new targets, new attack vectors come into play that we didn't have before. And as an industry, we need to work together both to identify the threats, but also I would like to put out a call to the community to help with pulling these threats in and clapping to classify them so that when it comes to mitigation, when you have to go sit down with the developer and say, you need to do these 12 new things that you didn't do yesterday to protect yourself, to protect your web services, they make it easy for them to understand why they should be spending their time working on security, why they should be adding input validation or hardening the parsers that they're using, using a classification system like the SOA threat model. Now I like my SOA threat model, but if you've got a better one, fine. Use something to make it easier to convey the message to the developers, to the testers, and to your vendors, beat up on your vendors, whether it be IBM, whether it be Microsoft, whether it be an open source project, yell and scream for them to do a better job of creating security in the parsers, in the processing, and in the frameworks that we're deploying. And with that, I think we're almost out of time. For more information, you can either email me directly or you can go look up the Center for Advanced Defense Studies at C4Ads.com, at that org, I'm sorry. Thank you.