We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Don't Drop the SOAP: Real World Web Service Testing for Web Hacker

00:00

Formal Metadata

Title
Don't Drop the SOAP: Real World Web Service Testing for Web Hacker
Title of Series
Number of Parts
122
Author
License
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Over the years web services have become an integral part of web and mobile applications. From critical business applications like SAP to mobile applications used by millions, web services are becoming more of an attack vector than ever before. Unfortunately, penetration testers haven't kept up with the popularity of web services, recent advancements in web service technology, testing methodologies and tools. In fact, most of the methodologies and tools currently available either don't work properly, are poorly designed or don't fully test for real world web service vulnerabilities. In addition, environments for testing web service tools and attack techniques have been limited to home grown solutions or worse yet, production environments. In this presentation Tom, Josh and Kevin will discuss the new security issues with web services and release an updated web service testing methodology that will be integrated into the OWASP testing guide, new Metasploit modules and exploits for attacking web services and a open source vulnerable web service for the Samurai-WTF (Web Testing Framework) that can be used by penetration testers to test web service attack tools and techniques. Tom Eston is a Senior Security Consultant for SecureState. Tom is a senior member of SecureState's Profiling team, which provides attack and penetration testing services for SecureState's clients. Tom focuses much of his research on new technologies such as social media and mobile devices. He is the founder of SocialMediaSecurity.com which is an open source community dedicated to exposing the insecurities of social media. Tom is also a security blogger, co-host of the Security Justice and Social Media Security podcasts and is a frequent speaker at security user groups and national conferences including Notacon, OWASP AppSec, DEFCON and ShmooCon. Joshua "Jabra" Abraham joined Rapid7 in 2006 as a Security Consultant. Josh has extensive IT Security and Auditing experience and worked as an enterprise risk assessment analyst for Hasbro Corporation. Josh specializes in penetration testing, web application security assessments, wireless security assessments, and custom code development. He has spoken at BlackHat, DEFCON, ShmooCon, The SANS Pentest Summit, Infosec World, CSI, OWASP Conferences, LinuxWorld, Comdex and BLUG. In his spare time, he contributes code to open source security projects such as the BackTrack LiveCD, BeEF, Nikto, Fierce, and PBNJ. He is frequently quoted in the media regarding Microsoft Patch Tuesday and web application security by ComputerWorld, DarkReading and SC Magazine. Kevin Johnson is a security consultant and founder of Secure Ideas. Kevin came to security from a development and system administration background. He has many years of experience performing security services for fortune 100 companies, and in his spare time he contributes to a large number of open source security projects. Kevin's involvement in open-source projects is spread across a number of projects and efforts. He is the founder of many different projects and has worked on others. He founded BASE, which is a Web front-end for Snort analysis. He also founded and continues to lead the SamuraiWTF live DVD. This is a live environment focused on Web penetration testing. He also founded Yokoso and Laudanum, which are focused on exploit delivery. Kevin is a certified instructor for SANS and the author of Security 542: Web Application Penetration Testing and Ethical Hacking. He also presents at industry events, including DEFCON and ShmooCon, and for various organizations, like Infragard, ISACA, ISSA, and the University of Florida.
Web serviceStatistical hypothesis testingWorld Wide Web ConsortiumHacker (term)Information securityComputer networkSocial softwareTwitterInformation privacyMultimediaCodeOpen sourceWeb browserObject (grammar)Mobile WebInternetworkingState of matterAddress spaceProcess (computing)Thermodynamisches SystemIntegrated development environmentEmailStatisticsDependent and independent variablesMessage passingSoftware developerRepresentational state transferComplex (psychology)Standard deviationEnterprise architectureInduktive logische ProgrammierungSample (statistics)AuthenticationBusiness modelGame theoryVertex (graph theory)Mechanism designSpacetimeForm (programming)Term (mathematics)QuicksortSurfaceStatisticsEmailTelecommunicationCodecType theoryWave packetRight angleSensitivity analysisStatistical hypothesis testingPoint (geometry)Goodness of fitPlastikkarteHeat transferInformationWeb serviceInformation securityWeb applicationStatistical hypothesis testingMobile WebEnterprise architectureGame controllerProper mapMetropolitan area networkCodeProjective planeRegular graphMobile appVector potentialSequelVector spaceCuboidDifferent (Kate Ryan album)System administratorState of matterInformation technology consultingTwitterSoftwareSampling (statistics)Cartesian coordinate systemEntire functionCASE <Informatik>Self-organizationRepresentational state transferBusiness modelProcess (computing)Numbering schemeSinc functionFormal languageElement (mathematics)ParsingSoftware bugVulnerability (computing)Thermodynamisches SystemWebsiteDemo (music)Level (video gaming)Software developerMultiplication signClient (computing)ImplementationOpen sourceDependent and independent variablesMessage passingWorld Wide Web ConsortiumHypermediaStorage area networkPasswordInjektivitätSlide ruleFamilyComa BerenicesAuthenticationBacktrackingData transmissionGroup actionEntropiecodierungExploit (computer security)DivisorLecture/Conference
Statistical hypothesis testingProcess (computing)Integrated development environmentWeb serviceElectronic program guideUniqueness quantificationAddress spaceStatistical hypothesis testingStandard deviationBusiness modelPhysical lawInformation securitySoftware developerExecution unitInclusion mapConfiguration spaceMessage passingWorld Wide Web ConsortiumModule (mathematics)Port scannerSuite (music)Plug-in (computing)Latent heatScripting languageUser interfaceTouchscreenSystem programmingThermodynamisches SystemPhase transitionAreaMathematicsUniform resource nameComputer fontProcess (computing)Suite (music)Revision controlType theoryFunctional (mathematics)Different (Kate Ryan album)Web serviceStatistical hypothesis testingScripting languageSet (mathematics)InformationParameter (computer programming)Information securityClient (computing)Statistical hypothesis testingComputer networkWorld Wide Web ConsortiumMessage passingCodeMultiplication signWebsiteTerm (mathematics)Film editingSoftware developerInjektivitätBootstrap aggregatingModule (mathematics)Port scannerProxy serverMultiplicationQuicksortOcean currentWeb applicationMathematicsThermodynamisches SystemElectronic program guideJava appletBitVector spaceOpen sourcePoint (geometry)CASE <Informatik>State of matterConnectivity (graph theory)CuboidProjective planeGoodness of fitVulnerability (computing)Communications protocolStandard deviationLevel (video gaming)Metropolitan area networkMereologyRight angleIntegrated development environmentLink (knot theory)Business modelInterface (computing)Cartesian coordinate systemData storage deviceArithmetic meanAreaSequelAuthentication
Computer fontSuite (music)AngleIntelStatistical hypothesis testingData managementInterface (computing)Web serviceLevel (video gaming)TransportschichtClient (computing)Module (mathematics)Web pageEmpennageDialectExplosionMathematicsSicCurve fittingLie groupHacker (term)GoogolComputer fileDirectory servicePasswordWorld Wide Web ConsortiumDefault (computer science)Demo (music)OracleCartesian coordinate systemSimilarity (geometry)Uniqueness quantificationEnumerated typeGlassFishRevision controlServer (computing)Open sourceWeb serviceWorld Wide Web ConsortiumRule of inferenceStatistical hypothesis testingType theoryStatistical hypothesis testingInteractive televisionPhase transitionClient (computing)Information securitySampling (statistics)Web applicationBusiness modelPerspective (visual)PlastikkarteCartesian coordinate systemCASE <Informatik>Right angleInformationGlassFishBusiness objectSelf-organizationQuicksortFunctional (mathematics)Dependent and independent variablesInterface (computing)AuthenticationKeyboard shortcutSoftware developerPoint (geometry)PasswordDifferent (Kate Ryan album)InternetworkingWindowVector spaceHash functionCodeMathematical analysisResultantMobile appVulnerability (computing)Gastropod shellThermodynamisches SystemCuboidSystem administratorExploit (computer security)Special unitary groupVoltmeterBitMotion captureFuzzy logicServer (computing)Scripting languageSlide ruleComputer fileEnumerated typeGoogolMultiplication signDefault (computer science)Revision controlView (database)MereologyData managementGodModule (mathematics)Level (video gaming)Content (media)Domain nameRepresentational state transferMultiplicationSoftware frameworkOracleWhiteboardProxy serverPurchasingSequelSound effectPort scanner2 (number)Goodness of fitMeta elementElectronic visual displayTraffic reportingLecture/Conference
PasswordMobile WebKolmogorov complexityWeb serviceSurfaceContent (media)Library catalogWorld Wide Web ConsortiumSoftware development kitProcess (computing)Business Process Execution LanguageLogicImplementationAlpha (investment)Revision controlAuthenticationInformation securityModul <Datentyp>Statistical hypothesis testingDemo (music)Series (mathematics)Statistical hypothesis testingInjektivitätConsistencyDatabaseLevel (video gaming)Thermodynamisches SystemElectronic visual displayCurve fittingView (database)Execution unitFluxSoftware protection dongleSoftware developerVector spaceClient (computing)Different (Kate Ryan album)Web serviceComplex (psychology)MultiplicationOpen sourceWeb applicationLibrary catalogIntegrated development environmentCross-site scriptingCryptographyDefault (computer science)Right angleSinePerspective (visual)Link (knot theory)2 (number)Demo (music)Uniform resource locatorCASE <Informatik>Vulnerability (computing)QuicksortProxy serverImplementationType theoryAuthenticationFlash memoryProcess (computing)Cartesian coordinate systemTelecommunicationPasswordInjektivitätDependent and independent variablesDatabaseInformation securitySoftware frameworkState of matterSuite (music)Electronic visual displayPlug-in (computing)BitMultiplication signWindowEntire functionLevel (video gaming)Gastropod shellGlassFishTwitterStatistical hypothesis testingStatistical hypothesis testingCodeBusiness modelWebsiteSurfaceSelf-organizationWordRevision controlReal numberWorld Wide Web ConsortiumModule (mathematics)Thermodynamisches SystemProjective planeAreaTerm (mathematics)Wave packetSequelExtension (kinesiology)TransmitterError messageInformationWritingValidity (statistics)outputProper mapParsingCondition numberComputer wormOcean currentCuboidArmSystem callAdditionGoodness of fitSet (mathematics)Office suiteInterpreter (computing)Direction (geometry)Exploit (computer security)DivisorPerfect groupBookmark (World Wide Web)Computer animation
World Wide Web ConsortiumStatistical hypothesis testingWeb serviceHacker (term)Multiplication signGlassFishRight angleGastropod shellAuthenticationComputer wormRevision controlType theoryTerm (mathematics)Sampling (statistics)CuboidPasswordMobile appCartesian coordinate systemInterface (computing)Data managementFunctional (mathematics)Suite (music)World Wide Web ConsortiumTouchscreenInterpreter (computing)Lecture/ConferenceComputer animation
World Wide Web ConsortiumStatistical hypothesis testingWeb serviceHacker (term)2 (number)Web serviceSampling (statistics)Demo (music)Computer fileElement (mathematics)Fuzzy logicCodeWorld Wide Web ConsortiumGoodness of fitCuboidElectronic mailing listWordTwitterLine (geometry)Computer animationMeeting/InterviewLecture/Conference
Maxima and minimaDemo (music)Web applicationGastropod shellWeb serviceInterpreter (computing)CodeWorld Wide Web ConsortiumData storage deviceRootLecture/Conference
Interpreter (computing)Gastropod shellServer (computing)
Demo (music)Gastropod shellGlassFishAuthenticationCASE <Informatik>Proxy serverLogicCartesian coordinate systemSpecial unitary groupModule (mathematics)CodeWeb serviceGoodness of fitBoss CorporationFunctional (mathematics)Revision controlVector spaceSimilarity (geometry)
Dependent and independent variablesWeb serviceFunctional (mathematics)Port scannerComputer fileSystem callSequelQuicksortGastropod shellGroup actionMultiplication signInjektivitätModule (mathematics)Revision controlAlpha (investment)Demo (music)Core dumpResultantSoftware developerState observerSession Initiation ProtocolNetwork topologyDifferent (Kate Ryan album)TouchscreenFigurate numberGoodness of fitCodeWorld Wide Web Consortium
Transcript: English(auto-generated)
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 pentesting 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 pentester. You probably have seen my previous talks with Kevin
Johnson on social media, social networks. Founder of a website, socialmediasecurity.com. I co-host two podcasts, Security Justice and Social Media Security. You can find me on Twitter as Agent 0x0. So I'm Jabra, also known as Josh Abraham. For those of you who don't
know, I code in Perl. I do... I code in Python. Shut up. Fight. Shut up. I do penetration testing. I work at Rapid7. 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, LiveCD, Metasploit, Nmap, all these other
projects, beef. I do a lot of coding in Perl. So pretty much anything. Also helping people get through their demos and all that stuff. He spent all day coding yesterday for Rich Mogul. Yeah. So Rich Mogul's demo will be less fail on the fail panel. We are
not Kevin Johnson, obviously. Unfortunately, Kevin Johnson could not make it. He had a black hat. But I definitely wanted 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 an all around great guy. He is an open source bigot, as he will tell you. He runs all those various projects that
mention in the slide there. He's also a SANS instructor and also founder of pen tester scripting dot com and you can find him on Twitter as secure ideas. 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 pen testing web services. So initially what we're
going to do is go over the state of the union of pen testing web services. What are web services? Who uses them? Why would you want to pen test 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. A lot of references of Fight Club in this deck. So if you pick them all up, let us know. 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 you guys know that our pen testers, really those web services are really that secondary attack factor when it comes to any web application. We find that developers, 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 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. In the industry we're really pretty good at pen testing web apps but how
many pen testers out there really know about the process of pen testing web services? I claim very few. So the developers are sort of like getting a free ride if you have all these web services. If we're not pen testing them, what's their motivation to get them really locked down and secure? So that's sort of the reason why we did this research. So some recent statistics. 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 bar codes. That is probably a talk all in itself. 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. So there's a large attack surface for everybody to start going after. And if the industry as a whole hasn't been really good about pen testing 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 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 Jabra 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 JSON. So what's interesting, if you don't know what REST is, it stands for representational state transfer and these use HTTP methods like Jabra was talking
about. So your 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 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 tradeoff, 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, if you're pen testing JSON and that sort of thing, it's 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. All right. 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, you know, 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 user name 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 1 is going to be transmitting information all the way to node 5, 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 sysadmin who's malicious or, you know, maybe one of those
boxes, intermediate 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 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 environments. 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 too is really pen testers really don't know what to do
with web services. I talk to a lot of pen testers and there's always this, it 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 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 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 an automated approach? More manual? Unfortunately most of the stuff we
find is around manual testing. And 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 3. The guide itself is a fantastic guide for all 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 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 that's what we really want to do. So, you know, just a question, you know, what happened to things like there was an awesome little web service module in WebScrub 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 WebScrub as a web proxy anymore? Probably nobody, right? I prefer Burp. Everybody kind of prefers Burp. But, you know, things like WS Digger, you know, that was kind of the defacto tool at one point. You just throw a
wisdom at it and it 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 lots of problems. You know, Java really likes doing SOAP messages written by hand. That's your ‑‑ it really sucks. Please. 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 in, 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. So here's the web services module that they actually show it on the website of this module will be depreciated. So instead of 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 .net 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 an example to show you where all these gaps are. And it gets frustrating when you're in a pen test and you're trying to use these tools, you run into these roadblocks. And roadblocks 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 wanted to mention Ken
Johnson, he does some really good work around this area. He's got a great article. I definitely recommend everybody 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 to show, you know, we've got to write our own custom stuff like this and this
takes time, billable hours and it just really sucks. A lot of people in the industry who are pen testers are not really, you know, awesome coders, right? And not everybody is 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, you've got to 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 for web services. So I got this awesome new tool, this script, you know, I've done a lot of work here. Where do I test this thing? Do I test it on a public web service? Production environment. Or production environment. That's
awesome. That's not illegal or anything, right? I'll just build my own testing environment, right? I'll do that during the pen test, right? How good are you at coding? Yeah, exactly. So there's a big gap here. I think WebGoat 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 started with ground zero here and 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? We've seen a lot of problems here.
There's problems with pretty much everything. So of course keep calm and make soap. So what we're doing is we're taking the information from the OWAS testing guide version 3 and we've completely revised it with the newest technology that's out there for web
services and we are contributing this back to OWAS for the testing guide in version 4 that right now is under development. The big thing that we're changing is from a high level, I want to keep that in mind, from a high level we are aligning that with the PTES, 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
Chris Nickerson and others that are really trying to define what a penetration test is. So getting away from the vulnerability assessment versus a pen test. A pen test is not a vulnerability scan. A 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 define your WSDLs. You're going to enumerate those WSDLs. You're
going to look at WS security controls that may be in place or may not be in place. Authentication credentials, sample SOAP requests, and identifying those awesome web service interfaces, which Jabra is going to be talking about in a second. Awesome. There will be exploits. Yep. And that's something that gets overlooked a lot by pen testers and the clients, of course. The other important phase here is the
threat modeling. So asking the client, looking at the application, looking at the web services and saying, what is most valuable from a business perspective? If there's credit card information going through those web services, you're 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've 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 pen testing, 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've got vulnerability analysis. So this is where we 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
second. And then, 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, minimal testing, and then Beeple, which we have a whole slide on
Beeple. 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 and document, and, of course, reporting at the end of the day. Reporting is the necessary part. It sucks, but we've 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 when we're talking about testing web services. These are the types of questions you need to ask. So things like determining what type of frameworks. So WCF, Apache Access, Zen. You have to know that to start off with. The types of services. Do they use REST, SOAP? What type of
data? Provide all those WSDL end 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 and you're not wasting time trying to figure out all that stuff on your own. So without a sample web service request in many cases, what you would often get is a WSDL. And the WSDL just says here are the functions and here's 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 look at the invalid requests. So you want to see both. 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 ASMF, you know, Microsoft technologies, but there are also tons of others. And the WSDL, right, the WSDL is what you actually would specify. Sort of like the data definition for communicating with a SOAP web service. As I said previously, it 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 Shodan and Google to do this enumeration. Shodan is awesome. Yeah, Shodan is awesome. It's so much win. 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 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 this in a second. But Silverlight, the Zap files, if you search for those in Google, 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. We just did a quick Google search. Take a look at this. I mean, 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 pen testing it, it's pretty much like, you know, all right, there's some risk there. So
here's Tom's password. Because one of the things that we've basically seen is 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 go into an internal pen test, you know, pass the hashes is a nice example. You crack one
Windows system, reuse the password, you know, you'll 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, you know, 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 into 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 document 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 meta display module or something else and basically demonstrate that risk. Yeah, developers really, in talking with them, they have no idea that these web services 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 left this wide open and it's kind of shocking. 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. Any idea here was that if you took the same approach that we've been taking to 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 or a web service. So we could just deploy a malicious one if we could get 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 purchased Sun and what Sun had 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 versions 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 it's 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
gone across the board, multiple organizations, they're documented so they're public. So how do we find this sort of stuff? Using Shodan, 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
not really Oday 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 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 server, you know, you can gain access to all that
data. Well, this is 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, it's really hard and a lot of work. So somebody who's just like, all right, I just want to demonstrate some risk really, really easily, you know,
the script creators 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 risk. So I worked with a couple 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
some application or Glassfish or some 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. It 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 is really kind of a newer client side application type technology that Microsoft has 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 factor there. And
we've 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. What if Ajax calls to web services are made from the DOM? Yeah, now you've got to basically fire up firebug and then just start, you know,
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 wsattacks.org by Andreas Flackenberg. He's been a great example 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 bringing 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, you know, 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 a 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 vulnerable web service where you can demonstrate persistent cross-site scripting through a web service, which is really cool when you think about it. All right. How many in here have actually heard the word beeple? Do you guys know what this stuff is? Show of hands. Not too many people. So for those of you who don't know,
beeple is like if you have multiple web services 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. So you can have an XML parser for the way that your web services would communicate and that's all
represented in XML. 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 pen test beeple. So the best way to approach that sort of thing is with a developer and sit down with developer interviews. We're not even good
enough at pen testing web services so we need to improve that state to get to pen testing 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 white box approach is my recommendation in those situations. All right. So now we're going to get to some of 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 all right, well, the current methodology is to use SoapUI to communicate with burp suite or use Ken Johnson stuff and add the plug-ins and then do a lot of coding outside of Metasploit. So two things that I did here was I basically wrote up a quick HTTP repeater to 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 want to. So this is only the beginning when it comes to testing the web services in Metasploit. This is only 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 can definitely code some stuff up. So yeah, let's get to it. We're going to save all the demos to the end. That way we can go through everything and 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 an addition to Dan Vulnerable Web Application that was created by Ryan Dewhurst and it's now another piece of that application called Dan Vulnerable Web Services. So this provides really an awesome, 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 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
WSDL 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 there's no other way to do that. I mean, you have, you know, production environments or testing labs or that sort of stuff. You know, here it is. This is going to be the location
and also doing training around, you know, your pentesting team, making sure that they can pentest and demonstrate risk for vulnerable web services. So this is perfect. And the other thing is it's also 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 test this stuff on your own. Preconfigured, ready to go. Perfect. All right. So starting out, right, SQL injection, right? 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 error 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 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 a persistent cross site scripting flaw through a web service. This is where if you find a web service that is publishing information back to the web app, if I can inject some JavaScript 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, 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 what we're talking about today. So pay attention to these new attack vectors. The technology is rapidly changing. You talk to these developers and they are jumping on this stuff like crazy. Just the other day I was out doing an engagement and I had a client ask me, you know, what's the best practices
around, you know, what Microsoft web services and, you know, you got to do a little research because there's not a lot out there yet. I can tell you how to attack them and they're like, well, I want to know how to defend them. So you have to, you know, right now it's very immature from a security perspective in that area. And
you need to play catch up, unfortunately. And, of course, this work is only the beginning so you need to get involved at OWASP, contribute to open source projects, try your hardest to get developers to do the same. You may have to get violent with them, but 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 glassfish exploit. Yeah, so the glassfish exploit is already in metasploit. I'm going
to double that in a couple of seconds. And then these two links, these links will not take you to bad places, I promise. Yeah. And that's where you can get the link to our white paper and then Jabra is going to be posting the WS modules. Yep. You can download. They'll all be available. And then DVWS is going to be available through that URL right now. You can download that now. Check out the code.
And it will also be available in the next version of samurai WTF. Awesome. Let's get to some demos. Demo time. All right. 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. All right. So can you guys see this? Right? So this is Oracle Glassfish. It's running on 4848. So all I did was I used metasploit to basically
construct, you know, authentication, you know, user name and password to be able to demonstrate and get shell. You know, in terms of doing how to actually build this exploit, all I had to do was to sit down and use burp suite to intercept and identify what did I actually have to do to make this type of post request. So here
we're just setting the host name, setting the payload and just providing this functionality. So all we need to do is just take a look at the Tomcat manager exploit generator rawr, you know, upload exec and then execute. So there's another application interface which is port 8080. So you see set R port or app app
underscore R port. So you have to make another interface request to that interface. So here all we're doing is we're doing glassfish, you know, 3.1, finds the version, uploads, gets shell, interpreter. Now we're going to do the clean up because you don't want to leave stuff on the box and then it just does the
clean up and deploy. So that's shell in the box. Latest, you know, fully unpatched. Actually it's up to date. There's no way that they could patch this. So shell. All right. So this is the web fuzzer. And this is just like a sample
post request. That's an awesome fuzzer. It's blank. Hang on. Other screen.
Two seconds. There it is. It's that Dell you have. Shut up. This is why we record demos. All right. So we kept the post request. This is a sample web service with soap.
Too dark? Can we dim the lights for a second? Kind of a dark demo. Sorry. Is this better? Can you guys see? My lights are dim. All right. Well, we're
going to upload all the demos online afterwards. I'm going to post them on Twitter, all that stuff. You guys can find me if you want to see more demos. If you guys can see this, all I'm doing is using the MSF web fuzzer, sending in the post request and then sending 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 going to do request two. And we get to the fuzz list from like fuzz DB or wherever. Burp has a nice one too that you can import. All right. So here what we've done is we've actually identified that we had command execution through the web
service. Just put in the word ID and then from there we can get, you know, we're going to be able to get code execution on the box. So we're good. Now this demo is
basically just doing a few different things, right? The first thing we're going to do is we're going to have to generate a PHP interpreter, store it in shell.sh and then from there we'll upload it to our attacker's web application and then from the web
service download and execute that shell. Just copy it in the web root. All right. So for
this, as you can see, we got right here it says W get minus O, MSF shell dot PHP. That's basically because we have to have the shell interpret this as PHP code rather than TST.
So now we did the W get. It should be on the server. All we need to do now is execute the command and we'll get shell. So we have our interpreter. We're going to set it up
as a listener on 444. And now we're just doing the W get to make sure that the PHP shell gets called and then we'll see the shell on the interpreter side. All right. So there's
our PHP shell. Great. So I wanted to show a couple more demos. This is the Oracle
Glassfish authentication bypass on sun application 9.X. So this is like the earlier versions of Glassfish and we can just use a lower case get and or post request to just not even need credentials, right? This is a CVE that they claim they have fixed. So
it's detecting the version, trying the authentication bypass and it's going to do the logical attack vector based on the version. So that's full authentication bypass. We're good. So you can kind of lump this in with the J boss patchy Tomcat modules,
very similar functionality. Yeah. And if you look at the code for this one module, it's like an Uber module because it works on like, you know, I don't know, like eight different applications. Waiting for shell. Waiting for shell. Shell. Okay. So this is
the demo. And it does the cleanup just the same. So there's one more demo that we wanted to do. So I did some custom web services modules. I did an auxiliary
scanner to be able to detect one of which one thing was the all the different actions for a web service. We need to be able to enumerate those actions because
they're sort of like functions. 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 SQL injection or code execution, that sort of thing. So I'm just demoing using public web services, you know, to show that functionality so that 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 from the public web service. And we're just going to ask for the stock of, you know, something like that, like Microsoft. So here
what we're doing is we have a SOAP basic request based on a WSDL and then it will just from there use this particular action get quote. So what it's going to do is it's going to use the WSDL 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. You know, it's alpha version. So figuring out what is the most useful response. I wasn't really sure. But as you can see right here, we have all the data that we need. So we're good. And that's all going to get incorporated into metasploit. Talking with those guys and figuring out
when exactly this stuff will get merged in. The glass stuff exploit is already in the tree. This other stuff we just need to plan and figure out when is the best time to get that stuff merged in. You'll be able to download that from Jabba's blog, right? Yeah. I'm going to make it available. It won't be an SVN for metasploit, but it will be available as a tarball. So that's pretty much what we've
got. All right, guys. Thank you all for coming. We'll be in the Q&A room.