Penetration Test Report (Cure53): pentest report nitrokey

Pentest-Report Nitrokey Storage Firmware 05.2015
Cure53, Dr.-Ing. Mario Heiderich, Jann Horn, Nikolai Krein
Index
Introduction
Scope
Identified Vulnerabilities
NK -01-004 Block number is used as IV in CBC mode ( Medium )
NK -01-005 Ou t - o f - Bounds Read in ConvertMatrixDataToPassword ( Low )
NK -01-007 OTP commands can be used withou t authorization ( High )
NK -01-008 OTP can be unlocked by replacing Smar t Card ( High )
NK -01-009 Passwords are encrypted in ECB mode ( Low )
NK -01-010 GetRandomNumber _ u 32 mixes randomness improperly ( Medium )
NK -01-013 Encryption o f uninitialized memory in HV _ WriteSlo t _ u 8 ( Medium )
NK -01-014 Security Bi t is bound to Firmware Updates ( High )
NK -01-015 Admin Check can be bypassed by resetting Smar t Card ( High )
NK -01-016 Ou t - o f - Bounds Read in CCID Handling ( Medium )
Miscellaneous Issues
NK -01-001 One - Byte Buffer Overflow in HTML _ CheckInpu t () ( Low )
NK -01-002 Read access to uninitialized stack memory ( Medium )
NK -01-011 HV _ InitSlo t _ u 8 zeroes encrypted slo t data ( Medium )
NK -01-017 Sightings o f outdated , deprecated or unused code ( Info )
Conclusion
Introduction
“Nitrokey is an USB key to enable highly secure encryption and signing of emails and
data, as well as login to the Web, networks and computers. Other than ordinary software
solutions, the secret keys are always stored securely inside the Nitrokey. Their
extraction is impossible which makes Nitrokey immune to computer viruses and Trojan
horses. The user-chosen PIN and the tamper-proof smart card protect in case of loss
and theft. Hardware and software are both available as Open Source to allow verifying
the security and integration with other applications.”
From https :/ / www . nitrokey . com /introduction
This penetration test against the Nitrokey Storage firmware, as well as the Nitrokey
desktop app, was performed by a team of three penetration-testers and took eleven
days in total to complete. The test is part of a larger series of security assessments. In
later phases, security-focused assignments will include tests against the hardware itself,
alongside detailed look into other models of the Nitrokey and its accompanying
applications and tools. The main scope of a particular assessment covered by this report
1/12
is the Nitrokey Storage firmware openly available on GitHub.1 The majority of code is
composed in the C and C++ languages. The test was performed as a pure source code
audit, hence the software was neither compiled nor run on any of the Nitrokey hardware.
As already mentioned, the actual hardware testing and integration tests are scheduled to
be performed at a later stage of the auditing process.
The test was carried out in reference with a threat model delivered by the Nitrokey Team.
Said threat model essentially specifies the attack scenarios which the tested soft- and
hardware seeks to protect against. It reads as follows:
• Malware trying to steal/export private keys while the device is being used on the
compromised computer.
• An attacker stealing or finding the (switched off) device and trying to tamper the
device in order to get access to the private keys or encrypted mass data. This
includes sophisticated physical attacks with laboratory equipment and (digital)
brute force attacks. ("offline")
• Nitrokey protects against Malware attempting to program malicious firmware onto
the stick by instrumenting an alleged tamper-proof smart card.
The following security assumptions have been added to complete the threat model:
• The Admin PIN and Firmware Password are only used on secure computers for
administrative purposes.
• The User PIN can be used on the potentially compromised computers.
Keep in mind the specificity of this basic threat model and the set of security
assumptions tied to it. Those are subject to this particular test only and might therefore
be changed, altered or extended for the upcoming hardware audit and/or any additional
firmware and application security checks.
In this document we report on the test findings which scope ten vulnerabilities and four
general weaknesses and recommendations overall. None of the identified issues were
classified to be of critical severity. At the same time four issues were marked with
severity “High“, as the underlying vulnerabilities would allow for a compromise of the
Nitrokey threat model used for this source code audit.
1 https :// github . com / Nitrokey / nitrokey - storage - firmware
2/12
Scope
• Nitrokey Storage Firmware
◦ https :/ / github . com / Nitrokey / nitrokey - storage - firmware
• Nitrokey App
◦ https :/ / github . com / Nitrokey / nitrokey - app
Identified Vulnerabilities
The following sections list both vulnerabilities and implementation issues spotted during
the testing period. Note that findings are listed in a chronological order rather than by
their degree of severity and impact, which is simply given in brackets following the title
heading for each vulnerability. Each vulnerability is additionally given a unique identifier
(e.g. NK-01-00X) for the purpose of facilitating any future follow-up correspondence.
NK-01-004 Block number is used as IV in CBC mode (Medium)
The method STICK20_mci_aes() encrypts in CBC mode2, with BlockNr_u32 repeated
four times as IV.3 This allows an attacker to recognize a certain plaintext pattern in the
ciphertext: If (plaintext of first 128 bytes of block A XOR plaintext of
first 128 bytes of block B) = repeat(chunkNumberA XOR chunkNumberB), the
first ciphertext blocks of the blocks will arrive at an equal result value.
Depending on the plaintext's structure, this problem may not only aid the reconstruction
of its shape, but could also assist an adversary who has gained access to the encrypted
flash storage and then manages to recognize watermarks that intentionally contain the
pattern.
It is recommended to encrypt or hash the chunk number. An encrypted or hashed chunk
number as IV should be used instead.
Note: This issue was fixed by the Nitrokey maintainers, the fix was verified by Cure53.
2 http :// en . wikipedia . org / wik i / Block _ cipher _ mode _ o f _ operation # Cipher _ Block _ Chaining _.28 CBC .29
3 http :// en . wikipedia . org / wik i / Initialization _ vector
3/12
NK-01-005 Out-of-Bounds Read in ConvertMatrixDataToPassword (Low)
In the file nitrokey-storage-firmware-master/src/USER_INTERFACE/html_io.c4, the
method HID_ExcuteCmd uses the HID_String_au8 buffer with a size of 50 to determine
the current action. If the first character is “M”, the user password gets converted from a
matrix form. However, the method ConvertMatrixDataToPassword() uses a statically
allocated MatrixColumsUserPW_au8 stack buffer with size 20, while the conversion loop
is bounded by the string length of HID_String_au8, thus resulting in an out-of-bounds
memory access when the values of MatrixColumsUserPW_au8 and PWM_Password-
Matrix_as8 are read.
It is recommended to ensure that the conversion loop is bounded by the size of
MatrixColumsUserPW_au8 instead of setting n to strlen(MatrixData_au8).
Note: This issue was fixed by the Nitrokey maintainers, the fix was verified by Cure53.
NK-01-006 cmd_user_authenticate does not clear Password from RAM (Low)
Whenever the Smart Card is queried to verify a password with, for example, the method
LA_OpenPGP_V20_Verify(), the caller has to make sure that the password is cleanly
wiped from the RAM.5 In the file report_protocol.c when a CMD_USER_AUTHENTICATE-
Command is invoked, cmd_user_authenticate() uses the user_password buffer for
authentication. However after the method LA_OpenPGP_V20_Test_SendUserPW2()
returns, this critical memory area is left untouched even if the password was correct,
thus letting it remain inside the RAM.
It is recommended to memset this buffer to 0, similar to cmd_first_authenticate().
Note: This issue was fixed by the Nitrokey maintainers, the fix was verified by Cure53.
NK-01-007 OTP commands can be used without authorization (High)
There