 all right so thanks for coming to our talk seems like we've got a packed house so thank you all for coming we're going to be talking about pen testing web services so we're the web hacking ninja guys if you're looking for a different talk different room all right so yeah. My name is Tom Eston I'm a senior security consultant at secure state I'm a web app network pen tester you probably have seen my previous talks with Kevin Johnson the social media social networks founder of a website social media security dot com I co-host to podcast security justice and social media security find me on Twitter is agent zero zero. So I'm Jabra also known as Josh Abraham for those of you who don't know I code in pearl I do I code in Python. Shut up. Fight. Shut up. I do penetration testing I work at rapid seven we do some cool stuff we work on the metasploit project vulnerability assessment that sort of stuff. I also do a lot of open source work contribute to things like the backtrack live CD metasploit end map all these other projects beef I do a lot of coding in pearl so pretty much anything you know also helping people you know get through their demos and all that stuff so. He spent all day coding yesterday for Rich Mogul. Yeah so Rich Mogul's demo will be less fail on the fail panel so yeah. We are not Kevin Johnson obviously unfortunately Kevin Johnson could not make it hit a family emergency had to fly back around black hat but I definitely want to mention Kevin's work in this presentation and we'll be talking a lot about that if you don't know Kevin Kevin is a all around great guy he is a open source bigot as he will tell you he runs all those various projects that mention the slide there he's also a sands instructor and also founder of a pentester scripting dot com and you can find them on twitter as secure ideas. So we miss you we miss you Kevin. We miss you Kevin. All right so here is the agenda for the entire talk we're going to be talking about pentesting web services so initially what we're going to do is we're going to go over like the state of union of pentesting web services what our web services who uses them why would you want to pentest them and why is this relevant and why do you care and then from there we'll be going through our methodology that we developed and from there releasing some new tools some new process a threat model and then at the end we're going to do all the demos and also releasing an exploit so all that cool stuff all in one hour talk. And we hope you like the movie fight club. Yeah we're just going to throw that out there. A lot of references of fight club in this in this deck so if you pick them all up you know let us know. This is project man. We hope you guys enjoy it. So why do we want to attack web services well we found through our research and I'm sure any of you guys know that our pentesters really those web services are really that secondary attack factor when it comes to any web application. We find that developers well just like any other web app they really don't implement proper security controls. In fact I would argue that sometimes the security controls are even more lacking than a regular web app because these things are usually found outside of the web application and of course that it's assumed that only a client or another web service is going to connect to this and of course you know what happens when we assume. Yeah and in the industry we're really pretty good at you know pentesting web apps but how many pentesters out there really know about the process of pentesting web services. I would claim very few so the developers are sort of like you know getting a free ride you know if you have all these web services if you're if we're not pentesting them you know what's their motivation to get them really you know locked down and secure so that's that's sort of the reason why we did this research. So some recent statistics you know just in the mobile space Kevin Johnson did a little experiment where he downloaded about 200 iPhone and iPad apps and then he looked to see if any of those were using web services and he found that actually all of them are using some form of web service mostly restful web services not necessarily soap but it goes to show you that especially in the mobile space we're just seeing web service usage increase tenfold. This statistic here is interesting in itself because it's from a Microsoft tag which is Microsoft's implementation of 2D barcodes. That is probably a talk all in itself. Definitely. So we won't go there but this is just kind of giving you an idea that with web services and new technology we're seeing a huge increase. Yeah so there's a large attack surface for everybody to start going after and if you know you know the industry as a whole hasn't been really good about pentesting this sort of stuff. There's a huge gap for research, new tools, methodology process and probably a lot of vulnerable web services out there. So a lot of stuff. Okay so in terms of web services there's really two different types of web service. One of which is known as soap and then the other one is known as rest. So as you can see we're talking about I make and produce soap. So yeah in essence what soap is everybody knows about web apps and doing like a post communicating with a web application. Well that's all well and good. When we talk about communications with a soap web service what we're doing is we're including XML in that request and the way that we construct that message is known as soap. So it's just XML with the soap you know construct and that's how you would define the data inside of the message. So when you think of a soap request think of email so SMTP instead of just a web application where you're making a request getting a response. You could have multiple systems sending the soap message or envelope to other systems. So that's sort of the way to start thinking about it. So Jabber kind of mentioned about rest right. So I do a lot of developer training. I talk to a lot of developers and we've really seen this departure from XML based soap services over to restfuls like Jason. So what's interesting if you don't know what rest is it stands for representational state transfer and these use H.C.B. methods like Jabber was talking about. So you get post put and delete. The reason developers like these is because they are lightweight, non complex, they're good for mobile apps, good for a quick data transmission. However though and I want to make this point important that soap is complex and it's for a reason and during our pen tests we find soap being used almost all the time in enterprise level applications. And of course you know enterprise level applications are holding very sensitive information. Data transfer such as credit card numbers and lots of other things go across soap based services. So I mean sort of right here is where you have the trade off right? Do you go after what's you know widely being used in the mobile side or do you go after the enterprise? And since soap was more complex we figured we'd go after the more complex stuff because we get a lot of you know the if you're pen testing Jason and that sort of thing is traditionally being used in some sort of web application that's you know also being used there. So we felt that if we were going to go after soap some of those tools could be back ported since it's all HTTP anyway into a restful web application testing process. And don't forget large services we've got you know Amazon EC2, PayPal, Microsoft Azure these are large large web services that use soap APIs so we can't forget about those. Alright so now we're going to start talking about a threat model for web services. So initially right when you build a web application or web service the developers always need to know what do you mean when you say a secure web service? What does that actually mean? Well there's tons of different things usually when you have a web application we want some sort of authentication if there's valuable data there also we have to encrypt our traffic so making sure that that's encrypted is a very important thing. A lot of developers if they miss that step we don't really need to do much else because you can just hack one of the systems and then just sniff all the traffic and when we get to the exploit you're going to see how that's really really useful but in essence you know there's tons of elements here and we can't cover all of the different attack vectors but you know one of which if you think of XML right it's a really complex you know language and you know you have all these soap things so you have to be able to parse and look at that type of information so potentially bugs in a parser or you know the potential for injecting like code or commands into the application so one of the things we're going to be talking about later is a sample web service and you guys can see how that works but you're going to get all the different attack vectors SQL injection could be possible through a web service if you're looking at passing username and password there's potential for a lot of different flaws which we're seeing in web applications it's just a different way of communicating so here if you take a look either way if you start out by having node one is going to be transmitting information all the way to node five well if you're using SSL that's going to be encrypting or securing your data in transit but what does it do for the data on that box right if there's a sys admin who's malicious or you know maybe that one of those boxes in a meter systems gets hacked what do you have to do to basically protect your data right what's to stop somebody from modifying the information replaying that traffic or just dropping your traffic you know you don't have any assurance as to that type of a protection so in that sort of a case you may want to consider actually encrypting the entire soap message to provide that type of security if that's an important thing so in terms of who would use this sort of thing you could have various third parties so one organization transmitting to another and then that information could be transmitted to another so depending on you know how you're using web services you would have to construct you know a threat model and protect against those different attack vectors depending on your use case so you know in some situations SSL may be enough but in others it may not work so. So the state of the union here really through our research we found that there's issues with all kinds of things with web services so how to properly scope a web service pen test tools testing process methodology techniques to test education education for developers and vice versa and testing environment so basically we come up to the conclusion that it is all broken and we have to do something about this. Like a single serving friend. So what we found to is really pen testers really don't know what to do web services I talked to a lot of pen testers and there's always this this seems like this mystery with web services like it's a magical art to test web services and really what it comes down to is it starts with scoping so are you asking the right questions are you asking about web services when you scope out like a gray box web app pen test do you even know that the web that there are web services in that application web services may be the most critical part of that web app and if you don't ask the right questions you're not going to know until you get into it and then you find this out and then you come across you know a couple hours later and you've got to re-scope the whole thing and that wastes a lot of time and it wastes money and of course how do you test it so do we do use a no automated approach more manual unfortunately most of the stuff we find is around manual testing so of course manual testing takes a long time and when you have one or two days on a pen test that's usually not feasible. So going to the testing methodology really the only great guide that's out there or guide at all is the OWASP testing guide which has a web service component in version three. The guide itself is a fantastic guide for all you know web app pen testing but however the web service piece is really outdated. It's missing full coverage on recent threats and different types of threat models so for example man in the middle attacks, client side storage, host based authentication, it's focused on old technology so no mention of WCF services from Microsoft or how to test multiple protocols such as soap over TCP. Right and the other thing to keep in mind here is if you think of soap it's actually been around pretty much just as long as SQL injection and yet how many people in this room really know how to pen test for it? You know I mean at the end of the day it's an important thing it's out there developers are using it and developers are so far ahead of everybody in the industry in terms of pen testing these web services that we're basically we're playing catch up so. Yeah developers really have gone down that road of functional testing and there's lots of tools out there for functional testing like soap UI and things like that and we're seeing more recently that they're adding more security features into these tools but it's just now that people are talking about this stuff. So tools well they just suck I mean let's be honest right you know there's commercial tools like I mentioned you know soap UI they provide more functional testing for developers you'll see them all over the place but there's very little automation a lot of the tools that we find they're just missing features missing functionality they're not open source so you can't contribute you can't change code on the fly or customize it for certain situations so what we find is that we end up writing our own stuff writing our own scripts writing our own tools and of course that takes time and that takes you know time away from actually hacking which is like what that's what we really want to do so you know just a question you know you know what happened to things like there was an awesome little web service module in a web script and that is actually being depreciated I don't know why so that's unfortunate because that actually had some good functionality but who actually uses web script as a web proxy anymore probably nobody right I prefer a burp everybody kind of prefers burp but you know things like WS digger you know that was kind of the de facto tool at one point you just throw a whizzle at it and does a little bit of checking but you know it doesn't support SSL so like what the hell you know little things like that so we find a lot of problems you know Jabba really likes doing soap messages written by hand that's really sucks yeah these are things that just really suck and take a lot of time and of course we find tools are broken or you know just not working properly or you got to sit down and code this thing and I don't know 13 hours or whatever it is and if it's custom and it's you know to get the job done it is what it is you either do that or you have a different process right so here's here's the web services module that they actually show it on the website of this module be depreciated so instead depreciating I think we should improve it but you know oh well here's WS digger everyone's probably familiar with this just doesn't cut it these days in terms of tools another kind of decent one was WS scanner that came out about a year ago this is great and everything but you know it only supports dotnet web services so you're kind of screwed with anything else so I have clients who use other technologies don't you yeah I kind of do so this is kind of example to showing you where all these gaps are and it gets frustrating when you're in a pen test you're trying to use these tools you run into these road blocks and road blocks is what we're trying to get around yeah so our current process for pen testing web services prior to this talk was to basically use soap UI which is really just a QA tool the recent versions have included things like you know some security features but when I looked at the interface it was kind of difficult to use or just didn't make sense to me so I was like all right well just sort of you know go off and do whatever but soap UI and then what we would do is to use burp suite as a web application proxy so since it speaks HTTP beautiful we'll just use soap UI and have soap UI use burp suite as a proxy bootstrap our HTTP post request and then use the intruder and then just teach burp suite about web application or web services testing yeah I want to mention Ken Johnson he does some really good work around this area he's got a great article I definitely recommend everybody truck checking this out he's basically taken the functionality of burp suite he's written some ruby scripts and put them into burp so you can kind of do the soap UI functionality within burp now which is really cool but it kind of goes goes to show you know we've got to write our own custom stuff like this and this takes time billblowers and it just really sucks a lot of people in the industry who are pentesters are not really you know awesome coders right and not everybody's going to be an awesome coder and that's fine so at the end of the day we need to look to alternative approaches to improving our testing process because you know writing code takes time and or not everybody has that type of skill so to get the job done we got to get approach the problem a little bit differently so here's just a couple screenshots of using soap UI and this is just a simple request and then from there what we'll do is we'll set up the proxy local host 8080 and we would use burp suite to intercept that request and then from there we can use the intruder to do fuzz testing against the web service so here's just a simple example of a public web service and we're just sending you know some information and then from there you would just leverage the intruder or the repeater to replay this request do some fuzzing looking at interesting parameters here and then you would never fuzz a public web service would you Oh absolutely not definitely not so you know now going into kind of testing environments web services so I got this awesome new tool this script you know I've done a lot of work here we're where do I test this thing you know do I test it on a public web production environment or production environment that's awesome that's not illegal or anything right and ours build my own testing environment right that I'll do that during the pen test right how good are your coding yeah exactly so there's a big gap here I think their web goat had a little web service component at one point but I don't really know anyone that uses it or if it was that good to begin with so we kind of start with ground zero here we want to provide some value around how can we do this in a good testing environment that's open source and contribute it back to the community and if you ever see an online pregnancy test yeah what the hell is that right fail fail so what do we do about all this you've seen a lot of problems here there's problems of pretty much everything so of course keep calm and make soap so what we're doing is we're taking the information from the oas testing guide version three and we've completely revised it with the newest technology that's out there for web services and we are contributing this back to oas for the testing guide in version four that right now is under development the big thing that we're changing is from a high level and I keep that in mind from a high level we are aligning that with the p-test which is the penetration testing execution standard so if you don't know what that is it's a large project that's going on right now in the security community led by guys like Chris Nickerson and others that are really trying to define what a penetration test is so getting away from you know the vulnerability assessment versus a pen test a pen test is not a vulnerability scan vulnerability scan is not a pen test right but setting standards around this so you can take this to clients take this to customers whoever and they'll know what a pen test is and it really helps define a methodology for any type of pen test which is very important especially when we're talking about web services because they are so complex so breaking this down from a high level obviously our white paper that we'll have links to at the end has the full excruciating detail that you can go through but it really starts with the pre-engagement interactions which is your scoping questions and goals defining what type of assessment this is and of course your rules of engagement do you have web services that should be a question for any type of web app engagement exactly intelligence gathering so this is where you're going to find your whistles you're going to enumerate those whistles you're going to look at W.S. security controls that may be in place or may not be in place of authentication credentials so sample soap requests and identifying those awesome web service interfaces which Jabba is going to be talking about awesome there will be exploits yep and that's something that gets overlooked a lot by pen testers and clients of course the other important phase here is the threat modeling so asking the client looking at the application look at the web services and saying what is most valuable from a business perspective there's credit card information going through those web services damn right that's important and that's something that you're going to have to test for and talking with developers is probably the best way to get a really good understanding of the threat model right so understanding the business is critical but then talking with the developers how did you implement this thing how did you build security into this web service I got to understand how you did it because that's the only way in some cases that we can provide assurance that it's even close to good and when you're doing your pen test you want to outline a realistic attack vector so a web service that's only used internally versus one that's accessible on the public internet is going to have a completely different threat model and you need to define that ahead of time next up we got vulnerability analysis so this is we're going to actually do our testing we're going to do the authentication testing transport layer web service interface management testing and analyze client side applications which we'll talk about in a little bit like Microsoft server light that interface with web services and of course the fun part right exploitation so we're going to do our content level testing we're going to be fuzzing you may want to use Jabra's new Metasploit MSF web fuzz module which we'll talk about and of course doing replaying man and middle testing and then people which we have a whole we'll talk about slide on people right now once you have shell hopefully you do have shell because you can get shell through a web service which Jabra will demonstrate you want to prepare in documents and of course reporting the end of the day reporting is the necessary part it sucks but we got to do it right so scoping this is a big piece that I want to spend some time on this is critical absolutely critical we're talking about testing web services these are the types of questions you need to ask so things like determining what type of framework so WCF patchy access then you have to know that to start off with the types of services do they use rest so what type of data provide all those wisdom and points and paths we need to have that in advance to do the testing properly what type of authentication does it use we find that some clients are setting up this you know strange custom authentication and if you don't know that ahead of time you're going to be in a bind once you start figuring out how that web service works definitely have the client provide multiple soap requests in advance showing the full functionality so you can do your testing you're not wasting time trying to figure out all that stuff on your own so without a sample web web service requests in many cases what you would often get as a whistel and the whistel just says here are the functions and here's you know roughly what the data would look like but you actually want to be able to make valid requests and see what valid responses would look like and then you know look at the invalid requests right so you want to see both right so understanding that if we have a sample web service request that would be super useful when we're actually doing the pen test all right so now when we're doing fingerprinting right we're going to go off and try to enumerate where are those web services on the internet so as a math you know Microsoft technologies but there are also tons of others and the whistel right the whistel is what you actually would specify sort of like the data definition for communicating with a soap web service this just you know as I said previously defines all the methods and all the different types of values that would be passed to the web service from there you can also look at you know using things like show Dan and Google to do this enumeration show Dan is awesome yeah show Dan is awesome it's so much when definitely makes reconnaissance really really easy especially when you're looking at web applications or web services reconnaissance it's definitely the primary method I would use and something that kind of gets overlooked now I mean Microsoft Silverlight is kind of a newer technology and and we're just starting to see a lot of research coming out about you know around the security of Silverlight but I'll talk about in a second but Silverlight the zap files if you search for them they're usually tied to web services so you can look at the client side app and then see where those services are exposed and then go from there yep okay so here are some of the results just did a quick Google search take a look at this I mean this is this is right now on the Internet this is pretty much what we found so you know it's definitely out there and if you know as an industry we're not really good at pentesting it's it's pretty much like you know alright there's some risks there so here's Tom's password because one of the things that we've basically seen it's kind of like in the industry we default and reuse passwords in my from my point of view is most organizations that's their biggest risk right so when you think of when you're going to do an internal pentest you know pass the hash this is a nice example you crack one window system reuse the password you know you probably compromise the entire domain so that's one thing that we've seen as you know a very useful vector so I did some research last year on SAP business objects and they had a you know a default username and password and we were able to get shell on this box so that was through a web services management interface right so thinking about not just the web service not just the web application but also the other interfaces that control that stuff right so some of the developers may not even be logging in to these web management interfaces because they may not need to if the security guy doesn't know about it and the developer doesn't use it well it's still there and it's a huge risk in the industry and if it's a documented username and password you know the attackers can you know they can do a quick Google search and find this stuff so we need to be able to translate that into a metasploit module or something else and basically demonstrate that risk. Yeah developers really I'm talking with them they have no idea that these web service interfaces are out there so they're actually kind of surprised when we make this a finding and they're like oh my god we we left this wide open and it's kind of shocking so yeah access to you know exposed on the internet with default credentials is code execution so all right so one of the things that I'm going to be talking about for this year is Oracle Glassfish which is something similar to Tomcat Manager and JBoss and Access2 it's basically like Access2 which is for handling and deploying web services but there's tons more functionality there right so it runs on a unique port which is 4848 and the idea here was that if you took the same approach that we've been taking to you know Tomcat Manager and Access2 and apply that to Glassfish potentially we could get shell through this application because it does allow for the ability to deploy a malicious web or a web service so we could just deploy a malicious one if we could get you know authenticated through the application or maybe bypass authentication so in the industry one of the things that we've seen is that there are actually documented there was a documented CVE which is a known authentication bypass for earlier versions of Oracle Glassfish so there's you know Oracle had previously they had purchased Sun and what Sun had was it was 2.x and Sun application server 9.x so there were the earlier versions and also it affects Glassfish 3.x so those were the earlier version that the authentication bypass affects but in the later version 3.1 there was also a default username and password so it's admin blank password right so as an industry we've seen from SQL Server SA 2011 and we're still seeing that sort of stuff so as an industry it's you know it's gone across the board multiple organizations they're documented so they're public so how do we find this sort of stuff using showdan we're good enough just type in Glassfish about 1400 systems on the internet so it's definitely out there so you know something to be aware of and it was documented so it was documented functionality so from that perspective it's it's not really ode because there is no patch there probably won't be a patch because there's nothing they can really do about it we just needed to make make sure that the security community was aware of you know you can get shell on this box you know if you have this documented you know admin blank password of course once you have shell and you have access to the internet server you know you can gain access to all that data well this is the going to the web service this is the the system that's going to be running the web services so if we just do a packet capture we're going to be able to get all that customer data anyway there's not a lot of work there all this web services stuff and the soap and communicating with XML that's really hard and a lot of work so somebody who's just like alright I just want to demonstrate some risk really really really easily you know the script could use of the world or you know whatever it is or even doing a vault scan you could probably pick this up in a vault scan so relatively easy to do and then from there the client needs to understand that that risk so I worked with a couple of other guys on this from the Metasploit team and some contributors so from here we got the exploit working really really beautifully so if you guys want to try it right now it's already in the Metasploit SVN it does version detection for you and then it does the best type of approach first and then it will walk down from there so on Glassfish 3.1 you have default credentials for the earlier versions you know 3.0 or Sun application or Glassfish or Sun Glassfish 2.x what it will do it will do authentication bypass and then it will try the default credentials on those earlier versions so those are fully documented and that works great so you're going to get Shell on a whole lot of different versions there's commercial and the open source works on both I tested this pretty extensively if you find any bugs please feel free to email me but yeah we'll do demos at the end so we can get Shell so we talked a little bit about Microsoft Silverlight and some other expanded attack services Silverlight's really kind of a newer client-side application type technology that Microsoft's developed but we found that it can use web services and it can use it extensively so it's more than just a flashy banner ad you can develop entire applications in Silverlight and they use WCF which is Windows Communication Foundation if you're not familiar with that it's a newer web service technology from Microsoft and what we found is you can really pretty much discard the application itself once you know what web services it's interacting with and attack the services directly so the developers like Silverlight because it pushes a lot of the client-side processing and things like that back down to the client and all you've got is these lightweight web services to transfer data so it's becoming more of a popular thing so the security we found really depends on how you configure those WCF services and that's really the attack vector there and we also seen a lot of complexity especially with Ajax and Flash implementations that are leveraging web services so great question I know Jabra I think you ran into this you know what if Ajax calls to web services are made from the DOM? yeah now you've got to basically fire a fire bug or fire bug and then just start reviewing that stuff because it's not going to be going through the proxy in that sort of case exactly so we've also seen a lot of different types of attacks being documented I wanted to definitely mention WOSattacks.org by Andreas Flakenberg he's done a great amount of work here detailing and cataloging pretty much every type of web service attack that's out there I mean there's stuff out there that I never even heard of before and it's an excellent excellent bit of work that hopefully he's going to be bringing this back into OWASP and bring it back into the community but he catalogs everything around soap and people services and you definitely need to check that out and we've tied this into our methodology as well so we've referenced where you can see these different attacks on his site and back and forth so no need to duplicate the efforts that have already been made we want to basically reduce these locations because there's so much attack surface we want to basically have one location for everybody in the industry to go to when we say we want to pen test the web service here's the location go yeah and one thing that we're finding too is that we're finding soap requests now that actually provide content back to the web application so Kevin has designed an actual a vulnerable web service where you can demonstrate persistent cross-site scripting through a web service which is really cool when you think about it alright so this thing called Beeple Beeple how many in here have actually heard the word Beeple right do you guys know what this stuff is alright show of hands not too many people right alright so for those who don't know Beeple is like if you have multiple web services right in an organization or even with a third party that sort of thing Beeple is the way that those web services could communicate and you can document that sort of thing in XML right so you can have an XML parser for the way that your web services would communicate and that's all represented in XML right so there's the XML there's an XML parser that's a whole lot of stuff but in terms of the industry we can't really we're not sophisticated enough right now I don't think to pentest Beeple so the best way to approach that sort of thing is with a developer and you know sit down with developer interviews we're not even good enough at pentesting web services so we need to improve that state to get to pentesting Beeple because when you think about multiple web services communicating based on conditionals or whatever situation is there we just don't have the tools to do it so a white box approaches my my recommendation in those situations alright so now we're going to get to some of the the cool stuff that we did and improving the state of the industry one of the things that I did was I was looking at the current stuff in Metasploit and I was like alright well the current methodology is to use Soap UI to communicate with BurpSuite or to use Ken Johnson stuff and add the plug-ins and then do a lot of coding outside of outside of Metasploit so two things that I did here was I basically wrote up a quick HTTP repeater that basically take a soap request and send this off to a web service and then the other thing that I did was to do a quick HTTP fuzzer so that we could actually demonstrate how we could find these vulnerabilities with Metasploit the next step will be to basically leverage some of the modules that I wrote to be able to construct these payloads like a PHP interpreter and actually get that included so that you can actually get shell if you find something like a command execution that sort of thing right so this is only the beginning when it comes to testing the web services on Metasploit yeah this is this is only this is only the the way way way beginning right this is like a call to arms everybody needs to get involved with this stuff so if you're pen testing web services you want to help out let me know we could definitely code some stuff up so now let's get to it we're gonna save all the demos to the end that way we can go through everything we won't skip anything so Kevin spent a lot of time working on you know let's find a way that we can have a good testing environment that's open source give it back to the community where we can test these things so he basically has created in addition to Dan Vulnerable web web application that was created by Ryan Dewhurst and it's now another piece of of that application called Dan Vulnerable web services so this provides really an awesome series office office a great set of things to test in terms of all kinds of vulnerabilities so it uses the Dan Vulnerable web app authentication by default which is nice the only thing that that I like about it too is it offers high medium and low difficulties so if you're just testing some simple things or if you want to get more advanced that's all available for you now there's a whizzle available for each service and then you can test reflective as well as persistent vulnerabilities so this is going to be super useful because we're going to be building a lot of new tools and improving our testing methodology so this is going to be what we're going to leverage to verify that our stuff works right because no other way to do that sort of stuff you know here it is this is going to be the location and also doing training around you know your pen testing team making sure that they can pen test and demonstrate risk for affordable web services so this is a perfect and the other thing it's also extend extendable which is great it's open source you guys can look at the code make modifications and do what you want with it he's also going to make this available in the Samurai web testing framework so also a great testing framework live CD that you can download pop it into a VM and then perfect all right so starting out right SQL injection like well SQL injection over web services right not too difficult right username and password transmits to a database you get the response well great and you know the various levels right you could have blind you could have air based you know all the different types you know union all that stuff so tons of work here the next example is the code execution right command injection this is going to be what we're going to be demoing to get shell to demonstrate some real true business risk and really just drive that home and also we have the you know the higher level for for this particular you know web service is blind command injection so good stuff you want to talk about the yeah this is my favorite so um persistent cross-excripting flaw through a web service on this is where if you find a web service as publishing information back to the web app if I can inject some JavaScript into into that web service request I can get that to show persistently back to the user so the challenge with this is this actually posts it back to the main web application within a damn vulnerable web app to kind of show you um you know if they're not doing proper input validation that you can get that to pop so before we jump into the demos just to kind of conclude here uh or to or we're talking about today um so pay attention to these new attack vectors the technology is rapidly changing um you talk to these developers and they are jumping on this stuff like crazy um just just the other day I was out doing an engagement and had a client ask me you know uh what's the best practices around uh you know web microsoft web services and you know you gotta had to do a little research cause there's not a lot out there yet um I can tell you how to attack them and they're like well I want to know how to defend them um so you have to you know right now we're just it's very immature from a security perspective um in that area um and so they're really ahead of us with developers and their functional testing um we need to play catch up unfortunately projects um try your hardest uh to get developers to do the same you may have to get violent with them but uh sometimes you have to with developers right and if you want to get involved and you're not a coder feel free to let us know about anything that you're seeing in the industry right if you're seeing web services that are communicating in different ways or things that we haven't thought of in our threat model let us know like we're on twitter so it's very easy to find us you know any reply will you know you'll definitely have my eyes on it so let us know and you can SVN update right now to get the glass exploit is already in metasploit I'm going to double that in a couple of seconds yep and then these two links these links will not take you to bad places I promise yeah um and that's where you can get the link to our white paper and then Jabba is going to be posting the uh mod WS WS modules yep you can download they'll be available yep and then dvws is going to be available through that ur right now you can download that now check out the code um and it'll also be available in the next version of samurai WTF awesome let's get to some demos demo time alright so the first demo we're going to do is the glassfish stuff because I know you guys want to see shell pop right now you guys are like antsy so can you guys see this right so this is Oracle Glassfish it's running on 4848 um so all I did was I used metasploit um to basically construct uh you know authentication you know username and password to be able to demonstrate and get shell um you know in terms of doing uh how did it actually to build this exploit all I had to do was to sit down and uh use burp suite um to intercept and identify what did I actually have to do to make this type of uh post request so here we're just setting the the hostname setting the payload um and it's providing this functionality so all we need to do is just take a look at the the Tomcat manager exploit generator R you know upload exec um and then execute um so there's uh there's another application interface which is port 8080 so you see set our port um or app app underscore our port um so you have to make another um interface request to that interface so here all we're doing is we're doing uh glassfish um you know 3.1 finds the version uploads gets shell interpreter now we're gonna do the cleanup because you don't wanna leave stuff on the box um and then it just does the undepoy so that's shell on the box uh latest uh you know fully unpatched or actually it is I mean it's it's up to date so there's there's no way that they could patch this so shell alright so this is the uh the web fuzzer and this is just like a sample post request um that's an awesome fuzzer it's blank hang on other screen 2 seconds there it is it's that dell you have shut up this is why we record demos alright so we cap the uh the post request this is a sample uh web service with soap can we dim the lights for a second? kind of a dark demo sorry there we go this is better can you guys see my lights are dim alright well we're gonna upload all the demos online afterwards so they'll be on I'm gonna post on Twitter all that stuff so you guys can find me if you want to see more demos um if you guys can see this um all I'm doing is using the MSF web fuzzer um setting in the post request and then setting in a file which basically has all of the elements to basically use and fuzz inside of the post request so here's request one and then we're gonna do request two we get to take a fuzz list from like yeah fuzzdb or wherever you know burp has a nice one too that you can import alright so here what we've done is we've actually identified that we add command execution uh through the web service um just put in the word ID and then from there we can get uh you know we're gonna be able to get uh code execution on the box so we're good now this demo is basically just doing um a few different things right the first thing we're gonna do is we're gonna have to generate a PHP interpreter store it in shell.sh and then from there we'll upload it to our attackers web application um and then from the web service download and execute that shell just copy it in the web root alright so for this um as you can see uh we got uh right here it says uh wget minus o msf shell.php um that's basically because we have to have uh the shell interpret this as php code rather than you know tfd so now we did the wget should be on the server all we need to do now execute the command and we'll get shell so we have our uh interpreter we're gonna set it up as a listener on 444 and now we're just doing the wget to make sure that the php shell gets called and then we'll see the shell on the interpreter side alright so there's our php shell great uh so I wanted to show a couple more demos this is the uh Oracle Glass Fish Authentication Bypass on Sun application 9.x so this is like the earlier versions of Glassfish um and we can just use uh a lower case uh get and or post request um to just not even need credentials right this is a a CVE that they claim they have fixed so there it goes it's detecting the version trying the authentication bypass um and it's gonna do the logical attack factor based on the version successful authentication bypass we're good so you can kind of lump this in with the uh in the Jboss patchy tomcat modules very similar functionality yeah and if you look at the code for this this one module it's like an uber module because it works on like you know I don't know like eight different uh applications waiting for shell waiting for shell shell and it does a cleanup just the same so there's one more demo that we wanted to do so I did some uh custom web services modules uh did a auxiliary scanner to be able to detect um one of which uh one thing was the uh all the different actions for web service we need to be able to enumerate those actions we need to be able to make those calls to those various functions and then pass in data to you know either get shell or you know do some sort of uh SQL injection or code execution that sort of thing so I'm just demoing using public web services um you know to show that functionality so you could reuse that exact demo and then get the same result shouldn't be pen testing public web services we're just using them as a normal developer would so you can see there's a get quote function and we're just gonna ask for the stock of you know something like that like Microsoft so here what we're doing is we have a a soap basic request based on a Wizzdle um and then it will just from there use this particular action get quote um so what it's gonna do is it's gonna use the Wizzdle to generate the soap request and here is the response so I basically converted the response and using Ruby to basically just dump all of that data to the screen um you know it's a it's alpha version so I wasn't really sure but as you can see right here uh we have all the data that we need so we're good um and that's all gonna get uh incorporated into Metasploit uh talking with those guys I'm figuring out when exactly that's this stuff will get merged in the glass stuff exploit is already in the tree uh this other stuff uh we just need to plan and figure out when is the best time to get that stuff merged in yeah you'll be able to download that from Jabba's blog, right? yeah yeah I'm gonna make I'm gonna make it available uh it won't be an SVN for Metasploit but it will be available uh you know as a tarball or sub file whatever so that's pretty much what we got alright guys thanks for coming we'll be in the Q&A room we'll be in the Q&A room we'll be in the Q&A room