Black box và white box

Trong khi bài report của nhà nghiên cứu ẩn danh tiếp cận lỗi theo hướng đánh giá mã nguồn (white-box), bài report của 1sd3d lại tiếp cận theo hướng dịch ngược chương trình – reverse engineering (Black-Box), sử dụng Ghidra và trình biên dịch ngược của nó. Do vậy, ta có thể suy đoán được tại sao khi khai thác các lỗ hổng, họ thực hiện theo cách khác nhau và phát hiện các lỗ hổng trên tập các Router khác nhau.

Đoạn code lỗi ZDI-20-1451 nằm trong preprocessor #ifdef PNPX. Khi tiếp cận theo hướng white – box, sẽ tương đối khó để xác nhận rằng liệu chỉ thị PNPX đã được khai báo tại thời điểm biên dịch hay chưa, và rất có thể đoạn code lỗi sẽ không được biên dịch vào bản firmware cuối cùng. Trên thực tế, đoạn code này đúng là không được biên dịch vào firmware cho Router không dây NETGEAR R6120.

Do đó, sẽ hiệu quả hơn nếu sử dụng 1 đoạn script nhằm tìm kiếm phần code bị lỗi ZDI trong bộ source code. Dễ thấy, chuyên gia ẩn danh lựa chọn khai thác mảng no_check_paswd_path, thứ không được đóng gói trong bất kỳ chỉ thị tiêng xử lý nào.

Khi tiếp cận theo hướng dịch ngược chương trình blackbox, bạn sẽ nhìn được thứ mà CPU thấy. Tuy nhiên, với câu lệnh goto, đi cùng với định lý de Morgan và việc thiếu các tên biến sẽ thường bị thay đổi khiến cho logic của các lỗ hổng bị ẩn đi trong đoạn mã biên dịch ngược. ZDI-20-1451 là lỗi có thể được xác định rõ ràng hơn trong 2 lỗi khi ta nghiên cứu đoạn mã biên dịch ngược của researcher.

Mã biên dịch ngược firmware NETGEAR R7450 trong Ghidra

Chuỗi “PNPX_GetShareFolderList” giúp cho việc tìm kiếm một lỗ hổng đã biết trên firmware của các thiết bị khác nhau trở nên dễ dàng hơn, khi mà bạn chỉ cần dùng lệnh strings đối với file binary và tìm kiếm chuỗi đặc trưng đó là đủ. Mặt khác, viết một đoạn script để tìm kiếm lỗi ZDI-20-1176 trong một trình phân dịch chắc chắn sẽ cần nhiều thủ thuật và chuyên môn hơn.

Kết luận

Mỗi phương pháp đều có những ưu điểm và nhược điểm riêng. Trong trường hợp cụ thể này, cả hai đều hướng đến một mục đích, nhưng có cách tiếp cận khác nhau trong quá trình khai thác. Điều này chứng minh rằng không có phương pháp nào làhoàn toàn vượt trội. Tuy nhiên, hoàn toàn có khả năng rằng sẽ chỉ có một phương pháp giúp bạn đi xa hơn trong hành trình tìm kiếm những lỗ hổng tiếp theo. Và vì thế, nắm vững kỹ năng sử dụng cả hai phương pháp sẽ mang lại rất nhiều lợi ích về lâu dài.

Trong một thế giới phát triển nhanh chóng, mọi giới hạn liên tục bị phá vỡ, cùng với chu trình phát triển phần mềm gấp gáp, các nhà phát triển hệ thống NETGEAR lẽ ra cần phảilàm tốt hơn công việc đánh giá code trước khi lỗ hổng này bị phát hiện. Khai báo biến cục bộ no_need_check_password_page bên cạnh biến need_auth đã loại bỏ hoàn toàn tính bảo mật của chương trình đi. May mắn là NETGEAR đang dần dần loại bỏ những nền tảng code lỗi thời này trong các sản phẩm và firmware mới của họ.

Chú thích

Thông thường, việc suy đoán phương pháp nghiên cứu sẽ dựa vào bài report kỹ thuật của lỗ hổng. Có một lưu ý quan trọng, đó là các nhà nghiên cứu có thể sẽ không phân tách rõ ràng nghiên cứu blackbox và whitebox của họ, thay vào đó họ đưa toàn bộ nội dung và so sánh vào trong bài blog của họ. Trong trường hợp đó, ít nhất bạn sẽ học được một số kiến thức về cả 2 lỗi trên bộ định tuyến.

Nguồn: Zerodayinitiative

Xem phần 1 của bài viết TẠI ĐÂY