Điện thoại thông minh thường đi kèm với các ứng dụng được cài đặt sẵn, một số ứng dụng hữu ích và một số ứng dụng không bao giờ sử dụng được. Tuy nhiên, điều mà người dùng không mong đợi là đối với một ứng dụng được cài đặt sẵn sẽ là một trách nhiệm thực tế đối với quyền riêng tư và bảo mật của họ.
Nghiên cứu của Check Point gần đây đã phát hiện ra một lỗ hổng trong một trong những ứng dụng được cài đặt sẵn tại một trong những nhà cung cấp thiết bị di động lớn nhất thế giới, Xiaomi, với gần như 8% thị phần đứng thứ ba trên thị trường điện thoại di động. Trớ trêu thay, đó là ứng dụng bảo mật được cài đặt sẵn, ‘Guard Provider’ (com.miui.guardprovider), sẽ bảo vệ điện thoại bằng cách phát hiện phần mềm độc hại, thực sự khiến người dùng bị tấn công.
Nói một cách ngắn gọn, do tính chất không an toàn của lưu lượng mạng đến và đi từ Guard Provider, kẻ đe dọa có thể kết nối với cùng một mạng Wi-Fi với nạn nhân và thực hiện một cuộc tấn công Man-in-the-Middle (MiTM). Sau đó, là một phần của bản cập nhật SDK của bên thứ ba, anh ta có thể vô hiệu hóa tính năng bảo vệ phần mềm độc hại và đưa vào bất kỳ mã giả mạo nào mà anh ta chọn để lấy cắp dữ liệu, cấy ransomware hoặc theo dõi hoặc cài đặt bất kỳ loại phần mềm độc hại nào khác.
Xiaomi ‘Guard Provider’ là một ứng dụng được cài đặt sẵn trong tất cả các điện thoại Xiaomi chính thống sử dụng một số Bộ phát triển phần mềm (SDK) của bên thứ ba như một phần của dịch vụ bảo mật mà nó cung cấp, bao gồm nhiều loại bảo vệ, xóa và tăng cường thiết bị.
Ứng dụng này bao gồm ba nhãn hiệu chống vi-rút khác nhau được tích hợp sẵn mà người dùng có thể chọn để giữ cho điện thoại của họ được bảo vệ: Avast, AVL và Tencent. Khi chọn ứng dụng, người dùng chọn một trong những nhà cung cấp này làm công cụ Chống vi-rút mặc định để quét thiết bị.
Trước khi giải thích kịch bản tấn công tiềm ẩn, điều quan trọng là phải chỉ ra rằng thực sự có một số nhược điểm tiềm ẩn trong việc sử dụng một số SDK trong cùng một ứng dụng. Bởi vì tất cả chúng đều chia sẻ bối cảnh ứng dụng và quyền, những nhược điểm chính sau đây là:
Sự cố trong một SDK sẽ ảnh hưởng đến khả năng bảo vệ của tất cả các SDK khác.
Dữ liệu lưu trữ riêng tư của một SDK không thể bị cô lập và do đó, SDK khác có thể truy cập.
Với trường hợp của Nhà cung cấp bảo vệ Xiaomi, chúng tôi chỉ ra bên dưới cách thức tấn công Thực thi mã từ xa (RCE) có thể xảy ra khi tích hợp hai SDK có hành vi có vấn đề.
Nói một cách ngắn gọn, do lưu lượng mạng của Nhà cung cấp bảo vệ từ bất kỳ thiết bị Xiaomi nào không được bảo mật, điều này cho phép nó bị chặn thông qua cuộc tấn công Man-in-the-Middle (MiTM) và đưa mã giả mạo như một phần của bản cập nhật SDK của bên thứ ba. Hãy xem xét kịch bản tấn công có thể xảy ra.
Sân khấu 1: Cập nhật bản cập nhật Avast
Theo mặc định, với Avast được đặt làm trình quét bảo mật của ứng dụng, ứng dụng cập nhật định kỳ cơ sở dữ liệu vi rút của ứng dụng bằng cách tải xuống tệp APK avast-android-vps-v4-release.apk vào thư mục riêng của Guard Provider: /data/data/com.miui. Guardprovider / app_dex / vps_update_
Sau đó, tệp APK này được Avast SDK tải và thực thi trước khi quét thiết bị và chứa dấu thời gian khi tệp được tải xuống. Ví dụ: vps_update_20190205-124933.apk.
Check Point đã tiết lộ lỗ hổng này một cách có trách nhiệm cho Xiaomi, hãng đã phát hành bản vá ngay sau đó.
Thật không may, do cơ chế cập nhật sử dụng kết nối HTTP không an toàn để tải xuống tệp này, tác nhân đe dọa, thông qua cuộc tấn công MiTM, có thể phát hiện thời gian cập nhật Avast và dự đoán tên tệp APK của đĩa tiếp theo. Kẻ tấn công chỉ cần chặn phần phản hồi của kết nối http://au.ff.avast.sec.miui.com/android/avast-android-vps-v4-release.apk.
Hãy ghi nhớ điều này, vì tên tệp dự đoán của bản cập nhật Avast sau đó sẽ được sử dụng trong bước thứ hai của cuộc tấn công.
Bằng cách đánh chặn ban đầu, kẻ tấn công MITM do đó có thể ngăn chặn các bản cập nhật Avast trong tương lai bằng cách trả lời “lỗi 404” cho các yêu cầu http://au.ff.avast.sec.miui.com/android/vps_v4_info.vpx.
Sân khấu 2: Ghi đè APK cập nhật Avast thông qua lỗ hổng bảo mật thông qua đường dẫn cập nhật AVL
Khi kẻ tấn công bắt đầu chủ động chặn các kết nối đến máy chủ Avast, người dùng sẽ chuyển chương trình chống vi-rút mặc định sang một chương trình chống vi-rút khác – trong trường hợp này là Chống vi-rút AVL. Hãy nhớ rằng, SDK chống vi-rút AVL cũng là một phần được tích hợp sẵn của ứng dụng Nhà cung cấp bảo vệ.
Sau khi AVL trở thành chương trình chống vi-rút mặc định, nó sẽ ngay lập tức cập nhật ứng dụng với cơ sở dữ liệu vi-rút của nó. Nó thực hiện điều này bằng cách kiểm tra sự tồn tại của các chữ ký virus mới bằng cách yêu cầu tệp cấu hình (ví dụ: http://update.avlyun.sec.miui.com/avl_antiy/miuistd/siglib/20180704.cj.conf). Tệp .conf này có định dạng văn bản thuần túy, cho biết URL, kích thước và băm MD5 của kho lưu trữ ZIP với các chữ ký mới.
Sau khi xử lý tệp cấu hình, AVL sau đó tải xuống kho lưu trữ các chữ ký được chỉ ra trong trường read_update_url và giải nén nó vào thư mục Nhà cung cấp bảo vệ.
Một lần nữa, kẻ tấn công MITM có thể thay đổi nội dung của tệp .conf vì tệp được tải xuống qua kết nối không an toàn, bằng cách sử dụng is_new =0 để hiển thị sự tồn tại của bản cập nhật mới và cung cấp liên kết URL tới tệp ZIP được tạo thủ công.
Nó chỉ ra rằng AVL SDK dễ bị tấn công bởi một vấn đề bảo mật khác giúp kẻ tấn công thực hiện giai đoạn thứ hai của cuộc tấn công: một đường dẫn truyền trong quá trình giải nén. Do đó, kẻ tấn công có thể sử dụng bản lưu trữ thủ công để ghi đè lên bất kỳ tệp nào trong hộp cát của ứng dụng, bao gồm các tệp liên quan đến SDK khác.
Do đó, một APK được tạo thủ công, được thêm vào dưới dạng “../../app_dex/vps_update_20190205-124933.apk” vào mục lưu trữ của chữ ký ZIP sẽ ghi đè thành công bản cập nhật đã tải xuống trước đó từ Avast, vì cả hai thành phần SDK chống vi-rút đều sử dụng cùng một hộp cát trong SDK tương ứng của chúng.
Nếu bạn nhớ lại, tên tệp APK của bản cập nhật Avast cuối cùng đã được phát hiện trong bước đầu tiên của cuộc tấn công MiTM.
Tất cả những gì kẻ tấn công cần làm bây giờ là giải phóng giao tiếp Avast và chặn giao tiếp của AVL cho đến khi người dùng chọn lại Avast làm chương trình chống vi-rút hoạt động. Khi điều này xảy ra, tệp APK độc hại được tạo thủ công sẽ được Avast SDK tải và thực thi.
Cuộc tấn công thành công vì tệp chữ ký của bản cập nhật Avast trước đó không được xác minh trước khi tải và Nhà cung cấp bảo vệ đã kiểm tra tệp này trong lần đầu tiên tải xuống. Do đó, nó giả định rằng không có lý do gì để xác minh lại. Bằng cách này, tệp tin độc hại đã được chế tạo có thể được tải xuống và chạy vì về cơ bản anh ta đã lẻn qua lưng người bảo vệ.
Việc người dùng đặt niềm tin vào các ứng dụng cài sẵn của nhà sản xuất điện thoại thông minh là điều hoàn toàn dễ hiểu, đặc biệt là khi các ứng dụng đó tự bảo vệ điện thoại. Tuy nhiên, lỗ hổng này được phát hiện trong ‘Nhà cung cấp bảo vệ’ của Xiaomi, đặt ra câu hỏi đáng lo ngại về việc ai đang bảo vệ người giám hộ. Và mặc dù người giám hộ không nhất thiết phải bảo vệ, nhưng rõ ràng khi nói đến cách các ứng dụng được phát triển, ngay cả những ứng dụng được xây dựng bởi nhà cung cấp điện thoại thông minh, người ta không thể quá cẩn thận.
Kịch bản tấn công ở trên cũng minh họa sự nguy hiểm của việc sử dụng nhiều SDK trong một ứng dụng. Mặc dù các lỗi nhỏ trong mỗi SDK riêng lẻ thường có thể là một vấn đề độc lập, nhưng khi nhiều SDK được triển khai trong cùng một ứng dụng, có khả năng là các lỗ hổng nghiêm trọng hơn sẽ không còn xa nữa.
Check Point SandBlast Mobile, nếu nó được cài đặt trên thiết bị, sẽ phát hiện và ngăn chặn cuộc tấn công trung gian ban đầu, do đó loại bỏ mối đe dọa do lỗ hổng này gây ra trong Nhà cung cấp bảo vệ của Xiaomi.
. .
…
