 Hey everybody, thank you for coming. My name is Alex Stamos and this is... My name is Alex Stamos and this is attacking web services. Is that a good volume for you guys? Okay, great. This is a session from 11 to 1250-ish. We'll probably run a little bit early. But I'll be available for Q&A afterwards. My email address is in here. So at any time, please feel free to drop me an email. Also, I want to make this an interactive thing. It's really hard to judge, especially when we do background information, what people's backgrounds are. So please raise your hand, or if I don't notice, just yell out a question if you have it at any time during the presentation. Okay? So I was joking about the whole Cisco thing. Obviously, Cisco doesn't deploy any web service boxes, so fortunately. So what are we going to talk about? I'm going to talk about who I am. My speaking partner, Scott, was supposed to be here. He did a lot of this work. I need to give him a shout-out, but I let him go to his engagement party, because he's divorced because of DEF CON. So we'll talk about what we do, what web services are worth of being used, talk about the basic technologies and new attacks that we're now seeing in the deployment of these technologies, as well as traditional attacks that we've lived with for a long time, especially traditional web applications, that now can be retooled a bit to work in the web services XML world. And then we'll be doing a couple of demos. So it looks like the network's up for now, so we should be able to do a couple of those. If you want to play along, there's an URL in here. You can start downloading our software off the web and the 19 different Python packages you need to make it run. If somebody actually gets it running, you can play along while we do the demo. And like I said, please interrupt any time if you guys need something. So who are we? I'm a founding partner of ISAC Partners. We're all ex-stakers, all wounded children from the at-stake semantic merger. Based on the West Coast, we do consulting and research, mostly in application security. What are we going to talk about? Well, we're talking about web services. Why is that important? Well, they're deployed all around us, and it's kind of this stuff deployment that a lot of people don't realize, especially a lot of people in the security community. If you're in the enterprise security community or if you're an enterprise developer, I'm sure you've heard the term SOAP or XML from a manager or had to buy a book about it. But it's not something that there's been a lot of security research in. So, you know, we're not saying that this is definitely not the definitive talk that's going to be given on web services over the next decade. This is the first run-through. We found some bugs. There's some interesting stuff going on. But really what we're trying to do is create interest about web services in the security community and kick off research by other people. Because there's a lot we don't know. There's tons of acronyms out there that need to be attacked. And we're looking for your guys' help. So, like I said before, the latest version of these slides is that the CD is way old. icepartners.com. If you go to icepartners.com, you can click all the way through to speak engagements. And then there's a demo web service at wsdemo.icepartners.com slash xpathservice slash xpathservice.asmx. I will concede right now that there's somebody in this room with a botnet that could destroy this machine and make the data center itself fall into the gaping maw of the earth. And I concede you are bigger man than I. Please don't sin flood it or anything. I'd like people to be able to play around with it, okay? So, this talk is supposed to be not only talking about the security stuff, but we're going to try to do a background on the relevant technologies. Because like I said, a lot of people, especially in the security community, haven't been exposed to them yet, right? It's not something that you get off a CD. It's not something that ships you through Dell. It's generally not something that you can download off a bit torrent. And therefore it's not something that gets researched very much, right? And so, we'll give a little background on that. Please let me know if you have any questions because I don't want to spend too much time on that, especially for the people here who are experiencing web services. Then we're talking about some of the security risks that are associated with web services. A lot of them sound pretty much familiar because a lot of technologies are familiar or built upon older technologies. But there's lots of different things. Like I said, I think there's going to be a lot of stuff in the next several years, both attacks enabled through web services at applications that are insecure or in the frameworks and technologies themselves. This is not a talk about the WS-security standards. That's a class of standards it does, like encryption allows you to do authentication and authorization and all that kind of stuff. They're pretty interesting. They do all kinds of stuff. They come in books, 700 pages long. Nobody deploys them. So that's one reason I have to talk to them about them. But they're also about things like being able to do legal signatures online using a web service, which has nothing to do with actually attacking or defending that application. Just because you have XML signing, digital signatures enabled, doesn't mean you can't attack it. Just as if you have SSL on your web application and there's a little lock in Internet Explorer that doesn't mean your application is secure. It's kind of the equivalent. So this isn't a talk about that, which is good because you people would leave. So what are web services? It's a very overloaded term, mostly because you can get millions of dollars thrown at you by venture capitalists. If you put the word web services in Indian programmers, like in your prospectus. For our purposes, web services or communication protocols are based on XML. That's pretty much the only standard we'll be talking about that's universal. Lots of people do all kinds of weird web services, not like soap or any definitions, but just moving XML files around using HTTP or even SMTP and they call it web services. That's fine. But for our purposes, we're talking about XML as the base language. They provide computer-to-computer communication, which is an important point to understand and kind of underlay lies a lot of the security issues, is that these are things that are not meant to be consumed by human beings, at least not initially. It's not like moving HTML over HTTP where the goal of the HTML is to be rendered into something that a human being can read. A web service might be rendered into a GUI or something, but maybe not. And a lot of the technologies are based upon the idea that human beings don't have to be involved, which is both scary for programmers who want to be in their jobs, but it's also scary from the security standpoint. They use standard protocols. They're often controlled by the W3C OASIS and WSI. Web services as a technology has more acronyms than I've seen anywhere else. It is unbelievable. It's not my fault. I just want to say that up front, blame Tim Berners-Lee. And they're designed to be platform and transport independent. Although a lot of these standards have been made by IBM or one standard has been made by Microsoft, all of them are generally accepted and patent-free and able to be deployed by anybody. And that's kind of what makes them powerful and makes them so compelling. Why are they compelling? Well, these web services are based upon some pretty well understood technologies. How many people here have ever edited or created an XML file? Right, a lot of people. That's great. That doesn't mean that you've done web service programming, but you now have a basic knowledge that a lot of people inherited from the HTML worlds anyway to get into it. The adoption of web services has been very, very quick by large software vendors. The whole creation of these standard bodies has gotten rid of the not-invented peer syndrome. So Microsoft and IBM are willing to implement it without either one of them taking credit for the other guys' inventions. That's pretty unique in the software industry. One of the reasons they're compelling is that they're described as kind of a panacea for interoperability issues, both internal to the enterprise and externally, and we'll talk about some scenarios and that. But probably why they're most compelling is the magic pixie dust, right? This is the same magic security pixie that comes by when you plug your computer into the wall at Caesar's and it automatically gets an IP address and then it's automatically able to talk to the gateway, even though it doesn't know the MAC address through this crazy little pixie dust protocol called ARP. It's all these magic pixie dust protocols that make things happen magically and automatically and without human intervention that create insecurities. Because there's nothing secure about plugging into any network in the world and that's because everything has always been built to be easy and easy is bad. If there's not a human being involved saying, yes, you're allowed to do that, then that's a bad thing and there's tons of magic pixie dust in this. For example, this is a little, what, 10 or 12 lines of C-Sharp. Open up, anybody has MSD uninstalled, open up Visual Studio right now. If you create a new project, you point it at something that has a web server, IAS 6 installed and it's got ASP.NET activated. If you set up that project, you copy and paste this into a file, you compile it. It will automatically compile the C-Sharp into CLR, create an ASM, an ASP page that corresponds with that C-Sharp file, create a configuration file, create a web discovery document called the disco file, create a whizzle, which is the web service document which we'll talk about. Load all these up. If you have a UDDI server, it will automatically register with UDDI and you'll now have a function that if somebody over the internet can send a message to IIS, which then hands it up to an XML parser, which hands it to a soap handler, which then finally hands it to your program which gives it a string and then it goes all way back down with 10 lines of programming and there's then millions of lines of code running around it, which is, that's a lot of magic pixie dust, and that's the kind of stuff that we'll be talking about today. Another reason that you see a model of the place is the value is really well understood by the pointy hair bosses. This is just a little fake quote, but this is something that we actually see, right? I see a couple gray hairs and pony tails in here, so those are people that might actually know what Kix is. It's a crazy little programming language for mainframes, but you can't hire people that do it anymore, right? All those guys are retired after all the Y2K money they made, and so a lot of these enterprises have these IBM boxes from the 70s that their whole enterprises are running on. Now, it's their stock trading system or your health records or a bank, your bank account numbers are all on a mainframe, and they can't hire people to talk to the mainframe. So what do you do? Well, you go buy some IBM products because IBM is able to take machines they sold in the 70s and continually make money off of them. You go buy an IBM product and you hire these guys and they come over and they put some web sphere right in front of it and they create the soap interface by which, just using XML and HTTP, you can talk to the mainframe. And now I can get all these guys that have learned Java in 30 days books and have them write all my new enterprise applications to talk to the mainframe. Don't need to get any of those gray hair pony tail guys. And that is very, very compelling to corporate management, because they want to extend stuff and they don't want to spend money. Okay, so I have been told. This is issue number 13, numbered, independent, I'm sorry. It's the last issue of FRAC, numbered 13. They're individually numbered. It's still warm from the printing press and it's incredible leatness. And it will be given to somebody in this room today. And I have to come up with a competition while I'm talking to you guys in my head about how we'll do that. So we'll have some kind of hacking competition at the end. Let me think about how we'll do it. Pay any attention, because it will have to do something with the supplies, okay? Please don't mob me, slow down. There's a lot of security guys here. I know you want it, but put it here so you guys can look at it. Okay. So now we're going to talk about web services are being used, right? Where are you going to run into it? Like I said, web services are not something that you consciously run into, like you run into RPC and Windows, right? If you're a hacker and you use Windows and you don't understand like but a lot of people in the year have not run into web services, even though most likely everybody in here, either your credit report, your social security number, your tax information, your bank information, it's been moved over a web service protocol at one time or another. So where are they being used? Between companies. This is a big mover. This is the whole B2B thing, right? Which meant business to business, then it meant back to banking after the dot com boom but bust. But now it means business to business again and people are doing this using web services, right? We've got a pass not invented here so you can get your vendor to support it and it gets rid of these stupid protocols that people invented. I mean, they're not stupid, but these incredibly complex, dense binary protocols like EDI and stuff and all the X protocols that people have talked from company to company, you can get rid of those and now you can write it in nice and easy XML, you can read it in English, use it in HTTP, everybody knows how that works but they're much easier for people to use than these old protocols to talk from business to business. A great example, the credit card companies have these weird binary packed ultra small formats for doing credit card clearing, but they're also moving to doing web service stuff. So the credit card clear when your order comes in, can talk to the bank, which can talk to the credit bureau, which can talk to the lender and all this can happen over so and you can write it all in Java and you don't have to buy a specific product for the credit card industry. Or ASP.net and write it on top of that. In turn with the companies, a lot of people like to hook their stuff up, I want my payroll system to work with my inventory system, web services to connect with instead of people having to understand each other's formats. In front of legacy systems, I already told you about this, mainframes, AS400s, all that kind of stuff between tiers of web applications and this is a really interesting one for some of the bugs we're talking about. A lot of people are moving towards an XML data format on the back end, so if you do something on a web application, that XML data goes somewhere. Now it might go to an XML-enabled database, which can mean anything from a database that can understand XML and put it into a normal table, to being transported somehow and then eaten up by a middle tier software or something like that. This makes the X injections and it might mean X star, there's different kinds of protocols here, injections into those protocols, very interesting. And the way that most of the people have here, who here has used Google Maps? Who here has used Gmail? Right, so you guys have used web services. Those are AJAX applications. Asynchronous JavaScript and XML. They don't use SOAP or any of the heavy-duty web service, but it's still a web service. Really cool for people who haven't noticed, these are applications that allow you to do all kinds of interactive stuff on the page constantly, right? And it works. Microsoft came out with Internet Explorer, has the ability to talk to what's called the XML-HTP object, and now Mozilla now simulates that and stuff, even though it's obviously not ActiveX, but basically I can give you an HTML page once. It has a bunch of JavaScript in it. That JavaScript talks to this object in the browser, which actually does all of its communication. It's able to move XML files back and forth over HTTP, and it can do that synchronously, so it can do it multiple times. You scroll around in Google Maps, and it can spawn a bunch of these XML-HTP objects to load up the address separately from loading up the pictures to loading up this and that, and it gives you a great end-user experience. A lot of people are using this in enterprises as a replacement for thick clients. If I don't want to use a... SAP doesn't want to have to ship an end client for Macs and Linux and Windows. They'd rather ship something that just loads into Mozilla on all those platforms and allows you to have an end-user experience, which, you know, the user experience kind of sucked in web applications because of reloading the background and stuff, and you can get rid of that. There are some definite, interesting security issues with Ajax. We'll talk about that a bit. A lot of this stuff is also about the heavy duty protocols. So what's the point of this? The code is broken free, right? One of the reasons people like web services is you do lots of powerful stuff over one port. Because back in the day, everybody put their whole network on and they hired some firewall guys and they paid Cisco some money and they installed a firewall. And now if you look at the outside of a normal corporation, you'll generally just see SMTP, HTP, HPS, every once in a while a firewall one management port, but you don't see things like RPC open to the internet. Well, it's open to the internet again now. You're moving it over a different protocol, but now with web services you can move all this stuff over ports that people have had closed. So that's one of the reasons for some of these products, right? Get around your firewall engineers by our web service product. So our new slogan is we poke holes in your firewall so you don't have to, right? Just set up your firewalls once, fire network engineers, out of your functionality do a soap interface and you're done. So now we're going to talk about some of these technologies, give you a little background and the attacks with each. So XML. Everybody here kind of knows what XML is. It's this incredibly complex standard for representing all the data in the known universe, right? It sounds like a really easy problem for them to tackle, especially if it's supposed to be like English readable on top of it. And it's very hard work, right? You've got things like binary data, internationalization. XML has internationalization built in from the beginning, right? Unicode 1.0 is the standard for XML. With XML 1.1 it'll be Unicode 2.0. This makes internationalization attacks really interesting, because we've seen these attacks before, minimal UTF-8 encodings, doing things like changing character sets to do like SQL injection and cross-site scripting. That's always been kind of stapled on, because internationalization was stapled on to web apps. With web services, internationalization is from the beginning. And so if you talk to something that understands XML, it probably understands all those character sets. You no longer have to get lucky, like somebody installed the Japanese character set pack on SQL server, but you used that to get it. For internationalization attacks, you should be covered by other people, but definitely move over to web services. You have to represent meta-characters, you have to be able to define and validate how these documents are, yada yada. Because of the size of the product space, we've ended up with dozens and dozens of standards. And very few people understand a lot of them, and there's nobody who understands all of them. Which is a little different than web applications, right? Because it's pretty easy to understand both HTML and the HTTP. Okay, I can understand how those work. Maybe I can't recite the RFC. But it's almost impossible to do that with web services. There's a couple basic strict rules. Why do you guys care about it? Well, when you're attacking a web service interface, you generally have to use legal XML. If you don't, you're just attacking the parser. And people have done that. People have done part things that do all kinds of wacky stuff with XML, but people have done that before, right? What we're trying to get to is the applications behind that standard XML parser. I'm not going to walk you guys through how this works, but here's a simple element in the XML attack, right? That's called the parent node. Those are called children nodes. Here's a full legal document. It does things like define the encoding. This is obviously a Latin character set 1 for us English speakers. The default encoding for XML is UTF-8. Which is great. This is the definition of a namespace. This XML document belongs to this namespace. You can, like, if I had manufacturer or shouldn't overlap with somebody else's namespace in the XML document, I also define a schema by which this can be these urls aren't real. Don't try to grab them. A schema by which this document can be verified. Schemas are the way you verify documents. DTDs are the old way. It was a non-XML basis. This weird thing with colons and stuff. The great thing with DTDs is there's a number of nasty attacks that have mostly been fixed. But as people come out with new XML parsers, they might be in there again. One of the attacks was to make a self-referencing DTD that could say, oh yeah, I define that type B. And then B defines type C, which defines type D, which types E, and then E defines something that has a subtype A. And you can get the DTD parsers to infinitely loop. You could also reference things that are external to the DTD, but mostly things have been fixed already. XSDs, XML schema documents are XML-based. They're the new way of doing it. The important thing for security people to understand is that from a defense perspective, XML schemas can actually be very powerful. From an attacker's standpoint, nobody uses them, so who cares? Like I said, they can prevent many of the attacks we're going to discuss. So if you are on the defense side, think about validating stuff with a strong schema, and don't do stupid stuff like having the all tag and stuff like that. We'll talk about that later. This is a schema. It's pretty readable. The only interesting thing here is I have a restriction that I have an element called year. I'm saying it has to be an integer, but this means I can't do SQL injection in the integer field. If I give it something that looks like a string, the XML parser itself is going to die whenever it gets close to the database. So here's a little bit of a protection. Most people don't do this kind of stuff. The magic pixie dust that we talked about generally doesn't include XML schemas. So parsing. I get an XML document. How do I read it? There's kind of two standard ways. Both ways have security flaws. Simple API for XML, I think it is. This is a step-by-step stateless parser that expects you to store the state. It's kind of like a thing I say, go one more step, one more step. Oh, you have children node? Okay, I want that child. I want that child. It's nice and lightweight. It's pretty easy to use, but it's not very powerful. It has the downside of if you use a sex parser, you have to track what data you've got. If I want to get out of that car, if I want to get manufacturer, I have to say car, okay, I got car, I want the child name manufacturer. It gives me a manufacturer, and then I have to store it in a variable for myself. And there's an attacking asset called XML injection that we'll talk about. And then the other one is DOM, document object model. This is really powerful parsing. Most people do it in enterprise applications, and that turns out to be a bad thing from a denial of service standpoint. Because building, if I have a big XML document, it represents all the nodes that are linked to all the child nodes. It's linked to this, it's linked to this, and each one of those nodes is an object in Java with its own garbage collection and all the information that gets wrapped around any variable in Java. So DOM has issues with denial of service. And then there's always a really bad idea. People make their own parsers with like regex and stuff. Don't do it. You can get an XML parser for every language. There's no reason to do it again, because you'll probably screw it up. So an attack. You can sex. XML injection. So this is the situation in which the attacker can control a string that gets put into an XML document. There's multiple ways this can happen. This can be an XML document that is standing in for like a database query. If I send, maybe it's my user login, and it puts the login information I give it, and it puts in the XML document and hands it off somewhere else to get parsed. Or it could be something like a document I upload because that's how I upload data. It could be a lot of things. If I can control text in it, and it's not being input filtered, I can put more XML tags in there. So in this situation, we have a user record. Let's say this is a bank, and I've created my user because I have a bank account, and so I go in and I now create my web user, and it asks me for something like my email address. And so when I fill out my email address, I give it an email address, and then I close the email tag, and I create a new tag called Unique ID. And then I say the email again. This is for the parser. Why did I put this Unique ID in here? In this situation, perhaps I have some knowledge of how the XML documents laid out. I know that there's a Unique ID child node in there that defines what my ID is. This is like a Unique ID that's used by the application itself. And so with a SACS parser, if I was writing a SACS parser to read this generally, this is a fault with the application, not the parser itself, but we see it over and over again because people don't expect this, is you step through the document and you go to use a record and you say give me the first tag, and it says, okay, tag is Unique ID, value is this, and so I write it to a temporary variable, and then I say name, and I write that to a variable, and I say email, and I write that to a variable, and then I get to Unique ID again. This is the same kind of information to put the zero back in. So who do you guys think user zero is on a web application? It's the admin, almost always, right? This is the same kind of, when you do SQL injection, you do or one equals one, it gets the first user in the table, and it always turns out to be either like the developer or an admin, it's the same kind of problem. And so the SACS parser, if I step through like this and store it in variables, gives me Unique ID of zero. You can only have one Unique ID for the user record, or you can use a DOM parser which you would specifically reference one of these and would probably check this. No, oh, I'm sorry. So this red, you're right, that's an excellent question. Why not do Unique ID zero in the first place? This red area is the only part I control. So this is a web, I imagine this is a web form that's taking my information and putting it into an XML document where it stores all my information about my bank account. Does everybody understand that? So I can only control what's between these two tags, and it puts it in, and as you see, I have to do the email twice so that there's not this hanging email tag out here which will make it choke probably, right? So like I said, for defense, you do an XML schema validation, or you can use a DOM parser, or you can go through and check to make sure that you don't get multiple input. This also works with XPath, which we'll talk about. So if I did this attack and somebody was trying to pull this information out using XPath even with a DOM parser, the attack would probably work as well. So, which takes us to XPath. XPath is this very simple language by which people are supposed to be able to reference what's in the XML document. It's kind of a cross between directly these things and regX. XPath number one was supposed to be nice and simple. It has like 20 pages of documentation, the standard. XPath two is something like 300 pages, and nobody's read them all yet, so I'm not sure what's in it, but it looks really scary. But these attacks work on XPath one. So say this is our car example. XPath entries are something like so I get this XML, this is part of it, I load it into a parser, and then I want to ask the parser for information from the XML document. And so one of the things I might ask for is let's say there's a bunch of car nodes in this document, it's a big list of used cars. I want to return all of the children nodes. XPath queries always return a list. It might be it's like MATLAB or something. It might be a list of one item, it might be a list, which is really interesting because if I just say car, it gives me all of them in a big list, all of these nodes. If I return, if I do slash car, that just gives me the root element, right, only the first one. If I do slash slash car, it has all the car elements in the document. I'm sorry, car, if you say just car, it's all the children of the car. Car slash slash color will give me all the color underneath the car. And then the interesting ones, search for car and give it to me the list of cars where color equals blue, right, and you can actually do pretty complex queries in here. And as you can see, this is really, really cool, right, because this makes it really easy to get information out of an XML document because this is a pretty easy to understand language and if my document's not incredibly complex, this is much easier to use than doing all these, you know, Python or C-sharp calls to the DOM parser. What's the downside? Well, we'll get to that in a second. So where do people use XPath? People often use it to talk to databases. It's starting to replace SQL in situations where people are storing XML data in the database. All of these, XPath is supported by all of these database servers. I think you need like SP3 or something for 2000. So what's the problem? Well, like our old friend SQL from SQL injection, XPath puts data and the demand you want to do puts the verb in the noun right next to each other and those are delineated by our old friend the single quote, right? So if I want to say give me the car where the color is blank, I use the single quote to say this blank describes the car. That's not a command I want you to run. That's a description. Unlike SQL, there is no access control in XPath or XML documents. So generally, if you run the XPath query against an XML document, you can read everything in that document. That's good, right, because sometimes SQL injection just doesn't work because they have a good database schema that doesn't exist here. There's also no real safe way of using XPath, right? A lot of times we'll do a pen test, we won't find SQL injection, we'll say hey, no SQL injection, congrats, you must be doing really good input filtering, and they'll be like input what? And we'll say, well, why don't we have SQL injection? Well, it turns out because they want things to run faster, they use prepared statements, or they call in distored procedures and that's a nice secure way of doing it and SQL injection doesn't work in that case. There's no secure way to call it. The way people always call it is you can candidate a bunch of strings together and then you give that string to the parser, right, which is the bad way of using SQL, that's the only way to use XPath. So the outcome is if I can control any data that gets into an XPath statement, and I can get a quote in, I can return arbitrary data and access arbitrary stuff in the document itself. And here's the example. So this example says this bank again, and I've created an XML document. I don't need a database, right, because I'm a small bank, so I just keep a flat XML document of all my users. I've already been XML injected, so I fixed that, right. Oh, I'm so stupid, I should have known that people couldn't gotten stuff in. And so I fixed it by going over to a DOM parser, a nice big complicated parser that you can't do XML injection against. But since it's so hard to use, I'm going to use XPath to get information out of it instead of stepping through it, step by step. And so one of the things that I have to do is when people log in, I have to go see if they're in this big flat XML file of users. Have you been with me so far? Okay, yeah. Great hypothetical, huh? Real original. So I'm going to create an XPath statement and then give it to my parser and it's going to look up the user for me. And so I'm going to say slash slash user, search for the user whose name is equal to Joe and his password is equal to let me in. And the two red things here are information that comes from the web form, the login and the password form. Okay, that's fine. It works. This will return a list of all of all the users, right, because it's slash slash will be a list of all the users that match that. Probably only one. It should be. But it does return a list, a list of one element. So now we come to our new canonical statement that will replace, if you're really, really cool, quote, what's the canonical SQL statement? This will be the first point for getting the book. Raise your hand. Yes, sir. Back there. And then what after it? Dash dash. And maybe semi-colon dash dash. Depending on that. So this is our new statement. Everybody memorize it, put it on t-shirts. I have to get money from the t-shirts. But I've actually seen that life on t-shirts, which is horrible about me and my social life. This is our new canonical statement that will tell us if Xpath injection is working. Single quote or one equals one. Hey, that sounds familiar. Or single quote, single quote. That's not a double quote. That's two single quotes. Equals one single quote. I know not everybody can see it, but download the pdf it will be in there. So what this does is now I have give me all the users whose name equals gel and my first single quote flows out the gel string. Or one equals one, which is a cylinder, what's the word for something that's always true? A typology. Something that's always true. So this always returns true. Or quote, quote, equals quote, quote. Why do I need that quote, quote, equals quote? Anybody? To get rid of the last quote, right. So I don't have, Xpath doesn't have the ability to do comments in line, like SQL. So I can't use the dash dash, which we use for SQL injection to throw away the rest of the line, or a semi-colon to make minus statement and then make the next one a different statement. I have to actually use what's in my application. And so the easy way to do that, I've got a single quote floating out there, is I create an empty string, and then I create another empty string using that single quote. So only with the red stuff I control, that last black one is put in there by the application, but I neutralize it by doing this. And password, let me in. So why does this work, because it's an or or and? Anybody? Why would this work? Well, the end's not quoted out, the end's used, but sir, obituary or president. Somebody took a first year CS class and hated it, right sir? Yes, operator presidents. The thing that bites you in your ass when you start CS. When you look at this, the first does the end. There's a implied parentheses around this. So the end is the first thing quote quote and pass it to the end. So this turns to a not, but then we have false or true or false, which turns into true. And so what this does is it returns all of the users, because it's a typology. It returns a list of all the users. Well, what use is that? But like I said, XPath, everything's a list. So if I'm using XPath to log somebody in, I have to take a list and what do I have to do with it? Well, not to protect, but what do I have to do just to use it normally? I have to ask for the first element and then use that as the login, right? So I just ask for the first element anyway and the first guy who's returned because my login is here. Does that make sense to everybody? Right? A lot of people yelled at me at Black Hat because they're like, how good it worked because it returns multiple things. Well, unlike SQL, in this situation, everything is a list. So I'm going to take this output and ask what's the number one guy and use that person, the first child. Thank you. So if we want to get all super powerful, we can do things like now change and put more stuff in there. This is obviously much more useful if you have access to information with it. You know how the XML is laid out. So this is a open source or a commercial product that you can get your hands on and you can figure out how the XML is laid out. And we can do things like create more rules and change around the statement to do all kinds of cool stuff. And we'll do that. I'll show a demo of that later. So like SQL injection, this requires some knowledge of the query which makes it much easier if error messages are on. How many people in here are going to vote that they don't give you all the information by default in all the major web service stacks? Anybody want to take that bet against me? I'll give you ten to one odds. Nobody. Okay, that's true. The default is given them all the information they need to make an XPath query and we'll show you on the defaultasp.net Even if you can't get access to it Amit Klein who used to be of Sanctum, I guess he's not there anymore which is now WatchFire, which is now probably today it's Verisign and tomorrow it'll be part of Time Warner. I don't know what's going on in the security industry while I'm here. But you were next on paper called blind XPath injection. Drop that into Google and you'll find it. He claims he has a way of getting the entire XML document out bit by bit by creating a conditional that's set on what the next character is. And so whether you log in or not is that one bit of covert channel you get out. Of course, they had a test of like there's 40 characters after and it took like two hours to get those 40 characters out because you have to do all the logins and test all possible characters, which is pretty cool. If anybody knows him I'm trying to find him, have him release the tool please so we can play with it. But XPath 2 might give us a lot more ways of actually getting all that information out. XPath 2 does a lot of cool things like you have the ability to reference outside documents. I can have tests that ask for information from an outside document. Like if this user is equal to the user in this, now the control of where that outside document comes from isn't really defined by the standard. That's going to have to be up to the people that write the implementation themselves. So how many people want to bet that at some point you're going to be able to get a document from your web server. And that way I'd probably be able to link a bunch of information about the rest of the XML. The future if you guys want to be really, really elite and get the next t-shirt before this t-shirt that's going to come out after this t-shirt is Xquery Injection. Xquery is a super set of XPath that is now the standard for talking to XML databases. And one of the really cool things it can do is it can reference a bunch of different documents and stuff. Downside is now people are actually building access control and it's a boo-boo. We won't be able to read everything, but that hasn't stopped us of SQL Injection, right? And in this attack, and a bunch of other attacks that we're talking about, our big friend is CdataField. So I'm not going to talk about it in detail, but it's basically just a way that XML has built in to get nasty stuff in the XML, right? Things that XML that you don't want it to interpret as part of the XML document, you put it in the CdataField and it disappears. So I can put things like with single quotes and with brackets and all that kind of stuff into a CdataField and that goes into the XML parser and then when you ask the XML parser for the string, it gets rid of that CdataField for you. So the application never sees that you did that. There's also other methods that work just as well, but the CdataField is so powerful and easy, it's the best way to do it. Once again, XML schema is for defense. You can turn off CdataField to XML. Oops, that was bad. So any questions on the Xpath Injection? And it shouldn't be X squared. Okay, I'm going to demo that at the end because that's the cool one. So soap is a standard where all of these like really cool web service stuff, this is where a lot of the magic exists. It's a standard that defines how to move XML around that can do remote procedure calls. That can do RPC calls. It's generally over HTTP, but it doesn't have to be. Soap is defined by things called whistels. Whistels are these really ugly documents that are never meant for human beings to read. They're meant for computers to read and they're generated by computers and the great part of them is that as an attacker, as somebody who's scoping out an application, the whistel tells you everything you need to know to attack the application. So this is so much more powerful than we had for web application hacking. Because to do a web application hack, you have to start off playing with the application for days using a user trying everything and then mapping it out and seeing all this functionality it has. With web services, they just tell you up front. They tell you, these are all the things I can do. These are all the things you can ask me to do on your behalf which is really, really cool and it makes a lot of things a lot easier. Generally, asking for whistel is as easy as adding a question mark whistel at the end of a document. And we have a tool that will do this automatically for you so you don't have to go through and do a question mark whistel over and over again. They define all this stuff, this is just for reference you guys that need to know, basically defines something like if I had a service that sold used cars it would define how I ask you to sell me the car and then your response to me and what that means. There's no way you can read this. This is like a third of a single whistel for a very simple eBay thing. It's incredibly complex and dense. What's good about that? That means that the developers that wrote that almost certainly never read the actual whistel. The whistels are generally automatically generated like my thing I wrote before. If you write a bunch of stuff that's accessible through web services and you turn it on, all of a sudden the whistel is generated that tells somebody all those things so they can point a web service at it and not have to talk to you about it. That's the whole idea. And so that often includes things like hidden debug messages that you've actually seen this. This is a web application that was ported over to having web service support and they had ported over all of their functionality. I think it had been on struts or something and they ported out all of this functionality over to web services. And one of the methods in the whistel that obviously they never read was make me admin. It was a debug call that a database that the developers would have just normal low rights users could make that call and become the administrator of the service. Now, they had had that in the web application before and it had never been attacked. Why? Because it was a parameter you had to put into a post. And that's not something that somebody might not make me admin might not be something that you guess and that you shove into every single parameter in every single post. But I didn't need to try anything. All I had to do was look at the whistel and I said it right there make me admin. It takes like a user ID for which admin you want to become. That has always existed and now it's just really, really simple. There's also all these cruft systems. Who here knows of like a 1am batch FTP job that they're embarrassed about, right? Come on. Yeah, right. It's unbelievable what's transferred over FTP in the middle of the night. Like if I was a router engineer, I'd be all over it. All this kind of stuff is getting moved over to web services. Nobody's ever thought about security for them before. Maybe they've been kind of hidden because you have to be on the right router at the right time to get the information. Not only if they do is ask and you can use something like UDI to say, hey tell me all of your secret services. We'll talk about that. So what's your defense? You can manually review the whistles. Everybody should know what's in their whistles with their broadcasting in the world to make sure there's nothing in there that's supposed to be a private function or that you're really embarrassed is in there like debug functionality. You can hand edit them. Like Google writes theirs by hand I think. Mostly for compatibility issues reasons. But the better part is don't have things like make me admin in your production app, right? Get rid of that before it gets out of production. So there's a number of different attacks with XML. One big one we'll talk about a lot, not a lot, but we've got a couple slides on is denial of application level denial of service through XML complexity. And so obviously it takes XML, but you're probably wondering, you know, obviously I probably can't give so arbitrary XML, right? Because maybe a method only wants, it says, you know, buy a car and all it takes is the VIN number. It takes one string. How do I shove arbitrary XML into that one string? Well, these fun things called soap headers. Soap headers are part of the message that almost nobody ever uses, but everybody listens to and reads. And they're there because, you know, all these things like WS routing and all the encryption standards and stuff use them. You can put arbitrary XML into soap header because there's no definition of what can and can't go in there. And that gets read and parsed by the application. You can also do some source routing sometimes. Sometimes people have multiple applications that are exposing to web services. And so they have to make a decision on where, who you talk to when your message comes in. Well, sometimes that decision comes from the header. And that can be set by the application itself. This is like a client that you downloaded or something. If you see something that looks like routing in the header, try other things that sound like they might be web services inside the application and see if you can get it bouncing off a different game than the inside. Soap has a lot of session management problems. It doesn't have session management. Just like HTTP. You do a post to get, you get a response. That's it. That means people have to develop their own session management. A lot of people do dumb stuff. Like they use cookies, right? HTTP cookies, they still work. Obviously it's not a browser on the other side, but somebody has to understand it. Well, what happens to that cookie once it hits the web server? It's stripped off, right? Like this XML document's going somewhere. It's going to a mainframe. It's going to a database. That cookie doesn't go with it. And so this causes a lot of access control problems for people because they're setting these cookies and they never see them actually where they're making decisions. So that's an issue. There's also all the old classical state issues. A lot of people have to implement their own state mechanisms. They haven't had to do it for years, right? They've been able to use web spheres or ASPs, a little cookie. So they're kind of old at it. And they don't remember that doing things like counting up from a thousand and making the next user number a thousand and one in that field is definitely a little bit guessable, right? As are things like counting up from a thousand and doing that. So we see that all the time again with web services because people have to roll their own. So this is a soap message. Yada, yada. It's kind of generic. You don't want to be actually writing these by hand. They're really hard to write by hand to make them accurate. And I'll show a little free tool that you can download that does all the communication itself. Remember, we don't have a web browser here, right? When we're talking to a web service, it's expecting another computer to talk to it. So we don't automatically get something that has a string. You'll see in a demo, there's something called Soap Faults. If something breaks, it sends a fault back that has a string. So who here can find the interesting part of this? So what do you think this is here? What does that look like that we've just talked about? That looks like an XPath query. This is the default functionality of ASP.NET 1.1 ServicePath 1. If XPath breaks, tell the user. Tell the user exactly the XPath and how it broke. We'll demo all that in just a second. And then something I talked about was web services to all service. This is, in my opinion, much, much, much, much, much more powerful. I'd rather have a good XML attack than a thousand bots on a botnet to do a SIN flood. Why? Because I have a huge, huge multiplier. I don't have a huge multiplier with a SIN flood now that they've got, somebody's got a hundred thousand dollar arbor boxes, or really nice net screens or something on the top. But I get a huge, huge multiplier with an XML attack against an application. And I have to look for this advantage. And often this advantage we've explored two different types. We're not releasing the code because it works too well. But it's pretty easy to recreate it yourself. But you either do attacks against the the parser itself, or against the application and its database backing. And against the parser itself, you get very large multipliers of CPU time and memory, right? If I can send you an XML document, how hard is that for me to send you a text document, right? It doesn't have to be dynamically generated. I don't have to use .net to create this document. I only have to write it once and send it with a purl script. So I send it once. Okay, that's a couple cycles. I can probably do a couple thousand of those a second. When it gets to the other guy, he takes that document and he says, okay, well you want me to download a schema, and you want me to set the namespace. Now I'm going to build a model that represents this document. So I have the code, which is A, and I have the child node that's B. Oh, and B has a child node called B. And B has a child node called B. And repeat that a hundred thousand times. And then close B off a hundred thousand times. And that guy builds a object in memory in some heavy duty language like Java or C-sharp, where it's not that memory management isn't that easy anyway. It uses a lot of memory. And it builds this huge object that's a hundred thousand objects long and deep. That is a huge, huge advantage. And all that happens before it makes a decision what to do with it, right? This is just the parser. The application hasn't even seen that anything's happened yet. This is the magic pixie dust framework that's done all this work for you. It gives you a huge advantage. How big of an advantage? Well, we've taken down four enterprise enterprise level hardware with a real patched good web services server with one of these laptops. Right, CPU pegged them. Because, and I don't think the CPU's reaction from the parser is called memory management, so every time a message came in, it would build that DOM and then it would destroy that object. And then do it again and again. Because we can get a couple thousand queries a second, or a couple thousand a second out of some twenty threads of pearl. So that is really, really powerful. And that's, you know, it would take a lot more than one laptop to sin-flood those four boxes, right? Especially if they have a real load balancer. The other attack we've looked at is database connections, right? Database connections are coming from a pool. There's a limit of how much they're pre-created and then they're used and they're usually not like even for sites that have millions of users, there's something like 200 or 500, right? Because they're only used in one that query is going to cross. So, like we said, this whizzdle tells you all the things that it can do, right? And you can do all of those things, it's stateless. You can do all those things as many times as you want generally, unless they're doing something very smart. And so what do I do? I go through this whizzdle, I find something that looks like it's a very heavy duty thing that it has to look up in the database. Somebody named a query in which you have to read a big table and you have to do it every time somebody asks you. Login, right? If I log into a machine and it's got a big list of users, and I give you a username, especially if it's randomized and you don't have it cast, you have to go ask the database, who's this user? And so to create these user requests with random user names and passwords over and over again is not very heavy duty, but it requires it takes up one of these connections during the while it's asking that question over and over again. And this is a great thing against enterprise servers because often, especially sites that have been dosed before, they have 20 or 30 or 40 front-end web servers. How many database servers do they have? One, two in HA, or maybe two HA clusters, right? And that HA is probably cold failover, so they're not actually running. So, and it's not considered a failure when you use up all the database connections, right? That doesn't mean the box is broken. It just means that the queue is filled up. And so we've also done this against an enterprise system where there's a ton of web servers in the front and two database servers in the back in an HA config and with a couple of laptops, we choked the database server. The database server only had like 5% CPU used, but that connection pool was all used up because we did something that took a lot of time. Why doesn't this get caught in normal testing? Well, in normal testing, you don't log in 100,000 times over a course of two minutes, right? That's not part of people's regression testing. You log in once and then you do the heavy duty stuff. And so that kind of application level attack, well, it's been doable with web applications is really easy with soap, right? Because the login all I have to do is change a little bit about the particulars and maybe generate some random user names and my pro script is destroy the database. In either case, there's some important things to remember. You have to have a legal soap request, right? You don't want it thrown out before it hits the application, especially on the database side. And then speed is very important too. We used multiple processes with multiple threads but you know, it is still a little heavy duty compared to like a sin flood. And obviously the attackers position is coming away. So that's a downside for the attackers. It's a good thing for the good guys, right? Because you have to use real TCP connections to move this stuff across. But you don't have to listen to that connection, right? You can make a connection send them the post and then drop it. If you're using your own TCP stack then just stop listening. Don't send a reset let it respond but you don't have to actually have that memory allocated to get the response. Makes it very, very efficient. We're also looking into ways to make it faster like HV1.1 pipelining. This is especially important with like SSL because I don't want to do an RSA transaction for every post I do. I do pipelining. I just send them all up with like, create a pool of 20 or 30 TCP SSL connections and send them up. Or things like XPath. Anybody hear about those crazy reg X attacks? That you can do to not have service by getting somebody to do a weird reg X that's really, really hard? Well, XPath, obviously if I can do arbitrary things in XPath, I can probably do my XPath injection that are really bad even if I can't use it to own the application. Unfortunately, defense isn't very easy for us. For things like the soap header XML complexity there's nothing you can do as an application developer in your application, right? Because like I said the soap message comes in even if it's not for you, you've never heard of it at your application. It's the web sphere or it's access Apache or it's asp.net that's doing it for you. So the only defenses against that are something like you have an XML firewall this is one of the reasons they actually sell a couple boxes a year that looks at them and has limitations on it. You can set your own limitations like if you only do small messages use 50k messages and you set that in Apache or IIS and so that's important. There's no reason somebody should be able to upload a 20 megabyte XML file to you, right? Or you can do something like write your own Apache filter or something like Apache mod rewrite or mod proxy to look for this kind of stuff. Sacks is not vulnerable, right? Yes, sir. Limiting rate from source IP. So you could do it from source IP. Of course this is the problem everybody's running with other issues. In situations like an AOL situation you might kill one of their 12 mega proxies, right? Or, you know, whatever Nippernet has like 15 ways it gets out to the internet or something like that. So I mean you could rate limit by source IP. The way to do it is you need to make them do work to ask you. So you need to have them ask you for a session ID You generate a session ID randomly. Don't put it in the database. Just generate randomly in memory. Give it to that person and then have them send it back with the login information. And then you can check against the table in memory, which is much faster than going to the database. As for the XML stuff you have to put a protection in front that looks for the complexity and stops it before it gets to the web server. Either that's a firewall or it's your own thing. Oh, right, in size. Yes, I do recommend limiting size. If you never have anything larger than 50k, send it up to 75 or something. Most people almost nobody thinks about that, right? And by default this stuff accepts up to like 20 or 30 meg posts and stuff. And that's when it gets really nasty, right? It takes a minute to you know, takes me 30 seconds or something to upload a 20 meg post over a 100 megabit connection and that takes a minute for it to parse it. Right, so... XML firewalls are these... Well, okay. So it's another it's another venture capital term. So it's something that makes people venture capital. A basic definition. Generally there are things that sell that look at XML. They're like application level firewalls. A lot of the XML firewalls aren't created for security purposes. They're created to do stuff like routing. So if I have multiple web interfaces, web services, I can just put one box in front of them and it's kind of like a load balancer. And it says, oh, you want to talk to the mainframe. I will send that information to the mainframe. Oh, you want to talk to this database. I'll send the information to this database. But they now, because of security issues they do things like they'll check for the complexity of the document before it comes through and not let it through. So kind of like, you know, SyncThem's app shield in front of web apps, XML firewalls or silk firewalls, web service firewalls, whatever gets you the most money right now, whatever they're called, look at the request and filter it for things that might be dangerous. They'll also do things like look for SQL injection and XPAC injections. I can't always recommend them. I mean, for most this is one of the only things that you can't fix yourself. If you have a SQL injection bug, fix it. Don't spend $100,000 for a hardware firewall that's now in your critical path that if it turns out they didn't do the right thing with their TCP stacks somebody can toss it anyway and take you down network blocks, right? Or it's something you have to pay to maintain. Um, there are not some things that you can just, you know, drop it from your app and expect it to work. Anybody here sell XML firewalls? Obviously we're not a vendor. Excuse me? Uh, I think Terros might do this kind of stuff. Forum systems, Sarvega, come up, somebody come up with a prefix and post fix for a startup company and it's probably there's like 20 or 30 companies to do it. Like I said, they're mostly to do stuff like I want to do encryption on my web service I don't want to write into my app so the box will do it automatically or something like that. So any questions on the DOS? Like I said, we're not releasing them but it's pretty easy for people to recreate them. You just need to build really complex but legal XML. Um, and it can be, you know, complex just means deep, right? If I have five root nodes that have 100,000 deep child nodes, right? It's not just the number of nodes but it has to be the linkage between them for something like a DOM attack. Uh, that's a really, really powerful attack. It's pretty easy to recreate. Obviously there's no reason for us. It would not be a very ethical thing to release them. Um, so discovery methods. We talked about wisdoms. Uh, I don't think we'll do it. I'm talking about this real fast. Uh, UDDI is another great discovery method like a wisdom what I talked about just to find one service, right? You ask for a service, how do I talk to you? How do you find that service in the first place? Well, there's this great thing called UDDI which lists all the services that somebody's running. Right? So, yes sir. Yeah. No. No. They will not load. People learn their lesson off the DTD attacks and they will not load off-site accessities. By default. You can tell your XML parser that you want to. Um, but, you know, I haven't seen anybody do that. Sure. Any other questions? I'm sorry, on the DOS stuff. Okay. Um, so UDDI is a way I can list all these web services and, uh, you might think that nobody's deploying them, but I've seen a bunch of them, right? A lot of people are doing testing of web services right now or they have two or three that their business partners use and so they put a UDDI server on the UDP. It's nothing very complex. There's a bunch of free Google for UDDI browser and you can download free ones or your web applications that will do it free for you. Um, and then they put these IP addresses out and they told their B2B partners, wow, you know, it's so hard to set up a VPN so what we're going to do is we're going to give you our UDDI address and then you guys can figure out how to hook up to them SSLs on, right? So use SSL. That's what we'll use instead of VPN. And they expect people won't find these UDDI servers, because if you do Nmap-A, I think right now, won't say this is a UDDI server, right? Because it's just a, it's just a port 80 CD out there, port 4, port 3. Um, the great thing about UDDI is it tells you everything you need to know to attack a web service. And it tells you if an enterprise is deploying it, everything they're deploying. Now, they don't have to list everything but like I said, some of this stuff automatically lists if you have a UDDI server, a visual studio will automatically list it up for you. Right? So how do I find UDDI servers? Well, IBM, Microsoft, SAP, and Nippon, Telegraph, and Telephone have very kindly stepped in and given us a nice searchable web interface that tells you UDDI servers that people have registered. So you guys see this hierarchy here? The whole idea is that, you know, I should be able to do a web service with another company without ever talking to somebody at that company. So first I go to the UBR. I search, if I want to talk to SAP, I search for SAP. I see all the web services that they're listing and I go to the UBR will tell me their UDDI server if they have one. I talk to their UDDI server and it has things like invoicing, right? Maybe I want to do I've sold them some stuff. I want to invoice them. And so it says the invoicing web service this is the contact information for that person and it exists at this URL. And so I go to that URL, I add a question mark and the invoicing service tells me, okay, these are the nine things you can do with the invoicing service and now I have the ability to do whatever I want to those different methods. So that's the tree and that's how people envision it. Obviously it makes things easy for businesses but it also makes things easy for attackers. One of the really scary things is there's currently no real binding of somebody who's in the UBR really is that person, right? Like this next one, who here is going to trust this entry? Bank of China, right? There's no cryptographic protection saying this is the Bank of China but here they are, they're listed in the UBR and with a character set that I can't read in my browser because I don't have the chance to read it, right? Now people are working on these big PKI's by which you can authenticate web services but people are fighting over the standards. Obviously it's a lot of money, just a lot of money to be able to sign certificates for web apps. It's going to be a lot of money for web services because it's only corporations, it's very rarely individuals and so there's no good way of verifying this right now. So we'll do a little walk through a UBR. Microsoft has the prettiest interface so I think I'll use theirs. So fortunately Microsoft puts up a big barrier to keeping attackers from using a UBR. You have to be registered. What kind of registration do you think you need? A passport. So I mean if that restricts all attackers with a hotmail account I think we're all okay. I'm going to sign in first so you guys can't razz me as how short my passport passport is. Are any of the passport guys in here? Passport's great, by the way. Are any of the passport guys here? Okay. They're actually, they're some really smart guys. Okay. I'm going to talk about something while this is loading. What? It's all right? Go in a book. Excellent. Yeah, because this is going real slow. Somebody's tossing Microsoft on probably so. Okay, competition. Okay, the first person who can raise their hand and give me the new canonical X-Path gets the prize. Yes sir. All right, next. The next, the injection attack itself. The string. Yes sir. It's not a semi-colon. It's not a semi-colon. Okay, I'm going to close my eyes. I'm going to say yes. I'm going to say now and then everybody raises their hand. Jesus, there's no way to do this. Now. I think, I think this gentleman was up there. You are the winner sir. What is your name sir? Come on up. Get your prize. And he can't even see the slides. That is amazing. What's your name sir? I've spotted the Fed. The shirt. Okay, that was perfect timing Mike. Good work because now I am logged in to the UBS. Now I'm not trying to beat up a Microsoft. I'm just using them because they have the prettiest interface and you don't have to really register. You just use passport. But as I said, those four companies all run UBR nodes and they all sync up with each other. So this is the same data from all of them. So we can do things like we can register ourselves as users. We can publish ourselves. Like I said, when you publish yourself as Bank of America, nobody calls the Bank of America headquarters to make sure, right? A little information and stuff. Let's try the search field. What should we search for? Any chase? Okay. Like a car chase, you mean, right? Well, another cool thing is they've got all these, well it's not cool, it's actually incredibly boring, but it might be useful, is that there's all these different ways these web services that are all competing. Like the government has some and then the Visual Studio has its own and all this kind of stuff. And eventually, when a lot of people are using it, you should be able to walk your way down this tree and find all the things that are important. Finance, that sounds like important. Pretty easy. It's amazing how many lovers there are. One. That doesn't mean that they've actually categorized everything. Anybody see where I search by name? Maybe it's there. You're right, you're right. So I can provide, providers is like the English name of the company or enterprise or whoever it is. I'm going to do something more general than chase because I'm not sure they're in here. I'm just going to do Bank and we'll see what happens. There's not a huge number of people because there's not a huge number of people deploying them publicly. One of the things that WSWISMAP is one of the tools that we're releasing. One of the functionalities we had to pull at the last minute. So, it's funny if you buy like a Learn Web Services book and it's got like an example how to do a UDDI registry, search for that thing. It's going to be like ACME Bank or something and there'll be hundreds of listings and all the people have downloaded and actually done it, which shows you something about them. So, Ms. Mantra Sharma is the contact. Here's her email and phone address so I'm not going to click through, actually. But you put contact information in case you can't get all this magic pixie dust doesn't work and you actually have to call somebody. This is saying that Bank of America has a lending service. They use a local host. So, somebody's just been playing around. But if Port 18,000 is now something very interesting to put in your MAP scan when you look at the Bank of America. But if this was if they're actually exposing this, then this would be an URL to something that's internet-exposable. And then there'll be interface. There's different ways of defining how an interface works. Let's see what their interface model is. It's called, like I said, there's lots of epidemics. It's a t-lender model. So, at this place, if they're publicly doing it, you probably have something like an URL. I think Bank of America had a wisdom URL. I want to get the floor back. Ironically, not a Bank of Lithuania. Awesome. We'll have, like, an URL that goes to a Wisdl that points you directly to. Oh, something I forgot to mention about Wisdls that were in the slides. A Wisdl gives you everything you need to know to attach to service. So, that includes the location of it, right? So, a Wisdl text document, if it's just floating around, contains all the information like, this is what you can do. This is how you log in. This is how you transfer money. And this is exactly where the URL is. So, if you have a Wisdl, you have everything to actually do the attack, right? Because the location of the service, what platform it's running on, all that kind of stuff is contained in there. This is so slow. So, anyway, everybody can go play with this when they're on their fast connections. UDDI.Rx.com, or search for UBR, and you can play with other people's if you have a preferred vendor. Oh, yeah, I'll call you next time. So, at this point, well, I guess I'll show you how the discovery works if I was actually going to do something nice. If I wanted to use a web service for legitimate purposes, there is a nice little program called WS Web Services Studio. It's distributed off of .NET.com, which is like the Microsoft community site for .NET developers. I think it's actually made by Microsoft and not supported, so they throw it on the cheap site so they don't have people calling they have a hundred number about it. It's a great little graphical interface. Like I said, web services, unless somebody gives you the client, or if it's something like an AJAX app, you don't have a nice gooey way of talking to it, so it's a good thing for a developer, yes, sir. Right, and Eclipse has a web service platform. I use XML Spy, which is really expensive, but there's all kinds of really cool stuff, too. So, Web Services Studio. I think I've already gone to the bank. So, this is the studio. There's things like, like I said, you put a whistle in there. It can either be on the internet and you ask for it. It can be local, and then I'll figure out where it is from the local one. And I'm going to go back to the bank of Lithuania to the interest rates details. Ah, here we go. Here's the accent point. ASM.ASMX so what platform do you guys think that is? Windows, right? It's probably ASP.NET. Although Web Services is supposed to be universally worked with each other, there's lots of little details, and so it doesn't always work. In fact, one of our tools you know, there's some problems I'll demonstrate. There's some problems with the Python implementation. One of the problems is, you know, not a lot of people are doing Web Services person to person. They generally control the software on both sides, so they use the same platform so these bugs don't get caught, right? So, it's good that this is a Windows 1. So, we'll just they have Visual Generation on there. Looks like he was able to get it. It's... This network is so slow. Is Kaminsky talking now and doing his weird network stuff? No. Last night, okay. Was that good? Excuse me, sir. Really? He ended up in the hospital, Dan Kaminsky. Jesus. Okay, we're taking a collection in the memory of Dan Kaminsky. Unlike Dan Kaminsky, I actually don't put in applause, pauses in my presentation. Do you guys think I should do that? Let go. And that's a Wisdl! Thank you. Thank you. So, this was able to grab the Wisdl, and it's generated, like I said, it has all the information it needs to know on the service. These are different methods. This is just as if I was writing an application and I call a function to my function. Just think of it as that, although it goes across the internet. In the web app world, these could be either parameters in a post, like transfer money or do this, or it could be the urls themselves, like slash interest, slash get money. So, if I click on one of these, it tells me what was defined in the header and the body for each one of these. This has nothing, so that means it takes no input. This one takes one string in the body to get latest interest rate. And so, if I wanted to put a value in there, I could put it in there and say invoke. This thing, this is meant for legitimate users, so it won't let you do things other than what they define. But, like I said, people sometimes don't check very well, so it might be very possible if, you know, one way a good way to do an attack on this would be to run WebService Studio or Eclipse or XML Spy through WebScurrup, watch the traffic that's legitimate, and then edit it bit by bit by bit. Remember, it's UTF-8, so it's two bytes per character if it's internationalized. Interest rate, interest rates by day, interest rates by day type, yada yada. So, this one doesn't require anything to invoke it, so I'll invoke it, and I should get something back. Right now, it's going across the internet, they use the WisDol to generate a message that it thinks these people are going to understand, and it sends it to them as an HTTP post, and it waits for the response, it's a XML document, it automatically parses it for us. Like I said, this is not how you're supposed to use this, right? If I was another bank and I wanted to get the interest rate, I'd have some application that would do this automatically and then give it to a user, or if I was Bank of Lithuania, I would create a nice little pretty GUI to do this for people, right? So that's why this is all ugly. Like I said, this isn't meant for human consumption, but here it gives us all the data that came back, we can say request response, and we'll actually see the SOAP messages have the envelope, the body, the header, we talked about the header, the envelopes required, it has things like what version of SOAP am I using, what's the name space, stuff like that, and then the response, which is just an old HTTP response. I love this, they tell us the exact service pack version of ASP.NET. And then a UTF-16 encoded XML document that gives all the input that comes back, just like if I called in a program, if I called, give me an interest rate, and it had three things that returns. This will return everything, even if it doesn't have information in there, and we're good to go. So, here's the wisdom, it's really ugly, you can see why people don't read them, for something that simple, right? It's all that wisdom, you have to define everything like four times. As you see why that might be a place that people don't look. So, I will do an attack, and we'll use WebService to look for it. So to wrap up before we get to the demo, why do we have all these discovery methods? It's this thing called service-oriented discovery, more venture capital, it's amazing how much of the English language is based upon what can get you venture capital. Service-oriented architectures, the idea is that delayed binding of applications. If I'm Bank of America, and I know most of the banks in the world use some kind of standard thing to say clear checks, then I can, not even knowing who those other banks are, go to a registry, cryptographically check that that person is who they are, because it's signed by somebody I trust, find the WebService to do the transfer, find how to talk to that WebService and talk to it, and you can program their software to do all this, right? Lots of magic pixie dust, it's a little bit scary. But because this is so powerful, and because you can automate stuff to do things without humans ever involved, it's going to be very popular people. Other than the UBRs, there's some cool third-party registries, xmethods.net has a big list of fun services, people who are just having fun, things like census data by zip code and stuff like that. It's a good place to play around if you just want to learn about WebServices. And then there's this thing called disco-slash-ws-inspection. Disco is a lightweight doing a UDDI instead of running a whole server to tell you what my services are. I just have a text file you can read it in, an XML file. This was a Microsoft-specific thing that's becoming now WSInspection, which is going to be a real standard like I said, this disco file will automatically be deployed for you if you hit the compile button on Visual Studio. And so those are some of the new issues. The traditional attacks that we've always had still exist, right? Design flaws, the bad idea methods like we talked about, the same OAS Top 10 things, SQL injection, still exist, right? Although some of these things are using XML on the back end, a lot of them are still using SQL. And so just as we had in web apps, SQL injection will work. I'm not going to talk about it. SQL injection, you can go find Dave Litchfield for that. The thing I will tell you is that the best way to do it is to, you have to escape those characters generally. You can use something like a CData block, put the entire SQL string in it that will magically get transferred by the XML document to whatever the string is, and then put into the query. Overflows and unmanaged code, right? Managed code is the Microsoft term for things like Java and .NET that run something like I compile C++ for an x86 or a spark, right? Well, there's a lot of people have a lot of stuff written in C and C++ out there that they still use. It still does the core of their stuff that they want to expose. And so all the vendors have cool ways of taking something that's compiled on my machine and making it web service accessible. One great one is called .NET Remoting. And again, I'm not beating up on Microsoft because they're bad. It's just theirs is the coolest and the easiest to use, right? If you have a calm object that works and you know, it can be something I think it has to support IonNone, and it's like the same standards as to be remoteable like that active X control. If you have a calm object you can just click through. You don't have to write any code. Visual Studio and say, I like this calm object. I want these methods to be exposed to the world. Boop! Magic PC Dust. And all of a sudden, now there's a web service with all of these, it takes all these inputs and gives it to a C++ program. Do you think that it goes and finds out what the limit on that stirring copy is? Or with the static buffer that goes to that stir copy is and that C++? Do you think it does that? No, it doesn't. It just gives it the information. It just says a calm object can be called locally. And so it makes it really easy for people to take something that's local and remote it. So .NET Remoting it's fun. See it in theaters near you in 2007, right? When people start really deploying it. It's a cheap way to do web services if you already have stuff written on the Windows platform. Java you can do the same thing with RMI and local calls and stuff. It's not as easy though. It's not just click-click-click. Mistakes and authorization authentication. Because SOAP is stateless, people have to roll their own, right? It's very possible that there are methods out there that you find from the WISDL that don't require you, that don't properly check your access control before they do something. They take a parameter like I want to transfer money from this bank account to this bank account. They don't check whose bank accounts those are. Like I said before the auto-discovery mechanisms make this great because you no longer have to go look for this stuff that's kind of crusty in the web application. You just ask the WISDL and they're sometimes named really stupid things like making me happy, right? Cross-site scripting. Now like I said, this is not something SOAP isn't something that you can eat with your web browser, right? So if I get cross-site scripting coming back in XML it's not going to run as script. But, and this is the big but, there's a lot of situations in which there's a web interface also to these applications. And so cross-site scripting is also still doable. It's just you're not attacking the web service itself. The exception to this being AJAX, right? The downside is it's not easy. I mean, I guess it's an upside because we're all good people in this room. The downside for the bad guys is it's not easy because I have to write something that, you know, in AJAX like in Google Maps it takes some XML data and then it makes it presentable. So I have to figure out probably exactly how that's happening to write cross-site scripting script that will actually run when it's transferred. That being said, unless they're doing filtering on their side before the information gets to me, it might be possible for me to do input through an AJAX interface one place and pop it out somewhere else. Another thing we've seen is a lot of these web services, there's a human in the loop somewhere, right? If I, if I go transfer money at a bank and I have to put a memo field in there about what my transfer is about, I put that field in, I make sure the transfer is going to die, I call up the customer service rep. Hello, how can we help you? We're, you know, dumbassbank.com. What can we do for you? Well, you know, my web, my transfer is not working out. Can you pull my file out and up and see what it is? Oh, sure, give us your social. They pull it up, it's a web interface, boom. They're on. Obviously, that's a, it's a pretty sophisticated attack. It requires some possible inside knowledge, but maybe not. And if this is, you know, if you have an IE0 day, or the way people patch IE in IE, you know, 90 day or something, um, and most enterprises, right, people are still writing IE5 and stuff, then you might get root control of their box. So any questions on those attacks before we kind of move into the wrap up and then the demo? I'm sorry that I know it's a lot of talking in a row. Yes, sir. Right. Did everybody hear that? That Apache Access allows you to take a few written Java and just drop it in. Yes, Axis is great too. Apache Access, if you guys want to play with web services and you don't like Microsoft, Apache, the Apache project has their own web service framework for Java. It's very nice, we'll claim with that too. I know, I'm saying, I'm beating up on Microsoft here because of the demos written in Microsoft, but this is stuff that everybody does. So thank you, sir. That's a good point. So we have a couple of tech tools that I'll show you. One's really cool, the one that Scott wrote, the one I wrote is kind of crappy, but I'll pretend that I wrote the one that Scott wrote. The cool one is Wisbane, that's how you pronounce it. It is a soap fuzzer. It doesn't fuzz the soap implementation, it fuzzes the application behind it. It takes a whizzle, right? And, you know, you can go and buy, like, SBI Dynamics and Sanctum and all these, but perhaps the really hard part that those guys have to tackle and write in those is actually the discovery of the attack surface, right? For us, the discovery of the attack surface is easy because we ask it, and unless they're really smart and they're manually editing the whizzles, the whizzle will most likely represent the actual attack surface. If it's not automatically generating to the whizzle, it's probably not callable remotely. And so it takes a whizzle, creates a nice little proxy, looks up what the types are, like this is a strain, this is an integer, this is nasty things, depending on that type. It's all extensible. It supports soap responses and faults. Gives you a nice little interface, I'll demo it, and, well, not a nice little interface. It gives you output in a web page. And the future work we're looking at right now, it only works with the RPC style soap for all the really hardcore soap people in here. It doesn't do doc-lit because of a bug in Python's implementation of soapy, but we're working on it. We're going to resubmit a patch to them and get it fixed. So, once we get the libraries fixed, it's almost all web services. Oh, here's Jesse Burns, my partner, who has also helped Scott in writing this and who is always tragically late, but not on consulting projects. He's never late on consulting projects for all those people with... Wait, I'll do a Dan Kaminsky. Jesse. Ta-da! Thank you. Thank you very much. And then the other tool that Jesse helped with, and that's pretty cool. It takes a web scarab a lot as input. We use web scarab a lot now. It's a really good product. Web attack proxy is probably the most you know. Open source, Alas, does it. There's a guy named Rogan in South America. I don't know where he is. South Africa, I'm sorry, not South America. That's it, he's EA, right? Who works on it and Jesse submitted patches and stuff. Jesse likes to run it in Eclipse and debug mode like in real time. Pretty hardcore about that. But anyway, it's really cool and we use it a lot and WisMap is not really for finding web service that are out there. WisMap is useful for situations in which I have something that already talks over a web service. So maybe I... Let me think of something. So back in the B2B, when I was talking about places where web services are being used, there's a point on the slide about OFX, which is the standard. Anybody here use Quicken or Money? Okay, you're not going to raise your hands, but... There are people in here use Quicken or Money to manage your money. There's nothing wrong with that. I'm just saying that OFX is the standard by which it transfers, it talks to banks when you say update my accounts and it gets your American Express information. That's called OFX. The next version of OFX is based on SOAP, right? So say I have a client like that. I have something that's been shipped to me and uses a web service on the back end and I want to reverse engineer it. So I'll put WebScarab. I'll set my HCD proxy, put WebScarab on it and watch that traffic because it goes up from Quicken up to Chase and MB&A and American Express and stuff, right? Those don't go through Quicken. Into it just tells Quicken where to find those people and then they go find it, right? And that's all over SOAP. And so say I want to actually, you know, research that communication channel. Then I'll record it in WebScarab logs and I'll run WisMap. And WisMap will go through and find all of the things I called as well as the implied directories and try a bunch of web service discovery requests looking for whistles and disco piles and stuff and then write them out to the disk. So I don't have to manually go through and find the things that are actually web services or not and they'll find all the implied web services and maybe they don't want their disco piles out there they just don't know that when they hit compile it automatically goes out there, stuff like that. Future work, something we had to pull up the last minute because it wasn't working. We're trying to get to find UDDI servers when you get a CIPR range or maybe even an MAPXML file, right? Because they are web servers. You have to do kind of a Nikto kind of thing where you get a UDDI, where you look at a web server and you ask it for different URLs that mean that it's a UDDI server. That's going to be very powerful because like I said, there are enterprises out there that are exposed, just don't tell people about it but register them in UBRs, just tell their partners about it. And then hopefully one day we'll integrate it with Wisbane so you can run it against, you know, the people that you have a legal ability to pen test against and then you can restrict it based on a REGX to only be within their domain and it will go find the web services and then automatically attack them, you run it overnight and then, you know, your two week engagement is done in an hour and a half, so. Okay, tying it all together, I think we kind of talked about this. Go to the UBR. I can't test UDDI server. Ask for the services. I go ask, you know, dumbbank.com. Give me all your web services. I ask that service, give me your wisdom. Use me the wisdom. I look at the dangerous methods. I run Wisbane to try all of those. I find an XML injection. I use XML injection to change the user ID and I become whoever I want. So a question here is, do are the old bugs still relevant? A lot of people here would argue that OAS Top 10 was never relevant and OAS Top 10 is actually saying the OAS Top 4 in 10 different ways. But it turns out that it is, right? These are still bugs that exist in our world. You still have to validate input. Access control is still a problem. Authentication session management is a problem. Like I said, it doesn't give that to you. You have to think about it yourself. Cross-h scripting, less of a problem but a problem if there's ever a web interface and certainly a problem in AJAX applications. Injection flaws, buffer overflows. Buffer overflows, you know, things like .NET Remoting, make that kind of stuff a reality and not rewrite that stuff. Injection flaws, SQL injection, XPath injection. This is worse now because we've added all these new protocols that are spoke on the back end so we have new things to try. Fortunately, almost all those things use a single quote so it makes fuzzing really easy for them. Insecure storage, denial of service, insecure configuration management. I think we've proved that denial of service is still a pretty big issue. So the conclusion before we get to the demo. Web services are very powerful. They're easy to use. They're fun to use. It's fun to go out and get a book and write 20 lines of code and have it do something like get me census data and then plot it onto a map. That's really, really cool. But because of all that, they're really, really dangerous, right? Especially because of the ease of use on the developer side. There's a lot of security work that needs to be acquired. You know, the people are writing these web with security standards but I don't think that a lot of security people are looking at them and so those things need to be inspected. We need better attack tools from everybody to help develop. We GPL'd our web service stuff so we're looking for people to help us with that stuff. I guess we'll start a source project or something so you can do that. We need people to find the best practice for development. Nobody knows how to write secure web services. That's one of the problems here. You can go and buy 20 books now on writing a secure web app but you can't buy one on writing a secure web service. You buy all the books that say securing web services. It's all about the encryption and stuff like that. That's not a bad thing. That's something people care about but it has nothing to do with injection attacks and stuff like that. And then we need for people to settle up and stop getting greedy and build this PKI infrastructure before people start deploying and moving my credit reports over these systems. And then on our shameless plug slide we are hiring if you are a researcher or a consultant you can send your resume to who resides in front of you. And a shout out to all these people. I mean sorry I'm a professional it's not a shout out it's a thank you. My brothers wanted me to show how many people here know that you write jangles. Okay that's a pretty good number. Okay any questions before we get into the demonstration? Yes sir that's an excellent point and I'm sorry I glossed over that it was in the slide but I didn't say it. Yes the right thing to do is if you if your web service you're putting out on the internet and you don't want anybody in the world to talk to it you just want like a partner just to email them the whistle. Yes turn off the auto mechanisms to publish the whistles and just email them. That's the best protection against that kind of stuff makes it much harder if you don't have the whistle that aren't built in and stuff and so just to ask for all the methods that's the method that's supported. And people do that if you guys if you go drop Google Maps into web scarab and find out what web service they're talking to and ask it for a whistle it's not going to give you one. So there's certainly people that understand that. That's also something because if you don't want people using your service if you're the way you get people to use your service just scraping it like eBay and stuff so that you know they make money off of your work then that's something you can do too. Google API is probably one of the coolest web services out there. See Johnny Long's talk. Any other questions before we move on to me messing up the demonstration do you people laugh at me? Okay I'm really sorry that there's so much talking in a row we got to get better at putting lots of demos in there I'm sorry. So here we have a I don't know if I can do this an 800 by 600 a virtual PC of Windows 2003 it's got a web service on it the exact same web service is currently running on wsdemo.isacpartners.com if you're online right now and you want to play with it or if you go home and you want to try some of these tools you're welcome to do a tax I'm letting you do a tax against wsdemo.isacpartners.com so it's going to be the only site that's going to say that So like we talked about before there's this cool thing called WS Studio I'm going to point it at the web service it's very very simple oh, I don't want to go into there it's got one user or one method logon user right so this is simulating maybe word bank and the first thing you do is log in before you get your account balance and stuff and it takes a string username and a string of password so say I've been hired to pen test this what am I going to do first and let's pretend this is like one of those more complicated ones there's hundreds and hundreds here I want to see if there are any vulnerabilities and so I'm going to do that using whizbang to do the initial thing so whizbang.py it should just tell me yeah so we're big on documentation of GUIs because we're privately funded and we have no venture capital if you want GUIs for the family stone they excel at that kind of stuff um so whizbang you give an url this isn't descriptive enough you have to give it an url that gives it a whizzle it can also point to a local file so I am going to give it the url of the whizzle I grabbed whizzle thanks this is why our partner, Hamanchu who spoke at blackhead he video records all his demos which is I'm starting to really appreciate how smart they are that's not a real demo if it's videotaped alright okay because I spend an hour and a half convincing you I'm smart and then I can't type so excuse me sir oh yes thank you is that a little more readable okay great so running it with an url that should give me a whizzle okay I run it it pulls down the whizzle and it's another packet real fast it runs a bunch of tests it does this by looking up an XML file it has just a second the type you know in a soap you define types you can do simple types which are things like string and number you define complex types which means you define it can actually be an XML document itself and stuff like that if you want to do cool extensible stuff or binaries we don't support those yet just simple types that covers probably 90% of web services so it looks up what the type is like a string and it looks up in the XML file of the things we want to try and it tries those things these are all the things I could try on that one method and then it reads the response and this response coming back in the soap message is made pretty and here we have something that says soap form so I click here and it gives me what I actually ran so outbound here's my HTTP headers I set the soap action header kind of glossed over this but there may be we have seen vulnerabilities and being able to set the soap action header it's different than actually what the the method is in the soap message so they check for it and then within the body we say logon user the namespace is this namespace this is the encoding mediata and then users are sweet they're not indented but they're children to this the username and the password strings and what was our username here? anybody see it? it's a single quote the password was default and so the response was to find this XML document oh I threw an exception okay this is a fault because it's a soap fault it gives me the nice little system trace of all the things I've got called now this is like 50 lines of C sharp that's running on the other side look at all the methods that get called in a row to parse that look at this that's all that's every one of those is a is a function that we went through to call this there's a lot of pixie dust there right? and then it gives me actually we'll do this the pretty way which is if I got this I would do it myself then in this so I'll try it say my password my username to quote single quote exception this isn't a local exception it just passes through a soap fault as an exception on your side and I go to request response yeah that's not what it's supposed to say yeah thank you right I need to have something in the password so it doesn't ah thank you so I get a soap fault back server's name able to process a quest and what does that look like to you XPAC so what was it sir what I'm going to try next the winner of frack that's correct let's give a round of applause for that tada thank you sir single quote or one equals one or single quote single quote that's not a double quote equals single quote spaces are a significant answer oh I assume the pauses in his human communication between words were meant to represent the symbol also known as a space when encoded in utfa so we'll let him keep the frack and string results successfully logged in on user id user id 3 henry ackerman so that was the next pattern check why was it why was it this user what's special about this user do you think who's the last guy right so when they referenced the list they probably asked for the last thing in the list right which you do with a negative one in python so they asked for index never negative one and you can either ask for the first thing or the last thing generally I should get the same thing right and they asked for the last thing in the list maybe they went to this talk and they thought it was enough they weren't paying attention to this part just the last hour and a half and they thought it was enough just to ask it's not asked for the first one because that first person might be a user so I'm logged in and this is good but nobody wants to stop here right this is where you stop if you're like a real second tier hacker oh yes I'm throwing it out there that's right I said it so what do I want to do right I can do user ID equals one but although I do know how the XML file is laid out that's kind of cheating what's another way to do it so let's go back to our string let's say it is pretty close it's not exactly the string right we did see what the string was but just because we know what the injection string was doesn't mean we know exactly what's in the XML document right unless it references it right in that path in that path the x-pass string and so this bottom one what else could I do other than ask for user ID equals one it's actually simpler than that name equals admin yes right I can just do name equals or quote quote quote quote and get rid of the or one equals one because I want them to match the first one right so I don't make it a full tautology anymore I make it a tautology only if the name is equal to who I want it to be does everybody understand that so I am going to let's say I tried admin it didn't work and I know these people wish they were programming on Unix right so they used the word root and I've now successfully logged in as user ID zero name root tada sorry if it works for Dan Kaminski he comes back every year to blackout in deathcon so if it works for him it's gonna work for me right so does everybody understand what we did here this was an X path injection X path one this could work with either an XML flat file in the back end or a quote unquote XML database this exact same query string would work in an X query right because like I showed before X query I mean the simplest way to do it is all you have to do is to find the document you're looking at which is the same as a table right no questions on that yes sir of course yeah how would I use that to map out the tatables in the database or the XML file it's we're not there yet you're right we Emit Klein worked on that and his the way he found to get it out was only through logging or logging off he was not able to get error messages out that contained enough information right like the traditional way of sequel is that there's a sequel statements that you can do you're gonna go Carl Rove style on them um I'm sorry to do I'm it's probably doable we don't have that answer yet and that's something that we'll be working on Emit Klein says I mean does it have that binary I think now with X-Path 2 there might be better ways of doing it you might be able because you can reference external links it might be possible for me to reference something and then make the rest of the XML document look like it's part of the Earl right so like people do cross-excript with an image tag to get a cookie out when it hits my log I might be able to get it out of a log I'm not sure Klein looked into doing it with error messages and he wasn't able to do it I still I mean the guys disappear off the face of the planet or the 19 commands you can probably do in a row that through the error messages you can map out the not the tables but the nodes okay well since we got a second I'm just going to do a quick demo of WizMap which I learned set it up without you guys seeing it okay so this is WizMap I'm just compiling it it's going to be hard to see so if you run it with dash H it says you can do as for WizDolls as for Discos store them locally verbose I'm going to ask it to everything I'm running in a directory with a web scarab conversation log although if you have it in a sub directory that's fine too it'll search all the directories for web scarab logs anybody who here use a web scarab decent number I recommend you guys use it anyway as you can see there's no dash U anymore we had to pull that out which is one of the great tragedies in my life sorry and our in WizMap got PY dash WizDolls dash Discos write out the files and do it verbosally and I just generate these these logs by kind of cheating and going to things that I thought would have different types of web services although I didn't know all of them but I knew these are different web services that are going to like I said this is not useful for blind this is useful for wearing something that uses web services and if the the network actually worked here at DEF CON you would see that it would find multiple WizDolls and Discos here and then write them to the local disc in the which are already written 1 dot disco 1 dot WizDoll 2 dot disco okay okay so in one test well that's going show you one of those so this is one of the things that when I ran it in my hotel room it pulled down this is the WizDoll for a census data so do you think the programmer read that whole thing before it got published to the internet looking for all the methods that he felt would be too dangerous to publish to everybody probably not I'm not I'm not going to you that's for you to explore yourself sir so you can see it's doing some test it's looking for it's asking for question mark WizDolls it's asking for question mark disco it's also looking for default disco URLs and it's about to find one and like I said disco is like UDEI it doesn't define a web service it defines the services you're publishing through a web server instead of running your UDEI server okay so open questions or comments is this useless do you guys think you'll never run into this any more questions for everybody okay well thank you very much we'll do spot the fed