Phơi bày lỗ hổng nghiêm trọng trong cổng chấm điểm trực tuyến của CBSE: Từ bỏ qua xác thực đến chiếm đoạt tài khoản

Một nhà nghiên cứu bảo mật vừa công bố chi tiết về chuỗi lỗ hổng bảo mật nghiêm trọng ảnh hưởng đến hệ thống Chấm điểm Trực tuyến (On-Screen Marking - OSM) của Hội đồng Giáo dục Trung ương Trung học (CBSE) - một trong những cơ quan giáo dục lớn nhất tại Ấn Độ. Những sai sót trong thiết kế và triển khai hệ thống này không chỉ cho phép bỏ qua quy trình xác thực hai lớp mà còn dẫn đến việc chiếm đoạt hoàn toàn tài khoản của người dùng, đe dọa trực tiếp đến tính toàn vẹn của các kỳ thi quốc gia.

Hệ thống chấm điểm trực tuyến

Bối cảnh: Hệ thống OSM của CBSE

CBSE chịu trách nhiệm tổ chức các kỳ thi lớp 10 và lớp 12 cho hàng triệu học sinh mỗi năm. Hiện nay, hội đồng này đã chuyển sang sử dụng hệ thống OSM để các giám thị có thể chấm điểm trực tuyến các bài thi đã được số hóa. Do tính chất quan trọng và quy mô lớn, việc bảo mật nền tảng này là tối quan trọng. Tuy nhiên, quá trình kiểm tra đã hé lộ những lỗ hổng bảo mật cơ bản khiến hệ thống trở nên "mở cửa" với bất kỳ ai có kiến thức kỹ thuật sơ đẳng.

Lỗ hổng số 1: Mật khẩu chủ được mã hóa cứng (Hardcoded Master Password)

Lỗ hổng đầu tiên và dễ thấy nhất nằm ngay trong mã nguồn phía máy khách (client-side). Cụ thể, tệp JavaScript đóng gói của ứng dụng (main bundle) được phục vụ công khai cho mọi người dùng đã chứa một chuỗi ký tự rõ ràng: mật khẩu chủ (master password).

Điều đáng sợ hơn là logic xử lý của hệ thống. Khi mật khẩu này được nhập vào form đăng nhập, ứng dụng sẽ tự động điền mã OTP và bỏ qua hoàn toàn quy trình xác thực thường nhật. Kẻ tấn công chỉ cần biết User ID và Mã trường (thông tin này có thể dễ dàng thu thập được) là có thể đăng nhập dưới tư cách của bất kỳ giám thị nào mà không cần bước xác thực thứ hai.

Lỗ hổng số 2: Xác thực OTP hoàn toàn ở phía Client

Quy trình xác thực hai yếu tố (2FA) sử dụng OTP tại hệ thống này thực chất chỉ là "hình thức". Khi gửi yêu cầu đăng nhập, máy chủ sẽ gửi lại mã OTP trong chính phản hồi xác thực (auth response). Sau đó, mã JavaScript chạy trên trình duyệt của người dùng sẽ thực hiện việc so sánh mã OTP vừa nhận với mã người dùng nhập vào ngay tại máy khách.

Điều này đồng nghĩa với việc bất kỳ ai giám sát qua tab Network (Mạng) đều có thể đọc trộp mã OTP. Hơn nữa, vì việc kiểm tra diễn ra ở phía máy khách, kẻ tấn công hoàn toàn có thể bypass (bỏ qua) bước này bằng cách sửa đổi mã hoặc gửi request giả mạo thông báo "kiểm tra thành công".

Lỗ hổng số 3: Thiếu bảo vệ tuyến đường (Route Guards)

Ngay cả khi bỏ qua quy trình đăng nhập, cấu hình định tuyến (routing) của ứng dụng Angular cũng không có bất kỳ lớp bảo vệ nào (canActivate guards). Các tuyến đường quan trọng như /dashboard, /evalscriptsview, hay /verificationdashboard đều có thể truy cập trực tiếp.

Bằng cách chèn một vài giá trị giả mạo vào localStorage và sessionStorage của trình duyệt, sau đó điều hướng trực tiếp đến các đường dẫn này, kẻ tấn công có thể tiếp cận bảng điều khiển mà không cần đăng nhập:

localStorage.setItem('jwtToken', 'dev-token-12345');
sessionStorage.setItem('role_id', '23');
// ... các thiết lập khác
window.location.href = '/cbseevalweb/#/dashboard';

Lỗ hổng số 4 & 5: Bỏ qua xác thực khi đổi mật khẩu và Lỗi IDOR hệ thống

Tình trạng trở nên nghiêm trọng hơn khi kết hợp hai lỗ hổng tiếp theo.

Tính năng "Đổi mật khẩu" yêu cầu người dùng nhập mật khẩu cũ. Tuy nhiên, khi phân tích yêu cầu HTTP (HTTP request) gửi đi, nhà nghiên cứu nhận thấy dữ liệu chỉ bao gồm ValuatorID và pin_NewPassword. Biến oldpassword tồn tại trong giao diện nhưng không bao giờ được gửi đi. Máy chủ chấp nhận bất kỳ yêu cầu đổi mật khẩu nào mà không kiểm tra xem người dùng có biết mật khẩu hiện tại hay không.

Điều này trở thành thảm họa khi kết hợp với lỗ hổng Insecure Direct Object Reference (IDOR). Hầu hết các API gọi hệ thống xác định danh sách người dùng dựa trên ValuatorID lấy trực tiếp từ sessionStorage (nơi người dùng có thể tự chỉnh sửa). Máy chủ tin hoàn toàn vào ID mà máy khách gửi thay vì xác thực từ phiên đăng nhập (session).

Mô phỏng việc kiểm tra mã nguồn

Hậu quả là kẻ tấn công có thể:

1. Chỉnh sửa ValuatorID trong bộ nhớ trình duyệt thành ID của nạn nhân.
2. Gọi API đổi mật khẩu với mật khẩu mới do attacker chọn.
3. Đăng nhập hợp pháp vào tài khoản nạn nhân, thay đổi điểm số và thông tin cá nhân.

Bài học về bảo mật phần mềm

Mọi lỗ hổng trên đều xuất phát từ một sai lầm nguyên thủy: đặt lòng tin vào phía máy khách (client-side trust).

Những bài học rút ra từ sự cố này bao gồm:

• Không bao giờ lưu trữ bí mật (mật khẩu, key, OTP) trong các tệp JavaScript gửi về trình duyệt.
• Mọi xác thực và ủy quyền phải được thực hiện nghiêm ngặt ở phía máy chủ (server-side).
• Không bao giờ lấy danh tính người dùng từ dữ liệu do client gửi lên (như sessionStorage); phải lấy từ phiên đã được xác thực.
• Các thao tác nhạy cảm như đổi mật khẩu bắt buộc phải xác minh quyền sở hữu hiện tại.

Mặc dù các lỗ hổng này đã được báo cáo cho CERT-In, nhưng tốc độ khắc phục chậm chạp cho thấy sự thiếu hụt nghiêm trọng trong năng lực quản trị rủi ro kỹ thuật số đối với các hệ thống then chốt. Đây là lời cảnh tỉnh mạnh mẽ cho các nhà phát triển phần mềm: An ninh mạng không thể dựa vào sự "lương thiện" của trình duyệt người dùng.