1
2
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
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: http://www.darkreading.com/database-security/167901020/security/news/240001240/u-of-nebraska-breach-highlights-education-in-crosshairs.html If you want to track published university breaches Softpedia and DataLossDB are good sources to follow. • http://datalossdb.org • http://news.softpedia.com/newsTag/university+site
4
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
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
https://www.owasp.org/
7
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. https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
8
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
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
Bobby Tables
11
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
• I have recently been testing http://code.google.com/p/domsnitch/ 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
13
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
12345 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
• Session tokens should be rotated often and hard to predict • Encrypted in transit via SSL
14
15
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 • https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelin
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)
• http://google-gruyere.appspot.com/ SANS
• SANS offers free secure coding assessments for your developers to complete
• Secure Coding Courses • http://software-security.sans.org/courses/assessment
16
Veracode E-Learning • Free intro course and paid courses for developers/IT security
professionals • http://www.veracode.com/products/veracode-elearning-
curriculum.html 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
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: http://www.slideshare.net/denimgroup/owasp-san-antonio-march
17
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
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
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
• http://www.exploit-db.com/ • If you identify an application is not patched to the latest version send
it back to the vendor/client to be updated
20
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
Burp Suite http://portswigger.net/burp/
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
I use this for everything web app related, its also good for malware analysis!
23
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 • http://code.google.com/p/zaproxy/
• 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
25
Skipfish - http://code.google.com/p/skipfish/ Active web application scanner Open source, developed by Google’s Michal Zalewski (Genius) Blog - http://lcamtuf.coredump.cx/ 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
Screenshot of skipfish a great day for science result
27
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 - http://samurai.inguardians.com/ • 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 http://www.backtrack-linux.org/ • 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
• Finally, it is sometimes necessary to demonstrate to a client exploitation of a vulnerability to understand why it should be remediated
28
SQLMap http://sqlmap.sourceforge.net/
• 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
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
Purposely Vulnerable Applications Google Gruyere - http://google-gruyere.appspot.com/ Damn Vulnerable Web App - http://www.dvwa.co.uk/ Multidae - http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10 Trustwave SpiderLabs – XSS/SQLi Testbeds - https://github.com/SpiderLabs
Open Source Applications Help secure open source apps Use old versions – PHPMyAdmin, PHPBB, Wordpress
31
32
33
34