Giải mã bản vá im lặng của MikroTik: Lỗ hổng RouterOS 7.23.4 mà họ không giải thích

Vào ngày 3 tháng 9 năm 2026, MikroTik âm thầm phát hành đồng loạt RouterOS 7.23.4 (long-term), 7.24.2 (stable) và 6.49.21 (v6) với thông báo đáng ngờ: "Bản cập nhật bảo mật quan trọng, nhưng chúng tôi chưa công bố chi tiết". Tuy nhiên, khi bạn phát hành mã nhị phân đã vá cho toàn thế giới, việc so sánh sự khác biệt giữa phiên bản cũ và mới chính là sự tiết lộ. Bài viết này sẽ đưa bạn qua hành trình đảo ngược mã nhị phân để khám phá ba lỗ hổng nghiêm trọng mà MikroTik cố giấu.

Phát hiện manh mối đầu tiên

Mọi bản phát hành RouterOS đều có danh sách dài các cải tiến "tăng cường ổn định". Thủ thuật để tìm ra bản vá bảo mật im lặng là tìm mục xuất hiện trên mọi nhánh được hỗ trợ cùng ngày, vì backport đồng bộ là dấu vân tay của một bản sửa lỗi nghiêm trọng. So sánh changelog, chỉ có một dòng đủ điều kiện:

*) ssh - refactor SSH internal processes and improved system stability;

Dòng này xuất hiện trong cả ba phiên bản 7.23.4, 7.24.2 và 6.49.21, nhưng vắng mặt trong 7.23.3. Đây chính là manh mối để bắt đầu cuộc điều tra.

Mổ xẻ định dạng NPK

RouterOS phân phối dưới dạng file NPK chứa hệ thống file squashfs. Quá trình giải nén cho thấy RouterOS không phải một daemon monolithic mà là một loạt các tiến trình "nova" nhỏ dưới /nova/bin/, giao tiếp qua message bus nội bộ. So sánh các symbol trong thư viện chia sẻ giữa hai phiên bản, câu chuyện dần hé lộ:

• libumsg.so thêm hàm validLoginParamInput — bộ lọc đầu vào mới
• libucrypto.so thay đổi chữ ký của parseHashFromDerEncoded — hàm xác minh chữ ký RSA
• nova/bin/mtget thêm hàm snprintf và thông báo lỗi "Filename too long"

Mảnh ghép thứ nhất: "-2" không phải tên người dùng, mà là file descriptor

Cơ chế xác thực SSH trong RouterOS sau khi xác thực thành công sẽ gọi /nova/bin/login với các tham số:

execl("/nova/bin/login", "login", "-ssh", "-trace", trace, "-h"/"-mac", peer, "-c", command, authenticated_name, decimal_policy_mask, NULL)

Điểm mấu chốt nằm ở bộ phân tích cú pháp của login: nếu tham số vị trí bắt đầu bằng dấu -, nó sẽ cắt dấu gạch, dùng atoi để chuyển đổi và chấp nhận descriptor 0 đến 32, sau đó đọc tối đa 4096 bytes từ descriptor đó và tách thành hai trường. Đối với phiên SSH tương tác, fd 0, 1, 2 đều trỏ tới PTY slave.

Do đó, tên người dùng SSH là -2 có nghĩa là "thay thế các tham số tin cậy bằng cách đọc từ stderr/fd 2 (PTY)". Trường thứ hai thay thế được đưa qua strtoul(..., 10) và trở thành policy mask xác thực — cho phép toàn quyền quản trị.

Chi tiết kỹ thuật làm khai thác tưởng chừng thất bại

PTY thường hoạt động ở chế độ canonical, việc gửi 4096 NULs sẽ không kết thúc đọc sạch sẽ. Giải pháp chính xác là gửi hai trường kết thúc bằng NUL, sau đó là hai byte VEOF (0x04 0x04) để buộc line discipline trả dữ liệu và EOF:

0\x00 654958\x00 \x04\x04
^     ^             ^
|     |             hai terminal-EOF
|     RouterOS full policy mask (0x9fe6e)
Trường thay thế thứ nhất

Tái hiện: Từ SSH read-only lên toàn quyền quản trị

Với một RADIUS responder tùy chỉnh (chỉ chấp nhận tên người dùng -2), kết quả thử nghiệm cho thấy RouterOS mở console với quyền đầy đủ, cho phép thay đổi identity, tạo tài khoản ops trong nhóm full — chính xác là mẫu hành vi được báo cáo từ các router bị tấn công thực tế.

Trên bản 7.23.3, việc gửi payload đúng cách tạo ra:

[654958@CHR] > :put [/system identity get name]  
CHR
/system identity set name=minus2-proof
:put [/system identity get name]
minus2-proof

Trong khi bản 7.23.4 từ chối với thông báo invalid user input.

Mảnh ghép thứ hai: Lỗ hổng xác minh chữ ký RSA số mũ thấp

Hàm parseHashFromDerEncoded được sử dụng trong mọi thành phần xác minh chữ ký RSA: sshd, IPsec, TLS. Lỗ hổng nằm ở việc kiểm tra padding PKCS#1 v1.5 quá lỏng lẻo:

• Trên 7.23.3, kiểm tra không yêu cầu tối thiểu 8 byte 0xFF — thực tế chấp nhận 0 byte 0xFF (tiền tố ngắn nhất: 00 01 00)
• Không kiểm tra xem sau DigestInfo còn byte thừa nào không

Thử nghiệm giả mạo chữ ký SSH

Với khóa RSA 2048-bit exponent e=3, kẻ tấn công có thể giả mạo chữ ký mà không cần khóa riêng bằng cách:

1. Xây dựng prefix: 00 01 00 || DER(SHA-256 DigestInfo) || SHA256(SSH session blob)
2. Chèn padding zeros vào cuối số nguyên 2048-bit
3. Tính căn bậc ba số nguyên làm tròn lên

Vì e=3, việc xác minh sẽ lập phương chữ ký giả mạo — phần lỗi nằm trong vùng garbage mà phiên bản 7.23.3 bỏ qua. Bản 7.23.4 đã vá bằng cách:

• Yêu cầu digest có độ dài chính xác
• Yêu cầu digest phải là phần tử cuối cùng trong thông điệp mã hóa

Mảnh ghép thứ ba: Lỗi tràn bộ nhớ trong mtget

mtget là công cụ tải file qua TFTP/FTP/HTTP. Lỗ hổng xuất hiện khi xử lý pathname dài bất thường:

EIP_OFFSET = 541
UNLINK_PLT = 0x0804C250
RETURN_CRASH = 0x42424242

Một chuỗi 700 bytes pathname có thể ghi đè saved EIP tại offset 541, cho phép thực thi ROP. Mặc dù binary có NX bit, không có stack canary, nhưng do non-PIE và partial RELRO, việc kiểm soát luồng thực thi là hoàn toàn khả thi:

Patch now: 7.23.4 long-term, 7.24.2 stable, 6.49.21 v6

Kết luận và khuyến nghị cho người dùng Việt Nam

Ba lỗ hổng tạo thành một chuỗi tấn công hoàn chỉnh. Mặc dù chưa có bằng chứng về khai thác từ xa mà không cần xác thực trên cấu hình mặc định, nhưng rủi ro cho hạ tầng mạng tại Việt Nam là rất lớn, đặc biệt với các nhà cung cấp dịch vụ internet (ISP) và doanh nghiệp sử dụng MikroTik làm router biên:

• Kiểm tra ngay phiên bản RouterOS; nếu dưới 7.23.4/7.24.2/6.49.21, hãy cập nhật khẩn cấp
• Rà soát tài khoản ops bất thường, log chứa ssh:-2@, scheduler entries với lệnh fetch kết hợp import
• Xem xét /system device-mode print — nếu hiển thị flagged: yes, xem như thiết bị đã bị xâm nhập
• Kiểm tra khóa RSA exponent 3 trong authorized keys — thay bằng Ed25519/ECDSA hoặc RSA e=65537
• Hạn chế SSH ra ngoài management plane, vô hiệu hóa MAC-Telnet trên segment L2 không tin cậy

Bài học quan trọng: sự im lặng không phải sự bí mật. Khi bạn vá lỗi một cách công khai, bạn đã tự tiết lộ. Những kẻ tấn công luôn đọc diff — vấn đề là bạn có đọc trước chúng hay không.

Hãy kiểm tra router biên của bạn ngay hôm nay. 🐟