4 triệu thông tin người dùng dễ dàng bị rò rỉ và câu hỏi về thực trạng An ninh mạng tại Việt Nam

Lời mở đầu

Tình trạng thiếu bảo mật, thiếu kiểm soát riêng tư của người dùng đang xảy ra trên rất nhiều doanh nghiệp ở Việt Nam và cả trên thế giới. Vấn đề này không mới, không phải khó khắc phục, nhưng đã và đang bị xem nhẹ. Và mục đích chính của bài viết này chính là cảnh báo những doanh nghiệp, tổ chức cũng như người dùng hãy chú ý nhiều hơn đến vấn đề An toàn thông tin cấp bách hiện nay.

Vì tôn trọng và không muốn làm giảm uy tín của công ty/tổ chức này. Tôi xin giấu tên và gọi họ là X.

Tôi đã tình cờ phát hiện lổ hổng này như thế nào?

Tôi là một người dùng của X, và một hôm khi sử dụng ứng dụng Android của X trên điện thoại của mình, tôi phát hiện rằng mình có thể truy cập vào thông tin nhạy cảm của người dùng khác như email, số điện thoại, địa chỉ,... Đây là một tính năng của ứng dụng, cho phép người dùng liên lạc với nhau, có lẽ không ai chú ý đến. Tuy nhiên, theo phán đoán và kinh nghiệm, chức năng này nếu không được bảo mật một cách đúng đắn, hacker có thể làm giả các request hệt như ứng dụng tới server của X và từ đó lấy toàn bộ thông tin người dùng. X có số lượng người dùng rất lớn - hàng TRIỆU, nên nếu điều này là khả thi, đây thực sự là một lổ hổng bảo mật nghiêm trọng.

Từ phán đoán đến thực tế

Bắt đầu với suy nghĩ trên, tôi tiến hành phân tích các request mà ứng dụng của X. Tôi sử dụng ARC Welder để chạy ứng dụng X trên máy tính và Fiddler để capture tất cả request đi ra từ ứng dụng đó. Cấu hình xong xuôi, thử tiến hành mở ứng dụng lên và sử dụng một vài tính năng cơ bản, Fiddler lập tức bắt được nhiều thông tin đáng chú ý sau:
Fiddler capture X android app request Chà chà, bạn có thể thấy ứng dụng request tới các trang có dạng https://x-server-api/profile/id-người-dùng, thử copy url của những trang này này và truy cập bằng trình duyệt thử xem thì còn đáng kinh ngạc hơn:
Api get user public informations Bạn có thể thấy tôi hoàn toàn có thể lấy được thông tin của người dùng qua trình duyệt, điều này có nghĩa là:

  • Lấy thông tin người dùng chỉ cần ID, mà ID lại là ID tự tăng bởi Database (auto_increment) nên chỉ cần cho quét từ 1 đến max, hacker có thể lấy tất cả thông tin người dùng.
  • API này không hề có một phương thức xác minh nào, kể cả authorization token hay authorization header,... Thậm chí API truyền tham số qua phương thức GET chứ không phải POST.

Tới thời điểm này, thì phán đoán của tôi hoàn toàn chính xác. Thật nguy hiểm, những thông tin này nếu rơi vào tay kẻ xấu sẽ gây hậu quả nghiêm trọng.

Xác định bao nhiêu người dùng bị ảnh hưởng

Lổ hổng nghiêm trọng như vậy, nhưng câu hỏi đặt ra là đã có bao nhiêu người dùng thông qua X mà bị lộ hết thông tin? Để trả lời câu hỏi này, tôi tiến hành xác định bằng phương thức đoán mò kinh điển.

Do ID trong API lấy thông tin trên là ID tự tăng bởi Database (cứ thêm 1 người dùng thì ID tăng lên 1), nên ta có thể dễ dàng xác định số lượng bị ảnh hưởng dễ dàng bằng cách tìm Min ID và tìm Max ID.
Tìm Min ID thì đơn giản, cho chạy từ 1 và tăng dần cho tới khi API trả về thông tin. Và ngay từ con số 1, API đã cho thấy có người dùng (có lẽ là người dùng đầu tiên của X).
Tiếp tục tìm Max ID, X là công ty lớn nên tôi mạnh dạn thử ngay với con số 1 triệu (1000000), API vẫn không báo lỗi, tăng lên 2 triệu, vẫn không luôn, chà chà sao nhiều vậy nhỉ, và cuối cùng API chỉ báo lỗi với con số 5 TRIỆU. Điều này có nghĩa hơn 4 TRIỆU người dùng tại Việt Nam bị ảnh hưởng (con số chính xác hơn 4 triệu 100 ngàn). Một con số cực khủng, nếu so sánh với số lượng người dùng Internet tại Việt Nam (nguồn) tính đến năm 06/2016 là 52 triệu người dùng thì cứ 13 người sử dụng Internet tại Việt Nam có 1 người đã bị lộ thông tin.

Truy tìm lổ hổng

Các ứng dụng trên Android có thể dễ dàng giải mã và xem code gốc, nên tôi tiến hành giải nén file APK của ứng dụng X ra xem xét.
Extract X android app Ta chỉ cần quan tâm 2 file là classes.dexclasses2.dex, đây là 2 file lưu code java dưới dạng binary. Tiếp tục tôi giải nén 2 file này bằng công cụ dex2jax. Giải nén xong được một loạt rất nhiều các file code java, nếu xem hết tốn rất nhiều thời gian nên tôi quyết định sử dụng công cụ grep để tìm file nào chứa đoạn code liên quan tới lổ hổng trên.
Grep find vulnerable files 1 Grep find vulnerable files 2 Dễ dàng xác định được 3 file liên qua đó là Config.java, ApiConfig.javaXService.java, thử mở 3 file này bằng Sublime Text để xem xét kĩ hơn.

Đầu tiên là file Config.java, file này cấu hình về đường dẫn tới Server API cùng với các authorization key (không hiểu sao API gây lổ hổng trên lại không sử dụng cái này để tăng bảo mật?) X Api Config Tiếp theo là file ApiConfig.java, đúng hệt như tên của nó, file này chứa những cấu hình liên quan tới API của X.
X Api Config Detail Cuối cùng, file quan trọng nhất mà ta cần xem xét đó là file XService.java, file này chứa hàng loạt các phương thức tương tác với API. Và tôi dễ dàng tìm phương thức chúng ta quan tâm nhất ở đây:
Request Public Profile Method Phương thức này được truyền vào ID của người dùng (String str) và Request tới API (URL API được cấu hình ở 2 file trên). Đây chính là nơi gây ra sự thất thoát thông tin.

Giải pháp:
  • Thay đổi việc sử dụng ID tự tăng bằng ID tạo ra ngẫu nhiên cho từng người dùng (trên server của X đã có hash_id làm được điều này nhưng không hiểu sao không dùng?).
  • Loại bỏ bớt các thông tin nhạy cảm của người dùng qua API, chỉ giữ lại những thứ cần thiết.
  • Thêm tính năng chỉ gửi những thông tin nhạy cảm cho người khác nếu người dùng cho phép.
  • Thêm các authorization key, authorization header cần thiết cho API.
  • Giới hạn số lần gọi API này đối với mỗi IP.
  • Obfuscate code để khiến hacker khó đọc code.
Những câu hỏi trăn trở về An ninh mạng tại Việt Nam qua vụ việc này

Câu hỏi 1: Liệu thông tin của chúng ta có được an toàn?

Tôi là một người nghiên cứu về bảo mật, áp dụng nhiều phương pháp và thói quen để có thể bảo mật thông tin cho chính mình. Nhưng chỉ cần một trang web, một ứng dụng mà tôi sử dụng bị tấn công, thì kẻ xấu có thể dễ dàng có được những thông tin này và tiến hành tấn công tôi dù tôi đã áp dụng nhiều phương pháp bảo mật đi chăng nữa. Vậy, còn bạn thì sao? Bạn có phải là người may mắn không có trong danh sách 4 triệu người dùng kia và vô vàn những vụ lộ thông tin khác?

Câu hỏi 2: Liệu doanh nghiệp, tổ chức ở Việt Nam có chú ý tới An ninh mạng?

Vấn đề lộ thông tin người dùng qua API không phải là lần đầu xảy ra. Những vụ như Lozi lộ 2 triệu người dùng do anh Phạm Huy Hoàng phát hiện hay tương tự với con số 3 triệu do Blogger Juno_Okyo tìm ra và bây giờ đã lên tới con số 4 triệu cho thấy thực trạng đáng báo động về sự kém quan tâm của doanh nghiệp, tổ chức với vấn đề An toàn, bảo mật thông tin.

Câu hỏi 3: Câu hỏi dành cho mọi người

Ở đâu đó ngoài kia, trên đà phát triển mạnh của công nghệ thông tin hiện nay, còn bao nhiêu những lổ hổng tương tự như vậy vẫn đang còn tồn tại?

POC (Proof of Concept)

Exploit X Server

Timeline
  • 15:11 19/02/2017: Gửi mail báo cáo lổ hổng tới X.
  • 11:01 20/02/2017: X liên hệ qua điện thoại, trao đổi rằng lổ hổng đang được kĩ thuật xem xét và vá lỗi.
  • 17:05 23/02/2017: Sau hơn 3 ngày, lổ hổng nghiêm trọng này vẫn chưa được X vá. Hành động duy nhất của X là obfuscate code ứng dụng android và cập nhật (thậm chí không hề chỉnh lại code). Tuy nhiên phần chính gây nên lổ hổng là API vẫn chưa được áp dụng bất kì phương pháp bảo mật nào. Vì lí do đó tôi quyết định đăng tải bài viết này để cảnh báo người dùng đang bị đe dọa bởi lổ hổng.
  • 16:30 24/02/2017: Gặp trực tiếp đại diện của X trên văn phòng của X và trao đổi một số thông tin liên quan.
Dây rút nhựa tp hcm