Đầu tiên, tôi cảm ơn Dan Rosenberg vì những thông tin thú vị về cơ chế ngăn chặn ROP trên Windows 8 mà anh ấy đã chia sẻ. Đồng thời, tôi đánh giá cao nỗ lực của Nguyễn Hồng Sơn, anh chàng đồng nghiệp trẻ tuổi của tôi, trong việc cụ thể hóa phương pháp vượt qua cơ chế ngăn chặn ROP của Dan thành một chuỗi ROP chung (có thể chạy trên nhiều hệ điều hành khác nhau). Tuy nhiên, dễ nhận thấy có hai nhược điểm tồn tại trong chuỗi ROP đó:

• Thứ nhất, nó yêu cầu phải có EAX trỏ đến một giá trị stack (ngăn xếp) hợp lệ trước khi vào chuỗi ROP. Nếu không có được điều này, chuỗi ROP sẽ không sử dụng được. Thực tế, có nhiều trường hợp ta không thể có thanh ghi nào lưu giữ lại giá trị của ESP (chẳng hạn các trường hợp thực hiện “pivot stack” – chỉnh lại stack trước khi vào chuỗi ROP – bằng lệnh MOV ESP,R32 chứ không phải XCHG). Thậm chí ngay cả khi có thanh ghi nào đó khác EAX lưu trữ giá trị hợp lệ của ESP, thì việc chuyển nó về EAX bằng các “ROP gadget” (địa chỉ ROP) không phải lúc nào cũng dễ dàng. Như vậy, để có một chuỗi ROP chung có thể dùng phổ biến cho Windows 8, nhược điểm này cần phải được khắc phục.
• Hạn chế nữa nằm ở độ dài của chuỗi ROP. Trong khi hiện nay, các chuỗi ROP chung phổ biến trên Windows 7 rất ngắn (18 dwords với  chuỗi ROP mới của Corelanc0d3r, và 22 dwords với chuỗi ROP của Sayonara), thì chuỗi ROP này lại chứa khoảng 100 dwords. Anh bạn của tôi hay bất cứ ai theo phương pháp của Dan có thể sẽ làm cho chuỗi ROP ngắn hơn được chút nữa nếu chú ý tối ưu trong việc sử dụng các “ROP gadget”, nhưng nó vẫn sẽ rất dài nếu đem so với những chuỗi ROP trên Windows 7, tôi tin vậy. Vì đôi khi mã khai thác của chúng ta gặp phải điều kiện ngặt nghèo về kích thước, nên độ dài của chuỗi ROP cũng là một vấn đề đáng quan tâm, giống vấn đề độ dài của shellcode vậy. Thêm nữa, tôi vẫn cho rằng một chuỗi ROP ngắn gọn trông sẽ đẹp đẽ và hoàn hảo hơn.

Tập trung nghĩ về cơ chế bảo vệ của Windows 8, tôi đã tạo ra một chuỗi ROP chung mới theo phương pháp của riêng mình. Và quan trọng là nó khắc phục được hai nhược điểm nêu trên.

chuỗi ROP của tôi cũng được xây dựng dựa trên thư viện msvcr71.dll như các chuỗi ROP chung đã nhắc tới, nó gồm 3 bước sau :

Bước 1: Xác định vùng stack hợp lệ

Bước này sẽ làm cho EAX trỏ đến một vùng stack hợp lệ đối với cách kiểm tra hiện tại của Windows 8. Qua đó, giải quyết được vấn đề đầu tiên mà tôi nói ở trên.

Nhắc lại tư tưởng của Dan Rosenberg trong ví dụ của anh ấy. Anh ấy sẽ khôi phục lại stack cũ (vốn đã bị “pivot stack” trước đó) để qua mặt cơ chế kiểm tra. Đây là vùng stack chuẩn được sử dụng trước đó một cách bình thường, nên hiển nhiên là hợp lệ. Vì thế đây là giải pháp tốt nếu chúng ta có thanh ghi nào đó sao lưu stack cũ để sau đó khôi phục lại. Tuy nhiên, ở đây, tôi đang bàn đến trường hợp không có thanh ghi nào thỏa mãn yêu cần của chúng ta.

Giờ hãy nhìn lại cơ chế kiểm tra của Windows: giá trị của ESP sẽ là hợp lệ nếu nằm trong khoảng “stack min” (FS:[8] ) và “stack max” (FS:[4]). Vậy sao ta không lấy luôn “stack min” để sử dụng ? Rõ ràng là nó sẽ vượt qua được cách kiểm tra kia, và nếu có được nó, tôi sẽ có một vùng stack rộng lớn, hợp lệ để sử dụng. Vậy tôi sẽ đi xác định giá trị này.

Việc tìm kiếm trên msvcr71.dll những “ROP gadget” thao tác trực tiếp đến FS:[8] không đem lại kết quả gì. Điều này là dễ hiểu vì các giá trị StackBase và StackTop thường được truy xuất từ cấu trúc TEB. Do đó, tôi đi tìm các gadget tham chiếu đến &(TEB) ( FS:[18] ), và thu được một kết quả duy nhất tại địa chỉ 0×7c34d38f :

Thoạt nhìn, chuỗi lệnh này có vẻ không phù hợp để trở thành một “ROP gadget” vì có quá nhiều lệnh tính toán và lệnh jump trước lệnh RETN. Tuy nhiên đây là kết quả duy nhất tôi tìm được trên msvcr71.dll có tham chiếu đến FS:[18], nên tôi đã phân tích kỹ nó. Dường như đoạn mã này cũng đang kiểm tra EBX có thuộc khoảng giữa StackBase và StackTop không. May mắn thay, tôi nhận ra rằng, nếu sắp xếp các thanh ghi hợp lý, tôi có thể lưu được giá trị của FS:[18] (hoặc chính StackBase) vào nơi tôi muốn ( [EBP+8] hoặc [EBP-4] ), rồi quay trở lại chuỗi ROP một cách tốt đẹp. Và đây là Bước 1 với 13 dwords:

Bước 2 : Sao chép đoạn ROP cho Windows 7 lên vùng stack hợp lệ, so đó trở lại chuỗi ROP

Ở đây, tôi sẽ giải quyết vấn đề độ dài của chuỗi ROP. Sở dĩ có sự chêch lệch đáng kể giữa chuỗi ROP theo phương pháp của Dan so với các chuỗi ROP cho Win7 hiện có là vì nó phải thực hiện nhiều hơn các việc tính toán, di chuyển dữ liệu giữa các thanh ghi, và ghi dữ liệu lên bộ nhớ. Sự hạn chế của các ROP gadget thường làm các công việc trên trở lên phức tạp hơn. Trong khi với các chuỗi ROP cho Win7 việc tính toán đơn giản hơn, lại có thể tận dụng một cách hợp lý PUSHAD để đẩy dữ liệu lên stack, rồi thực hiện lời gọi hàm.

Bởi vì cơ chế kiểm tra stack của Windows 8 chỉ áp dụng cho các hàm có liên quan đến việc cấp quyền cho vùng nhớ (như VirtualProtect), nên ta hoàn toàn có thể sắp xếp và gọi một hàm sao chép dữ liệu (memcpy chẳng hạn) mà chưa cần bận tâm đến tính hợp lệ của ESP.

Vậy bước này, tôi sẽ tận dụng lệnh PUSHAD (như phong cách của các chuỗi ROP chung cho Win7) để có một đoạn ROP ngắn thực hiện sao chép toàn bộ Bước 3 (chính là một chuỗi ROP cho Win7) cùng shellcode lên vùng stack hợp lệ ta đã có (được trỏ bởi EAX), rồi trở về đó.

Bước 2 này gồm 8 dwords :

Bước 3: Một chuỗi ROP bình thường trên Windows 7

Toàn bộ phần này, và shellcode theo sau nó, sẽ được ghi lên vùng stack hợp lệ, nên việc thực thi nó trên Windows 8 lúc này không khác gì trên các phiên bản từ Windows 7 trở về trước.

Vì thế, cái ta cần ở đây chỉ là một chuỗi ROP có thể chạy mượt mà trên Windows 7. Tôi đã tham khảo chuỗi ROP nhỏ nhất của Corelanc0d3r (bao gồm 18 dwords và được cập nhật vào tháng 10/2011) rồi viết một phiên bản khác chỉ với 14 dwords (thật tuyệt, phải không?). Chuỗi ROP “vạn năng” đó đây:

Kết luận

• Kết hợp 3 bước trên, ta sẽ có một chuỗi ROP “vạn năng” chạy ngon lành trên Windows 8, với độ dài 35 dwords (13 + 8 + 14).
• Trong trường hợp đã có EAX trỏ đến một vùng stack hợp lệ, bỏ qua Bước 1, chuỗi ROP của chúng ta chỉ cần 22 dwords (8+14) là hoạt động được trên Windows 8.
• Nếu chỉ dùng cho các phiên bản Windows 7 trở lại, Bước 3 của tôi với 14 dwords sẽ là một chuỗi ROP chung vô cùng ngắn mà hoàn chỉnh.

File đính kèm là demo khai thác lỗi CVE-2011-0065, đã thử nghiệm với Firefox 3.16 trên Windows 7 và Windows 8.

Không lâu sau khi Microsoft chính thức giới thiệu bản Developer Preview của Windows 8, tôi đã đọc được bài viết về cơ chế ngăn chặn ROP (Return Oriented Programming) trên Windows 8 và cách để vượt qua nó. Theo đó, tôi đã thực nghiệm và viết một chuỗi ROP có thể dùng chung cho các mã khai thác dùng kỹ thuật ROP trên Windows 8.

Để các bạn có thể hình dung rõ hơn, tôi sẽ miêu tả thêm một chút về cơ chế chống lại phương thức khai thác ROP của Windows 8. Như chúng ta đã biết, khi viết mã khai thác ROP, ta thường phải sắp xếp một chuỗi lệnh để thực thi các hàm có thao tác với Virtual Memory như VirtualProtect, VirtualAlloc… Chính vì thế, Windows 8 sẽ thực hiện kiểm tra ngăn xếp (stack) trước khi gọi các hàm này bằng cách so sánh thanh ghi ESP. Nếu ESP nằm giữa StackBase (FS:[8]) và StackTop (FS:[4]), khi đó địa chỉ stack là hợp lệ và hàm được thực thi. Ngược lại stack là không hợp lệ và quá trình gọi hàm sẽ không được thực hiện. Tuy nhiên, thực tế là cơ chế này không có tác dụng với những lỗi tràn bộ nhớ đệm trên stack (stack buffer overflow), và cũng không khó để vượt qua đối với nhiều lỗi khác. Giải pháp ở đây là chúng ta lưu lại địa chỉ stack (thanh ghi ESP) và phục hồi lại trước khi gọi hàm.

Tôi đã thực nghiệm phương pháp trên với lỗi CVE-2011-0065 của Firefox. Lỗi này đã có mã khai thác trên Windows 7 , trong đó có sử dụng chuỗi ROP cho Windows 7 của Corelan . Vì Windows 8 được bổ sung thêm cơ chế bảo vệ mới (như đã nêu trên) nên chuỗi ROP này (cũng như các chuỗi ROP khác đã được viết và sử dụng phổ biến trên Windows 7 trước đây) không có tác dụng trên hệ điều hành mới này của Microsoft.

Từ đây, như đã nói từ đầu, tôi đã xây dựng một chuỗi ROP mới có thể vượt qua cơ chế bảo vệ trên Windows 8 và tiện dụng cho những lần khai thác sau này.

Chuỗi ROP được xây dựng dựa trên:

-         Sử dụng module msvcr71.dll – v7.10.3052.4

-         Được gắn với: JRE (Java) 1.6

-         Load với trình duyệt.

-         Làm việc được trên Windows XP/Vista/Win7/Win8/2003/2008.

-         Module không bị ASLR.

-         Sử dụng hàm kernel32.VirtualProtect.

-         Địa chỉ cơ sở: 0×7c340000.

-         Kích thước 0×56000.

Tất nhiên bạn chỉ cần sử dụng chuỗi ROP này thay cho cái cũ, khi mà việc thay đổi địa chỉ stack là bắt buộc cho mã khai thác ROP của bạn. Chuỗi ROP của tôi có thể hoạt động với điều kiện EAX đang trỏ đến một vùng stack hợp lệ nào đó (tức thuộc khoảng giữa FS:[4] và FS:[8]). Vì vậy để sử dụng nó, trước khi vào chuỗi ROP, bạn phải có thanh ghi hoặc vùng nhớ nào đó lưu giữ một địa chỉ stack hợp lệ (thường chính là địa chỉ stack cũ trước khi thay đổi). Sau đó chuyển nó vào EAX và bắt đầu chuỗi ROP.

Chuỗi ROP đã được kiểm thử và chạy ổn định trên Windows 7, Windows 8 và một vài hệ điều hành khác.

Nguyễn Hồng Sơn – Bkav Security

Email là một trong những con đường phát tán mã độc khá hiệu quả, và cho tới nay vẫn được kẻ xấu sử dụng rộng rãi. Đã có những thời, email giúp kẻ xấu phát tán mã độc lên hàng triệu máy tính trên toàn thế giới, chẳng hạn như thời của MyDoom, Brontok…Tuy nhiên, qua thời gian, với nỗ lực cảnh báo của các hãng an ninh, phương thức đính kèm virus vào email không còn đạt hiệu quả như trước. Người dùng đã cảnh giác hơn với những email có đính kèm file không rõ nguồn gốc, để ý hơn tới phần mở rộng của file cho dù file đó có icon của các định dạng quen thuộc như .doc, .pdf, .jpg,…

Thực tế này đã buộc kẻ xấu phải tìm ra những phương thức mới để phát tán virus. Một trong số đó là lợi dụng kỹ thuật RLO (Right to Left Override – Đảo ngược Phải sang Trái) trong cách đặt tên file để giấu phần mở rộng của file, khiến người sử dụng nhầm tưởng đó là các file văn bản (.doc, .pdf, …) hay file ảnh (.jpg, .bmp, …).

Vậy bản chất của hiện tượng này là gì? Đối với các ngôn ngữ đọc từ phải sang trái (như tiếng Ả Rập…), Microsoft hỗ trợ việc hiển thị ngược xâu ký tự bằng cách thêm mã unicode U+202E vào trước xâu đó. Ví dụ, sau khi thêm mã U+202E vào trước kí tự “c” của file có tên XXXcod.exe, Windows sẽ hiển thị tên file thành XXXexe.doc. Và nếu kẻ xấu giả mạo cả icon file .doc nữa thì liệu bạn có mảy may nghi ngờ hay lập tức mở file ra xem?

Đây thực chất là 1 file virus

Có thể thấy đây là kỹ thuật khá tinh vi, và nếu không thực sự chú ý thì kể cả các chuyên gia cũng có thể bị lừa bởi những dòng virus này. Để không bị rơi vào bẫy của kẻ xấu, người sử dụng nên kiểm tra thuộc tính của file trước khi quyết định có chạy file hay không. Nếu file có định dạng của file thực thi (.exe, .scr, .pif,…) nhưng lại được hiển thị với phần mở rộng của một dịnh dạng file khác, đó chính là virus.

Đơn giản hơn, bạn có thể chạy các file nhận được trong Sandbox để được an toàn. Tốt hơn hết, bạn nên cài đặt 1 phần mềm diệt virus có bản quyền đủ mạnh để bảo vệ máy tính của bạn một cách toàn diện.

Phạm Tuấn Vũ – Bkav R&D

Thời gian gần đây, người dùng máy tính tại rất nhiều cơ quan, doanh nghiệp “bỗng nhiên” không thể truy cập vào được bất kỳ website nào, thay vào đó là một thông báo yêu cầu cập nhật trình duyệt.

Khi bấm nút “Browser update”, người sử dụng sẽ được yêu cầu tải về 1 chương trình về để “cập nhật” trình duyệt của mình.

Tuy nhiên, đó thực chất là một loại virus.

Những mạng nội bộ có hiện tượng như trên đều có ít nhất 1 máy tính bị nhiễm virus W32. Gatpaz.Worm có khả năng giả mạo DHCP Server để gửi các gói tin cấu hình đến các máy trạm nhằm thay thế địa chỉ DNS của các máy đó bằng địa chỉ server của hacker. Khi đó, khi người sử dụng truy cập mạng sẽ được chuyển hướng đến 1 website lừa đảo do hacker thiết lập từ trước.

Tình trạng này chỉ xảy đến đối với những mạng doanh nghiệp sử dụng phương pháp cấp phát động IP thông qua DHCP Server.

Trong mô hình này, mỗi mạng sẽ được thiết lập 1 DHCP Server làm nhiệm vụ quản lý và cấp phát IP cho các máy trong mạng đó. Khi máy bất kỳ cần 1 địa chỉ IP để truy cập mạng, nó sẽ gửi đi thông điệp DHCPDISCOVER ra toàn mạng. Sau khi nhận được thông điệp này, DHCP Server sẽ xử lý và gửi trả lại địa chỉ IP và một số thông tin được cấp phát cho máy đó. Quá trình gửi thông điệp chính là “lỗ hổng” trong mô hình này giúp hacker, một khi đã cài được Gatpaz vào 1 máy tính bất kỳ trong mạng, sẽ tạo được 1 DHCP Server giả mạo. Ngoài việc thiết lập địa chỉ IP cho các máy trạm, DHCP Server giả mạo còn thiết lập để địa chỉ DNS Server của máy đó trỏ về DNS Server của hacker, khi đó hacker sẽ toàn quyền kiểm soát hoạt động truy cập các website của người sử dụng.

Để giải quyết triệt để những trường hợp virus phá hoại mạng máy tính của các các doanh nghiệp như trên, Bkav khuyến cáo các công ty, tổ chức nên sử dụng một giải pháp diệt virus tổng thể dành cho doanh nghiệp.

Ngô Anh Huy – Bkav R&D

Một thời gian sau khi thu thập được một loạt các thư điện tử giả mạo FBI để phát tán W32.FakeFBIVariantovLT.Trojan, chúng tôi tiếp tục phát hiện một chiến dịch phát tán phần mềm lừa đảo mới, lần này là thông qua email giả mạo cảnh sát New York. Bức thư được gửi từ địa chỉ email có tên miền là nyc.gov, với nội dung thông báo về việc người nhận đã lái xe quá tốc độ vào lúc 7h25 sáng ngày 5/7.

“Để tự bào chữa, hãy in phiếu phạt được đính kèm và gửi tới tòa án thành phố, Po Box 117, Chatam Hall.”

Người nhận thậm chí có thể đã không có mặt tại New York vào thời điểm được nhắc đến trong email, nhưng vì muốn bào chữa cho mình, hoặc chỉ vì tò mò, họ vẫn mở tệp tin đính kèm này. Khi được giải nén, tệp tin có định dạng của file pdf. Đây thực chất là một trojan. Khi được chạy lên, trojan này sẽ kết nối đến nhiều địa chỉ khác nhau và tải về nhiều phần mềm độc hại, làm giảm mức độ an ninh của hệ thống.

Một trong những phần mềm độc hại này được Bkav nhận diện là W32.FakeHddRepair.Trojan.

Giống như W32.FakeFBIVariantovLT.Trojan, W32.FakeHddRepair.Trojan liên tục hiển thị các thông báo về lỗi ổ cứng:

Chương trình HDD Repair giả mạo được bật lên, tiến hành quét và cảnh báo các lỗi của ổ cứng. Để sửa được các lỗi này, người sử dụng cần phải bỏ ra một khoản tiền để kích hoạt phần mềm.

Kịch bản lừa đảo này đã trở nên tương đối quen thuộc: cảnh báo người dùng về những lỗi nghiêm trọng của hệ thống mà trên thực tế là không có thật, đưa ra một giao diện chương trình sửa các lỗi đó, với điều kiện phải trả tiền mua phần mềm. Tuy nhiên, nếu máy tính có chứa những dữ liệu quan trọng, sẽ không ít người chấp nhận bỏ ra một khoản tiền để “lấy lại” những dữ liệu đó.

Bkav khuyến cáo người sử dụng cần luôn cảnh giác trước các bức thư điện tử có tệp tin đính kèm. Đồng thời, để bảo vệ máy tính hữu hiệu và toàn diện nhất, bạn nên cài đặt một phần mềm diệt virus đủ mạnh, có bản quyền để được cập nhật mẫu nhận diện virus mới thường xuyên.

Nguyễn Hùng Phú – Bkav R&D