Trong thời đại hiện nay, hàng ngày chúng ta có thể thấy rất nhiều thông tin về các lỗ hổng an toàn thông tin trên các phương tiện đại chúng, tuy nhiên vì nhiều lý do khác nhau, không phải lúc nào cũng có thể tìm thấy các bài phân tích chi tiết, hay PoC ( Proof Of Concept) để có thể dễ dàng thử nghiệm cũng như có cái nhìn sâu hơn về lỗ hổng. Bên cạnh đó, việc phân tích một sản phẩm thương mại (thường rất nhiều chức năng và vô cùng phức tạp) không phải lúc nào cũng có thể thực hiện. Do đó, một kỹ thuật để giảm tải khối lượng công việc cần phân tích đã ra đời, dựa trên việc so sánh các file binary được vá khi lỗ hổng đã được công bố. Nhìn chung, kỹ thuật này có thể được sử dụng cho tất cả các phần mềm có thông tin về lỗ hổng và các bản vá. Tuy nhiên, trong nội dung bài trình bày này sẽ tập chung vào các bản vá cho Windows, đi cùng nó là khái niệm Exploit Wednesday.
Vậy tại sao lại gọi là Exploit Wednesday, đầu tiên chúng ta cần biết tới một khái niệm khác của Windows trước. Vào ngày thứ ba thứ hai hàng tháng, Microsoft thường đưa ra các bản vá cho lỗ hổng an ninh trên các sản phẩm của mình. Chỉ trừ một số trường hợp các lỗ hổng đặc biệt nghiêm trọng các bản vá bất thường ( không theo định kỳ) mới được cung cấp. Chính việc cập nhật định kỳ vào thứ ba này đã sinh ra một khái niệm đó là “Patch Tuesday”.
Về mặt lý thuyết, các thiết bị nên được cấu hình cập nhật tự động và sẽ được cập nhật các bản vá này ngay lập tức. Tuy nhiên, trên thực tế vì nhiều nguyên nhân khác nhau rất nhiều thiết bị không cấu hình tự động cập nhật, thậm chí tắt cả tính năng thông báo khi có bản vá mới. Chính vì vậy, sau khi bản vá ngày thứ ba được cung cấp cùng với thông tin về các lỗ hổng được vá trong bản vá này, các hacker có thể lợi dụng phân tích các điểm thay đổi trong bản vá từ đó phát hiện các lỗ hổng và lợi dụng để khai thác. Do đó đã sinh ra một khái niệm là “Exploit Wednesday” ám chỉ việc các mã khai thác phát sinh một ngày sau các bản vá từ việc phân tích chính bản vá này.
Trong phạm vi bài viết này, chúng ta sẽ lần lượt đi qua một số nội dung để cùng làm rõ về khái niệm Exploit Wednesday cũng như các kỹ thuật, công cụ liên quan để có thể phân tích các bản vá của Windows.
1. Patch Tuesday
1.1 Hoạt động cơ bản
Trên thực tế, “Patch Tuesday” không phải là một khái niệm chính thống do Microsoft đặt ra, nó chỉ đến từ việc các bản vá của công ty này thường được cung cấp vào ngày thứ ba thứ hai (hoặc đôi khi cả ngày thứ ba thứ tư) của một tháng.
“Patch Tuesday” hay bản vá ngày thứ ba bao gồm các bản vá cho tất cả các lỗi và các cập nhật cần thiết kể từ lần cập nhật gần nhất (thường là 1 tháng hoặc 2 tuần trước, trừ một số trường hợp các lỗ hổng nghiêm trọng cần được hot fix). Một số người dùng có thể thắc mắc về việc máy tính của họ có thể được yêu cầu cập nhật rất nhiều lần, không chỉ riêng vào các ngày thứ ba. Tuy nhiên, đây là một nhầm lẫn khá phổ biến giữa bản vá ngày thứ ba và các cập nhật hàng ngày ( bao gồm cập nhật cơ sở dữ liệu cho Window Defender và Microsoft Security Esentials – một AV sẵn có trên Windows từ phiên bản Windows 7 trở về trước).
Các bản cập nhật này có rất nhiều cách khác nhau để được cài đặt trên thiết bị chạy Windows, đối với các thiết bị có thể sử dụng Internet việc cài đặt là tương đối đơn giản.
- Tự động cài đặt khi có bản vá mới.
- Thông báo với người dùng khi có bản vá mới, để có thể chủ động chọn thời gian cài (về bản chất vẫn là cài đặt tự động, có thêm việc xác nhận từ người dùng)
Với các thiết bị không thể truy cập internet vẫn có thể thực hiện cập nhật bản vá thông qua việc:
- Tải trực tiếp bản vá từ trang web của Microsoft dưới định dạng file “.msu” và thực hiện cài đặt thủ công ( các bản vá đã được cài đặt thành package hầu như có thể cài đặt One click ). Đây cũng chính là cách thức sẽ được sử dụng để phân tích các bản cập nhật này.
- Cài đặt thông qua WSUS, đối với một số đơn vị có các chính sách bảo mật, việc cập nhật là vô cùng cần thiết, tuy nhiên vẫn sẽ có một số server không thể trực tiếp ra ngoài internet, do đó cần thực hiện cập nhật thông qua một máy chủ WSUS. Máy chủ này sẽ thực hiện tải về tất cả các bản vá mới sau đó thực hiện phân phối cho các thiết bị khác, các thiết bị này chỉ cần thông mạng đến WSUS server thay vì phải có đường truyền ra internet.
Tuy nhiên, trên thực tế, rất nhiều thiết bị vẫn không được cài đặt những bản vá này vì nhiều lý do khác nhau ví dụ như: cảm thấy bất tiện khi sử dụng, thời gian cài đặt có thể lâu trong một vài trường hợp, gây đầy ổ cứng với các thiết bị có ít dung lượng lưu trữ hoặc tâm lý ngại cập nhật với các thiết bị chạy dịch vụ quan trọng lâu ngày sợ ảnh hưởng. Từ đó tạo ra các cơ hội cho hacker tấn công vào hệ thống. Và một ngày sau khi bản vá được công bố chính là thời điểm vàng để thực hiện tấn công, khi việc cập nhật còn chưa được thực hiện cũng như các hacker không có khả năng phân tích các bản vá chưa thể lợi dụng các lỗ hổng, first come, first service, kẻ tấn công đầu tiên sẽ có được tất cả. Đó chính là lúc khái niệm “Exploit Wednesday” ra đời.
1.2 Cấu trúc file msu
Như đã nói ở trên, các file msu là một gói cập nhật được sử dụng bởi Windows Update. Nó có thể chứa một hoặc nhiều cập nhật cho các ứng dụng và file hệ thống trong Windows. Windows Update sẽ cài đặt msu file bằng Windows Update Stand-alone Installer (Wusa.exe).
Mỗi file msu sẽ bao gồm các thành phần sau:
- Một file xml mô tả nội dung của file msu
- Một file properties cung cấp các thông tin cho Wusa.exe để thực hiện cài đặt
- Một hoặc nhiều cab file, đây là các file cabinet chứa các binary được cập nhật trong bản vá này, cũng là thành phần cần được quan tâm nhất trong msu file.
Hình 1: Nội dung file msu của KB4534271 sau khi được giải nén
Hình 2: File xml mô tả nội dung file msu
Hình 3: File properties cung cấp thông tin cho Wusa.exe
2. Exploit Wednesday
Cũng như Patch Tuesday, Exploit Wednesday cũng là một khái niệm không chính thống, thứ tư ở đây có thể hiểu như một hình ảnh mang tính chất tượng trưng về việc nhanh chóng lợi dụng các bản vá để tìm ra lỗ hổng bảo mật thay vì miêu tả các mã khai thác được đưa ra vào thứ tư hàng tuần.
Việc phân tích các bản vá này có thể thực hiện thông qua các bước sau
- Thu thập thông tin về bản vá
- Phân tích file msu
- Tìm kiếm và thu thập phiên bản trước khi cập nhập của file binary được vá
- So sánh hai file binary và tìm điểm khác nhau
2.1 Thu thập thông tin về bản vá
Đây là bước đầu tiên để thực hiện phân tích, các thông tin này có thể dễ dàng thu thập từ nguồn:
- Microsoft bulletin: https://portal.msrc.microsoft.com/en-us/security-guidance
- NIST CVE: https://nvd.nist.gov/vuln
- Các nguồn báo mạng khác
Việc thu thập thông tin ban đầu sẽ cho chúng ta biết khi nào có bản vá mới vừa được cập nhật và lỗ hổng nào đã được công bố trong bản vá này cũng như các thông tin liên quan để dễ dàng tìm kiếm các file binary bị ảnh hưởng trong các bước sau
Ví dụ với CVE 2020 0610, thông qua thông tin trên nvd.nist.gov chúng ta có thể biết có một lỗ RCE ảnh hưởng tới dịch vụ Remote Desktop Gateway trên Windows vào đầu tháng 01 năm 2020, do đó cần phân tích bản vá tuần 02 tháng 01 và tập trung vào dịch vụ RDG.
Hình 4: Thông tin về CVE 2020 0610 trên nvd.nist.gov
Từ các thông tin thu được từ bước trước chúng ta dễ dàng tìm được file cài đặt stand-alone cho bản vá tương ứng trên portal.msrc.micorosft.com
Hình 5: Thông tin về các bản vá cho CVE 2020 0610
Để dễ dàng hơn cho việc phân tích về sau, càng ít thông tin dư thừa sẽ càng tiết kiệm thời gian, do đó ở đây chỉ nên tải về file “Security Only” (chỉ chứa các cập nhật bảo mật) thay vì Monthly Rollup (bao gồm cả các cập nhật liên quan đến trải nghiệm người dùng khác).
2.2 Phân tích file msu
Như đã trình bày về cấu trúc file msu, đây là một file nén bao gồm nhiều file khác và thành phần cần quan tâm ở đây là file cab nằm trong nó. Để lấy được các file này có thể sử dụng lệnh expand có sẵn trong Windows:
expand <filename> -F:* <location>
Lệnh này sẽ thực hiện giải nén file msu thành các file như trên. Sau khi giải nén file msu tiếp thục giải nén file cab tương ứng. Trong trường hợp có nhiều file cab trong gói, cần kiểm tra mã KB và kiến trúc và hệ điều hành của file để có thể tìm đúng file cần tìm. VD file Windows8.1-KB4534309-x64.cab dành cho mã KB4534309, cài đặt cho hệ điều hành Windows 8 64bit. Để giải nén file này cũng sử dụng expand tương tự ở trên
expand <filename> -F:* <location>
Kết quả sẽ cho ra các file và metadata tương ứng với các binary được cập nhật
Hình 6: Nội dung file cab sau khi giải nén
Như chúng ta đã thấy các nội dung này có thể rất nhiều và phức tạp, tuy nhiên không phải tất cả đều là các file mới được cập nhật. Do đó có thể thực hiện một bước tiền xử lý lấy tất cả các file trong các folder này và sắp xếp theo thời gian file được chỉnh sửa từ gần nhất đến xa nhất để loại bỏ các nội dung thừa. Sau khi chạy một script python có tác dụng sắp xếp file kết quả sẽ có được như sau:
Hình 7: Kết quả sắp xếp file theo thời gian
Từ đó có thể dễ dàng hơn trong việc tìm binary bị thay đổi
2.3 Tìm kiếm và thu thập phiên bản trước khi cập nhật của file binary được vá
Để có được file binary trước khi vá, chúng ta cần cài đặt một máy ảo chạy hệ điều hành tương ứng với bản vá đang phân tích. Tốt nhất nên được cài tất cả các bản vá trừ bản vá đang phân tích để hạn chế tối đa thông tin dư thừa. Có thể thực hiện bằng cách cập nhật tất cả các bản vá, sau đó thực hiện gỡ bỏ KB tương ứng với bản vá đang phân tích
Sau đó, tùy thuộc thông tin thu thập được về lỗ hổng ở trên sẽ tìm kiếm binary tương ứng:
- Đối với ứng dụng có thể dễ dàng tìm kiếm file thực thi thông qua chức năng search của Windows.
- Đối với các service có thể thực hiện như sau:
- Đảm bảo service đang cần tìm đã được enable trên máy ảo
- Mở cửa sổ services.msc
- Tìm đến service tương ứng và chọn Properties
- Trong trường hợp service chạy trực tiếp từ file exe, sẽ có tên file thực thi trong phần Path to executable
Hình 8: Ví dụ về file thực thi của CNG Key Isolation service
- Trong trường hợp file thực thi là svchost.exe, có nghĩa là service được thực thi từ một file dll.
Hình 9: Ví dụ service có file thực thi là svchost.exe
- Cần mở Registry Editor để xem thông tin về thanh ghi của service Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<service_name>
Hình 10: Thông tin service TSGateway trong registry
- Bên cạnh đó có thể kết hợp với việc sử dụng 02 công cụ rất mạnh mẽ trong bộ công cụ Sysinternals của Microsoft là “Process Explorer” và “Process Monitor” để tìm thêm thông tin về các file được sử dụng bởi một ứng dụng hay dịch vụ đang hoạt dộng
2.4 So sánh hai file binary và tìm điểm khác nhau
Sau khi đã có hai phiên bản binary trước và sau khi cập nhật có thể bắt đầu so sánh để tìm điểm khác nhau. Có rất nhiều phương pháp để thực hiện bước này, tuy nhiên, trong phạm vi bài viết sẽ chỉ đề cập đến việc sử dụng Diaphora, một plugin miễn phí của IDA pro.
Đôi nét về Diaphora ( xuất phát từ tiếng Đức của từ different có nghĩa là khác nhau), đây là một plugin của IDA pro, trước phiên bản IDA 6.8 nó được tích hợp ngay trong phần mềm. Tuy nhiên, về sau đã không có sẵn mà cần download về từ git https://github.com/joxeankoret/diaphora/releases/tag/3.2.1 và chạy như một script file. Diaphora 3.2.1 được viết bằng ngôn ngữ python và hoạt động tốt với python 3.
Để sử dụng iaphora, cần load lần lượt hai file binary vào IDA và chạy plugin này từ “File ->Script file”. Sau đó file sqlite tương ứng sẽ được sinh ra và so khớp với nhau.
Sau quá trình so khớp kết quả sẽ bao gồm các cửa sổ:
- Best match: các hàm hoàn toàn giống nhau
- Partial match: các hàm giống nhau về cơ bản, tên giống nhau và cấu trúc các block cũng gần như tương đồng. Đây thường là phần nên được quan tậm đầu tiên khi thực hiện so khớp hai file binary
- Unreliable match: các hàm có thể giống nhau nhưng không chắc chắn, có một số điểm chung, điểm chung này có thể được thể hiện ở phần Description.
- Unmatched in primary: các hàm có trong file đầu tiên mà không có trong file thứ hai
- Unmatched in secondary: các hàm có trong file thứ hai mà không có trong file đầu tiên.
Tại đây nên xem xét các hàm trong phần partial matches, kết hợp với thông tin từ bước đầu tiên để rà soát lỗi. Có thể chuột phải vào hàm quan tâm và chọn:
- Diff assembly: so sánh khác nhau trong mã máy
- Diff pseudo-code: so sánh giả mã
- Diff assembly in graph: so sánh khác nhau trong mã máy dưới dạng biểu đồ
Chú ý: đối với các binary có symbol file, việc so khớp sẽ dễ dàng hơn rất nhiều, do các symbol dễ match hơn các tên hàm random. Trong trường hợp phân tích các bản patch của Windows việc này tương đối đơn giản, do Microsoft có cung cấp public file pdb chứa symbol của các file hệ thống và có thể dễ dàng lấy về thực hiện debug. Tính năng load pbd file đã được tích hợp sẵn trong IDA pro (chọn download pdb file khi load file lên IDA) nên kết quả so khớp là tương đối tối ưu.
Tới đây chắc các bạn đã có cái nhìn rõ hơn về cách thức phân tích một bản vá để tìm ra lỗ hổng thông qua các công cụ thông dụng. Trong bài viết tiếp theo hãy cũng mình làm rõ hơn các bước thực hiện thông qua một usecase thực tế nhé. Xin chào tạm biệt và hẹn gặp lại các bạn.