Thời gian qua xảy ra nhiều trường hợp người sử dụng mạng xã hội Facebook vô tình tự làm mất tài khoản. Có nhiều nguyên nhân, nhưng trong đó đóng góp không nhỏ là do người dùng đã làm theo các chỉ dẫn không rõ nguồn gốc trên Internet về cách sửa file host, thiết lập proxy cho trình duyệt… để đăng nhập được vào Facebook. Hacker lợi dụng hành động này để lấy cắp thông tin tài khoản của họ.

Hình 1: Truy cập Facebook an toàn trên Google Chrome

Hình 1 bên trên minh họa trường hợp người dùng đăng nhập Facebook an toàn. Bạn hãy chú ý tới chữ https (màu xanh) ở cạnh địa chỉ trên trình duyệt. Biểu tượng này cho biết trình duyệt Chrome đã kiểm tra và xác thực rằng bạn đang vào trang Facebook hợp lệ. Giao thức https được dùng hiệu quả trong việc đảm bảo an toàn cho thông tin trao đổi trên Internet.

Tuy nhiên, sau khi sửa file host hoặc thiết lập proxy, người dùng rất có thể sẽ gặp cảnh báo nguy hiểm của trình duyệt khi đăng nhập không an toàn vào Facebook như hình dưới đây:

Hình 2: Cảnh báo nguy hiểm của Google Chrome khi người dùng truy cập không an toàn Facebook

Nhiều người dùng không để ý tới cảnh báo này, vẫn nhấn vào “Proceed anyway” để tiếp tục vào “Facebook”. Họ không thể ngờ rằng có thể đang bị hacker tấn công. Toàn bộ thông tin về quá trình đăng nhập của người dùng có khả năng bị đánh cắp và sử dụng cho những mục đích xấu. Cần phải nhấn mạnh một điều là: ngay cả trong trường hợp không có cảnh báo nào từ phía trình duyệt thì cũng không có nghĩa là bạn đã an toàn.

Để bảo vệ mình trước các hình thức tấn công trên, Bkav khuyến cáo người sử dụng không nên làm theo các hướng dẫn không rõ nguồn gốc trên mạng Internet. Người sử dụng cũng cần cẩn trọng để ý phần địa chỉ website trên trình duyệt, trước khi gõ mật khẩu.

Lê Đức Anh, Nguyễn Thế Anh – Bkav Security

Thời gian gần đây, một số lượng lớn người sử dụng thư điện tử nhận được email giả mạo Paypal với nội dung: “Please Update your Paypal information”. Email này thông báo Paypal đã áp dụng một số biện pháp bảo mật mới và yêu cầu người dùng click vào link update thêm thông tin để bảo vệ tài khoản của mình. Thoạt nhìn, email này trông giống những email từ Paypal nên người dùng không đề cao cảnh giác sẽ dễ bị mắc lừa.

Nội dung email lừa đảo

Khi người dùng click vào link update thông tin tài khoản, họ sẽ bị chuyển đến một website giả mạo Paypal, tất nhiên rồi! Nhưng, không dễ để nhận ra điều này. Nếu người sử dụng điền đầy đủ thông tin cá nhân theo các yêu cầu tại đây và nhấn nút gửi, kẻ lừa đảo có thể lấy được toàn bộ thông tin về tài khoản của người sử dụng.

Giao diện website giả mạo Paypal

Bạn nên làm gì nếu đã lỡ cung cấp các thông tin tài khoản Paypal của mình?

1. Liên hệ ngay với Paypal, nếu bạn liên hệ càng sớm, việc bảo vệ tài khoản của bạn càng dễ dàng hơn. Xin nhớ là hãy liên hệ trực tiếp với Paypal, chứ không qua địa chỉ của email yêu cầu update tài khoản mà bạn nhận được, hoặc bạn có thể gọi điện thoại tới bộ phận dịch vụ khách hàng của Paypal để được hỗ trợ.

2. Thay đổi ngay mật khẩu của tất cả các tài khoản trực tuyến. Nhiều người sử dụng chung một mật khẩu cho nhiều tài khoản khác nhau, vì thế bạn nên thay đổi mật khẩu của những tài khoản có liên quan đến thẻ tín dụng, hay thông tin cá nhân. Nếu nghi ngờ đã có ai đó truy cập vào tài khoản email của mình, ngay lập tức bạn phải thay đổi mật khẩu. Bạn cũng cần xem lại bảng kê chi tiêu tín dụng, yêu cầu công ty cung cấp dịch vụ thẻ và ngân hàng cung cấp bảng kê hàng tháng và thông báo những khoản chi không rõ ràng, các yêu cầu hay hoạt động mà bạn không yêu cầu.

3. Kiểm tra chắc chắn rằng bạn đã sử dụng những sản phẩm bảo mật cập nhật nhất, như các dịch vụ chống thư rác và thư giả mạo, bộ lọc thư rác ở chương trình duyệt web và các dịch vụ khác giúp cảnh báo đồng thời bảo vệ bạn trước các nguy cơ tấn công bằng thư lừa đảo.

4. Cuối cùng, hãy cảnh giác khi nhận được những email lạ, đặc biệt là những email yêu cầu cung cấp thông tin tài khoản, và hãy chắc chắn rằng đường link trong email bạn nhận được dẫn đến website của nhà cung cấp dịch vụ.

 Tống Văn Toàn – Bkav Security

Lần này, kẻ xấu sử dụng chiêu thức giả mạo Youtube Plugin cho trình duyệt Firefox, Chrome nhằm lừa người dùng truy cập vào các website lừa đảo, website chứa mã độc…

Người sử dụng Facebook cần hết sức cảnh giác khi nhận được các đường link lạ xuất hiện trên “Tường” với nội dung như sau: “Look! Hahaha! HOT Girl Show Her Breast on Live TV” “you look so cute”, “Aaaahaha, hey is this your ex?”, “click here to see paRiS Hilton!!”….

Link độc được phát tán qua mạng xã hội Facebook

Khi bấm vào các đường link này, người sử dụng sẽ được dẫn tới website lừa đảo với nội dung khiến họ có thể tin rằng sẽ phải cài Plugin mới có thể xem được clip.

Một khi plugin giả mạo này được cài đặt, lập tức tài khoản Facebook của bạn sẽ trở thành nguồn phát tán link độc hại lên “Tường” của bạn bè. Và thủ phạm, tất nhiên chính là Plugin bạn vừa cài.

Như vậy, mặc dù sử dụng chiêu thức hoàn toàn mới nhưng vẫn dựa trên kịch bản cũ là phát tán link độc qua các mạng xã hội như Facebook. Điều này cho thấy sự theo dõi, bám sát và thay đổi thủ đoạn lừa đảo liên tục của kẻ xấu.

Quay trở lại quá khứ một chút, nếu từng đọc một số bài blog trước đây về chủ đề phát tán mã độc qua Facebook, bạn sẽ dễ dàng nhận thấy quá trình “phát triển” thủ đoạn lừa đảo của hacker. Đầu tiên là đăng ký tên miền gần giống Facebook.com hòng rình rập những trường hợp người dùng gõ nhầm, tiếp đến là dẫn dụ người sử dụng chạy một đoạn javascript trên thanh địa chỉ của trình duyệt.Và gần đây nhất, kẻ xấu lừa người sử dụng cài đặt Youtube Plugin giả mạo cho Firefox hoặc Chrome. Hacker sẽ không ngừng tung ra các chiêu bài mới khi người sử dụng đã biết và cảnh giác hơn với những thủ đoạn cũ. Như vậy, cách tốt nhất để tránh rơi vào bẫy của hacker là nâng cao cảnh giác với những đường link chia sẻ nhận được, đồng thời cài đặt phần mềm diệt virus đủ mạnh để bảo vệ máy tính của bạn toàn diện hơn.

Nguyễn Công Cường – Bkav R&D

Đầ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