HackMD
iRent 事件之我見
tags: 資安
Back to Archer
重點摘要
事故經過
下面內容引用自參考資料，chrome 翻譯的結果：techcrunch：
台灣汽車集團和泰汽車暴露了其汽車租賃和汽車共享部門 iRent 的大量個人客戶數據，直到一名安全研究人員上週在網上發現了這些數據。
即便如此，該公司還是花了一周時間——在台灣政府的干預下——才採取行動。
和泰汽車是台灣最大的金融控股公司之一，也是豐田的台灣總代理。iRent 是一款流行的汽車服務應用程序，於 2022 年被 Hotai 收購，它允許客戶按小時付費租用可以自由浮動或在倉庫找到的汽車。
據報導， iRent擁有超過 110 萬輛註冊汽車和 580,000 名 iRent 用戶。
安全研究員Anurag Sen在和泰擁有的雲服務器上發現了一個數據庫，其中包含 iRent 客戶的全名、手機號碼和電子郵件地址、家庭住址、駕照照片以及部分編輯的支付卡詳細信息，該數據庫可從無意中訪問互聯網。
由於數據庫沒有密碼保護，互聯網上的任何人只要知道其 IP 地址就可以訪問 iRent 客戶數據。
Sen 表示，暴露的數據庫還包含數百萬個部分信用卡號碼、至少 100,000 個客戶身份證明文件，以及自拍、簽名和租車詳細信息。
TechCrunch 審查了部分暴露的數據並證實了 Sen 的發現。暴露設備和數據庫的搜索引擎 Shodan 的互聯網記錄顯示，該數據庫早在 2022 年 5 月就開始洩露數據，在其安全時包含約 4.2 TB 的數據。
TechCrunch 本周向和泰汽車發送了幾封電子郵件，其中包含公開數據庫的詳細信息，但我們沒有收到回复。一直以來，數據庫都在實時更新新的客戶數據。
1 月 28 日，TechCrunch 隨後聯繫了台灣數字事務部，該政府部門負責監管和監督該國的互聯網和電信，以幫助向該公司披露安全漏洞。在一封電子郵件回復中，台灣數字事務部長Audrey Tang告訴 TechCrunch，暴露的數據庫已被台灣國家計算機應急響應小組標記為 TWCERT/CC。一小時內，暴露的 iRent 數據庫變得無法訪問。
不久之後，和泰汽車確認它已經保護了數據庫。“我們立即阻止了與該 IP 的外部連接。” 和泰表示，將通知數據洩露的客戶。
目前尚不清楚，除了 Sen 之外，是否還有其他人在洩漏數據的九個月內發現了該數據庫。
事故摘要
- 內部用來記錄應用程式Log檔之暫存資料庫，因未適當阻擋外部連線，導致該資料庫可能遭外部專業資訊人員使用特定工具及技巧進入該資料庫內查詢近三個月的會員異動資料
- 和泰表示，暫存資料庫發生防護性缺口一事，iRent已於1月28日接獲通報1小時進行缺失防堵
- iRent發生資安缺口之暫存資料庫，僅保存經遮蔽之信用卡資訊
- techcrunch 說和泰花了一週才處理，並且是在政府的干預下才進行。
處置措施
- 後續iRent除執行主機系統弱點掃描及滲透掃描，App部分也已進行源碼掃描，確保客戶交易過程全程採用SSL安全加密，並著手進行加殼處理
- 委請外部專業資安公司監控是否有會員資料流出
- 不久之後，和泰汽車確認它已經保護了數據庫。我們立即阻止了與該 IP 的外部連接"(We had blocked the outside connection to this IP immediately)
- 已完成資安強化防護及風險管理機制
無言的回應
- 會員最關心之重要金融資料完全無外流風險
- 消費者至今並未有發生實質損失之狀況。
- 基於珍視會員權益、積極防堵詐騙之態度，決定拉高資訊安全防護原則，主動擴大將「個資風險對象」之定義調整為「該暫存資料庫自啟用以來，所有曾涉潛在風險之40.01萬用戶」
- 除交通部公路總局於第一時間派員進行行政檢查外，台北市交通局、新北市交通局等主管機關，均積極多次現地輔導關切，iRent高度感謝並虛心接受。
上面這段我就不予置評了…。
關鍵問題
事故經過與描述，回過頭來看和泰的說法，會發現一些問題：
- 和泰說 1/28 就處理了，但 techcrunch 說一週才在政府干預下處理。
- 依據 techcrunch 的說法，資料來自未經保護、放在 Internet 上的資料庫。但 iRent 公開的處置措施1跟2都無法解決該問題，處置措施3更是有趣，所以和泰內的東西是可以讓外部 ip 任意連線的嗎？那還有沒有別的東西是可以從外部連線的？
- 承上；處置措施4 說已經完成了資安強化防護及風險管理機制，依據已看到的內容…限制外部ip不能連線？這樣就算已完成強化了嗎？而風險管理機制要更新，有這麼容易嗎？是更新的「機制」？還是單純的擴增要風評的項目，或是重新進行風評而已？
- LOG 裡面為什麼會存那些資料？裡面有照片a，真的是LOG資料外洩嗎？
- 承上；由於資料類型的來源包含了新增會員與日常活動這二種類型，我猜測是整個系統的資料都公開了。而非只有log。
只能說官方回應的東西就是制式SOP，看看就算了…。
總結一下，依據前面的描述與處理內容，我估計一開始是系統沒有依照好的(或夠安全的)開發生命週期管理機制進行開發控管，後續「八成是」有人防火牆設定疏失、導致內部系統可被 Internet 存取，而這也可以說明為什麼整個系統都被人看光光、但和泰卻很快回覆已處理完畢。
我的看法
我在某司任職資安官時，其中一個重要推進項目就是將資安要確實與RD/產品線合作，將資安確實融入公司文化。
一般談SSDLC的人會要求這些東西：
- 系統要將安全納為規格
- 系統開發與驗收過程中要做檢測，包含RD個人/專案層級的源碼掃描、弱點掃描與滲透測試。
- 系統資料要納入保護，包含存取控制、遮罩/加密與備份要求(法遵)。
我的做法：
- RD/產品線在開新案時，必需通知資安參與
- 在架構討論過程中，資安必需全程參與，並且架構師與研發必需回覆資安提出的要項。
- 資安必需針對產品功能與定位、環境、架構、各級元件(硬體/OS/AP/框架…等)、資料生命週期進行書面化。註1
- 產品在進行SATP階段時，資安必需參與測試，包含但不限於弱掃與PT。註2
- 產品在實際佈署時，資安必需參與，確定實作環境、方式與存取設計的安全。
我這麼做的原因很簡單，首先是讓RD"自己"按照自己的想法去勾查檢表(資安規格)，怎麼可能會有"Assurance"的效果？再來，如果RD不做、隨便做、擺爛，那資安就不用去要求了嗎？十之九成九，資安是第一個被拋棄的規格與要求。
用這種方式推進的好處在於：
- 資安是專案的參與者，較易融入圑隊、使得安全要求更容易被接受與推行。而不是偶爾出現的要求者，丟了東西就不關他的事。
- 資安長期參與專案，在圑隊中會變成一個"可諮詢的對象"，更容易發掘各種細節與異動。因為魔鬼就在細節裡。
- 註1 的項目會是由資安進行，是因為該文件由資安撰寫的話，更容易確何描述與細節這二個項目的品質。同時，也不會讓研發「增加不關他的事的工作」
- ATP 階段就要測試，這種東西我很務實的覺得可遇不可求。當時有些圑隊有做，有些沒有，但我一個人的心力有限，只能抓關鍵項目進行控管。
這樣子做資安，雖然會辛苦些，但資安人員可以更清楚掌握公司"產品"與"環境"的狀況，一定比監控EDR、看看SIEM跟做弱掃，更能有效保障安全性。一定比做 ISO 27001…等，更有意義。
或許有人會提問；那來這麼多資安人員？我當年只有一個人，而公司有6-7個產品線，我本身還有其他工作。所以我挑了3個產品線來推動前述做法，過程中有吸引其他RD想加入這樣的角色。人少？那麼就挑重點做、改個方法做，而不是不做。
結尾
有些事情其實不應該會發生的，閉門造車也沒意義。
安全就是要究 Assurance，如果什麼事都是內部說了算，這樣你能放心嗎？
適時的找好顧問，一來可以分擔人員 loading，二來可以獲得外部意見 – ISO 27001不也是要通過外部稽核員的審查，才能取得證書嗎？
