享的內(nèi)容

本次分享一下作為一個CTF菜雞與如下“搞笑”代碼的糟心偶遇。

(上圖[1]，下圖[4]，然而實際上類似的代碼到處都是，也許你公司的代碼倉也已經(jīng)被“攻占”)

References：

[1]. https://www.jianshu.com/p/b854e97fb856.

[2]. https://stackoverflow.com/questions/13433529/android-4-2-broke-my-encrypt-decrypt-code-and-the-provided-solutions-dont-work.

[3]. https://www.jb51.net/article/40941.htm.

[4]. https://github.com/GcsSloop/encrypt/blob/master/encryptlib/src/main/java/com/gcssloop/encrypt/symmetric/AESUtil.java.

[5]. https://github.com/GcsSloop/encrypt/issues/4

[6]. https://www.it1352.com/558636.html

[7]. https://stackoverflow.com/questions/36813098/securerandom-provider-crypto-unavailable-in-android-n-for-deterministially-gen

開始講糟心的偶遇故事

作為一只CTF菜雞，當(dāng)遇到一道送分APP題時，是多么的開心；但是因為菜，這么簡單的開心，ta就是不給你！

題目思路：

l 使用私有的Base64算法(代號：PBase64)處理了flag的密文(代號：PBase64.en(AES.en(flag)))，而私有的Base64算法，實際上只是對標(biāo)準(zhǔn)Base64算法的table進(jìn)行了替換；

l 密文(AES.en(flag))為flag使用固定的密鑰，使用AES算法加密得到；//此處AES實現(xiàn)與[4]一致~

l 需要對部分代碼進(jìn)行逆運算得出PBase64.en(AES.en(flag))，處理邏輯主要為亦或，逆運算還是亦或。//開心是吧？

解題思路：

1. 反編譯APK拿到代碼；

2. 簡單寫個Java程序，逆出PBase64.en(AES.en(flag))；

3. 根據(jù)私有Base64算法的table和標(biāo)準(zhǔn)Base64算法table的字符對應(yīng)關(guān)系，由PBase64.en(AES.en(flag))還原出Base64.en(AES.en(flag))，使用標(biāo)準(zhǔn)的Base64庫decode計算得到AES.en(flag)；

4. 摳出APK里AES的實現(xiàn)，本地寫個程序調(diào)用AES的decrypt方法使用固定密鑰解密獲得flag，得分！

1&2&3都很順利，但是Too Young Too Simple！ 你就是解密不出來：Such issues can arise if a bad key is used during decryption。

暈，難道是菜雞誤會了題目？ 等公布答案，看看大佬們的Writeup學(xué)習(xí)一下吧。

。。。。。。

暈，不就是我這思路解的嗎！Base64.en(AES.en(flag))都和我算的是一樣的，為啥我就解密不出來？

。。。。。。(搗鼓了半天)

原來是SecureRandom在Windows平臺和Android平臺不一致導(dǎo)致，導(dǎo)致密鑰不一致，分析題目的時候沒仔細(xì)看(需要反省)，密鑰還有這么生成的！神了，也許這才是這個題目的精髓吧？

So 為什么說這段代碼是“搞笑”的？

這位老哥給出了完美答案[7]：

根據(jù)密碼學(xué)實踐，Java的SecureRandom原本就不應(yīng)該用來派生密鑰，而應(yīng)該使用更為專業(yè)的密鑰派生算法，比如PBKDF2；因為SecureRandom的具體表現(xiàn)，依賴底層隨機數(shù)發(fā)生器的實現(xiàn)，如果隨機數(shù)發(fā)生器不一致，即使你set的種子seed(不同的封裝中參數(shù)名可能不一樣，如[1]中就叫seed，[4]中叫password)一樣，結(jié)果也會不一樣，導(dǎo)致不同平臺甚至不同Android SDK版本計算得出的密鑰都不一樣；也就會出現(xiàn)一個平臺加密的密文，使用同樣的password，在另外的平臺解密不出明文的異常情況，即CTF菜雞本次的遭遇。

理論上正確的實踐(使用PBKDF2或類似算法派生密鑰)，應(yīng)該出現(xiàn)在各大公司的安全編碼規(guī)范、安全設(shè)計規(guī)范、密碼學(xué)應(yīng)用規(guī)范等等文檔中。

但是，隨便搜索一下，會發(fā)現(xiàn)使用類似邏輯派生密鑰的AES封裝以及相關(guān)帖子[1]~[7]隨處可見，說明壞代碼的擴散能力和好代碼一樣強。甚至有兄弟分析了為什么這種方案Windows和Linux上跨平臺解密異常的情況，還給出了“解決方案[6]”，但卻不是把SecureRandom換成類似PBKDF2這樣的專業(yè)算法的滿分答案，可惜了。

再扯一個很容易被忽視的SecureRandom使用實踐吧

Java的SecureRandom是一個可以用來高效產(chǎn)生密碼學(xué)意義的安全隨機數(shù)的偽隨機數(shù)發(fā)生器，它還是個偽隨機數(shù)發(fā)送器，并不是真隨機數(shù)發(fā)生器，多用在某些需求密碼學(xué)意義的安全隨機數(shù)場景，如AES的IV值。

但是呢，千萬要注意，這種場景下，千萬千萬千萬千萬千萬不要手動給SecureRandom實例setSeed，就像上面提到的“搞笑”代碼一樣。

因為set了固定的或不安全的種子seed后，Java的SecureRandom就退化為一個純純的偽隨機數(shù)發(fā)生器，也就產(chǎn)生不了密碼學(xué)意義的安全隨機數(shù)。