Trao đổi với tôi

www.hdphim.info

8/21/09

[Reverse] Vấn đề về quản lý mật khẩu trong IE và Firefox (Phần cuối)

Vấn đề về quản lý mật khẩu trong IE và Firefox (Phần cuối)
(Thứ Ba, 23/01/2007 - 9:30 AM)

Phần 2: Giới thiệu tiếp đến bạn về vấn đề quản lý mật khẩu trong IE và Firefox

5.2 Bổ sung những thiếu sót về bộ quản lý password trong Firefox 2.0

Bộ quản lý password của Firefox 2.0 (tháng 11 năm 2006) có một lỗ hổng có thể cho phép thông tin người dùng (từ trang đang vào) có thể gửi đến bất kỳ URL nào nếu họ click vào một link nguy hiểm. Lỗ hổng này được gọi là Reverse Cross-Site Request (RCSR), nó bắt nguồn từ thực tế trình duyệt không kiểm soát URL để các thông tin này được gửi thông qua các web form. Người dùng đã ghé thăm trang từ trước và lưu lại các thông tin trên bộ quản lý password, do đó các tấn công có khả năng tấn công vào. Việc đánh cắp thông tin này đã được đưa ra trên MySpace.com và được CIS phát hiện ra. Các trang bình thường có cho phép người dùng gửi HTML nguyên bản hầu như rất dễ gặp phải tấn công kiểu này.

RCSR nguy hiểm hơn kiểu tấn công mô tả trong phần 5.1 bởi vì XMLHttpRequest không cho phép các yêu cầu ngoài tên miền hiện hành. Thêm vào đó, link (cho phép đệ trình các form) có thể xuất hiện trong các dạng video, chương trình hay có thể là các trò chơi nhằm làm cho nó khó bị phát hiện.

5.3 Việc phát hiện ra các password Internet Explorer

5.3.1 Khôi phục lại password

Nhiều công ty có phần mềm thương mại để khôi phục lại các password từ AutoComplete của Internet Explorer. ElcomSoft cung cấp một chương trình thực hiện công việc này có tên là Advanced Internet Explorer Password Recovery (AIEPR). Khi bắt đầu nó có thể khôi phục lại bất kỳ thông tin AutoComplete trên bất kỳ phiên bản Internet Explorer nào từ 3 đến 6 miễn là người dùng đã đăng nhập vào. Các chương trình phần mềm như là PassView làm việc trên Internet Explorer phiên bản 4 đến 6 và IEPassView cho phiên bản IE7 được cung cấp hoàn toàn miễn phí.

5.3.2 Malware

Internet Explorer thường sử dụng một cách thức tốt để chống lại sự xâm hại của malware. Tuy nhiên vẫn còn những lổ hổng để các malware có thể xâm nhập vào thông tin AutoComplete. Các chương trình này tăng các thông tin mật sau đó gửi quay lại cho kẻ tấn công. BackDoor-AXJ là một chương trình Trojan lưu AutoComplete và các thông tin khác của nạn nhân sau đó gửi những thông tin này ngược trở lại người điều khiển. Srv.SSA-KeyLogger là một backdoor được cài đặt ngầm trên Internet Explorer và hành động như một bản ghi chính. Backdoor cũng ngầm khởi tạo AutoComplete và lấy cắp dữ liệu từ Protected Storage và sau đó gửi lại thông qua giao thức HTTP GET.

5.4 Phát hiện ra các password trong Firefox

5.4.1 Có thể truy cập một cách dễ dàng vào password văn bản.

Với những người sử dụng Firefox Password Manager thì các thông tin được ghi vào có thể quan sát được các password dưới dạng văn bản rõ ràng khi như hướng dẫn dưới đây:

Trên Windows XP:

Firefox 1.5
Tools | Options | Privacy | Passwords | View Saved Passwords | View Passwords | Show Passwords

Firefox 2.0
Tools | Options | Security | Show Passwords | Show Passwords

5.4.2 Các tấn công Master Password

Gần đây các công cụ được phát triển để thực hiện các tấn công vào password trên Master Password trong Firefox. Các tấn công kiểu dưới đây vẫn đang rất nguy hiểm:

  • Brute force
  • Dictionary
  • Hybrid

Firemaster là một công cụ bẻ khóa được thiết kế dành cho Master Password trong Firefox. Công cụ được viết bằng C++ bởi N. Y. Talekar vào tháng 1 năm 2006; mã nguồn của chương trình này hiện nay được tung lên mạng. Các công cụ khác được viết bằng C cho chức năng chính đang được phát triển tiếp. Khi các công cụ được cải thiện, cơ sở dữ liệu password hoàn toàn có thể tin tưởng vào Master Password để đối phó với các tấn công. Do vậy không thể nói rằng một password kém có thể được bẻ trong một vài giây. Hơn nữa việc không có password sẽ phơi bày cơ sở dữ liệu password ngay tức khắc. Điều này cơ bản tương đương với việc đánh dấu menu tùy chọn trong Firefox để hiện các password.

5.4.3 Nhiều username/password trên một URL

Firefox có một đặc tính thú vị sẽ cho phép nhiều sự thẩm định cho cùng một trang. Cho ví dụ hãy nói hai ký tự hư cấu là Alice và Bob sử dụng Firefox Password Manager trên cùng một tài khoản Windows XP nhưng có các tài khoản ngân hàng khác nhau trên cùng trang (www.pncbank.com). Password Manager sẽ cho phép nhiều cặp username và password. Password Manager sẽ nhận ra khi sử dụng mỗi tài khoản web dựa vào username và tự động điền trường password. Đặc tính này cung cấp khả năng quan sát thông tin người dùng sau:

URL
bob
k9x763s
alice
n63ld23f

Dựa vào các mô hình bảo mật, không có cặp riêng lẻ nào sẽ sử dụng cùng tài khoản; mặc dù vậy, vấn đề này vẫn có rủi ro bởi vì không phải tất cả các tổ chức đều làm việc tốt. Thêm vào đó, có một vấn đề liên quan nếu một cặp username/password được nhập không đúng cho một trang nào đó (như là một lỗi trong việc chuyển hai đăng nhập cho các trang mới khác nhau hoàn toàn). Thông tin này sẽ được lưu (thậm chí nó không được sử dụng) và có thể được thỏa hiệp một thời điểm nào đó trong tương lai mà không cần biết về người tham dự.

5.4.4 Các tấn công hạn chế dịch vụ

Bất cứ người dùng hay chương trình nào vơi sự được phép có một profile cục bộ của người dùng trên hệ thống file cũng có khả năng tấn công vào bộ quản lý password. Nếu các file (keyN.db, certN.db, secmod.db, signons.txt) được xóa hay được thay đổi kết quả thì không thể lấy lại được các username và password. File quan trọng nhất trong các file này là KeyN.dbsignons.txt, chúng giữ các chức năng riêng và dữ liệu được đã mã hóa một cách tương ứng.
Để bảo đảm cho cơ sở dữ liệu password chúng ta nên copy các file keyN.db, certN.db, secmod.db, và signons.txt đến một địa chỉ an toàn. Như vậy nếu các file này bị thay đổi hay xóa và Password Manager không có thì nó vẫn có thể đảm bảo việc khôi phục lại được cơ sở dữ liệu password bằng cách copy các file này trở lại thư mục profile của Firefox.

6, Những sai lầm trong bảo mật

Người dùng không hiểu một cách đầy đủ hay cũng không biết đến các rủi ro có thể gặp phải khi họ sử dụng các hệ thống quản lý password cho các trình duyệt. Sự nguy hiểm này gắn liền với sự thiếu quan tâm trong việc lưu giữ bất kỳ username hay password nào bất chấp cho cả việc truy cập vào một nhóm tin tức đơn giản hay một thứ gì đó bí mật hơn và nhậy cảm hơn như các thông tin về tài chính tại các phiên môi giới trực tuyến. Người dùng mong đợi ở các trình duyệt khả năng liên kết với hệ điều hành và sẽ bảo vệ thông tin của họ và trừu tượng hóa kỹ thuật bảo mật. Trong thực tế những rủi ro có thể xảy ra dễ dàng hơn những gì mà người dùng đang nghĩ. Các trình duyệt cũng nguy hiểm như những ứng dụng vì chúng được cài đặt trên hầu hết các hệ thống máy tính, được sử dụng bởi nhiều người và lưu tất cả username và password mà người dùng nhập vào.

7, Khả năng sử dụng

Các đặc tính thích hợp của quản lý password trong Internet Explorer và Firefox được chỉ ra dưới bảng 2. Một vài nét khác nhau chính chính là khả năng nhìn thấy các password một cách rõ ràng trong Firefox mà không có trong Internet Explorer. Điều này được xem như là một đặc tính cũng như rủi ro bảo mật, nó phụ thuộc vào Master Password có được thiết lập hay không. Thêm vào đó, Firefox có một đặc tính hữu ích cho phép các username và password được ngăn chặn một cách rõ ràng trong một số trang (ví dụ những thông tin nhạy cảm cho các trang cụ thể không thể có nhiều rủi ro). Trong AutoComplete, sự lựa chọn này chỉ được một lần và không thể dễ dàng thay đổi trừ khi không hiểu về các chức năng chính của registry. Hơn nữa AutoComplete còn có một thuận lợi nữa trong Password Manager đó là người dùng có thể chọn lưu URL, username hay password mà không cần sự ủy nhiệm của cả ba như trong Firefox.

Đặc tính Internet Explorer 7 Firefox 2.0
Nhắc nhở lưu giữ các password

yes

yes

Khả năng dễ dàng thay đổi trên sở thích "lưu" hay "không lưu"

yes

Khả năng không lưu bất kỳ thông tin nào trong các form

yes

yes

Khả năng dễ dàng truy cập các password dạng văn bản đã mã hóa (plaintext)

yes

Khả năng chọn lưu URL, username hay password

yes

Bảng 2: So sánh giữa các đặc tính tiện ích của Internet Explorer và Firefox.

8, Các chiến lược phòng chống

8.1, Phòng chống dựa trên người dùng

8.1.1, Lẩn tránh

Một phương pháp để ngăn chặn việc thỏa hiệp password là hạn chế sử dụng bộ quản lý của cả Internet Explorer và Firefox. Mặc dù vậy điều này có thể làm cho người dùng có xu hướng chọn cùng một password cho nhiều trang, điều rất bất lợi cho việc bảo mật. Như vậy, sự lé tránh nên được thực hiện nếu có một phương pháp luân phiên để thay thế cho nó. Cũng có một cách cho người dùng có thể tình cờ lưu các password trong một quá trình duyệt thông thường.

8.1.2, Vô hiệu hóa quản lý password

Điều này sẽ làm cho bộ quản lý password ngăn chặn được khả năng lưu username và password mặc dù có thể rơi vào trạng thái tương tự như biện pháp trên. Chiến lược này khác với phương pháp sẽ thảo luận trong 8.2.

8.1.3, Luân phiên các bộ quản lý password “được xác nhận”

Một phương pháp chung mà người dùng lưu các password là trong một ứng dụng gọi là Password Safe. Ứng dụng được thiết kế bởi Bruce Schneier đó là tiện ích Windows mã nguồn mở là một phương pháp phổ biến cho việc lưu và truy cập các password. Các password được mã hóa bằng khối chữ số 0 Schneier's Blowfish và được bảo vệ bằng Safe Combination (password chủ).

Sự thận trọng và những bước đi ban đầu nên được thực hành trước khi sử dụng bất kỳ một chương trình mới nào. Mặc dù vậy, một chương trình với mục đích để lưu các thông tin nhạy cảm sẽ tập trung sâu hơn bất kỳ trình duyệt nào nhất là trong tính năng lưu giữ password. Tập trung vào bộ quản lý password mã nguồn mở và được thiết kế bằng các mật mã nổi tiếng là những lý do khiến cho nó trở thành một tùy chọn có giá trị. Cả hai AutoCompletePassword Manager đều cung cấp sự đơn giản và thuận tiện đến người dùng; không cần phải chuyển đến ứng dụng khác để tăng sự truy cập đến các username và password.

8.1.4, Phức hợp password

Như đã được đưa ra trong những phần trước, việc có một password chủ vững chắc có thể cho phép ngăn chặn một cách hiệu quả các tấn công.

Như những gì đã nói từ các phần trên, Internet Explorer không cho phép bạn chọn một password chủ cho AutoComplete; sự bảo mật thông tin được lưu với AutoComplete được liên hệ trực tiếp đến password tài khoản người dùng Windows. Việc lựa chọn một password Windows mạnh hơn sẽ cung cấp hơn nữa sự bảo vệ. Mặc dù như vậy nhưng các password của Windows không dễ dàng gì có thể thỏa hiệp trong một vài phút. Việc tạo một password vững chắc hơn trong Password Manager cho Firefox có thể giảm đáng kể các rủi ro về sự thỏa hiệp. Một password tốt phải có chiều dài hơn 8 kí tự ngẫu nhiên và phải trộn lẫn với các kí tự chữ số, điều này sẽ làm tăng đáng kể khả năng bảo mật. Các tấn công bẻ khóa password hoàn toàn có thể tiến hành với Firefox Password Manager nhưng đó không phải là xu thế chủ đạo và bằng việc sử dụng thận trọng hơn nữa có thể tranh được việc này. Trong nhiều trường hợp, người dùng Firefox tăng lớp bảo vệ mở rộng bằng cách sử dụng một password tương tự như bên phía Internet Explorer.

8.2, Dàn xếp lại dựa trên chuyên gia phát triển Web

Theo sự nhìn nhận của các chuyên gia phát triển Web, trang thương mại và tổ chức tài chính có thể thực hiện việc bảo vệ người dùng chống lại sự thỏa hiệp password trong tương lai. Cả Internet Explorer và Firefox đều có khả năng bảo vệ này nếu các thuộc tính của tag trong HTML được thiết lập một cách thích hợp. Hãy xét một ví dụ được lấy đại diện từ MSDN và thể hiện dễ dàng như thế nào để có thể kết hợp chặt chẽ thay đổi này trong bất kỳ trang web nào. Bằng sử dụng phương pháp này, các trung tâm phòng chống rủi ro có thể ngăn chặn việc lưu password trong Internet Explorer và Firefox.

Văn bản này sẽ được lưu:

Văn bản này không được lưu:

Các ngân hàng sử dụng đặc tính này gồm có Washington Mutual, Chase Manhattan cũng như Fidelity, E*Trade, Vanguard, Schwab,… Nhiều tổ chức không sử dụng như các kho bạc PNC Bank Oppenheimer. Nếu mỗi trang web đều trang bị vấn đề này thì sẽ không có bất kỳ một lợi ích nào từ việc sử dụng các bộ quản lý password trong trình duyệt. Như vậy, phương pháp này chỉ ý nghĩa với mỗi một tổ chức riêng lẻ nếu nó thích hợp. Sử dụng phương pháp này sẽ không bảo đảm an toàn cho máy khách (đã được chỉ ra trong phần 5.1). HTML và JavaScript có thể bị thay đổi tại máy khách, chuyển từ “OFF” sang “ON”.
Dàn xếp bảo mật hoạt động kinh doanh của Windows

Hoàn toàn có thể vô hiệu hóa đặc tính AutoComplete của Internet Explorer cho bảo mật doanh nghiệp. Sử dụng Group Policy Objects (GPO) là một giải pháp dễ dàng để quản lý một số lượng lớn các hệ thống máy tính bằng điều khiển các thiết lập người dùng và máy móc với các chính sách riêng. Sử dụng Windows Server 2003 trong môi trường Active Directory hoàn toàn cho phép vô hiệu hóa các thiết lập AutoComplete trong toàn bộ một tổ chức hay công ty nào đó.

Kết luận

Sự rủi ro trong kỹ thuật lưu password của các trình duyệt như Internet Explorer và Firefox cần phải được đánh giá hơn nữa. Bất kỳ hệ thống nào điều khiển các chức năng chính trong nhiều lĩnh vực cũng cần phải xem xét hơn nữa. người dùng cũng cần phải có hơn nữa những kiến thức về rủi ro và những lợi ích mang lại từ sử dụng hệ thống quản lý password. Các phương pháp hiện nay nhằm giảm rủi ro hay tấn công như đã trình bày trong tài liệu cũng chỉ là các giải pháp nhất thời. Người dùng luôn mong đợi một hệ thống bảo mật tốt nhất. Như vậy, thế hệ kế tiếp của các hệ thống quản lý password cần phải tập trung hơn nữa để đáp ứng được các nhu cầu người dùng.

Theo Quantrimang

[Reverse] Vấn đề về quản lý mật khẩu trong IE và Firefox

Vấn đề về quản lý mật khẩu trong IE và Firefox
Cập nhật lúc 13h12' ngày 29/12/2006

1, Giới thiệu

Hai phần của bài viết này sẽ trình bày cho bạn một phân tích về các kỹ thuật bảo mật, rủi ro, các tấn công và cách phòng chống của hai hệ thống quản lý mật khẩu trình duyệt được sử dụng rộng rãi, đó là Internet Explore và Firefox. Đối tượng chính trong bài viết này đề cập đến hai trình duyệt IE 6 và 7, Firefox 1.5 và 2.0 và cụ thể là những nội dung sau:

  • Kỹ thuật lưu mật khẩu: Ý nghĩa của việc bảo vệ các username và password trên hệ thống file cục bộ thông qua mã hóa.
  • Các kiểu tấn công: Các phương pháp phá hoại hay vượt qua được sự bảo vệ.
  • Những sai lầm về bảo mật: Người dùng sử dụng mật khẩu không có kiến thức về khả năng rủi ro.
  • Khả năng sử dụng: Những đặc tính nhằm nâng cao hay cản trở khả năng sử dụng của các đặc tính bảo mật.
  • Biện pháp đối phó và khắc phục: Những hành động cần thiết để người dùng và các tổ chức giảm những rủi ro không đáng có.

Internet Explorer và Firefox đã cùng nhau chia sẻ khoảng gần 95% thị phần của tất cả các trình duyệt. AutoComplete và Password Manager là các tính năng để lưu username, password và URL tương của IE (từ phiên bản 4) và Firefox (từ phiên bản 0.7)

Mỗi trình duyệt có các tính năng riêng để hỗ trợ người dùng bằng việc nhớ các username và password khác nhau như một sự thẩm định cho các trang web. Vì vậy, khi vào một URL như http://www.gmail.com, nơi có các trường nhập vào, thì cả Internet Explorer và Firefox đều sẽ nhắc nhở người dùng xem có muốn lưu username hay password hay không. Khi người dùng vào lại trang web này thì trình duyệt sẽ tự động điền vào đầy đủ các trường đó.

Mặc dù những tính năng này giúp đơn giản hóa đáng kể trách nhiệm của người dùng song chúng cũng đưa ra những vấn đề cần phải suy xét về bảo mật, điều mà sẽ được nói đến trong những phần dưới đây.

2, Một trường hợp về bộ quản lý mật khẩu

Sự cần thiết của các bộ quản lý mật khẩu liên quan trực tiếp đến khó khăn để có thể nhớ một số lượng lớn username và password cho các trang web cụ thể. Thực tế, cần phải chú ý là bộ quản lý mật khẩu có thể tăng cường toàn bộ tính bảo mật vì chúng có quyền cho phép mức entropy lớn hơn trong việc sử dụng các bộ nhận dạng và mật khẩu. Vì vậy người dùng có thể tạo nhiều username khác nhau thay vì một username để cho những kẻ tấn công khó khăn hơn trong việc phỏng đoán.

Xét theo khía cạnh cân bằng mà nói thì người dùng phải tin tưởng vào ứng dụng để thực hiện vai trò của nó (như việc lưu, xử lý một cách an toàn và những khả năng tiến bộ để cho phép tồn tại của nó). Việc quản lý mật khẩu không phải là một phương thuốc chữa bách bệnh song chúng cũng có tác dụng thúc đẩy về mặt công nghệ, tăng khả năng rào chắn đối với những tấn công bằng cách cải thiện giao diện người dùng để tính toán các môi trường thông thường vẫn cần đến sự thẩm định.

Người dùng cũng như các doanh nghiệp cần phải được bảo đảm rằng các hệ thống quản lý mật khẩu phải được sử dụng và thực hiện đúng quy cách, kiến thức về khả năng rủi ro liên quan. Bài viết này có thể được sử dụng như một kiến thức cơ bản cho việc thiết kế các bộ quản lý mật khẩu an toàn hơn bằng việc ôn lại những tấn công, từ đó xây dựng một giải pháp vững chắc đối phó với các tấn công tương lai.

3, Công việc đầu tiên

Sử dụng cùng một username và password trong nhiều trang web sẽ làm tăng khả năng thỏa hiệp, chính nhờ đó mà kẻ tấn công chỉ cần khám phá một username và một password để thỏa hiệp với tất cả tài nguyên của người dùng. Sử dụng nhiều password, các kỹ thuật ghi nhớ và mối nguy hiểm khi dùng lại password đều được nghiên cứu một cách rộng rãi. Thêm vào đó, mở rộng ra Firefox cũng đã được nghiên cứu để giảm khả năng có thể phỏng đoán password.

4, Các kỹ thuật lưu password

Các vị trí và kỹ thuật lưu username và password được đưa ra dưới đây. Thông tin này được sử dụng như một nghiên cứu các kiểu tấn công cơ bản được sử dụng trong phần 5.

4.1, Vị trí lưu

4.1.1, Internet Explorer 6 & 7

Trên Internet Explorer (từ phiên bản 4 đến 6) thông tin định dạng web AutoComplete được lưu trong Registry ở các vị trí dưới đây:

Các username và password đã được mã hóa:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\SPW

Các địa chỉ Web:

HKEY_LOCAL_MACHINE\Software\MicrosoftProtected Storage System Provider\

Các key mã hóa đối xứng:

HKEY_CURRENT_USER\Software\Microsoft\ Protected Storage System Provider\Data\\

Trong Internet Explorer 7, thông tin AutoComplete cũng được lưu trong Registry nhưng trong vị trí khác.

Các username và password đã được mã hóa:

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2

Các mục trong registry chỉ được tạo khi người dùng thực hiện lưu thông tin đăng nhập (username và password) cho một trang web. SPW là viết tắt của SavedPassWords.

4.1.2, Firefox 1.5 and 2.0

Trong Firefox, các URL (Uniform Resource Locators), các username và password được lưu trong một file signons.txt:

Các username và password được mã hóa trong hệ thống Windows được lưu trong:

%userprofile%\Application Data\Mozilla\Firefox Profiles\xxxxxxxx.default\signons.txt

Khi %userprofile%, là biến môi trường trong Windows, thể hiện đường dẫn đến thư mục chủ của người dùng.

Các username và password được mã hóa trong hệ thống Linux đang chạy Firefox được lưu ở vị trí sau:

~/.mozilla/firefox/ xxxxxxxx.default/signons.txt

Vị trí của xxxxxxxx được chọn ngẫu nhiên khi Firefox được cài đặt. File signons.txt được tạo ra khi bất kỳ login cho một trang web được lưu. Các login theo sau với các URL được chèn vào trong file. Nó hoàn toàn không liên quan đến bộ quản lý password nếu trang đó truy cập sử dụng HTTP hay HTTPs. Các URL không được mã hóa bởi vì chúng được sử dụng như một tham chiếu (tra cứu) cho việc khớp các login. Đặc biệt hơn, khi một bộ quản lý password trình duyệt cần điền tự động login cho một trang cụ thể, có URL của trang được tham chiếu vơi file signons.txt (nếu URL đó tồn tại) thì username và password tương ứng được điền vào login của trang web.

4.2, Các kỹ thuật truy cập và lưu trữ

4.2.1, Internet Explorer 6 & 7

Kiến trúc lưu: Registry
Định dạng: Nhị phân, và được lưu như một cặp của các giá trị hex trong một loại dữ liệu REG_BINARY.
Mã hóa
: DES- ba cấp.
Truy cập: Bảo vệ API lưu trữ (cho Internet Explorer 4-6); API bảo vệ dữ liệu (cho Internet Explorer 7)
Các yêu cầu cho truy cập: Người dùng đăng nhập.
Lưu trữ tạm thời
: Các key đối xứng được đánh 0 vào bộ nhớ sau khi sử dụng.

Internet Explorer 4-6 sử dụng bộ cung cấp hệ thống bảo vệ lưu trữ (PStore) để lưu và truy cập thông tin người dùng gồm có username và password, các password nhập vào trên định dạng web trong Internet Explorer. Pstore như định nghĩa bởi MSDN, là một giao diện lập trình ứng dụng được sử dụng để lưu thông tin một cách an toàn. Trong một công bố gần đây của Microsoft người ta đã đưa ra:

"… dịch vụ Protected Storage, không sớm thì muộn cũng sẽ được quan tâm như một phương pháp bảo đảm cho lưu trữ các bí mật. Ứng dụng Windows đáng kể nhất vẫn sử dụng P-store là Microsoft Internet Explorer, lưu thông tin Auto-Complete gồm có tên, mật khẩu được sử dụng để thẩm định dựa trên các form."

Dữ liệu PStore được mã hóa với DES-ba cấp và được lưu trong một kiến trúc nhị phân. Dữ liệu không mã hóa không thể truy cập trực tiếp thông qua registry. Mặc dù vậy, việc truy cập và an ninh dữ liệu cần phải được thắt chặt với các khả năng đăng nhập Windows của người dùng. Khi người dùng đăng nhập, bất kỳ một chương trình đang chạy dưới nội dung của người dùng có thể tăng khả năng truy cập đến dữ liệu PStore không mã hóa bằng việc sử dụng các triệu gọi API đúng. Mặc dù vậy, các tài khoản người dùng Windows khác không thể truy cập vào dữ liệu PStore khác.

PStore không phải chỉ được sử dụng riêng trên Internet Explorer mà nó còn được sử dụng chung cho cả kỹ thuật khác của các sản phẩm Microsoft như Outlook và MSN Explorer. Các chương trình này cũng dễ bị ảnh hưởng đến các yếu điểm trong thiết kế bảo mật. Một số chương trình Spyware đã biết cách phá hoại bảo mật PStore thông qua API có khả năng lập trình dễ dàng của nó và tăng mức truy cập không chính đáng.

Internet Explorer 7 sử dụng giao diện lập trình ứng dụng dữ liệu bảo vệ (DPAPI) nhưng những khả năng trên vẫn có thể tồn tại và được công bố đến các chương trình mở rộng thông qua các triệu gọi API.

Mật mã cho AutoComplete trong IE7 được thể hiện dưới đang sử dụng thuật ngữ chuẩn:

EK - Encryption Key (Khóa mã hóa)
RK - Record Key (Khóa bản ghi)
CRC - Cyclical Redundancy Check (Kiểm tra tình trạng dư thừa theo chu kỳ)
Hash - Secure Hash Algorithm (SHA) (Thuật toán bảo mật Hash)

Khả năng lưu trữ:
EK: URL
RK: Hash(EncryptionKey)
C: CRC(Record Key)
V: {dữ liệu}EK
Lưu trữ (C, V) được đánh chỉ số bằng RK trong Registry, làm mất hiệu lực EK

Khả năng phục hồi lại:
EK: URL
RK: Hash(EK)
Tra cứu RK trong Registry, xem có khớp tương ứng dữ liệu mã hóa và dữ liệu {V}EK hay không

Vì vậy URL được yêu cầu để phục hồi lại các khả năng (dữ liệu) như nó xếp vào EncryptionKey (EK).

a, Những quan tâm về truy cập của Internet Explorer.

IE AutoComplete làm việc dưới giả thuyết rằng một tài khoản người dùng Windows cụ thể hoàn toàn có thể truy cập hợp lý với cơ sở dữ liệu mật khẩu. Vì vậy, nếu một người dùng không được phép có sự truy cập hợp lý đến máy tính và tài khoản được đăng nhập hoặc nó không phải là một password được bảo vệ thì kẻ tấn công có thể lạm dụng các đặc quyền tài khoản và sử dụng password một cách bất hợp pháp. Sự truy cập hợp lý có thể được thực hiện trực tiếp trên máy tính đó hoặc sử dụng máy khách truy cập từ xa (VNC, trạm làm việc từ xa,…).

Như vậy, nếu không có những tôn trọng về việc sử dụng máy (như việc các phòng được ngăn cách bởi khóa, hay mật khẩu để bảo vệ việc đăng nhập của các chương trình bảo vệ màn hình) thì bất kỳ ai cũng có thể sử dụng trực tiếp trên máy tính để truy cập tới bất kỳ website nào cho phép quản lý password. Nếu quản lý máy tính tốt, thì một người không đáng tin muốn tăng khả năng truy nhập tới bất cứ thứ gì (từ email cá nhân của một người tới tài khoản ngân hàng) sẽ gặp khó khăn.

Thêm vào đó, trong các trường hợp nhiều người có cùng một tài khoản người dùng hợp lý (một thực tế bảo mật kém), các vấn đề tăng vọt với người dùng bất hợp lý. Các kỹ thuật điều khiển từ xa để tăng truy cập được đưa ra trong phần sau và cũng có hiệu lực với các bổ sung thêm vào.

4.2.2, Firefox 0.7-1.5 và 2.0

Kiến trúc lưu: Dạng file văn bản (signons.txt)
Định dạng: ASCII, bằng sử dụng việc mã hóa Base64 (ngoại trừ URL và các trường)

URL (ví dụ. www.gmail.com)
Trường tên (trong cleartext,ví dụ: username, email, userid,…)
Mã hóa Base64 cho các thông tin ở trên
Trường tên (ví dụ: password, pass,...)
Mã hóa Base64 cho các thông tin ở trên
... (Có thể có nhiều mục cho mỗi URL)

(Mỗi mục URL kéo dài trong chu kỳ phân chia dòng)

Mã hóa: DES ba cấp (chế độ CBC)
Truy cập: Các dịch vụ an ninh mạng API (NSS)
Các yêu cầu cho truy cập: Người dùng đã đăng nhập và mật khẩu chủ (nếu thiết lập)
Các file liên quan: Các chứng chỉ (ký các Public Key) được lưu trong certN.db, còn các cơ sở dữ liệu Private Key được lưu trong keyN.db và các Module bảo mật được lưu trong secmod.db

Chú ý rằng các vị trí file được định tị từ trước trong phần 4.1.

Firefox sử dụng Network Security Services API để thực hiện mã hóa. Nó liên quan đến Password Manager Firefox để tạo ra Public Key Cryptography Standard (PKCS) #11 (định nghĩa API cho các modul bảo mật nhóm thứ ba gồm cả phần mềm và phần cứng). Sử dụng PKCS#5 để mã hóa password. Firefox cũng có một tùy chọn của việc sử dụng mođul bảo mật luân phiên cho bộ quản lý password, đó là chuẩn xử lý thông tin quốc gia (FIPS) 140-1. Master Password được sử dụng cùng chung với một phần trong file keyN.db thường được sử dụng để cung cấp một Master Key. Master Key sau đó được sử dụng để giải mã username, password được lưu trong Password Manager.

Mặc dù không dễ dàng giải quyết nhưng NSS API có một vài chức năng quan trọng đối với Firefox hay một chương trình liên quan để tăng khả năng truy nhập vào cơ sở dữ liệu có password. Các thiết lập password được nắm giữ bởi (PK11_SetPasswordFunc), giải mã dữ liệu cơ số 64 (NSSBase64_DecodeBuffer), giải mã (PK11SDR_Decrypt) cho phép một chương trình liên quan đến các username và password liên quan; đây quả thực là một vấn đề đơn giản. mã thực tế cần khởi chạy NSS, tuyên bố các biến, quản lý bộ đệm,… Mặc dù vậy sự bảo mật của toàn bộ hệ thống dựa vào sức mạnh mật mã của Master Password (được tạo ra bởi người dùng) và khả năng truy cập vào file key3.db (bao gồm những phần quan trọng) được lưu trong profile của người dùng.

Modul bảo mật FIPS 140-1 có thể cho phép bằng việc định hướng theo sự xếp đặt sau:

Firefox 1.5 trên Windows:

Tools | Options | Advanced | Security Devices | NSS Internal FIPS PKCS #11

Firefox 2.0 trên Windows:

Tools | Options | Advanced | Encryption | Security Devices | NSS Internal FIPS PKCS #11

5, Các tấn công vào bộ quản lý password

Phần này sẽ quan sát vài tấn công nhằm phá hoại các bộ quản lý password. Hai tấn công như đã được thảo luận và sau đó chúng tôi sẽ gộp thành một phần trong một loạt các bào báo.

Một công nghệ chung nhất để tìm tất cả các đường thâm nhập một hệ thống là sử dụng một sơ đồ hình cây. Mục đích của sơ đồ này được thể hiện bên dưới hình 1 là sự thỏa hiệp hoàn tất của cơ sở dữ liệu password.


Hình 1
: Tấn công kiểu cây với bộ quản lý password trong Firefox.

Kết quả của việc tăng truy nhập vào cơ sở dữ liệu sẽ cho phép kẻ tấn công đạt được tất cả các URL, username, password mà đã được sử dụng để xác nhận trong các trang. Bộ quản lý password thỏa hiệp cho phép kẻ tấn công truy cập vào bất kỳ thứ gì từ e-mail đến bảo hiểm, ngân hàng hay thậm chí cả thông tin cộng tác bên trong mạng nội bộ. Một vấn đề nhỏ (không được liệt kê trong cây trên) sẽ thỏa hiệp với khả năng đăng nhập cho các trang đặc biệt.

Một hệ thống quản lý password được phát triển cho ứng dụng và các thành phần người dùng. Để thỏa hiệp với cơ sở dữ liệu password hay một đăng nhập đặc biệt thì chỉ cần tấn công vào thành phần yếu nhất của hệ thống. Trong trường hợp này, các liên kết yếu nhất luôn là người dùng (không mã hóa hoặc bổ xung thêm phần mềm). Các tấn công đều dựa vào giao diện giữa người dùng và bộ quản lý password hoặc giữa bộ quản lý password và trình duyệt.

5.1, Trình duyệt không bị các tấn công JavaScript

Hai tấn công JavaScript sẽ không được thảo luận trong phần này trước trước khi kết luận: một tấn công chuẩn và một ứng dụng Ajax.

5.1.1, Tấn công JavaScript chuẩn

Giả định: Kẻ tấn công có tài khoản người dùng hợp lệ

Kết quả tấn công: Kẻ tấn công có khả năng xuyên qua một trang đã lưu đăng nhập và 1) Tăng truy nhập 2) Sử dụng JavaScript để phát hiện username và password.

Thiệt hại khác: sử dụng password bị lộ để truy cập vào bộ quản lý password hoặc các ứng dụng khác và các trang có cùng password.

Sử dụng JavaScript hoàn toàn có thể phát hiện ra các password đã được lưu trên bất kỳ trang nào thông qua DOM. Khi một ai đó viếng thăm một trang nào đó mà lưu lại username và password thì password luôn luôn được để ẩn bằng các dấu *. Đó là những gì mà người dùng nhìn thấy; nhưng trình duyệt thì lại lưu password bằng mã ASCII thực và đệ trình nó khi hành động đệ trình được cần đến. Việc sử dụng các dấu * hoàn toàn tốt trong thiết kế để ngăn chặn ngoài giao diện.

Để làm việc xung quanh phạm vi ngăn ngừa này, một kẻ tấn công thông minh có thể sử dụng cả JavaScript được nhúng trong trang HTML hay chạy một script sau khi tải trang, chúng ta cho rằng kẻ tấn công đã xác định được username và password.


Hình 2
: Mô hình đối tượng tài liệu JavaScript

Mã JavaScript hoàn toàn dễ dàng có thể truy cập online. Nó có thể được nhúng trong HTML hoặc được chạy trong một bookmarklet. Một bookmarklet là một chương trình JavaScript nhỏ được lưu như một URL và chạy cục bộ trong trang web sau khi tải.

Sử dụng logic lập trình, một kẻ tấn công có thể lặp đi lặp lại thông qua tất cả password-based elements (như trong hình 2) của DOM; các giá trị tương ứng với các đối tượng password này sẽ được lấy lại sau đó, việc phá các dấu * là không thể. Bất kỳ ai hay một chương trình nào logic với máy khách Web (Internet Explorer hoặc Firefox) có thể “click” trên một link và tìm ra được password.


javascript:(
function(){
var s,F,j,f,i;
s = "";
F = document.forms;
for(j=0; j f = F[j];
for (i=0; i if (f[i].type.toLowerCase() == "password")
s += f[i].value + "\n";
}
}
if (s) alert("Passwords in forms :\n\n" + s);
else alert("No passwords in forms on this page.");})();

Hình 3: Mã JavaScript để lấy lại password.

5.1.2, Việc lấy password bằng Ajax

Giả thiết: Kẻ tấn công truy cập đến một web proxy trong suốt hay được cấu hình cho web máy khách.

Kết quả tấn công: Kẻ tấn công có khả năng chèn, xóa hay thay đổi nội dung trang, JavaScript cho phép lấy được username và password trên bất kỳ trang nào có các kết nối HTTP (thậm trí nếu SSL submit được sử dụng tại thời điểm sau đó).

Thiệt hại khác: Cho phép sử dụng cùng một đăng nhập để truy cập vào hệ thống máy tính, các ứng dụng khác và các trang sử dụng cùng username và password.

Trong vấn đề được trình bày trong hình 4 dưới đây, chúng ta có một người dùng đang mở một trình duyệt web và muốn truy cập vào thông tin ngân hàng của anh ấy trên một máy chủ từ xa. Máy khách yêu cầu trang web chính của nhà cung cấp (như American Express). Mặc dù vậy, những thông tin trong câu trả lời đã bị thay đổi thông qua một proxy server. Các proxy server thường được đặt để bảo vệ nhận dạng các địa chỉ IP, lọc; chúng thực hiện như một trung gian truyền thông giữa máy khách và máy chủ.


Hình 4
: Việc lấy password bằng Ajax

Khi kẻ tấn công kiểm soát được proxy thì chúng có thể nhúng JavaScript để lấy và gửi username và password thông qua một yêu cầu đồng bộ đến máy chủ (XMLHttpRequest). Username và password có thể đạt được thông qua JavaScript (bộ quản lý password tự động điền vào đăng nhập) hay thông qua kỹ thuật định thời để đợi tới một thời điểm hợp lý (ví dụ 5 giây) cho phép người dùng nhập vào thông tin và sau đó JavaScript chạy và gửi các dữ liệu đăng nhập cho kẻ tấn công. Hình 4 đã thể hiện trình duyệt đang yêu cầu một file XML gồm có các thông tin đăng nhập (bobpassword). Máy chủ sẽ bỏ qua yêu cầu bởi vì nó không hợp lệ nhưng kẻ tấn công lại tăng mức đăng nhập tại điểm này.

Việc phân định ra các quá trình là rất quan trọng, quá trình này sẽ thẩm định người dùng đến máy chủ và phân chia mã độc hại có thể gửi username và password đến kẻ tấn công. Trên một trang nào đó, các thông tin đăng nhập được nhập vào trước khi kết nối SSL được thành lập. Điều này là điểm chính của tấn công, nếu có một kết nối SSL được thiết lập trước việc đăng nhập dữ liệu thì proxy server không thể thấy được lưu lượng được mã hóa. Tuy nhiên một vài trang sử dụng SSL submit (như Yahoo, AMEX,…) hình thành nên các kết nối thẩm định mã hóa sau trang gốc được tải thì chúng sẽ có các lỗ hổng với các loại tấn công về vấn đề này.

Bạn sẽ nhận thấy rất nhiều điều quan trọng khi so sánh sự khác nhau trong các đặc tính quản lý password của hai trình duyệt lớn:

Đặc tính

Internet Explorer 7

Firefox 2.0

Lưu username, password và URL

yes

yes

Password truy cập thông qua JavaScript

yes

yes

Password truy cập thông qua phần mềm truy cập

yes

yes

Bảo vệ password (không chói buộc tài khoản người dùng)

yes

Password Prompt khi bắt đầu session để lưu các password

yes

Dễ dàng xuất dữ liệu username/password

yes

Mã hóa

yes

yes

Giải mã

yes

Password Manager chọn "Show Passwords"

yes

Với vài mục cuối trong bảng trên, chú ý rằng cần thiết phải chú ý đến các vấn đề tranh luận dù đó là một đặc trưng tin tưởng hay một lỗ hổng bảo mật, mặc dù vậy, thỉng thoảng cũng không có phương pháp nào cho việc lấy lại password khi bị quên.

Kết luận của phần 1

Phần 1 của bài viết này đưa ra một công việc nền tảng cho việc định địa chỉ các vấn đề liên quan đến quản lý password, nhưng thực tế được định địa chỉ hai điểm đầu tiên đưa ra tại phần đầu của bài viết, nó đã giải thích kỹ thuật lưu password của cả Internet Explorer và Firefox, và sau đó đã trình bày hai tấn công JavaScript có thể sử dụng để phá hoại các trình duyệt.

Mời các bạn đón xem phần 2!

Văn Linh (Theo Securityfocus)

[Virus] JPG to EXE

JPG to EXE - By E-man @ Astalavista.NET
---------------------------------------


This tutorial was written for WinXP, but I think it can be used the same way on other Windows OSes.

You can not blame me for anything that happens if you are using this tutorial for god knows what. This was written for education porposes only and you can only use it under your own risk.

This tutorial will show you how to create JPG files that will act like EXE files.

It will require abit of luck, but i'm sure you can mamage it


So here it how it goes.

The way Windows executes EXE files is stored inside the registry.
The way it executes JPG files is stored there too.

This means that we need to make windows think a JPG file is an EXE file. But we cant do that without hurting the OS's configuration or risk that any future changes made by programs will set JPG back to its default registry value.

What we need to do is create a file that will look like its a JPG (not be the icon, but by the type) and will act like an EXE.

This will be our file:

"file.jpg "

notice the space after the ".jpg". This is no ordianry space, but a special char that for writing it, you need to do as follows:

Get the EXE you want to convert to "jpg".

rename it from "file.exe" to "file.jpg". Now press the rename again, and in the end of the .jpg, press the ALT key (dont let go of it) and on the keypad, type "0160".

this will look like this: "file.jpg ". you can now rename it to something like "my pic.jpg "

Go to:

Start -> Run -> RegEdit

Right click on the HKEY_CLASSES_ROOT key and New -> Key

Call it ".jpg " (the space represants the ALT+0160)

Inside it, you will find the (Default) string.
Double click on it and write "exefile".

Then right click anywhere but on the Default string and New -> String Value

Call it "Content Type". and edit it so it will say "application/x-msdownload".

Right click on the ".jpg " key and New -> Key

Call it "PersistentHandler".

Inside it, edit the Default string to "{098f2470-bae0-11cd-b579-08002b30bfeb}"

Now every EXE file that will have the ".jpg " type, will be executed like a regular EXE! But only on your computer.

Right click on the ".jpg " key and Export.

Call it something like "fix.reg" and tell the guy/gal you're sending the "picture" to that its a fix so that windows will be able to open your pic.

I recommand using an EXE joiner to join a real pic to an EXE file so the user wont suspect anything.


Have fun. E-man. 8:36 PM 4/15/2002

8/15/09

[MASM] Using MASM to build a EXE

Using MASM to build a EXE
Author : Deux (REA Team)

http://www.mediafire.com/download.php?bhzwzi2jn1y

http://www.npower.edu.vn/Sach/1472009_1722240DeuxLesson1_ver10.doc

Benina

8/13/09

[Rootkit] Windows Driver Kit Version 7.0.0


Windows Driver Kit Version 7.0.0 | 580 MB

Link: http://www.updatesofts.com/forums/showthread.php?p=1461238

WDK includes sets Driver Development Kit (DDK), Hardware Compatibility Tests (HCT) and the Installable File System (IFS), providing a platform for developing, testing, signing, and get the logo Windows. WDK includes all the necessary drivers for the development headers, libraries, source code, tools and documentation.



Direct link cho anh em

Code:
http://nhacload.com/url/Windows_Driver_Kit_Version_7_0_0_001
http://nhacload.com/url/Windows_Driver_Kit_Version_7_0_0_002
http://nhacload.com/url/Windows_Driver_Kit_Version_7_0_0_003
http://nhacload.com/url/Windows_Driver_Kit_Version_7_0_0_004
http://nhacload.com/url/Windows_Driver_Kit_Version_7_0_0_005
http://nhacload.com/url/Windows_Driver_Kit_Version_7_0_0_006
http://nhacload.com/url/Windows_Driver_Kit_Version_7_0_0_007


Code:
http://nhacload.com/hotfile/Windows_Driver_Kit_Version_7_0_0_001
http://nhacload.com/hotfile/Windows_Driver_Kit_Version_7_0_0_002
http://nhacload.com/hotfile/Windows_Driver_Kit_Version_7_0_0_003
http://nhacload.com/hotfile/Windows_Driver_Kit_Version_7_0_0_004
http://nhacload.com/hotfile/Windows_Driver_Kit_Version_7_0_0_005
http://nhacload.com/hotfile/Windows_Driver_Kit_Version_7_0_0_006
http://nhacload.com/hotfile/Windows_Driver_Kit_Version_7_0_0_007

Code:
http://www.megaupload.com/?d=RQPXLDEF
http://www.megaupload.com/?d=XRYK4SWZ
http://www.megaupload.com/?d=13W41UPP
http://www.megaupload.com/?d=J8GTIYGD
http://www.megaupload.com/?d=V9OYPSLF
http://www.megaupload.com/?d=W6XVA7T5
http://www.megaupload.com/?d=R9U9HELE

8/12/09

[Virus] Trojan toàn quyền điều khiển máy tính của nạn nhân.

Trojan toàn quyền điều khiển máy tính của nạn nhân.
Author: trungtrung
Link: http://virusvn.com/forum/showthread.php?p=9344#post9344

Mới viết được con trojan = vb6, điều khiển máy tính nạn nhân = teamviewer, nhưng ko cần hỏi ý kiến của thằng nạn nhân... post lên đây cho mấy anh nghịch chơi

Chỉ cần nó click vào file, trojan sẽ gửi mail về kèm theo ID & PASS, ta chỉ việc dùng Teamviewer truy cập vào và...

Nạn nhân không hề hay biết, các của sổ của Teamviewer đã được ẩn an toàn

Thông tin về con Trojan này:
- File trojan nặng 1 MB
- Gửi/nhận thông tin qua Email
- "Núp" bằng cách khóa task manager
- Phần điều khiển sử dụng y chang Teamviewer
- Ẩn mình vào 1 file cài đặt (setup unlocker).

Hướng dẫn xài nè:















Cuối cùng hết là link download
Download QTSS v3.0 Final + Keygen
http://www.mediafire.com/?jy0gykqz5lm


Gửi tặng mấy anh cái source luôn em chỉ làm có 1 ngày nên trông nó hơi bị dỏm, mấy anh tải source về rồi edit thêm vài chức năng nữa cho nó pro nha

Download QTSS v3.0 Full Source + Keygen (9.74 MB)
http://www.mediafire.com/?zvgmm2jnwgt

Tải source về nhớ đọc file Read_me.txt nha

[MASM] Own extract overlay to a file

Own extract overlay to a file

Author: Benina

Có nhiều người biết Overlay là gì, nhưng cũng có nhiều anh, cụ thể là các newbiez, thì lại ko biết rõ ràng nó là cái gì. Nếu các bạn học reverse dùng Peid để khảo sát một file thì hay thấy xuất hiện từ overlay này khi Peid thông báo kết quả. Và cũng có một số người thì lại đóan mò nó là kỹ thuật nén này nén nọ. Ko biết đâu mà mò. Đã ko biết còn làm rối thêm. Riêng tôi, lúc trước có hỏi overlay là gì trên 4rum REA thì ko ai trả lời. Đành tìm tòi vậy.

Download tut+source:

http://benina.rea.googlepages.com/OwnExtratOverlay.rar

8/7/09

[Programming] C++.Tương tác với màn hình Logon trên Windows XP & Vista

C++.Tương tác với màn hình Logon trên Windows XP & Vista

Link: http://virusvn.com/forum/showthread.php?p=9229#post9229

Ghi chú : Lượm được bài viết này trên PCWORD, vứt lên để anh em vọc chơi, khá hay.Tự nhiên thực hành windows service với C# lên máu system programing lại trỗi dậy,anh em cùng nghiên cứu nhé.

Nguồn : PCWORDVN

àn hình đăng nhập của Windows là một đối tượng được bảo vệ kĩ lưỡng vì đó là nơi người dùng cung cấp tên và mật khẩu để bắt đầu sử dụng hệ thống. Màn hình này được gọi là WinLogon desktop, được quản lý bởi tiến trình WinLogon.exe và bắt đầu hoạt động trước khi có bất kì người dùng nào đăng nhập. Về mặt kĩ thuật, để tương tác được với màn hình này, ứng dụng cần hoạt động dưới dạng một Windows service bằng tài khoản LocalSystem và được tự khởi động khi hệ thống bắt đầu làm việc. Điều này có thể thực hiện dễ dàng trên Windows XP và các phiên bản trước, tuy nhiên kiến trúc mới của Windows Vista hoàn toàn không cho phép các service và ứng dụng tương tác với màn hình này. Trên thực tế vẫn có những ứng dụng được yêu cầu phải tương tác được với cửa sổ đăng nhập của Windows Vista, ví dụ hiển thị một hộp thoại, vẽ một hình ảnh hoặc xuất một thông báo trực tiếp lên màn hình nền của cửa sổ đăng nhập.

Bài viết này sử dụng một số thuật ngữ lập trình và bảo mật sử dụng Windows API, do đó bạn cần chuẩn bị các kiến thức liên quan để dễ tiếp cận hơn với vấn đề này và một trình biên dịch như Microsoft Visual C++.


Hình 1 - Hiện thông báo trên màn hình WinLogon của Windows Vista

Service tương tác với WinLogon desktop trong Windows XP

Trong Windows XP hay Windows Server 2003, các service và ứng dụng của người dùng đầu tiên đăng nhập vào hệ thống hoạt động chung ở session 0. Khi đó service có thể tương tác dễ dàng với màn hình WinLogon vì tiến trình WinLogon.exe cũng hoạt động ở session 0 này. Điều này dẫn đến nguy cơ bảo mật khi một ứng dụng có hại có thể nâng cao quyền của mình để tương tác với các ứng dụng điều khiển hệ thống.



Hình 3 - Mô hình ứng dụng cà service hoạt động trong các session của Windows XP



Hình 4 - Các service và ứng dụng của người dùng đầu tiên hoạt động ở session 0 trên Windows XP

Để cho phép service tương tác với WinLogon desktop hoặc các desktop khác, bạn có thể sử dụng một trong ba cách sau:

- Thiết lập bằng tay thông số Allow service to interact with desktop của service, sử dụng Service Management Console. Bạn chạy dòng lệnh services.msc tại trình đơn Start/Run và thiết lập thuộc tính cho service như hình vẽ bên dưới.


Hình 5 - Thiết lập một interactive service bằng Services Management Console

- Sử dụng công cụ dòng lệnh Service Controller sc.exe có sẵn để cài đặt service với các thông số tương tác. Bạn cần có quyền quản trị (administrator) để có thể cài đặt thành công service.

Ví dụ: sc.exe create MyService binPath= C:\MyTools\MyService.exe type= own type= interact start= auto

Trong đó, tham số “type= own type= interact” kết hợp với nhau để cho phép service tương tác với desktop, “start= auto” cho phép service tự động chạy khi hệ thống Windows vừa bắt đầu. Lưu ý, cú pháp của “sc.exe” bắt buộc phải có một dấu cách sau mỗi dấu bằng “=” ở danh sách thông số trên.

- Sử dụng Windows API CreateService để cài đặt service như ví dụ sau:

Mở Services Control Manager để có thể cấu hình các service

Để đoạn mã cài đặt thành công, bạn phải thực thi với quyền quản trị.

#include

SC_HANDLE handleMgr = ::OpenSCManager(NULL, SERVICES_ACTIVE_DATABASE, SC_MANAGER_CREATE_SERVICE);

Cài đặt một service mới, ví dụ ta có một service MyService.exe

SC_HANDLE handleSvc = ::CreateService(handleMgr, _T(“MyService”), _T(“MyService”), SERVICE_ALL_ACCESS, SERVICE_INTERACTIVE_PROCESS | SERVICE_WIN32_OWN_PROCESS, SERVICE_AUTO_START, SERVICE_ERROR_NORMAL, _T(“C:\\Z0rr0\\MyTools\\MyService.exe”), NULL, NULL, NULL, NULL, _T(“”));

if (handleSvc != NULL)

{

::CloseServiceHandle(handleSvc);

}

::CloseServiceHandle(handleMgr);

Thao tác vẽ hoặc xuất thông báo lên WinLogon desktop trong Windows XP có thể thực hiện ngay trong entry point ServiceMain của service ngay khi nó vừa bắt đầu hoạt động vì như đã đề cập, Windows XP cho phép một service có thể tương tác.

Các bước thực hiện như sau:

- Mở WinLogon desktop bằng Windows API OpenDesktop

- Đọc và lưu giữ handle của desktop hiện tại mà service đang hoạt động bằng API GetThreadDesktop

- Gán service thread sử dụng WinLogon desktop bằng API SetThreadDesktop

- Thực hiện việc vẽ hoặc xuất thông báo bằng các GDI, API

- Phục hồi desktop cũ mà service hoạt động và đóng WinLogon desktop bằng API SetThreadDesktop

Dưới đây là đoạn mã tham khảo:

Biến lưu giữ desktop hiện tại để phục hồi sau khi thực hiện xong tương tác

HDESK hCurrDesk = NULL;

Mở WinLogon desktop

HDESK hDesktop = ::OpenDesktop(_T(“Winlogon”), 0, FALSE, GENERIC_ALL);

if (NULL != hDesktop)

{

Đọc / lưu giữ desktop hiện tại (default) và chuyển sang WinLogon desktop

hCurrDesk =::GetThreadDesktop(::GetCurrentThreadId());

Gán WinLogon desktop cho thread hiện tại của service

if (!::SetThreadDesktop(hDesktop))

{

::CloseDesktop(hDesktop);

hCurrDesk = NULL;

}

}

Xuất một thông báo lên desktop hiện tại của thread, chính là WinLogon desktop

HDC hDC = ::GetWindowDC(NULL);

TCHAR strMsg[] = _T(“Message on WinLogon desktop of Windows XP”);

DrawTextDC(hDC, strMsg, 200, 200);

Quay lại desktop cũ sau khi đã thực hiện xong việc tương tác

if (NULL != hCurrDesk)

{

::CloseDesktop(hDesktop);

::SetThreadDesktop(hCurrDesk);

}

Phương thức tiện ích xuất một chuỗi thông báo có thể hiện thực như sau:

void DrawTextDC(HDC hdc, LPTSTR str, int x, int y)

{

LOGFONT lf;

HFONT hFont;

Lưu trữ device context (DC) hiện tại để phục hồi sau khi vẽ

::SaveDC(hdc);

Tạo kiểu font chữ cho chuỗi thông báo

memset(&lf, 0, sizeof(LOGFONT));

lf.lfWeight = FW_BOLD;

lf.lfHeight = 22;

_tcscpy(lf.lfFaceName, _T(“Arial”));

hFont = ::CreateFontIndirect (&lf);

Sử dụng font vừa tạo cho device context hiện tại

hFont = (HFONT)::SelectObject (hdc, hFont);

Thiết lập hiệu ứng nền trong suốt và màu chữ

::SetBkMode(hdc, TRANSPARENT);

::SetTextColor(hdc, ::GetSysColor(COLOR_3DFACE));

Vẽ bóng chữ

::SetTextColor(hdc, COLORREF(RGB(111, 111, 111)));

::TextOut(hdc, x, y, str, _tcslen(str));

Vẽ thông báo

::SetTextColor(hdc, COLORREF(RGB(255, 255, 255)));

::TextOut(hdc, x - 2, y - 2, str, _tcslen(str));

:eleteObject(SelectObject (hdc, hFont));

Phục hồi DC cũ

::RestoreDC(hdc, -1);

}

Tương tác với WinLogon desktop trong Windows Vista

Với Windows Vista, các service bắt buộc hoạt động ở session 0 và ứng dụng của người dùng sẽ hoạt động ở các session còn lại với đặc quyền hạn chế. Service chạy ở session 0 sẽ không có khả năng tương tác với desktop cũng như lấy các thông tin liên quan đến đồ họa và tiến trình WinLogon cho mỗi người dùng sẽ hoạt động bắt đầu ở session 1 trở đi. Các thông số cho phép tạo service tương tác trong Services Management Console từng hoạt động tốt trên Windows XP sẽ vô hiệu trên Windows Vista. Thuật ngữ kĩ thuật gọi sự thay đổi này là session 0 isolation. Điều này dẫn đến việc tạo một service tương tác với cửa sổ WinLogon không còn đơn giản như ở các phiên bản trước vì bây giờ service và tiến trình WinLogon nằm ở hai session khác nhau được bảo vệ chặt chẽ bởi cơ chế bảo mật của Windows Vista.



Hình 6 - Mô hình ứng dụng và service hoạt động trong các session của Windows Vista

Hình 7 - Các service ở session 0 và WinLogon ở session 1 trở đi trên Windows Vista

Tương tác với WinLogon desktop từ một service trong Windows Vista

Mặc dù không cho phép trực tiếp truy xuất đến giao diện từ service ở session 0, Vista cho phép service gọi thực thi một ứng dụng ở session khác, hoặc trao đổi với ứng dụng đó dạng client – server thông qua các lời gọi RPC hoặc IPC named pipe, socket hoặc shared memory.

Như vậy mọi chuyện đã trở nên rõ ràng hơn, thay vì thực hiện thao tác vẽ ngay trong service như ở Windows XP, từ service ở session 0 ta sẽ gọi thực thi một ứng dụng ở cùng session với tiến trình WinLogon, tức là session 1, 2,... Ứng dụng ẩn này sau đó sẽ thực hiện việc tương tác tương tự như với Windows XP.

Hình 8 - Service tương tác thông qua một ứng dụng ẩn trong Windows Vista

Ta sẽ phác thảo các bước thực hiện như sau:

- Trong service, tìm tiến trình WinLogon để lấy được access token của người dùng thuộc session tương ứng mà WinLogon đang hoạt động.

- Tạo bản sao token này và tạo thông tin môi trường để áp dụng cho việc thực thi tiến trình ẩn. Phương pháp này gọi là impersonate user token.

- Tạo tiến trình để thực thi ứng dụng ẩn bằng API CreateProcessAsUser với access token vừa lấy ở trên.

- Ứng dụng ẩn này sẽ mở và tương tác với màn hình WinLogon.

Giải pháp trên được hiện thực với mã ví dụ sau, cài đặt trong ServiceMain:

#include

#include

PROCESS_INFORMATION processInfo;

STARTUPINFO startupInfo;

DWORD dwWinlogonPid = 0;

HANDLE hPToken, hProcess;

Tìm tiến trình WinLogon để lấy access token tương ứng. Ví dụ chỉ áp dụng cho trường hợp tương tác với màn hình Winlogon khi chưa có người dùng đăng nhập, nên giả định lúc này chỉ có duy nhất một tiến trình WinLogon hoạt động ở session khác 0

PROCESSENTRY32 procEntry;

HANDLE hSnap = ::CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);

if (hSnap == INVALID_HANDLE_VALUE) return FALSE;

procEntry.dwSize = sizeof(PROCESSENTRY32);

if (!:rocess32First(hSnap, &procEntry)) return FALSE;

do

{

if (_stricmp(procEntry.szExeFile, _T(“WinLogon.exe”)) == 0)

{

// Để mở rộng, bạn có thể kiểm tra SessionID của tiến trình WinLogon tương ứng

dwWinlogonPid = procEntry.th32ProcessID;

break;

}

} while (:rocess32Next(hSnap, &procEntry));

Đọc access token của tiến trình WinLogon

hProcess = ::OpenProcess(MAXIMUM_ALLOWED, FALSE, dwWinlogonPid);

DWORD dwUserResponse;

if (!::OpenProcessToken(hProcess,TOKEN_ADJUST_PRIVILE GES|TOKEN_QUERY
|
TOKEN_DUPLICATE|TOKEN_ASSIGN_PRIMARY|TOKEN_ADJUST_ SESSIONID

|TOKEN_READ|TOKEN_WRITE,&hPToken))

{

// Xử lý lỗi không đọc được token }

Bạn có thể impersonate một token và tạo thông tin môi trường ở đây bằng các API DuplicateTokenEx và CreateEnvironmentBlock, tuy nhiên để đơn giản, trong ví dụ này tôi sẽ sử dụng trực tiếp primary token của tiến trình WinLogon khi thực thi ứng dụng ẩn

ZeroMemory(&processInfo, sizeof(processInfo));

ZeroMemory(&startupInfo, sizeof(STARTUPINFO));

Chỉ định ứng dụng ẩn dạng console sẽ hoạt động ở Winlogon desktop của Winsta0, trong cùng session với tiến trình WinLogon

startupInfo.cb = sizeof(STARTUPINFO);

startupInfo.lpDesktop = _T(“Winsta0\\Winlogon”);

startupInfo.dwFlags = STARTF_USESHOWWINDOW;

startupInfo.wShowWindow = SW_HIDE;

Tạo một tiến trình mới thực thi ứng dụng ẩn sử dụng access token của tiến trình WinLogon, đồng nghĩa với việc ứng dụng ẩn của chúng ta sẽ hoạt động cùng session với WinLogon

Trong ví dụ này, giả định ứng dụng ẩn đã được tạo tại C:\Z0rr0\MyTools\HiddenApp.exe

if (!::CreateProcessAsUser(hPToken,

_T(“C:\\Z0rr0\\MyTools\\HiddenApp.exe”),

NULL, NULL, NULL, FALSE, NORMAL_PRIORITY_CLASS,

NULL, NULL, &startupInfo, &processInfo)

{

// Xử lý lỗi không tạo được process

}

CloseHandle(hPToken);

CloseHandle(hProcess);

Để hoàn tất một service tương tác hoạt động cho cả Windows XP và Vista, trong ServiceMain ta cần xác định phiên bản Windows trước khi thực hiện phương pháp tương tác tương ứng.

Chuẩn bị dữ liệu để đọc phiên bản Windows đang dùng

OSVERSIONINFOEX osvi;

BOOL bOsVersionInfoEx;

ZeroMemory(&osvi, sizeof(OSVERSIONINFOEX));

osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);

if( !(bOsVersionInfoEx = GetVersionEx((OSVERSIONINFO *) &osvi)) )

{

osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);

if ( !GetVersionEx((OSVERSIONINFO*) &osvi))

return FALSE;

}

Xác định phiên bản Windows để thực hiện việc tương tác phù hợp

if (osvi.dwPlatformId == VER_PLATFORM_WIN32_NT)

{

if ( osvi.dwMajorVersion == 6 && osvi.dwMinorVersion == 0 )

{

Thực hiện tương tác trên Windows Vista hoặc Longhorn server

}

else if ( osvi.dwMajorVersion == 5 && osvi.dwMinorVersion == 1 )

{

Thực hiện tương tác trên Windows XP workstation

}

else return FALSE;

}

Việc còn lại là tạo một ứng dụng ẩn HiddenApp.exe dạng Windows console bằng Visual Studio C++, có mã như sau:

#include

Hàm vẽ DrawTextDC đã được hiện thực ở ví dụ với Windows XP

void DrawTextDC(HDC hdc, LPTSTR str, int x, int y);

int _tmain(int argc, _TCHAR* argv[])

{

HDC hDC = GetWindowDC(NULL);

TCHAR strMsg[ ] = _T(“Message on WinLogon desktop of Windows Vista”);

DrawTextDC(hDC, strMsg, 200, 200);

return 0;

}

Lưu ý: Các đoạn mã ví dụ trên chỉ mang tính tham khảo, bạn cần điều chỉnh để phù hợp với yêu cầu thực tế của mình hoặc có thể tham khảo mã nguồn kèm theo bài viết này.

Khi đã hoàn tất việc biên dịch service và ứng dụng ẩn, để kiểm nghiệm kết quả bạn cần phải chạy cửa sổ dòng lệnh Command Prompt cmd.exe dưới quyền quản trị (Run as Administrator) trước khi thực hiện lệnh sc.exe để cài đặt service vào hệ thống Windows Vista và đồng thời chép ứng dụng ẩn vào vị trí được chỉ định trong lệnh gọi của service. Cuối cùng là khởi động lại hệ thống và chờ một khoảng thời gian ngắn trước khi đăng nhập để service của bạn tự động chạy và xuất thông điệp lên màn hình.
Bài viết đề cập đến nhiều thuật ngữ và vấn đề lập trình hệ thống và bảo mật trên Windows, đặc biệt là Windows Vista. Hy vọng đây sẽ là đề tài mở để các bạn bắt tay tìm hiểu một vùng đất mới, màu mỡ nhưng cũng không kém phần phức tạp. Chúc các bạn thành công.
_____________

[Reverse] Taskkill.exe tắt process bằng API nào

Taskkill.exe tắt process bằng API nào

Link: http://virusvn.com/forum/printthread.php?t=1569&pp=40


gianghoplus 08-02-2009 03:59 AM

Taskkill.exe tắt process bằng API nào ?
Không biết là Taskkill.exe của Windows xài API nào để kill process nhỉ. Xem import ở PE thì thấy có TerminateProcess nhưng thử chặn 2 hàm TerminateProcess và EndTask rồi mà vẫn không có kết quả. Giả thuyết cuối của gianghoplus là nó dùng WMI. Mình đang bí. Các bác có cao kiến gì không ?





TQN 08-02-2009 01:01 PM

Trên máy tui, search *kill*.exe ra 1 đống *kill.exe:
1. kill.exe của WinDbg
2. pskill.exe của SysInternal
3. tskill.exe của MS
4. taskkill.exe của MS

Trong đống trên, pskill là phức tạp nhất, taskkill của MS đứng nhì. Nhưng RE taskkill.exe thì dể hơn vì ta có thể lấy pdb symbol file của nó.

Taskkill.exe được viết = VC++ 2003, viết theo OOP. Chủ đạo của taskkill là class CTaskKill, làm tất tần tật, parse cmd line, kill, kết nối remote machine...

Trên local machine, CTaskKill có 2 method private:
int __thiscall CTaskKill::KillProcessOnLocalSystem(int &)
int __thiscall CTaskKill::ForciblyKillProcessOnLocalSystem(void)

Thông số /F sẽ gọi hàm Forciblyxxx, còn không thì gọi KillProcessxxx

Hàm KillProcessOnLocalSystem chỉ dùng PostMessage với WM_CLOSE tới window của PID hay IM chỉ ra
Hàm ForciblyKillProcessOnLocalSystem thì dùng OpenProcess với param PROCESS_TERMINATE | PROCESS_QUERY_INFORMATION, kiểm tra status của process với hàm API GetExitCodeProcess. Nếu process còn STILL_ACTIVE thì call API TerminateProcess.

Code:

.text:01003447 private: int __thiscall CTaskKill::ForciblyKillProcessOnLocalSystem(void) proc near
.text:01003447 ; CODE XREF: CTaskKill::Kill(int &):loc_100476Dp
.text:01003447
.text:01003447 ExitCode= dword ptr -4
.text:01003447
.text:01003447 push ebp
.text:01003448 mov ebp, esp
.text:0100344A push ecx
.text:0100344B and [ebp+ExitCode], 0
.text:0100344F push esi
.text:01003450 push dword ptr [ecx+58h] ; dwProcessId
.text:01003453 push 0 ; bInheritHandle
.text:01003455 push 401h ; dwDesiredAccess
.text:0100345A call ds:OpenProcess(x,x,x) ; Opens an existing process object.
.text:0100345A
.text:01003460 mov esi, eax
.text:01003462 test esi, esi
.text:01003464 jz short @@TerminateProcess_Failed
.text:01003464
.text:01003466 lea eax, [ebp+ExitCode]
.text:01003469 push eax ; lpExitCode
.text:0100346A push esi ; hProcess
.text:0100346B call ds:GetExitCodeProcess(x,x) ; Retrieves the termination status of the specified process.
.text:0100346B
.text:01003471 test eax, eax
.text:01003473 jnz short @@ProcessStillActive
.text:01003473
.text:01003475 push esi ; hObject
.text:01003476 call ds:CloseHandle(x) ; Closes an open object handle
.text:01003476
.text:0100347C jmp short @@Return_FALSE
.text:0100347C
.text:0100347E ; ---------------------------------------------------------------------------
.text:0100347E
.text:0100347E @@ProcessStillActive: ; CODE XREF: CTaskKill::ForciblyKillProcessOnLocalSystem(void)+2Cj
.text:0100347E cmp [ebp+ExitCode], STILL_ACTIVE
.text:01003485 jz short @@TerminateProcess
.text:01003485
.text:01003487 push esi ; hObject
.text:01003488 call ds:CloseHandle(x) ; Closes an open object handle
.text:01003488
.text:0100348E push SCHED_E_TASK_NOT_RUNNING
.text:01003493 jmp short @@SetComLastError
.text:01003493
.text:01003495 ; ---------------------------------------------------------------------------
.text:01003495
.text:01003495 @@TerminateProcess: ; CODE XREF: CTaskKill::ForciblyKillProcessOnLocalSystem(void)+3Ej
.text:01003495 push 1 ; uExitCode
.text:01003497 push esi ; hProcess
.text:01003498 call ds:TerminateProcess(x,x) ; Terminates the specified process and all of its threads.
.text:01003498
.text:0100349E test eax, eax
.text:010034A0 push esi ; hObject
.text:010034A1 jnz short @@Return_TRUE
.text:010034A1
.text:010034A3 call ds:CloseHandle(x) ; Closes an open object handle
.text:010034A3
.text:010034A9
.text:010034A9 @@TerminateProcess_Failed: ; CODE XREF: CTaskKill::ForciblyKillProcessOnLocalSystem(void)+1Dj
.text:010034A9 call ds:GetLastError() ; Retrieves the calling thread's last-error code value.
.text:010034A9 ; The last-error code is maintained on a per-thread basis.
.text:010034A9
.text:010034AF cmp eax, ERROR_INVALID_PARAMETER
.text:010034B2 jnz short @@Return_FALSE
.text:010034B2
.text:010034B4 push CO_E_NOT_SUPPORTED ; dwErrCode
.text:010034B4
.text:010034B9
.text:010034B9 @@SetComLastError: ; CODE XREF: CTaskKill::ForciblyKillProcessOnLocalSystem(void)+4Cj
.text:010034B9 call ds:SetLastError(x) ; Sets the last-error code for the calling thread.
.text:010034B9
.text:010034BF
.text:010034BF @@Return_FALSE: ; CODE XREF: CTaskKill::ForciblyKillProcessOnLocalSystem(void)+35j
.text:010034BF ; CTaskKill::ForciblyKillProcessOnLocalSystem(void)+6Bj
.text:010034BF call SaveLastError()
.text:010034BF
.text:010034C4 xor eax, eax
.text:010034C6 jmp short @@Return
.text:010034C6
.text:010034C8 ; ---------------------------------------------------------------------------
.text:010034C8
.text:010034C8 @@Return_TRUE: ; CODE XREF: CTaskKill::ForciblyKillProcessOnLocalSystem(void)+5Aj
.text:010034C8 call ds:CloseHandle(x) ; Closes an open object handle
.text:010034C8
.text:010034CE xor eax, eax
.text:010034D0 inc eax
.text:010034D0
.text:010034D1
.text:010034D1 @@Return: ; CODE XREF: CTaskKill::ForciblyKillProcessOnLocalSystem(void)+7Fj
.text:010034D1 pop esi
.text:010034D2 leave
.text:010034D3 retn
.text:010034D3
.text:010034D3 private: int __thiscall CTaskKill::ForciblyKillProcessOnLocalSystem(void) endp
.text:010034D3

CTaskKill trước gọi method Kill để kill PID/IM ta chỉ ra trong command line. Trong method Kill, nó gọi method CanTerminate. CanTerminate return FALSE nếu PID/IM của ta chỉ ra là 1 trong 4 system process sau: csrss.exe, smss.exe, services.exe, winlogon.exe.

Với remote machine, Kill method call private method: int __thiscall CTaskKill::ForciblyKillProcessOnRemoteSystem(void) . Method này dùng WMI command để kill.

Cpro 08-02-2009 01:08 PM



cho em hỏi nhỏ làm sao bác biết được tên của hàm,class của source thế

TQN 08-02-2009 01:15 PM

Dùng symchk.exe của WinDbg để lấy taskkill.pdb. File pdb này là public symbol.
Apply taskkill.pdb vào IDA và WinDbg/OllyDbg.

TQN 08-04-2009 04:30 AM

Với các process có window, cho dù có visible hay không, taskkill vẫn kill được dùng PostMessage(WM_CLOSE,....), còn nếu không có window, taskkill sẽ print ra error và yêu cầu chúng ta dùng thông số /F (Force kill).


[Virus] Cách sử dụng ardamax keylogger và cách diệt

Cách sử dụng ardamax keylogger và cách diệt

Link: http://flobg88.blogspot.com/2009/08/cach-su-dung-ardamax-keylogger-va-cach.html

Bước đầu tiên là tạo con keylog ardamax keylogger > tấn công victim













Khi send cho victim rồi giờ chỉ ngồi chờ log thôi




Bước 2 : Chui vào hang cọp để bắt cọp nào )




Bình thường anh em nháy chuột phải vào thanh toolsbar bên dưới

Chọn > nháy chuột phải vào




anh em có thể thấy ko nhìn đc process của nó chạy trong task manager

Sau khi anh em vào Start > chọn run > gõ cmd >> gõ lệnh tasklist anh em sẽ thấy process sau của con keylog






Muốn kill con keylog này trước tiên anh em phải kill process của nó đang chạy bằng lệnh đơn giản như sau

Quote:
taskkill /f /im "tên tiến trình virus"
taskill /f /pid " số tiến trình của virus "
Ví dụ ở đây process của con keylog này là jcot.exe
Và pid của nó là 324 >> anh em làm theo 2 cách sau

1 là taskill theo process 2 là taskill theo số )

Quote:
taskill /f /im jcot.exe
Hoặc
Quote:
taskkill /f /pid 324
Bước cuối cùng là nhổ cỏ tận gốc thì anh em xem hình sau đây mà xóa hết tàn dư của chúng



Các soft sử dụng

Quote:

http://www.4shared.com/file/106966873/f531ec18/ardamax_keylogger_31.html
http://www.4shared.com/file/106972642/11871ca0/Sandboxie_324.html
Giờ chuẩn bị quay lại virus nghịch tý nhưng giờ mình lại thích về trojan >> các bạn nào có trojan ( keylog ) nào ngon ngon thì send qua mail cho mình nhé !
Mail của mình là : FLobg88@banbeit.com

Theo cách trên 1 phần bạn có thể kiểm soát file nghi là keylog của người khác send cho mình xem có ám khí gì ko bằng sandboxie )

Cảm ơn các bạn đã ghé thăm topic

Writing by Flobg88 >> member of Deface Virus TEAM