Dc206 Best Of Blackhat And Defcon 2009

THE BEST OF BLACKHAT 2009 & DEFCON 17

Grant Bugher 8/17/2009

Agenda

About the Conferences What’s Not New XSRF (McRee, Bailey, Hamiel, Moyer) Business Logic Flaws (Grossman, Ford) De-Anonymization (RSnake)

What’s New SSL Exploits (Kaminsky, Marlinspike, Zusman) Cloud Computing Exploits (iSec, SensePost) Firefox Addon Exploits (Freeman, Liverani)

About the Conferences BlackHat Briefings 2009

Professional security conference Training sessions followed by short presentations and tradeshow

DefCon 17 Informal gathering of hackers No tradeshow; many short presentations Many people don’t even attend presentations Contests and villages

What’s Not New  The

same old threats are still 95% of web application security SQL and Other Injection Attacks Cross-Site Scripting (XSS) Cross-Site Request Forgery (CSRF) Business Logic Flaws

Cross-Site Request Forgery

 “CSRF:

Yeah, It Still Works,” Russ McRee & Mike Bailey  “Weaponizing the Web,” Nathan Hamiel & Shawn Moyer  Many recent attacks StrongWebmail.com McAfee Secure Web Scanner Linksys routers

Cross-Site Request Forgery

 More

recent attacks

osCommerce and ZenCart cPanel and WHM (it’s a feature!) Marblecake, Also The Game

 Advanced

Dynamic CSRF

MonkeyFist (http://hexsec.com/labs)

Cross-Site Request Forgery

 Defenses

that Don’t Work

Require POST Check Referrer Require Multiple Steps URL Rewriting

 Defenses

that Do Work

Good CAPTCHAs Re-authentication Dynamic canary

Business Logic Flaws  “Mo’

money, Mo’ Problems,” Jeremiah Grossman and Trey Ford  Non-Technical Hacks eBay Holiday Doorbusters Hacker Croll’s Twitter Hack Cookie stuffing & link manufacture Google Earth Recon iPod Advance Replacements Tunecore iTunes/Amazon Fraud

De-Anonymization  “De-Anonymizing

You,” Rsnake  Variety of methods tried for anonymity Anonymous proxies (CGI, SOCKS) Free email Hacked machines Onion routing (TOR), anonymous remailers

 Sites

try to track and identify you anyway

De-Anonymization  SSL Client certificate identifies system name, OS,

username, certificate dates

 Browser

Detection Tools (MrT, BeEF)

Enumerate plugins, history, screen resolution,

VMware detection, keylogging…

 IP

Detection

Java, Flash, Word, Acrobat bugs scp: and itms: protocol handlers

De-Anonymization  File

system enumeration

res:// timing attack, SMBenum (in BeEF)

 Google

Safe Browsing

Sends a unique ID automatically, 30 times an

hour, and obeys proxy settings Can get all IP history for that cookie with a subpoena Google Chrome sends machine/user ID every 5 hours

De-Anonymization  Onion

Routing Attacks

TOR actually works very well, albeit very

slowly Compromised exit nodes get lots of data ○ Not very targeted ○ Selected for confidentiality, though

Trojaned TOR clients on user machines HackedTor.exe runs a malicious exit node

SSL Exploits  Multiple

BlackHat & DefCon talks about attacks on SSL Dan Kaminsky, “Black Ops of PKI” Moxie Marlinspike, “More Tricks for Defeating

SSL” Mike Zusman, “Criminal Charges Were Not Pursued: Hacking PKI”  More

interesting in combination than individually

SSL Exploits  SSL

based on X.509 certificate PKI  Server presents a leaf certificate… …which is signed by an intermediate cert… …which is signed by one of the root CAs

intrinsically trusted by your browser.  Any

intermediate cert can sign any leaf

Intermediates can also sign each other

Certificate Authorities  Anyone

can run a CA, but to be trusted by browsers, it must chain to a trusted root  Certificate signing is not exclusionary Any root can sign any certificate Any signed intermediate certificate can sign

any certificate, too

 This

means there are 4,500 organizations that can sign a cert for your bank’s web site

Weak Cryptography on CAs



A VeriSign root certificate was self-signed with MD2 Actually no good reason to self-sign at all MD2 subject to preimage attack ○ Complexity of attack is 273 ○ Current crypto attacks are up to 263



RapidSSL intermediate certificate was signed with MD5 Researchers created an intermediate certificate

with a chosen prefix attack

PKCS#10 Certificate Signing

 How

do you get a certificate?

Go to any CA Submit a request in a binary protocol called

PKCS#10 Give them money  Certificate

is created automatically based on data in the PKCS#10 package  Protocol is old and eccentric

PKCS#10 Certificate Signing

 Domain

specified as a “Common Name”  CN identifier (2.5.4.3) followed by Pascal string (length-content, not nullterminated) 02 05 04 03 [length] [bytes]

 Protocol

is remarkably fragile

Multiple CNs in one packet? 2.5.4.03? 2.5.4.(264+3)? Invalid characters in the CN? Null bytes?

Pascal and C Strings  IA5String (Pascal String) [length] [bytes] ○ “Hello World” ○ 11 48 65 6C 6C 32 57 6F 72 6C 64 ○ Length is fixed; bytes can be anything  C String [bytes] [null terminator] ○ “Hello World” ○ 48 65 6C 6C 32 57 6F 72 6C 64 00 ○ Length is unlimited; bytes can’t be null

Certificate Validation  Domain

Validation for SSL certificates

Send a certificate signing request (PCKS#10)

to a CA CA emails the contact address in WHOIS Answer the email, and the CA signs the cer  Can

only register a certificate for a domain I own in WHOIS

Null Prefix Attack I can get a cert for perimetergrid.com (it’s registered to me)  I can’t get a cert for login.live.com  What about login.live.com\0.perimetergrid.com? 

Perfectly valid Pascal string in PCKS#10 ○ 33 6C 6F 67 69 6E 2E 6C 69 76 65 2E 63 6F 6D 00 2E 70 65 72 69 6D 65 74 65 72 67 72 69 64 2E 63 6F 6D Rather different as a C string ○ 6C 6F 67 69 6E 2E 6C 69 76 65 2E 63 6F 6D 00

Browsers Are Written in C

 IE,

are

Firefox, Opera, Safari, and Chrome

A = login.live.com\0.perimetergrid.com B = login.live.com

 In C… strlen(A) == 14, strlen(B) == 14 strcmp(A,B) == 0 sprintf(A) == “login.live.com”  Indistinguishable in all standard

functions

Browser Issues  Null

byte issues

*\0.perimetergrid.com

 Inconsistent

Treatment of multiple CNs

First CN? Last? All of them?

 No

warnings for DV->EV transition  BasicConstraints sometimes ignored  OCSP Protocol Flaws  Remote exploit the browser in the CN!

CA Issues  About

4,500 CAs chain to a valid root  Not all of them have strong security Each CA responsible for domain validation Some will sign null-byte certificates Web flaws can let you spoof email addresses For that matter, DV all depends on email Comodo will make you a CA for $200 ○ An intermediate certificate of your very own ○ Want a certificate for “*”?

The Net Result 

Moxie’s sslsniff 0.6 Automatic silent MitM attacks on all sessions ○ Firefox, IE, Chrome, Thunderbird, Outlook, Evolution, Pidgin, AIM, irssi, all CryptoAPI apps ○ Anything built on NSS, GnuTLS, CryptoAPI – VPNs! Signs with null prefix, * cert, basicConstraints Shuts down OCSP with ARP spoofing Hijacks autoupdates Authority & targeted modes



No safe way to use SSL on open WiFi

EV Will Save Us?  EV

(Extended Validation) certificates are not issued automatically Human validation of certificate request ID checks, documentation, etc. Green bar in the browser

 EV

certificates are not exclusionary  No warning switching from DV to EV  Zusman’s SSL rebinding (sslstrip)

SSL Rebinding Demo

http://stub.bz/sslrebinding/

SSL Rebinding Demo

Cloud Computing Issues

 Multiple

presentations, a full track at BlackHat

2009 “Raining on the Trendy New Parade,” Alex Stamos,

Andrew Becherer, Nathon Wilcox (iSec Partners) “Clobbering the Cloud,” Haroon Meer, Nick Advanitis, Marco Slaviero (SensePost)  Mostly

issues with the cloud model in general  Some specific attacks on Amazon Web Services, particularly EC2

Cloud Computing

 Outsource your IT to a technology company! They probably have more security experts than you

do. But you also get to outsource all your data

 What could possibly go wrong? Perimeter control, endpoint management,

multifactor authentication, credential quality controls, password reset process, realtime anomaly detection, logging & auditing If someone can read your email, they control your entire datacenter

Legal Concerns

 Liability

EULAs promise nothing, disclaim everything Forbids malicious traffic, even yours

 Search

and Seizure

No Constitutional protection Statutory protection only for “communications” No warrants, probable cause, notice ○ Can’t fight seizure before it happens ○ Google promises to notify in case of a seizure…  …if not forbidden to by law…  …and their EULA says they won’t.

EC2 Issues

 Amazon Web Services Most-used IaaS cloud platform Likely the major alternative to Windows Azure  Elastic Compute Cluster (EC2) Based on a modified Xen hypervisor 47 Amazon-provided VM images 72,000 user-provided VM images  DevPay Can make custom images & charge others for their

use

EC2 Issues

 Scanning is prohibited But you can scan through an SSH tunnel Or just have the VM scan itself  Issues with Amazon’s images 646 Nessus Critical vulnerabilities Can steal Amazon’s Windows license keys  Issues with user-provided images All sorts of cruft in them…like credentials Can alter DevPay information in the manifest

EC2 Issues

 Pre-Owned

Virtual Machines!

Create a new, free image with a good name ○ “Ubuntu 9.04, Official, All Patches” Add your own Trojan horses Register repeatedly until you have a good AMI Profit!

 Using

Cloud Services for Evil

Flexible, inexpensive, scalable spam servers Botnet-in-a-box with a stolen credit card

Entropic Principles

 Cryptography relies on randomness Computers are deterministic Randomness comes from the physical world  Entropy Pools Keyboard input & mouse movement Block device events Saved entropy pool on disk  None of these exist in the cloud Don’t run your poker server in EC2 or Azure Quantum-based RNG service in the cloud?

Firefox Addon Exploits

 “Exploiting

Firefox Addons,” Nick Freeman, Roberto Liverani  Firefox Extensions Extend, modify, and control browser behavior

 Components XUL – XML User Interface Language XBL – XML Binding Language XPCOM – Cross-platform Component Object Model XPConnect – XPCOM JavaScript interface

Firefox Addon Exploits

 Addon Security Model None. Can modify each other or the system at will XPCOM can be extended in C++  Human Factors Addons are trusted implicitly by users ○ Even unsigned ones NoScript and AdBlockPlus do nothing addons.mozilla.org reviews addons… ○ But experimental addons are publicly available, ○ and they look for maliciousness, not vulnerability.

Addon Vulnerabilities

 XUL

and XBL are markup, like HTML  Addons get data from web pages  Cross-site scripting into chrome:// URLs? Yes! And it’s arbitrary native code execution!

 Updates are not reviewed Bait and switch attacks, as with Facebook apps DNS or MitM attacks

Are Addons Exploitable?



Skype

XSS: make arbitrary phone calls



CoolPreviews XSS: execute arbitrary code



UpdateScanner XSS: execute arbitrary code with JS events



FireFTP XSS: Evaluates the banner in the chrome



FeedSidebar XSS: IFRAMES in RSS description



ScribeFire XSS: Executes events on images

Developer Awareness

 Security

a totally new idea for most addon developers No established process No contact information for disclosures

 Need

to follow web security practices  Code signing needs to be enforced Browser should require it Don’t download unknown addons

 Remember

this for other gadget architectures!

Conclusions

 Another

year, another vulnerability  X.509 fundamentally flawed Non-exclusionary DNSSEC the only fix for SSL ○ It’s only been around for 15 years No way to browse securely on open WiFi ○ And most WiFi is open WiFi

 Cloud

is still too new to predict

Q&A

Q&A