Thông tin chung

Trong tháng 2, Adobe đã đưa ra bản tin an ninh lần thứ 7 trong năm 2010. Đợt vá lỗi lần này khắc phục 2 lỗ hổng trong các sản phẩm Adobe Reader và Acrobat phiên bản 9.3.0 và 8.2.0 trở về trước. Trong đó, có một lỗ hổng rất nguy hiểm (CVE-2010-0188) cho phép kẻ xấu có thể tấn công, chiếm quyền điều khiển máy tính từ xa. Rất may, tại thời điểm hãng công bố bản vá này, mã khai thác cũng như thông tin chi tiết về lỗ hổng vẫn chưa bị tiết lộ.

Tuy nhiên, trong những ngày đầu và giữa tháng 3, một loạt mã độc gắn trong các file PDF khai thác lỗ hổng nói trên đã được phát hiện. Mã khai thác cũng đã được phát tán rộng rãi trên Internet.

Phân tích kỹ thuật

Nguyên nhân dẫn đến lỗ hổng nằm ở thư viện Libtiff, một thư viện mã nguồn mở được sử dụng trong Adobe Reader và Acrobat để xử lý định dạng ảnh TIFF (Tagged Image File Format). Điều đáng nói là lỗ hổng này cũng chính là một trong số các lỗ hổng của Libtiff đã được phát hiện từ năm 2006 (CVE-2006-3459).

Lỗi này xuất phát từ việc sử dụng hàm memcpy() khi số byte được sao chép vượt quá kích thước vùng nhớ đích, dẫn đến tràn ngăn xếp (stack) và địa chỉ trả về bị thay đổi.

Cách đơn giản để khai thác lỗ hổng này là chèn mã JavaScript vào file PDF và sử dụng kỹ thuật heap spray. Cụ thể, sau khi tạo ra vùng nhớ heap lớn chứa shellcode, hacker chỉ cần ghi tràn lên stack địa chỉ trỏ tới heap, chẳng hạn 0×0c0c0c0c, để khi chương trình trỏ về địa chỉ này, shellcode sẽ được thực thi. Tuy nhiên, hình thức tấn công này không thể thực hiện trong trường hợp tính năng Adobe Javascript bị tắt.

Hacker có thể áp dụng một cách hiệu quả hơn, đã được sử dụng trong mã khai thác nhắc đến ở trên. Theo đó, các dữ liệu ghi tràn trên stack được chuẩn bị khéo léo, để khi chương trình tham chiếu đến, các byte dữ liệu sẽ được sắp xếp tạo thành một đoạn mã có nhiệm vụ truy tìm, sao chép phần shellcode đang nằm ở đâu đó trên bộ nhớ rồi thực thi shellcode này.

Sau lời gọi hàm memcpy(), dữ liệu đã chuẩn bị trong file đầu vào được ghi tràn lên stack.

Giải pháp

Trong thực tế, đây chính là 2 phương pháp đã được các hacker sử dụng để phát tán mã độc. Các mã khai thác này đều chạy thành công trên Windows XP SP2 và Windows XP SP3. Đáng lưu ý, nguy cơ không chỉ nằm trực tiếp ở ứng dụng Adobe Reader và Acrobat mà còn trên Adobe Plugin dành cho các trình duyệt web. Điều đó có nghĩa mã độc sẽ dễ dàng được thực thi nếu người dùng truy nhập một đường link dẫn đến file PDF độc. Đây cũng chính là yếu tố khiến lỗ hổng này được đánh giá rất nguy hiểm và là mục tiêu tấn công ưa thích của các hacker trong thời gian gần đây.

Nhà sản xuất đã đưa ra bản vá cho lỗ hổng này từ tháng 2, người dùng cần nhanh chóng cập nhật Adobe Reader phiên bản 8.2.1 hoặc 9.3.1 để đảm bảo an ninh thông tin cho máy tính của mình.

Bkis Security

Cứ mỗi dịp mùa xuân, vào chủ nhật thứ 2 của Tháng 3, tại nhiều quốc gia trên thế giới, người ta chỉnh đồng hồ tiến lên một giờ. Do ban ngày, ánh sáng xuất hiện sớm hơn và tắt muộn hơn vào buổi tối, vì vậy, việc chỉnh đồng hồ tiến lên một giờ sẽ giúp chúng ta tiết kiệm được năng lượng do thời điểm bật đèn buổi tối sẽ lùi lại. Đến mùa thu, đồng hồ được chỉnh lùi lại một tiếng.

Năm 2010, thời gian bắt đầu chỉnh đồng hồ là từ 2:00 A.M ngày 14/03.

Dự đoán được việc người sử dụng sẽ tìm kiếm các thông tin liên quan tới thời gian tiết kiệm ánh sáng ban ngày (Daylight saving time) của năm nay để điều chỉnh đồng hồ cho hợp lý, kẻ xấu đã lợi dụng kỹ thuật Blackhat SEO để chèn các đường link dẫn tới website độc hại vào các kết quả tìm kiếm.

Cụ thể, nếu bạn tìm kiếm với từ khóa “Day Light Savings 2010″, bạn có thể bị dẫn tới các website cung cấp các phần mềm diệt virus giả.

Nếu bấm vào các kết quả tìm kiếm, có thể người sử dụng sẽ bị dẫn tới các website có giao diện giả mạo Windows và cảnh báo về virus.

Giả mạo Windows Vista

Giả mạo Windows XP

Bạn có lo lắng không khi gặp những cảnh báo virus này ? Nếu không cẩn thận, bạn có thể bị lừa và tự mình download các phần mềm diệt virus già về máy tính.

Giao diện download fake AV trên Internet Explorer

Bởi vậy, bạn cần cẩn trọng khi tìm kiếm các thông tin trên Internet. Người sử dụng Bkav có thể hoàn toàn yên tâm khi sử dụng Internet, vì Lab của Bkav liên tục cập nhật và theo dõi các hệ thống phần mềm diệt virus giả này.

Bkis Security

Gần đây, có nhiều bài báo và blog đưa tin về lỗ hổng liên quan đến phím F1. Vậy bản chất của lỗ hổng này là gì?

Theo tìm hiểu của Bkis, có tới hai chứ không phải là một lỗi như vậy. Cả hai lỗi cùng liên quan đến cơ chế xử lý file help của Windows, nhưng khác nhau về bản chất.

Lỗi thứ nhất xuất phát từ cơ chế truyền tham số của hàm MsgBox() trong VBScript. Theo đó, một file help nhất định (.hlp), truyền dưới dạng tham số thứ tư của hàm này, sẽ được mở bởi Windows Help (winhlp32.exe) nếu người dùng ấn phím F1 trên cửa sổ MessageBox.

Lỗ hổng còn lại liên quan đến việc thực thi Windows Html Help (.chm).

• Lỗ hổng VBScript với Windows Help (winhlp32.exe)

Trong các phiên bản Windows trước Vista, winhlp32.exe là chương trình hỗ trợ hiển thị các file help có định dạng .hlp (Các phiên bản Windows từ Vista trở đi không được cài sẵn chương trình này).

File .hlp được tạo ra từ file Help Project (.hpj) và các file văn bản (.rtf – Rich Text Format) và có thể cả nhiều file dữ liệu khác. Trong đó, file .hpj có nhiệm vụ liên kết dữ liệu và quy định cấu trúc của file help được tạo thành.

Macro EF (ExecFile) đặt trong trường [CONFIG] của file project (.hpj) làm chương trình Windows Help, khi chạy file help (.hlp) tương ứng, sẽ mở thêm file khác theo tham số của macro này. Điểm này, về lý thuyết, sẽ hỗ trợ file help liên kết, mở thêm các file bổ trợ khác. Tuy nhiên, do chương trình không kiểm tra định dạng file truyền cho marco EF trước khi đưa vào lời gọi hàm API ShellExecute(), nên winhlp32.exe có thể chạy một file thực thi bất kỳ thông qua hàm ShellExecute(). Như vậy, việc mở một file .hlp luôn khiến Windows Help có thể thực thi thêm lệnh bất kỳ.

Ví dụ về một file .hpj gọi file thực thi calc.exe

Điều này, kết hợp với đặc điểm của hàm MsgBox() trong VBScript, cho phép kẻ xấu có thể thực hiện tấn công máy tính từ xa. Cụ thể, trên một trang web, kẻ tấn công sẽ chèn đoạn mã VBScript có lời gọi hàm MsgBox() với tham số đầu tiên là một thông điệp dụ người dùng ấn phím F1 và tham số thứ tư trỏ đến file help đã được chuẩn bị sẵn. Lúc ấy, nếu người dùng mở trang web này bằng trình duyệt Internet Explorer (IE) và ấn phím F1 khi thấy cửa sổ messagebox hiện ra, Windows Help sẽ được gọi để mở file help (.hlp) truyền theo hàm MsgBox(), qua đó thực thi mã khai thác.

• Lỗ hổng trong mô-đun xử lý .chm

Trong khi định dạng file help cũ (.hlp) được mở bằng chương trình winhlp32.exe thì các file Microsoft Windows Html Help (.chm) lại được xử lý bởi hh.exe.

Cũng giống như .hlp, định dạng .chm được kết hợp bởi nhiều file khác nhau: html (nội dung trợ giúp), .hhc (mục lục), .hhk (index). Lỗi được phát hiện trong quá trình xử lý *.hhc. Cụ thể, hh.exe có thể chạy đoạn JavaScript đặt trong file mục lục này, qua đó thực thi mã bất kỳ.

Ví dụ về nội dung một file mục lục (.hhc) chèn mã JavaScript, đoạn mã này sẽ gọi thực thi file script.vbs

Nội dung file script.vbs chạy calc.exe

Như vậy, một file .chm cũng luôn tiềm ẩn những nguy cơ đe dọa máy tính của người sử dụng. Để khai thác lỗ hổng này từ xa, hacker sẽ lợi dụng một chương trình hỗ trợ .chm nào đó, chẳng hạn notepad.exe, để lừa người dùng ấn phím F1 khi mở file .txt đặt cùng thư mục với file .chm đã được chuẩn bị sẵn. Lúc ấy, file help này sẽ chạy, đồng thời mã độc trong nó cũng được thực thi.

• Giải pháp

Hiện tại, Microsoft vẫn chưa đưa ra bản vá cho hai lỗ hổng này. Vì thế, để đảm bảo an ninh cho máy tính của mình, người dùng cần tránh nhấn phím F1 khi nhận được yêu cầu từ bất cứ website hay một văn bản nào. Đồng thời, chú ý cập nhật bản vá khi nhà sản xuất phát hành.

Bkis Security

Gần đây, một đoạn mã khai thác trình duyệt Mozilla Firefox đã xuất hiện trên mạng Internet. Nếu người dùng mở đoạn mã này (thông qua một website) bằng trình duyệt Firefox phiên bản 3.5 và 3.6, trình duyệt sẽ bị lỗi.

Hình 1 – Đoạn mã bằng php được đưa lên mạng

Đoạn mã trên được viết bằng php. Sau khi được server xử lý, nó sẽ trả lại cho trình duyệt của người dùng một đoạn mã html, đoạn mã này sẽ gây lỗi cho trình duyệt. Theo đoạn mã php trên, văn bản html trình duyệt thu được sẽ có 500 thẻ <marquee> lồng nhau.

Hình 2 – Đoạn mã html được trả lại

Thẻ marquee là một thẻ không thuộc html chuẩn, cho phép hiển thị nội dung html của nó trôi dần sang trái, phải, lên trên hoặc xuống dưới một cách tự động. Do việc hiển thị không theo chuẩn của html (thường ở dạng tĩnh) nên modun xử lý thẻ marquee thường không cùng modun xử lý với các thẻ khác. Cụ thể, trong quá trình phân tích lỗi này, chúng tôi nhận thấy trình duyệt Firefox đã sử dụng modun xul để xử lý thẻ này.

Hình 3

Tiến hành cho Firefox thực thi từ đầu đến cuối dưới sự theo dõi của OllyDbg, bước đầu thấy rằng, lỗi xuất hiện trong modun xul và do stack (ngăn xếp) đã bị đầy, không thể cung cấp thêm bộ nhớ. Nhìn vào hình trên ta thấy, chương trình xảy ra trường hợp ngoại lệ tại lệnh call. Điều này có thể được lý giải như sau: để gọi được lệnh call cần đẩy vào stack địa chỉ của lệnh tiếp theo, tuy nhiên do vùng nhớ được khai báo dành cho stack đã hết nên chương trình xảy ra lỗi.

Vậy điều gì đã làm cho stack của chương trình bị đầy? Chúng tôi đã tiến hành giải mã và thấy rằng, hàm xử lý thẻ marquee được gọi đệ quy khi xử lý nội dung html. Mỗi khi gặp tag mở <marquee>, hàm này sẽ được gọi và hàm chỉ trả lại khi gặp tag đóng </marquee>.

Hình 4 – Các hàm gọi lồng nhau

Theo như hình trên (call stack), ta thấy các hàm được gọi lặp đi lặp lại một cách tuần tự theo từng khối và đều là những hàm chưa trả về, điều này chứng tỏ các hàm đó đang được gọi đệ quy. Để đảm bảo sự chính xác của nhận định này, chúng tôi đã tiến hành giảm số thẻ <marquee> trong mã lỗi và đặt break point tại một trong các vị trí gọi hàm ở bảng trên (0×103EE0A8) thì thấy rằng các hàm chỉ được gọi một số lần hữu hạn và trả về giá trị bình thường. Cụ thể trong trường hợp tại địa chỉ 0×103EE0A8, số lần gọi đúng bằng số thẻ <marquee> đã khai báo và hàm chỉ trả lại giá trị trong lần gọi hàm cuối cùng. Qua quan sát trong quá trình giải mã, chúng tôi đã xác định trong mỗi lần gọi đệ quy tại địa chỉ 0×103EE0A8, một vùng nhớ có độ lớn 0×1980 bytes nằm trên stack đã không được giải phóng. Từ điều này, chúng ta hoàn toàn có thể hiểu được tại sao khi khai báo rất nhiều thẻ <marquee> lồng nhau thì stack của chương trình bị đầy, dẫn đến hết khả năng đáp ứng.

Hàm đệ quy như một con dao hai lưỡi. Một mặt nó rất tiện lợi cho người lập trình khi không muốn dùng các vòng lặp. Mặt khác, nếu không quản lý tốt trường hợp kết thúc đệ quy thì sẽ rất dễ dẫn đến stack cứ tăng mãi không ngừng và hết khả năng đáp ứng như trường hợp của lỗi này. Hiện nay Mozilla vẫn chưa có bản vá cho lỗi này.

Bkis Security

Hôm nay, 7/3/2010, là ngày trao giải OSCAR 2010, người dùng hãy cẩn thận khi tìm kiếm các thông tin về giải OSCAR, rất có thể bạn đang bị dẫn tới các trang web có chứa phần mềm diệt virus (AV) giả.

Theo tìm hiểu của chúng tôi, với từ khóa “Oscars 2010 Time” bạn sẽ bị dẫn tới các trang web chứa mã độc.

Kết quả tìm kiếm thông tin về giải Oscar dẫn tới trang chứa mã độc

Không chỉ có WindowsXP mà cả Windows 7 cũng bị làm giả. Tùy vào thông số của hệ điều hành mà phần mềm AV giả sẽ hiện lên hình ảnh tương ứng.

Phần mềm AV giả trên Windows XP

Phần mềm AV giả trên Windows 7

Với khách hàng của Bkav, các bạn có thể yên tâm vì Bkav đã cập nhật mẫu nhận diện phần mềm giả mạo này vào cơ sở dữ liệu.

Người dùng không phải là khách hàng của Bkav, hãy cẩn thận khi tìm kiếm.

Cập nhật (ngày 10 tháng 3, 2010): Theo các phân tích gần đây của chúng tôi, một số các từ khóa “nguy hiểm” khác cũng liên quan đến giải Oscars 2010 như: “Best Actress Winner 2010 Oscars” (Nữ diễn viên xuất sắc nhất), “Oscar winners live 2010″ (Những người giành giải Oscars 2010, trực tiếp).

Bkis Security