Presentation on theme: "Authors: Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh, Vitaly Shmatikov By Jeremiah O’Connor."— Presentation transcript:
Authors: Martin Georgiev, Subodh Iyengar, Suman Jana, Rishita Anubhai, Dan Boneh, Vitaly Shmatikov By Jeremiah O’Connor
Background Focus specifically non-browser software SSL validation is defective in many applications and libraries where security is essential: List of vulnerable software: Amazon’s EC2 Java library (&& related cloud clients) Amazon’s and PayPal’s merchant SDKs Integrated shopping carts Android apps and libraries (Big surprise here) Java Web-services middleware Codehaus XFire, and Pusher library for Android (&& all applications employing this middleware) All of the above vulnerable to MiM Problem: poorly designed APIs of SSL implementations (ex. JSSE, OpenSSL, GnuTLS) and data-transport libraries (ex. cURL) Analyze shortcomings of SSL certificate validation in software based on these APIs, make own suggestions
Introduction SSL is widely used in non-browser software whenever a secure Internet connection is needed Examples: (1) sending local data to cloud-based storage (2) sending customers’ payment details from E-Commerce servers to payment processors (ex. PayPal and Amazon) (3) logging IM clients into online services (4) authenticating servers to mobile applications on Android and iOS. These programs do not implement SSL themselves, rather they rely outside libraries Authenticating Server important part of SSL connection Authentication occurs during SSL handshake, when server hands over public key certiﬁcate. For SSL connection to be secure, client must verify the certiﬁcate has been issued by a valid CA Verifications for certificate: Not expired/ revoked Name in certificate matches name of domain client is connecting to, perform several other checks
Authors’ Contributions Authors conduct an in-depth study of SSL connection authentication in non-browser software, focusing on how different applications and libraries on Linux, Windows, Android, and iOS validate SSL server certificate Black-Hat && White-Hat techniques Primary conclusion of article is that SSL certificate validation is defective in important software applications and libraries. Vulnerabilities exploited are errors in logic in Client SSL certificate validation Main problem is poor design of APIs to the SSL libraries API libraries are confusing, developers often misuse, and in some cases introduce new vulnerabilities themselves
Outline of Study Results Study uncovered an array of SSL Certificate Validation bugs Certificate validation bugs run rampant in merchant software development kits, that run on E-Commerce servers (ex. online stores) and responsible for sending customers’ financial information to payment processing gateways. Scary Surprise: Devastating bugs in Chase Mobile Banking App for Android SSL connections that are established in this paper are vulnerable to authors’ active MiM attack (Threat Model)
Causes Generally, the SSL libraries in these programs are used correctly. However, often in the final product SSL certificate validation is defective/ disabled. Why? Primary cause: developer’s misunderstanding of the numerous options, parameters, and return values of SSL libraries Developers often misinterpret security guarantees provided by SSL libraries. Other bugs include using incorrect regular expressions for hostname matching, not checking the results of certificate validation correctly, accidentally or intentionally disabling certificate validation
Lessons 1. Study uncovered poor vulnerability testing even for important software such as mobile banking apps and merchant SDKs (responsible for managing secure connections to payment processors) 2. SSL libraries unsafe by default, need better software to correctly set options, provide hostname verification functions, and interpret return values 3. Default Safe libraries, ex. cURL’s wrapper around OpenSSL often misused by developers Easily misinterpret the meaning of various parameters Better documentation and annotation of API semantics High-level vs. low-level 4. SSL bugs hidden inside many layers of middleware Hard to locate and fix for developer 5. Disabling certificate validation by developers Tell users SSL is supported on high level, but failure to disclose there is no protection against active attacks
Authors’ Threat Model Assumptions: Man-in-the-Middle attacker May control network routers or switches, Wi-Fi access points, and/or DNS. May control one or more servers and have valid SSL certificates for servers Attacker (1) No access to private keys of valid servers (2) No control of any certificate authorities (3) Cannot forge certificates
Authors SSL Certificate Validation Model SSL connection starts with handshake between client and server (Figure 1) Authors specifically focus on the client’s validation of the server certificate. Tests used X.509 certificates Chain of Trust Verification Each X.509 certiﬁcate has an “issuer” field which has name of certificate authority (CA) that issued the certificate. Every SSL client is set up with a list of certificates for trusted CAs. Hostname Verification. After chain of trust is established, client must verify server’s identity. If client ﬁnds an exact match in the list of server identiﬁers, veriﬁcation is done by string comparison. Certiﬁcate revocation and X.509 extensions. Authors focus on verifying the server’s identity, but full certiﬁcate validation involves many more checks. Checks are essential for security, but handled poorly or not at all by non-browser software
SSL Libraries OpenSSL Hostname verification must be managed by the application itself, or by data-transport wrapper (ex. cURL) JSSE (Java Secure Socket Extension) Uses insecure low-level API SSLSocketFactory Depending on implementation of SSL client, this API may or may not perform hostname veriﬁcation
Data Transport Libraries Apache HttpClient: Uses JSSE’s insecure SSLSocketFactory Weberknecht: Java implementation of WebSockets protocol Uses insecure SSLSocketFactory, but does not perform own hostname veriﬁcation. Vulnerable to MiM attack cURL: a library allows you to make HTTP requests in PHP connect and communicate to many different types of servers with many different types of protocols. In updated version, cURL validates SSL certiﬁcates by default. Interface is horrible! Ex. VERIFYPEER parameter is a boolean, similar VERIFYHOST parameter is an integer Wide misunderstanding of parameters PHP: many ways to make SSL connection Widely used fsockopen does not perform any certiﬁcate checks whatsoever Python- Python modules can be used for SSL connection establishment urllib, urllib2, and httplib connect to SSL servers but do not check certiﬁcates
SSL uses in Non-Browser Software Cloud Client APIs operators supply client SDKs through which 3 rd party software can forward user data to cloud-based storage, manage cloud- based computation, and access other cloud services (ex. Apache Libcloud) Merchant Payment SDKs Merchant software uses libraries to send customers’ payment details and/or receive notiﬁcations when customer makes payment See Figure 4 on next page Web-services middleware Middleware most often uses SSL but allocates SSL connection responsibility to Data Transport Library ex. Apache HttpClient or Weberknecht Mobile Advertising Connection from application provider’s site to AdMob server contains provider’s credentials and must be protected by SSL.
MISUNDERSTANDING THE SSL API Amazon Flexible Payments Service (PHP) PHP version of the FPS SDK uses a wrapper around the libcurl library) to establish an SSL connection to the payment gateway. Vulnerable to MiM PayPal Payments Standard and PayPal Invoicing (PHP) Any PHP code using these PayPal-provided SDKs to make an SSL connection to PayPal’s payment processing gateway is insecure against a man-in-the-middle attack PayPal IPN in ZenCart Huge misunderstanding of cURL’s parameters. Disables certiﬁcate validation entirely Lynx - text-based (often used by other software) Hostname veriﬁcation correct, but chain-of-trust veriﬁcation defective Apache HttpClient Apache HttpClient 3 accepts any certiﬁcate with a valid chain of trust, regardless of the name. Bugs in updated version 4 also. Trillian- popular IM client, relies on OpenSSL to make SSL connection Accepts any SSL certiﬁcate and is insecure against a man-in-the-middle attack. Rackspace- app for iOS, open-source application for managing cloud services Insecure against MiM TextSecure- is an Android application for encrypting SMS (text) and MMS(text, video, pictures, etc.) messages. SSL certiﬁcate validation vulnerabilities
Using Insecure Middleware Web Service software relies on middleware libraries to facilitate network connections. Apache Axis, Axis 2, Codehaus Xfire use: SSLSocketFactory for SSL connection SSL vulnerabilities caused by bugs in Web-services middleware found in Amazon libraries. Pusher WebSocket-based API that offers real-time messaging functionality to mobile and Web applications. Pusher’s Android libraries use Weberknecht Vulnerable to MiM Overall, SSL functionality inside these libraries is unclear to the app developers
Insecure SSL Libraries PHP fsockopen does not validate SSL certiﬁcates, often used by applications that should be secure against a man-in-the-middle attack. Ex. PayPal’s IPN (instant payment notification) utility contains this code: Included in code in PayPal payment modules for ZenCart, PrestaShop shopping carts PrestaShop uses fsockopen in its CanadaPost payment module also Other vulnerable software includes Open Source classifieds Python’s URL libraries do not validate certiﬁcates but developers still use them for SSL connections. Tweepy a library for accessing Twitter API utilizes httplib Mozilla’s Zamboni project accepts contributions for extension developers and uses urllib2 to connect to PayPal
BREAKING OR DISABLING Breaking or Disabling Certificate Validation Sometimes developer’s answer to problems with SSL Libraries is to disable proper certiﬁcate validation Bad security practices used where protection against MiM attack is essential, and SSL certificate validation is necessary “Tutorial: Disabling Certificate Validation in an HTTPS Connection... Reply: Thank you very much. You solved my biggest problem in the project.” “I have always turned off CURLOPT_SSL_VERIFYPEER in curl.” “I am using axis on java to consume a webservice. The web service is in https, and I want to avoid the check for certiﬁcate.”
Breaking or Disabling Certificate Validation (Others) Amazon Elastic Load Balancing API Tools X509TrustManager Disable hostname verification Shopping carts osCommerce, ZenCart, Ubercart, and PrestaShop are open- source shopping carts (PHP) Use cURL for SSL connections to payment Gateways, if cURL not available, fall back on insecure Fsockopen AdMob: provides sample code to mobile site owners that they can use on their servers to associate instances of their mobile apps with their developer accounts Vulnerable to MiM attack Android apps Groupon Redemptions, Breezy, ACRA vulnerable to MiM AIM accept certiﬁcates signed by untrusted authorities. No hostname veriﬁcation FilesAnywhere- is an application for managing cloud storage. When presented with third-party certiﬁcate, accepts it and sends user’s data to a wrong/ potentially malicious server.
Chase Mobile Banking SSL connections established by Android Mobile App. vulnerable to Man-in-the-Middle Attacks Allows a network attacker to capture username and password and rest of session customer using the app * Unreachable code. temporary plug during development, in final version of app., returns without checking server’s certificate
Apache LibCloud Python library extension providing support for 26 different cloud service providers Libcloud depends on the Python library (uses OpenSSL) to verify the chain of trust in SSL certificates Code uses an in- correct regular expression for hostname verification For example: it accepts oogle.com as a match for google.com, exposing all Libcloud clients to a man-in-the-middle attack:
Recommendations It is inevitable Application developers will grapple with SSL, and standard SSL libraries Common for developers of high-security software to use standard SSL libraries incorrectly. Do’s and Dont’s: For Application developers: DO use better testing against different types of certificates (black-box) DON’T disable certiﬁcate validation for testing with self-signed and/or untrusted certiﬁcates. DON’T depend on the library’s defaults to set up secure SSL connection For SSL Library Developers: DO improve documentation in SSL libraries APIs. DON’T make applications responsible for SSL connections DO design better error reporting interface.
Conclusion: Using SSL in non-browser software is a tough task Paper shows applications that depend on standard SSL libraries such as JSSE, OpenSSL, GnuTLS, etc. often accomplish SSL Certificate Validation incorrectly or not at all. Future research directions include (1) develop better black-box testing and code analysis tools to identify errors in logic when making SSL connection (2) develop better verification techniques and programming language support for making sure applications correctly use SSL Libraries in order to better understand important options and parameters (3) develop better APIs for SSL and other secure networking protocols.