AWS Security Agent 預覽版體驗：免費做資安滲透測試
AWS 在1個多月前的年度技術大會 re:Invent 發布一些新產品，看到一個 AWS Security Agent 目前是在預覽版階段。
AWS Security Agent (預覽版)：用於主動應用程式安全的 AI 代理程式
AWS unveils frontier agents, a new class of AI agents that work as an extension of your software development team
師爺，給我翻譯翻譯，什麼叫預覽版?
預覽版就是現在可以免費使用，順便當白老鼠的意思啦。
AWS Security Agent 公開預覽版發行期間無須費用。
AWS Security Agent 想解決應用程式資安門檻過高的問題
官方介紹:
AWS Security Agent 是一種前沿的代理程式，適用於您的所有環境，且能夠在整個開發生命週期，為您的應用程式提供主動式防護。該代理程式可依據您的要求量身定制，執行自動化安全審查，而安全團隊則可集中定義審查期間進行自動驗證的標準。該代理程式還可依據您的應用程式量身定制，執行所需滲透測試，以及探索及報告經驗證的安全風險。藉助這種方法，能夠擴展應用程式的安全專業知識，從而在提供全方位安全性的同時，與開發速度保持一致。從設計到部署，AWS Security Agent 可藉由整合安全性，在前期大規模防範漏洞。
目前有三大功能:
1.設計檢閱(design reviews):上傳一個 DOC, DOCX, JPEG, MD, PDF, PNG and TXT 格式的設計文件，讓 AWS Security Agent 幫你檢查設計文件裡面有沒有什麼安全性問題。
2.程式碼檢閱(code review):自動檢閱擷取請求是否存在安全漏洞以及是否符合組織的安全性要求。
3.滲透測試(penetration testing):透過隨需滲透測試，自動探索、驗證和修復安全漏洞。
AWS Security Agent 上的滲透測試功能其實非常方便，全部都靠 AWS 的雲端。
我不需要在電腦本機或生一個遠端環境來安裝檢測程式，不用依照原廠的 install guide 跟 upgrade guide 配環境弄老半天。不用跟任何業務溝通要報價，要幹什麼事不用透過地區代理商做設定，要受測的網站程式也不用特地先安裝什麼。
下面繼續稍微介紹一下滲透測試的功能。
服務可用區域限制
剛剛有提到這玩意全靠 AWS 的雲端機器，不需要自己佈署，老韭菜可能已經想到這服務不是所有區域都有了，點進去時就會提示:
AWS Security Agent is not available in XXX. Please select another region.
Supported Regions:
美國 (維吉尼亞州北部)
所以受測網站本來有擋海外 IP 的話，AWS Security Agent 可能會無法正常運作，要先想辦法讓 AWS 的 IP 能進來。
要是 AWS 帳號沒把 us-east1 區域打開的話，應該也無法使用這個服務。
接著需要做一些 AWS Security Agent 的基本設定，建立 workspace 之類的。這部份很簡單，沒什麼好說明的，都先照系統預設的安全規則來跑。
滲透測試前置作業：驗證網站所有權
在開始滲透測試前，必須先驗證網站的所有權，所以不要拿來亂測別人的網站啊。
AWS Security Agent 提供二種驗證方式，一種是 DNS 驗證，一種是 HTTP ROUTE 驗證。DNS 驗證是要在網站的 DNS 紀錄加一筆 TXT 紀錄，這不用多說。
如果沒有域名管理權限，可以用 HTTP ROUTE 驗證，在網站的指定目錄(.well-known/aws/securityagent-domain-verification.json)放一個驗證檔案就行。
操作介面上只有給一組驗證字串，直接放在檔案內會驗證失敗，操作介面上也沒有任何指引。
後來 RTFM，發現官方手冊第 51 頁有寫到正確的格式:
{"tokens": ["<insert-token>"]}User Guide - AWS Security Agent
之後開始掃描，經過幾個小時，就會出現結果。
一下就用完的免費預覽版配額與時數限制
公測期間免費使用，但不代表無限量使用。
例如滲透測試的地方，驗證5個網域後就滿了。
如果有比較多網站要測，要一直刪刪減減的。(我沒去測試如果開一堆 IAM user，或是一些特殊的組織帳號，會不會有更多扣打?)
然後每個網站每次測試通常都要跑個好幾小時，多用幾下就會提示 Monthly usage limit reached 了。
滲透測試有每個月 80 小時的限制(Per month per account per region)，另外的 code review 那些服務也都有每月額度限制，可以參考官方文件:AWS Security Agent - Service Quotas。
想要去 AWS Service Quotas 申請更多用量，但服務清單根本找不到 AWS Security Agent 這個服務，所以不知道怎麼申請提高額度。
雖然測一次要跑很久，但還是會發生同一個地方剛剛沒問題，下一次反而出問題的狀況，問題不一次報完，這就只能靠多測幾次來確認了。
AWS Security Agent 眼中的危險等級，和你習慣的可能不一樣
AWS Security Agent 的報告不會把 informational 直接在列表顯示一個大大的數字，也不會在最外層列一堆 informational 類別的統計數字，這做法相當nice，懂的都懂。
反觀有些廠商的真是罄竹難書:
- 先在第一頁顯示一堆 XXX 項目幾筆的，然後直接讓不懂的人大做文章「有幾百個問題要修」
- 然後再翻閱對照表跟詳細檔案，才發現一堆都是 informational 類別。
- 用 URL 做分類，例如網站頁尾有一些公司連絡資訊(如電話號碼)，這也是在有些廠商的軟體眼中也是 informational，然後網站有幾百頁，那這個電話號碼就會被算幾百次，然後就會有幾百頁報告，把每一頁的頁尾聯絡資訊列出來，列一堆 CWE-359, OWASP2021-A01, OWASP2023API-0xa3, OWASP2017-A3...
而且有些 CSP header 沒設定之類的，在其它間廠商的報告裡面是 Medium 級別，但在 AWS Security Agent 這邊只是 informational。
AWS Security Agent 的報告列表主要是呈現 Critical/High/Medium/Low 有幾筆，那麼哪些東西在他牌軟體可能無關緊要，在 AWS 這兒被算在大問題的，就值得探討一下。
CloudFlare CDN Proxy Fingerprinting via HTTP Response Headers
有一個工具系統型網站碰到 Medium 級的問題，這網站是直接用了 CloudFlare CDN，有開 Proxied，因為 response header 有一些 CloudFlare 特有的 header，被 AWS 歸類在 Medium 級別。
AWS 報告出的理由是
This finding represents an informational security weakness rather than a directly exploitable vulnerability. The disclosure provides no immediate attack path but contributes to an attacker's infrastructure knowledge, which could inform subsequent attack strategies targeting CloudFlare-specific vulnerabilities or origin server discovery techniques.
有趣的是我拿其它有掛 AWS 自家的 CloudFront 的網站去測試，Cloudfront 自己也有一堆 x-amz-cf-id 之類的特殊 header，但是 AWS Security Agent 就靜悄悄，這個雙標仔。
我還真沒想過有一天要把這些 Cloudflare 特有的 header 清乾淨? 看 CF 的資料，基本上應該是無法去乾淨的，只有其中兩個 Nel & Report-To 可以修改 Cloudflare 的設定，關掉就會消失了。
到某個網域>Network，裡面會有個 Network Error Logging (Browser reports that show end user connectivity to your sites.) 的開關。
Multiple Critical API Endpoints Returning HTTP 500 Internal Server Errors
有幾個網站碰到 Medium 級的問題，並沒有直接在 500 error 畫面上得到什麼精美的伺服器環境資訊。但每個網站背後發生的成因和解法不同，解法也不相同。
翻閱滲透測試的紀錄，有些網站是嘗試拼湊單字，呼叫一些可能存在的 api endpoint，雖然回應一串 NOT FOUND 的 JSON，但 status code 是 500，好好調整成 4xx 系列的，重掃就通過了。
有些網站是 WordPress，例如用各種方法(用現成的套件會是另外寫 php)把敏感的 REST API endpoint 給擋掉，雖然有些是會肉眼看到一個灰底白字的提示訊息畫面，但 status code 是 500，改成其它的再重掃就通過了。
反正就是 status code 不要亂設就對了。
Reverse Proxy/WAF Architecture Disclosure via Response Header Inconsistencies
這被歸類到 Medium 級的問題。
受測網站的設計:
- 一開始就都有處理 response header 中的 ServerSignature 不會隨便就看到一堆 IIS Apache version 1.2.3 之類的，然後 X-Powered-By 放了特殊的英文名稱。
- 在 404 error 有另外設計的頁面，這樣頁面失效時可以直接查看別的頁面，其它錯誤的 status code 就沒有特殊設計。
雖然錯誤畫面很乾淨，沒有露出什麼程式碼、伺服器目錄、版本號，但因為 X-Powered-By 是在應用程式層加上的，所以有些不會經過應用程式層的錯誤，response header 內的資訊就會長得不一致，AWS Security Agent 覺得有留給別人測試的可能。(The consistent pattern of header presence/absence across multiple tests confirms layered architecture with detectable proxy/WAF component.)
最後是把所有錯誤相關 status code 的頁面都做成一制性的 response header，這條就通過了。
雖然 X-Powered-By 內的特殊名稱被判定是 Custom Identifier Exposure，但我沒有把他移掉，繼續留著，最後還是照樣通過測設，甚至連 informational 都沒算進去呢，
結語
滲透測試終究只是安全環節的一小部分，AWS Security Agent 讓市場上又多了一種選擇。
只是預覽公測期去當一下免費白老鼠，AWS Security Agent 目前還沒有正式公布售價，也很難直接拿來和市面上其他成熟方案做比較。
在時代的演進下，可能每個組織、每個人都需要自己 DIY 一些程式工具，除了一些標準特別高的產業，像是金融、醫療、政府單位之外，其他慘業可能都無法負擔正常的資安成本，如各種真人的服務、要簽年約、價格驚人的資安軟體。
有了 AWS Security Agent 這樣的工具，在開發期間就可以檢查程式碼，在佈署後可以做滲透測試，更方便，隨時都能用。不用本機佈署幾套開源資安軟體，也不需要跟哪個業務議價，可能比較不會變成一年做一次的文書作業或作文比賽...
工具抓不住人性的漏洞
之前聽到有人問說，大語言模型工具都能寫程式，為什麼不能幫忙一鍵解決資安問題?
只能說這件事要從很多面向來看:
- 有時候資安問題根本不在那幾行程式碼本身，叫 LLM based 的工具一直去找出程式碼的漏洞，是在找身體健康的嗎?
- 又有時候決策者的認知可能像「在醫院抽一管血就可以檢測出所有問題，做內視鏡或其它檢查的都是笨蛋」，人家就是想要應付一下，沒有要花錢做深入檢查，有些東西就是抽血無法檢查出來的，專業人員還認真的在那邊分析各種階段的風險與防禦措施? 根本是在對牛彈琴而已。
- 現實上，有時候防禦成本就是遠大於出事後補救的成本。
之前在社群網站看到有個房仲業務自己用 AI，vibe-coding 來管理客戶資料，底下一堆工程師留言說這樣有什麼問題，系統應該要有 OOXXYYZZ......他也是看不懂的。如果我是那個房仲的客戶，我會很擔心我的資料安全性問題。
畢竟以前也看過不少神奇程式，例如有些代購網站上有個查詢訂單的功能，結果檢查發現是用 Google Sheets 當資料庫，只要一些方式就可以把整個 Google Sheets 所有欄位的資料都抓下來。
當然本文介紹的滲透測試工具能不能偵測出來是一個問題，到底有沒有人會去偷幹資料，有沒有人願意出「正常」的預算用正常的流程做出正常的程式，又是另外的幾個問題，而且還是無解的。
如今 AWS Security Agent 能更接近這些房仲業務、小賣家，讓他們系統哪邊有隱含的問題......這講出來連我自己都不信，講得好像世界上在此之前沒有其他檢測工具一樣? 說穿了，也只是降低一點門檻，離「認真對待」還很遠。
撇除技術面的問題，程式跟系統架構很安全，然後呢?
這些工具無法回答更多現實世界的問題：
誰能碰到資料?
誰可以把資料帶走?
誰會為了方便而繞過流程?