引賽門鐵殼的消息:
賽門鐵克表示其研究人員已監控到中國已出現兩個應用程序被黑客利用溢出感染。
谷歌已採取行動來解決問題,並在兩週前給手機制造商發佈補丁,但是補丁尚未普及到各手機用戶手中。與此同時,谷歌還在其遊戲市場掃描該溢出。不過谷歌無法保證消費者從其他網站下載軟件的安全性。
安全研究公司BlueBox 在今年 7月3日首先公佈發現谷歌主密鑰漏洞。據悉,Android操作系統可以合法掃描包含加密簽名的所有Android應用程序,並且程序不會被篡改。但是BlueBox表示已經發現一種方法可以在更改應用程序代碼的同時不會影響加密簽名。並且BlueBox提出警告,這項技術可以被用來在Android設備上安裝木馬,閱讀設備上的任何數據、竊取密碼、複製電話號碼、拍照並執行其他功能。
根據賽門鐵克報告,黑客已經利用這個漏洞安裝Android.Skullkey惡意軟件。該惡意軟件能夠從被感染手機讀取數據並獲取該手機收發的短信,甚至能夠將被感染手機變成惡意攻擊者的短信服務付費方。
賽門鐵克還表示已監控到中國市場兩款應用程序已被掛馬,並在報告裏提醒該公司預計攻擊者將會繼續利用這個漏洞來感染毫無戒備的Android設備用戶。
這個漏洞現在已經很清晰了,引我一篇舊博客:
https://gist.github.com/poliva/36b0795ab79ad6f14fd8
問題:
The appearance of two files with identical names in a JAR/ZIP/APK archive will provide application scanners with a simple signature for detecting modified archives and, presumably,
說白了,就是一個zip裏面部署了2個同名的dex。一個簽名一致的,一個篡改了的也就是簽名不一致的。
安裝時校驗簽名的時候是用的framework的ZipFile實現,用的是沒修改的class.dex,認證通過。而安裝完畢dexopt的時候,使用修改過class.dex。 這其實沒問題。
關鍵的問題就是同名entry的問題,就是一個zip裏面同名dex的問題。
下面的代碼修復就是檢測同名的:
原代碼:
for (int i = 0; i < numEntries; ++i) {
ZipEntry newEntry = new ZipEntry(hdrBuf, bin);
mEntries.put(newEntry.getName(), newEntry);
}
修補後:
for (int i = 0; i < numEntries; ++i) {
ZipEntry newEntry = new ZipEntry(hdrBuf, bin);
String entryName = newEntry.getName();
if (mEntries.put(entryName, newEntry) != null) {
throw new ZipException("Duplicate entry name: " + entryName);
}
}
POC:
既然這個漏洞可以重打包而且不改簽名。那麼漏洞來源最大的可能就是第三方電子市場。。。
當您打開第三方電子市場客戶端的時候,你都可以看到可升級應用這個選項。。。。這兒完全可以悄悄的給你全部升級成邪惡軟件。而且不用任何提示。
另外用戶自行下載軟件時,如果不是主動發起的升級,然該軟件安裝過程中,出現替換應用。。。那可能是碰見是邪惡的升級了。。。
當然,大部分人民都是好的,就是有這麼一小撮,不太和諧,大家擦亮眼睛。