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 12.50-ish. We'll probably run a little bit early.
But I'll be available for Q&A afterwards, and 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 you do, like, 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
so he doesn't get divorced because of DEF CON.
So we'll talk about what we do, what web services are, where they're 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, you know, 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.
And if somebody actually gets it running, you can play along while we do the demo.
And like I said, please interrupt at any time if you guys need something.
So who are we, or I? I'm a founding partner of iSEC 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.
Why? What are we going to talk about?
Well, we're talking about web services. And why is that important?
Well, they're deployed all around us.
It's kind of this stealth 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... the CD is way old.
isecpartners.com slash defcon.html.
If you go to isecpartners.com, you can click all the way through speaking engagements.
And then there's a demo web service at wsdemo.isecpartners.com
slash expathservice slash expathservice.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're a 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.
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 BitTorrent.
And therefore, it's not something that gets researched very much.
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 experienced in 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 that does, like, encryption,
allows you to do authentication and authorization, 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 not to talk 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,
it 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 words web services and Indian programmers, like, in your prospectus.
For our purposes, web services, our 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 underlies 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 a 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. Right.
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 world 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 gone rid of the not-invented-here syndrome,
so Microsoft and IBM are willing to implement it without either one of them taking credit for the other guy's invention.
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 of 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 Caesars,
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, right?
It's all these magic pixie dust protocols that make things happen magically and automatically
and without human intervention that create insecurities, right?
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, right?
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 who has MSDN installed, open up Visual Studio right now.
If you create a new project, you point it at something that has a web server, IS6 installed, and it's got ASP.NET activated,
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 ASP page that corresponds with that C-sharp file,
create a configuration file, create a web discovery document called a disco file,
create a WSDL, which is that web service document link 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 a program which gives it a string, and then it goes all the way back down,
with ten lines of programming, and there's then millions of lines of code running around it.
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 them all over the place is the value is really well understood by the pointy-haired bosses.
This is just a little fake quote, but this is something that we actually see.
I see a couple gray hairs and ponytails 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 some IBM Global Services guys,
and they come over and they put some WebSphere right in front of it, and they create this 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 Learn 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-haired ponytail guys.
And that is very, very compelling to corporate management, right?
Because they want to extend stuff and they don't want to spend money.
Okay, so I have been told. I mean, this was all pre-arranged, obviously.
This is issue number 13, numbered. Independent. I'm sorry.
It's the last issue of Frack, numbered 13. They're individually numbered.
It's still warm from the printing press, and it's incredible leet-ness.
Come on.
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.
But pay attention, because it'll have to do something with the slides, 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 what 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've ever done a file transfer,
you probably understand, like, ports 137, 139, Samba, and stuff.
It's a technology you run into.
But a lot of people in here 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 bust.
But now, it means business-to-business again.
And people are doing this using web services, right?
We 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. It uses HTTP. Everybody knows how that works.
It's based upon a web browser.
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.
Well, 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 SOAP.
And you can write it all in Java, and you don't have to buy a specific product for the credit card industry.
You can just buy WebSphere or ASP.net and write it on top of that.
Internal to companies, a lot of people like to hook their stuff up, right?
I want my payroll system to work with my inventory system.
Web services to connect those, 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 using 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 you might mean X star, there's different kinds of protocols here, injections into those protocols very interesting.
And the way that most 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 without reloading the page constantly.
Microsoft came out with Internet Explorer, has the ability to talk to what's called the XMLHTTP object.
And now Mozilla now simulates that and stuff, even though it's obviously not ActiveX.
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.
And it's able to move XML files back and forth over HTTP.
And it can do that without reloading, it can do it asynchronously.
So it can do it multiple times.
You scroll around in Google Maps, and it can spawn a bunch of these XMLHTTP 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 enterprise as a replacement for thick clients.
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 the same kind of user experience.
Which, you know, the user experience kind of sucked in web applications because of reloading the backbone 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 enterprises on the internet.
Then they herded this thing called a firewall.
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 SMPP, HCP, HPS.
Every once in a while, a Firewall 1 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.
And that's actually an advertisement for some of these products.
Get around your firewall engineers.
Buy our web service product.
So, our new slogan is we poke holes in your firewall so you don't have to.
Just set up your firewalls once.
Fire your network engineers.
Add all your functionality to a SOAP interface.
And you're done.
So, now we're going to talk about some of these technologies.
Give you a little background in the attacks.
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.
Which sounds like a really easy problem for them to tackle.
Especially if it's supposed to be English readable on top of it.
And it's very hard work.
You've got things like binary data, internationalization.
XML has internationalization built in from the beginning.
Unicode 1.0 is the standard for XML.
With XML 1.1, it would be Unicode 2.0.
This makes internationalization attacks really interesting.
Because we've seen these attacks before.
Things like non-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 the SQL server.
Like you used to have to get.
So, that's a really big deal for internationalization attacks.
Which have been 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 HTTP.
Okay, I can understand how those work.
I mean, I can't recite the RFCs.
But it's almost impossible to do that with web services.
There's a couple of 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 already parked 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 XML attack, right?
It'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 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.
So you can, like...
If I had manufacturers shouldn't overlap with somebody else's namespace in an XML document,
I also define a schema by which this can be...
These pearls aren't real.
Don't try to go 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 base.
There's 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 a type B.
And then B defines type C, which defines type D, which defines 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 most of these 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 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 and it has to be between these dates.
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
before it ever 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.
So how do you... I get an XML document, how do I read it?
There's kind of two standard ways. Both ways have security flaws.
The first one is called SAX. 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, go one more step.
Oh, you have children node? Okay, I want that child, I want that child.
So when people use it, it's nice and it's lightweight, it's pretty easy to use.
But it's not very powerful.
And it has the downside of if you use a SAX parser, you have to track what data you've gotten.
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 named manufacturer.
It gives me manufacturer, and then I have to store it in a variable for myself.
And there's an attack against that called XML injection that we'll talk about.
And then the other one is DOM, Document Object Model.
This is really powerful parsing, this is how 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, what this means is it takes and it builds a data structure in memory that represents it.
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 against X, XML injection.
So this is a 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, it puts it 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.
But anyway, 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?
Well, this is in a situation where perhaps I have some knowledge of how the XML document is 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,
and remember, 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 user 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 I get to unique ID again.
And because the parser itself isn't tracking the state, I'm just going through and have a switch statement that says,
when I get this information, put it into a variable.
I overwrite that information and 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 1 equals 1, it gets the first user in the table,
and it always turns out to be either 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 a unique ID of zero.
How do you defend against this?
You can do an XML schema where you say you can only have one unique ID per user record.
Or you can use a DOM parser, which you would specifically reference one of these, and it would probably check this one.
No, oh, 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 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, because it takes my data and 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 can 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 inputs.
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 an XML document.
It's kind of a cross between direct relations and regex.
XPath number one was supposed to be nice and simple.
XPath one 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, some of this stuff in two.
But these attacks work on XPath one.
So say this was 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, right, in this document.
It's a big list of used cars.
I want to return all of the children of the node.
XPath queries always return a list.
It might be, it's like MATLAB or something.
It might be a list of one item, but it always returns 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 does 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 car.
And then the interesting one is when you can have conditionals.
Give me 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 a 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 uses, puts data and the commands you want to do,
puts the verb and 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 an 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 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,
where they call and distort procedures, and that's a nice secure way of doing it,
and SQL injection doesn't work in that case.
There's nothing like that for XPath.
There's no secure way to call it.
The way people always call it is you concatenate 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, in this example, say it's this bank again, and I've created an XML document.
You know, 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 fix that, right?
Oh, I'm so stupid, I should have known that people could have 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.
Everybody 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 whose password is equal to let me in.
And the two red things here are information that come from the web form, the login and the password field.
Okay, that's fine. It works.
This will return a list of all the users, right, because slash slash will be a list of all the users that match that.
It's 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 we'll 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?
Right, dash dash.
It may be semicolon, dash dash, depending on that, right?
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, like, 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'll be in there.
So what this does, is now I have, give me all the users whose name equals Joe, and my first single quote closes out the Joe string.
Or, one equals one, which is a sylla... what's the word for something that's always true?
Apology. It's apology.
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 used for SQL injection to throw away the rest of the line,
or a semicolon to make mine a 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 the red stuff I control, that last black one is put in there by the application,
but I neutralize it by doing this.
End 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, sorry?
Operator precedence.
Somebody took a first year CS class and hated it. Right, sir?
Yes, operator precedence.
The thing that bites you in your ass when you start CS.
When you look at this, it first does the and.
There's an implied parentheses around this.
So the and is the first thing.
Quote quote and pass equals let me in, 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 returns all of the users, because it's a tautology.
It returns a list of all the users. Well, what use is that?
Well, 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, like, 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 becomes my login user.
That make sense to everybody? Right?
A lot of people yelled at me at Black Hat, because they're like,
how could it work, because it returns multiple things?
Well, you know, 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,
and you know how the XML is laid out.
So this is an open source or 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, give them all the information they need to make an XPath query,
and we'll show you on the default ASP.NET.
Even if you can't get access to it, Amit Klein, who used to be at Syncdome, 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 he wrote an excellent 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 there's 40 characters after, and it took them two hours to get those 40 characters out,
because you have to do all the logins and test all possible characters, but it's 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, right?
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, right?
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, right?
And that way I'd probably be able to leak a bunch of information out 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 you can reference a bunch of different documents and stuff.
Downside is now people are actually building an access controller, and so boo-hoo, we won't be able to read everything,
but that hasn't stopped us from SQL injection, right?
And in this attack, and in a bunch of other attacks that we're talking about, our big friend is the cdata field.
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 into XML, right?
Things in XML that you don't want it to interpret as part of the XML document, you put it in the cdata field, and it disappears.
So I can put things like with single quotes and with brackets and all that kind of stuff into a cdata field,
and that goes into the XML parser, and then when you ask the XML parser for the string, it gets rid of that cdata field for you.
So the application never sees that you did that.
There's also other escaping methods that work just as well, but the cdata field is so powerful and easy.
It's the best way to do it.
Once again, XML schema is for defense.
You turn off cdata fields in XML.
So any questions on the XPath injection?
And soon to be expert.
Okay, I'm going to demo that at the end, because it's a cool one.
So SOAP. 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 WSDLs.
WSDLs 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 WSDL 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, right?
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, right?
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 WSDL is as easy as adding a question mark WSDL 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 question mark WSDL over and over again.
They define all this stuff. This is just for reference. You guys don't need to know.
Basically, it 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 WSDL 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 WSDL.
The WSDLs 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 WSDL 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, and I'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 this functionality over to web services,
and one of the methods in the WSDL that obviously they had never read was make me admin.
It was a debug call that the developers would have, just normal low rights users,
could make that call, and they'd 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 WSDL, and it said it right there.
Make me admin. It takes 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 a 1AM batch FTP job that they're embarrassed about?
Come on. Yeah, right. It's unbelievable what's transferred over FTP in the middle of the night.
If I was a router engineer, I'd be all over it.
All this kind of stuff's 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.
Now all you have to 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 WSDLs.
Everybody should know what's in their WSDLs if they're broadcasting 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 reasons.
But the better part is don't have things like make me admin in your production app.
Get rid of that before it gets out to production.
So there's a number of different attacks with SOAP.
One big one we'll talk about a lot, well, not a lot, but we've got a couple of slides on,
is application-level denial of service through XML complexity.
And SOAP obviously takes XML, but you're probably wondering,
obviously I probably can't give SOAP 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, there's 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 in a 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 thing on the inside.
SOAP has a lot of session management problems.
It doesn't have session management.
It's just like HTTP.
You do a post, 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 on 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,
like whose bank account can you transfer money out of, right?
So, you know, 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 WebSphere's or ASP's little cookie.
So they're kind of old at it,
and they don't remember that doing things like counting up from 1,000
and then making the next user number 1,001 in that field
is definitely a little bit guessable, right?
As are things like counting up from 1,000 and doing a SHA-1 or something like that.
So we see that all the time again with web services
because people have to rule 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 GUI on it to put information in.
And then you'll see in the demo, there's this thing 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?
Right, 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 Service Pack 1.
If XPath breaks, tell the user.
Tell the user exactly the XPath string that broke and how it broke.
So we'll demo all that in just a second.
And then something I talked about was Web Services Download 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 SYNFLUD.
Why? Because I have a huge, huge multiplier.
I don't have a huge multiplier with a SYNFLUD now that somebody's got $100,000 arbor boxes
or really nice net screens or something on the other side.
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 parser itself or against the application and its database backend.
And against the parser itself, you get very large multipliers of CPU time and memory.
If I can send you an XML document, how hard is that for me to send you a text document?
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 Perl script.
So I send it once. OK, 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,
OK, 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 head node, 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 100,000 times.
And then close B off 100,000 times.
And that guy builds an object in memory in some heavy-duty language like Java or C Sharp,
where memory management isn't that easy anyway.
It uses a lot of memory.
And it builds this huge object that's 100,000 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.
Gives you a huge advantage.
How big of an advantage?
Well, we've taken down four enterprise-level hardware with a real, patched, good web services server
with one of these laptops.
CPU pegged them.
And I don't think the CPU was actually from the parsing as well as the memory management.
Because 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 20 threads of Perl.
So that is really, really powerful.
And that's, you know, it would take a lot more than one laptop to SYN 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,
they're something like 200 or 500, right?
Because they're only used when the query's going across.
So, like we said, this WSDL 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 WSDL.
I find something that looks like it's a very heavy-duty thing that it has to look up in the database.
Somebody name 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, 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 cached,
you have to go ask the database, who's this user?
And so to create these user requests with random usernames and passwords over and over again is not very heavy-duty,
but it requires, it takes up one of these connections 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 or two in HA, or maybe two HA clusters, right?
And that HA is probably cold failover, so they're not actually running.
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, while 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 usernames, and my Perl script has destroyed 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 SYN flood,
and obviously the attacker's position is given 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 HTTP 1.1 pipelining.
This is especially important with SSL, because I don't want to do an RSA transaction for every post I do.
If 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 RegEx attacks?
That you can do to null service by getting somebody to do a weird RegEx?
That's really, really hard.
Well, XPath, obviously if I can do arbitrary things in XPath, I can probably do things in 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 this.
For things like the SOAP header XML complexity, there's nothing you can do as an application developer in your application.
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 WebSphere, 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, you 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 20MB XML file to you, right?
Or you can do something like write your own Apache filter, or work with something like Apache Mod Rewrite or Mod Proxy
to look for this kind of stuff.
SACS is not vulnerable, right? Yes, sir.
Limiting RAID 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 megaproxies, 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, and size. Yes, I do recommend limiting size.
If you never have anything larger than 50K, set it 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,
it takes me 30 seconds or something to upload a 20 meg post over a 100 megabit connection,
and then it takes a minute for it to parse it, right?
XML firewalls are these... well, okay.
So it's another venture capital term.
So it's something that makes people venture capital. That's the 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.
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 Syncton's AppShield in front of web apps,
XML firewalls or SILK firewalls or web service firewalls or 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 XPath injection and things like that.
I can't always recommend them.
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 stack,
somebody can DOS it anyway and take you down network-wise, right?
Or it's something you have to pay to maintain.
They're not things that you can just drop in front of your app and expect them to work.
Anybody in here sell XML firewalls?
Obviously we're not a vendor.
Excuse me?
I think Teros might do this kind of stuff.
Forum Systems, Sarvega.
Somebody come up with a prefix and postfix for a startup company.
There's like 20 or 30 companies that do it.
Like I said, they're mostly to do stuff like I want to do encryption on my web service
and I don't want to write into my app, so the box will do it automatically.
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.
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.
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 that.
So discovery methods. We talked about WSDLs.
I don't think we'll do it. Let's talk about this real fast.
UDDI is another great discovery method, like a WSDL, what I talked about.
It just defines 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 XSDs.
By default. Certainly you can tell your XML parser that you want to.
But, you know, I haven't seen anybody do that.
Sure. Any other questions? I'm sorry on the DOS stuff.
Okay.
So UDDI is a way I can list all these web services.
And 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, which is XML on top of HTTP. It's nothing very complex.
There's a bunch of free Google for UDDI browser,
and you can download free ones or use web applications that will do it free for you.
And then they put these IP addresses out, and they tell 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 SSL is on, right?
So use SSL. That's what we'll use instead of a VPN.
And they expect people won't find these UDDI servers, right?
Because if you do nmap-a, I think right now, it won't say this is a UDDI server, right?
Because it's just a port 80, so you have to report 443.
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, 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 a UBR. I search and I want to talk to SAP.
I search for SAP. I see all the web services that they're listing.
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 WSDL,
and the invoicing service tells me, OK, 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 Chinese character set, right?
Now, people are working on these big PKIs by which you can authenticate web services,
but people are fighting over the standards.
Obviously, it's a lot of money.
Just as it's 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 with how short my passport is.
Are any of the passport guys in here?
Passport's great, by the way.
Are any of the passport guys here?
There are actually some really smart guys.
Okay, well, I'm going to talk about something while this is loading.
What? Sorry?
Oh, wait, a book. Excellent.
Yeah, because this is going real slow.
Somebody's tossing Microsoft in the dustbin, probably, so...
Okay, compensation.
Okay, the first person who can raise their hand and give me the new canonical XPath gets the prize.
Yes, sir.
Er, next?
The next, the injection attack itself. The string. Yes, sir.
It's not a semicolon.
Okay, I'm going to close my eyes.
Oh, no, I'm not closing my eyes.
I'm going to say yes.
I'm going to say now and then everybody raise their hand and whoever's fastest.
Jesus, there's no way to do this.
Now.
I think this gentleman was up there.
Bam! 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.
Mike, show them the shirt.
Okay, that was perfect timing, Mike.
Good work, because now I am logged into the UBR server.
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.
They all sync up with each other.
Right, 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.
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?
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 you can categorize these web services that are all competing.
Like the government has some.
And then the visual studio has its own.
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.
Okay, they say there's none.
Okay.
That doesn't mean that they've actually categorized everything.
Let's see.
Did anybody see where I searched my name on this?
Maybe it's enterprise.
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.
And 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 our web... WSMAP, one of the tools that we're releasing.
One of the functionalities we had to pull at the last minute.
It's funny, if you buy like a learned 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 of all the people who have downloaded it and actually done it.
Which tells you something about this.
So, Ms. Matma Sharma is the contact.
Here's her email and phone address that 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.
Oh, it's a...
Oh, they use a local host. So, somebody's just been playing around.
So, but if Port 18000 is now something very interesting to put in your NMAP scan.
Right, when you look at the Bank of America.
But if this was... if they're actually... 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 acronyms.
It's a T-Lender model.
So, at this place, if they're publicly doing it, you'd probably have something like an URL.
I think Bank of America had a WSDL URL.
Ironically, not a... think of Lithuania. Awesome.
We'll have like an URL that goes to a WSDL that points you directly to...
Oh, something I forgot to mention about WSDLs that were in the slides.
A WSDL gives you everything you need to know to attach to a service.
So, that includes the location of it. Right?
So, a WSDL 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 WSDL, you have everything you need to know 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.
God, this is so slow.
So, anyway, everybody can go play with this when they're on their fast connections.
Uddi.microsoft.com or you search for UBR and you can play with other people's if you have a preferred vendor.
Oh, yeah. All kinds of stuff.
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 but not supported, so they throw it on the cheap site.
So, they don't have people calling the 800 number about it.
It's a great little graphical interface.
Like I said, you know, 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 XMLSpy, 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.
It does things like, like I said, you put a WSDL in there.
It can either be on the internet and you ask for it.
It can be local and then it'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 access point.
ASM.ASMX.
So, what platform do you guys think that is?
Windows, right?
It's probably ASP.NET.
Although web services are 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 guess that they have WSDL generation on there.
Looks like he was able to get it.
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 at 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 WSDL!
Ta-da!
Thank you.
Thank you.
So, this was able to grab the WSDL.
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 that's defining 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 doesn't take any input.
This one takes one string in the body.
And so if I wanted to put a value in there, I could put it in there and say invoke.
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...
One good way to do an attack on this would be to run Web Service Studio or Eclipse or XML Spy through WebScarab,
watch the traffic that's legitimate, and then edit it byte by byte by byte.
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 date type, yada yada.
So this one doesn't require anything to invoke it, so I'll invoke it, and I should get something back.
So right now it's going across the internet, it used the WSDL to generate a message that it thinks these people are going to understand,
and it sends it to them as an HTTP post and waits for the response, and here's the response.
It's an 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'd 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...
SOAP messages have the envelope, the body, the header, we talked about the header, the envelope's required,
it has things like what version of SOAP am I using, what's the namespace, stuff like that.
And then the response, which is just an 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 it returns,
this will return everything even if it doesn't have information in there.
And we're good to go.
So, here's the WSDL, it's really ugly. You can see why people don't read them.
For something that simple, right, it's all that WSDL.
You have to define everything like four times.
And you can see why that might be a place that people don't look.
So, we'll do an attack and we'll use Web Service Studio 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 web service to do the transfer,
find how to talk to that web service and talk to it.
And you can program their software to do all this, right?
Lots of MagicPC 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 with people.
Other than UBRs, there's some cool third-party registries.
x-methods.net has a big list of fun services.
A lot of these are by 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 web services.
And then there's this thing called Disco slash WS Inspection.
Disco is a lightweight 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 WS Inspection,
which is going to be a real standard to do this without running a whole other server to do it.
Our tool will automatically look for Disco files for you.
Like I said, a 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 OWASP top 10 things.
SQL injection still exists, 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 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 stream in it
that will magically get transferred by the XML document into whatever the string is and then put into the query.
Overflow is an unmanaged code, right?
Managed code is the Microsoft term for things like Java and .NET that run in a virtual machine.
Unmanaged code being something like I compile C++ for an x86 or a Spark, right?
Well, there's a lot of... a lot of people have a lot of stuff written in C and C++ out there they still use.
It still is 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 COM object that works and, you know, it can be something... I think it has to support I Unknown.
It's like the same standards. It has to be remotable like an ActiveX control.
If you have a COM object, you can just click through.
You don't have to write any code.
And say, I like this COM object. I want these methods to be exposed to the world.
And all of a sudden, now there's a web service with all these... 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 what the... I'm sorry, what the static buffer that goes to that stir copy is in that C++?
Do you think it does that? No, it doesn't.
Right? It just gives it the information. It just says a COM 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 like RMI and local calls and stuff.
It's not as easy though. It's not just click, click, click.
Mistakes in authorization and authentication.
Because SOAP is stateless, people have to rule their own, right?
It's very possible that there are methods out there that you find from the WSDL
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 WSDL.
And like, they're sometimes named really stupid things like, make me admin, right?
Cross-site scripting.
Now, like I said, this is not something, SOAP isn't something that you 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 in 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'll 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 go transfer money at a bank and I have to put a memo field in there about what my transfer's about,
I put that field in, I make sure the transfer's gonna 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 transfer's not working out.
Can you pull my file up and see what it is? Well, sure, give us your social.
They pull it up, it's a web interface, boom. Their own.
Obviously, that'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,
in 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 pre-written Java and just drop it in.
Yes, Access 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, works with Java, it's very nice.
We're playing 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 WizBang, that's how we pronounce it. It is a SOAP fuzzer.
It doesn't fuzz the SOAP implementation, it fuzzes the application behind it.
It takes a WSDL, right? And, you know, you can go and buy, like, SPI Dynamics and SyncDyn and all these, like, attack tools, attack web apps.
The really hard part that those guys have to tackle in writing 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 WSDLs, the WSDL will most likely represent the actual attack surface.
If it's not automatically generated to the WSDL, it's probably not callable remotely.
And so, it takes a WSDL, creates a nice little proxy, looks up what the types are, like, this is a string, this is an integer,
and it does 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 webpage.
And the future work we're looking at right now, it only works with 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 should support 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, that's pretty cool, it's OK,
takes a WebScarab as input, we use WebScarab a lot now, it's a really good product,
WebAttackProxy is probably the most you know, it's open source, OS does it,
there's this guy named Rogan in South America, right? I don't know where he is.
South Africa, I'm sorry, he's not South American. That's it, he's EA, right?
Who works on it, and Jesse submitted patches and stuff. Jesse likes to run it in Eclipse, in debug mode, like in real time.
He's pretty hardcore about that.
But anyway, it's really cool, and we use it a lot, and WizMap is not really for finding web services that are out there.
WizMap 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 web services are being used,
there's a point on the slide about OFX, which is the standard... anybody here use Quicken or Money?
OK, you're not going to raise your hands, but there are people in here who use Quicken or Money to manage their money.
There's nothing wrong with that. I'm just saying that OFX is the standard by which it talks to banks
when you say, update my account, 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 MBNA and American Express and stuff, right?
Those don't go through Quicken.
Intuit 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 WSDLs and disco files 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 files out there,
or 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 at the last minute because it wasn't working.
We're trying to get to find UDDI servers when you get a SIPR range, or maybe even an NMAP XML file, right?
Because they are web servers, you have to do kind of a Nickto kind of thing,
where you get a UDDI, where you look at a web server and you ask it, you know,
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 have these exposed,
just don't tell people about it, don't register them in UDRs,
just tell their partners about it.
And then hopefully one day we'll integrate it with WSBANE,
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 reg X 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's done in an hour and a half.
Okay, tying it all together, I think we kind of talked about this,
I can go to a UBR, I can 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 WSDL, it gives me the WSDL,
I look at the dangerous methods, I run WSBANE 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, are the old bugs still relevant?
A lot of people here would argue that OWASP Top 10 was never relevant,
or that OWASP Top 10 is actually saying that OWASP Top 4 in ten 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 and session management is a problem, like I said,
SOAP doesn't give that to you, you have to think about it yourself.
Cross-site 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, things like .NET remoting make that kind of stuff a reality,
because people might get lazy and not rewrite their 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 of 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.
Especially because of the ease of use on the developer side.
There's a lot of security work that needs to be acquired.
These people are writing these web wiz security standards,
but I don't think 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 code project or something, so you can do that.
We need people to find the best practices 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, please have your resume to career size.
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 want me to know how many people here know Leroy Jenkins.
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're a 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 partners to email them the WSDL, yes.
Turn off the auto mechanisms to publish the WSDLs and just email them.
That's the best protection against that kind of stuff.
Makes it much harder.
If you don't have the WSDL, there aren't built in stuff in SOAP just to ask for all the methods, right?
That's the method that's supported.
And people do that.
If you guys, if you go drop Google Maps into WebScarab and find out what web service they're talking to
and ask it for a WSDL, 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 the way you get people to use your service is to mail them a WSDL,
or you don't want people scraping it, like eBay and stuff,
so that they make money off of your work, then that's something you can do too.
Google API is probably one of the coolest web service interfaces out there.
See Johnny Long's talk.
Any other questions before we move on to me messing up the demonstration and you people laughing?
Okay. I'm really sorry that there's so much talking in a row.
We've 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 in 800x600.
A virtual PC of Windows 2003.
It's got a web service on it.
The exact same web service is currently running on wsdemo.isecpartners.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.isecpartners.com.
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.
No, I don't want to do it today.
It's got one user, or one method.
LogonUser, right?
So this is simulating maybe Word Bank.
And the first thing you need to 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 pentest this.
What am I going to do first?
And let's pretend this is one of those more complicated ones.
There's hundreds and hundreds and hundreds of methods here.
I want to see if there are any vulnerabilities.
And so I'm going to do that using WSBANE to do the initial.
So we're big on documentation and GUIs because we're privately funded and we have no venture capital.
If you want GUIs, go to Foundstone.
They excel at that kind of stuff.
So WSBANE, you give it an URL.
This isn't descriptive enough.
You have to give it an URL that gives it a WSDL.
It can also point to a local file.
So I am going to give it the URL of the WSDL I grabbed.
WSDL hashtags.
This is why our partner Himanshu, who spoke at Black Hat, he video records all his demos.
Which I'm starting to really appreciate how smart that is.
That's not a real demo if it's videotaped?
Right, okay.
Because I spend an hour and a half convincing you I'm smart and then I can't type.
Excuse me, sir?
Oh, yes.
Thank you.
Is that a little more readable?
Okay, great.
So, I'm running it with an URL that should give me a WSDL.
Okay, I run it. It pulls down the WSDL.
I didn't know that happened real fast.
It runs a bunch of tests.
It does this by looking up in an XML file it has, which I'll show you in 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 a type.
It can actually be an XML document itself and stuff like that,
if you want to do really 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 the things we want to try.
And it tries those things.
These are all the things that get tried on that one method.
And then it reads the response.
And this response, coming back from the SOAP message, is made pretty.
And here we have something that says SOAP fault.
So I click here, and it gives me what 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 in being able to set the SOAP action header
to different than actually what the method is in the SOAP message.
So that would be a checkbook.
And then, within the body, we say logon user.
The namespace is this namespace.
This is the encoding metadata.
And then these are supposed to be... 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.
And 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.
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 of the methods that get called in a row to parse that.
Look at this.
That's all...
Every one of those 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.
I'll say my password...
My username to quote.
Oh, exception. This isn't a local exception.
It just passes through a SOAP fault.
That's 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 is unable to process a request.
And what does that look like to you?
XPath.
So, what was it, sir, that I'm going to try next?
The winner of crack?
That's correct.
Let's give a round of applause for that.
Ta-da!
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-ho-ho-ho.
I assume the pauses in his human communication between words
were meant to represent the symbol also known as a space.
When encoded in UTF-8, so.
We'll let him keep the frack.
And string result successfully logged in on user ID 3, Henry Ackerman.
So, that was an XPath injection.
Why was it this user?
What's special about this user, do you think?
He'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 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, you know,
not ask 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, right?
Oh, yes. I'm throwing it out there. That's right.
I said it.
So, what do I want to do?
Right, I could 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, the XPath 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've 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.
Ta-da! Sorry.
If it works for Dan Kaminsky, he comes back every year to Black Hat in DEF CON.
So, if it works for him, it's going to work for me, right?
So, does everybody understand what we did here?
This was an XPath injection, XPath 1.
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 XQuery, right?
Because, like I showed before, XQuery, I mean, the simplest way to do it is all you have to do is to find the document you're looking up, which is the same as a table, right?
No questions on that? Yes, sir.
Of course, yeah.
How do I use that to map out the tables in the database or the XML file?
That is harder.
We're not there yet. You're right.
Emmett Klein worked on that, and 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 SQL is that there's SQL statements that you can do.
You're going to go Karl Rove style on them?
Okay.
I'm sorry.
It's probably doable. We don't have that answer yet, and that's something that we'll be working on.
Emmett Klein does it through that binary. I think now with XPath 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 URL, right?
It's like people do cross-site scripting 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.
Still, I mean, the guy's disappeared off the face of the planet, so if anybody knows him, have him email me.
I'd love to see what he was doing. But you're right.
In SQL Injection, there are the 19 commands you can probably do in a row that's with the error messages.
You can map out the... not the tables, but the nodes.
Okay, well, since we've got a second, I'm just going to do a quick demo of WISMAP.
Well, since I learned to set it up without you guys seeing it.
Okay, so this is WISMAP.
Python's compiling it.
Shoot, that's going to be hard to see.
So, if you run it with "-h", it says you can do all these things, ask for WSDLs, ask for DISCOs, store them locally, verbose.
I'm going to ask it to do everything.
I'm running in a directory with a WebScarab conversation log.
Although, if you have it in a sub-directory, that's fine, too.
It'll search all the directories for WebScarab logs.
Anybody... who here uses WebScarab?
Decent number. I recommend you guys use it.
Anyway, as you can see, there's no "-u", anymore. We had to pull that out, which is one of the great tragedies of my life.
Sorry.
And I'll run wismap.py-wsdls-discos, write out the files, and do it verbosely.
And I just generate 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 were different web services I would go to.
Like I said, this is not useful for blind. This is useful for reverse engineering something that uses web services.
And if the network actually worked here at DEF CON, you would see that it would find multiple WSDLs and DISCOs here and then write them to the local disk.
In the... which are already written. 1.disco, 1.wsdl, 2.disco.
Wow. Okay.
Okay, so it did one test. While that's going, I'll 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 WSDL 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 tests. It's looking for... it's asking for question mark WSDLs.
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 UDI. It doesn't define a web service. It defines the services you're publishing through a web server instead of running your UDF 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.