您的主機商都完成更新了嗎?

捕夢網已完成更新cpanel主機，提供您最完整、最安全的主機!

cPanel 是安裝在Web hosting的軟體，安全漏洞存在，讓攻擊者以暴力攻擊手法繞過雙重身份驗證（2FA）核實保護；換句話說，該攻擊是針對使用cPanel＆Web Host Manager（WHM）軟體的 2FA 容易受到暴力攻擊，使攻擊者能夠猜測 URL 參數並繞過 2FA。

cPanel是通常安裝在shared Web hosting的管理軟體，它允許管理員和網站使用者使用圖形使用者介面自動執行伺服器和網站管理。

其網站上，cPanel聲稱目前被數多家主機代管商所使用，以管理全球超過7,000萬個網域。

發掘所需的有效身份驗證

資安公司Digital Defense的研究人員Michael Clark和Wes Wright發現了該漏洞，追踪為CVE-2020-27641。

攻擊者可能濫用CVE-2020-27641漏洞，在數百萬個網站上安裝cPanel的帳戶繞過2FA的身分驗證，原因為cPanel的安全政策未阻止攻擊者重複提交雙重身份驗證代碼。

研究人員說明: 當啟用MFA後且沒有進行任何鎖定或延遲來防止暴力攻擊時，啟用該功能的用戶可以提交任意數量的MFA (多重身份驗證) key。

這導致了此情況：攻擊者可以在數小時內繞過帳戶的MFA保護。我們也自己測試並顯示，通過對攻擊如進行更精細的調整，可以在幾分鐘內就完成攻擊。

攻擊者只能在發掘“所知或讀取有效身份驗證”的cpanel 帳戶並繞過雙重身份驗證（2FA）。

發布安全更新

cPanel已發布安全更新，已解決這些包含cPanel和WHM版本11.92.0.2、11.90.0.17和11.86.0.32中的漏洞，可通過軟體更新下載。

在更新的cPanel版本上，為了解決這個問題，該公司在cPHulk暴力保護服務中加入了速率限制檢查，如果2FA代碼驗證失敗，就會被視為登錄失敗。

該公司在發布CVE-2020-27641安全更新後上週表示：“沒有理由相信這些漏洞公布於眾。”

因此，cPanel目前僅會發布有限的漏洞訊息。

一旦有足夠的時間允許cPanel＆WHM系統將自動更新到新版本，cPanel將發布額外有關安全議題訊息。

捕夢網已更新cpanel 協助您的主機更安全無虞!!

參考更多捕夢網

文章參考處:

https://www.bleepingcomputer.com/news/security/cpanel-2fa-bypassed-in-minutes-via-brute-force-attacks/?fbclid=IwAR14_zcbDLgji35827ciolNWgnoTS6ugPWOqzKm-e-jMqlLqi27YG3HBcvQ

The post 您的主機商更新了沒？cPanel存在漏洞 first appeared on 捕夢網 Blog.

較新版的php 7.0同時將於2018年12月起停止支援，不再提供安全性更新。php 7.1版也將在12月停止主要更新，2019之後結束安全更新。

假設駭客發現並利用了php舊版本的漏洞，全世界幾百萬網站及數不清的網站用戶將會陷入風險當中。

php官方網站的支援版本及時程表：

資料來源：php官方網站

根據國外網路科技應用的調查公司W3Techs統計指出，在他們研究的網站樣本中，使用php比例高達78.9%，而使用php5 (包含5.6及更舊的版本)的網站比例又占了60.7%。資料來源：調查公司W3Techs

這代表您的網站如果是用php 5.6或更舊的版本寫成的，明年2019年1月1日起，將被停止支援安全性更新，屆時陷入被駭或被植入惡意程式的風險。

捕夢網提醒您

請即刻查看您所使用的php版本，如需升級請立即更新。或洽捕夢網客服或業務，我們將協助您應對。

如何查看你的php版本

如果你使用的虛擬主機後台是 cpanel 管理介面

登入帳密→點「多 PHP 管理器」→即可查看php版本

如果你使用的虛擬主機後台是 plesk  管理介面

登入帳密→點「PHP 設定」→即可查看php版本

The post 邁向生命末了，php 5年底終止安全更新。幾百萬網站恐陷入風險。 first appeared on 捕夢網 Blog.

駭客於近日駭入了Linux Mint網站，於該站所供應的Linux Mint作業系統映像檔（ISO）中植入了後門程式，還入侵了Linux Mint論壇資料庫，Linux Mint作者Clement Lefebvre已證實此事，確認受影響的版本為Linux Mint 17.3肉桂版（Cinnamon edition），並呼籲論壇用戶變更密碼。

Linux Mint為一基於Ubuntu及Debian所打造的Linux作業系統，旨在提供強大又容易上手的開放源碼作業系統，根據維基媒體在2015年上半年偵測造訪該站的作業系統流量報告，若不計Android與Mac OS，Linux Mint為全球第三大受歡迎的Linux作業系統版本，僅次於Ubuntu與Fedora。

Linux Mint提供4種官方的桌面環境，分別是Cinnamon、MATE、KDE與Xfce，當中只有Cinnamon為此次攻擊的受害版本。

Linux Mint作者Clement Lefebvre於本周日（2/21）表示，駭客竄改了Linux Mint的映像檔，加入了後門程式，而且入侵了Linux Mint網站，以導引使用者下載含有後門程式的版本。

因此，在2月20日透過Linux Mint官方網站下載Linux Mint 17.3肉桂版的用戶，極有可能下載到含有後門程式的版本。

Lefebvre說明，受影響的只有當天自官網下載Linux Mint 17.3肉桂版的使用者，藉由Torrent或直接HTTP連結來下載Linux Mint 17.3肉桂版的用戶並未受到波及，此外，其他版本則未被竄改。

根據卡巴斯基實驗室（Kaspersky Lab）的分析，駭客所嵌入的是個單純的後門程式，允許駭客透過未加密的IRC連結控制，該後門程式可用來下載任何檔案、於機器上執行任何命令，也能進行分散式阻斷服務攻擊。

Lefebvre建議使用者透過”md5sum yourfile.iso”指令來確認所下載ISO的MD5簽章，以鑑定該版本的真偽，或是以DVD及USB隨身碟執行Linux Mint時檢查是否含有”/var/lib/man.cy”檔案，若有即為受駭版本，要是已安裝受駭版本，則先讓電腦離線，備份所有的個人資料，再重新安裝乾淨的作業系統，並重設所有重要服務的密碼。

文章來源:http://www.ithome.com.tw/news/104084

圖片來源:https://pixabay.com/

The post Linux Mint網站遭駭，安裝檔被植入後門 first appeared on 捕夢網 Blog.

這篇文章是一個針對惡意軟體"Linux/XOR.DDoS" 感染事件分析，該惡意軟體試圖感染真正的linux伺服器。

原文：http://blog.malwaremustdie.org/2015/06/mmd-0033-2015-linuxxorddos-infection_23.html

事件細節：

攻擊源：通過某種方式監控來到攻擊來源107.182.141.40，可以看到這個ip的一些具體資訊。

"ip": "107.182.141.40",
"hostname": "40-141-182-107-static.reverse.queryfoundry.net",
"city": "Los Angeles",
"region": "California",
"country": "US",
"loc": "34.0530,-118.2642",
"org": "AS62638 Query Foundry, LLC",
"postal": "90017",
"phone": "213"

攻擊者登錄通過ssh密碼登錄一台linux：

[2015-06-23 01:29:42]: New connection: 107.182.141.40:41625
[2015-06-23 01:29:42]: Client version: [SSH-2.0-PUTTY]
[2015-06-23 01:29:43]: Login succeeded [***/***]

然後通過shell執行了如下命令：

然後惡意軟體啟動命令在受感染機器上執行。

攻擊者使用的Web伺服器（域：44ro4.cn）面板截圖，當時採取的攻擊執行步驟。

這個web上的ip資訊：

"ip": "198.15.234.66",
"hostname": "No Hostname",
"city": "Nanjing",
"region": "Jiangsu",
"country": "CN",
"loc": "32.0617,118.7778",
"org": "AS11282 SERVERYOU INC",
"postal": "210004"

通过dig 发现该ip的一些附加域信息：

;; QUESTION SECTION:
;44ro4.cn.                      IN      A

;; ANSWER SECTION:
44ro4.cn.               600     IN      A       23.228.238.131
44ro4.cn.               600     IN      A       198.15.234.66

;; AUTHORITY SECTION:
44ro4.cn.               3596    IN      NS      ns2.51dns.com.
44ro4.cn.               3596    IN      NS      ns1.51dns.com.

下邊是更多的證據：

0x02 感染的方法，偽裝和總結

通過進一步研究惡意軟體，該軟體看起來像是ZIP壓縮檔的惡意軟體，從檔案格式上看出像是一個shell腳本的惡意軟體安裝程式見下圖：

這是Linux/XorDDOSs，這種惡意軟體的感染後使作為BOT被感染的機器，遠端控制的惡意程式，配置，拒絕IP，程式和配置。他們使用的是XOR'ed加密通信，發送預先與MD5編碼過程。該惡意軟體的精靈的主要功能是為一個隱形的DDoS攻擊的僵屍網路。

這一事件的重要亮點和惡意軟體使用：

1.  我們使用用於此惡意軟體感染的基礎設施 (攻擊者的IP來自美國主機，一個IP用於感染)

2.  總在Linux/XorDDOSs，多個主機的使用：四數控系統。三的人建議是硬編碼在主機名稱（有相關的領域），從被感染的機器接收回檔，而其中的主機充當下載伺服器被感染的機器要求後門下載可疑的惡意檔。

3.  異或加密功能是用現在解密滴，讀取設定檔從遠端主機下載（是的，它似乎被下載的設定檔），並發送通信資料。

這裡是poc：

這些是cnc 與kernel的交互資訊，這裡用到了調試神器strace.

通過惡意軟體交互分析到的dns請求：

tcpdump中的timestamp時間戳記。

08:21:20.078878 IP mmd.bangs.xorddos.40274 > 8.8.8.8: 27458+ A? aa.hostasa.org. (32)
08:21:20.080602 IP mmd.bangs.xorddos.38988 > 8.8.8.8: 44387+ A? ns4.hostasa.org. (33)
08:21:25.092061 IP mmd.bangs.xorddos.45477 > 8.8.8.8: 58191+ A? ns3.hostasa.org. (33)
08:21:25.269790 IP mmd.bangs.xorddos.51687 > 8.8.8.8: 22201+ A? ns2.hostasa.org. (33)

和cnc(hostasa.org)建立連接，注意它使用google dns的方式：

cnc（hostasa.org）回檔都是加密的，這是在2個獨立的地方初步回檔。

通過解密它的請求，這裡記錄了一些解密圖：

這裡是代碼中通訊二進位編碼部分：

下載者：

這裡是下載函數硬編碼在二進位裡

也有確鑿的證據在wireshark抓包通信中，如圖：

0x03 有趣的事實

這些都是用惡意軟體專案的原始程式碼檔，它是Linux/xor.ddos集編譯設置（在C語言中，沒有"+"。）作者很無恥的收藏了，這裡我幫他翻譯下。

惡意軟體的腳本在二進位中編碼，這是通用的很多惡意軟體在中國製造。

發現XOR加密運行安裝程式和"據說"用於解密的配置資料，在樣本我破解的關鍵是BB2FA36AAA9541F0

這是自我複製的惡意軟體的安裝檔，使用逆向工具追蹤代碼，可以看到這裡：

和這裡：

acl功能，拒絕訪問的ip，來保護受感染的主機。

0x04 對於惡意軟體作者追蹤

通過逆向分析得到的資料，cnc使用的dns記錄在下邊：

;; ANSWER SECTION:
aa.hostasa.org. 300 IN  A   23.234.60.143
ns2.hostasa.org.300 IN  A   103.240.140.152
ns3.hostasa.org.300 IN  A   103.240.141.54
ns4.hostasa.org.300 IN  A   192.126.126.64

;; AUTHORITY SECTION:
hostasa.org.3600IN  NS  ns4lny.domain-resolution.net.
hostasa.org.3600IN  NS  ns1cnb.domain-resolution.net.
hostasa.org.3600IN  NS  ns3cna.domain-resolution.net.
hostasa.org.3600IN  NS  ns2dky.domain-resolution.net.

;; ADDITIONAL SECTION:
ns3cna.domain-resolution.net. 2669 IN   A   98.124.246.2
ns2dky.domain-resolution.net. 649 INA   98.124.246.1
ns1cnb.domain-resolution.net. 159 INA   50.23.84.77
ns4lny.domain-resolution.net. 2772 IN   A   98.124.217.1

經過分析，活著的cnc（hostasa.org）伺服器在美國。

"ip": "23.234.60.143",
"hostname": "No Hostname",
"city": "Newark",
"region": "Delaware",
"country": "US",
"loc": "39.7151,-75.7306",
"org": "AS26484 HOSTSPACE NETWORKS LLC",
"postal": "19711"

"ip": "192.126.126.64",
"hostname": "No Hostname",
"city": "Los Angeles",
"region": "California",
"country": "US",
"loc": "34.0530,-118.2642",
"org": "AS26484 HOSTSPACE NETWORKS LLC",
"postal": "90017"

其他的cnc（hostasa.org）伺服器在香港。

"ip": "103.240.140.152",
"hostname": "No Hostname",
"city": "Central District",
"country": "HK",
"loc": "22.2833,114.1500",
"org": "AS62466 ClearDDoS Technologies"

"ip": "103.240.141.54",
"hostname": "No Hostname",
"city": "Central District",
"country": "HK",
"loc": "22.2833,114.1500",
"org": "AS62466 ClearDDoS Technologies"

功能變數名稱hostasa.org無法證明是用於惡意目的的懷疑，3台主機看起來像一個DNS伺服器，下面是註冊的資料來自Name.com那裡註冊.org，與隱私保護：

Domain Name:"HOSTASA.ORG"
Domain ID: 2D175880649-LROR"
"Creation Date: 2015-03-31T06:56:01Z
Updated Date: 2015-05-31T03:45:36Z"
Registry Expiry Date: 2016-03-31T06:56:01Z
Sponsoring Registrar:"Name.com, LLC (R1288-LROR)"
Sponsoring Registrar IANA ID: 625
WHOIS Server:
Referral URL:
Domain Status: clientTransferProhibited -- http://www.icann.org/epp#clientTransferProhibited
Registrant ID:necwp72276k4nva0
Registrant Name:Whois Agent
Registrant Organization:Whois Privacy Protection Service, Inc.
Registrant Street: PO Box 639
Registrant City:Kirkland
Registrant State/Province:WA
Registrant Postal Code:98083
Registrant Country:US
Registrant Phone:+1.4252740657
Registrant Phone Ext:
Registrant Fax: +1.4259744730
Registrant Fax Ext:
Registrant Email:hostasa.org@protecteddomainservices.com
Tech Email:hostasa.org@protecteddomainservices.com
Name Server:NS3CNA.DOMAIN-RESOLUTION.NET
Name Server:NS1CNB.DOMAIN-RESOLUTION.NET
Name Server:NS2DKY.DOMAIN-RESOLUTION.NET
Name Server:NS4LNY.DOMAIN-RESOLUTION.NET
DNSSEC:Unsigned

此外，所使用的44ro4.cn域，這是DNS指向惡意的payload的Web頁面，這不是巧合，這是註冊在下面的QQ ID和名稱（可能是假的）：

Domain Name: 44ro4.cn
ROID: 20141229s10001s73492202-cn
Domain Status: ok
Registrant ID: ji27ikgt6kc203
Registrant: "蔡厚泉 (Cai Hou Sien/Quan)"
Registrant Contact Email: "2511916764@qq.com"
Sponsoring Registrar: 北京新網數碼資訊技術有限公司
Name Server: ns1.51dns.com
Name Server: ns2.51dns.com
Registration Time: 2014-12-29 10:13:43
Expiration Time: 2015-12-29 10:13:43
DNSSEC: unsigned

PS：CNNIC有更多這樣的註冊資訊，我把自由查詢他們找到這個騙子用的和其他身份的幾個可憐的cn功能變數名稱，相同和不同的名字下，在同一個QQ：

Domain   RegistrantID     Name
------------------------------
n1o9n.cn ej55v35357p95m   沈濤
u7ju0.cn ej55v35357p95m   沈濤
568b5.cn ej55v35357p95m   沈濤
93t9i.cn ej55v35357p95m   沈濤
5ntdu.cn ej55v35357p95m   沈濤
v90b8.cn ej55v35357p95m   沈濤
av732.cn ej55v35357p95m   沈濤
iqny7.cn ej55v35357p95m   沈濤
ewkp7.cn ej55v35357p95m   沈濤
8vu55.cn ji27ikgt6kc203   蔡厚泉
tj17e.cn ej55v35357p95m   沈濤
o88pn.cn ji27ikgt6kc203   蔡厚泉

通過進一步的分析，發現如下資訊和功能變數名稱所有者資訊相吻合。

看起來這個功能變數名稱所有者是住在，住在附近的潭溪公交站在三元里街頭，白雲區，廣州地區，中華人民共和國，按照該地圖描述：

文章來源:http://drops.wooyun.org/tips/6711

圖片來源:https://pixabay.com/

The post linux ddos惡意軟體分析 first appeared on 捕夢網 Blog.

在linux中有5個用於審計的命令：

last：這個命令可用於查看我們系統的成功登錄、關機、重啟等情況；這個命令就是將/var/log/wtmp檔案格式化輸出。

lastb：這個命令用於查看登錄失敗的情況；這個命令就是將/var/log/btmp檔案格式化輸出。

lastlog：這個命令用於查看使用者上一次的登錄情況；這個命令就是將/var/log/lastlog檔案格式化輸出。

who：這個命令使用者查看當前登錄系統的情況；這個命令就是將/var/log/utmp檔案格式化輸出。

w：與who命令一致。

關於它們的使用：man last，last與lastb命令使用方法類似：

last [-R] [-num] [ -n num ] [-adFiowx] [ -f file ] [ -t YYYYMMDDHHMMSS ] [name…]  [tty…]

lastb [-R] [-num] [ -n num ] [ -f file ] [-adFiowx] [name…]  [tty…]

who [OPTION]… [ FILE | ARG1 ARG2 ]

參數說明：

1.查看系統登錄情況

last：不帶任何參數，顯示系統的登錄以及重啟情況

2.只針對關機/重啟

使用-x參數可以針對不同的情況進行查看

3.只針對登錄

使用-d參數，並且參數後不用跟任何選項

4.顯示錯誤的登錄資訊

lastb

5.查看當前登錄情況

who、w

0x01 日誌查看

在Linux系統中，有三類主要的日誌子系統:

連線時間日誌: 由多個程式執行，把記錄寫入到/var/log/wtmp和/var/run/utmp，login等程式會更新wtmp和utmp檔，使系統管理員能夠跟蹤誰在何時登錄到系統。（utmp、wtmp日誌檔是多數Linux日誌子系統的關鍵，它保存了用戶登錄進入和退出的記錄。有關當前登錄使用者的資訊記錄在檔utmp中; 登錄進入和退出記錄在檔wtmp中; 資料交換、關機以及重啟的機器資訊也都記錄在wtmp檔中。所有的記錄都包含時間戳記。）

進程統計: 由系統內核執行，當一個進程終止時，為每個進程往進程統計檔（pacct或acct）中寫一個記錄。進程統計的目的是為系統中的基本服務提供命令使用統計。

錯誤日誌: 由syslogd（8）守護程式執行，各種系統守護進程、使用者程式和內核通過syslogd（3）守護程式向檔/var/log/messages報告值得注意的事件。另外有許多Unix程式創建日誌。像HTTP和FTP這樣提供網路服務的伺服器也保持詳細的日誌。

日誌目錄：/var/log(預設目錄)

1.查看進程日誌

cat /var/log/messages

2.查看服務日誌

cat /var/log/maillog

0x02 用戶查看

Linux不同的用戶，有不同的操作許可權，但是所有使用者都會在/etc/passwd /etc/shadow /etc/group /etc/group- 檔中記錄；

查看詳細

less /etc/passwd：查看是否有新增用戶

grep :0 /etc/passwd：查看是否有特權用戶（root許可權用戶）

ls -l /etc/passwd：查看passwd最後修改時間

awk -F: '$3==0 {print $1}' /etc/passwd：查看是否存在特權用戶

awk -F: 'length($2)==0 {print $1}' /etc/shadow：查看是否存在空口令用戶

注：linux設置空口令：passwd -d username

0x03 進程查看

1.普通進程查看

進程中我們一般使用ps來查看進程；man ps

ps -aux：查看進程

lsof -p pid：查看進程所打開的埠及文件

2.檢查隱藏進程

ps -ef | awk '{print }' | sort -n | uniq >1

ls /proc | sort -n |uniq >2

diff 1 2

注：以上3個步驟為檢查隱藏進程

0x04 其他檢查

1.檢查檔

find / -uid 0 -print：查找特權用戶檔

find / -size +10000k -print：查找大於10000k的文件

find / -name "…" -prin：查找用戶名為…的文件

find / -name core -exec ls -l {} \;：查找core檔，並列出詳細資訊

md5sum -b filename：查看文件的md5值

rpm -qf /bin/ls：檢查檔的完整性（還有其它/bin目錄下的檔）

2.檢查網路

ip link | grep PROMISC：正常網卡不應該存在promisc，如果存在可能有sniffer

lsof -i

netstat -nap：查看不正常埠

arp -a：查看arp記錄是否正常

3.計畫任務

crontab -u root -l：查看root用戶的計畫任務

cat /etc/crontab

ls -l /etc/cron.*：查看cron檔是變化的詳細

ls /var/spool/cron/

4.檢查後門

對於linux的後門檢查，網路上有一些公開的工具，但是在不使用這些工具的前提時，我們可以通過一些命令來獲取一些資訊。

首先就是檢測計畫任務，可以參考上面；

第二：查看ssh永久連結檔：vim $HOME/.ssh/authorized_keys

第三：lsmod：檢查內核模組

第四：chkconfig –list/systemctl list-units –type=service：檢查自啟

第五：服務後門/異常埠（是否存在shell反彈或監聽）

其它：

ls /etc/rc.d

ls /etc/rc3.d

文章來源:http://drops.wooyun.org/%E8%BF%90%E7%BB%B4%E5%AE%89%E5%85%A8/11106
圖片來源:https://pixabay.com/

The post Linux入侵偵測基礎 first appeared on 捕夢網 Blog.

0x00 目錄

關於目標環境的中間進度檢測報告

１.情況概述

2.取證情況

   2.1 目標網路情況

   2.2 針對xxx伺服器中介軟體的檢測

   2.3 針對xxx伺服器進程及埠的檢測

   2.4 發現攻擊者的攻擊操作

3.溯源操作

  3.1 關於攻擊者的反向檢測

4.攻擊源確定

   4.1 確定攻擊入口處

5.安全性建議

關於目標環境的中間進度檢測報告

0x01 情況概述

監控軟體監控到伺服器存在異常的訪問請求，故對此伺服器進行安全檢查。

通過提供的材料發現內網機器對某公網網站存在異常的訪問請求，網路環境存在著異常的網路資料的訪問情況。針對其伺服器進行綜合分析發現了病毒檔兩例，內網掃描器兩例，通過以上的發現證實伺服器已被駭客入侵。

0x02 取證情況

2.1 目標網路情況

下文中的內網內ip以及公網ip為替換後的ip。

2.2 針對xxx伺服器中介軟體的檢測

監測存在異常的伺服器開放了80埠和21埠，安裝了tomcat中介軟體。首先進行tomcat中介軟體的排查，查詢得知伺服器對外開tomcat資料夾路徑為/home/XXX/tomcat/XXX _tomcat ，查詢tomcat未使用弱密碼：

圖1：tomcat未使用默認弱口令

針對tomcat部署服務進行檢查，未發現可疑部署元件：

圖2：未發現可疑的部署組件

p3 圖3：未發現可疑的host配置

2.3 針對xxx伺服器進程及埠的檢測

針對目標伺服器進行了進程以及埠的檢測，發現了可疑現象入下圖所示：

圖4:發現可疑佔用情況

發現可疑現象後查找“l”所在的路徑，入下圖所示：

圖5：發現可疑檔路徑

在/dev/shm路徑下發現存在“l”與“conf.n”文件

圖6：找到可疑文件

將“l”與“conf.n”下載到本地進行分析，“l”程式為inux遠控木馬Linux.DDOS.Flood.L，經本地分析“l”程式為linux下僵屍木馬，同時具有遠控的功能

圖7：證實為Linux.DDOS.Flood.L木馬

通過繼續分析目標伺服器中的可以進程與埠佔用情況，發現另外可疑檔，如下圖所示：

圖8：發現可疑文件vkgdqddsx

將可疑檔進行本地分析，證實此檔為病毒檔：

圖9：證實為病毒檔

2.4 發現攻擊者的攻擊操作

針對目標環境進行徹底排查，發現攻擊者使用wget操作從 http://111.205.192.5:2356伺服器中下載“l”病毒檔，並執行了“777”加權的操作。

其記錄檔如下圖所示：

圖10：發現木馬檔下載操作

圖11：通過l檔的時間狀態定位到疑似攻擊者下載時間為2015-01-18 04:54:05

圖12:定位到可疑時間段連接ip位址

圖13：不同時間段的可疑連接ip

通過進一步的對可疑。

通過分析目標伺服器日誌檔，發現攻擊者下載病毒檔後又使用內網掃描軟體“.x”調用其“pascan”和“scanssh”模組進行內網ssh掃描，通過分析發現攻擊者收集到了目標網路環境中的常用密碼來進行針對性的掃描測試。

如下圖所示：

圖14：發現目標伺服器中存在ssh爆破以及網段掃描軟體

圖15：通過在測試環境中測試發現為掃描軟體

圖16：攻擊者使用掃描軟體進行內網網段的掃描

通過繼續對掃描軟體進行深入挖掘，發現攻擊者使用掃描軟體得到的其他內網的ip位址（部分）：

圖：17 攻擊者得到的內網部分位址及密碼

嘗試使用此位址中的192.168.21.231和192.168.21.218進行ssh登錄，可使用root:huawei成功進行ssh連接（其他位址及口令不再進行測試），並在內網機器中發現使用弱口令“123456”並發現了同樣的“l”病毒檔。

其記錄檔如下圖所示：

圖18：進行ssh連接

圖19:連接成功後進行“ifconfig”操作

圖：在網路中的其他機器也發現了同樣的病毒檔

在掃描器中發現了攻擊者使用的“passfile”字典檔，從中可以發現攻擊者使用的字典具有很強的針對性（初步斷定攻擊者為在網路環境中通過查詢密碼檔等操作獲取的相關密碼）：

隱私資訊–此處不貼圖

圖20：發現針對性極強的密碼字典

通過繼續對日誌檔進行排查，發現攻擊者使用掃描器進行攻擊的歷史記錄，驗證了搜集到的資訊：

圖21：攻擊者進行攻擊的歷史記錄

通過即系分析，發現攻擊者在進入目標伺服器後，又進行了防火牆許可權修改、“udf”許可權提升、遠端連接等其他操作。其中“udf病毒檔”未在目標伺服器中發現，在後期進行反追蹤中在攻擊者伺服器中獲取到“udf”檔，進行本地檢測後病毒檔。

其記錄檔如下圖所示：

圖22: 修改iptables防火牆配置

圖23：被修改後的防火牆配置

圖24：攻擊者進行提權的操作

圖25：“udf”檔證實為病毒檔

通過對攻擊者完整的攻擊取證，可證實攻擊者通過SSH連接的方式使用guest_cm使用者而和root用戶進行遠端連接，連接之後使用Wget方式下載並種植在目標伺服器中“l”和“vkgdqddusx”病毒檔，並使用“udf”進行進一步的許可權操作，然後使用“.x”掃描軟體配合針對性極強的密碼字典進行內網的掃描入侵，並以目標伺服器為跳板使用root和xxx帳戶登錄了內網中的其他機器在入侵過程中入侵者將部分相關日誌進行了清除操作。

0x03 溯源操作

3.1 關於攻擊者的反向檢測

在取證過程中發現攻擊者伺服器使用以下三個ip

xxx.xxx.xxx.x、xxx.xxx.xxx.xxx、xxx.xx.xxx.xx（打個馬賽克）

通過對這三個IP進行溯源找到

http://111.205.192.5:2356/ 網站使用hfs伺服器搭建，檔案伺服器內存儲著各種病毒檔，其中找到了在“l”“udf”等病毒檔，證實前文中的判斷。

圖26：檔案伺服器中存儲著在本次攻擊中所使用的病毒檔

通過其他手段查詢得知使用ip位址曾綁定 www.xxxx.com網站，並查找出疑似攻擊者真實姓名xxx、xxx，其團體使用xxxxxx@qq.com、wangzxxxxxx.yes@gmail.com等郵箱，使用61441xx、3675xx等QQ。並通過某種手段深挖得知攻擊者同事運營著多個博彩、私服類網站。

其他資訊請看下圖：

圖27：攻擊團夥使用支付寶及姓名

圖28：攻擊團夥旗下的其他博彩、私服網站

圖29：攻擊者旗下部分博彩、私服網站

打碼處理

圖30：攻擊團夥成員QQ資訊

0x04 攻擊源確定

4.1 確定攻擊入口處

綜合我們對內網多台伺服器的日誌分析，發現造成本次安全事件的主要原因是：

10.0.xx.xx設備的網路部署存在安全問題，未對其進行正確的網路隔離，導致其ssh管理埠長期暴露在公網上，通過分析ssh登陸日誌，該台設備長期遭受ssh口令暴力破解攻擊，併發現存在成功暴力破解的日誌，攻擊者正是通過ssh弱口令獲取設備控制許可權，並植入木馬程式進一步感染內網伺服器。

具體攻擊流程如下圖所示：

圖31：駭客本次攻擊流程圖

圖:32：存在長期被爆破的現象

圖33：被某公網ip爆破成功進入機器

經分析，2016年1月12號公網ip為211.137.38.124的機器使用ssh爆破的方式成功登陸進入10.0.xx.xx機器，之後攻擊者以10.0.16.24機器為跳板使用相同的帳戶登錄進入192.168.xxx.xxx機器。

圖34：相同帳戶進入192.168.150.160機器

攻擊者進入192.168.150.160機器後，於2016年1月17日使用wget的方式從http://111.205.192.5:23561網站中下載了 “Linux DDos”木馬檔，並使用掃描器對內網進行掃描的操作。

圖：35攻擊者下載“Linux DDos”病毒檔

攻擊者通過相同的手段在2016年1月17日使用sftp傳輸的方式進行了木馬的擴散行為，詳細情況見下圖：

圖36:使用SFTP傳輸的方式進行木馬的擴散

0x05 安全性建議

對使用密碼字典中的伺服器進行密碼的更改。

對網路環境進行徹底的整改，關閉不必要的對外埠。

網路環境已經被進行過內網滲透，還需要及時排查內網機器的安全風險，及時處理。

SSH登錄限制

修改sshd設定檔

由於伺服器較多，防止病毒通過ssh互相傳播，可通過修改sshd_config，實現只允許指定的機器連接，方法如下：

登錄目標主機，編輯/etc/ssh/sshd_config

# vi /etc/ssh/sshd_config

在檔的最後追加允許訪問22埠的主機IP，（IP可用*號通配，但不建議）

文章來源:http://drops.wooyun.org/tips/12972
圖片來源:https://pixabay.com/

The post Linux伺服器應急事件溯源報告 first appeared on 捕夢網 Blog.

根據Google的說明，在Glibc的DNS客戶端解析器中使用getaddrinfo() 函式功能時，駭客只要在合法的DNS請求時，以過大的DNS檔案(超過2048 byte)回應，會形成堆積緩衝區溢位漏洞。將會導致駭客使用遠端控制的方式攻擊伺服器。

唯目前並未發現針對該漏洞的攻擊程式。

以下為Google官方部落格原文，有興趣者可自行閱讀

Have you ever been deep in the mines of debugging and suddenly realized that you were staring at something far more interesting than you were expecting? You are not alone! Recently a Google engineer noticed that their SSH client segfaulted every time they tried to connect to a specific host. That engineer filed a ticket to investigate the behavior and after an intense investigation we discovered the issue lay in glibc and not in SSH as we were expecting.

Thanks to this engineer’s keen observation, we were able determine that the issue could result in remote code execution. We immediately began an in-depth analysis of the issue to determine whether it could be exploited, and possible fixes. We saw this as a challenge, and after some intense hacking sessions, we were able to craft a full working exploit!

In the course of our investigation, and to our surprise, we learned that the glibc maintainers had previously been alerted of the issue via their bug tracker in July, 2015. (bug). We couldn't immediately tell whether the bug fix was underway, so we worked hard to make sure we understood the issue and then reached out to the glibc maintainers. To our delight, Florian Weimer and Carlos O’Donell of Red Hat had also been studying the bug’s impact, albeit completely independently! Due to the sensitive nature of the issue, the investigation, patch creation, and regression tests performed primarily by Florian and Carlos had continued “off-bug.”

This was an amazing coincidence, and thanks to their hard work and cooperation, we were able to translate both teams’ knowledge into a comprehensive patch and regression test to protect glibc users.

That patch is available here.

Issue Summary:

Our initial investigations showed that the issue affected all the versions of glibc since 2.9. You should definitely update if you are on an older version though. If the vulnerability is detected, machine owners may wish to take steps to mitigate the risk of an attack.

The glibc DNS client side resolver is vulnerable to a stack-based buffer overflow when the getaddrinfo() library function is used. Software using this function may be exploited with attacker-controlled domain names, attacker-controlled DNS servers, or through a man-in-the-middle attack.

Google has found some mitigations that may help prevent exploitation if you are not able to immediately patch your instance of glibc. The vulnerability relies on an oversized (2048+ bytes) UDP or TCP response, which is followed by another response that will overwrite the stack. Our suggested mitigation is to limit the response (i.e., via DNSMasq or similar programs) sizes accepted by the DNS resolver locally as well as to ensure that DNS queries are sent only to DNS servers which limit the response size for UDP responses with the truncation bit set.

Technical information:

glibc reserves 2048 bytes in the stack through alloca() for the DNS answer at _nss_dns_gethostbyname4_r() for hosting responses to a DNS query.

Later on, at send_dg() and send_vc(), if the response is larger than 2048 bytes, a new buffer is allocated from the heap and all the information (buffer pointer, new buffer size and response size) is updated.

Under certain conditions a mismatch between the stack buffer and the new heap allocation will happen. The final effect is that the stack buffer will be used to store the DNS response, even though the response is larger than the stack buffer and a heap buffer was allocated. This behavior leads to the stack buffer overflow.

The vectors to trigger this buffer overflow are very common and can include ssh, sudo, and curl. We are confident that the exploitation vectors are diverse and widespread; we have not attempted to enumerate these vectors further.

Exploitation:

Remote code execution is possible, but not straightforward. It requires bypassing the security mitigations present on the system, such as ASLR. We will not release our exploit code, but a non-weaponized Proof of Concept has been made available simultaneously with this blog post. With this Proof of Concept, you can verify if you are affected by this issue, and verify any mitigations you may wish to enact.

As you can see in the below debugging session we are able to reliably control EIP/RIP.

(gdb) x/i $rip
=> 0x7fe156f0ccce <_nss_dns_gethostbyname4_r+398>: req
(gdb) x/a $rsp
0x7fff56fd8a48: 0x4242424242424242 0x4242424242420042

When code crashes unexpectedly, it can be a sign of something much more significant than it appears; ignore crashes at your peril!

Failed exploit indicators, due to ASLR, can range from:

Crash on free(ptr) where ptr is controlled by the attacker.

Crash on free(ptr) where ptr is semi-controlled by the attacker since ptr has to be a valid readable address.

Crash reading from memory pointed by a local overwritten variable.

Crash writing to memory on an attacker-controlled pointer.

We would like to thank Neel Mehta, Thomas Garnier, Gynvael Coldwind, Michael Schaller, Tom Payne, Michael Haro, Damian Menscher, Matt Brown, Yunhong Gu, Florian Weimer, Carlos O’Donell and the rest of the glibc team for their help figuring out all details about this bug, exploitation, and patch development.

文章來源:https://googleblog.blogspot.tw/

The post Linux函式庫Glibc再現重大安全漏洞 first appeared on 捕夢網 Blog.