Blog / AI / Deep Article
Gemini bị phát hiện tấn công mạng và đoán mật khẩu người dùng
Đọc tiêu đề lần đầu, phản xạ của tôi là bật cười. Một mô hình ngôn ngữ đi đoán mật khẩu người dùng nghe như kịch bản phim hạng B. Nhưng VnExpress đưa tin Gemini đã tấn công mạng và đoán mật khẩu người dùng (https://vnexpress.net/gemini-tan-cong-mang-doan-mat-khau-nguoi-dung-5122237.html). The Hacker News bổ sung chi tiết mấu chốt: Google Gemini đã xâm nhập vào hệ thống thật của một công ty thật, sau khi nhầm lẫn domain trong một bài kiểm tra bảo mật (https://thehackernews.com/2026/09/google-gemini-broke-into-real-company.html).
Đấy. Không có hacker gõ phím trong bóng tối. Không có nhóm APT nào từ nước ngoài. Chỉ có một lỗi cấu hình domain, và một AI agent làm đúng những gì nó được yêu cầu làm.
Vấn đề là: đây không phải câu chuyện về việc AI "nổi loạn" như báo lá cải thích mô tả. Đây là câu chuyện về việc con người cấu hình sai, còn AI thì không đủ khả năng — hoặc không được trao quyền — để nhận ra điều đó. Và đó mới là phần đáng sợ.
Theo The Hacker News, sự việc bắt nguồn từ một bài kiểm tra bảo mật mà Google chạy cho Gemini (https://thehackernews.com/2026/09/google-gemini-broke-into-real-company.html). Bài test này lẽ ra phải nhắm vào một domain thuộc sở hữu của Google, hoặc một môi trường sandbox nào đó do Google kiểm soát. Nhưng domain bị nhầm. Kết quả: Gemini chĩa vào hệ thống thật của một công ty thật.
Nếu bạn từng làm red team, bạn biết đây là tai nạn kinh điển. Scope creep. Danh sách mục tiêu không được cập nhật. Một dòng cấu hình sai trong file YAML. Ngày trước, hậu quả của lỗi này là một pentester gõ cửa nhầm máy chủ, xin lỗi, rồi rút lui. Ngày nay, hậu quả là một agent tự trị chạy hàng nghìn lệnh trước khi có người kịp bấm nút dừng.
Điều đáng nói là tốc độ. Một kỹ sư bảo mật của Google có thể mất vài phút để nhận ra "ơ, domain này lạ". Một AI agent thì không có khoảng nghỉ đó. Nó không do dự. Nó không tự hỏi "ủa, sao công ty này lại nằm trong scope nhỉ?". Nó chỉ thực thi.
Và đây là điểm tôi muốn nhấn mạnh: vấn đề không nằm ở Gemini. Vấn đề nằm ở giả định rằng AI agent sẽ tự biết dừng lại ở đúng ranh giới. Nó không biết. Nó chỉ biết những gì được viết trong prompt, trong system instruction, trong cấu hình tool. Nếu bạn viết sai một chữ, nó sẽ đi đúng hướng sai đó, với hiệu suất cao gấp trăm lần một con người.
Vậy ai chịu trách nhiệm khi cấu hình sai? Google, hay Gemini?
Trong hai tiêu đề, tôi thấy phần "đoán mật khẩu người dùng" bị chú ý ít hơn phần "xâm nhập hệ thống thật" (https://vnexpress.net/gemini-tan-cong-mang-doan-mat-khau-nguoi-dung-5122237.html). Nhưng với tôi, đây mới là chi tiết đáng mổ xẻ.
Đoán mật khẩu — hay còn gọi là credential brute-forcing — là kỹ thuật tấn công cơ bản nhất trong sách giáo khoa bảo mật. Nó tồn tại từ thời telnet. Điều mới ở đây là AI làm việc đó một cách có ngữ cảnh. Một script brute-force cổ điển sẽ thử "password123", "admin", "123456" rồi bỏ cuộc. Một LLM có thể đọc được tên nhân viên trên LinkedIn, đoán pattern đặt mật khẩu của công ty, thử các biến thể có ý nghĩa — rồi thử tiếp.
Thực tế là, khoảng cách giữa "brute-force cổ điển" và "brute-force có suy luận" không phải khoảng cách về tốc độ. Nó là khoảng cách về chất. Và hầu hết hệ thống phòng thủ hiện tại ở Việt Nam — và cả thế giới — được thiết kế cho kiểu tấn công cũ.
Các doanh nghiệp Việt Nam thường chặn brute-force bằng rate limiting: sau 5 lần sai thì khóa tài khoản 15 phút. Nghe ổn. Nhưng nếu kẻ tấn công là một agent có thể luân chuyển qua hàng nghìn tài khoản cùng lúc, mỗi tài khoản chỉ thử 2-3 lần, thì rate limiting theo tài khoản trở nên vô dụng. Bạn cần phát hiện ở tầng hành vi, ở tầng pattern phân tán. Rất ít hệ thống SIEM ở các công ty tầm trung Việt Nam làm được điều đó.
Câu hỏi thật sự là: nếu Gemini — một sản phẩm của chính Google, công ty vận hành hạ tầng bảo mật tốt nhất hành tinh — vẫn làm được chuyện này ngoài ý muốn, thì một agent do kẻ xấu cố tình huấn luyện sẽ làm được gì?
Nhiều người sẽ đọc tin này và kết luận "AI nguy hiểm". Tôi nghĩ kết luận đó lười biếng và sai hướng.
Đọc kỹ mô tả từ The Hacker News: Gemini không tự quyết định đi tấn công công ty kia. Nó được đặt vào một bài kiểm tra bảo mật, với một tập mục tiêu, và tập mục tiêu đó bị sai (https://thehackernews.com/2026/09/google-gemini-broke-into-real-company.html). Đây là lỗi kiến trúc hệ thống, không phải lỗi đạo đức của mô hình.
Nhưng kiến trúc hệ thống — đó lại là thứ thuộc về con người. Và kiến trúc agent hiện tại của toàn ngành đang có một lỗ hổng cấu trúc nghiêm trọng: agent được trao quyền hành động nhiều hơn quyền nhận thức về hậu quả.
Nói cách khác: agent có thể chạy 1.000 request HTTP, nhưng không có khả năng tự hỏi "1.000 request này có đang đánh vào một công ty thật không?". Agent có thể gọi tool scan port, nhưng không có cơ chế xác nhận độc lập rằng target nằm trong danh sách được phép. Mọi thứ dựa vào một dòng cấu hình. Một dòng.
Google là công ty có đội ngũ an ninh mạng hàng đầu — Project Zero, Threat Analysis Group, hàng nghìn kỹ sư bảo mật. Nếu lỗi cấu hình kiểu này lọt qua được ở đó, hình dung xem nó sẽ lọt qua thế nào ở một startup 20 người.
Và ở Việt Nam, số lượng startup đang nhúng LLM vào sản phẩm tăng theo cấp số nhân. Các đội 5-10 người, không có Security Engineer chuyên trách, đang cho agent quyền gọi API, đọc database, gửi email. Không ai trong số họ có hệ thống kiểm tra chéo domain target như Google. Nghĩa là gì? Nghĩa là tỉ lệ lỗi của họ cao hơn, và biên độ thiệt hại cũng có thể cao hơn.
Một khía cạnh nữa mà tôi thấy ít được nói tới: vụ này cho thấy ranh giới giữa "môi trường test" và "môi trường thật" đang bị xóa nhòa một cách nguy hiểm.
Ngày trước, test là test. Bạn dựng một con VM, cắt mạng, chạy thử, xong. Nếu có lỗi, thiệt hại bằng không. An toàn tuyệt đối.
Với AI agent, mô hình bảo mật đó sụp đổ. Vì agent không chỉ "chạy trong môi trường test" — nó tương tác với thế giới bên ngoài. Nó gọi API thật nếu URL trỏ ra ngoài. Nó gửi request thật nếu DNS resolve được. Nó có thể tải dữ liệu thật nếu endpoint trả về dữ liệu thật. Bạn không thể "cắt mạng" một agent mà vẫn mong nó hoạt động đúng như trong production.
Đây là nghịch lý cơ bản của việc test AI agent: để test đúng, bạn phải cho nó tiếp xúc với môi trường giống thật. Nhưng môi trường giống thật thì có hậu quả thật. Domain mix-up trong vụ Gemini là minh chứng sống cho nghịch lý này (https://thehackernews.com/2026/09/google-gemini-broke-into-real-company.html).
Các kỹ sư Việt Nam làm về AI agent — đặc biệt trong fintech, nơi agent có thể chạm vào giao dịch tiền thật — nên đọc kỹ vụ này. Nếu bạn đang test một agent có quyền gọi API chuyển khoản, câu hỏi không phải là "agent có thông minh không". Câu hỏi là "nếu cấu hình sai một dòng, ai chặn nó lại?"
Và câu trả lời thường là: không ai cả. Vì mọi người đều tin vào cấu hình đúng.
Sự việc này, cùng với The Hacker News đưa tin (https://thehackernews.com/2026/09/google-gemini-broke-into-real-company.html), đặt ra một loạt câu hỏi mà playbook bảo mật hiện tại không có câu trả lời.
Thứ nhất, domain allowlist theo kiểu truyền thống không đủ. Bạn cần một cơ chế xác nhận độc lập, không nằm trong prompt, không nằm trong cấu hình mà agent có thể đọc. Một "circuit breaker" ở tầng hạ tầng, chặn mọi request ra khỏi danh sách IP/domain đã được phê duyệt bằng chữ ký số của con người, không phải bằng biến môi trường.
Thứ hai, logging cho agent cần khác logging cho ứng dụng thường. Bạn cần biết không chỉ "nó gọi API gì", mà "nó lý luận thế nào để quyết định gọi API đó". Nếu không có chuỗi lý luận đó, điều tra sự cố sau này gần như bất khả thi.
Thứ ba, và quan trọng nhất: cần một định nghĩa pháp lý về trách nhiệm. Nếu agent của Google xâm nhập hệ thống công ty X, ai chịu trách nhiệm theo luật? Google? Người viết cấu hình? Người phê duyệt bài test? Hiện tại, không có khung pháp lý nào ở Việt Nam — hay ở hầu hết quốc gia — trả lời rõ câu này.
Ở Việt Nam, Luật An ninh mạng và Nghị định 13 về bảo vệ dữ liệu cá nhân đều chưa có điều khoản nào nói về "hành vi do AI agent tự trị gây ra". Các doanh nghiệp đang dùng agent để xử lý dữ liệu khách hàng — ngân hàng, ví điện tử, sàn thương mại điện tử — đang hoạt động trong một vùng xám pháp lý. Họ không biết mình có trách nhiệm gì nếu agent gây thiệt hại cho bên thứ ba.
Không có câu trả lời rõ ràng. Và đó chính là vấn đề.
Điều tôi quan tâm nhất lúc này không phải là vụ việc cụ thể. Mà là cách Google xử lý sau đó.
Nếu Google công bố chi tiết kỹ thuật về lỗi domain mix-up, về cơ chế ngăn chặn mà họ sẽ thêm vào, thì đó là tiền lệ tốt cho cả ngành. OpenAI, Anthropic, Microsoft — tất cả đều đang chạy các bài test tương tự với agent của họ. Họ sẽ phải học từ vụ này, dù muốn hay không.
Nếu Google im lặng, hoặc chỉ đưa ra một tuyên bố chung chung kiểu "chúng tôi coi trọng bảo mật", thì đó là tín hiệu xấu. Nó có nghĩa là ngành AI vẫn chưa sẵn sàng đối diện với sự thật rằng agent tự trị tạo ra loại rủi ro mới mà mô hình phát triển hiện tại chưa được thiết kế để xử lý.
Và đây là điều các đội sản phẩm ở Việt Nam nên chú ý: nếu Google — với hàng nghìn kỹ sư bảo mật và quy trình red team nghiêm ngặt nhất — vẫn để lọt lỗi này, thì đừng tin vào quy trình của bạn. Đừng tin vào checklist. Đừng tin vào "chúng tôi đã test kỹ rồi".
Hãy xây dựng hệ thống giả định rằng cấu hình sẽ sai. Giả định rằng domain sẽ bị nhầm. Giả định rằng agent sẽ đi quá xa. Và xây dựng lớp chặn ở tầng hạ tầng, không phải ở tầng prompt.
Vì prompt có thể sai. Hạ tầng thì phải cứng.
Câu hỏi cuối cùng, và có lẽ là câu hỏi đáng giá nhất sau vụ này: nếu bạn là một lập trình viên Việt Nam đang xây agent có quyền truy cập hệ thống nội bộ của công ty mình, bao nhiêu phần trăm tự tin bạn dành cho cấu hình allowlist hiện tại của bạn? Nếu câu trả lời là "khoảng 90%", thì 10% còn lại đang chờ một dòng YAML sai để biến thành sự cố thật.