Phân tích mã lỗi CVE-2014-1761 trong MS Office

[CauUt37]

Vào tháng 3/2014 một nhóm nghiên cứu bảo mật đã công bố một lỗ hổng zero-day trong việc xử lý file Rich Text Format (RTF) của Microsoft Word. Lỗ hổng tồn tại trong cách phân tích cú pháp của tập tin Microsoft Word RTF và có thể dẫn đến lỗi bộ nhớ. Microsoft đã cung cấp bản vá cho lỗ hổng này, tuy nhiên việc cập nhật bản vá không phải là tự động với tất cả người dùng. Bài này sẽ phân tích cách khai thác lỗ hổng này.

Chi tiết lỗ hổng:
Lỗ hổng nằm trong việc xử lý control word “listoverridecount ”và “lfolevel” trong header của file RTF.
Các phiên bản bị ảnh hưởng:
- Microsoft Word 2003
- Microsoft Word 2007
- Microsoft Word 2010
- Microsoft Word 2013
- Microsoft Word 2013 RT
- Microsoft Word Viewer
- Microsoft Office Web Apps 2010
- Microsoft Office Web Apps 2013
- Microsoft Office Compatibility Pack
- Microsoft Office for Mac 2011
- Microsoft SharePoint Server Word Automation Services 2010

Khai thác lỗ hổng:
Môi trường:
- OS: Windows 7
- Module “MSCOMCTL.OCX” Version: 6.01.9834
- MS Word 2010
- Thư viện wwlib.dll phiên bản 14.0.7113.500
Ở phân tích này, các địa chỉ ROP chain sử dụng để khai thác được đặt trong file “MSCOMCTL.OCX” phiên bản 6.01.9834. Do đó, shellcode không thể chạy trên file “MSCOMCTL.OCX” của windows XP.

Hình 1: “MSCOMCTL.OCX” được load vào bộ nhớ.
​

Lỗ hổng này nằm trong thư viện phân tích cú pháp file RTF “wwlid.dll” của MS Word 2010.

Hình 2: Thư viện wwlid.dll được load vào bộ nhớ.
​

Thông thường giá trị của “listoverridecount” này bằng 1 hoặc 9. Sẽ có một mảng bộ nhớ được khởi tạo khi sử dụng control word này. Mỗi phần tử của mảng có kích thước là 8 byte. Ở đây chúng ta sử dụng control word “listoverridecount25” và “lfolevel”, Lỗi sẽ xẩy ra khi giá trị của “listoverridecount” và “lfolevel” lớn hơn 16 (0x10).

Hình 3: File RTF lỗi.
​

Tìm kiếm module phân tích cú pháp file RTF trong thư viện “wwlid.dll” (Đia chỉ gốc 0x64E60000).

Hình 4: Module phân tích cú pháp RTF

Hình 5: Code cử lý control word “listoverridecount N”

​

Nhìn vào hình 5 chúng ta có thể thấy tham số Arg3=0x19 (25) là giá trị control word “listoverridecount25” được đẩy vào địa chỉ [EBP-0x2E04] ( stack:0x654918A2). Sau đấy gọi đến hàm xử lý cú pháp (0x6549BAFF). Với giá trị “listoverridecount” là 25 thì bộ nhớ heap được cấp phát sẽ là 0x19*8 (byte) tại địa chỉ 0x654918B4.

Hình 6:Kiểm tra giá trị của “listoverridecount”

​

Trên hình 6, thông số heap được load vào thanh ghi EAX. Với giá trị “listoverridecount25” khi được “And” với giá trị 0x0F sau đó chuyển tới địa chỉ 0x654A31DF. Nếu giá trị “listoverridecount” nhỏ hơn 16(0x10) thì không thể khai thác được lỗ hổng.

Hình 7: Đoạn mã gây tràn heap.
​

Debug step by step thì tại địa chỉ 0x654A31F9, EAX lưu con trỏ cấu trúc của module phân tích cú pháp RTF, và có địa chỉ tương đối là 0x80FC.

Hình 8: Lưu trữ con trỏ cấu trúc của RTF
​

Thanh ghi EDI tăng lên theo mỗi vòng lặp, mỗi vòng lặp sẽ có 8byte dữ liệu heap được cấp phát. Khi giá trị “listoverridecount” bằng 25(0x19), số vùng nhớ được cấp phát vẫn là 0x19 nhưng giá trị của EDI thì lớn hơn. Và giá trị của EDI chính là số lượng của “lfolevel”.

Hình 9: Các bản ghi giá trị “lfolevel” trong heap
​

Ban đầu (EDI=1), giá trị “lfolevel” đầu tiên sẽ bằng NULL, sẽ không có dữ liệu trong Hex Dump. Ở giá trị thứ 27 của “lfolevel” 8 byte dữ liệu sẽ được thêm vào heap. Lỗi xảy ra khi chỉ có 25(0x19) vùng được cấp phát cho “listoverridecountN” và dữ liệu “lfolevel” thứ 27 sẽ ghi đè lên vùng mà các API khác sử dụng.

Hình 10: Vùng bị ghi đè trong file RTF.
​

Giá trị thanh ghi EDI tăng lên 29 (0x1D) và ghi đè lên cấu trúc được sử dụng bởi API khác.

Hình 11: Giá trị thanh ghi EDI
​

Hình 12 là một cấu trúc dữ liệu thông thường, sau khi thực thi ở địa chỉ 0x654A3207 (Hình 11), các dữ liệu thông thường đã bị ghi đè (Hình 13)

Hình 12: Heap trước khi bị ghi đè

Hình 13: Heap sau khi bị ghi đè

​

Nếu di chuyển đến địa chỉ 0x034F0150 như trên hình 13 thì ta sẽ được dữ liệu tại địa chỉ 0x034F0150 như hình 14.

Hình 14: Lưu trữ biến lfolevel vào vùng heap bị tràn.
​

Tại đại chỉ 0x64E8C19C giá trị của [ECX + 4] sẽ là “0x275A48E8”, và EIP sẽ nhảy đến địa chỉ “0x275A48E8”.

Hình 15: EIP sẽ nhảy tới địa chỉ 0x275A48E8 (Thuộc module “MACOMCTL.OCX”)
​

Địa chỉ 0x275A48E8 thuộc module “MACOMCTL.OCX”. Để chạy được shell code, OPCode phải tồn tại ở địa chỉ 0x275A48E8 trong module “MSCOMCTL.OCX” như hình 16.

Module MSCOMCTL.OCX được sử dụng là version 6.01.9834 trên windows 7, vì vậy trên windows XP tuy có lỗ hông trên module “wwlib.dll”. nhưng OPCode không chạy trên MSCOMCTL.OCX, vì vậy không thể tấn công được.

Hình 16: OPCode tại địa chỉ 0x275A48E8
​

Tại hình 17 là dữ liệu “lfolevel” thứ 29 để chạy shellcode. Hãy xem làm sao để chèn được giá trị 0x275A48E8 vào địa chỉ 0x02E617E0 như trong hình 14.

Hình 17: Dữ liệu sử dụng để chuyển EDI tới 0x275A48E8
​

Để nhập giá trị 0x7B7B như bên dưới, chúng ta sử dụng control word “levelstartat31611”. Với tham số 31611 khi chuyển sang giá trị HEX sẽ là 0x7B7B.

Hình 18: Lưu giá trị “levelstartat31611” dưới dạng HEX.
​

Để tạo ra giá trị 0xE8, chúng ta sử dụng “levelnfcn232”. Giá trị 232 khi chuyển sang HEX sẽ có giá trị 0xE8.

Hình 19: Lưu giá trị “levelnfcn232” dưới dạng HEX
​

Để chèn giá trị 0x48, cần phải sử dụng 2 giá trị “levelnfcn1” và “levelnorestart1”.

Để chèn chuỗi 0x5A 0x27 0x89 0x64 0x58 0x27 0xEF 0xB8 0x58, chúng ta sử dụng control word “levelnumbers”. Khi sử dụng tham số 0x5A chương trình sẽ đọc các giá trị phía sau và ghi vào heap.

Hình 20: Giá trị control word “levelnumbers” trong file RTF.
​

Tương tự chúng ta sử dụng “levelfollow39, levelspace22873, levelindent23130” để chèn các giá 0x27, 0x5959, 0x5A5A.

Bây giờ chúng ta có thể điều khiển EIP về Shellcode của mình. Mã khai thác các bạn có thể tham khảo tại đây.