Cisco ISE zero-day CVE-2026-76460: CVSS 10 và cánh cổng của cả mạng

Sáng thứ Hai, bạn vào công ty, cắm laptop vào cổng mạng như mọi ngày. Switch hỏi ISE: "máy này là ai, có được vào VLAN nhân viên không?". ISE gật đầu, bạn vào mạng. Điện thoại bắt Wi-Fi doanh nghiệp cũng qua đúng cái gật đầu đó. Quản trị viên mạng đăng nhập vào hệ thống bằng tài khoản TACACS+ cũng nhờ nó.

Giờ thử nghĩ ngược lại: nếu có người bấm vào được trang quản trị của chính con ISE đó mà không cần đăng nhập, thì chuyện gì xảy ra? Họ không cần phá từng cái switch. Họ ngồi vào chỗ của người phát thẻ ra vào.

Đó là lý do CVE-2026-76460 làm giới vận hành mạng giật mình hồi giữa tháng 9. Bài này mình đọc lại advisory gốc, ghi rõ chỗ nào Cisco đã xác nhận, chỗ nào chỉ là suy đoán của người ngoài, vì cơ chế kỹ thuật của lỗi này công khai đến đâu thì mình cũng chỉ nói được đến đó.

# dòng thời gian

Các mốc dưới đây lấy từ advisory của Cisco PSIRT (cisco-sa-ISE-ABP-VNSW7Tn5) và bản ghi NVD, không phải từ bài tổng hợp.

Hai điểm đáng chú ý. Một là CVE này là zero-day đúng nghĩa: khi Cisco công bố thì kẻ tấn công đã dùng rồi. Hai là khoảng cách từ ngày công bố tới lúc có công cụ quét công khai (khoảng 5 tuần) là quãng mà ai chưa vá chỉ còn biết cầu may. CrowdSec bắt đầu gắn thẻ tín hiệu từ 28/10 chứ chưa chắc đó là lúc các cuộc quét mới bắt đầu. Con số 311 IP của CrowdSec là số IP bị gắn thẻ quét/khai thác trên mạng cảm biến của họ, CrowdSec nói rõ họ không biết lượt nào thành công, nên đừng đọc nó thành "311 tổ chức bị hack".

# ISE là gì mà đáng giá vậy

Cisco Identity Services Engine là sản phẩm NAC (network access control). Nó là chỗ tập trung chính sách "ai, bằng thiết bị nào, ở đâu, được vào mạng ra sao":

• Switch và access point hỏi ISE qua RADIUS (802.1X, MAB) để quyết định cho thiết bị vào, gán VLAN hay SGT (Security Group Tag) nào.
• Thiết bị mạng (router, switch, firewall) hỏi ISE qua TACACS+ xem admin nào được gõ lệnh nào.
• ISE nối với Active Directory, LDAP, hệ thống MDM, nên nó nắm danh tính và trạng thái thiết bị của cả tổ chức.
• Nó cũng làm captive portal cho khách, posture check, phân tách mạng theo chính sách.

Vì thế một con ISE bị chiếm khác nào cướp được phòng bảo vệ của toà nhà. Kẻ tấn công không cần lẻn qua cửa nào, họ tự in thẻ. Cụ thể, nếu có quyền quản trị ISE thì về lý thuyết có thể: sửa chính sách để thiết bị của mình vào thẳng VLAN nội bộ, tắt xác thực cho một dải nào đó, tạo tài khoản admin mạng trong kho TACACS+, đọc cấu hình chứa thông tin kết nối AD/LDAP, hoặc dùng ISE làm điểm đặt chân để đi ngang sang các hệ thống khác. Danh sách này là suy luận từ chức năng của sản phẩm, chứ Cisco không nói kẻ tấn công đã làm những gì.

Cisco chỉ nói rõ một điều: khai thác thành công có thể dẫn tới thực thi lệnh với quyền root trên node ISE, và kẻ tấn công có thể dùng quyền đó để xoá dấu vết. Chừng đó đã đủ nặng. Root trên một appliance đứng giữa mọi quyết định truy cập mạng thì coi như mạng đó hết còn là thứ bạn tin được.

Điểm khác với nhiều lỗ hổng "critical" thường gặp: ISE là appliance, không phải server bạn tự cài rồi quản lý như Linux thường. Bạn không có EDR chạy trên đó, không có công cụ tự kiểm tra tính toàn vẹn. Phía vận hành thường chỉ có log của chính nó, mà log thì kẻ có root xoá được.

# cơ chế: cái gì đã biết, cái gì chưa

Phần này mình phải nói thẳng: root cause ở mức code chưa được công bố. Bản vá của Cisco đóng kín, không có commit công khai để mổ. Những gì chắc chắn từ advisory:

• Lỗi nằm ở "insufficient authentication control on an API endpoint", nghĩa là một API endpoint kiểm soát xác thực chưa đủ.
• Kẻ tấn công không cần xác thực, từ xa, độ phức tạp thấp, không cần người dùng bấm gì (vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). S:C (scope changed) nghĩa là tác động vượt khỏi thành phần bị lỗi, hợp lý với một thiết bị kiểm soát truy cập.
• Một request được dựng riêng có thể bypass giao diện quản trị web.
• CWE được gán là CWE-648: Incorrect Use of Privileged APIs.
• Lỗi ảnh hưởng ISE và ISE-PIC bất kể cấu hình.

Tên endpoint, định dạng request và đường đi từ bypass tới root thì không có trong advisory. CrowdSec cũng viết rõ là họ không tìm được nguồn công khai nào cho bước từ bypass lên root.

Có một manh mối. Hướng dẫn phát hiện của Cisco trỏ vào file log ise-kong/access.log (đường dẫn trong support bundle là ise/logs/apigateway/access.log). Kong là API gateway mã nguồn mở, và theo cách đặt tên log thì request tới API quản trị của ISE đi qua một gateway kiểu này. Bạn nên coi đây là suy luận từ tên log, vì Cisco không viết "lỗi nằm trong Kong".

Ngoài ra, CrowdSec đọc template Nuclei công khai và cho rằng lỗi giống như thế này: gateway chấp nhận một session cookie chưa từng được cấp và trả về dữ liệu phiên đang hoạt động. Đó là cách họ diễn giải template quét, Cisco không xác nhận. Mình trích để bạn có hình dung, đừng coi là cơ chế chính thức.

Để hiểu loại lỗi này trông thế nào, đây là đoạn minh hoạ đơn giản hoá, không phải code của Cisco, thể hiện đúng kiểu sai: kiểm tra "có session" thay vì kiểm tra "session có hợp lệ".

// Minh hoạ: KHÔNG phải code gốc của Cisco ISE, chỉ mô tả kiểu lỗi
boolean isAuthenticated(HttpRequest req) {
    String sid = req.cookie("SESSION");
    // Sai: chỉ kiểm tra cookie có tồn tại, không tra ngược về kho session
    return sid != null && !sid.isBlank();
}
 
boolean isAuthenticatedFixed(HttpRequest req) {
    String sid = req.cookie("SESSION");
    if (sid == null) return false;
    Session s = sessionStore.find(sid);          // phải do server cấp
    return s != null && !s.isExpired() && s.isBoundTo(req.clientContext());
}

Lỗi dạng này nguy hiểm vì nó rất dễ viết ra. Một endpoint nội bộ ban đầu chỉ dành cho thành phần khác trong cùng máy gọi, nên người viết nghĩ "gateway đã lo xác thực rồi". Về sau endpoint được lộ ra qua đường khác, hoặc gateway và backend hiểu "đã xác thực" theo hai kiểu khác nhau. CWE-648 gói đúng tình huống đó: một API đặc quyền bị gọi mà không ai kiểm tra người gọi có tư cách hay không.

Sơ đồ dưới đây ghi lại luồng theo đúng phần đã xác nhận (nét liền) và phần chưa rõ (khung cam):

Hai khung cam là phần mình suy luận hoặc chưa biết, không phải kết luận của Cisco.

# ai bị ảnh hưởng, bản nào đã vá

Theo advisory: Cisco ISE và ISE-PIC, mọi cấu hình, không có điều kiện nào để "tránh được". Danh sách bản vá đầu tiên:

Có chi tiết nhỏ mà mình thấy đáng nói: một bài của Help Net Security cho biết Cisco khuyên nên chuyển lên 3.3 Patch 12, 3.4 Patch 7 hoặc 3.5 Patch 4, vì nhánh 3.1 và 3.2 chỉ còn nhận bản sửa lỗi nghiêm trọng. Mình chỉ thấy chi tiết này ở một nguồn thứ cấp nên bạn hãy tự đối chiếu với lịch vòng đời (EoL) trên trang Cisco. Nếu bạn đang ở 3.0 thì không có "bản vá nhanh" nào, mà phải lên hẳn nhánh khác, tức là một đợt nâng cấp thật sự, có kiểm thử chính sách.

Mình cũng thấy vài bài ghi "3.0 đến 3.5" và vài bài ghi "3.1.0 đến 3.5.0". Bảng bản vá của Cisco thì rõ ràng, nên lấy bảng đó làm chuẩn.

# kiểm tra mình có dính không

Các lệnh dưới đây chỉ đọc, chạy trong CLI của ISE (SSH vào từng node). Tên lệnh bạn kiểm tra lại theo phiên bản của mình.

Xem phiên bản và patch đang cài:

show version
show application version ise

So kết quả với bảng ở trên. Với deployment nhiều node (PAN, MnT, PSN), phải làm từng node, vì bản vá cài theo node và thứ tự nâng cấp có quy định riêng của Cisco.

Rà log theo hướng dẫn của advisory:

show logging application ise-kong/access.log | include dummyuser

Theo Cisco, bất kỳ dòng nào khớp với username đáng ngờ như thế đều có thể là dấu hiệu hoạt động độc hại. Đây là ví dụ Cisco đưa ra, kẻ tấn công khác có thể dùng tên khác, nên đừng coi "không thấy dummyuser" là sạch. Cũng cần chạy trên mọi node.

Muốn xem log cũ hơn thì tạo support bundle (chọn "include debug logs" và mã hoá bằng shared key). Log nằm ở ./ise/logs/apigateway/access.log.<số>.gz trong bundle.

Một chi tiết quan trọng: nếu kẻ tấn công đã có root thì chúng xoá được log cục bộ. Vì vậy Cisco khuyên đối chiếu thêm log mạng và firewall để tìm các lượt upload bất thường ra IP bên ngoài, hoặc download từ IP độc hại. Đó là lý do mình nghĩ bạn nên đẩy log của ISE sang chỗ khác (syslog/SIEM) từ trước khi có sự cố, chứ không phải sau.

# vá, giảm thiểu, và khi nghi bị xâm nhập

Vá: lên bản có Patch như bảng trên. Đây là biện pháp duy nhất giải quyết tận gốc. Cisco nói rõ là không có workaround.

Giảm thiểu tạm thời: advisory chỉ nêu một cách là dùng infrastructure ACL (iACL) để chỉ cho phép lưu lượng quản lý và control plane cần thiết tới thiết bị. Nói đơn giản là giao diện quản trị của ISE không nên mở từ chỗ nào cũng với tới được. Biện pháp này thu hẹp ai gọi được endpoint, nó không sửa lỗi. Với kẻ đã nằm sẵn trong mạng quản lý hoặc VPN của bạn thì ACL không cản được.

Nếu nghi bị xâm nhập: Cisco khuyến nghị mạnh việc re-image node bị ảnh hưởng và khôi phục từ bản backup cấu hình nếu cần. Nghe nặng, nhưng hợp lý: khi đã có root trên appliance thì bạn không thể chứng minh nó sạch bằng cách xoá vài file. Chọn backup cũng cần cẩn thận, backup lấy sau thời điểm bị xâm nhập có thể mang theo chính sách đã bị sửa.

Một việc dễ bị bỏ sót (đây là suy luận của mình, không phải kết luận của nguồn nào): sau khi vá hoặc re-image, hãy nghĩ tới việc xoay credential mà ISE đang giữ, như tài khoản service nối AD/LDAP, shared secret RADIUS/TACACS+ với thiết bị mạng, chứng chỉ. Nếu node từng bị root thì những thứ này coi như đã lộ.

# bài học cho người vận hành

Giao diện quản trị là bề mặt tấn công, đừng để nó "ở đó cho tiện". Lỗi này là lỗi phía API quản trị. Nếu cổng đó chỉ mở cho một subnet quản lý nhỏ, qua jump host, thì dù lỗi vẫn tồn tại, số kẻ gọi được giảm hẳn. Cisco gợi ý iACL không phải ngẫu nhiên.

Hệ thống kiểm soát truy cập phải được vá như hệ thống quan trọng nhất của mạng. ISE, firewall, VPN gateway, IdP: nếu bị chiếm thì tác động lên mọi thứ phía sau. CISA đặt hạn 3 ngày (16 đến 19/09) cho cơ quan liên bang Mỹ, và mình thấy con số đó có lý do. Cái khó ở ISE là nâng cấp thật sự đau: cluster nhiều node, chính sách phức tạp, ngại làm vì sợ mất mạng cả toà nhà. Trade-off ở đây khá rõ: cửa sổ bảo trì có kế hoạch với rủi ro có kiểm soát, hay để hở một lỗ CVSS 10 đang bị quét. Với lỗi đang bị khai thác thì mình nghiêng hẳn về vá trước.

Đừng tin log nằm trên chính máy bị nghi. Cisco tự nói root có thể che dấu vết. Log nên đẩy ra ngoài ngay khi sinh ra.

Bản đã hết hạn bảo trì là nợ bảo mật. ISE 3.0 là ví dụ: khi lỗi tới thì không còn bản vá để áp, chỉ còn đường duy nhất là nâng cấp lớn, và bạn phải làm trong lúc đang bị quét. Kế hoạch nâng cấp tốt nên có từ trước.

Dành cho dev đang viết API, lỗi dạng CWE-648 nhắc một điều cũ mà vẫn hay quên: kiểm tra xác thực phải nằm ở mỗi endpoint đặc quyền, hoặc ở một lớp mà không thể đi vòng. Đừng dựa vào ngầm định "request này chắc đã qua gateway". Và khi kiểm tra session thì hỏi "do server nào cấp, còn hạn không, gắn với ai", đừng chỉ hỏi "có cookie không".

Cuối cùng là chuyện chưa rõ: đến lúc mình viết bài này (07/11/2026), nhà cung cấp chưa công bố kỹ thuật chi tiết, và theo CrowdSec cũng chưa có bằng chứng công khai về bước lên root. Nếu sau này có phân tích kỹ thuật từ hãng nghiên cứu độc lập, phần "cơ chế" ở trên có thể cần cập nhật. Cứ coi đoạn code minh hoạ là cách hiểu loại lỗi, đừng coi là cách lỗi này thực sự hoạt động.

Việc nên làm ngay: kiểm tra phiên bản từng node, lên patch, giới hạn nguồn truy cập cổng quản trị bằng iACL, rồi rà access.log trên mọi node. Nếu còn ở 3.0, đặt lịch nâng cấp ngay hôm nay.

Tài liệu tham khảo:

• Cisco Security Advisory: cisco-sa-ISE-ABP-VNSW7Tn5
• NVD: CVE-2026-76460
• CISA Known Exploited Vulnerabilities Catalog
• Help Net Security: Unauthenticated attackers are bypassing Cisco ISE's management interface
• CrowdSec: CVE-2026-76460, Cisco ISE auth bypass, 311 attacking IPs
• CWE-648: Incorrect Use of Privileged APIs

Chỉ là những ghi chép cá nhân với hy vọng mang lại chút giá trị. Nếu thấy hữu ích, đừng ngại chia sẻ cho bạn bè & đồng nghiệp nhé!

Happy coding 😎 👍🏻 🚀 🔥.