With so many web applications, universities have a huge attack surface often without the IT security budgets or influence to back it up.

Transcription

1 1

2 2

3 Why do we care about web application security? With so many web applications, universities have a huge attack surface often without the IT security budgets or influence to back it up. We constantly see threats hitting our firewalls, malware on our desktops and now more and more web based attacks both automated and targeted. Attackers are looking to steal the data we hold, both personally identifiable and financial information. They also target our resources, network bandwidth and compute power. In the process they can destroy a universities reputation. 3

4 I found this quote to be relevant when reading an article about a recent targeted attack on the University of Nebraska where attackers stole over ½ million records. Source: If you want to track published university breaches Softpedia and DataLossDB are good sources to follow

5 Over the past year I have reviewed over 50 web applications These applications were developed both internally and those purchased from vendors Everything from lecture capture to budget web applications Some were written in obscure languages or had weird configurations In rest of the presentation I will talk about some of things I have learned. 5

6 So, what is a web application attack anyways? An attacker attempts to insert malicious code into your application through input fields in order to gain access to your data or to elevate privilege within the application. 6

7 7

8 OWASP (The Open Web Application Security Project) is an organization that was created to raise awareness and bring focus to application security. They produce and regularly update a list of the top web application vulnerabilities and how to prevent them. I have chosen these 3 to talk about as they are commonly seen being attempted and also are the biggest impact as well as usually the most common vulnerabilities I find in applications. Please read the entire list and use/contribute to OWASP as it is a great resource. 8

9 Many of you maybe familiar with SQL injection, this vulnerability has been long publicized none the less I still commonly find this vulnerability in web applications today. Exists when an application uses untrusted or unescaped input data to construct a query. For SQL, developers should use bind variables in all prepared statements and stored procedures, and avoid dynamic queries like the example shown. If nothing else whitelist acceptable input data as enumerating all possible bad is not comprehensive. Possible with many types of application queries SQL, XPATH, LDAP, OS commands, etc Usually the most potential to cause harm as an attacker could manipulate/access application data or systems 9

10 In this example the query accepts user input for username and password to construct the query. If an attacker were to use the single quote or 0=0 for both it would return every record as 0=0 will always be true. 10

11 Bobby Tables 11

12 Very widespread vulnerability in applications tested and can be just as dangerous as an inject depending on the context. Similar problem as an injection, exists when an application does not validate input data and returns the unescaped user input back to the browser. In this example the attacked submits malicious JavaScript in a search field, this becomes stored on the search page as a recent search. A victim then goes to the site and the JavaScript executes on their system. Developers need to properly escape/encode untrusted data for the context it is being returned to in a browser. A whitelisting input validation approach is also important in mitigation of XSS. Multiple types stored, reflected, DOM based Stored is where malicious code is permanently inserted into the application and loaded into application pages Reflected requires tricking the user into going to a vulnerable application URL with the malicious code as parameters to be executed DOM based is where malicious code is not returned by the server but via a client side script. 12

13 I have recently been testing for finding insecure coding practices in client side code Allows an attacker to execute malicious code in the users browser in the context of the application Example would be JavaScript to hijack a users session, steal users cookie 12

14 13

15 This is basically an OWASP term for managing logins and sessions. Its amazing how often these issues are overlooked. Protecting user credentials There is no reason for storing passwords in plaintext biggest fail we see in the news coming out of a breach Tell vendors the product is a no go unless passwords are stored as properly salted hashes LinkedIn Password management Enforcement of good password policy If I am doing a vulnerability assessment and the client provides me as the password it sets off some flags How are passwords recovered/changed? Session Management Can an attacker hijack a users session? When users disconnect are they logged out correctly, This is a common issue I see with CAS integrated applications, users click the log out button but it doesn t kill the CAS session so they are still logged into the application and even worse the central login system. Bad for public computers Sessions should have timeouts 14

16 Session tokens should be rotated often and hard to predict Encrypted in transit via SSL 14

17 15

18 Step 1: Avoid vulnerabilities in the first place, we do this by, Starting with your developers Present to them on these vulnerabilities Resources on secure coding OWASP is for developers too outlines secure coding practices Mozilla has developed a nice and concise set of guidelines es Frameworks, language, CMS, product specific best practice Much easier/cheaper to build in secure coding at the start Finding the problems after and remediation will kill your project timelines, increase your budget or worse release a vulnerable application Training Google Code University Google Gruyere (Personal Favorite) SANS SANS offers free secure coding assessments for your developers to complete Secure Coding Courses 16

19 Veracode E-Learning Free intro course and paid courses for developers/it security professionals Specific Language Body eg. Zend - PHP Testing Get developers involved in testing their code Provide them testing tools, automate where possible Allow them to run basic tools, goal is not to make them pentesters but to identify low hanging fruit 16

20 Further to the point, here are some remediation time averages for 20 web applications. Denim Group took 20 web applications, the vulnerabilities found and average time to fix Source: 17

21 Talk with the vendor Tenders At Memorial all tenders for web applications include a clause to require approval from the IT security group as well as remediating issues found during any testing we carry out at no additional cost Work with your procurement person so that no tenders get by without such a clause Previous VA work Ask vendors for previous VA reports, gives you a starting point and reduce the amount of testing needed Internal coding practices Do they implement secure coding practices internally? Are their developers trained in secure coding practices or hold any certifications Remediation time- Managing client expectations Whenever dealing with a client department in a project ensure that timelines include vendor remediation time which I have seen be from days to months depending on the vendor 18

22 Develop a web application testing process When should an application be tested? Currently at Memorial applications that need to be externally accessible and/or access sensitive must be tested Major revisions or updates to an application require further testing Develop consistent set of tests to be completed based on the application or data, allow for variation based on the application as well Factor in testing and remediation times into any timelines you provide clients Web app VA testing can cause damage to the application or data or even leave the application more vulnerable, always use a test environment or have really good backups Assess the application and data involved Set a scope based on Data involved High profile Number of users Aim to find and remediate the major issues You can t expect a vendor/developer to fix every issue before production aim for the major issues and the quick wins 19

23 Map the application Work with the client to understand how the application works Determine different user roles (unauthenticated, basic user, power user, admin) Take this information and approach the application as if you were an attacker Look for problems in how the application works, logic flaws, automated scanners will not find these problems Search Google and Exploit-DB for known vulnerabilities If you identify an application is not patched to the latest version send it back to the vendor/client to be updated 20

24 Now we get to the tools! Spidering and Proxies Using these tools you map the application even further Manually move through the application first Then have the tool find anything you missed 21

25 Burp Suite Is a desktop web proxy that intercepts and allows you to modify browser traffic Spiders the application You can configure how forms are handles, provide credentials Allows automatic and manual active scanning Can do custom payloads Test session token randomization Can easily repeat an attack New features all the time Awesome Reporting Provides levels of criticality and certainty $300 for full version, not free but cheap for what it does, biggest problem with purchasing is explaining what portswigger is Free version allows for spidering and manual testing 22

26 I use this for everything web app related, its also good for malware analysis! 23

27 Zed Attack Proxy Great open source alternative to Burp Active scanning is not as accurate or robust Reporting is very well done Developed by OWASP Something our developers use Where it is open source and fairly quick to learn we have our developers test their code with ZAP in a sandbox 24

28 25

29 Skipfish - Active web application scanner Open source, developed by Google s Michal Zalewski (Genius) Blog - Super fast capable of thousands of requests per second, may take down server if not careful Advanced site crawler Uses a basic dictionary and builds upon it by looking at web application content Finds parts of the application that would be missed by other tools Broad active scanning 26

30 Screenshot of skipfish a great day for science result 27

31 Confirm and test everything you found so far If you found a file upload feature try uploading executable code If Burp/ZAP found a SQL injection see if you can dump the database or execute a command Lots more tools based on the what you found Samurai WTF - Web App focused pentest distribution and tool kit Developed by Kevin Johnson and Justin Searle Every tool I talked about is on this distribution Backtrack Offensive Security All around pentest live CD includes a lot more then just web application tools Why are we doing this? The main reason we do exploitation is to demonstrate that a vulnerability is exploitable The first false positive you send to a vendor or developer you will get blow back, you don t know what your talking about, the rest of the report does in the trash If you can confirm a vulnerability is exploitable great put emphasis on it, if you can t exploit it document it and ask the vendor/developer to see if they can determine why we are seeing this behavior Another reason is to determine the impact of a vulnerability, can an attacker actually use it to do harm? 28

32 Finally, it is sometimes necessary to demonstrate to a client exploitation of a vulnerability to understand why it should be remediated 28

33 SQLMap Exploit SQL injection Million times faster then by hand Multiple database support Oracle, MySQL, MSSQL, Postgres Input from Burp Import possible SQL injections found in Burp Blind SQL injection Time based and other methods Command Line Various levels of aggressiveness/risk Lots of extras Search Google for known SQL injections Upload a reverse shell Dump the database 29

34 Each tool shown has a reporting option Some allow for summaries or detailed reports or saved states, keep them all Developers/vendor may need them for reference Gather everything together Summarize Major vulnerabilities Low hanging fruit/quick wins Disclosure Be careful when disclosing your report, it is very sensitive information Should only go to the developer or vendor With open source projects identify the proper disclosure process, DO NOT POST PUBLICALLY! If you find a large number of a type of vulnerability it may indicate an underlying problem with the applications development, release specific examples but not all Reason is that you may have missed certain instances of a vulnerability and if you give the vendor/developer all specific examples they may fix them up without fixing the root cause Ask them to review the entire application for coding practices that result in that vulnerability type 30

35 Purposely Vulnerable Applications Google Gruyere - Damn Vulnerable Web App - Multidae - Trustwave SpiderLabs XSS/SQLi Testbeds - Open Source Applications Help secure open source apps Use old versions PHPMyAdmin, PHPBB, Wordpress 31

36 32

37 33

38 34