1. Thông tin chung

Sâu Conficker sử dụng nhiều kỹ thuật để phát tán như phát tán qua USB, qua giao thức HTTP, qua khai thác lỗ hổng hệ điều hành... Điều này cho phép Conficker có khả năng phát tán mạnh. Bài viết này sẽ đề cập đến kỹ thuật lây lan của Conficker lợi dụng lỗ hổng của hệ điều hành, cụ thể là khai thác lỗ hổng MS08-067 trong dịch vụ Server Service của hệ điều hành Windows.

2. Mô tả chi tiết lỗ hổng trong MS08-067

Tháng 10/2008, ngay sau khi Microsoft công bố khẩn cấp bản vá MS08-067, Bkis đã có bài viết mô tả sơ lược về lỗi cũng nhưng khuyến cáo cập nhật bản vá tới người sử dụng máy tính tại Việt Nam. Trong bài viết lần này, chúng tôi sẽ mô tả chi tiết hơn về lỗ hổng trong MS08-067.

Giao thức RPC của dịch vụ Server Service trong Windows hỗ trợ một thủ tục được gọi từ xa và xử lý các yêu cầu đổi đường dẫn (ví dụ \\C\Program Files\..\Windows) về định dạng đường dẫn Canonicalization ngắn gọn hơn (\\C\Windows). Tuy nhiên, với một đường dẫn quá dài, Windows xử lý không tốt dẫn đến tràn bộ đệm.

Cụ thể, Windows (svchost process) sử dụng hàm NetpwPathCanonicalize trong thư viện netapi32.dll để thực hiện chức năng kể trên. Đây là Pseudo-code (đoạn mã mô phỏng) :

func _NetpwPathCanonicalize(wchar_t* Path)
{
// kiểm tra độ dài của Path
if( !_function_check_length(Path) )
return;
…
_CanonicalizePathName(Path);
…
return;
}

func _CanonicalizePathName(wchar_t* Path)
{
// Bảo vệ Stack với cookie - /GS
_save_security_cookie();
…
wchar _wcsBuffer[420h];
…
// đây chính là hàm gây tràn bộ nhớ
wcscat(wcsBuffer,Path);
…
// Hàm chuyển đổi
_ConvertPathMacros(wcsBuffer);
…
return;
}

Theo Pseudo-code trên thì hàm NetpwPathCanonicalize() đã thực hiện kiểm độ dài của đường dẫn đưa vào hàm CanonicalizePathName(). Tuy nhiên, hàm CanonicalizePathName() lại sử dụng wcscat để thực hiện copy đường dẫn vào biến cục bộ (wcsBuffer). Điều này dẫn đến vấn đề là hàm này sẽ không bị tràn trong lần thực thi đầu tiên nhưng sẽ bị tràn trong các lần gọi tiếp sau, ví dụ nội dung của wcsBuffer trong các lần gọi như sau :

- Lần 1 : wcsBuffer = “\\a\aaaaa\aaaa\..\..\a”
- Lần 2 : wcsBuffer = “\\a\aaaaa\aaaa\..\..\a\\a\aaaaa\aaaa\..\..\a”
- Lần 3 : wcsBuffer = “\\a\aaaaa\aaaa\..\..\a\\a\aaaaa\aaaa\..\..\a\\a\aaaaa\aaaa\..\..\a”
- …

Như vậy, chắc chắn có thể gây tràn Server Service bằng một vài lời gọi hàm NetpwPathCanonicalize() từ xa với độ dài đường dẫn hợp lý.

Tuy nhiên, để khai thác lỗ hổng này Conficker gặp phải hai rào cản:

• Cookie : Vấn đề thực sự là hàm CanonicalizePathName() được build với tham số /GS. Điều này nhằm bảo vệ hàm với một cookie đặt trước địa chỉ trả về. Bất cứ khi nào địa chỉ trả về bị ghi đè, cookie cũng bị ghi đè và hệ thống biết được hàm bị tràn.

• DEP : Tiến trình của Server Service là svchost.exe được mặc định bảo vệ bởi cơ chế DEP. Vì thế nếu Shellcode đặt trên stack thì DEP không cho phép thực thi lệnh.

3. Conficker sử dụng những kỹ thuật khai thác nào ?

Trong Pseudo-code, hãy chú ý đến một hàm sử dụng trong CanonicalizePathName(). Microsoft gọi hàm này là ConvertPathMacros(). Hàm này không kiểm tra cookie nên Conficker đã lợi dụng nó để chuyển điều khiển tới Shellcode.

Còn việc vượt qua cơ chế bảo vệ DEP, Conficker lợi dụng hàm ZwSetInformationProcess() để tắt (disable) DEP ở chế độ runtime. Sau đó, Conficker mới chuyển điều khiển đến Shellcode nằm trên stack.

Các hàm trên đều đã được gọi sẵn trong thư viện AcGenral.dll được nạp bởi shvshost, vì vậy Conficker chỉ cần sử dụng thư viện này để vượt qua cả hai cơ chế bảo vệ trên.

Hệ điều hành có thể bị Conficker tấn công khai thác MS08-067 là các hệ điều hành Windows XP SP2, SP3 và Windows 2003 SP1, SP2. Chúng tôi, một lần nữa, khuyến cáo người sử dụng cần nhanh chóng thực hiện việc cập nhật các bản vá an ninh của Microsoft.

Ngoài ra, bạn có thể tìm hiểu thêm về module phát tán lợi dụng MS08-068 của Conficker, phân tích shellcode của Conficker và thông tin các hệ điều hành có thể bị khai thác bởi Conficker tại Security Blog của Bkis.
 

Chuyên viên phân tích: Bùi Quang Minh và Hoàng Xuân Minh