Measuring Breaches of Trust in the Windows Code-Signing PKI
Total Page:16
File Type:pdf, Size:1020Kb
Load more
										Recommended publications
									
								- 
												  Scripting – Windows Powershell – Part 5CNT 4603: System Administration Spring 2012 Scripting – Windows PowerShell – Part 5 Instructor : Dr. Mark Llewellyn [email protected] HEC 236, 4078-823-2790 http://www.cs.ucf.edu/courses/cnt4603/spr2012 Department of Electrical Engineering and Computer Science Computer Science Division University of Central Florida CNT 4603: Scripting – Windows PowerShell – Part 5 Page 1 Dr. Mark Llewellyn © Code Signing • In the second set of notes on PowerShell we discussed the execution policy which is part of the security built-in to PowerShell. • We modified PowerShell’s default setting of Restricted, which prevents PowerShell from running any scripts (it is restricted to running in an interactive mode only). • We changed the setting using the set-executionpolicy cmdlet to RemoteSigned, which allowed locally created scripts to be loaded and executed without being digitally signed. • The other two options are: AllSigned, which is a notch under Restricted, in that all scripts must be digitally signed by a publisher you trust in order to be loaded and executed. The Unrestricted option allows any script to be executed but for non-local scripts the user is prompted for an action. CNT 4603: Scripting – Windows PowerShell – Part 5 Page 2 Dr. Mark Llewellyn © Code Signing • In short code signing is the process of digitally signing scripts, executables, dynamic link libraries (DLLs), and so forth to establish a level of trust for the code. • The trust granted to digitally signed code is based on two assumptions. – One, a signed piece of code ensures that the code hasn’t been altered or corrupted since being signed. – Two, the digital signature serves to prove the identity of the code’s author, which helps you to determine whether the code is safe for execution.
- 
												  Certified Malware: Measuring Breaches of Trust in the Windows Code-Signing PKICertified Malware: Measuring Breaches of Trust in the Windows Code-Signing PKI Doowon Kim Bum Jun Kwon Tudor Dumitras, University of Maryland University of Maryland University of Maryland College Park, MD College Park, MD College Park, MD [email protected] [email protected] [email protected] ABSTRACT To establish trust in third-party software, we currently rely on Digitally signed malware can bypass system protection mechanisms the code-signing Public Key Infrastructure (PKI). This infrastruc- that install or launch only programs with valid signatures. It can ture includes Certification Authorities (CAs) that issue certificates also evade anti-virus programs, which often forego scanning signed to software publishers, vouching for their identity. Publishers use binaries. Known from advanced threats such as Stuxnet and Flame, these certificates to sign the software they release, and users rely this type of abuse has not been measured systematically in the on these signatures to decide which software packages to trust broader malware landscape. In particular, the methods, effective- (rather than maintaining a list of trusted packages). If adversaries ness window, and security implications of code-signing PKI abuse can compromise code signing certificates, this has severe impli- are not well understood. We propose a threat model that highlights cations for end-host security. Signed malware can bypass system three types of weaknesses in the code-signing PKI. We overcome protection mechanisms that install or launch only programs with challenges specific to code-signing measurements by introducing valid signatures, and it can evade anti-virus programs, which often techniques for prioritizing the collection of code-signing certificates neglect to scan signed binaries.
- 
												  Security Economics in the HTTPS Value ChainSecurity Economics in the HTTPS Value Chain Hadi Asghari*, Michel J.G. van Eeten*, Axel M. Arnbak+ & Nico A.N.M. van Eijk+1 * [email protected], [email protected] Delft University of Technology, Faculty of Technology Policy and Management + [email protected], [email protected] University van Amsterdam, Faculty of Law, Institute for Information Law Abstract. Even though we increasingly rely on HTTPS to secure Internet communications, several landmark incidents in recent years have illustrated that its security is deeply flawed. We present an extensive multi-disciplinary analysis that examines how the systemic vulnerabilities of the HTTPS authentication model could be addressed. We conceptualize the security issues from the perspective of the HTTPS value chain. We then discuss the breaches at several Certificate Authorities (CAs). Next, we explore the security incentives of CAs via the empirical analysis of the market for SSL certificates, based on the SSL Observatory dataset. This uncovers a surprising pattern: there is no race to the bottom. Rather, we find a highly concentrated market with very large price differences among suppliers and limited price competition. We explain this pattern and explore what it tells us about the security incentives of CAs, including how market leaders seem to benefit from the status quo. In light of these findings, we look at regulatory and technical proposals to address the systemic vulnerabilities in the HTTPS value chain, in particular the EU eSignatures proposal that seeks to strictly regulate HTTPS communications. Keywords: HTTPS, Cybersecurity, Internet Governance, Constitutional Values, E-Commerce, Value Chain Analysis, Security Economics, eSignatures Regulation, SSL, TLS, Digital Certificates, Certificate Authorities.
- 
												  Code Signing Requirements 2015-11-19Draft of Final Forum Guideline Version 1.0 Draft of November 19, 2015 CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates Copyright © 2015, The CA/Browser Forum, all rights reserved. Verbatim copying and distribution of this entire document is permitted in any medium without royalty, provided this notice is preserved. The CA/Browser Forum participants grant you a license to reproduce, distribute, make derivative works and display this entire document in any medium without royalty, provided this notice is preserved. If you make a translation of this document, we request that you prominently display the following statement in the language of the translation: “This document is a translation of the original English version. If a discrepancy arises between interpretations of this version and the original English version, the original English version governs.” i Draft of Final Forum Guideline Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates Version 1.0, as adopted by the CA/Browser Forum on nn aaa nnnn. These requirements describe an integrated set of technologies, protocols, identity-proofing, lifecycle management, and auditing requirements that are minimum standards for the issuance and management of Code-Signing Certificates that are trusted because their corresponding Root Certificate is distributed in widely-available application software. These Requirements are not mandatory for Certification Authorities unless and until they become adopted and enforced by an Application Software Supplier. Notice to Readers This version of the Baseline Requirements for the Issuance and Management of Publicly-Trusted Code Signing Certificates presents criteria established by the CA/Browser Forum for use by Certification Authorities when issuing, maintaining, and revoking publicly-trusted Code Signing Certificates.
- 
												  TR-4569: Security Hardening Guide for Netapp ONTAP 9Technical Report Security Hardening Guide for NetApp ONTAP 9 Guidelines for Secure Deployment of ONTAP 9 Product Security Team, NetApp December 2020 | TR-4569 Abstract This technical report provides guidance and configuration settings for NetApp® ONTAP® 9 to help organizations meet prescribed security objectives for information system confidentiality, integrity, and availability. TABLE OF CONTENTS Introduction ................................................................................................................................................. 4 ONTAP image validation ............................................................................................................................ 4 Upgrade image validation ........................................................................................................................................ 4 Boot-time image validation ...................................................................................................................................... 4 Local storage administrator accounts ...................................................................................................... 4 Roles, applications, and authentication ................................................................................................................... 4 Default administrative accounts ............................................................................................................................... 7 Certificate-based API access..................................................................................................................................
- 
												  Measuring Revocation Effectiveness in the Windows CodeThe Broken Shield: Measuring Revocation Effectiveness in the Windows Code-Signing PKI Doowon Kim and Bum Jun Kwon, University of Maryland, College Park; Kristián Kozák, Masaryk University, Czech Republic; Christopher Gates, Symantec; Tudor Dumitras, University of Maryland, College Park https://www.usenix.org/conference/usenixsecurity18/presentation/kim This paper is included in the Proceedings of the 27th USENIX Security Symposium. August 15–17, 2018 • Baltimore, MD, USA ISBN 978-1-939133-04-5 Open access to the Proceedings of the 27th USENIX Security Symposium is sponsored by USENIX. The Broken Shield: Measuring Revocation Effectiveness in the Windows Code-Signing PKI Doowon Kim Bum Jun Kwon Kristian´ Kozak´ University of Maryland University of Maryland Masaryk University Christopher Gates Tudor Dumitras, Symantec Research Labs University of Maryland Abstract code. A common security policy is to trust executables that carry valid signatures from unsuspicious publishers. Recent measurement studies have highlighted security The premise for trusting these executables is that the threats against the code-signing public key infrastructure signing keys are not controlled by malicious actors. (PKI), such as certificates that had been compromised Unfortunately, anecdotal evidence and recent measure- or issued directly to the malware authors. The primary ments of the Windows code-signing ecosystem have doc- mechanism for mitigating these threats is to revoke the umented cases of signed malware [8, 9, 12, 23, 26] and abusive certificates. However, the distributed yet closed potentially unwanted programs (PUPs) [1, 13, 17, 28], nature of the code signing PKI makes it difficult to evalu- where the trusted certificates were either compromised ate the effectiveness of revocations in this ecosystem.
- 
												  PKI Under AttackDEVELOPING AND CONNECTING ISSA CYBERSECURITY LEADERS GLOBALLY PKI Under Attack By Jeff Stapleton – ISSA member, Fort Worth, USA Chapter In the September 2012 ISSA Journal, the author looked at a concise history of public key infrastructure and mentioned several Certificate Authority compromise incidents from 2011. This trend seems to be continuing as PKI continues to be under attack. This article explores various PKI vulnerabilities. PKI and SSL framework n the September 2012 ISSA Journal, we looked at a con- cise history of public key in- Ifrastructure (PKI) and mentioned several Certificate Authority (CA) compromise incidents from 2011. This trend seems to be continuing as PKI continues to be under attack. To explore this further, let’s first establish a typical PKI framework, shown in figure 1, to discuss the various vulnerability points and attack vectors. For Figure 1 – PKI and SSL framework this discussion we will focus on a secure socket layer (SSL) [1] scenario which includes a CA consisting of a root certificate of the Red subordinate CA. The Blue root CA typi- (Blue) and two subordinates (Red and Green), a server (S), cally operates in an offline manual mode, and does not issue and the relying parties consisting of the browser manufactur- any other certificates, except possibly to other Red peer-level er (M) and the browser (B). The most common PKI and SSL subordinate CAs not shown. Note that most root CAs have option is using the RSA algorithm for server-side certificates. numerous sub-CAs dedicated to various PKI techniques and As a quick refresher, the browser recognizes the SSL certifi- usage (e.g., RSA keys, other asymmetric algorithms, SSL, cate sent to it by the server.
- 
												  Globalsign Certificate PolicyGlobalSign Certificate Policy Date: September 25, 2019 Effective date for Qualified Time Stamping, Qualified Web Authentication Certificates, Qualified Certificates for Electronic Signatures and Qualified Certificates for Electronic Seals: {normal date + 2 weeks} Version: v6.2 Table of Contents TABLE OF CONTENTS ................................................................................................................................ 2 DOCUMENT HISTORY ............................................................................................................................... 8 ACKNOWLEDGMENTS .............................................................................................................................10 1.0 INTRODUCTION ...........................................................................................................................11 1.1 OVERVIEW ........................................................................................................................................ 11 Additional requirements for Trusted Root Issuer CAs ............................................................ 13 1.2 DOCUMENT NAME AND IDENTIFICATION ................................................................................................. 13 1.3 PKI PARTICIPANTS .............................................................................................................................. 15 Certification Authorities (“Issuer CAs”) .................................................................................
- 
												  Don't Root Robots: Breaks in Google's Android PlatformDON'T ROOT ROBOTS! - BSides Detroit 2011 Slide # 1 A TEAM JOCH Production Jon Oberheide + Zach Lanier = TEAM JOCH DON'T ROOT ROBOTS! - BSides Detroit 2011 Slide # 2 DON'T DATE ROBOTS! DON'T ROOT ROBOTS! - BSides Detroit 2011 Slide # 3 Agenda • Overview • Escalation • Delivery • Persistence DON'T ROOT ROBOTS! - BSides Detroit 2011 Slide # 4 Kill All Humans! What's in an Android? DON'T ROOT ROBOTS! - BSides Detroit 2011 Slide # 5 Android at a Glance • Base platform – ARM core – Linux 2.6.3x kernel • Native libraries – libc, Webkit, etc • Dalvik VM – Register-based VM – Runs dex bytecode • Applications – Developed in Java – Run on Dalvik VM – Linux process 1:1 DON'T ROOT ROBOTS! - BSides Detroit 2011 Permission-Based Model • Apps explicitly request pre-defined permissions • Examples: – Cellular: calls, SMS, MMS – Network, Bluetooth, WiFi – Hardware: vibrate, backlight – Location: coarse, fine – App data: contacts, calendars DON'T ROOT ROBOTS! - BSides Detroit 2011 App Sandboxing • “Sandboxed” by standard UNIX uid/gid – Generated unique per app at install time • High-level permissions restricted by Android runtime framework DON'T ROOT ROBOTS! - BSides Detroit 2011 App Distribution • Application signing – Self-signed by developers • Android Market – $25 signup, anyone can publish – Anonymous sign-up is possible DON'T ROOT ROBOTS! - BSides Detroit 2011 Agenda • Overview • Escalation • Delivery • Persistence DON'T ROOT ROBOTS! - BSides Detroit 2011 Slide # 10 DON'T ROOT ROBOTS! Why root your Android? DON'T ROOT ROBOTS! - BSides Detroit 2011 Slide # 11 Android Jailbreaks • Jailbreaks can be “GOOD” – Allow custom firmwares, etc – Great for power users, hobbyists • Jailbreaks can be “BAD” – Essentially a privilege escalation – Leveraged by malware to rootkit your device – eg.
- 
												  Apple Inc. Certification Authority Certification Practice Statement Worldwide Developer RelationsWWDR Certification Practice Statement Version 1.17 Mar 20, 2017 Apple Inc. Certification Authority Certification Practice Statement Worldwide Developer Relations Version 1.17 Effective Date: March 20, 2017 WWDR Certification Practice Statement Version 1.17 Mar 20, 2017 Table of Contents 1. Introduction ................................................................................... 6 1.1. Trademarks ....................................................................................................... 6 1.2. Table of acronyms ............................................................................................. 6 1.3. Definitions .......................................................................................................... 6 2. General business practices .............................................................. 7 2.1. Identification ...................................................................................................... 7 2.2. Community and applicability ............................................................................. 7 2.2.1. iOS Development Certificates ....................................................................... 8 2.2.2. iOS Submission Certificates .......................................................................... 8 2.2.3. Development Client SSL Certificates ............................................................ 8 2.2.4. Production Client SSL Certificates ................................................................ 9 2.2.5. Push CSR Signing Certificates
- 
												  Globalsign Certification Practice StatementGlobalSign Certification Practice Statement Date: December 29, 2020 Effective date for Qualified Timestamping, Qualified Web Authentication Certificates, Qualified Certificates for Electronic Signatures and Qualified Certificates for Electronic Seals: {normal date + 2 weeks} Version: v9.6 Table of Contents TABLE OF CONTENTS ................................................................................................................................ 2 DOCUMENT HISTORY ............................................................................................................................... 8 ACKNOWLEDGMENTS .............................................................................................................................10 1.0 INTRODUCTION ...........................................................................................................................11 1.1 OVERVIEW ........................................................................................................................................ 12 1.1.1 Certificate Naming ................................................................................................................. 15 1.2 DOCUMENT NAME AND IDENTIFICATION ................................................................................................. 17 1.3 PKI PARTICIPANTS .............................................................................................................................. 22 1.3.1 Certification Authorities ........................................................................................................
- 
												  NIST SP 1800-16B: Securing Web Transactions: TLS Server Certificate Management INIST SPECIAL PUBLICATION 1800-16 Securing Web Transactions TLS Server Certificate Management Includes Executive Summary (A); Security Risks and Recommended Best Practices (B); Approach, Architecture, and Security Characteristics (C); and How-To Guides (D) Mehwish Akram Alexandros Kapasouris William C. Barker Dung Lam Rob Clatterbuck Brett Pleasant Donna Dodson Mary Raguso Brandon Everhart Murugiah Souppaya Jane Gilbert Susan Symington William Haag Paul Turner Brian Johnson Clint Wilson FINAL This publication is available free of charge from: http://doi.org/10.6028/NIST.SP.1800-16 The first draft of this publication is available free of charge from: https://www.nccoe.nist.gov/projects/building-blocks/tls-server-certificate-management NIST SPECIAL PUBLICATION 1800-16 Securing Web Transactions: TLS Server Certificate Management Includes Executive Summary (A); Security Risks and Recommended Best Practices (B); Approach, Architecture, and Security Characteristics (C); How-To Guides (D) Donna Dodson Clint Wilson William Haag DigiCert Murugiah Souppaya NIST Paul Turner Dung Lam Venafi F5 William C. Barker Alexandros Kapasouris Strativia Symantec Mehwish Akram Rob Clatterbuck Brandon Everhart Jane Gilbert Brian Johnson Thales Trusted Cyber Brett Pleasant Technologies Mary Raguso Susan Symington The MITRE Corporation June 2020 U.S. Department of Commerce Wilbur Ross, Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Undersecretary of Commerce for Standards and Technology NIST SPECIAL PUBLICATION 1800-16A