OWASP Mobile Top 10 Risk M3 : Insufficient Transport Layer Protection Anant Shrivastava
A presentation at OWASP local chapter meet in September 2014 in Bengaluru, Karnataka, India by Anant Shrivastava
OWASP Mobile Top 10 Risk M3 : Insufficient Transport Layer Protection Anant Shrivastava
About Me • • • • • Anant Shrivastava (@anantshri) http://www.anantshri.info Independent Information Security Consultant Focus Area’s : Web, Mobile, Linux Current Project: o CodeVigilant (codevigilant.com) • An initiative to find flaws in open source software and perform a responsible disclosure. Website currently holds 160+ disclosed vulnerability in various wordpress plugins. o Android Tamer (androidtamer.com) • Live ISO environment for Android Security Researchers. Used by multiple researchers as well as Trainers across the globe.
Agenda • Understand Transport Layer • Understand Transport Protections • Understand Complexities/Insecurities in transport layer protection. • How to Find Insecure or inadequate protections • How to Prevent it
Transport Layer • OSI Model Layer 4 (from bottom or top) • A transport layer provides end-to-end or host-tohost communication services for applications within a layered architecture of network components and protocols. • Protocols in Use : TCP and UDP • The transport layer is responsible for delivering data to the appropriate application process on the host computers • Unique Identifier : IP:Port (URI) • In short backbone of internet communication
TCP Headers
UDP Headers
Transport Layer Protections • Commonly known as Transport Layer Security (TLS) or formerly Secure Socket Layer (SSL) • Latest version in use TLSv1.2 • Commonly found: SSLv2, SSLv3/TLSv1.0,TLSv1.1 • Uses X509 Certificate based asymetric encryption. • What we generally know as HTTPS • TLS v1.3 in draft since July 2014. • first defined in 1999 and last updated in RFC 5246 (August 2008) and RFC 6176 (March 2011).
TLS Certificates • Issued by a CA (Certification Authority) • Follows a chain of trust to establish the identity of a website. • For internal purposes people use self-signed certificate which doesn’t following trusted chain. • Example of trusted chain @ google.com
Various Algorithms in use
Mobile Prospective Data in transit over TCP / UDP
Insecure implementations • Using Known Weak Ciphers / version (SSLv2, RC4, MD5, CBC in SSL3) • Communication using Self-signed certificate (ignoring warning) • Securing only specific portion of communication • Not validating the chain of trust • Mixxing TLS and non TLS content on Page
SSL Version 2 • SSL version 2 was designed in 1994 by Netscape. Its 20 years old this year. • Known attacks o Identical cryptographic keys are used for message authentication and encryption. o SSL 2.0 has a weak MAC construction that uses the MD5 hash function with a secret prefix, making it vulnerable to length extension attacks. o SSL 2.0 does not have any protection for the handshake, meaning a man-inthe-middle downgrade attack can go undetected. o SSL 2.0 uses the TCP connection close to indicate the end of data. This means that truncation attacks are possible: the attacker simply forges a TCP FIN, leaving the recipient unaware of an illegitimate end of data message (SSL 3.0 fixes this problem by having an explicit closure alert). o SSL 2.0 assumes a single service and a fixed domain certificate, which clashes with the standard feature of virtual hosting in Web servers. This means that most websites are practically impaired from using SSL • Blocked in most modern browsers (IE 6 users anyone?)
Other versions • SSLv3 (was working good till 2012) • SSL 3.0 cipher suites have a weaker key derivation process; half of the master key that is established is fully dependent on the MD5 hash function • More attacks o o o o o o Renegotiation attack BEAST attack CRIME and BREACH attacks Padding attacks (Lucky 13) RC4 Attacks Implementation bugs like (Apple SSL, Heartbleed, GNUTLS Fail)
Chain of trust • • Establish chain of trust Ensure the connection has exact same chain of trust as official certificate. Any certificate in the chain is self-signed, unless it the root. Not every intermediate certificate is checked, starting from the original certificate all the way up to the root certificate. • An intermediate, CA-signed certificate does not have the expected Basic Constraints or other important extensions. • The root certificate has been compromised or authorized to the wrong party. • Ref : http://cwe.mitre.org/data/definitions/296.html • •
Mixing content • HTTP and HTTPS content • HTTP can be cached and read over the wire. • Analytics and tracking generally use http for quick transaction and hence susceptible.
Detecting SSL issues • Launch emulator / start device. • Add proxy settings for burp/zap/ironwasp etc • Run application and check if traffic interception works and application performs its actions. (Implementation is flawed) • Identify end points • End point Implementation flaws : use SSLScan (either original or rbsec/sslscan at github)
Preventions
Preventions Assume connection is compromised Disable weak ciphers and versions Perform entire sensitive communication over TLS Never allow connection using Self-signed certificate. Use secure versions of tracking/analytics/ad network SDK Add a second layer of encryption for sensitive data. Follow Rules: https://www.owasp.org/index.php/ Transport_Layer_Protection_Cheat_Sheet • Perform certificate validation via Certificate pinning : refer http://www.thoughtcrime.org/blog/authenticity-isbroken-in-ssl-but-your-app-ha/ • • • • • • •
Preventions • iOS: For CFNetwork, use Secure Transport API to designate trusted client certificates • iOS: all NSURL calls (or wrappers of NSURL) do not allow self signed or invalid certificates such as the NSURL class method setAllowsAnyHTTPSCertificate. • iOS Cert Pinning : export your certificate, include it in your app bundle, and anchor it to your trust object. Using the NSURL method connection:willSendRequestForAuthenticationChallenge: will now accept your cert. • Android: ensure org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER are not present
References • https://en.wikipedia.org/wiki/Transport_layer • https://www.owasp.org/index.php/Mobile_Top_10_2014M3 • http://www2.dcsec.uni-hannover.de/files/android/p50fahl.pdf • TCP UDP Headers : http://nmap.org/book/tcpip-ref.html • https://commons.wikimedia.org/wiki/ File:Mobile_and_desktop_device_templates.svg • https://openclipart.org/collection/collection-detail/ silpstream/8546 • http://www.troyhunt.com/2013/06/understanding-risk-ofmixed-content.html
Question Time