├── Cure53 ├── Cryptocat-2-Pentest-Report.pdf ├── Cure53_-_Subrosa.pdf ├── cure53-audit-may2014.pdf ├── pentest-report_SC4.pdf ├── pentest-report_accessmyinfo.pdf ├── pentest-report_casebox-1.pdf ├── pentest-report_casebox-2.pdf ├── pentest-report_clipperz.pdf ├── pentest-report_cyph.pdf ├── pentest-report_dompurify.pdf ├── pentest-report_fdroid.pdf ├── pentest-report_globaleaks.pdf ├── pentest-report_libjpeg-turbo.pdf ├── pentest-report_mailvelope.pdf ├── pentest-report_minilock.pdf ├── pentest-report_nitrokey-hardware.pdf ├── pentest-report_nitrokey.pdf ├── pentest-report_onion-browser.pdf ├── pentest-report_openkeychain.pdf ├── pentest-report_openpgpjs.pdf ├── pentest-report_pcre.pdf ├── pentest-report_peerio.pdf ├── pentest-report_securedrop.pdf ├── pentest-report_smartsheriff-2.pdf ├── pentest-report_smartsheriff.pdf ├── pentest-report_streamcryptor.pdf └── pentest-report_whiteout.pdf ├── Defuse ├── Defuse_-_EncFS.txt ├── Defuse_-_Hash0.txt ├── Defuse_-_ZeroBin.txt └── Defuse_-_eCryptfs.txt ├── Fox-IT └── Fox-IT_-_DigiNotar.pdf ├── Fraunhofer └── Fraunhofer_-_TrueCrypt.pdf ├── IOActive └── ioactive-bromium-test-report-final.pdf ├── IndependentSecurityEvaluators └── ISE_-_Apple_iPhone.pdf ├── LeastAuthority ├── LeastAuthority-Cryptocat-audit-report.pdf └── LeastAuthority-GlobaLeaks-audit-report.pdf ├── Leviathan ├── OmniFileStore Encryption Review - FINAL - 06102016.pdf └── SpiderOak-Crypton_pentest-Final_report_u.pdf ├── Matasano ├── Matasano SourceT Security Evaluation Report.pdf └── wp-multistore-security-analysis.pdf ├── OPM-OIG └── OPM-OIG_-_US_Office_of_Personnel_Management.pdf ├── OffensiveSecurity └── penetration-testing-sample-report-2013.pdf ├── PrincetonUni ├── Princeton_University_-_Diebold_AccuVote-TS.pdf └── Princeton_University_-_Safeplug.pdf ├── ProCheckUp └── CHECK-1-2012.pdf ├── PwC └── PwC_-_HM_Revenue_and_Customs.pdf ├── QuarksLab └── 14-03-022_ChatSecure-sec-assessment.pdf ├── README.md ├── Sakurity └── Sakurity_-_Peatio.pdf ├── SecureLayer7 ├── Penetration-testing-report--open-source-Ruby-on-rails-Refinery-CMS.pdf └── readme.md ├── TrailOfBits └── Trail_of_Bits_-_Apple_iOS_4.pdf ├── UniWashington └── UW-CSE-13-08-02.PDF ├── Veracode ├── Veracode_-_Cryptocat.pdf └── Veracode_-_GlobaLeaks_and_Tor2web.pdf ├── iSEC ├── NCC_Group_-_Ricochet.pdf ├── NCC_Group_-_phpMyAdmin.pdf ├── TrueCrypt_Phase_II_NCC_OCAP_final.pdf ├── iSEC_Cryptocat_iOS.pdf ├── iSEC_Wikimedia.pdf ├── iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf ├── ncc_docker_notary_audit_2015_07_31.pdf └── ncc_osquery_security_assessment_2016_01_25.pdf └── mnemonic └── mnemonic_-_Norwegian_electronic_voting_system.pdf /Cure53/Cryptocat-2-Pentest-Report.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/Cryptocat-2-Pentest-Report.pdf -------------------------------------------------------------------------------- /Cure53/Cure53_-_Subrosa.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/Cure53_-_Subrosa.pdf -------------------------------------------------------------------------------- /Cure53/cure53-audit-may2014.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/cure53-audit-may2014.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_SC4.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_SC4.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_accessmyinfo.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_accessmyinfo.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_casebox-1.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_casebox-1.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_casebox-2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_casebox-2.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_clipperz.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_clipperz.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_cyph.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_cyph.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_dompurify.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_dompurify.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_fdroid.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_fdroid.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_globaleaks.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_globaleaks.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_libjpeg-turbo.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_libjpeg-turbo.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_mailvelope.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_mailvelope.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_minilock.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_minilock.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_nitrokey-hardware.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_nitrokey-hardware.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_nitrokey.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_nitrokey.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_onion-browser.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_onion-browser.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_openkeychain.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_openkeychain.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_openpgpjs.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_openpgpjs.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_pcre.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_pcre.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_peerio.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_peerio.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_securedrop.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_securedrop.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_smartsheriff-2.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_smartsheriff-2.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_smartsheriff.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_smartsheriff.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_streamcryptor.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_streamcryptor.pdf -------------------------------------------------------------------------------- /Cure53/pentest-report_whiteout.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Cure53/pentest-report_whiteout.pdf -------------------------------------------------------------------------------- /Defuse/Defuse_-_EncFS.txt: -------------------------------------------------------------------------------- 1 | ------------------------------------------------------------------------ 2 | EncFS Security Audit 3 | Taylor Hornby 4 | January 14, 2014 5 | (Updated: February 5, 2014) 6 | ------------------------------------------------------------------------ 7 | 8 | 1. Introduction 9 | 10 | This document describes the results of a 10-hour security audit of 11 | EncFS 1.7.4. The audit was performed on January 13th and 14th of 2014. 12 | 13 | 1.1. What is EncFS? 14 | 15 | EncFS is a user-space encrypted file system. Unlike disk encryption 16 | software like TrueCrypt, EncFS's ciphertext directory structure 17 | mirrors the plaintext's directory structure. This introduces unique 18 | challenges, such as guaranteeing unique IVs for file name and content 19 | encryption, while maintaining performance. 20 | 21 | 1.2. Audit Results Summary 22 | 23 | This audit finds that EncFS is not up to speed with modern 24 | cryptography practices. Several previously known vulnerabilities have 25 | been reported [1, 2], which have not been completely fixed. New issues 26 | were also discovered during the audit. 27 | 28 | The next section presents a list of the issues that were discovered. 29 | Each issue is given a severity rating from 1 to 10. Due to lack of 30 | time, most issues have not been confirmed with a proof-of-concept. 31 | 32 | 2. Issues 33 | 34 | 2.1. Same Key Used for Encryption and Authentication 35 | 36 | Exploitability: Low 37 | Security Impact: Low 38 | 39 | EncFS uses the same key for encrypting data and computing MACs. This 40 | is generally considered to be bad practice. 41 | 42 | EncFS should use separate keys for encrypting data and computing MACs. 43 | 44 | 2.2. Stream Cipher Used to Encrypt Last File Block 45 | 46 | Exploitability: Unknown 47 | Security Impact: High 48 | 49 | As reported in [1], EncFS uses a stream cipher mode to encrypt the 50 | last file block. The change log says that the ability to add random 51 | bytes to a block was added as a workaround for this issue. However, it 52 | does not solve the problem, and is not enabled by default. 53 | 54 | EncFS needs to use a block mode to encrypt the last block. 55 | 56 | EncFS's stream encryption is unorthodox: 57 | 58 | 1. Run "Shuffle Bytes" on the plaintext. 59 | N[J+1] = Xor-Sum(i = 0 TO J) { P[i] } 60 | (N = "shuffled" plaintext value, P = plaintext) 61 | 2. Encrypt with (setIVec(IV), key) using CFB mode. 62 | 3. Run "Flip Bytes" on the ciphertext. 63 | This reverses bytes in 64-byte chunks. 64 | 4. Run "Shuffle Bytes" on the ciphertext. 65 | 5. Encrypt with (setIVec(IV + 1), key) using CFB mode. 66 | 67 | Where setIVec(IV) = HMAC(globalIV || (IV), key), and, 68 | - 'globalIV' is an IV shared across the entire filesystem. 69 | - 'key' is the encryption key. 70 | 71 | This should be removed and replaced with something more standard. As 72 | far as I can see, this provides no useful security benefit, however, 73 | it is relied upon to prevent the attacks in [1]. This is security by 74 | obscurity. 75 | 76 | 2.3. Generating Block IV by XORing Block Number 77 | 78 | Exploitability: Low 79 | Security Impact: Medium 80 | 81 | Given the File IV (an IV unique to a file), EncFS generates per-block 82 | IVs by XORing the File IV with the Block Number, then passing the 83 | result to setIVec(), which is described in Section 2.2. This is not 84 | a good solution, as it leads to IV re-use when combined with the 85 | last-block stream cipher issue in Section 2.2: 86 | 87 | The stream algorithm (see previous section) adds 1 to the IV, which 88 | could *undo* the XOR with the block number, causing the IV to be 89 | re-used. Suppose the file consists of one and a half blocks, and that 90 | the File IV's least significant bit (LSB) is 1. The first block will 91 | be encrypted with the File IV (block number = 0). The second (partial) 92 | block will be encrypted with File IV XOR 1 (since block number = 1), 93 | making the LSB 0, using the stream algorithm. The stream algorithm 94 | adds 1 to the IV, bringing the LSB back to 1, and hence the same IV is 95 | used twice. The IVs are reused with different encryption modes (CBC 96 | and CFB), but CFB mode starts out similar to CBC mode, so this is 97 | worrisome. 98 | 99 | EncFS should use a mode like XTS for random-access block encryption. 100 | 101 | Correction 12/05/2014: XTS mode is probably not the ideal option, see 102 | Thomas Ptacek's blog post for good reasons why: 103 | 104 | http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ 105 | 106 | 2.4. File Holes are Not Authenticated 107 | 108 | Exploitability: High 109 | Security Impact: Low 110 | 111 | File holes allow large files to contain "holes" of all zero bytes, 112 | which are not saved to disk. EncFS supports these, but it determines 113 | if a file block is part of a file hole by checking if it is all 114 | zeroes. If an entire block is zeroes, it passes the zeroes on without 115 | decrypting it or verifying a MAC. 116 | 117 | This allows an attacker to insert zero blocks inside a file (or append 118 | zero blocks to the end of the file), without being detected when MAC 119 | headers are enabled. 120 | 121 | 2.5. MACs Not Compared in Constant Time 122 | 123 | Exploitability: Medium 124 | Security Impact: Medium 125 | 126 | MACs are not compared in constant time (MACFileIO.cpp, Line 209). This 127 | allows an attacker with write access to the ciphertext to use a timing 128 | attack to compute the MAC of arbitrary values. 129 | 130 | A constant-time string comparison should be used. 131 | 132 | 2.6. 64-bit MACs 133 | 134 | Exploitability: Low 135 | Security Impact: Medium 136 | 137 | EncFS uses 64-bit MACs. This is not long enough, as they can be forged 138 | in 2^64 time, which is feasible today. 139 | 140 | EncFS should use (at least) 128-bit MACs. 141 | 142 | 2.7. Editing Configuration File Disables MACs 143 | 144 | Exploitability: High 145 | Security Impact: Medium 146 | 147 | The purpose of MAC headers is to prevent an attacker with read/write 148 | access to the ciphertext from being able to make changes without being 149 | detected. Unfortunately, this feature provides little security, since 150 | it is controlled by an option in the .encfs6.xml configuration file 151 | (part of the ciphertext), so the attacker can just disable it by 152 | setting "blockMACBytes" to 0 and adding 8 to "blockMACRandBytes" (so 153 | that the MAC is not interpreted as data). 154 | 155 | EncFS needs to re-evaluate the purpose of MAC headers and come up with 156 | something more robust. As a workaround, EncFS could add a command line 157 | option --require-macs that will trigger an error if the configuration 158 | file does not have MAC headers enabled. 159 | 160 | 3. Future Work 161 | 162 | There were a few potential problems that I didn't have time to 163 | evaluate. This section lists the most important ones. These will be 164 | prioritized in future audits. 165 | 166 | 3.1. Information Leakage Between Decryption and MAC Check 167 | 168 | EncFS uses Mac-then-Encrypt. Therefore it is possible for any 169 | processing done on the decrypted plaintext before the MAC is checked 170 | to leak information about it, in a style similar to a padding oracle 171 | vulnerability. EncFS doesn't use padding, but the MAC code does 172 | iteratively check if the entire block is zero, so the number of 173 | leading zero bytes in the plaintext is leaked by the execution time. 174 | 175 | 3.2. Chosen Ciphertext Attacks 176 | 177 | Since the same key is used to encrypt all files, it may be possible 178 | for an attacker with read/write access to the ciphertext and partial 179 | read access to the plaintext (e.g. to one directory when --public is 180 | used) to perform a chosen ciphertext attack and decrypt ciphertexts 181 | for which they have no plaintext access. 182 | 183 | EncFS should consider using XTS mode. 184 | 185 | Correction 12/05/2014: XTS mode is probably not the ideal option, see 186 | Thomas Ptacek's blog post for good reasons why: 187 | 188 | http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ 189 | 190 | 3.3. Possible Out of Bounds Write in StreamNameIO and BlockNameIO 191 | 192 | There is a possible buffer overflow in the encodeName method of 193 | StreamNameIO and BlockNameIO. The methods write to the 'encodedName' 194 | argument without checking its length. This may allow an attacker with 195 | control over file names to crash EncFS or execute arbitrary code. 196 | 197 | 3.4. 64-bit Initialization Vectors 198 | 199 | Initialization vectors are only 64 bits, even when using AES instead 200 | of Blowfish. This may lead to vulnerabilities when encrypting large 201 | (or lots of) files. 202 | 203 | 4. Conclusion 204 | 205 | In conclusion, while EncFS is a useful tool, it ignores many standard 206 | best-practices in cryptography. This is most likely due to it's old 207 | age (originally developed before 2005), however, it is still being 208 | used today, and needs to be updated. 209 | 210 | The EncFS author says that a 2.0 version is being developed [3]. This 211 | would be a good time to fix the old problems. 212 | 213 | EncFS is probably safe as long as the adversary only gets one copy of 214 | the ciphertext and nothing more. EncFS is not safe if the adversary 215 | has the opportunity to see two or more snapshots of the ciphertext at 216 | different times. EncFS attempts to protect files from malicious 217 | modification, but there are serious problems with this feature. 218 | 219 | 5. References 220 | 221 | [1] http://archives.neohapsis.com/archives/fulldisclosure/2010-08/0316.html 222 | 223 | [2] http://code.google.com/p/encfs/issues/detail?id=128 224 | 225 | [3] https://code.google.com/p/encfs/issues/detail?id=186 -------------------------------------------------------------------------------- /Defuse/Defuse_-_Hash0.txt: -------------------------------------------------------------------------------- 1 | ----------------------------------------------------------------------- 2 | Security Audit of Hash0 3 | Taylor Hornby 4 | April 13, 2014 5 | ----------------------------------------------------------------------- 6 | 7 | 1. Introduction 8 | 9 | This report is the result of a 5-hour audit of Hash0 [1]. Hash0 is 10 | a tool for generating different passwords for websites based on 11 | a master password, similar to pwdhash [2] and hashpass [3]. 12 | 13 | The audit scope and threat model are discussed in sections 1.2 and 14 | 1.3 respectively. Section 2 gives an overview of Hash0's 15 | cryptography. Section 3 presents security issues found during the 16 | audit. Section 4 recommends improvements. Section 5 lists future 17 | work, and Section 6 concludes. 18 | 19 | 1.2 Audit Scope 20 | 21 | This audit focused on the implementation and design of Hash0's 22 | cryptography, and did not explicitly check for other kinds of 23 | vulnerabilities. 24 | 25 | While some light review of the supporting libraries was performed, 26 | the audit focused on code unique to Hash0 and did not include 27 | significant time reviewing the PasswordMaker, SJCL, or CryptoJS 28 | libraries. 29 | 30 | The SHA1 of the commit that was reviewed is: 31 | 32 | 09338e4f0f453e8ad95859e0f882cf7c7d54aa26 33 | 34 | 1.3 Threat Model 35 | 36 | There are three types of entities involved in every use of Hash0: 37 | 38 | 1. The User 39 | 40 | The User is the person using the Hash0 software. The User 41 | knows the master password and uses Hash0 to generate 42 | site-specific passwords from the one master password. 43 | 44 | 2. The Storage Provider 45 | 46 | The Storage Provider is responsible for storing metadata 47 | like the salts and synchronization settings. We assume this 48 | entity is controlled by the adversary. 49 | 50 | 3. The Website 51 | 52 | This is the website the user is using Hash0 to generate 53 | a password for. The website provides a standard username and 54 | password login interface and is not necessarily aware that 55 | Hash0 is being used. We assume this entity is controlled by 56 | the adversary. 57 | 58 | The following list summarizes some kinds of attacks that would be 59 | considered security flaws in Hash0. 60 | 61 | - Attacks that leak useful information about the Master Password 62 | to any entity other than the User, even when the attacker can 63 | see many generated passwords. 64 | 65 | - Attacks that leak passwords for one Website to any entity 66 | other than the User or the intended Website. 67 | 68 | - Attacks that cause weak passwords to be generated. 69 | 70 | - Attacks that speed up the recovery of the master key from 71 | derived data (ciphertext, generated passwords, etc). 72 | 73 | 2. Cryptography Design 74 | 75 | Given a master password, Hash0 runs it through 100 iterations PBKDF2 76 | with the salt "saltysnacks" to produce 512 bits of output*. That 77 | output is used as a key to HMAC the string "zerobin1337". The HMAC 78 | output is converted to a 30-character password, called the 79 | "encryption password", with a base conversion algorithm. This 80 | password is used for encrypting and decrypting data stored by the 81 | Storage Provider. 82 | 83 | The data stored by the Storage Provider is encrypted and decrypted 84 | using SJCL's encrypt() and decrypt() convenience functions, with the 85 | default parameters. The default is to derive an 128-bit key from the 86 | password with PBKDF2 then encrypt the data with AES in CCM mode, 87 | which is an authenticated encryption mode. 88 | 89 | To generate a password for a website, Hash0 runs the master password 90 | through 100 iterations of PBKDF2 with a random salt** to generate 512 91 | bits of output. That output is used as a key to HMAC the string 92 | which is the domain name of the website prefixed to the password 93 | number (used to generate multiple passwords for the same website). 94 | The HMAC output is converted to a password of configurable length 95 | using a base conversion algorithm. 96 | 97 | * - The PBKDF2 output is encoded in hex and is used as the HMAC key 98 | without being decoded. 99 | 100 | **- The salt may be the empty string if the Storage Provider URL is 101 | not configured. See Issue 3.7. The salt is encoded (and used) as 102 | a 128-bit hex string. 103 | 104 | 3. Issues 105 | 106 | This section lists the issues discovered during the audit. We do not 107 | attempt to assign criticality or exploitability ratings to the 108 | issues. 109 | 110 | 3.1 Encryption is Stored in LocalStorage 111 | 112 | The encryption key, which is used to encrypt and decrypt the data 113 | stored by the Storage Provider, is stored in localStorage. Unless the 114 | browser is in private browsing mode, it will be written to disk. It 115 | should be kept it memory. 116 | 117 | The Hash0 author was aware of this issue before this audit began. 118 | 119 | 3.2 Salts Generated with Math.random() 120 | 121 | The salts are generated with CryptoJS's WordArray.random(), which 122 | uses Math.random(). This is insecure. Salts must be generated with 123 | a CSPRNG. 124 | 125 | Use window.crypto.getRandomValues() or the SJCL cryptographic random 126 | number generator. 127 | 128 | The Hash0 author was aware of this issue before this audit began. 129 | 130 | 3.3 Low PBKDF2 Iteration Count 131 | 132 | Only 100 iterations of PBKDF2 are used when deriving the encryption 133 | password or a website password. This low value was explicitly chosen 134 | for performance reasons. According to these benchmarks... 135 | 136 | https://wiki.mozilla.org/SJCL_PBKDF2_Benchmark 137 | 138 | ...most platforms can support many more iterations. The iteration 139 | count should be increased to 1000. 140 | 141 | This is probably because 1000 iterations of PBKDF2 actually are being 142 | used, but not in the right place. SJCL's encrypt() and decrypt() 143 | functions compute 1000 iterations of PBKDF2 to turn the passed string 144 | into a key. To avoid this, pass a key (bitArray), not a string, to 145 | encrypt() and decrypt(). 146 | 147 | The Hash0 author was aware of this issue before the audit began. 148 | 149 | 3.4 Corrupted Ciphertext Exception is Not Caught 150 | 151 | The SJCL decrypt() function will throw sjcl.exception.corrupt if the 152 | key is wrong or if an attacker has tampered with the ciphertext. 153 | Hash0 does not handle this case, and simply crashes without giving 154 | the user any explanation. 155 | 156 | This exception should be caught, and the user should be told that 157 | either the password they entered was wrong, or an attacker has 158 | tampered with the data saved by the Storage Provider. 159 | 160 | 3.5 Encryption Password Derived with Constant Salt 161 | 162 | The encryption password is derived from the master password with 163 | a constant salt: 164 | 165 | generatePassword( 166 | 'on', 30, 'zerobin', '1337', 'saltysnacks', password 167 | ); 168 | 169 | This is insecure, because the same master password will always 170 | generate the same encryption password, so rainbow tables and lookup 171 | tables can be used to crack the encrypted data. 172 | 173 | Fixing this is left as future work. See Section 5.3. 174 | 175 | 3.6 Migration Code Always Runs 176 | 177 | This is not a security issue. The code to prompt the user if they 178 | want to migrate will always run, because the "if" statement's 179 | condition will always be true: 180 | 181 | var password = $('#setup_master').val(); 182 | localStorage['encryptionPassword'] = // ... snipped ... 183 | 184 | var url = $('#setup_url').val(); 185 | localStorage['settingsURL'] = url; 186 | 187 | // Check if there is existing settings 188 | if (defined(localStorage['settingsURL']) && 189 | defined(localStorage['encryptionPassword'])) { 190 | 191 | 3.7 Empty Salt Used Without Warning 192 | 193 | If the URL to the Storage Provider is not provided or is empty, an 194 | empty salt is used: 195 | 196 | if (!defined(localStorage['encryptionPassword']) || 197 | !defined(localStorage['settingsURL']) || 198 | localStorage['settingsURL'] == '') { 199 | salt = ''; 200 | } else { 201 | ... 202 | 203 | Instead of using an empty salt, display an error (refuse to generate 204 | passwords), or warn the user and ask them to opt-in to using the 205 | empty salt. 206 | 207 | 3.8 HMAC Key is a Hex String 208 | 209 | When deriving the encryption password or a website password, the 210 | string used for the HMAC key is hex-encoded. This does not cause any 211 | immediate weaknesses, however using a key that isn't uniformly 212 | distributed is not ideal and probably breaks some of HMAC's security 213 | proofs. 214 | 215 | 3.9 Salt is a Hex String 216 | 217 | The salt passed to PBKDF2 is a hex string. While this doesn't cause 218 | any immediate security problems, it is not ideal. 219 | 220 | 3.10 Password is Output Before Settings are Saved 221 | 222 | When generating a website password, the password is shown to the user 223 | before the settings are uploaded. This means an attacker who can 224 | prevent the settings from being uploaded (e.g. by a DoS attack) can 225 | cause password reuse in some cases: 226 | 227 | 1. User generates a password for example.org. 228 | 2. Example.org's password database is breached. 229 | 3. User generates a new password, but the upload fails. 230 | 4. Example.org's password database is breached again. 231 | 5. User generates a new password, but this time it's the same as 232 | the one generated in (4) because the upload with the 233 | incremented number failed. 234 | 235 | 3.11 Browser Tab Race Conditions 236 | 237 | Because of a TOCTTOU bug, it's possible for the password to be 238 | entered in to the wrong tab. 239 | 240 | The init() function first obtains the password for the current param 241 | (domain), and then, AFTER it already has the password, it inserts it 242 | into the current tab. The tab might have changed in between. 243 | 244 | A malicious website could potentially "steal focus" at just the right 245 | time to steal a password that was intended for another website. 246 | 247 | To fix this, make sure that the tab the password is going to be 248 | inserted into is the same as the one that was the source of param. 249 | 250 | 4. Recommendations 251 | 252 | 4.1 Unit Tests 253 | 254 | Hash0 could benefit from unit tests, especially of important 255 | functions like initWithUrl() and generatePassword(). 256 | 257 | 4.2 Use PBKDF2 alone, not PBKDF2 then HMAC 258 | 259 | It doesn't seem necessary to use PBKDF2 to generate a key then to use 260 | HMAC on top of that to apply the param and number. It would be better 261 | to encode everything unambiguously into the PBKDF2 salt. 262 | 263 | 4.3 Do Not Use Passwords as Intermediate Keys 264 | 265 | Hash0 is somewhat strange in that instead of deriving an encryption 266 | key from the password, it derives another "encryption password." This 267 | is inefficient at best, and error-prone at worst. Stick to binary 268 | keys whenever possible. 269 | 270 | 5. Future Work 271 | 272 | 5.1 Side Channel Attacks 273 | 274 | Some of the code seems vulnerable to side-channel attacks. For 275 | example, passwordmaker/hashutils.js uses charAt() to get the 276 | character at an index into the character set, where the index is 277 | a secret. 278 | 279 | It could be possible for other scripts running in the browser, or 280 | other processes running on the system (as other users), to extract 281 | the key this way. 282 | 283 | 5.2 URL Reliability 284 | 285 | This audit did not fully explore all possible problems with the URL 286 | used to find the domain name not matching up with the actual URL of 287 | the page. Is it possible for a page to lie about its URL, so that 288 | Hash0 is fooled into giving it the password for another website? 289 | 290 | 5.3 Salting the Master Password 291 | 292 | The encryption key is derived from the master key with a fixed salt. 293 | Obviously, a random salt should be used instead. More time is needed 294 | to design a secure solution. 295 | 296 | 5.4 Storage Provider Replaying Old Data 297 | 298 | What exactly happens when the Storage Provider replays an old 299 | ciphertext? This will cause old passwords to be generated, and 300 | possibly some passwords re-used. What kind of risk does this pose to 301 | the user? 302 | 303 | 6. Conclusion 304 | 305 | No fatal flaws in Hash0 were identified. However, there is room for 306 | improvement. The most significant issues are 3.1, 3.2, 3.4, and 3.5. 307 | 3.11 may be very important as well, depending on how exploitable it 308 | is in practice (something this audit did not investigate). 309 | 310 | 7. References 311 | 312 | [1] https://github.com/dannysu/hash0 313 | [2] https://www.pwdhash.com/ 314 | [3] http://www.hashapass.com/en/index.html -------------------------------------------------------------------------------- /Defuse/Defuse_-_ZeroBin.txt: -------------------------------------------------------------------------------- 1 | ----------------------------------------------------------------------- 2 | Security Audit of ZeroBin 3 | Taylor Hornby 4 | February 02, 2014 5 | ----------------------------------------------------------------------- 6 | 7 | 1. Introduction 8 | 9 | ZeroBin's website [ZBW] describes ZeroBin as "a minimalist, 10 | opensource online pastebin/discussion board where the server has zero 11 | knowledge of hosted data." 12 | 13 | This report documents the results of a 4-hour security audit of 14 | ZeroBin. It was performed for free as a service to the free and open 15 | source software community. 16 | 17 | The audit was performed on a current clone of ZeroBin's Git 18 | repository [GR]. The commit hash is: 19 | 20 | 4f8750bbddcb137213529875e45e3ace3be9a769 21 | 22 | Note that this code is newer than the code available for download 23 | from the ZeroBin website [ZBW] (version 0.18), which has known 24 | vulnerabilities [XSS]. 25 | 26 | 1.1 Audit Scope 27 | 28 | This audit focused on the PHP side of ZeroBin. The JavaScript side 29 | was only audited briefly, so most issues could not be verified, and 30 | were added to Section 4, Future Work, below. The audit did NOT check 31 | for XSS vulnerabilities in zerobin.js, and did NOT check for correct 32 | usage of the SJCL cryptography library. 33 | 34 | The audit did NOT cover the following files: 35 | 36 | - lib/rain.tpl.class.php 37 | - js/base64.js 38 | - js/highlight.pack.js 39 | - js/jquery.js 40 | - js/rawdeflate.js 41 | - js/rawinflate.js 42 | - js/sjcl.js 43 | 44 | 2. Issues 45 | 46 | 2.1. Salt and HMAC Key Generated with mt_rand() 47 | 48 | Exploitability: Medium 49 | Security Impact: Low 50 | 51 | In serversalt.php, generateRandomSalt() generates a salt using the 52 | mt_rand() pseudo-random number generator. Because mt_rand() is not 53 | a cryptographic random number generator, this function will return 54 | easily-guessed salts with a much higher probability of collision. 55 | 56 | The salts generated by this function are relied on for security. For 57 | example, it is used as an HMAC key when checking delete tokens in 58 | processPasteDelete(). It should be replaced with mcrypt_create_iv() 59 | or openssl_random_pseudo_bytes(). 60 | 61 | Another unused mt_rand() salt generator appears in 62 | vizhash_gd_zero.php. This should be removed. 63 | 64 | This issue has already been reported in [GH68], but has not been 65 | fixed (the issue is still open). 66 | 67 | 2.2. Fixed Server Salt 68 | 69 | Exploitability: Low 70 | Security Impact: Low 71 | 72 | The security of the VizHash hashes of IP addresses (used to generate 73 | comment avatars) and delete tokens both rely on a fixed "salt" which 74 | is generated once per deployment, saved in data/salt.php. 75 | 76 | As noted in Issue 2.1, this salt is not generated with a secure 77 | random number, but keeping it fixed has several other disadvantages: 78 | 79 | - If the salt is compromised and published, anyone can reverse 80 | a VizHash into the corresponding IP address, even for expired 81 | posts (that they saved). This would not be possible if a random 82 | comment salt was generated for each post, then destroyed along 83 | with the post when it expires. This would, however, give users 84 | different avatars on different posts (which may be desired). 85 | 86 | - If the salt is compromised and published, anyone can find the 87 | delete link for any post, since they can compute the HMAC. This 88 | does not need to be possible. A random delete token could be 89 | generated for each post, and its hash stored along with the post. 90 | Then, the post could only be deleted if the user can provide the 91 | preimage of the hash. 92 | 93 | - Reusing the same key for two purposes is generally a bad idea. 94 | 95 | 2.3. Traffic Limiter Race Conditions 96 | 97 | To rate limit requests, ZeroBin keeps a history of hit times in 98 | data/traffic_limiter.php, which is generated and re-generated in 99 | traffic_limiter_canPass(). Because requests can be made 100 | asynchronously, the file may become corrupted. 101 | 102 | This might allow remote code execution, if the attacker is clever 103 | enough to corrupt the file in just the right way, since the 104 | traffic_limiter.php file is require()'d. 105 | 106 | This issue has already been reported, and a patch has been provided, 107 | in [GH61], but has not been fixed (the issue is still open). 108 | 109 | 2.4. VizHash IP Address Online Guessing 110 | 111 | Exploitability: Very Low 112 | Security Impact: Low 113 | 114 | The VizHash system is used to give users who comment an avatar 115 | derived from their IP address. If an attacker can create connections 116 | to the ZeroBin server from arbitrary source IPs (e.g. if they are in 117 | the same LAN as the ZeroBin server, or man-in-the-middling its 118 | traffic), they can perform an online guessing attack on the VizHash 119 | they are interested in. 120 | 121 | 2.5. Relies on .htaccess files, which may not be enabled. 122 | 123 | Exploitability: N/A 124 | Security Impact: Very Low 125 | 126 | ZeroBin relies on .htaccess files being enabled to prevent access to 127 | the 'data' directory. This directory contains the ciphertexts, salt, 128 | and rate limiter array. If .htaccess is disabled, of if ZeroBin is 129 | installed on a non-Apache web server, then an attacker may be able to 130 | access these files. 131 | 132 | The salt and rate limiter array are safe since they are in .php 133 | files. However, the attacker would be able to access the ciphertext. 134 | This is not a security issue because the attacker already has access 135 | to the ciphertext. 136 | 137 | If directory traversal is enabled, the attacker can see all of the 138 | post ids, too. 139 | 140 | 2.6. The robots.txt does not work in a subdomain. 141 | 142 | Exploitability: N/A 143 | Security Impact: Low 144 | 145 | ZeroBin uses a robots.txt file to prevent search engines from 146 | indexing the posts. If you install ZeroBin into a subdirectory, this 147 | does not work. A note about this should be added to the README or 148 | other documentation, so that the user knows to install the robots.txt 149 | file in the right place. 150 | 151 | 2.7 HMAC Not Compared in Constant Time 152 | 153 | Exploitability: Medium 154 | Security Impact: Low 155 | 156 | ZeroBin uses an HMAC to generate and check delete tokens. The HMAC is 157 | compared against the correct one with PHP's "!=" operator. A timing 158 | attack can exploit this error to compute the HMAC of arbitrary data 159 | with the server's salt. 160 | 161 | ZeroBin should check if the strings are equal in constant time: 162 | 163 | function slow_equals($a, $b) 164 | { 165 | $diff = strlen($a) ^ strlen($b); 166 | for($i = 0; $i < strlen($a) && $i < strlen($b); $i++) 167 | { 168 | $diff |= ord($a[$i]) ^ ord($b[$i]); 169 | } 170 | return $diff === 0; 171 | } 172 | 173 | 2.8. Arbitrary File Unlink 174 | 175 | Exploitability: Medium 176 | Security Impact: High 177 | 178 | An attacker can delete arbitrary files on the server by exploiting 179 | a vulnerability in processPasteDelete(). Here is a condensed version 180 | of the code: 181 | 182 | function processPasteDelete($pasteid,$deletetoken) 183 | { 184 | if (preg_match('/\A[a-f\d]{16}\z/',$pasteid)) 185 | { 186 | $filename = dataid2path($pasteid).$pasteid; 187 | if (!is_file($filename)) 188 | { 189 | return ... error message ... 190 | } 191 | } 192 | 193 | if ($deletetoken != hash_hmac('sha1', $pasteid , getServerSalt())) 194 | { 195 | return ... error message ... 196 | } 197 | 198 | deletePaste($pasteid); 199 | return array('','','Paste was properly deleted.'); 200 | } 201 | 202 | The $pasteid variable comes directly from $_GET['pasteid'], which the 203 | attacker can control. The $deletetoken variable comes from 204 | $_GET['deletetoken']. If $deletetoken matches the HMAC, $pasteid is 205 | passed to deletePaste(), which runs: 206 | 207 | unlink(dataid2path($pasteid).$pasteid); 208 | 209 | Thus, if an attacker can compute the HMAC, they can delete arbitrary 210 | files on the server. The HMAC can be computed if the salt is known. 211 | Forging the HMAC without already knowing the salt is easy because of 212 | Issue 2.7 and Issue 2.1. 213 | 214 | 2.9. HMAC Uses SHA1 instead of SHA256 215 | 216 | Exploitability: Very Low 217 | Security Impact: Low 218 | 219 | ZeroBin uses a SHA1 HMAC to derive the delete token. SHA1 should be 220 | replaced with a better hash function, like SHA256. 221 | 222 | 2.10. No Cross-Site Request Forgery Protection 223 | 224 | Exploitability: Medium 225 | Security Impact: Medium 226 | 227 | ZeroBin does not attempt to prevent Cross-Site Request Forgery (CSRF) 228 | attacks. A malicious website can make a user's browser delete ZeroBin 229 | posts (if the delete token is known), create posts, and post comments 230 | to existing posts. 231 | 232 | A CSRF attack to post comments can be a problem when a malicious 233 | website wants to find out the ZeroBin VizHash of its visitors, to see 234 | what they have been commenting. The attack would work as follows: 235 | 236 | 1. Alice suspects Bob posted a rude ZeroBin comment. 237 | 2. Alice generates a web page that causes Bob's browser to comment 238 | "I AM BOB!" on a ZeroBin post. 239 | 3. Alice emails a link to the malicious page to Bob. 240 | 4. Bob clicks the link. 241 | 5. Alice checks the post, sees that the "I AM BOB!" comment has the 242 | same VizHash as the rude comment. Alice now knows it was Bob 243 | that made the rude comment. 244 | 245 | 3. Coding Practices 246 | 247 | The ZeroBin code could be made more secure, and easier to audit, by 248 | following some good coding practices. These are documented in the 249 | next sections. 250 | 251 | 3.1. Always Assume Malice 252 | 253 | When a string is used in a way that might affect security, it should 254 | always be assumed to be malicious, even if it is just a constant 255 | string. The ZeroBin code does not do this, for example: 256 | 257 | - In the post creation code, it assumes $dataid is safe, which it 258 | is, since it it is a hex string from an MD5 hash, but it would be 259 | better if the code assumed it was malicious and checked/escaped 260 | it anyway. 261 | 262 | - Several strings are not escaped in tpl/page.html. $VERSION is not 263 | escaped in the header, and $STATUS is not escaped in the body. 264 | Even though these are static strings, they should be escaped 265 | anyway, since someone might change the error messages to reflect 266 | user input in the future. See Section 4.6. 267 | 268 | 4. Future Work 269 | 270 | 4.1. Secure Code Delivery 271 | 272 | ZeroBin relies on the JavaScript code being delivered securely. 273 | A malicious server or man-in-the-middle can modify the code to leak 274 | the key. This is already well known and is being addressed in [GH17]. 275 | 276 | 4.2. urls2links XSS 277 | 278 | In zerobin.js, urls2links() converts a URL text into a clickable 279 | link. The replacement is done purely by regular expression, and no 280 | escaping is done. This may be a source of XSS vulnerabilities. I did 281 | not have enough time to understand what the regular expression is 282 | doing, so I'm not sure if this is exploitable or not. 283 | 284 | There are other bits of code that look like they might be XSS 285 | vulnerabilities (e.g. line 233 in zerobin.js where divComment is 286 | set). I did not have enough time to check these in detail. 287 | 288 | 4.3. Low Entropy in Browsers Without CSPRNGs 289 | 290 | If the web browser does not have window.crypto.getRandomValues(), the 291 | key is derived from mouse movements and stuff. That may not be good 292 | enough. Perhaps in these cases the server could help the client by 293 | supplying some of its own entropy from mcrypt_create_iv() or 294 | openssl_random_pseudo_bytes(). 295 | 296 | 4.4. Plaintext is Compressed Before Encryption 297 | 298 | Posts are compressed before they are encrypted. This makes the 299 | ciphertext length depend on the plaintext content. This may create 300 | vulnerabilities in specific use cases where an attacker can choose 301 | variations of the same post to be encrypted. This would be similar 302 | to the CRIME and BREACH attacks, except happening at the application 303 | layer. 304 | 305 | 4.5. Is SJCL used correctly? 306 | 307 | This audit did not check if zerobin.js uses the SJCL cryptography 308 | library correctly. 309 | 310 | 4.6. Possible XSS in tpl/page.html 311 | 312 | JSON encoded data is inserted into the HTML page unescaped in 313 | tpl/page.html. This is because $STATUS is set to the return value of 314 | processPasteFetch(), which returns JSON encoded data based on the 315 | user's input. I did not check if this is exploitable. 316 | 317 | 5. Conclusion 318 | 319 | Several issues were found. The most critical being the arbitrary file 320 | unlink vulnerability, described in Section 2.8, and the use of 321 | mt_rand() to generate HMAC keys, described in Section 2.1. 322 | 323 | This audit did not cover the JavaScript cryptography, nor did it 324 | cover XSS vulnerabilities in the JavaScript code. More auditing time 325 | is recommended. 326 | 327 | 6. References 328 | 329 | [GH17] https://github.com/sebsauvage/ZeroBin/issues/17 330 | [GH68] https://github.com/sebsauvage/ZeroBin/issues/68 331 | [GH61] https://github.com/sebsauvage/ZeroBin/pull/61 332 | [GR] https://github.com/sebsauvage/ZeroBin 333 | [ZBW] http://sebsauvage.net/wiki/doku.php?id=php:zerobin 334 | [XSS] https://github.com/sebsauvage/ZeroBin/commit/4f8750bbddcb137213529875e45e3ace3be9a769 -------------------------------------------------------------------------------- /Defuse/Defuse_-_eCryptfs.txt: -------------------------------------------------------------------------------- 1 | ----------------------------------------------------------------------- 2 | eCryptfs Security Audit 3 | Taylor Hornby 4 | January 22, 2014 5 | ----------------------------------------------------------------------- 6 | 7 | 1. Introduction 8 | 9 | This document describes the results of a 10-hour security audit on 10 | the latest version (at time of writing) of the eCryptfs encrypted 11 | file system. It follows a previous 10-hour audit on EncFS [4]. 12 | 13 | 1.1. What is eCryptfs? 14 | 15 | eCryptfs is an encrypting file system similar to EncFS. The main 16 | difference is that it runs as a kernel module instead of on top of 17 | FUSE. 18 | 19 | 1.2. Audit Results Summary 20 | 21 | Due to the limited amount of time, this audit could only cover 22 | a small portion of eCryptfs's design and implementation. Analysis of 23 | the cryptographic design was prioritized. 24 | 25 | Documentation about eCryptfs's crypto design is sparse and 26 | contradictory. The design has changed dramatically from initial 27 | (very old) design documents like [3]. The only reliable source is the 28 | actual source code itself, which takes longer to review. 29 | 30 | Some non-critical issues were discovered while looking over 31 | eCryptfs's source code. These are documented in the next section. 32 | 33 | 2. Issues 34 | 35 | 2.1. ecryptfs-rewrap-passphrase salt reuse 36 | 37 | Exploitability: Low 38 | Security Impact: Low 39 | 40 | The ecryptfs-rewrap-passphrase command does not generate a new random 41 | salt when the password is changed. I'm not sure if this is an 42 | architectural requirement or not (I don't think so), but a new random 43 | salt would be better. 44 | 45 | 2.2. IV is the MD5 hash of key and extract (block) offset. 46 | 47 | Exploitability: Low 48 | Security Impact: Low 49 | 50 | The "Root IV" is the MD5 hash of the session encryption key, which is 51 | a per-file random key. From the Root IV, the IV for an extract 52 | (portion of the file) is generated by hashing it with the offset. 53 | 54 | This doesn't immediately lead to vulnerabilities, and it's much 55 | better than the way EncFS does it, but it doesn't seem safe. It would 56 | be much better to use proper CBC ESSIV mode or XTS mode. 57 | 58 | Correction 12/05/2014: XTS mode is probably not the ideal option, see 59 | Thomas Ptacek's blog post for good reasons why: 60 | 61 | http://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/ 62 | 63 | There is a comment in the code that derives the IV... 64 | 65 | /* TODO: It is probably secure to just cast the least 66 | * significant bits of the root IV into an unsigned long and 67 | * add the offset to that rather than go through all this 68 | * hashing business. -Halcrow */ 69 | 70 | ...which is wrong, and needs to be removed. 71 | 72 | 2.3. Filename Encryption Does Not Use IVs 73 | 74 | Exploitability: Low 75 | Security Impact: Low 76 | 77 | The file name encryption in encfs_write_tag_70_packet uses a zero IV 78 | for filename encryption. However, "random bytes" are prepended to the 79 | path before encrypting, and they are supposed to "do the job of the 80 | IV here." However, they are not actually random bytes, they are the 81 | hash the "session key encryption key." This key does not appear to 82 | change, so I doubt these bytes are serving the purpose of an IV. 83 | 84 | This may be required for determinism (so that you can look up a file 85 | path without iterating through all files in a directory), but it's 86 | a weird way of doing it. The comment does say "We do not want to 87 | encrypt the same filename with the same key and IV, which may happen 88 | with hard links, so we prepend random bits to each filename" ... but 89 | it doesn't. This needs further analysis. 90 | 91 | Prepending random IVs is not sufficient when using cipher modes other 92 | than CBC, such as GCM and CTR, which are being discussed on the 93 | mailing list [1,2]. 94 | 95 | Update (February 14, 2014): Filename encryption actually uses ECB 96 | mode, so the random bytes are useless. Thanks to @samuelks for 97 | reporting this. 98 | 99 | 3. Future Work 100 | 101 | The following sections document what should be prioritized in future 102 | audits. 103 | 104 | 3.1. The Mailing List is Discussing GCM Mode 105 | 106 | Possible Exploitability: Medium 107 | Possible Security Impact: High 108 | 109 | The eCryptfs mailing list is discussing the option of using other 110 | modes like GCM and CTR. There are already patches submitted that 111 | allow this, however, as far as I can tell, they haven't made it into 112 | the git repository. 113 | 114 | Using a stream mode like GCM would destroy eCryptfs's security, since 115 | the key stream would not depend on the plaintext and an attacker 116 | could simply XOR snapshots of a ciphertext at two different times to 117 | learn the XOR of the plaintexts that changed. This is not the case 118 | with a block mode like CBC (currently the default). 119 | 120 | 3.2. Authenticated Encryption 121 | 122 | The mailing list is discussing patches for adding authenticated 123 | encryption (GCM, HMAC, etc). There was not enough time to review 124 | these proposed changes, and I'm not sure if they're already in the 125 | released code or not. 126 | 127 | 3.3. Produce Crypto Documentation 128 | 129 | eCryptfs's current crypto implementation is not well-documented. It 130 | would be useful to create a document that describes it at a high 131 | level, so that it is easier for experienced cryptographers to review 132 | it. 133 | 134 | 4. Conclusion 135 | 136 | eCryptfs appears to have a better crypto design than EncFS [4], but 137 | there are some red flags indicating that it was not designed by 138 | a cryptographer, and has not received enough security review. It 139 | should be safe to use, but more auditing would be a good idea. 140 | 141 | 5. References 142 | 143 | [1] http://thread.gmane.org/gmane.comp.file-systems.ecryptfs.general/494 144 | 145 | [2] http://www.spinics.net/lists/ecryptfs/msg00381.html 146 | 147 | [3] http://ecryptfs.sourceforge.net/ecryptfs.pdf 148 | 149 | [4] https://defuse.ca/audits/encfs.htm -------------------------------------------------------------------------------- /Fox-IT/Fox-IT_-_DigiNotar.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Fox-IT/Fox-IT_-_DigiNotar.pdf -------------------------------------------------------------------------------- /Fraunhofer/Fraunhofer_-_TrueCrypt.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Fraunhofer/Fraunhofer_-_TrueCrypt.pdf -------------------------------------------------------------------------------- /IOActive/ioactive-bromium-test-report-final.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/IOActive/ioactive-bromium-test-report-final.pdf -------------------------------------------------------------------------------- /IndependentSecurityEvaluators/ISE_-_Apple_iPhone.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/IndependentSecurityEvaluators/ISE_-_Apple_iPhone.pdf -------------------------------------------------------------------------------- /LeastAuthority/LeastAuthority-Cryptocat-audit-report.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/LeastAuthority/LeastAuthority-Cryptocat-audit-report.pdf -------------------------------------------------------------------------------- /LeastAuthority/LeastAuthority-GlobaLeaks-audit-report.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/LeastAuthority/LeastAuthority-GlobaLeaks-audit-report.pdf -------------------------------------------------------------------------------- /Leviathan/OmniFileStore Encryption Review - FINAL - 06102016.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Leviathan/OmniFileStore Encryption Review - FINAL - 06102016.pdf -------------------------------------------------------------------------------- /Leviathan/SpiderOak-Crypton_pentest-Final_report_u.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Leviathan/SpiderOak-Crypton_pentest-Final_report_u.pdf -------------------------------------------------------------------------------- /Matasano/Matasano SourceT Security Evaluation Report.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Matasano/Matasano SourceT Security Evaluation Report.pdf -------------------------------------------------------------------------------- /Matasano/wp-multistore-security-analysis.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Matasano/wp-multistore-security-analysis.pdf -------------------------------------------------------------------------------- /OPM-OIG/OPM-OIG_-_US_Office_of_Personnel_Management.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/OPM-OIG/OPM-OIG_-_US_Office_of_Personnel_Management.pdf -------------------------------------------------------------------------------- /OffensiveSecurity/penetration-testing-sample-report-2013.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/OffensiveSecurity/penetration-testing-sample-report-2013.pdf -------------------------------------------------------------------------------- /PrincetonUni/Princeton_University_-_Diebold_AccuVote-TS.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/PrincetonUni/Princeton_University_-_Diebold_AccuVote-TS.pdf -------------------------------------------------------------------------------- /PrincetonUni/Princeton_University_-_Safeplug.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/PrincetonUni/Princeton_University_-_Safeplug.pdf -------------------------------------------------------------------------------- /ProCheckUp/CHECK-1-2012.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/ProCheckUp/CHECK-1-2012.pdf -------------------------------------------------------------------------------- /PwC/PwC_-_HM_Revenue_and_Customs.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/PwC/PwC_-_HM_Revenue_and_Customs.pdf -------------------------------------------------------------------------------- /QuarksLab/14-03-022_ChatSecure-sec-assessment.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/QuarksLab/14-03-022_ChatSecure-sec-assessment.pdf -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Public penetration testing reports 2 | 3 | Curated list of public penetration testing reports released by several consulting firms. 4 | -------------------------------------------------------------------------------- /Sakurity/Sakurity_-_Peatio.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Sakurity/Sakurity_-_Peatio.pdf -------------------------------------------------------------------------------- /SecureLayer7/Penetration-testing-report--open-source-Ruby-on-rails-Refinery-CMS.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/SecureLayer7/Penetration-testing-report--open-source-Ruby-on-rails-Refinery-CMS.pdf -------------------------------------------------------------------------------- /SecureLayer7/readme.md: -------------------------------------------------------------------------------- 1 | Uploading the SecureLayer7's pentest report of the refinery CMS 2 | -------------------------------------------------------------------------------- /TrailOfBits/Trail_of_Bits_-_Apple_iOS_4.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/TrailOfBits/Trail_of_Bits_-_Apple_iOS_4.pdf -------------------------------------------------------------------------------- /UniWashington/UW-CSE-13-08-02.PDF: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/UniWashington/UW-CSE-13-08-02.PDF -------------------------------------------------------------------------------- /Veracode/Veracode_-_Cryptocat.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Veracode/Veracode_-_Cryptocat.pdf -------------------------------------------------------------------------------- /Veracode/Veracode_-_GlobaLeaks_and_Tor2web.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/Veracode/Veracode_-_GlobaLeaks_and_Tor2web.pdf -------------------------------------------------------------------------------- /iSEC/NCC_Group_-_Ricochet.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/iSEC/NCC_Group_-_Ricochet.pdf -------------------------------------------------------------------------------- /iSEC/NCC_Group_-_phpMyAdmin.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/iSEC/NCC_Group_-_phpMyAdmin.pdf -------------------------------------------------------------------------------- /iSEC/TrueCrypt_Phase_II_NCC_OCAP_final.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/iSEC/TrueCrypt_Phase_II_NCC_OCAP_final.pdf -------------------------------------------------------------------------------- /iSEC/iSEC_Cryptocat_iOS.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/iSEC/iSEC_Cryptocat_iOS.pdf -------------------------------------------------------------------------------- /iSEC/iSEC_Wikimedia.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/iSEC/iSEC_Wikimedia.pdf -------------------------------------------------------------------------------- /iSEC/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/iSEC/iSec_Final_Open_Crypto_Audit_Project_TrueCrypt_Security_Assessment.pdf -------------------------------------------------------------------------------- /iSEC/ncc_docker_notary_audit_2015_07_31.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/iSEC/ncc_docker_notary_audit_2015_07_31.pdf -------------------------------------------------------------------------------- /iSEC/ncc_osquery_security_assessment_2016_01_25.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/iSEC/ncc_osquery_security_assessment_2016_01_25.pdf -------------------------------------------------------------------------------- /mnemonic/mnemonic_-_Norwegian_electronic_voting_system.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/SecWiki/public-pentesting-reports/e902fff074cf18e6d8fb549507e3876e949f15d9/mnemonic/mnemonic_-_Norwegian_electronic_voting_system.pdf --------------------------------------------------------------------------------