Web Application Penetration Testing Introduction


Published on

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 10 years in the industryLast 4 solely dedicated to pentestingBoth Infrastructure and Web Application penetration testing Worked both sides : Defense (security operations) and Offense (pentesting)
  • Take away with you that web app testing is a necessary piece to securing you dataI could spend a week on this topic. This will be brief. Hopefully you will walk away with enough knowledge to get started.I highly recommend reading material from OWASP
  • Focus will be on the demonstrationI will need to spend some time giving overview of methodology and some termsDemonstrationsLike the bank robber in the image, hackers are looking for items of value. The applications are the gateway to this data.[Image Explained]Long gone are the days of defacing a web site. Hackers are going after your data
  • The key word is ”method” in the definitionThe focus is on the application not the infrastructure.The goal is to take advantage of a weakness in a legitimate function for nefarious purposes.Anywhere from stealing money to stealing your identity to controlling the machine to stage another attack.Testing methods are well documented. You don’t have to be a hacker to test your apps.
  • [Answerthe question / misnomers after the video]You just audited my network / infrastructure! I must be secure?This is not an infrastructure test, a different focus that a infrastructure test will not coverBefore I answer, watch this video
  • Hackers retaliate to the shutdown of Wiki LeaksSo how does it work?
  • [Answerthe misnomers on this page]Firewall lets the hacker in, IPS / IDS is almost useless when the traffic is encrypted (SSL port 443). The cartoon image is dead on. You let him into your network. Network security was uselessYou are going to assume the role of the “Hacker”So how does this work?
  • Wrong! Pentesting is teachable. There are plenty of materials online and in books.You just need a little aptitude for details and have voracious curiosity.[ story about meeting Marc Maiffre founder of eEye ---short , mountain dew drinking little nerd. Little rich nerd though.]The Code Red worm was a computer worm observed on the Internet on July 13, 2001. It attacked computers running Microsoft's IIS web server.The Code Red worm was first discovered and researched by eEye Digital Security employees Marc Maiffret and Ryan Permeh. The worm was named the .ida "Code Red" worm because Code Red Mountain Dew was what they were drinking at the time, and because of the phrase "Hacked by Chinese!" with which the worm defaced websites.[1]
  • Before we start hacking, a little background…TWO PHASE APPROACH. Don’t be tempted to jump to phase two, could miss something or make inefficient use of timeThe passive phase will help refine your approach for phase IIYou will save time and get better resultsYou will deploy the same tactics and techniques as a hacker would!!! !!Trust me a competent hacker does his homework.
  • Is it Apache 2.x or IIS 7.xYou can look up know vulnerabilities by application type and version. This is public knowledge and very helpfulKnowing how the application works normally and its logic will help you determine abnormal behavior. Google knows all about your site if its on the Internet. You’d be surprised what types of documents are out on your site. You might find someone's password.Spidering allows you to map out the site based on hyperlinks!!!NVD – a ton of information can be found here to help determine vulnerabilities
  • Now you get to Hack! This phase is where the real testing begins. All the work up to now has prepared you for this moment.The attack plan is a list of all the exploitation categories. Your recon will allow you to tailor your attacks to and focus on certain categories.The items in the list are general categories for various attacks. Your research will help you determine which of the test categories are more likely to yield results. Configuration Management – Did you find a backend administrative page during phase 1. Maybe there is a default password enabledBusiness Logic – what would happen if I skipped step “B” and sent my browser to step “C”? Session Management – can more than one user login with the same account. Are cookies properly disposed of?Data validation – Classic XSS and SQL Injection. Session hijacking and database dumps. Web Services: SOAP REST, XML oh my!! This is a sub category of web application testing and is out of scope but the same phase approach applies. Some additional tools are needed.NOTE about the Image: “If McClellan had done his homework, he would have know that he had a3:1 advantage , Lee’s back was to the Potomac and could have ended the war. But McClellan belived Lee had twice as many men as he actually did and as a result was overly cautious. The result, the battle of Antietam was effectively a draw, Lee escaped, and the war drug out for another three years. Shortly after the battle Lincoln fired McClellan (again).
  • Introduction to type of toolsYou don’t need many tools to begin, these are the basics. All can be found on Back TrackA browser, I prefer Firefox because it has many plugins that really helpWeb Developer, Tamper Data, Live Http Headers, XSS and SQL inject me, Foxy Proxy, etc..Web Proxy, I’ll used BURP in the demonstrations.Briefly explain what a web proxy is, refer to the pirate image
  • Scanner – can be used as the initial instrument in phase II, still need to perform phase I manually. Review the Pros’s and Cons
  • The majority of phase two testing is somehow related to fuzzingFuzzing equals abusive user input.What happens when the program gets data it does not expect? -1 versus +1 , large strings of data, inserting codeIdeally the application gives you a very generic error message and rejects data that is inappropriate. But…Error pages can reveal a lot of information especially if debugging is enabled.Example, database schema or data, location of files, software versionsSummaryThe majority of web app testing can be summed up as “using the app in ways the developer did not intend”.Next two slides, Classic examples of fuzzing (SQL Injection and XSS)
  • The attack is through the web application to the database, not a direct attack on the database!!!!!Sql injection changes the query string to something other than the intended query.Often the application will respond with detailed errors, giving away schema and or the contents of the database.This vulnerability can disclose sensitive data in your database.
  • XSS can be discovered by fuzzingXSS enables attackers to inject client-side scripts into web pages or trick users into sending malicious code to a vulnerable web serverOften a part of a Phishing Attack
  • This is a non persistent example, very ugly exampleAn actual example I created to prove a pointNo filtering at all!Focus on the content between the <script> tagsThis example injects an iframe that calls in data from a third party website. The “request” parameter is injected with the attack string
  • To follow along, have BackTrack bootedGoalUse a web proxy with Firefox and attack a vulnerable applicationTarget is webgoatWill show two sample atttacks (SQL Injection and XSS)
  • With Google Hacking you cand findAny type of file, remote login via citrix, login pages, directory listings, text files, even passwords.
  • Directory listing of pages Here you will look for files to help you gain more knowledge about the sitePasswordsConfiguration filesOffice related files – metadata may disclose a user name
  • This is good for finding configuration Mgt. admin pages : Jboss,
  • This error gives me valuabe information about the databaseTable name = t.MenumenuID is a numeric value. I could use a tool to enumerate the menuID’s Can start to craft a SQL injection attack with this data
  • ZAP and Webscarab have Spidering capabilitiesRecord distinct URI’s(Uniform Resource Identifier) URI is the string of identifiers that makes a URL uniqueWebscarab is designed for more manual testingZAP has an automated scanner (parameter manipulator, not a vulnerability database)Burp Suite Pro (paid vor version) is like the previous two combined
  • Setup firefox to use the ZAP proxy.ZAP is in BackTrack under web-application proxiesUnder Tools  Options you can configure the local proxy, I used port 8088Capture a web site and run the spider toolNote that Burp is used in much the same mannerIf time permits run the scanner tool. Alternatively run it and come back later to the results
  • Xlose ZAP and open up BurpStart Burp Suite (webproxy) for capturing trafficEnsure the proxy is running, sometimes it does not turn on by default.Configure Firefox to use a proxyBrowse to a URL, make sure it shows up in the targets in BURP and then run the spider.
  • Log into webgoatDefine Webgoat – An insecure web application for the purpose of teaching how to perform web application pentests. It is a tutorial with several modules. Has various hints and and solutions .If there is time use Burp to spider webgoatShow how to capture trafficSend a packet to repeaterSQL and XSS examples
  • Web Goat DemoPurpose: To access Nevile's admin account with out knowing his passwordShow that you cant login with random passwords, show the failure noticeFlaw Exploited:The security flaw is that users have the ability (although limited but enough) to modify the SQL query directly in the password fieldHint: This is the code for the query being built and issued by WebGoat: "SELECT * FROM employee WHERE userid = " + userId + " and password = " + passwordGoal : Make the SQL statement evaluate as true!Answer:sql string to inject in the password field: 1+'or+'1'='1the "+" signs are used to fill in blank spaces and the "--" is a sql statement that this is the end of the query. The "a" can be anything, it just needs to be a false answer to the password does not match the userid's password entry in the database. The Single quotes make it a litteal "1". Sometimes you need the quotes in a sql injection attack, other times you don't. To find out which permutation will work can take time. it can be done manually or more easily done with a brute force method. The Intruder function in BURP can help with this.
  • The fix is to use stored procedures and disallow characters like the single quote
  • Test:In Webgoatgoto Cross-Site Scripting, Stage 1 Stored XSSGoal: Execute a Stored Cross Site Scripting (XSS) attack.Answer:In the Street field of theuser’s profile type in a javascript<script>alert(“You Won”)</script>Or<script> function showcookie() document.write(document.cookie); </script><body><br><input type="button" onclick="showcookie()" value="See Cookie" /></body>Logout as Tom and log in as Jerry and see if its there.The ultamate issue is that the user input is unfiltered, allowing one to insert code.
  • Start W3AF in Backtrack
  • If webgoat is availabe, have them scan it.There is a command line version of w3af, a little more stable, lighter weight.
  • Sample results of a scan
  • These are your “Hand Tools” they will do the job, not flashy and not necessarily easy to useYour Power tools are the commercial scannersBacktrack has all you need to get started.
  • Security Development Life Cycle is out of scope.But web app testing Should be part of the development life cycle!! Ask your self, ”Where is my valuable data on line?” !! help decide what to test firstRisk and Cost analysis is out of scopeBut, given tests generally run over the course of a week or two, you need to do some set up work to make things go smoothlyYou don’t want to inadvertently test a subdomain or function. Some tests may be very targetedAccess can be complicated in testing environments, vpn’s, client certificates, user accountsIn the event of a problem, you can call someone and vice versa. Communication with all groups is key. If a development team does not know about the test and pushed up a new code base, the test can become invalid.Obviously if you cant access the site due to scheduled maintenance, you can’t test and time is money.
  • Web Application Penetration Testing Introduction

    1. 1. 2011 NSAA IT Pre-Conference WorkshopPenetration Testing For Maximum BenefitWEB APP HACKING<br />
    2. 2. Web Application Testing<br />A concise Overview<br />Scott Johnson<br />Principal Security Consultant<br />Emagined Security<br />Introductions<br />
    3. 3. Grasp of the web application testing process<br />Convinced of the necessity<br />Knowledge of core tools<br />Confident that “I can do this”<br />Goals<br />
    4. 4. Overview<br />Testing Phases<br />Demonstration<br />Agenda<br />
    5. 5. Black Art or Science?<br />A penetration test is a method of evaluating the security of a computer system or network by simulating an attack. A Web Application Penetration Test focuses only on evaluating the security of a web application. The process involves an active analysis of the application for any weaknesses, technical flaws, or vulnerabilities. (OWASP)<br /><ul><li>Targets the legitimate business functions users use everyday.
    6. 6. The supporting infrastructure is generally off limits
    7. 7. It is not a code review</li></ul>What is Web Application Testing?<br />
    8. 8. Common Misnomers<br />“Our site is safe”:<br />We have firewalls in place<br />We encrypt our data <br />We have IDS / IPS<br />We have a privacy policy <br />Why Test?<br />
    9. 9. Web App Hacking in the News<br />
    10. 10. The firewall is going to let them in<br />Encryption will hide most of the attacks<br />Privacy? Like they care!<br />Your Front Door Hacker<br />
    11. 11. How does it work?<br />SQL injection over HTTPS (port 443)<br />Database returns<br />Account Passwords<br />Network Security Controls<br />acme.bank.com<br />Firewall<br />IDS / IPS<br />Data Base Server<br />
    12. 12. You Don’t have to look like this<br />You can perform web app testing if:<br /><ul><li>Basic understanding of HTTP protocol
    13. 13. Methodical
    14. 14. Tenacious curiosity</li></ul>Uber Nerd<br />Founder and CTO of eEye Security <br />Marc Maiffret<br />
    15. 15. Passive Phase<br />Information gathering<br />Understanding the logic<br />Observing normal behavior<br />Active Phase<br />Targeted testing<br />Applying methodologies<br />Testing Phases<br />
    16. 16. Reconnaissance<br />Reconnaissance is a mission to obtain information by visual observation or other detection methods, about the activities and resources of an enemy or potential enemy, (US Army FM 7-92; Chap 4)<br />Know your target before you begin, its worth the effort<br />Determine Application types and versions<br />Cross reference vulnerabilities with OSVDB / NVD<br />http://web.nvd.nist.gov/view/vuln/search<br />Observe normal behavior<br />Advanced Google searching<br />Aka Google hacking<br />http://en.wikipedia.org/wiki/Google_hacking<br />Application Mapping<br />Spidering / Web crawling<br />Directory busting<br />Passive Phase<br />
    17. 17. The Attack Plan<br />Configuration Management <br />Business Logic <br />Authentication <br />Session Management <br />Authorization <br />Data Validation <br />Denial of Service <br />Web Services Testing <br />Active Phase<br />
    18. 18. Deploying Your Assets<br />Browser (prefer Firefox and friends)<br />Foxyproxy, Live HTTP Headers, Firebug, Web Developer, etc…<br />Web Proxy<br />Aserver (a computer system or an application program) that acts as an intermediary for requests from clients seeking resources from other servers.<br />Examples<br />BURP<br />Webscarab<br />Paros<br />Tools<br />
    19. 19. Scanner<br />Tool that automates many of the tests methods described earlier<br />Many commercial tools – AppScan, Web Inspect, Accunetix, etc..<br />W3AF Web Application Attack and Audit Framework<br />OWASP ZAP<br />Free open source web scanner.<br />Pro’s – Fast and the tester quickly target weak spots<br />Con’s prone to false positives, poor session management<br />Does not replace manual testing<br />Tools - continued<br />
    20. 20. Definition: A software testing technique, often automated or semi-automated, that involves providing invalid, unexpected, or random data to the inputs of a computer program. The program is then monitored for exceptions such as crashes or failing built-in code assertions. (Wikipedia)<br />Fundamental technique in web application testing<br />Parameters<br />Form fields<br />Cookies<br />HTTP Headers<br />Can uncover many kinds of vulnerabilities: SQL injection, XSS, improper error handling, DDoS, etc…<br />Fuzzing<br />
    21. 21. SQL Injection<br />Fuzzing aimed at the database layer of an application<br />Improper user input filtering is the root cause<br />‘1 or 1=1 classic test string<br />Many variations, automated fuzzing helpful<br />
    22. 22. Bypass access controls<br />Hijack sessions<br />Disclose sensitive information.<br />Persistent – lives on the server<br />Non Persistent – malicious link<br />Targets users not your site!<br />Cross Site Scripting<br /><script>alert(“You Won!”)</script><br />
    23. 23. https://stg.acmesite.com/home/EP_SelectionIB.aspx?request=Ayn0G3lQ7l………BbK9M1vm8m3s%3df22b5<script> function changeSrc() {document.getElementById("myframe").src="http://www.emagined.com";}<br /></script><body bgcolor="Red"><table bgcolor=”red”><p><iframe align=top” width=”40%” height=”400” id="myframe" src="https://stg.xyz.com"><p>Your browser does not support iframes.</p></iframe><br> An Error Occurred<p><input type="button" onclick="changeSrc()" value="Click to Continue" /><p><p><p><p></body><br /></script>f973c1e3be0<br />XSS - Example<br />
    24. 24. Using a Web Proxy<br />Basic Recon.<br />Platform Back Track<br />Starting BURP<br />Configuring your browser<br />Starting Web Goat<br />http://x.x.x.x:8080/webgoat/attack<br />guest / guest<br />Capturing Traffic<br />SQL Injection Example<br />Cross Site Scripting (XSS) Example<br />Demonstration Overview<br />
    25. 25. <ul><li>Google Hacking
    26. 26. Inurl:
    27. 27. Site:
    28. 28. Filetype:</li></ul>Entire books on the subject<br />http://www.gnucitizen.org/blog/google-hacking-for-penetration-testers-second-edition/<br />Reference:<br />http://www.ethicalhacker.net/content/view/41/2/<br />http://www.google.com/intl/en/help/operators.html<br />Demo 1. – Reconnaissance<br />
    29. 29. Finding Indexes<br />site:sc.govintitle:index.of<br />Demo 1. Reconnaissance<br />
    30. 30. Finding login pages<br />Site:sc.gov login | logon<br />Demo 1. Reconnaissance<br />
    31. 31. Site:sc.govintitle:error | warning<br />Demo. 1 – Error Pages<br />
    32. 32. Demo 1- Passwords?<br />
    33. 33. Demo 1 - Passwords<br />You Bet!<br />
    34. 34. Spidering / Web Crawling<br />OWASP<br />Webscarab<br />ZAP<br />Portswigger<br />Burp Suite<br />Demo 1 - Reconnaissance<br />
    35. 35. Demo 1. ZAP - Spider<br />
    36. 36. Demo 2 - Setup <br />Make sure the port number is the same<br />In this case port 8008<br />
    37. 37. Browse to webgoat<br />http://x.x.x.x:8080/webgoat/attack<br />User ID = guest<br />Password = guest<br />Demo 2 - Setup<br />
    38. 38. Demo 2 – SQL Injection<br />
    39. 39. Why does that work?<br />Make the SQL statement evaluate as true!<br />1=1 right?<br />Answer:<br />1+'or+'1'=’1<br />Demo. 2 - SQL Injection - Answer<br />
    40. 40. Demo 2 XSS (persistent)<br />
    41. 41. W3AF Vulnerability Scanner<br />Platform Back Track<br />Starting W3AF<br />Layout and configuration<br />Defining the Target<br />Selecting Plugins<br />Analyzing Results and Reporting<br />Demonstration 3<br />
    42. 42. Demo. 3 – W3AF Layout<br />
    43. 43. Demo. 3 – W3AF Results<br />
    44. 44. Web Proxy<br />BURP<br />Paros<br />Webscarab / Zap<br />Fuzzing<br />WS Fuzzer<br />Brute Forcing<br />Brutus<br />Password Cracking<br />John The Ripper<br />Scanner<br />W3AF<br />Zap<br />Don’t forget the shell<br />Tool Starter Kit<br />There are many tools <br />Some technology centric: Citrix, Flash, javascript, etc… <br />Back Track is your starter kit<br />
    45. 45. OWASP Testing Guide<br />Comprehensive Guide<br />https://www.owasp.org/index.php/Testing:_Introduction_and_objectives<br />BURP<br />http://portswigger.net/burp/<br />W3AF<br />http://w3af.sourceforge.net/<br />Fire Fox & Friends<br />https://addons.mozilla.org/en-US/firefox/collections/adammuntner/webappsec/<br />Back Track –Every tool you need to get started<br />http://www.backtrack-linux.org/<br />References<br />
    46. 46. Questions<br />
    47. 47. Supplamental Slides<br />
    48. 48. Increase the likelihood of a successful test<br />Communication and Cooperation<br />Reaffirm scope of test<br />Validate functionality and user accounts<br />Technical support on the ready<br />No unforeseen outages or code changes<br />Pre-Flight Checks<br />
    49. 49. Burp Suite Pro<br />
    50. 50. W3AF<br />