3b92e - Posted: January Mon 9th 1:59 PM (Never Expires) - Format: bash
  1. I'm glad more people are in here now. It gets much, much worse than this.
  2.  
  3. The post below literally says "if you have the password, you can generate the key and open the file.
  4.  
  5. The real exploit is that you don't need the password or the key to open a file.
  6.  
  7. That is how serious this is. It is really bad. It is not a joke.
  8.  
  9. Some of you are joining now and seeing how bad the weak KDF is that they're using. It gets much worse.
  10.  
  11. The salt is not a random number. It is a side channel that leaks information about the passphrase. This reduces the entropy of the search space, so that it now becomes possible to brute force.
  12.  
  13. The REAL exploit is what's going on with memory management. The ENGINE plugin literally modifies the code during the compile, so what you think it's doing isn't what's being done. It's one of the most insane things I've ever seen in my life. You can see it if you compile and then decompile the code.
  14.  
  15. It's basically the same thing they did with Heartbleed, but on steroids. Same exact design pattern. Memory management is so thoroughly skewered that you might as well think of the entire thing as a secret data structure.
  16.  
  17. If you really want to see what is happening here, just go look in the random number generator. It is not random. They do all sorts of stuff in the entropy pool to make it look like the time, date, process id, etc are all involved. Then they clear the buffer in a call to ENGINE (!!) which throws all of that out, pops stuff off of the secret data structure.
  18.  
  19. There are race conditions in the entropy pool. There are actually even comments telling you this.
  20.  
  21. There is actually a comment in the entropy pool saying something like, "we are not ambitious to provide *information-theoretic* randomness." Or, translated into plain English, "I am a contractor who is trying to warn people the random number generator is not random."
  22.  
  23. There are times when they even have comments in the code telling people not to worry about valgrind complaining that uninitialized memory is being used to seed the bufer. Again, translated into plain English, "I am a contractor, and you should definitely worry about this."
  24.  
  25. There is, I swear to god, a comment right in the decrypt function that basically says "PADDING ORACLE HERE." It is insane. They didn't even take it out.
  26.  
  27. The whole thing is ruined. If you are just tuning in now, read the writeup posted before. Seriously, you are in for a hell of a ride.
  28. -------------------------------------------------------------------------------------------
  29. # One error and one missing step in 5) have been corrected.
  30. # Procedure now 100% verified
  31.  
  32. You can actually get the full key.
  33.  
  34. This is how it works.
  35.  
  36. first half of the key = MD5(password+salt)
  37. second half of the key = first half + MD5(first half+password+salt)
  38.  
  39. Let's prove this step by step.
  40.  
  41. openssl enc -aes-256-cbc -p -in 000svgLA.7z -out test.aes -salt -k p@ssword
  42. salt=596C09F4AFCC2B9D
  43. key=DD73502243215E39A0CDDE52CF5AB975EAA8F8DA936B35650308113E42DF8862
  44. iv =322ACE8546EBA994AF17A1BC5DC999B1
  45.  
  46. We wan't to get the key value. Let's do it.
  47.  
  48. 1.) Save the salt:
  49. perl -e 'print pack "H*", "596C09F4AFCC2B9D"' > salt
  50.  
  51. 2.) Save the password:
  52. echo -n p@ssword > keyhalf
  53.  
  54. 3.) Add them (password+salt):
  55. cat salt >> keyhalf
  56.  
  57. 4.) Get the first half of the key:
  58. md5sum keyhalf
  59. dd73502243215e39a0cdde52cf5ab975  keyhalf
  60.  
  61. Compare to the full key:
  62. DD73502243215E39A0CDDE52CF5AB975 EAA8F8DA936B35650308113E42DF8862
  63.  
  64. Checks out. So now we need the rest.
  65.  
  66. We can easily get it with the information we have so far since we now know that it's = first half + MD5(first half+password+salt)
  67.  
  68. 5.) Save the part of the key we already have:
  69. perl -e 'print pack "H*", "DD73502243215E39A0CDDE52CF5AB975"' > key
  70. echo -n p@ssword > password
  71. cat key > keysecond
  72.  
  73. 6.) Add the password:
  74. cat password >> keysecond
  75.  
  76. 7.) Add the salt:
  77. cat salt >> keysecond
  78.  
  79. 8.) Get the second half of the key:
  80. md5sum keysecond
  81. eaa8f8da936b35650308113e42df8862  keysecond
  82.  
  83. Compare to second half:
  84. EAA8F8DA936B35650308113E42DF8862
  85.  
  86. In step 4.) we got dd73502243215e39a0cdde52cf5ab975
  87. In step 8.) we got eaa8f8da936b35650308113e42df8862
  88.  
  89. dd73502243215e39a0cdde52cf5ab975 eaa8f8da936b35650308113e42df8862
  90. DD73502243215E39A0CDDE52CF5AB975 EAA8F8DA936B35650308113E42DF8862
  91.  
  92. We have the full key. We only used MD5 and didn't write a single line of code.
  93.  
  94. Note that this the current version of OpenSSL.
  95. There is no patch that can fix the files that have already been encrypted.
  96.  
  97. RIP OpenSSL.
  98.  
  99. ------------------------------------------------------
  100. this is crazy...
  101.  
  102. ------------------------------------------------------
  103. >the first 16 bytes of the key will be equal to MD5(password||salt)
  104.  
  105. Let's test this.
  106.  
  107. openssl enc -aes-256-cbc -pass pass:p@ssword -p -in 000svgLA.7z -out testfile.aes
  108. salt=C532A7E7BFFBAD69
  109. key=9104D17FB6C06D9B0F8368D52678FD4B88DF2E244029BF068EED22DD816A5DBC
  110. iv =B08DB48DCF6CAC52C6CF040FB06A0809
  111.  
  112. python pwdsalt2key.py 'p@ssword' 'C532A7E7BFFBAD69'
  113. 9104D17FB6C06D9B0F8368D52678FD4B
  114. 9104D17FB6C06D9B0F8368D52678FD4B88DF2E244029BF068EED22DD816A5DBC
  115.  
  116. pwdsalt2key.py
  117. http://gateway.glop.me/ipfs/QmbYCbZYsViLSAy7ht6iNpecyCeoTWBonsLPtHDa6bX6Ku/pwdsalt2key.py
  118. https://zerobin.net/?7ff571d39efdcd1c#uBSr6l6vCFq1EA95h3SQSmK4KVN9rAlMx/58uGRgN0o=
  119.  
  120. ------------------------------------------------------
  121. *********************************************************************
  122. ORACLE:
  123. https://blog.cloudflare.com/yet-another-padding-oracle-in-openssl-cbc-ciphersuites/
  124. https://github.com/FiloSottile/CVE-2016-2107
  125.  
  126. Explanation: https://blog.cloudflare.com/yet-another-padding-oracle-in-openssl-cbc-ciphersuites/
  127. Code: https://github.com/FiloSottile/CVE-2016-2107
  128. Internal discussion: https://www.openssl.org/news/secadv/20160503.txt
  129. Exploit: https://www.exploit-db.com/exploits/39768/
  130. Damage control: http://web-in-security.blogspot.ca/2016/05/curious-padding-oracle-in-openssl-cve.html
  131. 'Fix': https://git.openssl.org/?p=openssl.git;a=commitdiff;h=68595c0c2886e7942a14f98c17a55a88afb6c292;hp=643e8e972e54fa358935e5f8b7f5a8be9616d56b
  132. Compiled information: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2107
  133.  
  134. *********************************************************************
  135. BLOCKS AND SIZE:
  136. (ls -l, head -c 256)
  137.  
  138. There is also this weird comment in enc.c, line 431:
  139. /*
  140. * zero the complete buffer or the string passed from the command
  141. * line bug picked up by Larry J. Hughes Jr. <hughes@indiana.edu>
  142. */
  143. if (str == strbuf)
  144. OPENSSL_cleanse(str, SIZE);
  145. else
  146. OPENSSL_cleanse(str, str_len);
  147.  
  148. The memcpy() routine is explicitly not safe if the source and destination buffers overlap. This can happen when the EVP_enc_null() cipher is used to decrypt longer text than BUF_OFFSET bytes because of this code in bio_enc.c:
  149. EVP_CipherUpdate(&(ctx->cipher),
  150. (unsigned char *)ctx->buf, &ctx->buf_len,
  151. (unsigned char *)&(ctx->buf[BUF_OFFSET]), i);
  152. It's the overwrite of the ctx->buf memory that is the problem.
  153. Saw this on a SUSE 12 SP2 machine. It is not necessarily repeatable on other machines. Valgrind also complained.
  154. https://github.com/openssl/openssl/issues/1935
  155.  
  156. You should use EVP_ENCODE_LENGTH to determine the required output buffer size:
  157. https://github.com/openssl/openssl/blob/master/include/openssl/evp.h#L458
  158. *********************************************************************
  159. MEMORY:
  160. (https://www.hex-rays.com/products/decompiler/)
  161.  
  162. >Mem allocator isn't actually an allocator, it's LIFO system that allows the devs to be sloppy and access "already free()d memory", I notice that they alloc in EVP_BytesToKey, whereas LibreSSL does not.
  163.  
  164. >double free
  165. https://github.com/guidovranken/openssl-x509-vulnerabilities
  166. http://seclists.org/fulldisclosure/2016/Oct/62
  167. There are many other instances of double frees in the code.
  168.  
  169. *********************************************************************
  170. 3SAT:
  171. (https://github.com/msoos/cryptominisat)
  172. (http://baldur.iti.kit.edu/sat-competition-2016/solvers/main/)
  173.  
  174. >You need to do linear correleation attack on the bit vectors and other annoying things. You can reduce entropy down to 64+32 bits and then its within brute force range with ASIC.
  175.  
  176. >For 3-sat Solver you just download it off of github. There are dozens.
  177.  
  178. >The problem is getting the md5 and aes circuit into 3-SAT, CNF form. You may need to take the C code for the decryption functions and md5 hashing functions, then compile it to verilog. See if there is a way.
  179.  
  180. >You have to represent the hash function as a circuit in CNF.
  181.  
  182. >128 Bit is breakable in 40 seconds with 3-SAT attack. Its not breakable with brute force.
  183. *********************************************************************
  184. MD5 PBKDF1:
  185. (http://blog.thireus.com/cracking-story-how-i-cracked-over-122-million-sha1-and-md5-hashed-passwords/)
  186. (https://github.com/qsantos/rainbow)
  187.  
  188. >"The first 16 bytes are actually derived using PBKDF1 as defined in PKCS#5 v1.5.
  189. The next 16 bytes would be MD5(PBKDF1(PASSWORD, SALT) || PASSWORD || SALT)
  190. and the IV would be MD5(MD5(PBKDF1(PASSWORD, SALT) || PASSWORD || SALT) || PASSWORD || SALT)"
  191.  
  192. >PBKDF1(PASSWORD, SALT) = MD5(PASSWORD || SALT), where || is concatenation
  193.  
  194. ^^There is an idea that this decimates the entropy to 2^128, assuming each of the first 128 passphrases hashes to a unique MD5. However, it's tricky, because you have to find the right preimage to compute the full key, as well as the IV. However, if you have some way to identify that you have the first 128 bits right, then finding collisions for it is easy, since a collision attack on MD5 exists. Either way, this is pretty weak and it's crazy that it's there.
  195.  
  196. > EVP_BytesToKey uses an outrageously weak KDF (basically MD5 salted and iterated a couple times), and drops the entropy down to 128 bits at least.
  197.  
  198. >The process by which the password and salt are turned into the key and IV is not documented, but a look at the source code shows that it calls the OpenSSL-specific EVP_BytesToKey() function, which uses a custom key derivation function with some repeated hashing. This is a non-standard and not-well vetted construct (!) which relies on the MD5 hash function of dubious reputation (!!); that function can be changed on the command-line with the undocumented -md flag (!!!); the "iteration count" is set by the enc command to 1 and cannot be changed (!!!!). This means that the first 16 bytes of the key will be equal to MD5(password||salt), and that's it.
  199.  
  200. >I will tell you a secret.
  201. >To decrypt the insurance file. Make sure to archive this before it disappears.
  202. >The EVP_BytesToKey key derivative algorithm uses md5. It is trivial to break the key for the first block.
  203. *********************************************************************
  204. CONTENT:
  205. (binwalk, diff, comm, head/tail -c)
  206. >See if the filename, file contents, or choice of key or IV changes the salt. (I believe I saw the key choice did not change the salt)
  207.  
  208. Download: http://gateway.glop.me/ipfs/QmZudb4s2nF5JgdeFA1nKzs6MtvaPr58rR4LzddZqYir3s/evp_test.py
  209. It recreates EVP_BytesToKey completely outside of OpenSSL.
  210. Example:
  211. python evp_test.py md5 'p@ssword' '64 97 22 63 0B 61 9D 74'
  212.  
  213. salt=649722630B619D74
  214. key=F6EEA040C6BDD0EF1429C4CF4FE09FD3EA1C9BDE96B6B41DBFF838E408628BBE
  215. iv=576F54891CADC222492E038F8ECE557A
  216. *********************************************************************
  217. AES:
  218. (http://www.lifl.fr/~bouillag/implementation.html)
  219.  
  220. http://gateway.glop.me/ipfs/QmUUm47AkBuv2atQVLBPjTrVhaXQRDj9bNTqErkaP2TNwB/papers.zip
  221. http://gateway.glop.me/ipfs/QmZHXz3g6LBNGYknFMLZbtdTawTNDt8dQByauk5fmFLb2k/aestools.zip
  222. https://mega.nz/#!cI9jUAoQ!VGJnhIlTU5YBhIXTNLBfhasER6qxfsD_ho3PO_U5oSs
  223. https://mega.nz/#!0BN3lRYT!G172BViFAInD2gTOsyZOZ56zHC4nNA1DHHwP7RliT6U
  224.  
  225. If people are saying the first block of the insurance files contains "runs of zeros," then here's what that looks like.
  226. Suppose that AES(block, key) encrypts a block with a key. Then the first block looks like the following equation:
  227. AES(IV,key) ^ ciphertext = plaintext
  228. Where ^ is XOR.
  229. Now: if the plaintext were ALL zeros, that would mean
  230. AES(IV,key) ^ ciphertext = 0000000…
  231. which means
  232. AES(IV,key) = ciphertext
  233.  
  234. But, the IV and key are generated in completely deterministic fashion from the key and the salt. And we have the salt. So that first function really becomes
  235. F(passphrase) = ciphertext
  236. for a certain F.
  237. *********************************************************************
  238.  
  239.  
  240.  
  241. ------------------------------------------------------
  242. openssl enc -aes-256-cbc -pass pass:p@ssword -p -d -in testfile.aes -out test1
  243.  
  244. salt=2F140A2A667109B6
  245. key=460EBADE3CCC9AD2E6D223EB119435F947CC802044295EA90793AEC981AE3183
  246. iv =20E75E1E60ADF1C345E420EB9CD935BA
  247.  
  248. openssl enc -aes-256-cbc -pass pass:WRONG_PASSWORD -p -d -in testfile.aes -out test2
  249.  
  250. salt=2F140A2A667109B6
  251. key=C44D5867FFE37E08397DE9A4CC8058EAED59C20EB66759D7F78C960C2B91A200
  252. iv =5F5A6DFC5CCF0A50AD7502BD047076CE
  253. bad decrypt
  254. 140687120832160:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539:
  255.  
  256. openssl enc -aes-256-cbc -pass pass:WRONG_PASSWORDxxxxxxx -p -d -in testfile.aes -out test2b
  257. salt=2F140A2A667109B6
  258. key=4D44D8C33DD754B64F460A69DA4E4F722678CBF04C44A03C7DB2B5AE4499C9E4
  259. iv =4EABEE050D7D4C29F83B7134BE9FDF21
  260. bad decrypt
  261. 140683261372064:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539:
  262.  
  263. head -c 2560 testfile.aes > snippet
  264.  
  265. openssl enc -aes-256-cbc -pass pass:p@ssword -p -d -in snippet -out test3
  266.  
  267. salt=2F140A2A667109B6
  268. key=460EBADE3CCC9AD2E6D223EB119435F947CC802044295EA90793AEC981AE3183
  269. iv =20E75E1E60ADF1C345E420EB9CD935BA
  270. bad decrypt
  271. 140591540508320:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539:
  272.  
  273. openssl enc -aes-256-cbc -pass pass:WRONG_PASSWORD -p -d -in snippet -out test4
  274.  
  275. salt=2F140A2A667109B6
  276. key=C44D5867FFE37E08397DE9A4CC8058EAED59C20EB66759D7F78C960C2B91A200
  277. iv =5F5A6DFC5CCF0A50AD7502BD047076CE
  278. bad decrypt
  279. 140213217490592:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:539:
  280.  
  281. ls -l
  282.  
  283. 5083502  test1
  284. 5083488  test2
  285. 5083488  test2b
  286. 2528         test3
  287. 2528         test4
  288.  
  289. strings test1 > s1
  290. strings test2 > s2
  291. strings test2b > s2b
  292. strings test3 > s3
  293. strings test4 > s4
  294. strings testfile.aes > as
  295. strings snippet > ss
  296.  
  297. ls -l
  298.  
  299. s1 352345
  300. s2 351306
  301. s2b 352104
  302. s3 153
  303. s4 156
  304. ss 186
  305. as 352191
  306.  
  307. binwalk test1
  308.  
  309. DECIMAL       HEXADECIMAL     DESCRIPTION
  310. --------------------------------------------------------------------------------
  311. 0             0x0             7-zip archive data, version 0.3
  312.  
  313. binwalk test2
  314.  
  315. DECIMAL       HEXADECIMAL     DESCRIPTION
  316. --------------------------------------------------------------------------------
  317.  
  318. binwalk test2b
  319.  
  320. DECIMAL       HEXADECIMAL     DESCRIPTION
  321. --------------------------------------------------------------------------------
  322.  
  323. binwalk test3
  324.  
  325. DECIMAL       HEXADECIMAL     DESCRIPTION
  326. --------------------------------------------------------------------------------
  327. 0             0x0             7-zip archive data, version 0.3
  328.  
  329. binwalk test4
  330.  
  331. DECIMAL       HEXADECIMAL     DESCRIPTION
  332. --------------------------------------------------------------------------------
  333.  
  334. binwalk snippet
  335.  
  336. DECIMAL       HEXADECIMAL     DESCRIPTION
  337. --------------------------------------------------------------------------------
  338. 0             0x0             OpenSSL encryption, salted, salt: 0x2F140A2A667109B6
  339.  
  340. binwalk testfile.aes
  341.  
  342. DECIMAL       HEXADECIMAL     DESCRIPTION
  343. --------------------------------------------------------------------------------
  344. 0             0x0             OpenSSL encryption, salted, salt: 0x2F140A2A667109B6
  345.  
  346.  
  347. head -c 8 test1
  348. 7z��'
  349. head -c 8 test2
  350. ��`@R��
  351. head -c 8 test2b
  352. ��nZ�
  353.  
  354. head -c 8 test3
  355. 7z��'
  356. head -c 8 test4
  357. ��`@R��
  358. tail -c 8 test1
  359. W[��
  360. tail -c 8 test2
  361. a  ��ܹ�
  362. tail -c 8 test3
  363. �!��H\�
  364.  
  365. tail -c 8 test4
  366. �O��$�
  367.  
  368. tail -c 8 snippet
  369. �(���
  370. tail -c 8 testfile.aes
  371. �s��Q�
  372.  
  373.  
  374. hachoir-subfile test1
  375. [+] Start search on 5083502 bytes (4.8 MB)
  376. [+] File at 0 size=5083502 (4.8 MB): Compressed archive in 7z format
  377. [+] File at 4139258 size=27418666 (26.1 MB): MS-DOS executable
  378. [+] End of search -- offset=5083502 (4.8 MB)
  379.  
  380. hachoir-subfile test2
  381. [+] Start search on 5083488 bytes (4.8 MB)
  382. [+] File at 1605181 size=18645165 (17.8 MB): MS-DOS executable
  383. [+] File at 3773184 size=15678389 (15.0 MB): MS-DOS executable
  384. [+] File at 4786234 size=2034059 (1.9 MB): MS-DOS executable
  385. [+] End of search -- offset=5083488 (4.8 MB)
  386.  
  387. hachoir-subfile test2b
  388. [+] Start search on 5083488 bytes (4.8 MB)
  389. [+] End of search -- offset=5083488 (4.8 MB)
  390.  
  391. hachoir-subfile test3
  392. [+] Start search on 2528 bytes (2528 bytes)
  393. [+] File at 0 size=5083502 (4.8 MB): Compressed archive in 7z format
  394. [+] End of search -- offset=2528 (2528 bytes)
  395.  
  396. hachoir-subfile test4
  397. [+] Start search on 2528 bytes (2528 bytes)
  398. [+] End of search -- offset=2528 (2528 bytes)
  399.  
  400. hachoir-subfile snippet
  401. [+] Start search on 2560 bytes (2560 bytes)
  402. [+] End of search -- offset=2560 (2560 bytes)
  403.  
  404. hachoir-subfile testfile.aes
  405. [+] Start search on 5083520 bytes (4.8 MB)
  406. [+] File at 1292169 size=18091181 (17.3 MB): MS-DOS executable
  407. [+] File at 3813667 size=11944255 (11.4 MB): MS-DOS executable
  408. [+] End of search -- offset=5083520 (4.8 MB)
  409.  
  410.  
  411. ------------------------------------------------------
  412. Alright - the holidays are over. We laughed, we cried, we did lots of math. Time to finish the job and bring it all home.
  413.  
  414. In this thread, we will start to make this concrete with OpenSSL.
  415.  
  416. Applying some of the ideas here, what we really want to do with OpenSSL is decrypt a file with a random key (or passphrase), and then let it fail. But, unfortunately, OpenSSL leaks "information" about why it fails (padding oracle, etc). So, if you test a bunch of random passwords, you can collect this leaked information, and use it to narrow down the search space (!!!!) for the next round of tests.
  417.  
  418. THUS, YOU NEVER HAVE TO BRUTE FORCE THE ENTIRE SEARCH SPACE. That is the big idea.
  419.  
  420. You instead brute force a small random "representative sample" of the search space, gather the leaked information as a set of experimental "results," and adjust your probability distribution (and as a result, the entropy) accordingly, use that to rule out HUGE sections of the search space in the next round of tests, then repeat and iterate towards a solution.
  421.  
  422. Rather than try to re-derive the math here from scratch, let's try a concrete example. The following 7z on archive.org is about 5 MB, completely public domain under CC0, and contains SVGs of all the Tic-Tac-Toe games (as used on Wikipedia):
  423.  
  424. Details: https://archive.org/details/000svgLA.7z
  425. Direct Download: https://archive.org/download/000svgLA.7z/000svgLA.7z
  426.  
  427.  
  428. Now, so that we can ALL have the same file, simply do the following commands:
  429.  
  430. $ wget https://archive.org/download/000svgLA.7z/000svgLA.7z
  431. ...
  432.  
  433. $ openssl enc -aes-256-cbc -pass pass:p@ssword -S 2F140A2A667109B6 -p -in 000svgLA.7z -out testfile.aes
  434. salt=2F140A2A667109B6
  435. key=460EBADE3CCC9AD2E6D223EB119435F947CC802044295EA90793AEC981AE3183
  436. iv =20E75E1E60ADF1C345E420EB9CD935BA
  437.  
  438. $ sha256sum -b testfile.aes
  439. b5210324b21f88e83601d8aa2b940622258c3aab459d9476570f9ec427157574 *testfile.aes
  440.  
  441. And now we're all on the same page here. The last line is just to confirm you have the right file.
  442.  
  443.  
  444.  
  445. So, now we want to take all of this stuff and do some tests. Here's three sample "Bad Decrypts" with the password set to "WRONG_PASSWORD":
  446.  
  447. $ openssl enc -aes-256-cbc -pass pass:WRONG_PASSWORD -p -d -in testfile.aes -out testdecrypt.7z
  448. salt=2F140A2A667109B6
  449. key=C44D5867FFE37E08397DE9A4CC8058EAED59C20EB66759D7F78C960C2B91A200
  450. iv =5F5A6DFC5CCF0A50AD7502BD047076CE
  451. bad decrypt
  452. 140341122025112:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529:
  453.  
  454. $ openssl enc -aes-256-cbc -pass pass:WRONG_PASSWORD -p -d -in testfile.aes -out testdecrypt.7z
  455. salt=2F140A2A667109B6
  456. key=C44D5867FFE37E08397DE9A4CC8058EAED59C20EB66759D7F78C960C2B91A200
  457. iv =5F5A6DFC5CCF0A50AD7502BD047076CE
  458. bad decrypt
  459. 140164202464920:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529:
  460.  
  461. $ openssl enc -aes-256-cbc -pass pass:WRONG_PASSWORD -p -d -in testfile.aes -out testdecrypt.7z
  462. salt=2F140A2A667109B6
  463. key=C44D5867FFE37E08397DE9A4CC8058EAED59C20EB66759D7F78C960C2B91A200
  464. iv =5F5A6DFC5CCF0A50AD7502BD047076CE
  465. bad decrypt
  466. 140193671071384:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:529:
  467.  
  468.  
  469. Note the three numbers we get:
  470.  
  471. 1. 140341122025112
  472. 2. 140164202464920
  473. 3. 140193671071384
  474.  
  475.  
  476. You can see it's different every time, so some randomness is involved here. This number is, also, what the padding oracle is mysteriously spitting out.
  477.  
  478. The question is, what the hell does this number mean, and how do we interpret these results?

Enter new version of [ 3b92e ] :

Paste Options:

Recent Pastes:

14 days ago

a7682

27 days ago

4fc54

185 days ago

10819

207 days ago

HOW_TO_HACK_FH2.txt

221 days ago

md5

223 days ago

a78a0

230 days ago

4d8a6

260 days ago

3b92e

1230 days ago

intro