陷阱，誘惑，小心蜜罐
隨著安全意識的提高，現在很多大公司或者企事業單位都配置有蜜罐系統，用來識別攻擊，加強自身安全防御體系的建設。筆者前段時間對一些漏洞進行復現，也發現很多目標很容易拿到權限，但進入一看都是docker部署的，這種一般都是蜜罐。早期蜜罐系統很容易被發現，現在的蜜罐系統做的跟真的一樣，端口掃描，漏洞利用都跟預期一模一樣，就像前幾天微軟用linux來模擬代碼服務器，在測試時也有一些異常，比如shadow文件查看不像正常的文件，域名指向等等。蜜罐的識別來自實戰經驗積累。
前幾天朋友圈瘋狂傳Microsoft微軟某個網站（code.microsoft.com）存在RCE，可直接執行命令：
http://code.microsoft.com/wp-content/plugins/wechat-broadcast/wechat/Image.php?url=/etc/shadow
筆者也曾經測試過，執行該命令后，當時有一個現象，就是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.蜜罐系統分類
蜜罐系統可以分為兩類：高交互蜜罐和低交互蜜罐。
高交互蜜罐：這種類型的蜜罐模擬完整的操作系統環境，提供了豐富的服務和功能，與真實系統幾乎無法區分。攻擊者與高交互蜜罐進行交互時，其活動被記錄和監視，以獲取關于攻擊者技術、意圖和策略的詳細信息。
低交互蜜罐：低交互蜜罐模擬了有限的服務和功能，通常僅限于模擬特定的漏洞或服務。這種類型的蜜罐雖然不能提供與真實系統完全相同的體驗，但由于其輕量級和易于部署的特點，仍然是收集攻擊信息的有效工具。
3.基本概念
- 欺騙與監控：蜜罐的核心在于設置陷阱，這些陷阱對攻擊者而言看似是具有吸引力的真實目標，但實際上是為了監控和記錄攻擊行為而特意設計的。
- 信息收集：通過蜜罐，防御者可以收集關于攻擊者工具、戰術、技術和程序（TTPs）的寶貴情報，包括攻擊入口點、漏洞利用方式、橫向移動策略等。
- 風險隔離：蜜罐通常不包含任何真實或敏感數據，因此即使被攻破也不會造成實際損害，同時保護了真實的系統和資產。
4.蜜網（Honeynet）
- 蜜網是蜜罐技術的擴展，它不是一個單獨的系統，而是一個由多個相互連接的蜜罐組成的網絡，能夠提供更全面的監控和分析環境。
- 這個網絡系統可能包括多種類型的蜜罐，每個都有特定的設計目標，用于捕捉不同類型的攻擊或針對不同層次的威脅。
- 蜜網增加了攻擊者識別的難度，同時提供了更深入的視角來觀察攻擊者的行為模式。
5.使用目的
- 早期預警：蜜罐能夠作為網絡安全的前哨站，預警潛在的威脅。
- 攻擊分析：收集的攻擊數據有助于安全團隊理解新興威脅，及時修補漏洞，優化防御措施。
- 消耗攻擊資源：通過吸引并占用攻擊者的注意力和資源，蜜罐可以分散對真正關鍵系統的攻擊壓力。
- 法律證據：記錄的攻擊活動可以作為法律訴訟中的證據。
6.實現原理
- 偽裝與仿真：蜜罐模仿真實系統的服務和響應，讓攻擊者信以為真。
- 監控與日志：系統詳盡記錄所有與蜜罐的交互，包括網絡包、系統日志、命令行操作等。
- 數據分析：利用自動化工具和人工分析來解析收集的數據，識別攻擊模式和趨勢。
三、蜜罐技術產品
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發行版，常用于蜜罐部署和安全教育。
- Conpot：專注于工業控制系統的蜜罐，模擬SCADA系統來檢測針對工控網絡的攻擊。
2.國內蜜罐產品
- 知道創宇-創宇蜜罐：這是知道創宇公司推出的一款蜜罐產品，專門設計用于模擬真實環境，吸引并監測攻擊者的行為，提供攻擊預警與行為分析功能。
- 長亭科技-諦聽：長亭科技開發的諦聽蜜罐系統，同樣著眼于高仿真度和高交互性，能夠有效吸引攻擊者并收集其攻擊手法與意圖。
四、蜜罐技術識別及發現
識別一個系統是否為蜜罐涉及多種技術和方法，以下是一些常用的策略：
1.配置失真與資源搶奪
檢查系統配置是否存在異常，比如在同一臺機器上運行不同平臺的服務，如Windows Web服務器與Linux FTP服務器共存，這可能表明配置失真。
嘗試執行一些資源密集型任務或復雜命令，看系統是否有異常反應或資源分配不合理。
2.數據包時間戳分析
分析網絡流量的時間戳，蜜罐可能因為虛擬化環境或模擬服務導致響應時間異常或不符合預期。
3.網絡響應分析
仔細觀察系統對不同請求的響應，真正的系統與蜜罐在響應速度、錯誤信息、服務版本細節等方面可能存在差異。
4.環境不真實導致的穿幫
尋找環境中的不一致性，比如不合理的文件結構、缺失的常見系統文件或過于“干凈”的系統。
5.BOF(Buffer Overflow)識別
利用特定的緩沖區溢出攻擊測試，蜜罐可能因為缺乏完整操作系統環境而對某些攻擊無響應或響應異常。
6.假代理技術與Honeypot Hunter軟件
使用工具如Honeypot Hunter來檢測蜜罐特有的指紋或響應模式。
7.Honeyd識別
對于使用Honeyd等知名蜜罐軟件搭建的系統，可以通過特定的檢測手段識別其特征。
8.利用Sebek識別蜜網
Sebek是一種監控工具，廣泛應用于蜜網中。通過檢測系統中是否存在Sebek或類似監控軟件的痕跡來判斷。
9.Tarpits識別
觀察系統是否故意延時響應，模擬緩慢的服務，這可能是Tarpit技術(故意拖延攻擊者時間)的跡象。
10.外聯數據控制識別
監測系統對外的通信，蜜罐往往限制或監控所有出站連接，異常的網絡訪問控制規則可能是線索。
11.虛擬機檢測
由于蜜罐常用虛擬機部署，可通過檢測硬件指紋、性能指標或特定虛擬化環境特征來識別。
結合以上方法，并結合經驗和直覺，攻擊者或安全研究人員可以提高識別蜜罐的準確性。然而，隨著蜜罐技術的進步，識別難度也在增加，因此這些方法并非絕對可靠，需要不斷更新知識和技術手段。
