Secured by Kika (=ˆ꒳ˆ=)

 ## 公告 目前我的網站轉移到這：  kika secures 部落格 相關的文章會慢慢轉移至這邊 有時間的話我會持續更新 有點忙忙 QAQ 謝謝關注 <3

前言 最近發現自己對於封包分析的理解就卡在使用 Wireshark Filter 而已 XD  有夠愚蠢 💧 於是開始研究簡單的 Wireshark 用法以及判斷惡意流量的方式 為了避免本人腦抽，筆者把自己透過 HTB 學習封包分析的路徑畫成下圖～讓大家方便有效地學習！ 學習路徑參考 當然，實際的經驗也是挺重要的，大家有興趣也可以參考： 1. TryHackMe 的 Traffic Analysis Essentials  2. HackTheBox 的 Network Traffic Analysis 系列 等等 簡單地了解惡意行為 👿 筆者簡單將惡意行為分成幾種：探測、嘗試讓你掛掉連別的、誘導你上當，以及繞過你的安全機制（當然也有可能是複合的情況，此處簡單舉例之）～ 探測（Reconnaissance） ： 攻擊者先透過各種掃描手段來了解你的網路架構，例如使用 Nmap 掃 port、分析 beacon frame、或是觀察 Wi-Fi 加密方式，藉此找出漏洞下手。 嘗試讓你掛掉連別的（Denial or Forced Disconnection） ： 像是 deauthentication 攻擊，就是逼你從原本的 Wi-Fi 斷線，好讓你誤連到假的（evil-twin）AP；或者利用 fragmentation 攻擊導致設備資源耗盡，造成 DoS。 誘導你上當（Social Engineering / Phishing） ： 例如建立仿冒的登入頁面收集密碼，或是假裝是公司內部的 AP 引導使用者連線並輸入敏感資訊。 繞過你的安全機制（Evasion） ： 例如透過封包切割繞過防火牆與入侵偵測系統（IDS），或偽裝成合法設備（如 MAC spoofing）來取得內部網路的權限。 了解基礎款攻擊 我們在此分成幾類，從實體層到應用層 ～可以先簡單看過名詞就好 👀 攻擊層級分類 實體層（Physical Layer） 攻擊範圍：裝置硬體、訊號干擾 常見手法： 無線干擾（Jamming） 裝設 USB 惡意設備（例如 Rubber Ducky） 替換設備硬體（Supply Chain Attack） 資料連結層 / 無線層（Data Link / Wireless Layer） 攻擊範圍：MAC 位址、Wi-Fi...

前言 最近筆者忙著衝刺 OSCP Lab，過程中發現了一個有趣的小東西： PHP Wrapper 。 其中有個特別讓人眼睛一亮的東東： data:// 。 那時候我心裡想， data://  ... 怎麼長得跟之前看到的 「 瀏覽器支援的 內嵌資源格式 」 ：「 data: 」 有 87% 相似？ 結果這個念頭就剛好戳中我的強迫症，忍不住想把兩者 好好整理、比較一下 。 👾 PHP wrapper 的 data:// 危險在哪？ 什麼是 PHP 的 data:// 它是  PHP 官方提供的「虛擬檔案協定」 。  讓你可以用「字串」來模擬成一個「檔案」給 PHP 讀取。   會被  include() 、 file_get_contents() 、 fopen()  等函數當成檔案來處理 。 為什麼危險？ 本來 PHP 讀的是「伺服器上的檔案」。 攻擊者卻可以透過 LFI 等漏洞，把 data:// 這種「假的檔案」塞進去。 最後讓 PHP 讀取、甚至「執行」這些字串內容。 舉例來說： include('data://text/plain;base64,PD9waHAgZXZhbCgnY2F0IC9ldGMvcGFzc3dkJyk7ID8+'); 這行會讓 PHP 執行這段 base64 編碼過的惡意 PHP 程式碼 。 本質上的風險：   原本應該只能從硬碟讀的檔案，卻被攻擊者用 data:// 偷渡進來。  不用上傳檔案、不用寫入磁碟，光靠一段字串，就能讓伺服器乖乖幫忙執行惡意程式碼。 💣 Client 端的 data: URL 危險在哪？ 什麼是 Client 的 data: URL   是瀏覽器支援的 內嵌資源格式 。  可以用來嵌入圖片、HTML、PDF、CSS 等等。 常見例子： < img src = "data:image/png;base64,...." /> 為什麼危險？ 1. 攻擊者可以把惡意內容藏在 data: URL 裡面 。 例如： data:text/html;base64,xxxx -> 直接夾帶 XSS 攻擊內容。 data:application/octet-stream;base64,xxxx -...

Log ，我到底要記錄什麼？ 前言 最近筆者開始要準備上工，無意間接觸到「Log 記錄」的議題，於是開始著手研究它。 自從開始擔任顧問後，我的視角從單純的開發者，逐漸拓展至企業層面與內部人員的需求。 現在的我開始嘗試從「合規」與「導入實務」的角度切入，並歸納出一套可供初步參考的思維架構，針對不同企業規模與需求，逐步拆解背後的問題邏輯。 捫心自問時間 在正式進入「優化你我的 Log」之前，先來個捫心自問的時刻： 你的系統， 有明確的合規要求 嗎？ 還是你只是 希望讓 Log 記錄更清晰、好用、有效 ？😉 這兩種出發點，會直接影響你後續的 Log 設計邏輯與優先順序： 合規導向 的 Log，通常是為了滿足法規、稽核標準與保留期限的要求。這類設計需要強調操作可追溯性、角色辨識與完整性。 優化導向 的 Log，則更著重於開發與維運需求，包括除錯便利性、使用行為分析、效能監控，甚至 強化異常偵測與安全預警 的能力。 釐清需求，是打造良好 Log 記錄策略的第一步，也是你省下大量重構成本的起點。 法規 Review 接下來，我們就先針對「法規」的部分，先做進一步地釐清。 根據不同產業別，需要做的事情也會不同，筆者列出幾個跟「Log」有一些關聯的法規。 常見法規與內容說明 1. ISO 27001:2022  適用機構： 希望建立資訊安全管理系統（ISMS）並取得 ISO 國際認證的各類組織（如政府機構、金融業、科技業、醫療單位、雲端服務商等）。 條文相關內容： 8.15 存錄 紀錄活動、異常、錯誤及其他相關事件之日誌，應產生、儲存、保護及分析之。 2. 金融機構資通安全防護基準 適用機構： 金融各類機構。 條文相關內容： 第四條、營運環境管理人員應符合下列要求： 五、除代登系統外於登入作業系統進行 系統異動或資料庫存取 時，應留存人為操作紀錄，並於使用後儘速變更密碼；但因故無法變更密碼者， 應建立監控機制，避免未授權變更，並於使用後覆核其操作紀錄。 八、加解密程式或具變更權限之公用程式（如資料庫工具程式）應列管並限制使用，防止未經授權存取並保留稽核軌跡。 九、 最高權限帳號使用時應先取得權責主管或授權人員同意並保留稽核軌跡 。 第五條、個人資料保護應符合下列要求： 五、應針對核心資通系統及各類電腦系統建置留存個人資料使用稽核軌跡（如登入帳號、...

前言 SSL / TLS ? 最近筆者剛轉職，正要進行第一個專案 👾 在某次 Sync 的會議中突然被問到： 舊版本的 SSL/TLS 為什麼危險，應該知道吧？  腦中突然浮現：「啊！之前在看 Microsoft 官方文檔確實有看到這塊，它建議升版 o.o」 好了，問題來了！ 那更深層次的問題，以及如何清楚解釋，我知道嗎？ 於是就有了這篇的誕生 ☺ 讓我們看下去吧！ 為什麼過去的 SSL/TLS 舊版協定比較危險？ 先聊聊什麼是 SSL/TLS SSL（Secure Sockets Layer）/  TLS（Transport Layer Security） 是一種用來 加密網路連線 的安全協定，用來確保你和網站之間傳輸的資料 不會被偷看、不會被竄改。 TLS 是 SSL 的後續版本，目前已發展到 TLS 1.3，具備更高的安全性與效能；舊版本如 SSL 3.0、TLS 1.0 和 1.1 已被淘汰，現代網站多採用 TLS 1.2 或 TLS 1.3 作為主流標準。 相關重點：SSL/TLS 握手（以 TLS 1.2 為例） 當 TLS 或 SSL 連線開始時，雙方會進行一個關鍵步驟叫做：「握手（Handshake）」。 這就像談戀愛前的「 確認彼此身分與溝通規則 」，要談情說愛之前，得先確定你是誰、我們怎麼講話、要不要加密、用哪種暗號（Cipher Suite）😇 握手的過程像是以下這樣： 關鍵澄清： 上方的圖片代表的是邏輯步驟，實際上這五個步驟不等於五個「RTT（Round Trip Time）」～ TLS 1.2 的實際 RTT 解釋如下：   在 TLS 1.2 中，完成一次完整握手大約需要「兩次往返（2-RTT）」的傳輸時間：  1. 第一個 RTT：  Client 發送 Client Hello（我支援這些 Cipher Suites）  Server 回應 Server Hello + 憑證 + Key Exchange + Hello Done  2. 第二個 RTT：  Client 發送 Client Key Exchange + Change Cipher Spec + Finished  Server 回應 Change Cipher Spec ...

前言 一個奇怪的夢境 說來也奇妙，今天夢到自己被飛船接走了 o.o 醒來後說不上來的精力充沛 @@ 直覺要我繼續去寫部落格跟學資安（？） 感謝 canva AI 產圖 最近我一直在探索自己的使命（?），同時也持續挑戰 OSCP Lab 👾 在閱讀「Common Web Attacks」的時候，無意間接觸到了「日誌中毒（Log Poisoning）」這個概念，讓我忍不住想更深入了解： 為什麼我們僅僅透過修改 HTTP Header，就可以污染伺服器的 log，甚至讓它被當成程式碼執行呢？  

資安標準:系統化地看待標準 😺何謂資安標準? 資安標準是為了確保資訊安全而制定的規範與準則，旨在降低網路攻擊風險、保護資料完整性、確保系統可用性，以及維護機密性。 常見的資安標準有很多，而這些標準通常由國際組織、政府機構或產業聯盟制定，以 指導企業、機構及個人如何有效實施資安措施 。 💜為什麼我們需要它? 這是一個相當有趣的問題，大家可以想想看已經紅了很久的議題: 數位轉型。 不知道讀者們有沒有想過: 當我們執行了數位轉型，會有什麼連帶的影響? 是變夯了? 變潮了? 還是資安威脅變多了 XD 數位轉型確實帶來了許多便利，但也讓網路威脅的攻擊面大幅擴張。企業需要確保新技術的安全性，而這正是資安標準存在的意義。 我們可以從以下的層面來看 ： 降低資安風險 ：透過標準化的安全控制措施，減少攻擊面。 符合法規要求 ：許多國家與產業要求遵守特定資安標準，如 GDPR（歐盟一般資料保護規範）。 提升信任度 ：遵循標準可向客戶、合作夥伴及投資者展示資訊安全能力。 簡化安全管理 ：標準提供明確的指南，使組織能夠系統化管理資安。 👾常見資安框架/標準 筆者在此介紹一個標準 & 一個框架來讓讀者有個初步的認識 ~ ISO 27001（資訊安全管理標準，ISMS） 簡單來說 ： 這是一個國際標準，指導企業如何建立 資訊安全管理機制 ，確保資料不外流、不被攻擊或意外遺失。 它的核心是 風險管理 ，強調 先找出可能的安全問題，然後降低風險 。 適用於任何組織，無論是企業、政府機構，甚至學校，都可以用來強化資安。 重點 ✔️ 風險評估 ：識別組織內的資安風險，例如：資料外洩、駭客攻擊。 ✔️ 安全控制 ：建立標準流程來防範這些風險，例如：存取權限管理、定期審查、備份機制。 ✔️ 持續改善 ：透過內部稽核與資安評估，確保企業安全機制符合標準。 簡單理解 ： ISO 27001 就像是一套 公司資安管理規則 ，確保企業內部對資訊安全有一套明確的方法來執行與監控，而不只是隨機處理資安事件。 不同版本的 ISO 27001 ： 演進與變化  💫 ISO 27001:2013（舊版）  包含 114 項控制措施，分為 14 個領域（如存取控制、密碼管理、營運安全等）。  著重於風險管理，確保企業識別、評估和降低資訊安全風險。 適用於各類型組織，但當時的技術環...

何謂零信任? 「零信任」是一種網路安全模型，它的核心概念就是「內外皆不可信」。它的核心原則如下： 1. 持續監控與驗證： 「驗證使用者與裝置的身份與安全性」，並在登入與連線後設置超時機制，強制使用者與裝置定期重新驗證，確保持續安全。 2. 最小權限原則： 網路「僅授予使用者與裝置必要的存取權限」，並逐一驗證連線，定期重新驗證，以嚴格控管內部潛在威脅。 3. 微分段： 「將網絡劃分為小型安全區域」，各區域獨立管控存取權限。即使獲得其中一個區域的授權，未經額外許可，仍無法存取其他區域，從而強化安全性。 👀 可能產生誤解的概念說明： 微分段不等於子網劃分 ，所謂的「子網」（Subnet）是傳統網絡架構的一部分，透過劃分 IP 位址範圍 來組織設備。 然而，「微分段」則有所不同，它比子網劃分更進一步， 即使在相同的子網內，存取仍需要個別授權。 4. 防止橫向移動： 存取採用分段控制，並需定期重新驗證，使攻擊者無法在網絡中橫向移動。一旦偵測異常，系統可隔離受感染裝置或帳戶，立即阻斷進一步存取，防止攻擊擴散。 5. MFA（多因子身份驗證）： 使用多個證據證明使用者身份，如：密碼、裝置代碼等。 6. 裝置存取控制：  「嚴格控管裝置存取」，要求監控所有試圖連接的裝置，確保它們經過授權，並評估其安全性，以防遭受入侵。 以上是零信任常見的幾點原則，基本上就是圍繞著裝置、身份驗證、切割管理區域、權限控管等。 備註：筆者也有把上述的文字整理成心智圖，方便大家增強記憶～有興趣可以點擊圖片存取 💪 💘 零信任帶來的價值與影響 在傳統網絡安全架構中，系統通常預設內部網絡是「安全的」，只需在邊界（如 VPN、防火牆）設置防護。但隨著 遠端辦公普及、雲端應用激增、網絡攻擊越來越精細 ，這種方式已經不夠安全。 前面我們已經介紹過 零信任的原則 ，總結來說， 零信任（Zero Trust） 的核心概念其實很簡單，主要包括： 1. 沒有人或裝置是天生可信的，每次存取都需要驗證。  就像人與人交流時，即使是親朋好友講的話也不一定完全可信，需要自己判斷（看看最近的心靈課程事件就知道了 XDD）。  2. 確保每個人與每台設備只能存取他們應該存取的資源，沒有例外。  這意味著即使是內部員工或受信任設備，也無法隨意存取無關的系統與數據，從而減少潛在風險。 在了解...

經歷 - 新創公司（供應鏈相關）一年半：Frontend Developer - 新創公司（DCIM）一年：Frontend Developer - 四大會計事務所：Senior Cybersecurity Consultant 創作相關背景 鐵人賽 - 第15屆 IT 鐵人賽 (優選)： 從自建漏洞中學習 - 一起填坑吧！ - 第16屆 IT 鐵人賽： 前端小廢物誤入 Hackthebox Module 出版書籍 - 究極 Web 資安心智圖學習法！嚴選12大主題 × 7張心智圖 × 7個實戰，核心技能無痛升級（iThome鐵人賽系列書）:  天瓏書局網站   社群背景 - DevSecOps Taiwan：社群 Leader - 台科資安社：社員 正在準備的證照 - OSCP - 托福

Python 3 實踐 MAC Changer  還記得我們在  上一篇  鋪的哏嗎？ 今天我們就來用 Python 實作 Mac Changer 看看！ 先備知識 - Python  基於 Python 3.5 後的版本實踐，我們會需要認識一些新版本的函式。 subprocess.run（3.5版本以後加入） import subprocess subprocess.run(["ls", "-l", "/dev/null"], capture_output=True) 像是上述這個例子，經過逐步拆解，大致上會是這樣： 1. 使用 subprocess.run 執行系統指令 2. ["ls", "-l", "/dev/null"] 如同在終端機執行以下指令 ls -l /dev/null 意思是列出 /dev/null 這個文件的詳細資訊， capture_output=True 代表擷取標準輸出、標準輸入，但是因為這行程式並沒有儲存輸出，所以不會顯示結果（如下圖）。 如果拿掉 capture_output=True 就會跑出結果了（如下圖），讀者們可以試試看! 除此之外，如果想要保持原有設定，並把結果儲存到文字中，可以這樣寫： import subprocess result = subprocess.run(["ls", "-l", "/dev/null"], capture_output=True, text=True) print(result.stdout) 結果輸出會像是下圖： subprocess.check_output()（3.1版本以後加入） check_output() 「 自動啟用了 check=True 」，如果命令執行失敗（回傳碼 !== 0），它會拋出錯誤，而非靜默失敗。另外，有個好用的地方，就是 我們可以使用這個函式來獲取輸出的結果。 argparse（3.2版本以後加入） argparse 基本上就是一個用來解析命令列模組（CLI Arguments）的 Python 內建模組，讓我們的 Python script 可以支援不同的輸入選項，例如： ...

MAC Address 攻擊向量 MAC Address 的問題 💀 MAC Address 是可以被更改或是偽造的，所以它不適合當作唯一的可信來源考量 XD 比起 MAC Address，我們需要選擇較好的驗證來源方式 💖 如果要驗證來源，需要採用比較安全的方式，如： 1. 使用 802.1X 認證（EAP-TLS, EAP-PEAP） 透過 RADIUS 伺服器 進行身份驗證，確保只有授權設備能連接網路。 使用 數位憑證（TLS） ，防止 MAC Spoofing。 有關 802.1X 是什麼、RADIUS 是什麼，筆者會在之後文章中做講解。 2. 搭配 IP/MAC 綁定（DHCP Snooping + Dynamic ARP Inspection） DHCP Snooping ：記錄合法設備的 MAC 與 IP 綁定關係 ，防止攻擊者偽造 MAC 地址。 Dynamic ARP Inspection（DAI） ：檢查 ARP 回應是否符合 DHCP Snooping 記錄，防止 ARP Spoofing。 MAC Address 攻擊向量 - MAC Spoofing 👾 介紹： 修改設備的 MAC 地址，使其與另一設備的 MAC 地址匹配，通常是為了獲取未經授權的網路訪問。 如何進行 MAC Spoofing? - 使用 macchanger 我們可以採用以下方式修改 MAC Address： -r：亂數產生新的 MAC macchanger -r eth0 -m：自定義要修改的 MAC macchanger -m aa:aa:aa:aa:aa:aa eth0 -p：恢復原廠設定的 MAC macchanger -p eth0 最後，如果要看看對應介面的 MAC Address，macOS / Linux 可以使用 ifconfig 或是 macchanger -s eth0  貼心小提醒: 如果要換介面，修改 eth0 就行啦 ! 更多的參數說明: 不過，我們並不是都要依賴工具啦 XD 身為一個 Developer ，我們還是可以玩玩動態排程切換 MAC 地址的! 參考資源 https://ithelp.ithome.com.tw/m/articles/10281860 預告 下次我們一起用 Python 寫看看吧!...

Mac Address MAC Address 就是設備的身分證號碼，長度是 48 bits （6 個 byte），通常用 十六進位 表示，像是 AA:BB:CC:DD:EE:FF 這樣的格式。我們可以把它拆成前 24 bits 和後 24 bits ，兩部分各有不同的作用。 前 24 bits：OUI（組織唯一識別碼） 這部分是「 IEEE 負責分配給各家廠商 」的，確保不同品牌的設備不會相同。像是： Apple 可能是 00:1A:2B Intel 可能是 00:1B:63 Cisco 可能是 00:90:4C 簡單來說，就是前面這段可以看出設備是哪家公司的。 後 24 bits：裝置識別碼 這部分是「 設備製造商自己分配的 」，確保自家產品的 MAC Address 不會重複。你可以把它想成這台設備的專屬編號，每台設備的這段都不一樣。 Mac Address 特性 1. 全球唯一性 此處是指「 原廠設定 」的 MAC Address 是唯一的，但其實我們還是可以修改 MAC Address。 2. 廣播（Broadcast） ： 舉例來說會像是「FF:FF:FF:FF:FF:FF」，發送給所有設備（如 ARP 查詢）。 3. 群播（Multicast） MAC Address 低位元為 1 ，發送給特定群組（如 IPv6 Multicast）。 4. 單播（Unicast） MAC Address 低位元為 0 ，發送給特定設備（如一般網路通訊）。 5. 全球管理 （Global） ： 由製造商提供，OUI 決定前 24 bits，U/L 位元為 0，通常是設備的原始 MAC Address。 6. 本地管理 （Local） ： 手動修改的 MAC Address，U/L 位元為 1，常用於虛擬機或測試。 範例： 01:00:5E:7F:00:01 仔細看最左邊的數字為 01，轉換成二進位會是 0000 0001。 如果要分辨是 群播 還是 單播 ，我們可以看轉換成二進位數的最右邊的數字。 因為群播是 1，單播是 0，所以仔細看會發現: 我們的範例是 1，所以是群播。 再來，若要分析是否有修改過，可以看最右邊的第二個數字，會發現我們的範例是 0，意旨沒有修改過。 看看你電腦的 Mac Address 如果你是 Windo...

開發安全 簡報 https://speakerdeck.com/kika08/kai-fa-an-quan-fen-xiang-jian-bao 相關分享管道 YouTube 頻道（ 預計 2/9 更新 臨時有事情變動延期ＱＱ ）  https://www.youtube.com/@hack-kika

SRV 紀錄 不知道讀者們是否還記得我們在  上一篇  文章提到的 SRV 紀錄呢？ 先來複習一下我在 GoDaddy 截圖的 DNS SRV Record 設定～也就是上面這張圖 XD 仔細看會看到幾個關鍵設定，如： 1. 服務（Service）： 指定提供的服務名稱，如 _sip （SIP 通訊協議）或 _xmpp （XMPP 即時通訊）等。 2. 協議（Protocol）： 指定使用的協議，如  _tcp 或 _udp 等。 3. 姓名（Name）： 為此 SRV 記錄所對應的 主機名稱（子域名） ，通常是 @ （代表根域）或 email。 4. 值（目標，Target）： 提供該服務的「 伺服器主機名」 ，如 host.domain.com。 5. 優先級（Priority）： 數字越小，優先級越高，伺服器會被優先使用。 6. 粗細（官方的翻譯有夠怪，應該是指「權數」，Weight）： 「權數」越高的伺服器，分配到的流量就越多 ，讓負載更均衡。 7. 端口（Port）： 表示該服務運行的 TCP / UDP 埠號 ，如 5060 （SIP）、 5222 （XMPP）等。 8. TTL： 表示 DNS 快取時間 ，單位為秒，影響記錄多久才會刷新（例如 3600  ＝ 1 小時）。 在大致了解其基礎後，我們一起來看看實際的 SRV 記錄範例：  _xmpp._tcp.kikasecures.com.86400 IN SRV 10 5 5223 chat.kikasecures.com. 而上述紀錄其實就是對應到如下（以下為 Chatgpt 幫忙整理的表格）： 唯一比較沒有特別說明到的是類別 Class，此處代表的是 Internet 類型的 DNS 紀錄，而 Internet 類型也是目前很廣泛使用的一種。 在了解其紀錄個別代表的涵義後，此時應該會有讀者心想：「有了這個 SRV 紀錄，那具體會怎麽運行啊？」 筆者就根據上述提到的「 _xmpp._tcp.kikasecures.com.86400 IN SRV 10 5 5223 chat.kikasecures.com. 」範例做講解： 1. 連線： 當 XMPP 客戶端（如 Pidgin、Gajim 等）連線 kikasecures.com 時，會查詢這條 ...