Penetration Test Report (Cure53): pentest report openkeychain

Pentest-Report OpenKeychain 08.2015
Cure53, Dr.-Ing. M. Heiderich, J. Horn, Dipl-Ing. A. Aranguren, Dr. J. Magazinius, D. Weißer
Index
Introduction
Scope
Identified Vulnerabilities
OKC -01-001 Private Keys can be imported from Keyserver ( Medium )
OKC -01-004 Arbitrary file write when decrypting and saving messages ( High )
OKC -01-006 Keyserver can send arbitrary Public Keys withou t Verification ( Low )
OKC -01-009 Bypassable Fingerprin t - Check for Key Exchange via QR Code ( High )
OKC -01-010 Database can be exported using Encryp t Operation ( Low )
OKC -01-011 Unconfirmed Main Identities are shown as confirmed ( Low )
OKC -01-012 Database Extraction possible via Version Downgrade ( Medium )
OKC -01-013 Key Usage unchecked upon Decryption / Signature Verification ( Low )
OKC -01-014 Multiple File overwrite Vulnerabilities via Path Traversa l ( High )
OKC -01-015 Expor t o f PGP Information in clear - tex t on insecure Storage ( Medium )
OKC -01-017 Predictable File Creation on insecure Location ( Medium )
OKC -01-018 Key Server Verification Bypass via HTTP Redirec t ( Medium )
Miscellaneous Issues
OKC -01-002 Malicious public Key can lead to persisten t Denia l o f Service ( Medium )
OKC -01-003 Malicious Key Server response can lead to Denia l o f Service ( Low )
OKC -01-005 Insufficien t and insecure RSA / DSA Key Sizes permitted ( Medium )
OKC -01-007 Signing Operations with weak Key lead to Denia l o f Service ( Info )
OKC -01-008 OpenKeychain accepts weak Passwords withou t any Warning ( Info )
OKC -01-016 No Warnings when adding a clear - tex t HTTP Key Server ( Low )
Conclusion
1/18
Introduction
“OpenKeychain helps you communicate more privately and securely. It uses high-quality
modern encryption to ensure that your messages can be read only by the people you
send them to, others can send you messages that only you can read, and these
messages can be digitally signed so the people getting them are sure who sent them.
OpenKeychain is based on the well established OpenPGP standard making encryption
compatible across your devices and operating systems.”
From https :/ / github . com / open - keychain / open - keychain
This penetration test and source code audit against the OpenKeychain mobile
application took an entirety of twelve days and was performed by five testers of the
Cure53 team. The test yielded an overall of eighteen issues, of which twelve were
classified as vulnerabilities and six as general weaknesses.
The test was performed over a dedicated release tag created by the project maintainers
in the public Github repository1. The Cure53 team audited the available sources and
performed tests against the running application on both emulators and actual Android
devices for maximum coverage. In addition to the core library, certain parts of the
involved third party libraries were also audited. However, please note that only the
relevant parts of libraries were analyzed. For instance, this applies to Spongy Castle2, for
which exclusively the parts that actually interact with OpenKeychain were examined.
The first and foremost conclusion of the test is that, on the one hand, none of the
identified issues were classified as being of “critical” severity. On the other hand, three
vulnerabilities were rated to be of a “high” severity. Quite telling is the fact, however, that
these issues do not pertain to cryptographic flaws but rather to implementation-related
issues. They occurred in connection to the handling of information during the process of
key import and similar interaction with the app. This namely applied to the context of the
external data being parsed and handled incorrectly, and thus could lead to an attack
harming the device and users’ security and privacy. Overall, the application presented
itself as fairly robust in the core, yet requiring quite an array of smaller fixes, alterations
and changes. The main focus at present should be to acquire a consistent level of
security with regard to the import features, UI security and general file handling.
Scope
• Sources made available via Github
◦ https :/ / github . com / open - keychain / open - keychain
• APK from F-Droid
◦ https :/ / f - droid . org / repository / browse /? fdid = org . sufficientlysecure .keychain
1 http :// www . openkeychain . org / openkeychain -3-5/
2 https :// rtyley . github . io / spongycastle /
2/18
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. The aforementioned severity rank is simply given in
brackets following the title heading for each vulnerability. Each vulnerability is
additionally given a unique identifier (e.g. OKC-01-001) for the purpose of facilitating any
future follow-up correspondence.
OKC-01-001 Private Keys can be imported from Keyserver (Medium)
When a user attempts to download a public key from a keyserver, a rogue keyserver can
instead send a private key inside a public key’s armor. The app imports the private key
without a warning and adds it to the private keyring. The method ImportOperation.
serialKeyRingImport() invokes the method HkpKeyserver.get(), which then
extracts the base64-encoded key from the keyserver’s response.. This is done through
testing for the presence of the Armor Header and Armor Tail lines and stripping them:
Affected Code:
Matcher matcher = PgpHelper.PGP_PUBLIC_KEY.matcher(data);
if (matcher.find()) {
return matcher.group(1);
}
The base64-encoded key without Armor Header and Tail is then related to
UncachedKeyRing.decodeFromData(), which is also used to parse private keys. This
effectively causes the problem assessed and pointed out here. Consequently, it is
recommended to verify that keys that are imported from a keyserver contain solely public
keys.
OKC-01-004 Arbitrary file write when decrypting and saving messages (High)
PGP files can contain the name of the original unencrypted file. This feature is used by
OpenKeychain in order to select a proper location when decrypting and finally saving a
PGP file. Although value is not intended to contain path elements, OpenKeychain fails to
perform any checks ensuring the prevention of possible file-overwrite-type attacks.
A malicious user - let us call him Bob - could craft an encrypted file with the original
filename set to an arbitrary path of his choice on the file system. He could then send it to
a second (regular, non-malicious) user we will call Alice. When Alice decrypts the file and
clicks “OK” on the “Decrypt To File” dialog without choosing a location for storing the file,
the decrypted file will be written to the PATH defined by Bob. The “Decrypt To File” dialog
only shows the target file name but not the full path on Android < KitKat (namely its 4.4
version).3
The consequences of this issue are two-fold: a certain Denial of Service (e.g. by
overwriting the key database), and a possibility for command execution. Devices running
3 https :// www . android . com / versions / ki t - kat -4-4/
3/18
Android versions equals or newer KitKat are seemingly not affected due to the fact that
they employ a different file manager.
Example Data:
• Password used here: a
• Original filename:
//////////////////////////////////////../../../../../../data/data/
org.sufficientlysecure.keychain/databases/badfile
Encrypted File:
-----BEGIN PGP MESSAGE-----
Version: GnuPG v2
jA0EBwMCtdLrYNpnR9rZ0nMBAPoOTWO+Q0RaYo22ZttlVdDL6gbu1xEVYoYOtsRj
lVWNuwc2FxSfHUFsY26DRx0Ho8JlONAyj6LxWbJ3XWn/7hR17t47d5AvqbgWNHbL
Aoq+OlPdsTFy8qeMi19HtyBVol5kGbPMBUnoS7Cv7FQyYlG+
=qA7c
-----END PGP MESSAGE-----
This occurrence can be explained with several following conditions. Firstly, when a user
decrypts the file shown above, only a sequence of “/” is displayed as the filename.
Secondly, when a user running Android versions older than KitKat selects “Save file”, he
only sees “badfile” in the dialog. In case th