Penetration Test Report (Cure53): pentest report streamcryptor

Audit-Report Bitbeans StreamCryptor 04.2015
Cure53, Dr.-Ing. Mario Heiderich, Dipl.-Math. Franz Antesberger, Jann Horn
Index
Introduction
Scope
Identified Vulnerabilities
BSC -01-004 Directory Traversa l Vulnerability via outputFolder Argumen t ( High )
BSC -01-006 Unauthenticated FilenameNonce allow s Information Leakage ( Low )
BSC -01-007 Same Key is used for MAC and SecretBox ( Medium )
Miscellaneous Issues
BSC -01-001 README . md listing an outdated , deprecated Library Location ( Info )
BSC -01-002 Redundan t Header Data is being used ( Low )
BSC -01-003 Outdated libsodium Version is used in Build Process ( Info )
BSC -01-005 ChunkLength is no t authenticated and no t needed ( Low )
BSC -01-008 MACs use no explici t Type Prefix ( Low )
BSC -01-009 Unchecked Length Additions in ArrayHelpers ( Medium )
BSC -01-010 GetRandomString is slightly skewed by an of f - by - one Error ( Info )
Conclusion
Introduction
“You can use StreamCryptor to encrypt and decrypt files without size limit and the need
to load every file completely into memory. StreamCryptor uses FileStream to read and
write files in chunks, there is also an asynchronous implementations for progress
reporting available.“
From https :/ / github . com / bitbeans /StreamCryptor
This report describes the Source Code Audit (SCA) against the StreamCryptor library1
maintained by Christian Hermann. The SCA was carried out by three testers of the
Cure53 team in late April 2015 and took two days to complete. The scope of the test
essentially comprised the latest Github-stored snapshot of the library, with an inclusion
of all files and documentation offered. The audit yielded two security vulnerabilities and
eight general weaknesses.
Evidently, the overall count of issues indicates a positive result. No major flaws were
spotted in the cryptographic implementation and primitives, while the only serious flaw
resulted from improper validation of file paths leading to a potential directory traversal
and arbitrary file-write attack. This bug should be trivial to address and fix.
1 https :// github . com / bitbeans / StreamCryptor /
1/7
Scope
• Bitbeans StreamCryptor Source Code
◦ https :/ / github . com / bitbeans /StreamCryptor
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. BSC-01-00X) for the purpose of facilitating any future follow-up correspondence.
BSC-01-004 Directory Traversal Vulnerability via outputFolder Argument (High)
The variants of the method DecryptFileWithStreamAsync() receive an
outputFolder argument and decrypt data into a given folder are affected by a path
traversal vulnerability. The methods pass an unfiltered path-name contained in the
encrypted data into Path.Combine(). Next, they use the result as a path to which the
received file should be moved by using File.Move(). This allows an attacker to place
files in almost arbitrary file system locations to which the user has write-access. Thus
this can potentially lead to remote code execution as quoted below.2
“If path2 does not include a root (for example, if path2 does not start with a
separator character or a drive specification), the result is a concatenation of the
two paths, with an intervening separator character. If path2 includes a root, path2
is returned.”
A partial mitigation possibly takes place if the parameter overWrite is set to false, which
is its default value.
From observations made on the code it transpires that the use of path-names is not
intended to be permitted at this location at all. It is therefore recommended to either
blacklist all characters returned by Path.GetInvalidFileNameChars(), or only
whitelist known-safe characters. However, if it is important to support file names in
distinct world languages (for instance Japanese), a blacklist might be more appropriate.
Keep in mind that the latter solution, i.e. the blacklist, needs to be handled with care.
Further note that it is not necessary to filter the filename for special filenames like PRN or
COM1 because File.Move() calls MoveFileEx(..., MOVEFILE_COPY_ALLOWED)3, which
will not write into “existing files”.
Note: The issue has been addressed by the maintainer of the StreamCryptor Library
and was verified as fixed by Cure53.
2 https :// msdn . microsoft . com / en - US / en - en / library / fyy 7 a 5 k t ( v = vs .110) .aspx
3 https :// msdn . microsoft . com / en - us / library / windows / desktop / aa 365240%28 v = vs .85%29 .aspx
2/7
BSC-01-006 Unauthenticated FilenameNonce allows Information Leakage (Low)
The FilenameNonce member of the EncryptedFileHeader class is not protected
against tampering in any way. In addition, Filename is solely protected by a NaCl
Secretbox4 using ephemeralKey.
If a Man-in-the-Middle (MitM) attacker5 copies the ciphertext of the last chunk (which has
to be very short) into Filename and the nonce of the chunk into FilenameNonce,
respectively, then the filename of the decrypted file will in fact be the same as the
contents of the plaintext chunk. It is therefore recommended to include at least
FilenameNonce, and ideally also Filename, in the header checksum.
Note: The issue has been addressed by the maintainer of the StreamCryptor Library
and was verified as fixed by Cure53.
BSC-01-007 Same Key is used for MAC and SecretBox (Medium)
StreamCryptor uses ephemeralKey for both message authentication (using
Sodium.GenericHash.Hash()) and encryption (using SecretBox).
It is strongly recommended to make ephemeralKey larger and split its use. One half of it
can be employed as a key for message authentication, while the other half as a key for
encryption. Otherwise a class of cryptanalytic attacks on the combination of Blake2b and
XSalsa20 could become possible.
Note: The issue has been addressed by the maintainer of the StreamCryptor Library
and was verified as fixed by Cure53.
4 http :// nac l . cr . yp . to / secretbox .html
5 http :// en . wikipedia . org / wik i / Man - in - the - middle _ attack
3/7
Miscellaneous Issues
This section covers those noteworthy findings that did not lead to an exploit but might aid
attackers in achieving their malicious goals in the future. Most of these results are
vulnerable code snippets that did not provide an easy way to be called. Conclusively,
while a vulnerability is present, an exploit might not always be possible.
BSC-01-001 README.md listing an outdated, deprecated Library Location (Info)
The protobuf-net library was moved from Google Code to Github, 6 but is still listed under
the old location in the project’s README.md file.7 It is recommended to update the
document to reflect the new location. This would prevent users from adopting a
deprecated and potentially vulnerable library.
Note: The issue has been addressed by the maintainer of the StreamCryptor Library
and was verified as fixed by Cure53.
BSC-01-002 Redundant Header Data is being used (Low)
Chunks contain ChunkNumber and ChunkNonce members that encompass the number of
the chunk and a derived nonce value.8 These member variables are not required for
correct parsing of the encrypted file. In all actuality, StreamCryptor ignores them while
decrypting the file.
Nevertheless, the presence of these members in the encrypted data might lead future
re-implementations of StreamCryptor towards the use of the chunk number or chunk
nonce contained in the chunk header instead of counting chunks themselves. Such
behavior would allow attackers to mix the order of encrypted chunks, and therefore also
the plaintext contained within them. It is therefore recommended to remove
ChunkNumber and ChunkNonce for the purpose of maintaining clarity and unambiguity.
Similarly, file footers contain unused memb