陷阱，誘惑，小心蜜罐
隨著安全意識的提高，現在很多大公司或者企事業(yè)單位都配置有蜜罐系統，用來識別攻擊，加強自身安全防御體系的建設。筆者前段時間對一些漏洞進行復現，也發(fā)現很多目標很容易拿到權限，但進入一看都是docker部署的，這種一般都是蜜罐。早期蜜罐系統很容易被發(fā)現，現在的蜜罐系統做的跟真的一樣，端口掃描，漏洞利用都跟預期一模一樣，就像前幾天微軟用linux來模擬代碼服務器，在測試時也有一些異常，比如shadow文件查看不像正常的文件，域名指向等等。蜜罐的識別來自實戰(zhàn)經驗積累。
前幾天朋友圈瘋狂傳Microsoft微軟某個網站（code.microsoft.com）存在RCE，可直接執(zhí)行命令：
http://code.microsoft.com/wp-content/plugins/wechat-broadcast/wechat/Image.php?url=/etc/shadow
筆者也曾經測試過，執(zhí)行該命令后，當時有一個現象，就是shadow文件內容出來了，但不是正常的linux shadow文件格式。
今日再訪問，已經無法訪問了。
一、再次分析
1.dns查看
2.crt.sh查看
3.fofo搜索
fofa搜索code.microsoft.com結果是其他東東。
4.quake查看
5.zoomeye查看
{
"paths": [
"/api",
"/api/v1",
"/apis",
"/apis/",
"/apis/admissionregistration.k8s.io",
"/apis/admissionregistration.k8s.io/v1",
"/apis/admissionregistration.k8s.io/v1beta1",
"/apis/apiextensions.k8s.io",
"/apis/apiextensions.k8s.io/v1",
"/apis/apiextensions.k8s.io/v1beta1",
"/apis/apiregistration.k8s.io",
"/apis/apiregistration.k8s.io/v1",
"/apis/apiregistration.k8s.io/v1beta1",
"/apis/apps",
"/apis/apps/v1",
"/apis/authentication.k8s.io",
"/apis/authentication.k8s.io/v1",
"/apis/authentication.k8s.io/v1beta1",
"/apis/authorization.k8s.io",
"/apis/authorization.k8s.io/v1",
"/apis/authorization.k8s.io/v1beta1",
"/apis/autoscaling",
"/apis/autoscaling/v1",
"/apis/autoscaling/v2beta1",
"/apis/autoscaling/v2beta2",
"/apis/batch",
"/apis/batch/v1",
"/apis/batch/v1beta1",
"/apis/certificates.k8s.io",
"/apis/certificates.k8s.io/v1beta1",
"/apis/coordination.k8s.io",
"/apis/coordination.k8s.io/v1",
"/apis/coordination.k8s.io/v1beta1",
"/apis/discovery.k8s.io",
"/apis/discovery.k8s.io/v1beta1",
"/apis/events.k8s.io",
"/apis/events.k8s.io/v1beta1",
"/apis/extensions",
"/apis/extensions/v1beta1",
"/apis/networking.k8s.io",
"/apis/networking.k8s.io/v1",
"/apis/networking.k8s.io/v1beta1",
"/apis/node.k8s.io",
"/apis/node.k8s.io/v1beta1",
"/apis/policy",
"/apis/policy/v1beta1",
"/apis/rbac.authorization.k8s.io",
"/apis/rbac.authorization.k8s.io/v1",
"/apis/rbac.authorization.k8s.io/v1beta1",
"/apis/scheduling.k8s.io",
"/apis/scheduling.k8s.io/v1",
"/apis/scheduling.k8s.io/v1beta1",
"/apis/storage.k8s.io",
"/apis/storage.k8s.io/v1",
"/apis/storage.k8s.io/v1beta1",
"/healthz",
"/healthz/autoregister-completion",
"/healthz/etcd",
"/healthz/log",
"/healthz/ping",
"/healthz/poststarthook/apiservice-openapi-controller",
"/healthz/poststarthook/apiservice-registration-controller",
"/healthz/poststarthook/apiservice-status-available-controller",
"/healthz/poststarthook/bootstrap-controller",
"/healthz/poststarthook/crd-informer-synced",
"/healthz/poststarthook/generic-apiserver-start-informers",
"/healthz/poststarthook/kube-apiserver-autoregistration",
"/healthz/poststarthook/rbac/bootstrap-roles",
"/healthz/poststarthook/scheduling/bootstrap-system-priority-classes",
"/healthz/poststarthook/start-apiextensions-controllers",
"/healthz/poststarthook/start-apiextensions-informers",
"/healthz/poststarthook/start-cluster-authentication-info-controller",
"/healthz/poststarthook/start-kube-aggregator-informers",
"/healthz/poststarthook/start-kube-apiserver-admission-initializer",
"/livez",
"/livez/autoregister-completion",
"/livez/etcd",
"/livez/log",
"/livez/ping",
"/livez/poststarthook/apiservice-openapi-controller",
"/livez/poststarthook/apiservice-registration-controller",
"/livez/poststarthook/apiservice-status-available-controller",
"/livez/poststarthook/bootstrap-controller",
"/livez/poststarthook/crd-informer-synced",
"/livez/poststarthook/generic-apiserver-start-informers",
"/livez/poststarthook/kube-apiserver-autoregistration",
"/livez/poststarthook/rbac/bootstrap-roles",
"/livez/poststarthook/scheduling/bootstrap-system-priority-classes",
"/livez/poststarthook/start-apiextensions-controllers",
"/livez/poststarthook/start-apiextensions-informers",
"/livez/poststarthook/start-cluster-authentication-info-controller",
"/livez/poststarthook/start-kube-aggregator-informers",
"/livez/poststarthook/start-kube-apiserver-admission-initializer",
"/logs",
"/metrics",
"/openapi/v2",
"/readyz",
"/readyz/autoregister-completion",
"/readyz/etcd",
"/readyz/log",
"/readyz/ping",
"/readyz/poststarthook/apiservice-openapi-controller",
"/readyz/poststarthook/apiservice-registration-controller",
"/readyz/poststarthook/apiservice-status-available-controller",
"/readyz/poststarthook/bootstrap-controller",
"/readyz/poststarthook/crd-informer-synced",
"/readyz/poststarthook/generic-apiserver-start-informers",
"/readyz/poststarthook/kube-apiserver-autoregistration",
"/readyz/poststarthook/rbac/bootstrap-roles",
"/readyz/poststarthook/scheduling/bootstrap-system-priority-classes",
"/readyz/poststarthook/start-apiextensions-controllers",
"/readyz/poststarthook/start-apiextensions-informers",
"/readyz/poststarthook/start-cluster-authentication-info-controller",
"/readyz/poststarthook/start-kube-aggregator-informers",
"/readyz/poststarthook/start-kube-apiserver-admission-initializer",
"/readyz/shutdown",
"/version"
]
}二、蜜罐
1.蜜罐定義
蜜罐系統或蜜罐技術在網絡攻防中扮演著重要角色，它是一種主動的防御策略，旨在通過模擬易受攻擊的系統、服務或信息來吸引并誘騙潛在的攻擊者。蜜罐系統是一種網絡安全技術，旨在誘使攻擊者攻擊虛假或特意弱化的系統，從而收集有關攻擊者行為和策略的信息。這些系統被用于網絡防御和安全研究，有助于識別潛在的網絡威脅并改進防御策略。
2.蜜罐系統分類
蜜罐系統可以分為兩類：高交互蜜罐和低交互蜜罐。
高交互蜜罐：這種類型的蜜罐模擬完整的操作系統環(huán)境，提供了豐富的服務和功能，與真實系統幾乎無法區(qū)分。攻擊者與高交互蜜罐進行交互時，其活動被記錄和監(jiān)視，以獲取關于攻擊者技術、意圖和策略的詳細信息。
低交互蜜罐：低交互蜜罐模擬了有限的服務和功能，通常僅限于模擬特定的漏洞或服務。這種類型的蜜罐雖然不能提供與真實系統完全相同的體驗，但由于其輕量級和易于部署的特點，仍然是收集攻擊信息的有效工具。
3.基本概念
- 欺騙與監(jiān)控：蜜罐的核心在于設置陷阱，這些陷阱對攻擊者而言看似是具有吸引力的真實目標，但實際上是為了監(jiān)控和記錄攻擊行為而特意設計的。
- 信息收集：通過蜜罐，防御者可以收集關于攻擊者工具、戰(zhàn)術、技術和程序（TTPs）的寶貴情報，包括攻擊入口點、漏洞利用方式、橫向移動策略等。
- 風險隔離：蜜罐通常不包含任何真實或敏感數據，因此即使被攻破也不會造成實際損害，同時保護了真實的系統和資產。
4.蜜網（Honeynet）
- 蜜網是蜜罐技術的擴展，它不是一個單獨的系統，而是一個由多個相互連接的蜜罐組成的網絡，能夠提供更全面的監(jiān)控和分析環(huán)境。
- 這個網絡系統可能包括多種類型的蜜罐，每個都有特定的設計目標，用于捕捉不同類型的攻擊或針對不同層次的威脅。
- 蜜網增加了攻擊者識別的難度，同時提供了更深入的視角來觀察攻擊者的行為模式。
5.使用目的
- 早期預警：蜜罐能夠作為網絡安全的前哨站，預警潛在的威脅。
- 攻擊分析：收集的攻擊數據有助于安全團隊理解新興威脅，及時修補漏洞，優(yōu)化防御措施。
- 消耗攻擊資源：通過吸引并占用攻擊者的注意力和資源，蜜罐可以分散對真正關鍵系統的攻擊壓力。
- 法律證據：記錄的攻擊活動可以作為法律訴訟中的證據。
6.實現原理
- 偽裝與仿真：蜜罐模仿真實系統的服務和響應，讓攻擊者信以為真。
- 監(jiān)控與日志：系統詳盡記錄所有與蜜罐的交互，包括網絡包、系統日志、命令行操作等。
- 數據分析：利用自動化工具和人工分析來解析收集的數據，識別攻擊模式和趨勢。
三、蜜罐技術產品
1.國外蜜罐產品
一些常見的蜜罐產品包括：
- Cowrie: Cowrie 是一個基于 Python 的 SSH/Telnet 蜜罐，旨在模擬 SSH 和 Telnet 服務，并記錄攻擊者的行為。
- Honeyd: Honeyd 是一個虛擬蜜罐框架，可以模擬各種網絡服務，并產生大量的虛假網絡流量，以吸引攻擊者。
- Kippo: Kippo 是一個交互式 SSH 蜜罐，可以模擬 SSH 服務，并記錄攻擊者的輸入和行為，以便分析和防御。
- Glastopf: Glastopf 是一個 Web 應用蜜罐，可以模擬各種 Web 服務，并記錄攻擊者的 Web 請求和攻擊行為。
- Thug: Thug 是一個低交互式蜜罐，可以模擬 Web 瀏覽器，并記錄惡意網站的行為和攻擊代碼。
- DTK (Damn Vulnerable Linux)：一個故意設計漏洞的Linux發(fā)行版，常用于蜜罐部署和安全教育。
- Conpot：專注于工業(yè)控制系統的蜜罐，模擬SCADA系統來檢測針對工控網絡的攻擊。
2.國內蜜罐產品
- 知道創(chuàng)宇-創(chuàng)宇蜜罐：這是知道創(chuàng)宇公司推出的一款蜜罐產品，專門設計用于模擬真實環(huán)境，吸引并監(jiān)測攻擊者的行為，提供攻擊預警與行為分析功能。
- 長亭科技-諦聽：長亭科技開發(fā)的諦聽蜜罐系統，同樣著眼于高仿真度和高交互性，能夠有效吸引攻擊者并收集其攻擊手法與意圖。
四、蜜罐技術識別及發(fā)現
識別一個系統是否為蜜罐涉及多種技術和方法，以下是一些常用的策略：
1.配置失真與資源搶奪
檢查系統配置是否存在異常，比如在同一臺機器上運行不同平臺的服務，如Windows Web服務器與Linux FTP服務器共存，這可能表明配置失真。
嘗試執(zhí)行一些資源密集型任務或復雜命令，看系統是否有異常反應或資源分配不合理。
2.數據包時間戳分析
分析網絡流量的時間戳，蜜罐可能因為虛擬化環(huán)境或模擬服務導致響應時間異常或不符合預期。
3.網絡響應分析
仔細觀察系統對不同請求的響應，真正的系統與蜜罐在響應速度、錯誤信息、服務版本細節(jié)等方面可能存在差異。
4.環(huán)境不真實導致的穿幫
尋找環(huán)境中的不一致性，比如不合理的文件結構、缺失的常見系統文件或過于“干凈”的系統。
5.BOF(Buffer Overflow)識別
利用特定的緩沖區(qū)溢出攻擊測試，蜜罐可能因為缺乏完整操作系統環(huán)境而對某些攻擊無響應或響應異常。
6.假代理技術與Honeypot Hunter軟件
使用工具如Honeypot Hunter來檢測蜜罐特有的指紋或響應模式。
7.Honeyd識別
對于使用Honeyd等知名蜜罐軟件搭建的系統，可以通過特定的檢測手段識別其特征。
8.利用Sebek識別蜜網
Sebek是一種監(jiān)控工具，廣泛應用于蜜網中。通過檢測系統中是否存在Sebek或類似監(jiān)控軟件的痕跡來判斷。
9.Tarpits識別
觀察系統是否故意延時響應，模擬緩慢的服務，這可能是Tarpit技術(故意拖延攻擊者時間)的跡象。
10.外聯數據控制識別
監(jiān)測系統對外的通信，蜜罐往往限制或監(jiān)控所有出站連接，異常的網絡訪問控制規(guī)則可能是線索。
11.虛擬機檢測
由于蜜罐常用虛擬機部署，可通過檢測硬件指紋、性能指標或特定虛擬化環(huán)境特征來識別。
結合以上方法，并結合經驗和直覺，攻擊者或安全研究人員可以提高識別蜜罐的準確性。然而，隨著蜜罐技術的進步，識別難度也在增加，因此這些方法并非絕對可靠，需要不斷更新知識和技術手段。
