Vụ hack công ty bảo hiểm bằng cách lạm dụng công cụ tính phí bảo hiểm
(eaton-works.com)- Thông tin xác thực Microsoft corporate cloud bị lộ trên subdomain công cụ tính phí bảo hiểm của Eicher Motors, cho phép đăng nhập vào tài khoản email noreply của TTIBI
- API gửi email liên quan đã gửi thư mà không cần xác thực, và nhật ký gửi trong phản hồi lỗi máy chủ làm lộ mật khẩu được mã hóa base64
- Tài khoản bị lộ còn lưu 657.000 email đã gửi cho khách hàng, cùng khoảng 25GB PDF hợp đồng bảo hiểm, thông tin khách hàng, liên kết đặt lại mật khẩu và OTP
- Tài khoản không có xác thực hai yếu tố, và các tài nguyên đám mây khác như thư mục doanh nghiệp Microsoft, SharePoint, Teams cũng có thể bị truy cập
- API dễ tổn thương được sửa để yêu cầu xác thực sau hơn 2 tháng kể từ khi được báo cáo; tính đến ngày 27/01/2024, mật khẩu tài khoản email cũng đã được đổi nên không thể đăng nhập nữa
Vụ xâm nhập TTIBI bắt đầu từ công cụ tính phí bảo hiểm của Eicher
- Trong quá trình điều tra hệ thống Eicher Motors, tài khoản email Microsoft
noreplyeicher@ttibi.co.incủa Toyota Tsusho Insurance Broker India, sau đây gọi là TTIBI, đã bị lộ - TTIBI là công ty môi giới bảo hiểm tại Ấn Độ thuộc Toyota Tsusho Insurance Management Corporation của Nhật Bản, được thành lập năm 2008
- Eicher Motors là nhà sản xuất ô tô của Ấn Độ, sản xuất xe máy của Royal Enfield Motors và xe thương mại của VE Commercial Vehicles, liên doanh với Volvo Group
- Hai công ty có quan hệ hợp tác liên quan đến bảo hiểm, và trên website của TTIBI có một subdomain riêng cho Eicher
Cách phát hiện lỗ hổng
- Khi phân tích ứng dụng Android MY EICHER, URL công cụ tính phí bảo hiểm được tìm thấy trong lớp Java giao diện API
- Mã nguồn website công cụ tính phí bảo hiểm có chứa cơ chế gửi email phía client
- Trong mã có dấu vết sử dụng Bearer Authorization nên tưởng như cần xác thực, nhưng khi tự tạo yêu cầu API trực tiếp, email thực sự được gửi thay vì nhận
401 Unauthorized - Phản hồi lỗi máy chủ trả về kèm nhật ký gửi email, trong đó có mật khẩu được mã hóa base64
Dữ liệu còn lưu trong tài khoản noreply
noreplyeicher@ttibi.co.inlà tài khoản noreply dùng để gửi email tự động, nhưng tại TTIBI đây là tài khoản có thể đăng nhập thực sự- Tài khoản này còn lưu toàn bộ lịch sử email đã gửi cho khách hàng
- Tổng cộng 657.000 email
- Dung lượng khoảng 25GB
- Thông tin khách hàng
- PDF hợp đồng bảo hiểm
- Liên kết đặt lại mật khẩu
- OTP
- Vì có thể xem cả OTP và liên kết đặt lại mật khẩu, tài khoản chứa thông tin có thể bị lạm dụng để chiếm quyền tài khoản bảo hiểm của khách hàng
- Cũng có thể truy cập các tài nguyên Microsoft cloud bằng cùng tài khoản này
- Thư mục doanh nghiệp
- SharePoint
- Teams
Những thất bại bảo mật làm lỗ hổng nghiêm trọng hơn
-
Chức năng gửi email phía client
- Chức năng gửi email cho phép client kiểm soát tiêu đề, nội dung và người nhận có thể bị lạm dụng để gửi thư độc hại
- Vì email được gửi từ tài khoản thật, điều này có thể dẫn đến suy giảm uy tín email và phishing
-
Thiếu xác thực API
- Frontend có dấu vết sử dụng token xác thực, nhưng server không thực sự kiểm tra token
- Nếu server kiểm tra token, cuộc tấn công này có khả năng đã bị ngăn chặn
-
Phản hồi lỗi API quá mức
- Khi xảy ra lỗi trong quá trình xử lý API, quá nhiều thông tin được trả về cho client
- Trong trường hợp này, phản hồi lỗi đã trực tiếp làm lộ mật khẩu
-
Không có xác thực hai yếu tố
- Khi đăng nhập tài khoản Microsoft, không có xác thực hai yếu tố hay lời nhắc kiểm tra đăng nhập nào khác
- Nếu có xác thực hai yếu tố, việc đăng nhập thành công có khả năng đã khó hơn
-
Lưu giữ email
- Toàn bộ email tài khoản đã gửi và nhận đều được lưu lại, khiến lượng lớn thông tin khách hàng có thể bị truy cập dễ dàng
- Nếu có chính sách lưu giữ phù hợp, tác động của việc lộ dữ liệu khách hàng có thể đã giảm đi
Ứng phó và tình trạng hiện tại
- Tính đến ngày 17/01/2024, dù TTIBI đã biết về lỗ hổng hơn 5 tháng, mật khẩu tài khoản email vẫn chưa được thay đổi
- Theo bản cập nhật ngày 27/01/2024, mật khẩu tài khoản email đã được thay đổi, nên không thể đăng nhập vào tài khoản đó nữa
- API dễ tổn thương cuối cùng đã được sửa để yêu cầu xác thực
- Không rõ có cảnh báo đăng nhập Microsoft bất thường hay không; nếu có, cảnh báo có thể đã bị bỏ qua hoặc không được kiểm tra
Timeline báo cáo
- Vì TTIBI không nằm trong phạm vi chương trình công bố lỗ hổng HackerOne của Toyota, lỗ hổng được báo cáo cho CERT-In của Ấn Độ
- 07/08/2023: Gửi báo cáo chi tiết về lỗ hổng cho CERT-In
- 08/08/2023: CERT-In cấp case ID và trả lời rằng họ sẽ liên hệ với TTIBI
- 01/09/2023: Yêu cầu cập nhật tiến độ
- 06/09/2023: CERT-In trả lời rằng họ đã chuyển lỗ hổng cho TTIBI và sẽ chia sẻ thêm cập nhật
- 08/10/2023: Website bị ảnh hưởng đã bị gỡ xuống nhưng API dễ tổn thương vẫn còn, nên đã thông báo cho CERT-In
- 11/10/2023: CERT-In trả lời rằng TTIBI đã sửa lỗ hổng, nhưng khi kiểm tra thì lỗ hổng vẫn còn tồn tại
- 18/10/2023: API gửi email được đổi để yêu cầu xác thực, qua đó lỗ hổng được khắc phục
- Sau đó có trao đổi tiếp về việc có thưởng bug bounty hay không, nhưng TTIBI không phản hồi, và case được đóng vào ngày 22/12/2023
1 bình luận
Ý kiến trên Hacker News
Tôi không phải người Ấn Độ, nhưng từ góc nhìn của một người làm ở các công ty IT lớn kiểu Tata, chuyện này nghe quá thực tế
Ở đây, văn hóa quản lý thưởng cho việc làm cho rẻ, cùng văn hóa kìm hãm tính chủ động hay sự tự hiện thực hóa của lập trình viên, đóng vai trò rất lớn
Nếu thấy chuyện như vậy ở Mỹ thì tôi đã nghỉ ngay, nhưng họ về cơ bản không có lựa chọn vì nếu nghỉ việc sẽ bị thu hồi 90 ngày lương
Phần lớn quản lý xuất thân không phải kỹ thuật nên chỉ nghe điều họ muốn nghe, và không muốn nghe những gì sai trái
Ngay cả việc xem đó là kết quả do cùng một đội hay cùng một công ty tạo ra cũng có thể sai, vì họ silo hóa lập trình viên rất nặng: chia nhỏ thành lập trình viên API, lập trình viên Office 365, lập trình viên frontend, và không động vào lĩnh vực mà bản thân chưa được “chứng nhận”
Ngay cả trong cuộc họp của một dự án 100 triệu USD, họ cũng tranh cãi nghiêm túc về chi phí SendGrid, rồi cuối cùng lại thành chuyện một lập trình viên nói có thể làm bằng Office 365 vì không có “kinh nghiệm SendGrid”
Ngân sách đội bảo mật bị cắt đầu tiên vì “vốn dĩ phải an toàn rồi”, còn nếu nói với người kiểu cháu họ được tuyển làm phụ trách bảo mật thì thái độ sẽ là chính phủ hay ai đó cũng đâu có kiện, sao phải phiền phức
Lập trình viên không được khuyến khích phát triển, mà được dạy phải xử lý ticket và đừng hỏi
Tôi làm việc với nhiều lập trình viên Ấn Độ thông minh, nhưng đây không phải văn hóa đổi mới, mà là công việc bị đối xử như call center. Đừng đi lệch kịch bản, hãy ở trong phạm vi vấn đề hẹp, và miễn là không thất bại thì coi như đang thắng
Chuyện đó cũng có thể sớm đến với chúng ta
Một đại lý ô tô thuộc hệ thống Honda mà tôi từng làm việc cùng vào nửa sau thập niên 2000 đang lưu đơn xin vay tài chính bằng ID số tăng dần
Tôi đã không báo cáo, nhưng có thể xem được nhiều thông tin nhạy cảm của cư dân New Jersey như SSN, ngày sinh, tên, địa chỉ
Khi đó gần như không có bug bounty, còn CFAA thì có, nên tôi không báo cáo
Tôi đã bắt họ xóa đơn của mình, nhưng lỗ hổng vẫn tồn tại trong nhiều năm cho đến khi chuyển sang hệ thống mới, và hệ thống mới trông cũng có vẻ dễ bị tấn công
Từ đó tôi không giao dịch với đại lý đó nữa, và đến giờ vẫn rất cẩn trọng với đại lý ô tô và đơn xin vay tài chính. Dù đắt hơn một chút, tôi thường vay ở nơi khác
https://eaton-works.com/2023/06/06/honda-ecommerce-hack/
Tôi đang làm về mảng khác là tra cứu danh tính tại https://cerebrum.com, và bình luận này gợi cho tôi rất nhiều ý tưởng
Bản thân sai sót bảo mật thì kinh khủng, nhưng có vẻ vẫn có thể phần nào giải thích bằng việc giao cho một lập trình viên thiếu kinh nghiệm công việc vượt xa phạm vi hiểu biết của họ
Nhưng tôi không thể hiểu nổi rốt cuộc họ đã phê duyệt việc lưu tài liệu khách hàng mật trong tài khoản email như thế nào
Điều đó có nghĩa là không có ai chịu trách nhiệm biết cách vận hành doanh nghiệp này, và nếu là công ty con hay đối tác outsourcing thì cũng có nghĩa là chưa ai từng audit
Đây gần như là hành vi sơ suất hình sự đối với cả chủ sở hữu công ty lẫn bên giao việc này
Có thể mail server có tính năng lưu thư đã gửi, và đây là sản phẩm phụ của quyết định ngu ngốc dùng một tài khoản thật cho địa chỉ “noreply”
Nó kiêm luôn audit log, công cụ debug và bản sao lưu database
Họ chỉ thay đổi sau khi biết nhân viên mang toàn bộ thông tin khách hàng sang chỗ làm mới
Nếu “đã hơn 5 tháng mà TTIBI biết về lỗ hổng nhưng vẫn không đổi mật khẩu tài khoản email”, thì tôi hy vọng ít nhất họ đã loại mật khẩu Base64 ra khỏi error log
Chắc chắn là họ làm rồi. Phải không?
Mức ảnh hưởng thì khổng lồ, đúng nghĩa là quyền truy cập toàn bộ SharePoint và Outlook, nhưng con đường khai thác chỉ là xem JavaScript phía client, nên đây là một lỗ hổng khá lạ
Một điểm nhỏ là trong ảnh chụp màn hình, tôi nghĩ với thông tin nhạy cảm thì dùng khối đen để che sẽ tốt hơn làm mờ. Cẩn thận không bao giờ thừa
Do cấu trúc kết thúc bằng một “thư cảm ơn”, phần lớn các lỗ hổng như thế này không được báo cáo/công bố cho white hat, mà bị hacker tích cực khai thác
Cần có khung pháp lý buộc công ty chịu trách nhiệm về một mức độ quản lý bảo mật yếu kém nhất định liên quan đến dữ liệu cá nhân của khách hàng
Ấn Độ còn có vấn đề lớn hơn rò rỉ dữ liệu
Một trong số đó là nguồn cung điện ổn định
Tôi đang chờ ngày Ấn Độ có đủ điện để hacking trở thành mối lo chính
Họ đang kéo 100.000 km cáp quang mỗi tháng và dựng 350 trạm gốc 5G mỗi ngày
Cũng cần nhìn vào việc endpoint email giám sát về cơ bản được thiết kế như một worker/agent/runner truyền thông, rồi bị bỏ mặc và tiếp tục phình to
Điều này có nghĩa là họ không giám sát mức sử dụng email, và cũng không có cơ chế bổ trợ để tìm hành vi bất thường kiểu “tại sao alias email này lại tốn chi phí lưu trữ gấp mấy lần những cái khác?”
Điểm mấu chốt là “tài khoản noreply có thể nắm giữ mọi bản ghi từng gửi cho khách hàng, nên có thể là tài khoản quan trọng nhất trong tổ chức”
Nếu “nhà môi giới bảo hiểm hàng đầu trên toàn Ấn Độ” không có tiền thuê lập trình viên có năng lực, thì ít nhất cũng nên trả vài đồng cho người đã tìm ra và thông báo có trách nhiệm về nhiều vấn đề nghiêm trọng khiến khách hàng gặp rủi ro
Nhưng họ đã không làm vậy, và thật khó tin là ngay cả mật khẩu tài khoản email bị xâm phạm mà họ vẫn chưa đặt lại
Làm sao có thể tin một công ty hành xử kiểu này sẽ làm đúng được bất cứ điều gì
Toyota Tsusho Insurance Broker India trông giống một công ty nên tránh như tránh dịch
Đây không phải là ai đó chủ động phớt lờ cảnh báo bảo mật quan trọng, mà là trạng thái họ không hiểu bạn đang nói gì
Họ về cơ bản không nắm được môi trường mình vận hành hay vấn đề đang đối mặt, và vì thuật ngữ chuyên môn bạn dùng chẳng có ý nghĩa gì với bản thân họ hay đội của họ, họ chỉ muốn bạn biến đi
Thái độ kiểu “đừng gửi mấy email khó hiểu nữa. Chúng tôi có việc quan trọng”
Muốn giải quyết thì cần thay máu ban lãnh đạo ở cấp tổ chức, và người phụ trách IT cùng mọi thứ ông ta từng đụng vào đều phải ra đi
Một phần vấn đề nằm ở việc họ dùng hộp thư đến này như một tài khoản SMTP “miễn phí” để khỏi trả chi phí gửi email
Nếu dùng thứ như SES thì hộp thư đã gửi/hộp thư đến của tài khoản này đã không chứa nhiều thông tin nhạy cảm như vậy
SES rất rẻ, 0,10 USD cho mỗi 1.000 email
Bạn phải lưu mọi email đã gửi, và tạo giao diện để nhân sự nghiệp vụ không phải lập trình viên có thể xem và tìm kiếm các tin nhắn cũ
Nếu họ đang dùng toàn bộ chức năng của cách tiếp cận SMTP “miễn phí” này thì chi phí phát triển và bảo trì sẽ khá lớn