隨意聊

有別於其他的長文,這裡都是比較隨意寫的短文。原本是發在臉書粉專,但都藏在臉書裡面有點可惜,索性搬一份到部落格來,對不用臉書的人也更友善。

共 110 篇 第 6 / 6 頁 RSS 訂閱

ToDesktop建置機漏洞

只是想裝個 Cursor 來玩玩,卻意外發現個嚴重的漏洞?

一名資安研究員 xyzeva 在安裝 Cursor 的時候,發現了一個連線到 todesktop[dot]com 的請求,於是就好奇往下追,去看看這是什麼。發現 ToDesktop 是個能夠讓快速讓 web app 變成 desktop app 的服務(其實就是外面包一層 Electron 啦),也一併提供了 installer, auto update 等功能。

因此在安裝 Cursor 時,才會有連線到 ToDesktop 的請求。

經過了一番摸索之後,xyzeva 自己試用了一下 ToDesktop 的服務,做了個簡單的 app,並且在 package.json 的 postinstall 裡面放了一段 reverse shell 的程式碼。

因為 app 最後是在 ToDesktop 的 server build 的,所以 reverse shell 被觸發,xyzeva 成功進入了他們的 builder。結果找著找著就看到 config.prod.json.encrypted 跟 config.prod.json,一打開發現 HSM 的 secret 跟各種 credentials 都在裡面。

拿到這些 credentials 以後,可以自己簽一個合法的 package,然後自動幫有用 ToDesktop 這服務的軟體更新,如 Cursor、ClickUp 或是 Linear 等等。

最後 xyzeva 從 ToDesktop 那邊拿到了 5 千塊美金的賞金,而 Cursor 則另外加碼了 5 萬美金。

整件事情發生在去年 10 月,ToDesktop 被找到漏洞後也在 26 小時內快速修復,然後找資安公司來做 audit,一直到一月底完成,二月底複測結束,因此三月初公開漏洞。

,原文有更多細節,有興趣的可以看看。

話說這種 builder 拿 reverse shell 的操作滿常見的,你在 GitHub Actions 或是 Heroku 之類的也能做到(之前我有試過可以,現在不確定啦),畢竟這些 builder 就是要跑程式碼的,所以會執行任意指令也不意外。

但重點是權限的控管,不能讓這些 builder 有太多敏感資訊,不然就全部都曝光了。這些 builder 的 threat model 應該會是:「假設外人可以執行任意指令,該怎麼防禦?」,例如說弄個 sandbox 或是跑一個沒什麼權限的 container 之類的,而 ToDesktop 忽略了這點,就直接 gg 了。

Material Theme下架疑雲

到底是刻意製作惡意擴充套件、供應鏈攻擊,還是全部烏龍一場?

前幾天在推特上有看到 VSCode 的知名擴充套件 Material Theme 被強迫下架,而且會由 VSCode 主動移除,理由是裡面包含惡意程式碼,這幾天也看到一些新聞或是臉書上有人在分享這件事情。

剛剛花了點時間看了一下原始資料,發現事情並不單純。

目前看起來講述比較完整的新聞是 BleepingComputer 的這一篇:VSCode extensions with 9 million installs pulled over security risks [1],裡面提到了資安研究員 Amit Assaraf 與 Itay Kruk 向 VSCode 回報這個套件可能含有惡意程式碼,在他們自已發表的文章 A Wolf in Dark Mode: The Malicious VS Code Theme That Fooled Millions [2] 中是這麼說的:

A deep analysis concluded that hiding inside it’s codebase are multiple red flags indicating malicious intent. The malicious code seems to be inside a dependency of the theme, which was compromised.
經過深入分析後發現,其程式碼中隱藏著多個顯示惡意意圖的警訊。惡意程式碼似乎存在於該主題的一個依賴項內,而該依賴項已遭到入侵。

但是文章中並沒有提到具體細節,雖然有說更多資訊公開後會更新文章,但目前還沒更新。

事情的發生是在 2/26,這些套件被強制下架後在 Hacker News [3] 上引起了相關討論,在微軟官方的 Visual Studio Marketplace GitHub repo [4] 中也有這件事情的討論串,在 HN 上 VSCode 團隊的成員 Isidor 有出來說明狀況:

A member of the community did a deep security analysis of the extension and found multiple red flags that indicate malicious intent and reported this to us. Our security researchers at Microsoft confirmed this claims and found additional suspicious code.
社群中的一名成員對該擴充功能進行了深入的安全分析,發現多個顯示惡意意圖的警訊,並向我們報告。微軟的安全研究人員隨後確認了這些發現,並進一步發現了額外的可疑程式碼。

而 GitHub 的討論串則是有 VS Code Marketplace 的 PM Sean 出來回覆:

We take the decision to remove seriously and thoroughly verify any reports. To protect developers, we also prioritize speedy removal of positives. We’ve posted the reason for removal in RemovedPackages, where we plan to add any future removals as well.
我們對移除決策持謹慎態度,並會徹底驗證所有舉報。為了保護開發者,我們也優先迅速移除確定存在問題的項目。我們已在 RemovedPackages 中發布了移除原因,並計劃未來將所有移除記錄統一發布在該處。

而在 RemovedPackages 中紀錄的原因是:

A theming extension with heavily obfuscated code and unreasonable dependencies including a utility for running child processes
一個主題擴充功能,其程式碼經過高度混淆,並包含不合理的依賴項,例如用於執行 child process 的 utility。

好,看到這邊,我相信大家應該很好奇這個惡意擴充套件到底幹了什麼。至少身為對資安有興趣的人,我很好奇他到底偷了什麼,那些惡意程式碼又是什麼。

而資安人的報導《資安風險!微軟禁下載量達900萬次的VSCode Material Theme擴充套件》[5] 中,有一段是:

技術專家進一步檢查發現,擴充套件中的「release-notes.js」文件包含高度混淆的JavaScript代碼,這在通常追求透明和可讀性的開源項目中是非常罕見且危險的信號。混淆的程式碼中頻繁出現與使用者名稱和密碼相關的引用,這進一步增加了安全疑慮。

這段的來源應該是開頭提過的 BleepingComputer 的報導中所寫的:

A partial deobfuscation of the code showed numerous references to usernames and passwords
對該程式碼進行部分反混淆後,發現其中包含大量與使用者名稱和密碼相關的引用。

所以目前已知的證據是:

  1. 擴充套件的某些程式碼經過混淆
  2. 用到了不合理的依賴,會去呼叫 child_process
  3. 反混淆後發現有提到許多使用者名稱跟密碼

看起來似乎…確實有點可疑?

但仔細想想會發現,可疑的不止上面這些,而是原始程式碼都有了,為什麼給不出一個罪證確鑿的證據說:「你看這段程式碼,就是偷偷讀取你的 SSH key 然後傳到這個 domain 去」。一開始回報的資安人員只說有很多 red flags,而微軟那邊也確認發現了可疑的程式碼,那第一個重點就出現了,到底那一段混淆過的程式碼,是單純的可疑,還是真的有問題?

那如果有問題,背後到底做了哪些惡意的事情?雖然混淆過了比較難解析,但微軟一定是有能力去反混淆的。

但很遺憾的是,目前無論是微軟還是當初的資安研究員,都還沒提出確切的證據。甚至在 GitHub Issues 中有些人把程式碼反混淆之後,說看不出來可疑的地方,而那些「提到許多使用者名稱跟密碼」的部分可能跟 URL parser 的一個 library 有關(URL 上面可以帶帳號密碼,因此 URL parser 需要處理)。

總而言之呢,截止目前為止,沒有一個人拿出證據說:「對,就是這段惡意程式碼有問題,它會偷你東西」。

而套件的作者 equinusocio 也在 2/28 的時候發了一個 Issue [6],描述了他的視角,說在他看來可疑的地方只有使用了一個太舊的 package 而已,明明就沒有經過證實,怎麼就把我的套件都下架,甚至連帳號都 ban 了。

也在裡面公開了一直被說有問題的檔案 release-notes.ts 混淆前以及混淆後的原始碼,並且指控 VSCode 團隊散播未經證實的假消息:

As for the VS Code team — and by extension, @microsoftopensource — the entire team, and particularly @isidorn, publicly accused me of criminal activity by spreading false and unverified information.
至於 VS Code 團隊,特別是 @isidorn,公開散播不實且未經證實的資訊,指控我涉及犯罪行為。

當然啦,整個故事還有其他案外案,包括了套件作者以前的其他事蹟(修改 commit 紀錄以及修改開源的 license,準備賣付費版的套件,有一說認為混淆程式碼是因為之後要賣付費版),以及有個技術網紅 t3dotgg fork 了一個號稱乾淨版的 Material Theme 重新上架等等,這些就都先不談了。

在我自己目前看來,儘管程式碼經過混淆確實可疑,但混淆過並不代表一定就是惡意程式碼。要說它是惡意程式碼,你必須要有明確的證據,這種事不能亂指控的,畢竟現在全天下都直接認定 Material Theme 就是惡意軟體了。

總之呢,我認為整件事情還沒蓋棺定論,還需要再讓子彈飛一會兒,目前還不能確認 Material Theme 含有惡意程式碼(因為沒有確切證據)。

故事大概會有兩種發展,看是微軟會先拿出證據一槍斃命,證實它就是個惡意軟體;還是拿不出證據反而變成 🤡,只要有疑慮,在沒有驗證過以前就可以把套件下架,讓無辜的套件背上惡意軟體的污名。

補充文章:https://www.informationsecurity.com.tw/article/article_detail.aspx?aid=11684

Bybit冷錢包竊案

終於可以來寫加密貨幣交易所 Bybit 被偷走 15 億美金的案例啦!

事情發生在 2 月 22 號,Bybit 的冷錢包被駭客直接偷走大約 15 億美金,換算成台幣快 500 億了,是史上最大宗的加密貨幣竊案。

事件一出來的時候,我就認為這會是個歷史性的事件,因為:

  1. 損失 15 億美金,史上最嚴重
  2. 是冷錢包出事,不是熱錢包
  3. 已經有證據證明是北韓的駭客集團 Lazarus Group 幹的

在講犯罪手法之前,我們先來看一下 Bybit 的冷錢包平常是怎麼簽署交易的。

他們在 Ethereum 上的冷錢包走的是智慧合約多簽錢包,多簽的數量沒有查到細節,有查到 3/5 跟 3/6 兩種說法,但總之需要有 3 個人簽署才會生效。

而整個錢包系統用的是一個叫 Safe{Wallet} 的東西,提供了一個介面讓簽署者看交易內容,實際要簽署的時候,需要使用 Ledger 提供的冷錢包。

當三個人簽署這個交易後,交易就直接送去鏈上了。

而這次的攻擊其實與冷錢包本身無關,是 Safe{Wallet} 這段被駭了。駭客入侵了 Safe{Wallet} 的 S3 bucket,修改了前端的檔案,讓那些 signer 看到要簽署的交易內容是 A,結果真正簽的是 B。因此就簽署了錯誤的交易,就是這麼簡單。

這邊有個細節是,一般會想到的「竄改交易」是例如說我想轉 100 塊到熱錢包,此時竄改成轉 100 萬給駭客的地址,但是在這個案例中並不是這樣。實際上駭客簽署的內容是去執行智慧合約的某個方法,讓自己有權限,就可以繞過後續的簽名,直接把錢轉走。

那為什麼不直接篡改交易就好,要額外多一步呢?我猜有可能是因為 :
(1) 這個地址有多個幣種,竄改交易只能轉一個幣種
(2) 轉更大額有風控機制會擋下來

總而言之呢,看似是轉給熱錢包的交易,其實是「授權給駭客的智慧合約」,三個簽署者都簽完,交易上鏈之後,就直接 gg 了。

我上一份工作做的是冷錢包相關的風險評估,看過不少交易所的文件跟架構,稍微有些理解,看到這事件我就想說不合理啊,這個流程有問題啊。

第一個大問題是,為什麼冷錢包轉帳的地址沒有白名單?這算是滿基本的操作,因為是冷錢包,所以通常轉帳的地址就那幾個,所以會設定一個白名單,設定白名單要先簽過一次交易,之後才能轉到這個地址。我查了一下,好像 Safe{Wallet} 本身沒有這個功能 😂

第二個問題是,為什麼沒有人確認自己簽的交易跟看到的是不是一樣?

我去找了 Bybit CEO 親上火線解釋的片段,其實流程裡是有的,但沒人照做,以下是英文逐字稿原文以及中文翻譯:

I use a a ledger as a hardware device for the last signing part. so after I signed and also check the The Ledger screen one of the issues with, at least from my experience, with the ethereum related cold wallet transfer is that it doesn’t exactly shows the destination.
我使用 Ledger 作為硬體設備來進行最後的簽署步驟。所以我簽署時也檢查了 Ledger 的螢幕。不過根據我的經驗,與以太坊相關的冷錢包轉帳存在的一個問題是,它並不會準確地顯示目標地址。

it shows a lot of code so it is not so I checked the code but I didn’t check fully. normally also the address the destination address is not inside of that multi-sig signing, so I signed.
它顯示了大量的 code,因此並不那麼直觀。我檢查了 code,但沒有完全檢查。通常來說,目標地址並不會出現在多重簽名的簽署內容中,所以我還是簽署了交易。

簡單來講就是,因為看不懂所以就不檢查了,有看跟沒看一樣。三個人可能都看過,但是都沒看仔細,就當作例行流程直接簽了。就算內容看不懂,只要能檢查到 to 的位置,應該就能發現 to 是一個陌生的地址。說不定其實也是個 UI + UX 問題,因為 Ledger 每次顯示的內容都不重要,所以每次都被略過不看。

所以呢,雖然是因為 Safe{Wallet} 前端被駭所導致的事件,但我覺得 Bybit 也要負滿大的責任,畢竟前端被駭在 Web3 世界早就不是什麼新鮮事,這個風險是絕對可以預測到的,明明知道風險卻沒有做任何對策,或是做得不夠徹底。

我以前看過的冷錢包流程中,有那種很安全的是 100% 離線的,例如說拿來簽署的 UI 是放在自己內網,而且簽署完之後還沒完成,不會直接上鏈,而是把簽署好的交易複製到某個硬體裝置,接著把這個裝置 帶去一個完全隔離的房間,用那裡面的電腦搭配上最後一個 key 去簽署(到這一步多簽才完整),此時在 UI 上可以看到正確的交易內容,確保交易內容無誤。

簽完之後,一樣把簽好的東西放到硬體裝置中儲存,再帶到外面的電腦,接上公網,把交易上鏈。

由於最後一步的電腦在一個離線的環境中,因此 UI 很難被篡改(除非有內鬼,那是另外一回事),能很大程度保證看到的就是最後簽的。要攻破整個流程,需要的成本會多很多。

總之呢,整件事情差不多就是這樣,沒有強制的白名單、三個簽署者也都沒有檢查簽的內容,只要竄改 UI 就能騙過這些人,然後偷走了 15 億美金。看起來人果然是資安最脆弱的一環,明明知道要檢查,但因為看不懂 + 以前也都是這樣的,一個失誤就釀成大禍。

補充文章:

GitLab重設密碼漏洞

今天看到 HackerOne 公開了一個 2023 年底的 GitLab 漏洞報告,最嚴重的那種,賞金 35000 美金。

查了一下發現是 CVE-2023-7028,只要知道 email 就可以透過漏洞,把重設密碼的信件送到自己信箱,輕輕鬆鬆重設其他人的密碼然後登入(如果沒有 2FA 的話)。

而這個漏洞的細節也很簡單,原本重設密碼的請求裡是這樣寫的:
{
“email”: “victim@gmail. com”
}

你只要把它改成 array:
{
“email”: [“victim@gmail. com”, “huli@huli .tw”]
}

GitLab 就會順便送一封重設密碼的信到我信箱,就是這樣 😅

身為開發者,看到這種漏洞的第一反應就是:「後端到底幹了什麼奇耙的事,為什麼陣列也能過」,於是我去找了 patch 來看。

看起來好像是原本拿到 input 中的 email 之後就呼叫一個 find_by_any_email 的方法,去找出背後對應的 user 然後寄信,而這些方法既支援字串也支援陣列,但用的時候是以 input 是字串去考量的,沒想到會有陣列的可能性,因此就出包了。

之後的 patch 把找 email 那段改成了簡單的 Email.confirmed.find_by(email: attributes[:email].to_s),先轉成字串再去找對應的 user 準沒錯,就不會寄到其他人那裡了。

話說這種型態的混淆一直都是很好的攻擊面,尤其是針對 JavaScript 或 PHP 這種超級彈性的語言,這種原本預期是字串卻變成陣列的攻擊滿常碰到的,但 Ruby 我就不太熟了,至少這次的 GitLab 漏洞原理也類似。

講到這個,我最喜歡看到的其實是背後用 TypeScript 寫的後端,因為很多開發者誤以為用 TypeScript 宣告了某個東西是字串,它就一定是字串,不知道這只在靜態檢查生效,動態才不管你 😆

參考資料:https://github.com/Vozec/CVE-2023-7028

公共CDN腳本風險

今天看到黑暗執行緒大大寫了一篇 CDN 相關的貼文,講了一下引用第三方公共 CDN 檔案的優缺點,而貼文底下也有不少回應補充(我也去補充了一下XD),由於這個議題很有趣,因此這邊再簡單講一下我的想法。

先說明一下,這篇提的情境是在網頁上引用來自於 unpkg 或是 cdnjs 等等這種第三方公共 CDN 的 JavaScript ,你對內容沒有掌控權,只能使用不能修改,跟自己把東西放到 CDN 是完全不同的情境。

我的想法是,除非是壞掉也沒關係的小玩具,否則一律建議不要。

使用那些公開免費的 CDN,最大的優點就是方便,直接 script 無腦引入就好,而且通常速度比放自己那裡快(假設自己那裡沒有開 CDN 的話)。

缺點的話主要就兩個,一個是那些第三方網站掛掉你的網站就跟著掛了,第二個是資安風險,你引用的那些來源被入侵你的網站也跟著被入侵,就是俗稱的供應鏈攻擊。

這些問題其實實際上也發生過不少次。例如說 2023 年 12 月我就寫過冷錢包公司 Ledger 的 CDN 被入侵的事件;還有去年 6 月才發生的 polyfill 事件,都是直接使用其他人 host 的腳本而導致資安問題的經典案例。

就連 Cloudflare 自己經營的 cdnjs 也曾經被打進去過,說明了這些第三方 CDN 的安全性可能沒有你我想像中的高。就算前端用了 integrity 防禦,當攻擊發生時,仍然會面臨兩個問題,第一個是網站會掛掉(因為檢查不通過),第二個則是如果那些腳本原本就是動態再引用其他網址,那 integrity 是無效的,因為腳本中的文字沒有變,而是引用的來源內容變了。

再者,以往使用這些第三方 CDN 的好處是因為快取的關係,別的網站用了你也能受益,只要下載一次就好。但自從 Chrome 在 2020 年開啟了快取分區(cache partition)的功能後,這點也不再成立。

總之呢,前端直接引用那些第三方 CDN 的 JavaScript,就是拿方便性來換取安全性跟穩定性。如同我開頭所說,如果是掛掉也沒差的小玩具我覺得倒是無妨,頂多一年掛個一次。

但若是公司的服務用了結果出事,那影響就比較大了,畢竟這個風險是完全可以避免的。

不過話說回來,其實整個議題與 CDN 這個技術沒什麼關係,本質上就是個「動態引入其他網站的腳本」的問題,當內容不可控而且是動態的時候,自然而然就會提高風險。

延伸可以參考我在《Beyond XSS》裡關於快取風險的章節,以及我之前寫過的 polyfill.io 事件。書籍版本也可以在天瓏找到

CSS高度動畫新招

如果你問我,HTML、JavaScript 跟 CSS 哪個最難,我大概會回答 CSS,並且送你一張 CSS 拉窗簾.gif。跟 JavaScript 比起來,CSS 進化的速度來得更快,每隔幾個月就出來一個新東西,解決了許多的經典難題。

不過就算沒有這些新東西,其實也能做出一個堪用的版本,或是乾脆直接用 JavaScript 來弄,大部分也都能搞定。但正是因為如此,導致許多人(包括我)的 CSS 知識可能一直都沒有進化,原地踏步,不知道有哪些新的東西。

舉個例子,一個點擊可以展開,再點一次可以收起來的摺疊元件(Collapse)大家應該都不陌生。那如果折疊的時候想加上一點動畫該怎麼弄?沒弄過的人會說這簡單,不就加個 transition: height 0.3s; 就行了嗎?

弄過的人會跟你說這樣沒用,因為 height 是 auto,這種狀況下不會有 transition。要解決的話不外乎就是三招,第一招是寫死固定高度,但通常沒辦法滿足需求;第二招是改成用固定的 max-height,既能動又不會真的讓高度寫死,而缺點是動畫時間會很奇怪;第三招則是請 JavaScript 出馬,在折疊前先把高度取出來再設置上去。

除了廣為人知的這三招以外,最近看到另外兩招新的也可以解決,第一個是 ChatGPT 推薦我用的 grid + grid-template-rows,利用 grid 會自己調整大小但又不是 auto 的特性來做,就能有 transition。

第二個其實才是今天想講的主題,只要在展開時把高度改成 height: calc-size(auto, size); 就搞定了,酷吧。

不過瀏覽器支援度很差,去年九月推出的 Chrome & Edge 129 才開始支援,其他瀏覽器直接死給你看。或許這也是為什麼許多新的 CSS 方法沒有受到這麼多關注吧?就算知道了,可能要先等個半年一年才能等到所有主流瀏覽器的支援,就算到了那時,整體支援率可能還只有 50% 不到,還要再等個三五年才能實際用在 production 上。

但總之呢,能用純 CSS 解決這個千古難題還是挺讚的對吧。

下次碰到需要幫 height: auto 加上 transition 時,如果可以保證使用者的瀏覽器都很新,不妨試試看。

CDN快取去匿名化

有一種攻擊手法叫做「deanonymization」,中文翻作:「去匿名化」,在網路世界中,每個人都保有一定的匿名性,但我們也都知道這層匿名性其實滿容易被打破的。

舉例來說,假設我發了我的 server 連結給 Discord 網友,當他點了之後,我的 server 就會直接收到他的設備傳來的網路請求,假設他沒開 VPN,那我就能拿到他的 IP 跟設備資訊等等,足夠辨識出他人大概是在哪個區域(例如說在台北或是東京之類的)。

但這畢竟也要我的網友主動點擊 URL 才行,而今天要介紹的手法不須要點擊也能做到同樣的事。有個 15 歲的高中生 daniel 前陣子就發表了一篇文章《Unique 0-click deanonymization attack targeting Signal, Discord and hundreds of platform》,分享了他是如何做到的。

Discord 在發送好友邀請的時候,會在手機上彈一個通知出來,這個通知會有加你好友的人的大頭貼照片,讓你方便辨識,十分合理。這時候你可能會想說,那我把 Discord 大頭貼設成自己的 URL 不就行了嗎?抱歉,這樣是行不通的,因為大頭貼只能上傳圖片,最後會被放到 Discord 的 server,前面掛 CDN,所有網址都是 Discord 在管的,這也是滿常見的做法。

然而,就是這個 CDN 開啟了去匿名化之路。

以 Cloudflare 為例,它有許多節點,例如說在東京連到的就是 NRT 節點,會從這邊下載資源,如果這個節點沒有,就會去 source 拉取並且存一份到節點中,別的東京使用者下次去 NRT 節點就拉得到資源了,速度會更快,這就是 CDN 運作的原理。

而 daniel 之前在網路上發現有人分享一個方法,可以透過 Cloudflare 自己的服務 Cloudflare Workers,強制把請求發送給某個特定 CDN 節點。

這是什麼意思呢?

對於某個特定資源 huli_avatar.png,我可以用這個方式,發請求給所有 Cloudflare 的 CDN 節點,並且透過 response header,來得知這個節點的快取狀況,我能知道是 HIT 還是 MISS,也能知道快取還多久會過期。

也就是說,當我發送 Discord 好友邀請給小明的時候,小明手機自動跳通知,去最近的 CDN 節點抓取圖片。接著,我利用剛剛講的方法,發送請求給所有節點,只要查看 response header,就能知道小明剛剛訪問的是哪個節點,進而推測出小明大概的位置。

簡單來說就是利用 CDN 快取機制來 leak 出使用者的大概位置,也算是一種 side-channel attack 了。

Signal 跟 Discord 都能用類似手法進行攻擊,不過這兩個聊天軟體都不認為這是個需要修的漏洞(我也不認為就是了),而 Cloudflare 最後修了那個可以透過 worker 發送請求到任意節點的問題。

我的想法是,這個手法有趣歸有趣,但是對那些聊天軟體來說,似乎確實超過了職責所在,畢竟就算不是透過這種方法,發 URL 點擊也還是能達到一樣的效果,而且更精準。況且這就是 CDN 的運作機制,要修的話也不知從何修起,成本滿高的。

分享這篇是因為故事很有趣,而且很完整,原文裡面有附各種圖片還有完整的 exploit 影片,推薦有興趣的人去看看原文。

影片:https://gist.github.com/hackermondev/45a3cdfa52246f1d1201c1e8cdef6117

DeepSeek資料庫裸奔

今天來分享一個過年時的舊聞,應該不少人看過了,就是 DeepSeek 的資料庫在網路上裸奔被發現的故事。

資安公司 Wiz 的研究團隊在 1/30 的時候發佈了一篇名為《Wiz Research Uncovers Exposed DeepSeek Database Leaking Sensitive Information, Including Chat History》的文章,揭露了整段故事的細節。

基本上要入侵的第一步叫做 reconnaissance,簡稱 recon,偵查的意思,從外部的角度去搜集各種資訊,最常見的就是去找出 subdomains 或是 Google Dorking 等等,先把公開的資源搜集一波,再決定下一步。

當找到 subdomain 以後,先掃一次 port,看一下有哪些有趣的發現,接著再繼續打。

而這次 DeepSeek 的漏洞是在掃 port 這邊就被找到了,簡單來說先掃到一個 subdomain: dev[dot]deepseek[dot].com,掃 port 發現上面開著 8123 port,結果一連進去就是一個公開的 ClickHouse,可以直接下 SQL query 並顯示結果。

整個過程就是這樣,一個裸奔的 ClickHouse 放在網路上,就算沒有被這間資安公司找到,可能過不久就被其他機器人掃到了。完全不需要驗證又直接開放在公網,暴露的又是資料庫,算是滿嚴重的。

補充文章:https://www.ithome.com.tw/news/155392

工程師求職詐騙案例

分享一個在推特上看到的,台灣工程師被詐騙結果 Metamask 裡的加密貨幣全都被偷走的血淋淋案例

攻擊者在 Linkedin 上主動發起社交攻擊,説已經有個 MVP 在找人繼續開發產品,提供了一個 repo,結果 repo 裡面有些隱藏的惡意程式碼,跑起來之後跳出要求權限的視窗。

雖然一開始按了拒絕,但因為一直跳,事主想說應該是其他現有的 App 在要的,就按了同意,接著過不久後發現自己 Metamask 錢包中的加密貨幣被洗劫一空,損失 4 萬美金。

留言裡的原文有詳細的攻擊手法、過程跟事後檢討,這種精心設計的社交工程在幣圈似乎也屢見不鮮了,不管你是工程師還是其他角色,都有可能被騙到,而且越來越精緻,看起來越來越像真的。

分享這些案例也是希望能引起大家的警覺心,之後碰到類似狀況時至少能突然想起這些案例,立刻就覺得這好像有點問題

補充文章:https://dawson54068.medium.com/%E6%8E%89%E4%BA%86%E4%B8%80%E5%8F%B0%E9%80%B2%E5%8F%A3%E8%BB%8A%E7%9A%84%E6%95%85%E4%BA%8B-609421ca2e09?sk=7cb053a2b19bb5671ad5ba5fa8358c6d

Discord V8漏洞影片

年前其實本來就想分享一個很猛的影片,但不知不覺就拖到年後了 😆

強者我朋友最近開了一個講資安的 YouTube 頻道,今天要介紹的這一支影片叫做:「Hacking Discord for $5000 Bounty」

在影片中完整解釋了整串的攻擊鏈,包含​了從 XSS 打進 Electron,而且是利用了舊版 Chromium 的 n-day,直接串成 RCE。雖然說這個漏洞有一陣子了(2021 年),但現在回顧還是很好看。

這部影片花了大量的篇幅與時間在介紹 V8 的機制跟 exploit,這是相當精彩的部分,之前我看文章也沒看到這麼詳細的解說,內容包括 ignition 跟 turbofan 是怎麼運作的,以及這個 n-day 的成因是什麼,patch 又是什麼。

最後則是講到 V8 的 memory layout、儲存東西的機制,並且從簡單的 OOB access 串到完整的任意讀寫,再串到最後的 RCE。

對於想了解 browser security 或是 V8 如何運作的人來說,絕對是個不可錯過的影片,真心推薦。