DOCSLIB.ORG

Breaking Best Practice Protection of the TLS Protocol in an Android

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Breaking Best Practice Protection of the TLS Protocol in an Android Introduction Breaking best practice protection of the TLS protocol in an Android environment 2020-05-11 Version 1.0 Author Supervisor C.A.L. Mandjes F. de Korte Master student Radboud University Northwave Red team [email protected] [email protected] Supervisor Second reader Prof. dr. E. Verheul Dr. ir. E. Poll Radboud University Radboud University [email protected] [email protected] 1 Introduction Abstract Northwave’s Red team performs penetration testing on Android applications for its customers. As part of this test, the tester analyzes the data which is being transmitted between the application and its backend server. However, many applications are using the Transport Layer Security (TLS) protocol, which is an encryption protocol, with the certificate pinning technique implemented. In order to set up a man-in-the-middle attack, Northwave was using a tool called the Android-SSL-Trustkiller. This tool disables the certificate pinning technique so that a man- in-the-middle position can be deployed. However, the Android-SSL-Trustkiller is not working when the targeted Android application is using the SafetyNet Attestation service. Therefore, the goal of this research project is to find a new way to break the protection of the data sent in a TLS session, with certificate pinning and SafetyNet Attestation service implemented, in an Android environment. The SafetyNet Attestation service is an anti-abuse system that focusses on the integrity of the Android application and the Android device which it is running on. As part of the integrity checks on the Android device, it can detect whether a device is rooted. The Android-SSL-Trustkiller requires a rooted Android device; this is one of the reasons why this approach is not working when the targeted Android application is using the SafetyNet Attestation service. This research project proposes a solution, called the Android-CertificatePinning-Killer, to bypass certificate pinning for an Android application by deploying code modification at run- time. The Android-CertificatePinning-Killer can bypass the following certificate pinning libraries: Android’s default library and the OKHttp library. Since the SafetyNet Attestation service can detect rooted Android devices, several experiments are performed to bypass this service. In these experiments, the two root implementations, system and systemless root, are assessed to bypass the SafetyNet Attestation service. Based on the performed experiments, it can be concluded that the rooted OnePlus 3T Android device could not be detected by SafetyNet’s device integrity checks when it is using systemless root. 2 Introduction Contents 1 INTRODUCTION ...................................................................................................................... 7 1.1 CONTEXT ....................................................................................................................................................................7 1.2 PROBLEM DESCRIPTION ...............................................................................................................................................7 1.3 RESEARCH QUESTION ..................................................................................................................................................8 1.4 APPROACH .................................................................................................................................................................8 1.5 OUTLINE.....................................................................................................................................................................9 2 TRANSPORT LAYER SECURITY PROTOCOL .................................................................................. 11 2.1 INTRODUCTION ........................................................................................................................................................ 11 2.2 HISTORY .................................................................................................................................................................. 11 2.3 PROTOCOLS ............................................................................................................................................................. 11 2.3.1 TLS Record protocol....................................................................................................................................... 12 2.3.2 TLS Handshake protocol ............................................................................................................................... 14 2.3.3 TLS Change Cipher Spec protocol................................................................................................................ 17 2.3.4 TLS Alert protocol........................................................................................................................................... 18 2.3.5 TLS Application Data protocol ..................................................................................................................... 18 2.4 SECURITY CONTROLS ................................................................................................................................................ 19 2.4.1 Confidentiality ................................................................................................................................................ 19 2.4.2 Integrity ........................................................................................................................................................... 19 2.4.3 Authentication................................................................................................................................................ 19 2.4.4 Forward secrecy ............................................................................................................................................. 19 2.5 PROTOCOL WEAKNESSES .......................................................................................................................................... 20 2.5.1 Cryptographic aspects .................................................................................................................................. 20 2.5.2 Version aspects .............................................................................................................................................. 21 2.5.3 Implementation aspects ............................................................................................................................... 21 3 DIGITAL CERTIFICATES............................................................................................................ 24 3.1 INTRODUCTION ........................................................................................................................................................ 24 3.2 CERTIFICATE AUTHORITY........................................................................................................................................... 24 3.2.1 Chain of trust .................................................................................................................................................. 25 3.2.2 Baselines.......................................................................................................................................................... 25 3.3 X.509 STANDARD .................................................................................................................................................... 27 3.3.1 Certificate format .......................................................................................................................................... 27 3.3.2 Additional extensions and techniques ....................................................................................................... 28 3.4 CERTIFICATE VALIDATION.......................................................................................................................................... 30 3.4.1 Certification path processing ....................................................................................................................... 30 3.4.2 HTTP Public Key Pinning ............................................................................................................................... 31 3.4.3 Certificate pinning ......................................................................................................................................... 32 4 CERTIFICATE PINNING IMPLEMENTATION ................................................................................. 34 4.1 INTRODUCTION ........................................................................................................................................................ 34 4.2 ANDROID TLS IMPLEMENTATION.............................................................................................................................. 35 4.3 ANDROID CERTIFICATE PINNING IMPLEMENTATION .................................................................................................... 36 4.4 IOS IMPLEMENTATION ............................................................................................................................................. 38 5 ANDROID SAFETYNET SERVICE ................................................................................................ 40 5.1 INTRODUCTION .......................................................................................................................................................
Load more

Recommended publications
  • Test Coverage Guide
    TEST COVERAGE GUIDE Test Coverage Guide A Blueprint for Strategic Mobile & Web Testing SUMMER 2021 1 www.perfecto.io TEST COVERAGE GUIDE ‘WHAT SHOULD I BE TESTING RIGHT NOW?’ Our customers often come to Perfecto testing experts with a few crucial questions: What combination of devices, browsers, and operating systems should we be testing against right now? What updates should we be planning for in the future? This guide provides data to help you answer those questions. Because no single data source tells the full story, we’ve combined exclusive Perfecto data and global mobile market usage data to provide a benchmark of devices, web browsers, and user conditions to test on — so you can make strategic decisions about test coverage across mobile and web applications. CONTENTS 3 Putting Coverage Data Into Practice MOBILE RECOMMENDATIONS 6 Market Share by Country 8 Device Index by Country 18 Mobile Release Calendar WEB & OS RECOMMENDATIONS 20 Market Share by Country 21 Browser Index by Desktop OS 22 Web Release Calendar 23 About Perfecto 2 www.perfecto.io TEST COVERAGE GUIDE DATA INTO PRACTICE How can the coverage data be applied to real-world executions? Here are five considerations when assessing size, capacity, and the right platform coverage in a mobile test lab. Optimize Your Lab Configuration Balance Data & Analysis With Risk Combine data in this guide with your own Bundle in test data parameters (like number of tests, analysis and risk assessment to decide whether test duration, and required execution time). These to start testing with the Essential, Enhanced, or parameters provide the actual time a full- cycle or Extended mobile coverage buckets.
    [Show full text]
  • Measuring the Rapid Growth of HSTS and HPKP Deployments
    Measuring the Rapid Growth of HSTS and HPKP Deployments Ivan Petrov∗ Denis Peskov∗ Gregory Coard∗ Taejoong Chungy David Choffnesy Dave Levin∗ Bruce M. Maggsz Alan Mislovey Christo Wilsony ∗ University of Maryland yNortheastern University zDuke University & Akamai Technologies ABSTRACT version of the website, thereby exposing future commu- A basic man-in-the-middle attack to bypass HTTPS strips nication to the MiTM attacker, as well. Second, if an the “s” off of an “https://” URL, thereby forcing the client attacker is able to have a certificate created in someone to effectively downgrade to an insecure connection. To ad- else's name, the attacker can impersonate that victim dress such crude attacks, the HSTS (HTTP Strict Transport domain. Security) protocol was recently introduced, which instructs Both of these attacks completely sidestep the protec- clients to preemptively (or at time of first acquire) load a tions that TLS seeks to provide to its users. To address list of domains to whom to connect strictly via HTTPS. In a these concerns, two recent additions to HTTPS have similar vein, the HPKP (HTTP Public Key Pinning) protocol been introduced. We describe them in detail in Sec- has clients obtain a set of public keys; if in future visits to tion 2, but at a high level: the website the certificate chain does not include any of those • HTTP Strict Transport Security public keys, the client is supposed to reject the connection. (HSTS) [10] addresses SSL stripping attacks by Both HSTS and HPKP are relatively new additions to the informing clients which domains it should connect web’s PKI that have seen a sudden surge in deployment in to strictly over HTTPS (i.e., if presented with an the last couple of years (we observe an order of magnitude http URL to one of these domains, they should greater deployment than a 2015 study of HSTS/HPKP).
    [Show full text]
  • Comptia Security+ 501
    CompTIA Security+ 501 CompTIA Security+ SY0-501 Instructor: Ron Woerner, CISSP, CISM CompTIA Security+ Domain 6 – Cryptography & PKI 6.4 Given a scenario, implement public key infrastructure Cybrary - Ron Woerner 1 CompTIA Security+ 501 6.4 Public-Key Infrastructure (PKI) ● Components ● Types of certificates ○ Public / Private Key ○ User ○ Certificate ○ Root ○ CA ○ Wildcard ○ CRL ○ SAN ○ Code signing ● Concepts ○ Self-signed ○ Online vs Offline CA ○ Machine/computer ○ Stapling ○ Domain validation ○ Pinning ○ Trust model ● Certificate formats ○ Key escrow ○ Certificate chaining Public and Private Keys ● Encrypt a document with the recipient’s public key. Only their private key needs to be kept secret and only it can decrypt the message ● The sender’s private key is used to sign the message Cybrary - Ron Woerner 2 CompTIA Security+ 501 PKI Components Public Key Infrastructure ● Solves the issues with key management ● A set of roles, policies, and procedures needed to manage public- key(asymmetric) encryption ● The process of creating, managing, distributing, storing, using, and revoke keys and digital certificates. ● Public Key Infrastructure X.509 (PKIX) is the working group formed by the IETF to develop standards and models PKI PKI Components - Digital Certificate ● A digitally signed block of data used to prove the ownership of a public key issued by a Certificate Authority ● Includes ○ information about the key, ○ information about the identity of its owner (called the subject), ○ and the digital signature of an entity that has verified the certificate's contents (called the issuer) ● X.509 v3 standard defines the certificate formats and fields for public keys. Cybrary - Ron Woerner 3 CompTIA Security+ 501 Digital Certificate Components X.509 Certificate Types ● Root certificates: for root authorities.
    [Show full text]
  • Oneplus 6T User Manual Index
    OnePlus 6T User Manual Index 04 What’s in The Box? 24 Notch Display Settings 05 Device 25 OnePlus Fast Charging 06 Power On 26 OxygenOS 07 Setup Wizard 27 Launcher 08 Migrating Data (OnePlus Switch) 28 App Drawer 09 Insert SIM Card (SIM Card Tray) 29 Hidden Space 10 Screen Unlock 30 Notification Shade 11 Face Unlock 31 Shelf 12 Alert Slider 32 Gestures 13 Camera 33 App Long Press 14 Camera Interface 34 Reading Mode 15 Choosing Camera Modes and Settings 35 Gaming mode 16 Studio Lighting 36 Dialer 17 Nightscape 37 Messenger 18 Portrait Mode 38 Gallery 19 Video 39 Recorder 20 Video Editor 40 File Manager 21 Pro Mode 41 App Permission 22 Pro Mode - Continued 23 Optic AMOLED Display 2 Welcome Thank You! We believe in sharing the best technology, designed to be fast, smooth, and user-centric. The OnePlus 6T offers a fast and smooth experience, with an emphasis on speed. Navigating between apps, photos and games is now easier than it’s ever been. With speed at the center of its design, the OnePlus 6T now ensures that your time receives its optimum value. With our continued attention to improve swift and smooth transitions based on a sense of speed, the OnePlus 6T is our fastest product yet. A beautiful combination of sophisticated hardware and software allows you to experience speed like you’ve never done before. 3 What’s in The Box OnePlus 6T Screen Protector Translucent Case USB Type-C Cable Power Adapter SIM Tray Ejector Quick Start Guide USB Type-C 3.5mm (pre-applied) Safety Information Adapter 4 | What’s in the Box Device OxygenOS Device Alert Slider Nano SIM Slot Volume Power Sleep/Wake USB Type-C 5 | What’s in the Box Device OxygenOS Power On Turn on your OnePlus 6T by pressing and holding the <Power> button (found on the right side of the phone) for a few seconds.
    [Show full text]
  • Layered Mobile Device Architecture
    ISSN (e): 2250 – 3005 || Volume, 08 || Issue,10|| October – 2018 || International Journal of Computational Engineering Research (IJCER) Layered Mobile Device Architecture 1Shinto Kurian 2Dr.K.Nirmala K, Research Scholar(Reg.No:PhD/10/PTE/1/2017, Madras University), Quaid-E-Millath College for Women, Chennai - 600 002, Tamilnadu,India. Assoc. Professor,Dept. of Computer Science, Quaid-E-Millath College for Women, Chennai - 600 002, Tamilnadu,India Corresponding Author: Shinto Kurian ABSTRACT Mobile device structure is organised in a layered architecture from electronic components to application user interface. Based on various functionalities, the mobile devices are separated into multiple layers. Each layer has well defined boundaries and interacts with each other using certain protocols. The layered separation helps the devices to segregate the functionalities in stabilized and secured manner. Depending on manufacture, the components in each layer change. Most of the mobile devices are follow a standard architecture but the components and methodologies used in each layer have differences. The degree of smoothness between the layers directly proportionate with user friendliness of the mobile device. KEYWORDS: Mobile Device, Operating system, Software, Hardware, BIOS, Firmware, User Interface. ----------------------------------------------------------------------------------------------------------------------------- ---------- Date of Submission: 15-12-2018 Date of acceptance: 31-12-2018 ---------------------------------------------------------------------------------------------------------------------------------------------------
    [Show full text]
  • An Empirical Analysis of Email Delivery Security
    Neither Snow Nor Rain Nor MITM . An Empirical Analysis of Email Delivery Security Zakir Durumeric† David Adrian† Ariana Mirian† James Kasten† Elie Bursztein‡ Nicolas Lidzborski‡ Kurt Thomas‡ Vijay Eranti‡ Michael Bailey§ J. Alex Halderman† † University of Michigan ‡ Google, Inc. § University of Illinois, Urbana Champaign {zakir, davadria, amirian, jdkasten, jhalderm}@umich.edu {elieb, nlidz, kurtthomas, vijaye}@google.com [email protected] ABSTRACT tolerate unprotected communication at the expense of user security. The SMTP protocol is responsible for carrying some of users’ most Equally problematic, users face a medium that fails to alert clients intimate communication, but like other Internet protocols, authen- when messages traverse an insecure path and that lacks a mechanism tication and confidentiality were added only as an afterthought. In to enforce strict transport security. this work, we present the first report on global adoption rates of In this work, we measure the global adoption of SMTP security SMTP security extensions, including: STARTTLS, SPF, DKIM, and extensions and the resulting impact on end users. Our study draws DMARC. We present data from two perspectives: SMTP server from two unique perspectives: longitudinal SMTP connection logs configurations for the Alexa Top Million domains, and over a year spanning from January 2014 to April 2015 for Gmail, one of the of SMTP connections to and from Gmail. We find that the top mail world’s largest mail providers; and a snapshot of SMTP server providers (e.g., Gmail, Yahoo,
    [Show full text]
  • Devices, the Weak Link in Achieving an Open Internet
    Smartphones, tablets, voice assistants... DEVICES, THE WEAK LINK IN ACHIEVING AN OPEN INTERNET Report on their limitations and proposals for corrective measures French République February 2018 Devices, the weak link in achieving an open internet Content 1 Introduction ..................................................................................................................................... 5 2 End-user devices’ possible or probable evolution .......................................................................... 7 2.1 Different development models for the main internet access devices .................................... 7 2.1.1 Increasingly mobile internet access in France, and in Europe, controlled by two main players 7 2.1.2 In China, mobile internet access from the onset, with a larger selection of smartphones .................................................................................................................................. 12 2.2 Features that could prove decisive in users’ choice of an internet access device ................ 14 2.2.1 Artificial intelligence, an additional level of intelligence in devices .............................. 14 2.2.2 Voice assistance, a feature designed to simplify commands ........................................ 15 2.2.3 Mobile payment: an indispensable feature for smartphones? ..................................... 15 2.2.4 Virtual reality and augmented reality, mere goodies or future must-haves for devices? 17 2.2.5 Advent of thin client devices: giving the cloud a bigger role?
    [Show full text]
  • Introduction À La Sécurité Des Systèmes D'informations
    Université de Paris Saclay Polytech Paris Saclay – Département d’informatique Introduction à la sécurité des systèmes d’informations Document réalisé par : Polytech Paris Saclay Département d’informatique Université Paris Saclay Maison de l'Ingénieur Bâtiment 620 91405 Orsay Cedex Gilles Soufflet, Ingénieur Système Version janvier 2020 Université de Paris Saclay Sécurité informatique Polytech Paris Saclay – Département d’informatique Table des matières 1 Avant-propos ________________________________________________________________ 7 2 Notions de cryptographie _____________________________________________________ 10 2.1 Introduction _________________________________________________________________ 10 2.1.1 Principe de Kerckhoffs _______________________________________________________________ 10 2.2 Fonctions de hachage __________________________________________________________ 11 2.2.1 MD5 _____________________________________________________________________________ 11 2.2.2 SHA-1 ____________________________________________________________________________ 12 2.2.3 SHA-2 ____________________________________________________________________________ 12 2.2.4 SHA-3 ____________________________________________________________________________ 13 2.2.5 Whirpool __________________________________________________________________________ 13 2.3 Cryptographie à masque jetable _________________________________________________ 13 2.4 Cryptographie symétrique ou à clé secrète ________________________________________ 14 2.4.1 Chiffrement par bloc _________________________________________________________________
    [Show full text]
  • End User License Agreement
    DATED ------------ OXYGENOS END-USER LICENCE AGREEMENT between END-USER and ONEPLUS TECHNOLOGY (SHENZHEN) CO., LTD. CONTENTS CLAUSE 1. Acknowledgements ....................................................................................................... 1 2. Grant and scope of licence ............................................................................................ 3 3. Licence restrictions ........................................................................................................ 3 4. 6 9. Communication between us .......................................................................................... 7 10. [Events outside our control ............................................................................................ 7 11. Other important terms ................................................................................................... 8 THIS AGREEMENT is dated [DATE] PLEASE READ CAREFULLY BEFORE DOWNLOADING OR STREAMING THE OXYGENOSFROM THIS WEBSITE. This end-user licence agreement (EULA) is a legal agreement between you (End-user or you) and OnePlus Technology (Shenzhen) Co., Ltd. (Licensor, us or we) for: OxygenOS mobile software, the data supplied with the software, and the associated media (App); and Electronic documents (Documents). We license use of the OxygenOS and Documents to you on the basis of this EULA and subject to any rules or policies applied by any Google Play provider or operator from whose site, located at www.oneplus.net (Google Play), the End-user downloaded the OxygenOS
    [Show full text]
  • Oneplus 2 User Manual Index
    OnePlus 2 User Manual Index 03 Welcome Page 10 USB Type-C Port & Charging 11 Power On 04 What’s in The Box? 12 OxygenOS 05 The Device 13 App Permissions 06 Alert Slider 14 Customization 07 Fingerprint Sensor 15 Messaging 08 Back Cover 16 Making a Call 09 Dual SIM Card Tray 17 Camera & Photos Thank you! The OnePlus 2 is the result of our hard work in trying to meet the steep expectations held by our users and community, of us. We promised to deliver an amazing amalgamation of mobile hardware, software and experience, and we want to thank all of you for pushing us to keep this promise. We truly couldn’t have offered the best mobile experience out there, without your help. What’s in The Box OnePlus 2 Charger USB Data & User Guide Charging Cable Quick Start Guide 4 | What’s in the box Device OxygenOS Camera Dual Nano SIM Slot Alert Slider Volume IR Laser Focus Power Sleep/Wake StyleSwap Cover Release Home/Fingerprint Sensor 5 | What’s in the box Device OxygenOS Alert Slider None Disable all notifications from all contacts The Alert Slider allows you to effortlessly switch between 3 (Alarm notifications will still be enabled). notification profiles without having to take the phone out of your pocket. Priority Receive notifications from only your priority contacts. All Receive notifications from all your contacts. 6 | What’s in the box Device OxygenOS Fingerprint Sensor Quickly and securely unlock your OnePlus 2 with a simple press. It can store up to 5 unique fingerprint profiles.
    [Show full text]
  • State of the SSL/ TLS Industry Where Are We Today / Future Trends & Changes by Jay Schiavo
    State of the SSL/ TLS Industry Where Are We Today / Future Trends & Changes By Jay Schiavo © 2016 Entrust Datacard Corporation. All rights reserved. AGENDA • SSL/TLS History • State of the Industry Today • Technologies to Consider • Questions? 2 © 2016 Entrust Datacard Corporation. All rights reserved. SSL/TLS History 3 © 2016 Entrust Datacard Corporation. All rights reserved. SSL MARKET HISTORY 1998 2005 2012 2016 • VeriSign, Entrust, • VeriSign (acquired • Symantec (acquired • Symantec (acquired Thawte, GlobalSign Thawte), Entrust, Thawte and Thawte and GeoTrust, Comodo, GeoTrust), Entrust, GeoTrust), Entrust, • OV SSL GoDaddy Comodo, GoDaddy, Comodo, GoDaddy, Digicert, GlobalSign Digicert, GlobalSign, • E-Commerce • OV SSL, DV SSL Let’s Encrypt, AWS • EV SSL, OV SSL, DV • No governance • E-Commerce and SSL, Multi-Domain • EV SSL, OV SSL, DV protecting sensitive SSL, Cert Mgmt SSL, Multi-Domain data SSL, Cert Mgmt, • E-Commerce and Other Services • CA/Browser Forum protecting sensitive data, Logins, • Encryption Webmail everywhere • EV & SSL Baseline • Browsers enforcing Reqs proper SSL issuance and deployment © Entrust Datacard Corporation. All rights reserved. CHANGING TECHNOLOGIES Endured three certificate-based migrations 1. MD2 and MD5 to SHA-1 2. Small RSA keys to 2048-bit keys or larger 3. SHA-1 to SHA-256 • Additionally: – Encryption levels have changed from 40 bit to 128 bit to 256 bit – SSL protocol to TLS protocol (current version is 1.2) • SSL 2.0 and 3.0 no longer supported in modern browsers • TLS 1.0 and 1.1 are showing some cracks • TLS 1.2 is most secure protocol • TLS 1.3 has not yet been released • What’s next – ECC, RSA 3072, CT for all TLS/SSL © Entrust Datacard Corporation.
    [Show full text]
  • Let's Encrypt
    Let’s Encrypt Die neue Sicherheit für Jeden Inhaltsverzeichnis 1 Let’s Encrypt 1 1.1 Überblick ............................................... 1 1.2 Beteiligte ............................................... 1 1.3 Technik ................................................ 2 1.3.1 Protokoll ........................................... 2 1.3.2 Server-Implementierung ................................... 2 1.3.3 Clients ............................................ 2 1.4 Geschichte und Zeitplan ....................................... 3 1.5 Siehe auch .............................................. 4 1.6 Weblinks ............................................... 4 1.7 Quellen ................................................ 4 2 Extended-Validation-Zertifikat 6 2.1 Motivation .............................................. 7 2.2 Benutzerschnittstelle ......................................... 7 2.2.1 Browserunterstützung .................................... 7 2.3 Vergabekriterien ........................................... 7 2.4 Weblinks ............................................... 8 2.5 Einzelnachweise ............................................ 8 3 X.509 9 3.1 Geschichte .............................................. 9 3.2 Zertifikate ............................................... 9 3.2.1 Struktur eines X.509-v3-Zertifikats ............................. 9 3.2.2 Erweiterungen ........................................ 10 3.2.3 Dateinamenserweiterungen für Zertifikate .......................... 11 3.3 Beispiel für ein X.509-Zertifikat ..................................
    [Show full text]