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