Owasp Mobile Risk Series : M3 : Insufficient Transport Layer Protection
A presentation at OWASP local chapter meet in 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
This Session will focus on Mobile Top 10 2014-M3 : Insufficient Transport Layer protection. We will try to understand Transport Layer, Transport layer security (TLS), insecurities in TLS/SSL, and how this affects the overall security of Mobile Devices as well as what kind of protection can be applied and how this can be identified..
Resources
The following resources were mentioned during the presentation or are useful additional information.
