Cách GitHub tìm ra 24 lỗ hổng Android bằng AI agent bảo mật mã nguồn mở

Trong bối cảnh AI ngày càng đóng vai trò quan trọng trong lĩnh vực bảo mật, nhóm GitHub Security Lab đã tạo ra Taskflow Agent — một framework mã nguồn mở cho phép các nhà nghiên cứu bảo mật tự động hóa, đóng gói và chia sẻ những prompt cùng quy trình AI mà họ thấy hiệu quả trong công việc.

Bài viết này chia sẻ cách Kevin Stubbings, thành viên nhóm GitHub Security Lab, xây dựng các taskflow kiểm tra bảo mật để tìm ra lỗ hổng trong các ứng dụng Android. Kết quả: hơn 20 lỗ hổng đã được báo cáo, trong đó có những lỗi nghiêm trọng ảnh hưởng đến hàng chục triệu người dùng.

AI agent bảo mật hoạt động như thế nào?

Dù các mô hình ngôn ngữ lớn (LLM) ngày càng hiểu code tốt hơn, nhưng các prompt tùy chỉnh trong taskflow cho phép nhà nghiên cứu dẫn dắt AI theo từng bước tăng dần. Điều này giúp LLM tìm ra các lỗ hổng phức tạp nhanh hơn — hoặc phát hiện những lỗi mà nếu chạy prompt đơn lẻ sẽ bị bỏ qua hoàn toàn.

Cách tiếp cận cốt lõi là chia nhỏ quy trình kiểm tra thành các giai đoạn:

• Thu thập điểm xâm nhập (entry point) — nơi dữ liệu do kẻ tấn công kiểm soát có thể chảy vào
• Phân loại ứng dụng — xác định đâu là entry point di động, đâu là entry point web/desktop
• Kiểm tra từng lớp lỗ hổng — đối chiếu với danh sách các lớp lỗ hổng phổ biến
• Chạy lặp nhiều lần — kết hợp prompt nghiêm ngặt và prompt mở rộng để vừa không bỏ sót lỗi rõ ràng, vừa tận dụng khả năng sáng tạo của AI

Minh họa quy trình kiểm tra bảo mật bằng AI

Cách tự chạy taskflow trên dự án của bạn

Các taskflow này hoàn toàn mã nguồn mở và dễ chạy. Tuy nhiên cần lưu ý: bạn phải có giấy phép GitHub Copilot và các prompt sẽ tiêu tốn lượt yêu cầu của mô hình cao cấp. Quá trình chạy có thể gọi công cụ rất nhiều lần, tiêu hao lượng token đáng kể.

Quy trình gồm ba bước đơn giản:

1. Truy cập repository seclab-taskflows và khởi tạo một codespace
2. Chờ vài phút để codespace khởi tạo xong
3. Trong terminal, chạy lệnh ./scripts/audit/run_mobile.sh myorg/myrepo

Với repository quy mô trung bình, quá trình này có thể mất một đến hai giờ. Khi hoàn tất, công cụ sẽ mở trình xem SQLite với kết quả. Bạn vào bảng audit_results và tìm những dòng có dấu tích ở cột has_vulnerability.

Hai lỗ hổng thực tế đã được phát hiện

Theo dõi người dùng qua ứng dụng OsmAnd

OsmAnd là ứng dụng bản đồ điều hướng phổ biến sử dụng OpenStreetMap làm nguồn dữ liệu chính, với hơn 10 triệu lượt tải trên Google Play. Trong ba lỗ hổng được tìm thấy, lỗ hổng đáng chú ý nhất cho phép ứng dụng độc hại theo dõi vị trí thiết bị.

Vấn đề nằm ở MapActivity — một activity được export ra ngoài, nghĩa là bất kỳ ứng dụng nào cũng có thể khởi chạy nó. Activity này xử lý việc mở file cài đặt và deeplink, nhưng lại cho phép truyền các intent extras như settings_version, silent_import, replace, export_type_list_key.

Đáng lẽ những extras này chỉ nên được truyền qua kênh nội bộ (AIDL service), nhưng vì MapActivity được export, bất kỳ ứng dụng nào cũng có thể đính kèm extras tùy ý. Android không cung cấp cơ chế nào để giới hạn extras mà bên gọi bên ngoài có thể thiết lập.

Khai thác lỗ hổng này, kẻ tấn công có thể:

• SilentImport — nhập cài đặt mà không hiện thông báo
• Replace — thay thế thay vì chỉ thêm cài đặt
• SettingsTypes — nhập mà không cần người dùng xác nhận

Hậu quả là kẻ tấn công có thể thay đổi URL tile của bản đồ thành máy chủ của mình, từ đó ghi lại chính xác tọa độ x, y của mọi tile mà nạn nhân đã tải. Thậm chí họ còn lấy được điểm xuất phát và điểm đến của mọi lộ trình người dùng thực hiện — tất cả diễn ra âm thầm, người dùng không hề hay biết cài đặt ứng dụng của mình đã bị thay đổi.

Chiếm đoạt tài khoản Wikipedia qua deeplink

Trường hợp thứ hai liên quan đến ứng dụng Wikipedia trên Android. Ứng dụng đăng ký hook cho deeplink wikipedia:// để mở nội dung trong app. Tuy nhiên, một lỗi logic trong bộ phân tích hostname cho phép tải các URL không phải của Wikipedia.

Cụ thể, code kiểm tra it.authority.orEmpty().endsWith(WikiSite.BASE_DOMAIN) — chỉ cần tên miền kết thúc bằng wikipedia.org là được chấp nhận. Điều này cho phép kẻ tấn công dùng tên miền như evil-wikipedia.org để đánh lừa người dùng và thực thi JavaScript tùy ý trong WebView của ứng dụng.

Lỗ hổng bảo mật trong ứng dụng di động

Đáng chú ý, lỗi tương tự còn xuất hiện lần thứ hai trong file SharedPreferenceCookieManager.kt. Khi kết hợp cả hai lỗi, kẻ tấn công có thể đánh cắp toàn bộ cookie của Wikipedia — bao gồm username, token dài hạn và session token có hiệu lực trên mọi dự án Wikimedia (tất cả các phiên bản Wikipedia, Commons, Wikidata, Meta...).

Kịch bản tấn công diễn ra như sau:

1. Nạn nhân truy cập trang web độc hại chứa deeplink và nhấp vào
2. Ứng dụng Wikipedia tự động mở và tải trang do kẻ tấn công kiểm soát (ví dụ evil-wikipedia.org)
3. Nạn nhân tưởng đang ở trang Wikipedia, ứng dụng tự động gửi cookie của người dùng
4. Kẻ tấn công chiếm được quyền truy cập tài khoản trên toàn bộ hệ sinh thái Wikimedia

Hạn chế của LLM trong đánh giá mức độ nghiêm trọng

Dù rất giỏi phát hiện lỗ hổng, LLM lại yếu trong việc ước lượng mức độ nghiêm trọng. Nhóm nghiên cứu ghi nhận nhiều vấn đề:

• AI thường báo cáo các vấn đề đòi hỏi trạng thái cực kỳ cụ thể, gần như không thể xảy ra trong thực tế
• AI liên tục báo lỗ hổng mức thấp dù đã được yêu cầu rõ ràng là không làm vậy
• Mức độ nghiêm trọng thường bị đánh giá sai do bỏ qua các yếu tố giảm nhẹ

Mỗi phát hiện đều cần được một nhà nghiên cứu bảo mật có kiến thức về ứng dụng di động xem xét lại.

Ví dụ điển hình: một lỗi path traversal bị giới hạn trong bộ nhớ ngoài có mức độ nghiêm trọng thấp. Hoặc trường hợp ứng dụng dùng dữ liệu từ cả bộ nhớ trong lẫn bộ nhớ ngoài — dữ liệu bộ nhớ trong thường được ưu tiên, nên dù ta ghi được vào bộ nhớ ngoài qua path traversal thì cũng không thay đổi được dữ liệu thực tế của ứng dụng. LLM khó nhận ra những hành vi phức tạp này nếu không được yêu cầu tạo proof of concept cụ thể.

Điểm mạnh: hiểu biết sâu về hành vi API

Trái ngược với hạn chế trên, nhóm nghiên cứu bất ngờ trước khả năng hiểu hành vi của các API bảo mật phổ biến ở nhiều ngôn ngữ khác nhau của LLM — ngay cả khi không có quyền truy cập mã nguồn của ngôn ngữ đó.

Ví dụ, dùng path.Clean trong Go kém an toàn hơn nhiều so với filepath.Clean và thường là nguyên nhân của nhiều lỗ hổng ảnh hưởng đến phiên bản Windows của các sản phẩm phổ biến. Hầu hết proof of concept mà LLM tạo ra sau khi được cung cấp báo cáo lỗ hổng đều chỉ cần rất ít chỉnh sửa từ phía nhà nghiên cứu.

Kết luận

Tính đến thời điểm viết bài, nhóm GitHub Security Lab đã tìm ra 24 lỗ hổng Android trong các ứng dụng di động. Phần lớn là các lỗi đơn giản như path traversal, nhưng cũng có một số lỗ hổng nghiêm trọng như đã trình bày.

Vì bảo mật ứng dụng Android khá vững chắc, các lỗ hổng thường tập trung đúng vào những nơi nhà nghiên cứu bảo mật dự đoán — như cross app scripting trong WebView hay JavaScript bridge bị lộ.

Kết quả nghiên cứu bảo mật với AI

Nhóm tin rằng nghiên cứu bảo mật bằng AI là một trong những cách tốt nhất để bảo vệ các dự án mã nguồn mở hiện nay, có thể áp dụng cho ứng dụng web, di động lẫn desktop. Trong những năm tới, AI sẽ trở thành công cụ thiết yếu cho mọi maintainer — cả trong phát triển lẫn bảo mật.

Với các nhà phát triển Việt Nam đang duy trì dự án mã nguồn mở hoặc xây dựng ứng dụng di động, đây là thời điểm phù hợp để thử nghiệm công cụ này và đưa bảo mật AI hỗ trợ vào quy trình phát triển của mình.