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
 Certificateis 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 null-
terminated)
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, Firefox, Opera, Safari, and Chrome
are
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
 “ExploitingFirefox 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
 Securitya 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