MÌNH ĐÃ CÓ THỂ TRUY CẬP ĐƯỢC THÔNG TIN SINH VIÊN TOÀN TRƯỜNG NHƯ THẾ NÀO

MÌNH ĐÃ CÓ THỂ TRUY CẬP ĐƯỢC THÔNG TIN SINH VIÊN TOÀN TRƯỜNG NHƯ THẾ NÀO

Tags
Hacking
Tech
Security
Published
February 13, 2025
Author
Bài viết được copy từ J2Team Community: https://www.facebook.com/groups/j2team.community/posts/2599032533762184/
1. Mở đầu
Chào các bạn, mình là một sinh viên ngành CNTT. Ngay từ năm nhất, mình (và các bạn của mình) đã gặp nhiều cuộc gọi và email lừa đảo. Bằng một cách nào đó, chúng có được thông tin về họ tên, số CCCD, thậm chí là cả mã lớp sinh viên. Các thông điệp này thường mạo danh cơ quan pháp luật hoặc thậm chí là nhà trường, yêu cầu thanh toán học phí, thu phí thi lại, ... Điều này đã khiến mình thắc mắc: Tại sao thông tin cá nhân lại dễ dàng rò rỉ ra ngoài?
2. Phân tích lỗ hổng
2.1. Bắt đầu từ trang quản lý sinh viên
Mình bắt đầu từ trang Quản lý thông tin sinh viên (######[.]#########[.]edu[.]vn). Sử dụng công cụ DevTools trên trình duyệt, mình ghi lại các gói tin (packet) được gửi đi và phản hồi từ server. Qua đó, mình phát hiện hệ thống gửi các request GET tới địa chỉ #########[.]#########[.]edu[.]vn với các đường dẫn (path) và truy vấn (query) thay đổi tùy theo nội dung cần truy cập (ví dụ: Thông tin cá nhân, Lịch học, Kết quả học tập).
2.2. Phân tích các header trong request
Trong mỗi request, có ba trường header quan trọng mà mình để ý (Hình 1):
clientid: với giá trị mặc định là ###.
  • clientid: với giá trị mặc định là ###.
apikey: một chuỗi khóa xác thực.
  • apikey: một chuỗi khóa xác thực.
authorization: chứa JWT (JSON Web Token), được dùng để xác thực và ủy quyền truy cập dữ liệu.
  • authorization: chứa JWT (JSON Web Token), được dùng để xác thực và ủy quyền truy cập dữ liệu.
notion image
2.3. Phân tích JWT
Sử dụng các công cụ giải mã (Decode) trực tuyến, mình nhận thấy hệ thống sử dụng JWT với thuật toán HS256 (Hình 2). Cụ thể:
notion image
  • Header (Phần đầu): Thông tin về thuật toán mã hóa và kiểu token.
  • Payload (Nội dung): Bao gồm dữ liệu như:
id: Mã sinh viên
  • id: Mã sinh viên
name: Tên sinh viên
  • name: Tên sinh viên
role: Vai trò (ví dụ: sinh viên, cán bộ, giảng viên)
  • role: Vai trò (ví dụ: sinh viên, cán bộ, giảng viên)
nbf (Not Before): Thời gian bắt đầu có hiệu lực của token
  • nbf (Not Before): Thời gian bắt đầu có hiệu lực của token
iat (Issued At): Thời điểm token được phát hành
  • iat (Issued At): Thời điểm token được phát hành
exp (Expiration Time): Thời điểm token hết hạn
  • exp (Expiration Time): Thời điểm token hết hạn
iss (Issuer): Người phát hành token
  • iss (Issuer): Người phát hành token
aud (Audience): Đối tượng nhận token
  • aud (Audience): Đối tượng nhận token
  • Signature (Chữ ký): Phần này được tạo ra bằng cách kết hợp header và payload với một secret key dùng thuật toán HS256.
Dù header và payload có thể dễ dàng giải mã từ định dạng Base64, nhưng chữ ký sẽ chỉ hợp lệ nếu dùng đúng secret key.
3. Phân tích secret key và thử nghiệm tấn công
Như mọi hệ thống bảo mật khác, secret key là "linh hồn" bảo vệ tính toàn vẹn của JWT. Thông thường, secret key được lưu giữ cẩn thận, chỉ sử dụng nội bộ và không tiết lộ ra bên ngoài. Nếu secret key yếu hoặc có thể đoán được, kẻ tấn công có thể tạo ra các JWT giả mạo cho các tài khoản khác nhau.
Bước 1: Mình sử dụng công cụ HashCat kết hợp với bộ từ điển mặc định để thực hiện brute-force nhằm dò tìm secret key.
  • Bước 1: Mình sử dụng công cụ HashCat kết hợp với bộ từ điển mặc định để thực hiện brute-force nhằm dò tìm secret key.
Bước 2: Mặc dù ban đầu nghĩ đây chỉ là "trò chơi" nhỏ, nhưng chỉ sau khoảng 7 phút, HashCat đã tìm ra được secret key. (Hình 3)
notion image
  • Bước 2: Mặc dù ban đầu nghĩ đây chỉ là "trò chơi" nhỏ, nhưng chỉ sau khoảng 7 phút, HashCat đã tìm ra được secret key. (Hình 3)
Bước 3: Với secret key có được, mình thử tạo ra một số JWT giả mạo cho các mã sinh viên khác nhau và gửi các yêu cầu tới server. Kết quả trả về là các response hợp lệ, chứng tỏ lỗ hổng bảo mật thực sự tồn tại. (Hình 4)
notion image
  • Bước 3: Với secret key có được, mình thử tạo ra một số JWT giả mạo cho các mã sinh viên khác nhau và gửi các yêu cầu tới server. Kết quả trả về là các response hợp lệ, chứng tỏ lỗ hổng bảo mật thực sự tồn tại. (Hình 4)
4. Kết luận
Một lần nữa, mình xin được nhấn mạnh rằng, bài viết của mình chỉ mang mục đích chia sẻ thông tin, giúp các bạn nâng cao nhận thức và đề phòng cảnh giác trước những tin nhắn hay email lừa đảo. Hãy tỉnh táo, xác thực chính xác thông tin trước khi cung cấp thông tin cá nhân hoặc thực hiện giao dịch chuyển tiền. Nội dung chia sẻ trên đây chỉ mang tính chất học thuật và nhằm mục đích nâng cao nhận thức bảo mật. Mọi hành vi sử dụng thông tin cho mục đích xấu đều là hành vi vi phạm pháp luật và sẽ không được khuyến khích.
Mình xin được nhận ý kiến đóng góp của mọi người.