Owasp Mobile Risk Series : M3 : Insufficient Transport Layer Protection

A presentation at OWASP local chapter meet in September 2014 in Bengaluru, Karnataka, India by Anant Shrivastava

Slide 1

Slide 1

OWASP  Mobile  Top  10  Risk   M3  :  Insufficient  Transport  Layer   Protection   Anant Shrivastava

Slide 2

Slide 2

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.

Slide 3

Slide 3

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

Slide 4

Slide 4

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

Slide 5

Slide 5

TCP  Headers

Slide 6

Slide 6

UDP  Headers

Slide 7

Slide 7

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).

Slide 8

Slide 8

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

Slide 9

Slide 9

Various  Algorithms  in  use

Slide 10

Slide 10

Mobile  Prospective Data  in  transit  over   TCP  /  UDP

Slide 11

Slide 11

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

Slide 12

Slide 12

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?)

Slide 13

Slide 13

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)

Slide 14

Slide 14

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 • •

Slide 15

Slide 15

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.

Slide 16

Slide 16

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)

Slide 17

Slide 17

Preventions

Slide 18

Slide 18

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/ • • • • • • •

Slide 19

Slide 19

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

Slide 20

Slide 20

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

Slide 21

Slide 21

Question  Time