iRent 個資外洩事件是怎麼一回事？我的非專業解讀

這幾天大家應該都有看到新聞，共享汽機車大廠 iRent，被國外資安研究人員發現，因系統設定不當導致資料庫開放匿名存取，只要知道 IP 便能在上面查到客戶姓名、手機、Email、信用卡等個資，經通報廠商遲無回應(可能剛好在年假期間)，最後透過數位發展部轉由 TWCERT/CC ( 台灣電腦網路危機處理暨協調中心)介入才緊急調整，關掉存取權限。

我不算資安專業，但卻非常關注這次事件，理由是這種資安議題與我切身相關。有愈來愈多的服務提供線上申請(甚至只能線上申請)，每次遇到需要上傳身分證、雙證件照片的環節，若有臨櫃辦理選項，我都寧可親自跑一趟也不要從網路上傳身分證。自己會寫網站，知道從上傳、傳輸到儲存的運作方式，有多少環節可能出紕漏，稍有不慎資料便能輕易被複製偷走，成為資料外洩的破口。不清楚對方的資安意識與技術能力，實在很難有信心資料會被妥善保護？
(遇到非傳不可的場合，我唯一的自保手段是用自己寫的程式在身分證影本加浮水印，加好加滿。咦？為什麼不用現成 App 或人家寫好的工具？沒辦法，事關個資我就神經兮兮，只相信我自己)

(大誤)

人家生意做那麼大，背後肯定有專業團隊，安全管控應該有一定水準吧？何必杞人憂天？登楞! iRent 做了經典示範，數十萬個客戶的大公司，照樣犯下這種超超超低級錯誤，期間無人發現、覆核或糾正... (這次事件後，以後遇到要線上給個資，我只會更神經兮兮)

想多查些資料了解事件始末，無奈網路上消息不多，國內新聞大多來自同一篇外媒報導：TechCrunch 的 Hotai Motor exposed thousands of iRent customer documents。沒查到什麼技術細節討論，一來是發現問題的資安研究員並未揭露細節藉此炒作，只聚焦在通報當事者(這是我心中白帽駭客的典範，反觀去年藉 7-Zip CVE 大鬧一場的中二研究員...)，二來，對駭客圈這是個超無聊案例，完全用不到專業技巧高深手法(啊就店家保險箱沒鎖放門口)，深無技術含量可言，沒地方展現功力，有啥好討論的。

公路總局介入後，iRent 的回覆再多透露一些線索 iRent個資外洩！調查發現「防護性缺口」公總：限期改善，比較能推敲是怎麼一回事。這邊就整理我蒐集到的資料跟對事件始末的解讀。

一位資安研究員 Anurag Sen 近期發現 iRent 公司的某台雲端主機，有個沒設密碼的資料庫，裡面包含客戶姓名、手機號碼、Email、住家地址、駕照照片、部分遮蔽(文字馬賽克)的信用卡資料，熟悉該資料庫運作的人只要知道 IP 就能存取。其中包含數百萬筆部分信用卡號，至少十萬筆個資文件，包含自拍照、簽名及車輛資料... 等等。

TechCrunch 人員使用 Shodan 引擎查詢，顯示該資料庫最早可回溯到 2022 年五月開始洩漏資料，在資料庫還安全的時期有 4.2 TB 的資料。(此部分 TechCrunch 未解釋判斷依據，待求證)

TechCrunch 發了好幾封信給和泰汽車告知資料外洩一事但遲未獲回應，而此段期間資料庫仍在時時有客戶資料更新。1/28 TechCrunch 連絡上數位發展部，之後獲得部長唐鳳回覆，該事件已通報 TWCERT/CC，一小時內外洩資料庫便已無法存取。稍後和泰汽車證實，已封鎖該資料庫之外部連線，並會通報客戶資料外洩一事。而過去九個月期間，除了 Anurag Sen 之外有沒有其他人也發現此一漏洞並竊取資料，不得而知。

Anurag Sen 並未揭露資料庫種類等細節，但 iRent 回覆公路總局時，提到「已於 28 日接獲客服信件告知資料庫存有外洩風險，發現應用程式 Log 檔暫存資料庫發生防護性缺口，才會讓外部人員運用特定技術及工具可能進入資料庫查詢近 3 個月的會員異動資料。」

請教過兩位相關領域的前輩，關鍵字「Log 檔暫存資料庫」，加上 Anurag Sen 過去也曾發現成人影片網站 CAM4 因為 ElasticSearch 配置不當造成資料洩漏，出包源頭指向 ElasticSearch 資料庫。尤其，Anurag Sen 在 CAM4 事件時曾提到：

CAM4 had misconfigured an ElasticSearch production database so that it was easy to find and view heaps of personally identifiable information, as well as corporate details like fraud and spam detection logs.
“Leaving their production server publicly exposed without any password,” says Safety Detectives researcher Anurag Sen, whose team discovered the leak, “it’s really dangerous to the users and to the company.”
CAM4 的 ElasticSearch 正式資料庫沒設好，導致很容易被找到，而其中的個資、企業資料(詐騙及垃圾信偵測 Log)也被看光光。
發現資料洩漏的 Anurag Sen 團隊表示，「正式伺服器對 Internet 公開且沒密碼管控，無疑是置使用者與公司於險境」

由此，大概可以推測本次事件與 CAM4 類似，是 ElasticSearch 資料庫設定不當(未隔離網段、限制存取 IP，也沒設密碼管制存取)，導致 Log 性質資料外流，不是核心資料庫洩漏，故流出資料也偏瑣碎。

但資安這檔事跟築堤防洪有點像，破一個洞都破十個洞都是出大事。而搞網站寫服務，只能如履薄冰，時時繃緊神經。

【參考資料】

• Hotai Motor exposed thousands of iRent customer documents
• iRent 10萬用戶個資外洩、資料庫門戶大開9個月？和泰回應了
• iRent個資外洩！調查發現「防護性缺口」公總：限期改善
• 成人网站泄露 108 亿数据后，一个 Elasticsearch 爱好者的思考

2023-02-05 更新

iRent 發布了正式聲明：

因為「內部用來記錄應用程式Log檔之暫存資料庫，因未適當阻擋外部連線，導致該資料庫可能遭外部專業資訊人員使用特定工具及技巧進入該資料庫內查詢近三個月的會員異動資料。」該暫存資料庫曾紀錄之個資包含會員姓名、電話、地址、經遮蔽之信用卡資訊（排除盜刷疑慮）、身分證、生日、Email、緊急聯絡人、申請會員上傳照片檔（經編碼），有遭外部查詢之可能

符合先前推測：蒐集 Log 用的 ElasticSearch 資料庫未設密碼未限存取客戶端 IP 造成，外流資料包含會員姓名、生日、電話、地址、Email、緊急聯絡人、經馬賽克的信用卡號、會員上傳照片(有編碼)。

由於 Log 保留最近三個月的內容，若以通報日推算，上面有近三個月內使用過該服務會員的資料，人數共計 14 萬人；假設更早之前就有其他人發現並偷取資料，得回溯擴大到這九個月來用過該服務的所有會員，共計 40.01 萬人。

聲明提到三種補強手段：

1. 弱點掃描：Vulnerability Assessment，自動化工具掃瞄已知弱點
2. 滲透測試：Penetration Test，由技術人員模仿駭客攻擊破解
3. 源碼檢測：Source Code Analysis，用工具檢查程式有沒有可能危害安全的不當寫法

本次問題屬設定管理不當，最有效發現問題的手段應是滲透測試，其次為弱點掃描(假設掃描項目包含允許匿名存取的 ElasticSearch 資料庫)，源碼檢測較幫不上忙。