Tiết lộ bộ nhớ và khởi động lại kernel qua bandwidth-test trong MikroTik RouterOS

RouterOS chấp nhận một kết nối btest "related" trước khi phiên chính tương ứng hoàn tất xác thực. Một client chưa xác thực có thể sử dụng trạng thái này để khởi động một bài kiểm tra UDP trên IPv4. Với "random-data=false", bên gửi truyền phần đuôi chưa được khởi tạo từ kernel packet buffer. Một khoảng kiểm tra kích thước gói tin riêng biệt, không được kiểm tra và bị đảo chiều, gây unsigned integer underflow, đầu ra phân mảnh có kích thước bất thường và có thể khởi động lại RouterOS kernel. Lỗi này đã được sửa trong các phiên bản: 6.49.21 (Long-term), 7.23.4 (Long-term) và 7.24.2 (Stable)

MikroTik RouterOS được bản ghi liệt kê với trạng thái mặc định là không bị ảnh hưởng, nhưng các phạm vi sau được xác định là bị ảnh hưởng:

• Nhánh bắt đầu từ 7.24 và thấp hơn 7.24.2.
• Nhánh từ 7.0.0 và thấp hơn 7.23.4.
• Nhánh từ 6.0.0 và thấp hơn 6.49.21.

CERT Polska xác nhận cùng các ranh giới nhánh này. MikroTik công bố bản sửa có trong 7.24.2, 7.23.4, 6.49.21 và 7.25 beta 3. Các nguồn được kiểm tra không cung cấp một ánh xạ đầy đủ cho mọi nhánh RouterOS khác ngoài các nhánh và bản sửa nêu trên, vì vậy không nên suy ra trạng thái của các nhánh chưa được liệt kê.

MikroTik RouterOS xử lý một kết nối btest kiểu related trước khi phiên chính tương ứng hoàn tất xác thực. Vì vậy, một client chưa xác thực có thể đưa dịch vụ bandwidth-test vào trạng thái vốn chỉ nên đạt được sau khi đăng nhập và khởi động một bài kiểm tra UDP trên IPv4.

Khi random-data=false, bên gửi có thể truyền phần đuôi chưa được khởi tạo của kernel packet buffer, dẫn đến tiết lộ dữ liệu còn sót lại trong bộ nhớ kernel. Một lỗi riêng trong việc kiểm tra khoảng kích thước gói tin, cụ thể là khoảng bị đảo chiều nhưng không được xác thực đúng cách, có thể gây unsigned integer underflow, tạo ra dữ liệu phân mảnh có kích thước bất thường và làm RouterOS kernel khởi động lại.

Nguồn công khai xác nhận cơ chế xử lý trạng thái, việc tiết lộ bộ nhớ và khả năng gây crash, nhưng không cung cấp đầy đủ định dạng gói tin hoặc mọi điều kiện triển khai chi tiết cần thiết để tái hiện lỗi. Khả năng khai thác thực tế phụ thuộc vào việc bandwidth-test server có thể truy cập từ vùng mạng của kẻ tấn công hay không.

Lỗi có thể bị tiếp cận qua mạng bằng một client chưa xác thực và không yêu cầu tương tác của người dùng. Điều kiện quan trọng là dịch vụ bandwidth-test phải có thể truy cập từ mạng không tin cậy; CERT Polska nêu rõ việc vô hiệu hóa hoặc giới hạn truy cập đến bandwidth-test server là biện pháp giảm bề mặt tấn công.

Bản ghi chuẩn đánh dấu lỗi có public exploit và known exploited. CERT Polska cũng cho biết CVE này đã được đưa vào CISA Known Exploited Vulnerabilities Catalog và mô tả việc khai thác tích cực trong bối cảnh các cuộc tấn công nhằm vào RouterOS.

Tuy nhiên, các cuộc tấn công chiếm quyền được CERT Polska quan sát thuộc một chuỗi nhiều lỗi RouterOS. Bằng chứng công khai không khẳng định rằng mọi vụ xâm nhập đã quan sát đều khai thác riêng lỗi bandwidth-test này, cũng không xác nhận rằng lỗi này đơn độc dẫn đến quyền quản trị.

Kết quả kỹ thuật trực tiếp gồm hai khả năng độc lập: tiết lộ phần đuôi chưa được khởi tạo của kernel packet buffer và gây unsigned integer underflow trong kiểm tra kích thước, từ đó tạo đầu ra phân mảnh bất thường hoặc làm RouterOS kernel khởi động lại.

Tác động bảo mật đã được mô tả là ảnh hưởng thấp đến tính bí mật và ảnh hưởng cao đến tính sẵn sàng. Lỗi không được xác nhận là cho phép sửa dữ liệu, tạo tài khoản, nâng quyền hoặc chiếm quyền quản trị khi khai thác riêng.

Về vận hành, kernel restart có thể làm mất kết nối và làm gián đoạn các dịch vụ đi qua router. Khả năng tiết lộ bộ nhớ có thể làm lộ dữ liệu tạm thời của kernel, nhưng nguồn công khai không xác định chính xác dữ liệu nào sẽ xuất hiện trong phần bộ nhớ bị gửi ra ngoài.

Lỗi có thể làm lộ một phần dữ liệu còn sót lại trong bộ nhớ kernel, nhưng nguồn hiện có không xác định loại dữ liệu cụ thể hoặc chứng minh việc tiết lộ toàn bộ cấu hình hay thông tin xác thực.

Việc tạo dữ liệu phân mảnh bất thường và khởi động lại RouterOS kernel có thể làm gián đoạn chuyển tiếp lưu lượng, quản trị thiết bị và các dịch vụ mạng phụ thuộc vào router. Tác động sẵn có là từ chối dịch vụ từ xa, không phải thay đổi cấu hình hoặc nâng quyền được xác nhận từ riêng lỗi này.

Nếu bandwidth-test được mở cho mạng Internet hoặc mạng không tin cậy, một thiết bị chưa vá có thể trở thành điểm gây gián đoạn dịch vụ mà không cần tài khoản hợp lệ. Mức độ ảnh hưởng phụ thuộc vào vai trò của thiết bị, khả năng dự phòng và phạm vi mạng mà thiết bị phục vụ.

1. Nâng cấp RouterOS lên bản sửa tương ứng với nhánh đang sử dụng: dùng 6.49.21 cho nhánh bị ảnh hưởng từ 6.0.0 và thấp hơn 6.49.21, 7.23.4 cho nhánh từ 7.0.0 và thấp hơn 7.23.4, hoặc 7.24.2 cho nhánh từ 7.24 và thấp hơn 7.24.2. MikroTik cũng liệt kê 7.25 beta 3 là bản có bản sửa.
2. Nếu chưa thể cập nhật ngay, vô hiệu hóa bandwidth-test server hoặc chặn toàn bộ truy cập đến dịch vụ này từ ngoài các mạng quản trị tin cậy. Đây chỉ là biện pháp tạm thời và không thay thế việc cài đặt bản RouterOS đã sửa.
3. Sau khi cập nhật, kiểm tra log về thông báo thiết bị bị xâm nhập, kiểm tra trạng thái flagged bằng /system/device-mode/print, và rà soát user, script, scheduler task, proxy, tunnel cùng các thay đổi cấu hình không được nhận diện.
4. Nếu có dấu hiệu thiết bị đã bị xâm nhập, cô lập thiết bị khỏi mạng và bảo toàn log cùng cấu hình trước khi reset. Sau khi thu thập dữ liệu cần thiết, khôi phục từ cấu hình đáng tin cậy, cấu hình lại thiết bị và thay đổi mật khẩu, khóa cùng các secret liên quan. Không khôi phục mù quáng một bản sao cấu hình đầy đủ được tạo trên thiết bị có khả năng đã bị xâm nhập.

1. Kiểm kê toàn bộ thiết bị MikroTik RouterOS và đối chiếu phiên bản với các nhánh bị ảnh hưởng trong affected_summary.
2. Xác định bandwidth-test server có đang bật hay có thể truy cập từ Internet hoặc các mạng không tin cậy hay không. Việc dịch vụ không bị giới hạn truy cập nên được xem là dấu hiệu cần ưu tiên xử lý, không phải bằng chứng đã bị khai thác.
3. Kiểm tra log và hệ thống giám sát về các lần RouterOS kernel hoặc thiết bị khởi động lại bất thường, đặc biệt khi có lưu lượng từ bên ngoài hướng đến bandwidth-test. Đây là kiểm tra phòng ngừa, không phải IOC riêng đã được xác nhận cho lỗi này.
4. Sau khi cập nhật, kiểm tra log về thông báo thiết bị bị xâm nhập và kiểm tra trạng thái flagged bằng /system/device-mode/print. Cơ chế này chỉ phát hiện một số dấu vết được biết trước, nên trạng thái không bị đánh dấu không chứng minh thiết bị an toàn.
5. Rà soát các user, script, scheduler task, proxy, tunnel và thay đổi cấu hình không được nhận diện. Nếu phát hiện dấu hiệu nghi ngờ, cần cô lập thiết bị và bảo toàn log cùng cấu hình trước khi reset hoặc khôi phục.