Bộ giới hạn xác thực dùng bucket toàn cục gây từ chối đăng nhập trên Pterodactyl Panel

Lưu ý: Dữ liệu này chỉ có tính chất tham khảo, phục vụ nghiên cứu an ninh mạng.CyStack khuyến nghị người dùng không sử dụng các thông tin này nhằm các mục đích bất hợp pháp

Lỗ hổng CVE-2026-61609 là gì?

Lỗ hổng CVE-2026-61609 là lỗ hổng Allocation of Resources Without Limits or Throttling ảnh hưởng tới panel (phiên bản bị ảnh hưởng: >= 1.7.0, < 1.13.0). Lỗ hổng này được xếp hạng ở mức Cao, với điểm CVSS 7.5. Lỗ hổng này đã có mã hoặc bằng chứng khai thác công khai, nhưng điều đó chưa xác nhận việc khai thác trong thực tế.

Giới thiệu chung

Dữ liệu gốc

Pterodactyl là một panel quản lý máy chủ game miễn phí và mã nguồn mở. Từ phiên bản 1.7.0 đến trước phiên bản 1.13.0, authentication rate limiter được định nghĩa trong RouteServiceProvider::configureRateLimiting() đã áp dụng một bucket toàn cục duy nhất cho các endpoint đăng nhập và checkpoint xác thực hai yếu tố thay vì dùng IP hoặc tài khoản làm khóa: Limit::perMinute(10) ở nhánh fall-through bao phủ POST /auth/login và POST /auth/login/checkpoint đã bỏ qua ->by(), vì vậy Laravel tạo ra một cache key cố định (md5('authentication')) được dùng chung cho mọi yêu cầu. Kẻ tấn công chưa xác thực gửi khoảng mười yêu cầu mỗi phút từ một IP duy nhất, thuận tiện nhất nhằm vào endpoint checkpoint (endpoint này không có reCAPTCHA), có thể làm cạn counter dùng chung và khiến HTTP 429 được trả về cho mọi người dùng đang cố đăng nhập hoặc hoàn tất xác thực hai yếu tố, tạo ra một tình trạng từ chối dịch vụ authentication trên toàn panel đồng thời khóa cả quản trị viên. Lỗi này được sửa trong phiên bản 1.13.0.

Sản phẩm và phạm vi ảnh hưởng

  • pterodactyl/panel: CNA advisory xác định các phiên bản >= 1.7.0, <= 1.12.4 bị ảnh hưởng.
  • Bản ghi CVE chuẩn hóa biểu diễn phạm vi bị ảnh hưởng là >= 1.7.0, < 1.13.0.
  • Phiên bản đã được vá: 1.13.0.
  • Endpoint forgot-password được advisory xác định là không bị ảnh hưởng vì limiter của endpoint này đã khóa theo IP. Không có bằng chứng riêng cho các nhánh phát hành song song khác.

Chi tiết kỹ thuật

Lỗi nằm trong bộ giới hạn tốc độ xác thực của RouteServiceProvider::configureRateLimiting(). Nhánh áp dụng cho POST /auth/login và POST /auth/login/checkpoint gọi Limit::perMinute(10) nhưng không gọi ->by(), nên Laravel tạo một cache key cố định từ tên limiter authentication thay vì tạo key theo IP hoặc tài khoản. Vì vậy, các yêu cầu từ mọi client cùng tăng một bộ đếm dùng chung; sau khi bộ đếm đạt giới hạn, middleware throttle trả về HTTP 429 cho các yêu cầu xác thực tiếp theo trong cửa sổ giới hạn. POST /auth/login/checkpoint không có reCAPTCHA, nên là endpoint thuận tiện để làm đầy bộ đếm; trên POST /auth/login, throttle được áp dụng trước middleware reCAPTCHA. Nhánh forgot-password sử dụng ->by($request->ip()) và được advisory xác định là không bị ảnh hưởng. Chi tiết triển khai của cơ chế lưu cache ngoài việc tạo key dùng chung không được mô tả thêm trong bằng chứng hiện có.

Khả năng khai thác

Lỗ hổng có thể bị khai thác qua mạng mà không cần xác thực, quyền hoặc tương tác của người dùng. Một địa chỉ IP có thể gửi khoảng mười yêu cầu mỗi phút tới endpoint checkpoint để làm đầy bucket dùng chung; advisory công khai mô tả một proof of concept cho hành vi này. Khi bucket bị cạn, người dùng hợp lệ từ các IP khác cũng có thể nhận HTTP 429 khi đăng nhập hoặc hoàn tất xác thực hai yếu tố. Việc lặp lại lưu lượng theo từng cửa sổ giới hạn có thể duy trì trạng thái khóa xác thực. Bằng chứng hiện có xác nhận public proof of concept, nhưng không xác lập việc lỗ hổng đã bị khai thác trong thực tế.

Tác động kỹ thuật

Lỗi cho phép một client chưa xác thực tác động đến trạng thái xác thực của các client khác vì mọi yêu cầu cùng tranh chấp một cache counter. Kết quả kỹ thuật là HTTP 429 trên login và endpoint checkpoint, tạo ra từ chối dịch vụ ở phạm vi toàn panel thay vì chỉ giới hạn một IP hoặc một tài khoản. Quản trị viên và người dùng thông thường đều có thể bị ảnh hưởng, trong khi endpoint forgot-password vẫn được giới hạn theo IP. Bằng chứng hiện có không cho thấy khả năng vượt quyền, truy cập trái phép vào dữ liệu hoặc sửa đổi tính toàn vẹn của panel.

Tác động đến tổ chức

  • Người dùng hợp lệ có thể không đăng nhập được hoặc không hoàn tất được bước xác thực hai yếu tố trong thời gian bị tấn công.
  • Quản trị viên bị khóa ngoài panel, làm chậm hoặc cản trở việc phản ứng sự cố và khôi phục dịch vụ.
  • Panel quản lý game server có thể vẫn đang chạy, nhưng kênh quản trị và đăng nhập trở nên không khả dụng đối với người dùng cần truy cập.
  • Lỗ hổng không được mô tả là cho phép đọc dữ liệu hoặc thay đổi cấu hình; tác động được xác nhận là denial of service đối với authentication.

Cách khắc phục

  1. Nâng cấp lên pterodactyl/panel 1.13.0, là phiên bản được CNA advisory xác định đã vá lỗi.
  2. Nếu chưa thể nâng cấp ngay, áp dụng thay đổi mã nguồn đã được xác nhận trong app/Providers/RouteServiceProvider.php: đổi fall-through limiter thành return Limit::perMinute(10)->by($request->ip());. Đây là biện pháp tạm thời theo commit sửa lỗi và cần được kiểm thử trong quy trình triển khai của đơn vị.
  3. Sau khi cập nhật, kiểm tra lại cả POST /auth/login và POST /auth/login/checkpoint từ các client khác nhau để xác nhận giới hạn không còn dùng một bucket chung. Việc thiết kế thêm khóa kết hợp IP với identifier tài khoản hoặc token checkpoint có thể cần được đánh giá riêng để duy trì bảo vệ chống brute force, nhưng advisory không xác nhận một thiết kế cụ thể ngoài việc loại bỏ bucket toàn cục.

Cách phát hiện

  1. Kiểm kê các triển khai Pterodactyl Panel và xác định những panel có thể truy cập từ mạng không tin cậy.
  2. Kiểm tra phiên bản của package pterodactyl/panel theo từng môi trường.
  3. Trong mã nguồn, kiểm tra app/Providers/RouteServiceProvider.php và xác nhận fall-through authentication limiter có khóa theo IP bằng ->by($request->ip()), thay vì chỉ gọi Limit::perMinute(10).
  4. Rà soát telemetry của POST /auth/login và POST /auth/login/checkpoint để tìm các phản hồi HTTP 429 bất thường, đặc biệt khi xảy ra đồng thời cho nhiều tài khoản hoặc nhiều địa chỉ IP.
  5. Có thể xem việc xuất hiện đồng loạt lỗi throttling trên các client khác nhau là tín hiệu cần điều tra; đây là biện pháp giám sát phòng ngừa, không phải IOC đã được vendor xác nhận. Việc không thấy log phù hợp không chứng minh hệ thống an toàn.
Nguồn (16)
Tìm hiểu thêm

Kiểm tra chuyên sâu cùng giải pháp quản lý rủi ro Web toàn diện

Giải pháp CyStack VulnScan liên tục phát hiện tài sản, xác minh lỗ hổng và giúp đội ngũ bảo mật ưu tiên khắc phục cho toàn bộ doanh nghiệp.