Vụ rò rỉ dữ liệu Optus xảy ra như thế nào và cách phòng tránh?

1. Giới thiệu#

Vào tháng 9 năm 2022, Optus, một trong những nhà cung cấp viễn thông hàng đầu của Úc, đã trải qua một vụ rò rỉ dữ liệu làm lộ thông tin cá nhân của gần 10 triệu khách hàng. Sự cố này đánh dấu một trong những cuộc tấn công mạng lớn nhất trong lịch sử Úc, dẫn đến những lo ngại cao về quyền riêng tư dữ liệu và các thực tiễn bảo mật ở quốc gia này.

Bài viết này sẽ tập trung vào các câu hỏi sau:

• Optus đã có những lỗ hổng bảo mật nào dẫn đến vụ rò rỉ dữ liệu?
• Một số phương pháp đối phó nào Optus có thể đã sử dụng để tránh vi phạm bảo mật?

2. Các lỗ hổng bảo mật dẫn đến vụ rò rỉ dữ liệu Optus#

Dưới đây, bạn sẽ tìm thấy 5 lỗ hổng bảo mật của vụ rò rỉ dữ liệu tại Optus.

2.1 Lỗ hổng bảo mật #1: Lộ API hướng ra công chúng#

Lỗ hổng bảo mật lớn đầu tiên trong vụ rò rỉ Optus là việc sử dụng một API (Giao diện Lập trình Ứng dụng) hướng ra công chúng đã tạo điều kiện truy cập vào dữ liệu nội bộ nhạy cảm. Các API hướng ra công chúng được thiết kế để cho phép các hệ thống bên ngoài tương tác với các dịch vụ của một công ty, nhưng khi các API này không được bảo mật đúng cách, chúng có thể trở thành cửa ngõ cho những kẻ tấn công.

Các API hướng ra công chúng được sử dụng để làm gì?

Các API hướng ra công chúng an toàn, ví dụ như Google Maps API hoặc Weather API, cung cấp dữ liệu hạn chế, không nhạy cảm cho các hệ thống bên ngoài. Chúng được thiết kế để cô lập mọi dữ liệu được chia sẻ khỏi các hoạt động kinh doanh cốt lõi, khiến chúng an toàn hơn về bản chất.

Tại sao các API hướng ra công chúng lại là vấn đề trong trường hợp này?

Không giống như các API bảo mật, API của Optus đã làm lộ thông tin nhạy cảm của khách hàng và thiếu các biện pháp bảo vệ thiết yếu. Điều này khiến nó dễ bị tấn công bởi những kẻ có thể xác định được nó thông qua các đợt quét internet.

Những kẻ tấn công có thể khai thác API này như thế nào?

Không có xác thực hoặc cô lập dữ liệu, những kẻ tấn công có thể kết nối trực tiếp với API và truy xuất thông tin khách hàng bí mật, vượt qua các biện pháp bảo mật nội bộ.

2.2 Lỗ hổng bảo mật #2: API không được bảo mật cấp quyền truy cập vào dữ liệu khách hàng nhạy cảm#

Lỗ hổng bảo mật lớn thứ hai trong vụ rò rỉ dữ liệu Optus là API không được bảo mật. Do đó, nó đã cấp quyền truy cập vào dữ liệu khách hàng cực kỳ nhạy cảm. Trong khi vấn đề đầu tiên xoay quanh việc API hướng ra công chúng, thì vấn đề nghiêm trọng ở đây là việc thiếu các biện pháp kiểm soát truy cập thích hợp, cho phép truy cập không hạn chế vào thông tin bí mật.

Khi một khách hàng của Optus truy cập tài khoản của họ thông qua ứng dụng di động hoặc trang web của Optus, các API tạo điều kiện giao tiếp giữa giao diện người dùng (frontend) và hệ thống phụ trợ (backend) để truy xuất dữ liệu cần thiết. Các quy trình backend này thường xử lý thông tin nhạy cảm để tải hồ sơ khách hàng.

Trong trường hợp này, API bị lộ đã cung cấp cho những kẻ tấn công quyền truy cập trực tiếp vào các loại dữ liệu cá nhân sau đây, vốn đặc biệt có giá trị cho hành vi trộm cắp danh tính và gian lận:

• Số giấy phép lái xe • Số điện thoại • Ngày sinh • Địa chỉ nhà

Một phân tích về hồ sơ Hệ thống Phân giải Tên miền (DNS) công cộng sau đó tiết lộ rằng API này có khả năng hướng ra công chúng và có thể được truy cập bởi bất kỳ ai trên internet trong tối đa ba tháng.

2.3 Lỗ hổng bảo mật #3: Sử dụng mã định danh khách hàng tăng dần#

Lỗ hổng bảo mật thứ ba trong vụ rò rỉ dữ liệu Optus là việc sử dụng các mã định danh khách hàng tăng dần. Trong thế giới kỹ thuật số, các mã định danh khách hàng duy nhất — bao gồm các chuỗi số và chữ cái ngẫu nhiên — được sử dụng để phân biệt các tài khoản một cách an toàn. Các phương pháp an ninh mạng tốt nhất quy định rằng các mã định danh này phải ngẫu nhiên và không liên quan, nhằm ngăn chặn tin tặc xác định các mẫu hình.

Mã định danh khách hàng Optus: Trong trường hợp này, các mã định danh khách hàng tuân theo một mẫu hình có thể dự đoán được, khác nhau theo mức tăng là 1. Ví dụ: nếu mã định danh của một khách hàng là 5332, thì khách hàng tiếp theo sẽ là 5333. Khi tin tặc giành được quyền truy cập vào cơ sở dữ liệu, chúng có thể viết một tập lệnh tự động để truy xuất mọi bản ghi chỉ đơn giản bằng cách tăng dần mã định danh.

Phương pháp tự động này đã đẩy nhanh quá trình đánh cắp dữ liệu, cho phép kẻ tấn công trích xuất dữ liệu khách hàng nhạy cảm ở quy mô lớn. Lỗ hổng thiết kế có thể dự đoán được này đã tạo điều kiện cho vụ rò rỉ Optus xảy ra nhanh hơn và ảnh hưởng đến nhiều khách hàng hơn mức có thể.

2.4 Lỗ hổng bảo mật #4: Các biện pháp kiểm soát truy cập bị suy yếu do lỗi mã hóa#

Ngoài các lỗ hổng về API và ID khách hàng, còn có nhiều vấn đề bảo mật khác: Vào năm 2018, một lỗi mã hóa đã làm suy yếu các biện pháp kiểm soát truy cập trên một số tên miền nhất định của Optus, khiến chúng kém an toàn hơn. Mặc dù Optus đã khắc phục sự cố này trên trang web chính của mình vào tháng 8 năm 2021, nhưng họ đã không áp dụng bản sửa lỗi tương tự cho một trang web phụ có thể truy cập trên internet. Tên miền phụ này vẫn tồn tại lỗ hổng cho đến khi vụ rò rỉ được phát hiện vào tháng 9 năm 2022.

Sự sơ suất này đã để lại một lỗ hổng bảo mật đáng kể. Các tên miền hướng ra công chúng là mục tiêu phổ biến của những kẻ tấn công và mọi lỗ hổng chưa được vá đều làm tăng rủi ro truy cập trái phép. Trong trường hợp này, lỗi mã hóa đã giúp những kẻ tấn công có thể vượt qua các biện pháp kiểm soát truy cập và truy cập dữ liệu nhạy cảm.

Việc bỏ qua các tên miền phụ hoặc ít hiển thị hơn có thể để ngỏ các lỗ hổng nghiêm trọng, thứ mà những kẻ tấn công có thể khai thác một cách dễ dàng. Việc kiểm toán thường xuyên và kiểm thử kỹ lưỡng là điều cần thiết để đảm bảo rằng các bản cập nhật bảo mật được áp dụng ở mọi nơi cần thiết.

2.5 Lỗ hổng bảo mật #5: Tên miền phụ chứa lỗ hổng#

Sự thiếu giám sát thích hợp này đã lan rộng sang tên miền phụ, vốn đóng vai trò then chốt trong vụ rò rỉ. Mặc dù tên miền không được sử dụng tích cực, nhưng nó vẫn trực tuyến và không được bảo vệ trong một thời gian dài. Mặc dù không cần thiết cho các hoạt động hàng ngày, nó không được bảo mật bằng các biện pháp kiểm soát truy cập thích hợp cũng như không được ngừng hoạt động, tạo ra một điểm xâm nhập dễ dàng cho những kẻ tấn công khai thác.

Ngay cả khi không được sử dụng tích cực, các tên miền như vậy vẫn có thể đóng vai trò là vectơ tấn công nếu tồn tại lỗ hổng. Để giảm thiểu những rủi ro này, các công ty nên thường xuyên kiểm toán các tài sản kỹ thuật số của mình, nhanh chóng ngừng hoạt động các tên miền không sử dụng hoặc áp dụng cùng mức độ bảo mật như các hệ thống đang hoạt động.

3. Làm thế nào để tránh các vụ rò rỉ dữ liệu như vậy?#

Để ngăn chặn các vụ rò rỉ dữ liệu tương tự như vụ hack Optus và giảm thiểu nguy cơ thiệt hại về danh tiếng, các tổ chức có thể áp dụng các chiến lược bảo mật khác nhau mà bạn có thể tìm thấy ở phần sau:

3.1 Biện pháp đối phó #1: Tham khảo Dự án Bảo mật API OWASP#

Dự án Bảo mật API OWASP là một tài nguyên được cập nhật thường xuyên làm nổi bật các rủi ro bảo mật API đã biết. Điều cần thiết đối với các nhóm an ninh mạng là thường xuyên theo dõi cơ sở dữ liệu này để xác định và giải quyết các lỗ hổng có thể ảnh hưởng đến doanh nghiệp của họ. Nó bao gồm một loạt các rủi ro tiềm ẩn, ví dụ như:

• Ủy quyền Cấp Đối tượng Bị hỏng (Broken Object Level Authorization - BOLA): Các lỗ hổng trong quyền truy cập của người dùng cho phép truy cập dữ liệu trái phép.

• Lộ Dữ liệu Quá mức (Excessive Data Exposure): Các API trả về nhiều thông tin hơn mức cần thiết, làm tăng nguy cơ rò rỉ dữ liệu nhạy cảm.

• Cấu hình sai Bảo mật (Security Misconfigurations): Cài đặt hoặc mặc định bị lệch làm lộ các API nhạy cảm trước các cuộc tấn công.

• Lỗ hổng Tiêm (Injection Flaws): Những kẻ tấn công khai thác API để tiêm (inject) các lệnh hoặc dữ liệu độc hại.

3.2 Biện pháp đối phó #2: Bảo mật tất cả API bằng Giao thức Xác thực#

Dự án Bảo mật API OWASP nhấn mạnh các API không được xác thực là lỗ hổng API phổ biến thứ hai. Các API này không yêu cầu tên người dùng, mật khẩu hoặc bất kỳ phương pháp xác thực nào khác để thiết lập kết nối, khiến chúng rất dễ bị khai thác. Điểm yếu này đã đóng vai trò trung tâm trong vụ rò rỉ dữ liệu Optus.

Trong một số trường hợp, các API cố ý không được xác thực để duy trì khả năng tương thích với các hệ thống cũ hoặc cho mục đích thử nghiệm. Rất có thể Optus đã để API của mình không được xác thực vì những lý do tương tự. Tuy nhiên, dù việc thử nghiệm hoặc các yêu cầu của hệ thống cũ có quan trọng đến đâu, thì việc triển khai bất kỳ API nào—dù là nội bộ hay hướng ra công chúng—mà không có xác thực đều là một rủi ro bảo mật đáng kể.

Cách Ngăn Chặn Khai Thác API Không Được Xác Thực

Để bảo vệ các API của bạn, mọi yêu cầu kết nối phải được bảo mật bằng Xác thực Đa yếu tố (MFA). MFA thêm một lớp bảo vệ bổ sung bằng cách yêu cầu nhiều hình thức xác minh, khiến nó trở thành một trong những cách hiệu quả và đơn giản nhất để chặn truy cập trái phép vào các API và tài khoản người dùng.

Xác Định Các Lỗ Hổng API Bị Ẩn

Một chính sách bảo mật API chỉ có hiệu quả nếu tất cả các API yêu cầu bảo vệ đều được xem xét. Nhưng điều gì sẽ xảy ra nếu tổ chức của bạn vô tình bị phơi nhiễm bởi một API hướng ra công chúng, như trường hợp của Optus?

Các API bị ẩn hoặc bị bỏ qua rất khó bị phát hiện bằng các công cụ quét tiêu chuẩn. Cách hiệu quả nhất để phát hiện ra chúng là thông qua kiểm thử xâm nhập (penetration testing) để phơi bày các lỗ hổng như:

• Các cơ chế xác thực yếu: Các hệ thống chấp nhận mật khẩu văn bản gốc (plaintext) hoặc thông tin xác thực bị băm (hashed) kém.

• Khả năng bị tấn công nhồi nhét thông tin xác thực hoặc brute force: Khai thác tên người dùng và mật khẩu bị đánh cắp ở quy mô lớn.

• Thao túng tham số API: Tiết lộ chi tiết xác thực nhạy cảm trong các URL hoặc phản hồi.

4. Kết luận#

Tóm lại, vụ rò rỉ dữ liệu Optus nhấn mạnh tầm quan trọng đặc biệt của việc triển khai các biện pháp an ninh mạng mạnh mẽ và thường xuyên kiểm toán các tài sản kỹ thuật số. Việc không bảo mật các API, không thực thi các giao thức xác thực thích hợp và không giải quyết các lỗ hổng bị bỏ qua trên các tên miền phụ đã góp phần đáng kể vào sự cố này. Bằng cách áp dụng các phương pháp hay nhất trong ngành, chẳng hạn như những phương pháp được nêu trong Dự án Bảo mật API OWASP và ưu tiên các chiến lược bảo mật toàn diện, các tổ chức có thể chống lại các vụ rò rỉ tương tự, bảo vệ dữ liệu khách hàng nhạy cảm và quan trọng nhất là duy trì sự tin tưởng của người dùng.

Về Corbado

Corbado là Passkey Intelligence Platform dành cho các đội CIAM vận hành xác thực consumer ở quy mô lớn. Chúng tôi giúp bạn nhìn thấy điều mà log IDP và các công cụ analytics thông thường không thấy: những thiết bị, phiên bản OS, trình duyệt và trình quản lý credential nào hỗ trợ passkey, tại sao quá trình đăng ký không chuyển thành đăng nhập, luồng WebAuthn fail ở đâu, và khi nào một bản cập nhật OS hay trình duyệt làm hỏng đăng nhập một cách âm thầm — tất cả mà không cần thay thế Okta, Auth0, Ping, Cognito hay IDP nội bộ của bạn. Hai sản phẩm: Corbado Observe bổ sung observability cho passkey và mọi phương thức đăng nhập khác. Corbado Connect mang đến managed passkey với analytics tích hợp (song hành cùng IDP của bạn). VicRoads vận hành passkey cho hơn 5M người dùng với Corbado (kích hoạt passkey +80%). Trao đổi với chuyên gia Passkey →

Các Câu Hỏi Thường Gặp#

Dữ liệu cá nhân nào đã bị đánh cắp trong vụ rò rỉ Optus và tại sao nó lại gây hại đến vậy?#

API bị phơi nhiễm đã cung cấp cho những kẻ tấn công quyền truy cập trực tiếp vào số giấy phép lái xe, số điện thoại, ngày sinh và địa chỉ nhà. Những loại dữ liệu này đặc biệt có giá trị đối với hành vi trộm cắp danh tính và gian lận, khiến vụ rò rỉ này đặc biệt gây thiệt hại cho các khách hàng bị ảnh hưởng.

Tại sao một công ty lại để một API không được xác thực ngay từ đầu?#

Các API đôi khi cố ý không được xác thực để duy trì khả năng tương thích với các hệ thống cũ hoặc cho mục đích thử nghiệm, điều này có khả năng là trường hợp của Optus. Tuy nhiên, việc triển khai bất kỳ API nào, dù là nội bộ hay hướng ra công chúng, mà không có xác thực đều là một rủi ro bảo mật đáng kể bất kể lý do vận hành.

Làm thế nào các nhóm bảo mật có thể phát hiện các API bị ẩn hoặc bị bỏ qua trước khi những kẻ tấn công khai thác chúng?#

Các công cụ quét tiêu chuẩn gặp khó khăn trong việc phát hiện các API bị ẩn hoặc bị bỏ qua. Phương pháp tiếp cận hiệu quả nhất là kiểm thử xâm nhập (penetration testing), có thể phơi bày các cơ chế xác thực yếu kém, khả năng bị tấn công nhồi nhét thông tin xác thực (credential stuffing) và các chi tiết xác thực nhạy cảm bị lộ trong URL hoặc phản hồi API.

Dự án Bảo mật API OWASP là gì và nó giúp các tổ chức tránh các vụ rò rỉ như Optus như thế nào?#

Dự án Bảo mật API OWASP là một tài nguyên được cập nhật thường xuyên lập danh mục các rủi ro bảo mật API đã biết như Ủy quyền Cấp Đối tượng Bị hỏng (BOLA), Lộ Dữ liệu Quá mức, Cấu hình sai Bảo mật và Lỗ hổng Tiêm. Các nhóm an ninh mạng nên thường xuyên theo dõi nó để xác định và giải quyết các lỗ hổng trước khi những kẻ tấn công có thể khai thác chúng.