Penetration Test Report (Doyensec): Doyensec SoloKeys Firmware Q12020

Security Auditing Report
SoloKeys Firmware
Prepared for: SoloKeys
Prepared by: Filippo Cremonese
Feb 7, 2020
WWW.DOYENSEC.COM © DOYENSEC
SoloKeys - Security Auditing Report
Table of Contents
Table of Contents 1
Revision History 2
Contacts 2
Executive Summary 3
Methodology 5
Project Findings 6
Appendix A - Vulnerability Classification 17
Appendix B - Remediation Checklist 18
Appendix C - Firmware Downgrade Proof of Concept 19
Appendix D - AFL Fuzzing Results 20
1 of 20 WWW.DOYENSEC.COM
SoloKeys - Security Auditing Report
Revision History
Version Date Description Author
1 Feb 1, 2020 First release of the final report Filippo Cremonese
2 Feb 5, 2020 Peer review Luca Carettoni
3 Feb 7, 2020 Peer review Lorenzo Stella
Contacts
Company Name Email
SoloKeys Emanuele Cesena ec@solokeys.com
SoloKeys Conor Patrick cp@solokeys.com
Doyensec, LLC Luca Carettoni luca@doyensec.com
Doyensec, LLC John Villamil john@doyensec.com
2 of 20 WWW.DOYENSEC.COM
SoloKeys - Security Auditing Report
Executive Summary
Hardware vulnerabilities and physical attacks
such as voltage glitching and timing/power side
Overview
channels were out-of-scope for this engagement.
SoloKeys engaged Doyensec to perform a The following components were included in the
security assessment of the SoloKeys software assessment on a best effort basis and were not
components. The project commenced on January extensively reviewed:
20, 2020, and ended on January 31, 2020,
requiring one security researcher. The project • NFC protocol support
resulted in three (3) findings of which one (1) was • External cryptographic libraries
rated as high severity. • External parsing libraries
• STM32 platform libraries
The project consisted of a manual security
assessment and fuzzing of the firmware running
Findings Summary
on the device.
Doyensec discovered and reported three (3)
Testing was conducted remotely from Doyensec
vulnerabilities in SoloKeys firmware. While two of
EMEA offices.
the issues are considered informational, one
issue has been rated as high severity. An
Scope
additional section (Appendix D) reports the
results of our fuzzing effort.
Through meetings with SoloKeys the scope of
the project was clearly defined. We list the agreed It is important to reiterate that this report
upon scope below: represents a snapshot of the security posture at
the time of testing.
• U2F/FIDO2 software layer
• Bootloader At the design level, Doyensec has found the
system to be well architected and adequate for
The testing was performed against the latest the threat model for which it was designed.
version of the software at the time of testing. In
detail, this activity was performed on the Recommendations
following releases:
The following recommendations are proposed
• Solo Firmware v3.0.1 (17b430fd4482) based on studying Solo security posture and
vulnerabilities discovered during this engagement.
This firmware is used across all SoloKeys
products (Solo, Somu) at the time of testing.
Short-term improvements
Scoping Restrictions • Work on mitigating the discovered
vulnerabilities. You can use Appendix B -
The engagement primarily focused on the attack Remediation Checklist to make sure that you
surface exposed to: have covered all areas
• remote attackers (browsers) • Integrate fuzzing testing into the software
• local attackers (compromised browser/OS) development lifecycle. The AFL-compatible
• physical attackers with limited capabilities fuzzing harness developed for this
3 of 20 WWW.DOYENSEC.COM
SoloKeys - Security Auditing Report
engagement can be used as a starting point
for subsequent security automation
enhancements. Further root cause analysis
work is also required for all crashes
discovered during this short engagement
Long-term improvements
• Perform a more comprehensive security
review of the components not audited during
this engagement. This would include auditing
the external cryptographic and parsing
libraries
• Evaluate currently unused security features
available on the STM32L432 processor, such
as the MPU
• Use formal techniques such as state
machines to model, document and review the
implementation of complex protocols and
interactions
• Expand the threat model to include advanced
physical attackers and implement appropriate
countermeasures. Research concerning the
security properties of STM32-based
platforms against glitching, side channels and
other techniques is available, hence SoloKeys
maintainers would need to investigate the
results and potentially develop mitigations for
such attacks
4 of 20 WWW.DOYENSEC.COM
SoloKeys - Security Auditing Report
Methodology
Auditing Approach
Overview
Doyensec strives to follow a methodic approach
Doyensec treats each engagement as a fluid
to source code review. We analyze all control flow
entity. We use a standard base of tools and
paths and the interactions between them, while
techniques from which we built our own unique
understanding and subverting the assumptions
methodology. Our 30 years of information security
on which the code is built upon. We study how
experience has taught us that mixing offensive
data is parsed, processed, stored, and relayed
and defensive philosophies is the key for standing
between producers and consumers.
against threats, thus we recommend a graybox
approach combining dynamic fault injection with
The WebAuthn and CTAP2 specifications were
an in-depth study of source code to maximize the
carefully studied and used as a reference while
ROI on bug hunting.
reviewing the Solo implementation, as well as the
STM32L432 processor data-sheet, programming,
This assessment consisted primarily of manual
and reference manuals.
code review, aided by automated analysis and
fuzzing.
Manual code auditing was performed starting
from the bootloader at the root of the trust chain
Hardware Setup
and ending at the higher level FIDO2
implementation. The configuration of the security
Four SoloKeys were used for this engagement: features provided by the STM32L432 was also
evaluated, finding no flaws. The boot process was
• 3 secure Solo found to be secure against the threat model
• 2 with application v3.0.1, bootloader 0.0.1 agreed upon.
• 1 with application v3.0.1, bootloader 3.0.1
• 1 hacker Solo Attempts to expand the remotely available attack
• unlocked device allowing to run arbitrary surface via WebUSB and WebHID APIs were
unsigned firmware unsuccessful.
Fuzzing Setup
When performing assessments, we combine
manual security testing with state-of-the-art tools
in order to improve efficiency and efficacy of our
effort.
During this engagement, we used the industry-
standard American Fuzzy Lop (AFL) fuzzer to
perform coverage guided automated testing of
parts of the code where this testing technique is
commonly used to expose bugs.
5 of 20 WWW.DOYENSEC.COM
SoloKeys - Security Auditing Report
Project Findings
The table below lists the findings with their associated ID and severity. The severity ranking and
vulnerability classes are defined in Appendix A at the end of this document. The vulnerability class
column groups the entry into a common category, while the status column refers to whether the finding
has been fixed at the time of writing.
Findings Recap Table
ID Title Vulnerability Class Severity Status
TinyCBOR API Misuses Leading to Denial of
1 Denial of Service Low Open
Service and Undefined Behaviour
Memory
2 Insufficient Minimum Stack Size Informational Open
Corruption
Incorrect Firmware Version Check Allows
3 Insecure Design High Open
Downgrading
6 of 20 WWW.DOYENSEC.COM
SoloKeys - Security Auditing Report
Findings per Severity
The table below provides a summary of the findings per severity.
Critical 0
High 1
Medium 0
Low 1
Informational 1
Findings per Type
The table below provides a summary of the findings per vulnerability class.
Denial of Service 1
Memory Corruption 1
Insecure Design 1
7 of 20 WWW.DOYENSEC.COM
SoloKeys - Security Auditing Report
1. TinyCBOR API Misuses Leading to Denial of Service and Undefined
Behaviour
Severity Low
Vulnerabili