sunny
VIP Members
-
30/06/2014
-
869
-
1.849 bài viết
Thông tin người dùng rò rỉ từ các ứng dụng Android phổ biến do SDK của bên thứ ba
Các ứng dụng di động phổ biến sử dụng bộ phát triển phần mềm (SDK) của bên thứ ba cho mục đích quảng cáo, để lộ dữ liệu người dùng do gửi các thông tin đó qua giao thức HTTP không an toàn, Kaspersky Lab cảnh báo.
Trong khi phân tích các ứng dụng hẹn hò phổ biến, công ty an ninh phát hiện dữ liệu người dùng thường bị gửi đi không được mã hoá khi sử dụng các SDK từ các mạng quảng cáo nổi tiếng. Với một số ứng dụng có vài tỷ lượt cài đặt trên toàn thế giới, các lỗ hổng an ninh khiến một lượng dữ liệu cá nhân khổng lồ gặp nguy hiểm.
Do tích hợp các công cụ phát triển và thường được cung cấp miễn phí, SDK cho phép các nhà phát triển ứng dụng ngay lập tức đưa một số tính năng vào ứng dụng của họ và tiết kiệm thời gian trong khi đang tập trung vào các yếu tố quan trọng khác. Tuy nhiên, điều đó cũng có nghĩa là các nhà phát triển không lường hết được các nguy cơ an ninh từ đoạn code mà mình sử dụng.
SDK quảng cáo được thiết kế thu thập dữ liệu người dùng để hiển thị các quảng cáo có liên quan đồng thời hỗ trợ nhà phát triển thu lợi từ sản phẩm của họ.
Các bộ dụng cụ này sẽ gửi dữ liệu thu thập được tới tên miền của các mạng quảng cáo phổ biến nhằm đảm bảo nhiều quảng cáo có chủ đích được hiển thị, nhưng dữ liệu gửi đi không được mã hóa qua HTTP, có nghĩa là dữ liệu không được bảo vệ khỏi hàng loạt các cuộc tấn công trong quá trình chuyển tiếp.
Dữ liệu không chỉ bị chặn, mà còn có thể bị sửa đổi, điều này có thể dẫn đến việc người dùng tiếp xúc với các quảng cáo độc hại thay vì các quảng cáo thông thường. Điều này có thể dẫn đến việc người dùng bị lừa tải các ứng dụng được quảng cáo nhưng thực chất là mã độc.
Các thông tin không được mã hóa bao gồm: thông tin thiết bị, ngày sinh, tên người dùng và tọa độ GPS cùng với thông tin về cách sử dụng ứng dụng (giống như những thông tin mà người dùng yêu thích (like)).
Các ứng dụng hẹn hò khác được phân tích cũng có những hành vi tương tự, sử dụng HTTP để liên lạc với máy chủ, nhưng lại gửi truy vấn HTTP đến máy chủ của bên thứ ba. Máy chủ này thuộc mạng lưới quảng cáo được sử dụng bởi cả hai ứng dụng hẹn hò và dữ liệu người dùng đã được gửi dưới dạng các thông số trong URL.
Kaspersky phát hiện ra rằng các ứng dụng bị rò rỉ có phần lớn code của bên thứ ba, với mỗi ứng dụng có ít nhất 40 module khác nhau.
"Chúng chiếm một phần rất lớn trong số những ứng dụng này - ít nhất 75% mã byte Dalvik nằm trong các module của bên thứ ba; có ứng dụng mà tỷ lệ code của bên thứ ba còn lên tới 90% ", Roman Unuchek thuộc Kaspersky ghi nhận trong một bài blog.
Sau khi phân tích các truy vấn GET và POST thông qua các ứng dụng phổ biến với SDK của bên thứ ba đang gửi dữ liệu không được mã hóa, hãng an ninh đã xác định được SDK phổ biến nhất đang rò rỉ dữ liệu người dùng cũng như các tên miền mà dữ liệu được gửi đến.
Bốn lĩnh vực phổ biến nhất mà ứng dụng tiết lộ dữ liệu thông qua truy vấn GET bao gồm mopub.com (được sử dụng trong các ứng dụng với hàng trăm triệu lượt cài đặt), rayjump.com (chín trong số các ứng dụng đã có tổng cộng 2 tỷ lượt cài đặt), tappas.net (hàng chục triệu cài đặt) và appsgeyser.com (được cho là được sử dụng trong 6 triệu ứng dụng với gần 2 tỷ lượt cài đặt).
Bốn tên miền phổ biến nhất các ứng dụng tiết lộ dữ liệu thông qua truy vấn POST bao gồm ushareit.com (một trong số các ứng dụng có hơn 500 triệu lượt cài đặt), Lenovo (đã bị rò rỉ dữ liệu người dùng do lỗi của nhà phát triển), Nexage.com (gần 1,5 tỷ lượt cài đặt mỗi app trên tổng cộng 8 ứng dụng) và Quantumgraph.com (với hàng chục triệu lượt cài đặt).
Trong hầu hết các trường hợp, các SDK bị rò rỉ dữ liệu bao gồm thông tin về thiết bị (độ phân giải màn hình, dung lượng lưu trữ, dung lượng, mức pin, phiên bản hệ điều hành, IMEI, IMSI, ngôn ngữ), thông tin mạng (tên nhà điều hành, địa chỉ IP, loại kết nối, cường độ tín hiệu, MAC), tọa độ thiết bị, ID Android, cách sử dụng ứng dụng và thông tin cá nhân như tên người dùng, độ tuổi và giới tính. Số điện thoại và địa chỉ email cũng có thể bị rò rỉ.
Vấn đề chính với các ứng dụng này là dữ liệu gửi đi không được mã hóa, có nghĩa là có thể bị chặn. Điều này có nghĩa là bất kỳ ai biết cách dữ liệu cũng có thể biết rất nhiều về người dùng và tùy thuộc vào dữ liệu được gửi đi, thậm chí có thể sử dụng với mục đích phá hoại. Ngoài ra, dữ liệu có thể được sửa đổi, dẫn đến các cuộc tấn công nguy hiểm khác.
"Bắt đầu từ nửa cuối năm 2016, ngày càng nhiều ứng dụng đã chuyển đổi từ HTTP sang HTTPS. Vì vậy, có thể nói chúng ta đang đi đúng hướng, nhưng quá chậm. Tính đến tháng 1/ 2018, 63% ứng dụng đang sử dụng HTTPS nhưng hầu hết trong số đó vẫn đang sử dụng HTTP. Gần 90% ứng dụng đang sử dụng HTTP. Và nhiều người trong số họ đang gửi đi những dữ liệu nhạy cảm không được mã hóa", Unuchek chỉ ra.
Nhà nghiên cứu kêu gọi các nhà phát triển ngừng sử dụng HTTP và thực hiện redirect 301 sang HTTPS cho các giao diện đầu cuối. Họ cũng nên mã hóa dữ liệu, luôn luôn sử dụng phiên bản SDK mới nhất và nên kiểm tra đường truyền mạng của ứng dụng trước khi phát hành.
Người dùng nên kiểm tra các quyền được yêu cầu bởi mỗi ứng dụng và chỉ cấp những quyền đó khi được yêu cầu cho chức năng của ứng dụng. Người dùng cũng nên sử dụng một VPN, dùng để mã hóa lưu lượng truy cập đến các máy chủ bên ngoài.
Trong khi phân tích các ứng dụng hẹn hò phổ biến, công ty an ninh phát hiện dữ liệu người dùng thường bị gửi đi không được mã hoá khi sử dụng các SDK từ các mạng quảng cáo nổi tiếng. Với một số ứng dụng có vài tỷ lượt cài đặt trên toàn thế giới, các lỗ hổng an ninh khiến một lượng dữ liệu cá nhân khổng lồ gặp nguy hiểm.
Do tích hợp các công cụ phát triển và thường được cung cấp miễn phí, SDK cho phép các nhà phát triển ứng dụng ngay lập tức đưa một số tính năng vào ứng dụng của họ và tiết kiệm thời gian trong khi đang tập trung vào các yếu tố quan trọng khác. Tuy nhiên, điều đó cũng có nghĩa là các nhà phát triển không lường hết được các nguy cơ an ninh từ đoạn code mà mình sử dụng.
SDK quảng cáo được thiết kế thu thập dữ liệu người dùng để hiển thị các quảng cáo có liên quan đồng thời hỗ trợ nhà phát triển thu lợi từ sản phẩm của họ.
Các bộ dụng cụ này sẽ gửi dữ liệu thu thập được tới tên miền của các mạng quảng cáo phổ biến nhằm đảm bảo nhiều quảng cáo có chủ đích được hiển thị, nhưng dữ liệu gửi đi không được mã hóa qua HTTP, có nghĩa là dữ liệu không được bảo vệ khỏi hàng loạt các cuộc tấn công trong quá trình chuyển tiếp.
Dữ liệu không chỉ bị chặn, mà còn có thể bị sửa đổi, điều này có thể dẫn đến việc người dùng tiếp xúc với các quảng cáo độc hại thay vì các quảng cáo thông thường. Điều này có thể dẫn đến việc người dùng bị lừa tải các ứng dụng được quảng cáo nhưng thực chất là mã độc.
Các thông tin không được mã hóa bao gồm: thông tin thiết bị, ngày sinh, tên người dùng và tọa độ GPS cùng với thông tin về cách sử dụng ứng dụng (giống như những thông tin mà người dùng yêu thích (like)).
Các ứng dụng hẹn hò khác được phân tích cũng có những hành vi tương tự, sử dụng HTTP để liên lạc với máy chủ, nhưng lại gửi truy vấn HTTP đến máy chủ của bên thứ ba. Máy chủ này thuộc mạng lưới quảng cáo được sử dụng bởi cả hai ứng dụng hẹn hò và dữ liệu người dùng đã được gửi dưới dạng các thông số trong URL.
Kaspersky phát hiện ra rằng các ứng dụng bị rò rỉ có phần lớn code của bên thứ ba, với mỗi ứng dụng có ít nhất 40 module khác nhau.
"Chúng chiếm một phần rất lớn trong số những ứng dụng này - ít nhất 75% mã byte Dalvik nằm trong các module của bên thứ ba; có ứng dụng mà tỷ lệ code của bên thứ ba còn lên tới 90% ", Roman Unuchek thuộc Kaspersky ghi nhận trong một bài blog.
Sau khi phân tích các truy vấn GET và POST thông qua các ứng dụng phổ biến với SDK của bên thứ ba đang gửi dữ liệu không được mã hóa, hãng an ninh đã xác định được SDK phổ biến nhất đang rò rỉ dữ liệu người dùng cũng như các tên miền mà dữ liệu được gửi đến.
Bốn lĩnh vực phổ biến nhất mà ứng dụng tiết lộ dữ liệu thông qua truy vấn GET bao gồm mopub.com (được sử dụng trong các ứng dụng với hàng trăm triệu lượt cài đặt), rayjump.com (chín trong số các ứng dụng đã có tổng cộng 2 tỷ lượt cài đặt), tappas.net (hàng chục triệu cài đặt) và appsgeyser.com (được cho là được sử dụng trong 6 triệu ứng dụng với gần 2 tỷ lượt cài đặt).
Bốn tên miền phổ biến nhất các ứng dụng tiết lộ dữ liệu thông qua truy vấn POST bao gồm ushareit.com (một trong số các ứng dụng có hơn 500 triệu lượt cài đặt), Lenovo (đã bị rò rỉ dữ liệu người dùng do lỗi của nhà phát triển), Nexage.com (gần 1,5 tỷ lượt cài đặt mỗi app trên tổng cộng 8 ứng dụng) và Quantumgraph.com (với hàng chục triệu lượt cài đặt).
Trong hầu hết các trường hợp, các SDK bị rò rỉ dữ liệu bao gồm thông tin về thiết bị (độ phân giải màn hình, dung lượng lưu trữ, dung lượng, mức pin, phiên bản hệ điều hành, IMEI, IMSI, ngôn ngữ), thông tin mạng (tên nhà điều hành, địa chỉ IP, loại kết nối, cường độ tín hiệu, MAC), tọa độ thiết bị, ID Android, cách sử dụng ứng dụng và thông tin cá nhân như tên người dùng, độ tuổi và giới tính. Số điện thoại và địa chỉ email cũng có thể bị rò rỉ.
Vấn đề chính với các ứng dụng này là dữ liệu gửi đi không được mã hóa, có nghĩa là có thể bị chặn. Điều này có nghĩa là bất kỳ ai biết cách dữ liệu cũng có thể biết rất nhiều về người dùng và tùy thuộc vào dữ liệu được gửi đi, thậm chí có thể sử dụng với mục đích phá hoại. Ngoài ra, dữ liệu có thể được sửa đổi, dẫn đến các cuộc tấn công nguy hiểm khác.
"Bắt đầu từ nửa cuối năm 2016, ngày càng nhiều ứng dụng đã chuyển đổi từ HTTP sang HTTPS. Vì vậy, có thể nói chúng ta đang đi đúng hướng, nhưng quá chậm. Tính đến tháng 1/ 2018, 63% ứng dụng đang sử dụng HTTPS nhưng hầu hết trong số đó vẫn đang sử dụng HTTP. Gần 90% ứng dụng đang sử dụng HTTP. Và nhiều người trong số họ đang gửi đi những dữ liệu nhạy cảm không được mã hóa", Unuchek chỉ ra.
Nhà nghiên cứu kêu gọi các nhà phát triển ngừng sử dụng HTTP và thực hiện redirect 301 sang HTTPS cho các giao diện đầu cuối. Họ cũng nên mã hóa dữ liệu, luôn luôn sử dụng phiên bản SDK mới nhất và nên kiểm tra đường truyền mạng của ứng dụng trước khi phát hành.
Người dùng nên kiểm tra các quyền được yêu cầu bởi mỗi ứng dụng và chỉ cấp những quyền đó khi được yêu cầu cho chức năng của ứng dụng. Người dùng cũng nên sử dụng một VPN, dùng để mã hóa lưu lượng truy cập đến các máy chủ bên ngoài.
Nguồn: Security Week