Những người tham gia chương trình AdSense (tạm gọi là các publisher) đều phải tuân thủ các chính sách dưới đây. Chúng tôi yêu cầu các bạn nên đọc kỹ các chính sách này một cách cẩn thận và thường xuyên xem lại nó để tránh mắc lỗi. Nếu bạn không tuân thủ các chính sách này, chúng tôi sẽ không hiển thị các quảng cáo trên website của bạn nữa và sẽ vô hiệu hóa/đóng tài khoản AdSense của bạn vĩnh viễn. Trong nhiều trường hợp, chúng tôi thích làm việc với các Publisher để giải quyết các tranh chấp và khiếu nại nhưng CHÚNG TÔI LÀ NGƯỜI CÓ QUYỀN QUYẾT ĐỊNH VÔ HIỆU HÓA BẤT CỨ MỘT TÀI KHOẢN NÀO VÀO BẤT KỲ THỜI GIAN NÀO. Nếu tài khoản của bạn bị vô hiệu hóa, thì có nghĩa bạn SẼ KHÔNG BAO GIỜ ĐƯỢC PHÉP THAM GIA VÀO CHƯƠNG TRÌNH ADSENSE NỮA. Xin các bạn lưu rằng chúng tôi có thể thay đổi các chính sách của mình vào bất kỳ thời gian nào và chiểu theo các điều khoản tham gia của chúng tôi. Trách nhiệm của các bạn là phải thường xuyên theo dõi những thay đổi trong chính sách tại trang website của chúng tôi và áp dụng ngay những thay đổi đó.Các click và impression không hợp lệ Khuyến khích click Để đảm bảo chất lượng dịch vụ cung cấp cho người truy cập, các publisher và các nhà quảng cáo (advertiser), các publishers không được đề nghị người truy cập click vào các quảng cáo trên trang website/blog của họ hay đáp lại băng cách phương pháp mang tính gian lận/lừa đảo nhằm có nhiều click. Các Publishers tham gia vào chương trình AdSense:
Các click trên các quảng cáo của Google phải băt nguồn từ sự quan tâm thực sự của người truy cập vào trang website đó. Bất cứ một phương pháp nhân tạo nào nhằm tạo ra nhiều click và impression không hợp lệ trên các quảng cáo của Google AdSense trên website của bạn đều bị nghiêm cấm. Nhưng phương pháp bị cấm này bao gồm nhưng không giới hạn đối với các click, impression lặp đi lặp lại bằng tay, có sử dụng robot, các công cụ tự động click hoặc tự động mở website, các dịch vụ của bên thứ 3 như: click-để-nhận tiền (paid-to-click), lướt-để-nhận tiền (paid-to-surf), tự lướt web (autosurf), và các chương trình trao đổi click (click-exchange), hoặc bất cứ một chương trình/phần mềm lừa đảo nào. Xin lưu ý rằng click trên chính các quảng cáo của bạn vì bất cứ lý do gì đều bị nghiêm cấm. Việc không tuân thủ chính sách này có thể dẫn đến việc vô hiệu hóa/khóa tài khoản của bạn.
* Không thể khuyến khích người truy cập click vào các quảng cáo AdSense bằng việc sử dụng các lời mời chào như: "hãy click vào quảng cái (click ads)," "ủng hộ chúng tôi (support us)," "hãy truy cập các đường link này (visit these links)," hay đại loại sử dụng các chiêu bài có nội dung tương tự bằng các ngôn ngữ tương tự
* Không thể hướng người truy cập tới các quảng cáo bằng việc đặt các mũi tên hoặc các máng lới/mẹo quảng cáo khác
* Không thể đặt các hình ảnh dễ làm cho người truy cập lầm tưởng dọc theo các quảng cao của AdSense
* Không thể quảng bá các website của bạn bằng việc đặt các quảng cáo thông qua các hệ thống email không được yêu cầu hoặc các dịch vụ quảng cáo không mong muốn của các website của bên thứ 3
* Không thể bồi thường/trả công cho người truy cập xem các quảng cáo hoặc tìm kiếm thông qua công cụ của bạn, hoặc hứa hẹn trả công cho bên thứ 3 khi làm chuyện đó
* Không thể đặt các biển hiệu dễ gây nhầm lẫn như đã nói ở trên – ví dụ: các quảng cáo có thể đặt tên là “các đường link của nhà tài trợ (Sponsored Links)" nhưng không thể đặt tên là “các trang được yêu thích (Favorite Sites)" hoặc tương tự như thế.
Nội dung website
Google cho phép tiếp cận tới hầu hết các nội dung trong trang tìm kiếm, các publisher trong chương trình AdSense chỉ có thể đặt các quảng cáo trên các trang có tuân thủ các quy định của chương trình AdSense, và các quảng cáo không được phép đặt trên bất cứ một trang nào mà ngôn ngữ của trang đó không được hỗ trợ. Xem danh sách các ngôn ngữ được Google hỗ trợ đến thời điểm này.
Các website hiển thị các quảng cáo AdSense không bao gồm:
* Có nội dụng bạo lực/phân biệt chủng tộc/sắc tộc, hoặc vận động chống lại bất cứ một cá nhân nào, nhóm nào hoặc tổ chức nào
* Có nội dung khiêu dâm, mang tính người lớn hoặc nội dung dành cho người trưởng thành
* Có nội dung hack/crack
* Có nội dụng về thuốc trái phép/lậu và các đồ dùng cá nhân liên quan đến thuốc/dược phẩm
* Có nổi dụng tục tĩu/chửi thề/xúc phạm và nội dung báng bổ thái quá
* Đánh bạc kiếm tiền và các nội dung liên quan đến casino
* Các nội dụng liên quan đến các chương trình mang tính khích lệ người truy cập click vào các quảng cáo hoặc có tính khuyến mại khi ai đó tìm kiếm, lướt web và đọc email ăn tiền
* Có các từ khóa không phù hợp, thái quá và lặp trên nội dung và các mã của trang website
* Có nội dung dối trá/lừa đảo và có tính lôi cuốn hoặc mang tính xây dựng nhằm cải thiện cho website vị thế website của bạn. Ví dụ như: xếp hạng trang website của bạn (PageRank)
* Có nội dung mua bán hoặc quảng bá vũ khí hoặc quân trang (ví dụ: súng cầm tay các loại, dao dành cho chiến đấu, các loại súng sat thương….)
* Có nội dung mua bán hoặc quảng bá beer hoặc rượu mạnh
* Có nội dung mua bán hoặc quảng bá thuốc lá và các sản phẩm liên quan đến thuốc lá (tobacco)
* Có nội dung mua bán hoặc quảng bá toa thuốc
* Có nội dung mua bán hoặc quảng bá các sản phẩm là các tác phẩm mô phỏng/làm giả/sao chép các tác phẩm nghệ thuật của người khác
* Có nội dung mua bán hoặc phân phát luận án và bài văn của sinh viên (essay)
* Có bất cứ một nội dung khác nào bất hợp pháp, quảng bá cho các hoạt động phi pháp, hoặc xâm phạm quyền hợp pháp của người khác.
Các tài liệu được bảo về bản quyền
Các publishers sở hữu các website không được đăng các quảng cáo của AdSense trên các trang được bảo vệ bản quyền trừ khi họ có quyền hợp pháp để đăng trên website đó. Bạn có thể xem chính sách DMCA của chúng tôi để biết thêm thông tin.
Hướng dẫn cho các Webmaster
Các publisher tham gia chương trình AdSense cần phải tuân theo các hướng dẫn về chất lượng được đăng tại trang hướng dẫn cho các webmaster
Các hoạt động của các website và các quảng cáo
Các website hiển thị các quảng cáo AdSense nên đơn giản cho người truy cập hướng tới và không nên có các pop-up thái quá. Mã AdSense không thể được thay đổi hoặc có những cách điều chỉnh nhằm thu hút người truy cập dưới mọi hình thức đều không được chấp nhận bởi Google.
* Các website hiển thị các quảng cáo AdSense không thể chứa các pop-up hoặc các dạng pop-under mà khi mở ra sẽ đụng chạm với các thanh điều hướng của trang website (navigation), thay đổi sở thích của người sử dụng, hoặc đề xướng downloads.
* Bất cứ một mã AdSense nào cũng đều phải được chèn trực tiếp vào các trang mà không được điều chỉnh gì hết. Những người tham gia chương trình AdSense không được phép thay đổi bất kỳ một phẩn nào của mã hoặc thay đổi hoạt động, kết quả đích hoặc cách hiển thị các quảng cáo. Ví dụ: các click lên quảng cáo AdSense không thể hiện thị trên một trang hoàn toàn mới mà phải hiện thị ngay trên trang website của bạn.
* Một website hoặc một bên thứ 3 không thể đặt các quảng cáo của AdSense, các công cụ tìm kiếm, kết quả tìm kiếm, hoặc các phím giới thiệu người khác tham gia trên bất ký phần mềm nào như toolbar (thanh công cụ)..
* Không một mã AdSense nào có thể được tích hợp vào bất ký một phần mềm nào.
* Các trang chứa nội dung mã AdSense không thể được tải bằng bất kỳ phần mềm nào mà phần mềm đó sử dụng pop-up, hướng người truy cập tới các trang website không mong muốn, chỉnh sửa chế độ cài đặt của trình duyệt, hoặc đụng chạm/gây trở ngại cho các thanh điều hướng của trang web. Trách nhiệm của bạn là phải đảm bảo rằng không một mạng lưới quảng cáo/chương trình môi giới nào sử dụng các phương pháp tương tự để thu hút lượng truy cập tới các website của bạn hiện đã có chèn các mã AdSense.
* Việc đặt các banner của các chương trình referral phải được đưa ra mà không có bất kỳ một ràng buộc nào nhằm vô hiệu hóa tài khoản nếu họ không sử dụng chương trình do bạn giới thiệu. Các publisher không được níu kéo/thu hút địa chỉ email từ người truy cập có liên kết tới các phần có chương trình referral của AdSense.
* Các publisher sử dụng quảng cáo trực tuyến để hướng người truy cập tới các trang có hiển thị quangrcaos của AdSense đều phải tuân thủ tinh thần của Google tại trang các hướng dẫn về chất lượng của trang web. Ví dụ: nếu bạn quảng cáo cho các website đangtham gia chương trình AdSense, thì việc quảng cáo đó không được mang tính lừa đảo khách hàng/người truy cập.
Vị trí đặt quảng cáo
AdSense đưa ra hàng loạt định dạng quảng cáo và các sản phẩm quảng cáo. Các publisher được khuyến khích thử nghiệm với hàng loạt các vị trí, miễn là tôn trọng các chính sách sau đây:
* Tối đa có thể đặt 3 đơn vị quảng cáo trên một trang.
* Tối đa 2 hộp tìm kiếm của AdSense có thể đặt trên một trang.
* Tối đa 3 đường link quảng cáo cũng có thể đặt trên một trang.
* Tối đa 2 banner giới thiệu (referral) của mỗi một chương trình giới thiệu có thể đặt trên một trang bên cạnh các đơn vị quảng cáo, link quảng cáo và hộp tìm kiếm như đã đề cập ở trên.
* AdSense cho các trang kết quả tìm kiếm có thể chỉ hiện thị một đường link quảng cáo bên cạnh các kết quả tìm kiếm được Google cung cấp. Không một quảng cáo nào khác có thể được hiển thị trên trang kết quả tìm kiếm của bạn.
* Không đặt hộp tìm kiếm của Google dưới dạng pop-up, pop-under, hoặc trong các email.
* Các thành tố trên một trang không được phép làm mờ đi bất cứ một phần nào của các quảng cáo.
* Không được đặt quảng cáo trên các trang mà không có nội dung thực sự.
* Không một quảng cáo của Google nào được đặt trên các trang được làm ra chỉ với mục đích đơn thuần là quảng cáo, không cần biết nội dung của trang website đó là phù hợp hay không phù hợp.
Các dịch vụ và các quảng cáo mang tính cạnh tranh
Để bảo vệ người truy cập không bị nhầm lẫn, chúng tôi không cho phép các quảng cáo hay các hộp tìm kiếm của Google được đặt trên những trang nào có mà các quảng cáo/dịch vụ của các nhà quảng cáo khác có cùng định dạng, màu sắc như các quảng cáo hoặc hộp tìm kiếm của AdSense. Mặc dù, bạn có thể bán các quảng cáo trực tiếp trên website của mình, nhưng bạn phải có trách nhiệm đảm bảo các quảng cáo đó không thể nhầm lẫn với các quảng cáo của AdSense được.
Friday, October 26, 2007
Google Adsense cho người Việt Nam
Một số luật quy định của GA - Những người mới làm nên biết
Đây là một vài điều mà bạn cần quan tâm khi sử dụng Google Adsense( viết tắt GA) để tránh bị khóa tài khoản.
1.Không được phép mua, bán, trao đổi hay chuyển nhượng tài khoản GA. Khi website bạn đang sử dụng bán lại cho người khác, bạn phải thông báo với Google Adsense Team xin xóa bỏ tài khoản. Người quản lý mới sẽ có quyền đăng ký tài khoản mới trên website đó.
2.Không được click vào GA của chính bạn . Những click ảo (ma) là không được chấp nhận . Nếu click nhiều lần tài khoản của bạn sẽ bị khóa. Đây là sai lầm lớn nhất của các Webmaster mới tham gia quảng cáo trực tuyến (trên website).
3. Không bảo người khác click vào ads của bạn . Có rất nhiều người nghĩ rằng mình không click thì có thể bảo người khác click để kiếm thêm thu nhập Chính điều này là một vi phạm nghiêm trọng . Tôi và bạn đều không hiểu Google làm thế nào để phát hiện ra sự vi phạm này . Tuy nhiên luật GA đã đưa ra thì nên tuân thủ . Nếu bạn tôn trọng đối tác , nhà quảng cáo (Advertisers) thì chắc chắn bạn sẽ làm được thôi. Hãy để mọi việc được tự nhiên, như T và K ấy!
4. Không đặt GA trên một trang popup hay một chương trình được cài đặt. Trang Popup là trang tự động mở bởi các Script mà chúng ta dễ dàng nhận thấy trên một vài Website. Điều này quá dễ để Google nhận ra . Bởi các Script của GA sẽ tự động thông báo cho Robots quản lý. Một vài chương trình cho bạn cài đặt, sử dụng miễn phí , ngược lại bạn phải đồng ý là nó sẽ hiện quảng cáo. các nhà tài trợ . Tất nhiên họ sẽ không được đặt quảng cáo của GA trên đó nếu không họ sẽ bị trả giá.
5. Không được sửa GA code . Bạn chỉ có thể sửa các giá trị hiển thị màu sắc. Và đặt trực tiếp vào Website, không thông qua một Script khác.
6.Không đặt quảng cáo của Google trên third frame (frame thứ ba).
7. Không được đặt phía trên của GA những từ có nội dung khuyến khích click như: Click Me, Click here, Click here to support, hot links, other articles… nếu bị phát hiện thì bạn sẽ bị khóa tài khoản ngay lập tức thậm chí khóa luôn Domain của bạn bởi googlesyndication .Điếu đó có nghĩa là Website của bạn sẽ không bao giờ được tham gia vào chương trình này nữa.Theo luật của GA về labels ads thì bạn chỉ có quyền lựa chọn một trong hai: hoặc Sponsored Links , hoặc Advertisements. Nếu bạn đặt label cho ads bằng ngôn ngữ không hỗ trợ như Vietnamese thì coi chừng. Họ chẳng cần hiểu ý nghĩa của câu bạn nói là gì, họ sẽ thẳng thừng lock tài khoản của bạn và lock luôn domain nơi bạn đang sử dụng đó. Theo tôi thì chúng ta chẳng cần đặt label cho ads làm gì.
8 .Không được ẩn các chữ hiển thị của GA. Bạn có thể chỉnh sửa các giá trị màu sắc tuy nhiên không được làm nó mất đi một phần chữ hiển thị . Ví dụ như bạn chọn color của backround (nền) là :FFFFFF(màu trắng), và color text cũng là: FFFFFF thì hiển nhiên các text của GA sẽ bị biến mất cùng background , hay nói chính xác là visitor không nhìn thấy các từ description.
9. Không được lừa bịp GA. Có quá nhiều người trong chúng ta cố gắng thử tài lừa GA hoặc ít nhất cũng nghĩ rằng mình có thể lừa GA. Tốt nhất là những ý định đó hãy biến đi trong đầu của bạn . Bạn phải luôn quan niệm: ta sẽ tôn thủ đối tác ( nhà quảng cáo chứ không phải GA). Nếu hiểu được điều này bạn sẽ hiểu mọi sự lừa bịp của bạn đều là ngu ngốc cả. GA thông minh hơn ta tưởng . Họ đã bỏ ra nhiều thời gian , nhiều tiền của để nghiên cứu công nghệ không dễ gì lừa họ đâu.
10. Nội dung site của bạn phải:
-Không liên quan đế P0RN, GAMBLING (cờ bạc, cá độ) hay nội dung trái luật pháp, bạo lực, khủng bố, hàng cấm, tôn giáo, hay ảnh hưởng đến cá nhân, nhóm người, tổ chức khác.
-Không được chèn thêm quá nhiều những từ khóa thừa thãi, hoặc không liên quan đến nội dung chính.
-Không tạo nhiều site có nội dung giống nhau hoặc tương tự .
-Không bán hoặc giới thiệu vũ khí,bia, rượu, chất kích thích,thuốc kích thích, kích dục,… thuốc lá
-Không có nội dung về Pay to surf, pay to read email .
-Không đặt Google Adsense trong những trang đòi hỏi đăng nhập.
-Không được mở quảng cáo GA trong cửa sổ mới theo mặc định. Nhiều webmaster muốn mở quảng cáo của GA trên một cửa sổ mới nhưng đây là một sự vi phạm. Mỗi click của người viếng thăm bạn đều có tiền cả, việc bán visitor như vậy cũng đáng mà phải không!.
-Không được đặt sẵn từ khóa trong Searching box.
-Không hiển thị GA trên những trang mp3, video, new groups, các hình ảnh …nếu có liên quan đến bản quyền.
-Không đặt GA trên những trang không có nội dung bằng chữ hiển thị, và không có liên kết nào khác.Ví dụ như trang chỉ có hình ảnh , có mô tả về nó song lại không có một liên kết nào.
-Không có nhiều liên kết gãy, hoặc hơn 100 liên kết khác.
11. Không đặt GA trong email.
12. Không khích lệ người khác click vào GA
13. Trên một trang bạn chỉ có thể sử dụng tối đa: 1 link unit, một button referral cho một sản phẩm (Picasa, FireFox, Adsense , Adword) , hai form tìm kiếm và 3 ad units.
14. Chỉ đặt Search box, ads và referral button trên những trang có nội dung. Không đặt trên các domain parking nếu không được sự cho phép của Google.
15. Không sử dụng Roboots, script tự click, hay các click trao đổi lẫn nhau.
16. Không được cố gắng tạo nhiều Impression.
17. Ngôn ngữ chính của trang web phải được hỗ trợ từ GA. Hiện tại chưa hỗ trợ tiếng Việt. Nếu site của bạn có nội dung tốt, chất lượng cao. Bạn có thể liên hệ với GA để xin sự cho phép.
18. Không sử dụng một chương trình quảng cáo hiển thị theo nội dung khác cùng với GA. Ví dụ Yahoo Publisher Network. Bạn có thể kết hợp giữa Adbrite và GA trên cùng một trang mà không sợ vi phạm.
19. Không tiết lộ các thông tin như CTR, CPM, CPC của bạn. Tôi thấy nhiều bạn chưa nhận rõ được điều này nên còn chụp luôn cả màn hình GA đưa lên forum, hoặc tệ hơn là ngay trên Website của mình. Nếu GA team phát hiện ra thì coi như bạn hết phim.
20. Không sử dụng trên cùng một trang với hai mã số GA trở lên. Bạn có thể sử dụng nhiều mã số (.Không có nghĩa là bạn có nhiều tài khoản mà là có sử dụng mã số của người khác.) trên cùng một trang nhưng bạn phải chắc chắn rằng mỗi lần xuất hiện ads sẽ là một mã số duy nhất. Bạn cũng thường thấy điều này trên các forum sharing revenue (Chia sẻ thu nhập) qua GA.
21. Bạn không được phép có hơn một tài khoản. Nếu GA phát hiện thì họ sẽ xóa tất cả các tài khoản của bạn. Bạn có thể sử dụng một mã số cho nhiều trang Web khác nhau mà không cần xin phép GA. Tất nhiên là site bạn đặt lên phải có nội dung hợp lệ.
22. Bạn không được cố tình phá tài khoản Adsense của người khác. Đây là một luật rất mới, rất sáng suốt của GA. Bạn đừng nên nghĩ rằng bạn có thể phá GA của người khác. Họ sẽ phát hiện ra ngay rằng bạn là ai, sở hữu tài khoản nào và bạn tự làm mất cơ hội của chính mình. Đừng ích kỷ như thế phải không các bạn.
Bạn hãy tuân thủ tất cả các luật trên và nên cập nhật thường xuyên vì có thể có những thay đổi mới. Lần cập nhật gần đây nhất là vào tháng 4 năm 2006.
Trong chúng ta chắc chắn còn nhiều sự thắc mắc về luật của Google Adsense. Rất nhiều người trong chúng ta đã làm, hợp tác với Google Adsense. đã tuân thủ rất tốt luật của Google nhưng vẫn bị khóa tài khoản vô cớ. Nguyên do vì đâu? Đây là một khía cạnh khác, rất quan trọng cần nhiều thảo luận tiếp.
Adsense là gì
Kiếm tiền cùng Google Adsense
Bạn có thể đã nghe nói nhiều về "Google Adsense" nhưng bạn không biết chính xác đó là gì. Theo tôi, Google Adsense là 1 trong những cách kiếm tiền trên mạng Hot nhất hiện nay. Trong bài viết này mình sẽ cho bạn thấy cái nhìn khái quát về Google Adsense như : Adsense là gì, làm thế nào để tham gia, làm thế nào để kiếm tiền với Google Adsense...
Google Adsense là một chương trình dịch vụ quảng cáo, họ sẽ đặt những mẫu quảng cáo có nội dung liên quan đến nội dung website. Adsense là 1 ứng dụng của quan niệm rông hơn : Contextual Marketing. Contextual Marketing họat động như sau : trên website có nội dung về xe hơi, bạn có thể thấy những mẫu quảng cáo về bánh xe, kiếng chiếu hậu dành cho xe hơi...
Sau khi bạn đăng ký tham gia Google Adsense, công việc của bạn là đặt một đọan code mà Adsense cung cấp cho bạn ở vị trí thích hợp trên trang web của bạn. Google Adsense sẽ tự động cho hiện lên những mẫu quảng cáo có liên quan đền nội dung của webpage, mỗi khi khách tham quan click chuột lên quảng cáo thì bạn sẽ được trả một số tiền (= % của số tiền mà nhà quảng cáo Google Adwords trả cho Google).
Làm thế nào để tham gia Google Adsense?
Đầu tiên bạn phải đăng ký một tài khoản với Google Adsense, bạn click chuột vào địa chỉ sau :
https://www.google.com/adsense/
Bạn click chuột lên nút "Click here to apply" để đăng ký. Chú ý : bạn cần phải có một website tốt trước khi đăng ký tài khoản Google Adsense.
Hiện tại Google Adsense thông báo chưa hỗ trợ tiếng việt, do vậy nếu website của bạn dùng tiếng việt thì 99% Google Adsense sẽ từ chối sự đăng ký tham gia của bạn. Cách tốt nhất là tạo một website tiếng anh, có nội dung tốt rồi mới đăng ký tham gia Adsense.
Có một cách mà bạn có thể dễ dàng được chấp nhận tham gia vào Google Adsense nếu bạn chưa có website. Bạn tiến hành các bước sau :
Bước 1 : Tạo một blog tại blogger.com hay blogspot.com (đây là một dịch vụ miễn phí của Google)
Đây là cách dễ nhất để có một website tham gia Google Adsense. Bạn truy cập www.blogspot.com và tạo một blog với chủ đề nào đó. Tôi sẽ không đi vào chi tiết cách tạo một blog và sử dụng blog như thế nào, để biết thêm thông tin xin mời bạn tham khảo ở phần "Blog, tagging and RSS feed".
Bước 2 : Post một số bài viết về chủ đề mà bạn đã chọn lên blog của bạn.
Hai hoặc 3 ngày sau khi tạo blog, bạn bắt đầu thêm nội dung cho blog của mình, bạn có thể tự mình viết nội dung hay thu thập tài liệu trên internet về chủ đề của mình đã chọn.
Post khoảng 5 hoặc 6 bài viết lên blog của bạn trong khoảng thời gian 5-7 ngày, sau đó bắt đầu đăng ký Google Adsense sử dụng địa chỉ Blog của bạn làm website. Google rất thích Blogger blog, họ nhiều khả năng sẽ chấp nhận cho bạn tham gia vào google adsense nếu blog của bạn có nội dung tốt.
Sau khi đăng ký, bạn chờ khoảng 2-3 ngày để Google xem xét website của bạn, sau đó họ sẽ gửi mail thông báo có chấp nhận cho bạn tham gia chương trình Adsense hay không. Khi đã được chấp nhận thì bạn có thể đặt quảng cáo trên những site khác mà không cần phải đợi Google xem xét, ngoại trừ những website có nội dung mà google adsense không chấp nhận như web sex, web đánh bạc.
Monday, October 15, 2007
IIS Lockdown and Urlscan 1
The security posture of a web application can be severely undermined if the underlying web server software is vulnerable. The web server software is the most visible and easy to exploit part of a web application. Even if the web application itself is impregnable it can be subject to serious security breaches if the underlying web server platform is insecure.
As one of the more widely deployed web servers, Microsoft's IIS has been a frequent target for attackers over the last few years. It has been beleaguered by vulnerabilities such as source code disclosure attacks like $DATA, information exposures through sample scripts like showcode.asp, and easily exploited buffer overflow vulnerabilities which have fueled Internet-borne worms like Code Red and NIMDA. Such attacks emphasize the importance of web server security and more specifically IIS security. This article discusses two important vendor-provided tools (IIS Lockdown and Urlscan) that target significant security-related configuration problems for IIS versions 6.0, 5.0, and earlier.
IIS Lockdown
The default installation of most web servers do not satisfy the security needs of all administrators. Microsoft's IIS (particularly versions 5.0 and earlier) is no exception. It is packaged with several sample scripts, minimal file-system permissions and a plethora of file handlers. Vendors adopt this strategy to provide administrators the flexibility to tailor the security configuration to the business needs of their organization. The IIS administrator can accomplish this task either by manually configuring the server or by utilizing Microsoft's IIS Lockdown tool.
The tool provides a centralized GUI interface to un-map a specific list of Directories, Methods and Services which could pose a security threat to the web server and hence the resident web applications. In this section we will cover some basic configurations of the IIS Lockdown tool.
The novice user may opt to apply one of the many default templates provided by IIS Lockdown. These include - Small Business Server 2000, Exchange Server, FrontPage Server Extensions, Dynamic Web Server and Static Web Server. Based on the selected template, only select ISAPI DLL mappings are retained. It is however important to note that IIS Lockdown only un-maps these ISAPI extensions, it does not uninstall or un-register the DLLs. Thus, the configuration of the server can be restored to its original format by simply re-running the IIS Lockdown tool against the web server. Note that IIS 6 installs without any extras by default, and will only serve static pages until you configure it otherwise.
The more advanced user may, however, choose to manually configure the security settings to be subsequently applied by IIS Lockdown. These settings include:
1. Disabling unnecessary services
IIS allows for three basic services - the Web Service, the FTP Service and the SMTP Service. IIS Lockdown provides an option to disable and/or remove one or all of these services that are not required. This is a necessary step in securing the server as the existence of un-patched, unused services may well go unnoticed by the administrator and prove to be a playground for potential attackers.
2. Un-mapping unused file handlers
The functionality embodied in the various ISAPI DLLs can be invoked simply by requesting a file with the appropriate extension from IIS. Out of the box, IIS 5.0 and its precursors are provided with a large number of potentially unused DLLs. The extensions mapped by default include .htw, .ida, .idq, .asp, .cer, .cdx, .asa, .htr, .idc, .shtm, .shtml, .stm and .printer. The most commonly used ones are .asp (for server side scripts that help generate dynamic HTML), .asa (global configuration file, generally contains global variables and connect strings to the back end database), .cer (used for https communication) and .cdx (used for https communication). The other extensions such as .printer (provides internet printing capability) are rarely used. The DLLs supporting these extensions should be un-mapped, thus depriving erstwhile hackers with a myriad of different functionality available for exploit via malicious input. IIS Lockdown allows the user to perform this operation with relative ease through the user-friendly GUI.
3. Un-mapping sample scripts and their directories
Sample scripts and applications included in the default IIS installation pose a serious threat to the security posture of the server and its resident applications. This is due to the fact that the primary purpose of sample programs is to exhibit functionality and they do not incorporate the highest level of security. Thus, they do not include input validation routines to prevent the acceptance of malicious input from a potential attacker. This could result in compromises such as disclosure of the source code of critical applications and arbitrary command execution on the IIS server.
This issue is addressed by the IIS Lockdown tool by un-mapping these sample files and the directories in which they are contained. It is important to note that the tool does not delete the files and they can be restored if need be.
4. Modifiying critical file access permissions
IIS Lockdown modifies access permissions to the web root directory (InetPub\wwwroot). This action denies an anonymous IIS user the ability to create or delete files and folders, create or modify data and change file attributes within this directory. The permissions pre- and post-execution of IIS Lockdown are
Pre Installation Post Installation
Everyone Read-Only
NT AUTHORITY\SYSTEM Full Control
BUILTIN\Administrators Full Control
Machine\Web Applications DENIED DwawE
Machine\Web Anonymous Users DENIED DwawE
Everyone Read-Only
NT AUTHORITY\SYSTEM Full Control
BUILTIN\Administrators Full Control
The tool also changes file permissions in the %Windir% directory. These changes prevent the remote execution of system utilities like cmd.exe, tftp.exe and edit.com. Even though an anonymous IIS user cannot access these utilities remotely, the exploitation of a new or existing vulnerability could provide a channel for such access. However, the explicit removal of permissions (by the IIS Lockdown tool) plugs the hole punched by such vulnerabilities.
5. Editing WebDAV access permissions
Web Distributed Authoring and Versioning (WebDAV) is a facility that allows users to remotely collaborate and manage files on a particular IIS web server. This functionality is provided by httpext.dll. The IIS Lockdown tool denies the "Everyone" group permission to execute this DLL. This action decreases the risk of unauthorized users uploading malware to and deleting critical files on the web server.
Although IIS Lockdown tackles most of the security concerns of an IIS administrator, it is not a comprehensive solution for IIS security. The validation of client input, for example, is a major issue not tackled by IIS Lockdown. Maliciously formed URLs can result in serious security hazards. This can be prevented by using Microsoft's Urlscan (now a part of IIS Lockdown), a tool that monitors and filters the content of URLs before they are processed by the server.
Urlscan
Many attacks launched against web servers involve a maliciously crafted URL. The URL may be unusually long, may be encoded by an alternate character set or may include character sequences which are not common to a legitimate request. Such URLs, if processed by the IIS server, may cause severe damage to the server and/or the web site hosted by it. In order to prevent this, Microsoft has developed a tool known as Urlscan.
As the name suggests, Urlscan scans all incoming URL requests. Based on a set of pre-established rules, Urlscan filters out the request and sends only valid data to the server process. It provides an option to store the filtered requests in a log file.
It is important to note that Urlscan is practically obsolete with IIS 6.0. Most of the features provided by Urlscan have either been implemented by default in IIS or can be enabled by simply modifying registry keys. Therefore, this part of the article will apply primarily to versions 5.0 and earlier.
Urlscan consists of two key files: urlscan.dll and urlscan.ini which reside in the %systemroot%\inetsrv\Urlscan directory. The default urlscan.ini is archived here.
Urlscan.dll is an ISAPI filter that is self-registered when installed through IIS Lockdown/Urlscan. It can be manually registered through the Internet Services Manager interface as well. It pre-processes all requests to the IIS server looking for malicious input as defined in the Urlscan.ini configuration file. Rejected requests are logged to the Urlscan.log file located in the same directory as the other Urlscan files.
The Urlscan.ini file holds the key to successful prevention of attacks against the IIS server. The remainder of this article thus focuses on these configurations due to their paramount importance.
The Urlscan.ini file has two main parts: options and implementation. The options part of the file allows the user to enable or disable a particular option while the latter supports the actual configuration of the enabled options.
Options and Implementations:
The options take a value of either "0" or "1". Typically "1" is to enable the option and "0" to disable the option, or "1" is to explicitly allow certain implementations, whereas "0" would deny only the actions specified in the list of implementations and allow all the other default actions. Additionally the semicolon ";" is used to mark the beginning of a comment in the urlscan.ini file.
UseAllowVerbs Some typical verbs for a web-server are "GET", "HEAD", "POST", "DEBUG", "TRACE", "OPTIONS", "PUT", "DELETE". Additionally, there are the WebDAV (Web Document Authoring and Versioning) verbs like "PROPFIND", "MOVE" etc. This option works in conjunction with the implementation section's "AllowVerbs" and "DenyVerbs".
The default value for "UseAllowVerbs" is "1". If the value is set to "1", then only the verbs that are explicitly specified in the "AllowVerbs" section are passed on to the web-server and other verbs are rejected. If the value is set to "0" then all the verbs are passed on to the web-server except for those specified in the "DenyVerbs".
The value should be set to "1". A typical web site needs only "GET", "HEAD" and "POST" requests. However, to find the list of verbs that are typically used by a website, an administrator can review the website logs, in the default location "%system32%\Logfiles\W3SVC1\*.log".
This option could help prevent an attacker from using a verb to attack a remote system by disallowing the verb from being used (either explicitly or implicitly). An example of an attack that could be prevented is the TRACE cross site scripting vulnerability or the PROPFIND vulnerability, whereby an attacker can enumerate the internal IP address of a web server by simply making a "PROPFIND" request with the "Content-Length:" of zero.
UseAllowExtensions Some of the extensions that are mapped on a server are ".asp", ".aspx", ".html", ".exe", ".bat", ".cmd", ".com", ".htr", ".printer". Many of these extensions need only be executed on the server and don't need to be actually sent to the web.
This option works in conjunction with the implementation section's "AllowExtensions" and "DenyExtensions". The default value for "UseAllowExtensions" is "0". This value allows all extensions to be processed by the server except for the extensions listed in the "DenyExtensions" implementation section. If the value is "1", then the "AllowExtensions" implementation section is processed, which will only allow particular file extension requests to be passed to the web server and deny all the other extensions.
The value should be set to "1". A typical web site needs to allow only ".asp", ".aspx", ".cer", ".cdx", ".asa", ".html", ".js", ".htm", ".jpg", ".jpeg", ".gif" extensions. To determine the extensions that should be allowed, an administrator should not only review the logs to determine the files being requested, but also review the directory tree of the website.
This option could help prevent an attacker from abusing extensions to attack a remote system by disallowing those extensions from being processed. An example of an attack that could be prevented would be the ".+htr" attack, where by an attacker could view the contents of the "global.asa" file by modifying the request to "global.asa+.htr".
Similar to a firewall ruleset, it is recommended that one always try and deny everything by default and then explicitly allow specific verbs (UseAllowVerbs - AllowVerbs) and extensions (UseAllowExtensions - AllowExtensions).
NormalizeUrlBeforeScan Some of the requests that could be sent back to the server could be either hex encoded, URL Encoded or UTF encoded. For example, %20 indicates the hexadecimal value for a space character in ASCII. Files on a web server can be requested using alternate representation. The use of "NormalizeUrlBeforeScan" causes the URL to be canonicalized before processing. All the characters would be decoded/normalized before a request is processed. The default value is "1" which would normalize the request before passing it to the server process.
The value should be set to "1", however it is known to break various web applications. The cause of this failure is typically because the application expects to receive encoded characters and tries to process regular characters as encoded characters.
This option could help prevent an attacker from requesting information from a server by encoding the request in order to bypass access controls in the applications. An example of an attack that could be prevented would be the "cgi-bin/..%c0%af../..c0%af../..c0%af../..c0%af../..c0%af../winnt/system32/cmd.exe?/c+dir+c:\", which would list the directory contents of the "c:\", the Unicode attack.
VerifyNormalization Some of the requests that could be sent back to the server could be encoded multiple times. For example, %255c is double encoded for "\". The hex encode character for "\" is %5c. The hex encoded character for "%" is "%25". Thus the double encoded character for "\" would yield "%255c".
When "VerifyNormalization" value is set to "1", the default value, it causes the URL to be canonicalized twice to verify the resulting value with the result of the previous canonicalization. If the two differ the request is rejected.
The value should be set to "1", however it is known to break various web applications. The cause of this failure is typically because the application expects to receive encoded characters and tries to process regular characters as encoded characters.
This option could help prevent an attacker from requesting information from a server by double-encoding the request in order to bypass access controls in the applications. An example of an attack that could be prevented would be the scripts/..%255c..%255c..%255cwinnt/system32/cmd.exe?/c+dir+c:\", which would list the directory contents of the "c:\", the double-encode attack.
AllowHighBitCharacters Some of the requests that might be sent back to the server could contain non-ASCII characters. These characters would typically be UTF-8 encoded, and a site that requires international language support would use this character set.
When AllowHighBitCharacters is set to "0", the default value, the server won't process characters which are non-ASCII. However, if the value is set to "1", the server processes the request directly.
For a site that contains only ASCII characters, the value should be set to "0", however for a site which might contain additional characters (multiple language support), the value should be set to "1". This option could help prevent an attacker from requesting information from a server by encoding the request in order to bypass access controls in the applications. An example of an attack that could be prevented would be the "cgi-bin/..%c0%af../..%c0%af../..%c0%af../..%c0%af../..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\", which would list the directory contents of the "c:\", the Unicode attack.
AllowDotInPath Many requests that are sent back to the server contain "../". An example of such a request could be a simple reference in the source code itself "../../images/company_logo.gif".
If this option is set to "0", the default value, Urlscan rejects any request that contains multiple periods, including the example shown above. Note that this does not negate the server IP address. If this option is set to "1" then Urlscan allows for file or directory requests with multiple periods to be processed by the server.
The default value should be set to "0", however it may break the functionality of many web applications and web sites because of the common use of relative references, such as "../../images/company_logo.gif" to reference files versus literal references, like "/images/company_logo.gif". This option could help prevent an attacker from attempting to request information from a server by providing multiple "../" as an argument. An example of an attack that could be prevented would be the "cgi-bin/..%c0%af../..c0%af../..c0%af../..c0%af../..c0%af../winnt/system32/cmd.exe?/c+dir+c:\", which would list the directory contents of the "c:\", the Unicode attack.
RemoveServerHeader By default when a request is made to the server, the server responds with a list of options. Among the response there is a variable called "Server:" which specifies the exact version of server that is hosting the site.
The default value of this is set to "0" which responds back to the client and displays the server information. If the value is set to "1", the server name is no longer sent to the client. The entire line containing the server string is omitted.
The value should be set to "1". This option could not only help prevent remote attackers from randomly targeting your websites due to the version you are running but also could prevent worms from spreading to your website if the worms are designed to first read the header information before attempting the attack on the server. Note that there are other ways to identify and enumerate a web server, however this approach removes the easiest and most obvious method.
So far there aren't any know attacks against the server string directly, however, knowing the server type and version could make the server a potential target for a zero day exploit.
EnableLogging This option starts the logging of all activities that are related to the Urlscan ISAPI. It not only logs the requests sent from the client, but also provides information onhe settings that are being implemented by the ISAPI. The default value of this is set to "1" to enable logging, however if the value is set to "0", the logging is disabled.
The value should be set to "1". However, it is important to note that some parts of the logging will be duplicated with the standard IIS logs. This option could provide more information on the type of attacks a malicious user was attempting against the website or it might also help troubleshoot other problems in the web application.
PerProcessLogging This option could be viewed as an extension to logging. It provides a separate log file for each individual process ID, by appending the Process ID in each log file. This option may aid in debugging a process using the process ID.
The default value "0" doesn't separate the logs per process ID, however if the value is set to "1", the log files are generated on the basis of each and every Process ID.
The recommended value for PerProcessLogging is "0".
AllowLateScanning This option allows the administrator to load the Urlscan ISAPI as a high or low priority filter. Note that this feature is not required for IIS 6.0 because IIS 6.0 does not depend on filter notifications for its lockdown mechanism.
The default value is "0" which will load the ISAPI as a high priority and thus will process all the requests before they are passed to the server process. When set to "1", Urlscan will be loaded later, first allowing other ISAPI Filters to be used before Urlscan screens the input.
The recommended value for "AllowLateScanning" is "0", however per Microsoft's Website, late scanning has to be enabled (set to "1" ) to allow for Front page extensions to work.
PerDayLogging This option allows for either producing daily log files or letting the administrator rotate the logs. The default value which is set to "1" separates the daily logs. A new log file is automatically started at the end of the day (12:00 AM). The log files are labeled with the date in the name - Urlscan.
The recommended value is "1". This would help organize the data more systematically, however when the logs are centralized using a central log server it might require a single master file.
RejectResponseUrl This option allows for a custom error message to be presented to the client.
The default value would reveal to the User Agent - that Urlscan is being run on the remote system. Note that XSS is common in custom error messages, therefore one should be careful in modifying this default value.
UseFastPathReject This option is used in conjunction with the RejectResponseUrl. If the value of "UseFastPathReject" is set to "0", then the ISAPI will respond back with the value of the "RejectResponseUrl", however, if the value is set to "1", then the ISAPI will neither use the "RejectResponseUrl" nor log the request. If an ISA server is part of the website architecture, then the Proxy server will log both the request and the response.
The default value for "UseFastPathReject" is "1". Urlscan will ignore the "RejectResponseUrl" and returns a 500 error message to the browser. This is faster than processing RejectResponseUrl, but it does not permit as many logging options.
The recommended value is "1", if the value is set to "0", there is too much information logged.
AlternateServerName This option allows to customize the "Server" value. This option works in conjunction with "RemoveServerHeader". If the value of "RemoveServerHeader" is "0", then AlternateServerName can be used to specify a replacement for IIS's built in 'Server' header.
The recommended value could changed to either be a different vendor's name or something unique that would mislead the attacker.
DenyUrlSequences This option allows you to specify a list of characters to be rejected in the URL. The default options here are "..", "./", "\", ":", "%" and "&". Additional values recommended to add to this list are "#", "<", ">", "$", "@", "!", "," and "~".
This option could help prevent different attacks against the site including cross site scripting attacks on the URL.
Conclusion
The use of Urlscan in conjunction with IIS Lockdown blocks a multitude of attacks against IIS. However they do not provide a comprehensive solution for the IIS administrator. There are some security issues that still need to be explicitly addressed by the IIS administrator. These include: implementation of a patch management process to ensure that the both the IIS server and the underlying operating system are up to date with security fixes, hardening the underlying operating system security and the removal of un-mapped or unused DLLs to prevent their accidental re-mapping. However, IIS lockdown and Urlscan go a long way in securing an IIS server.
Antivirus Concerns in XP and .NET Environments
After Windows NT was released, it took virus writers five years to learn how to infect it. Windows NT 3.1 and the Win32 API were released in late 1993, but it wasn't until August 1998 that W32.Cabanas became the first NT virus by capturing coveted kernel mode access. .NET and some of Microsoft's other initiatives have not been as lucky. The purpose of this article is to discuss antivirus (AV) concerns with .NET and Microsoft Windows XP.
.NET Review
.NET was officially announced by Microsoft in July 2000 at a Microsoft Professional Development Conference. Since then, what .NET has meant and the products involved have changed (and been renamed). .NET is an idea and a programming platform. The basic concept is an evolving extension of Microsoft's Object Linking Embedding (OLE) introduced back in the early days of Windows 3.0. OLE allows you to copy objects and data created in one application, like a spreadsheet graph, to other applications. OLE evolved into ActiveX objects, which are executables you can download and run within an Internet browser.
.NET takes it two steps further by allowing the entire application to be hosted elsewhere (potentially allowing your environment to follow you, no matter where you go) and allowing different distributed software parts to make up one application. For example, your Windows desktop settings, your applications, and your data may be available to you where ever you compute. Running by an Internet kiosk in an airport? Just login and access your desktop and your data. Different applications will co-exist together, over the web, to bring you that integrated environment. One vendor will handle the login and authentication, another will store your data, and each of your applications will be made up of specifically customized components. I'll take two thesauruses, a math equation editor, and a French translation dictionary please. Hold the autocorrect.
All of this magic happens because of new distributed .NET programming platform and a horde of new Microsoft developer tools and languages: C# (C Sharp), Visual J#, VB.NET, Visual Studio .NET, ASP.NET, increased reliance on XML, and a host of other new programming tools and platforms.
The .NET execution framework reminds many people of Java's model. In order for a Java applet to run, it must be executed in a Java Virtual Machine (JVM) environment. .NET executables (regular Windows 32-bit Portable Executables) run on top of a similar environment called the Common Language Runtime or CLR. This is what you are installing when you install the Microsoft .NET Framework component. The CLR runtime engine performs security checks, does type checking, checks memory pointers, loads other component dependencies, and Just-In-Time (JIT) compiles the platform-independent source code into executable code. And further, there are intermediate source code representations (called Microsoft Intermediate Language or MSIL), class files, class loaders, and separate treatment between trusted and untrusted code. Untrusted code is sandboxed and prevented from accessing or risking system resources. This should sound a whole lot like Java to anyone.
I bring up this comparison because .NET is more complex than Java, and complexity doesn't mix well with security. I often hear that Java is very secure because it has only had one widespread in-the-wild exploit. I love Java and the people who designed it did so with security as top priority. But the truth is that Java has had dozens of security holes patched since its release. Just because the white-hatters are the ones finding them doesn't make it a secure platform. Many Java exploits have been found by breaking assumptions between its mesh of interoperating components. See, in order for Java security to work, all the components must work 100% of the time. If one fails, they all fail. Because .NET's execution model is roughly similar, it isn't a hard stretch to believe that many holes will be found in .NET.
Web Services
Web services are the reason for all the complexity. Web services are XML applications, interfaces, and data, designed to be shared across multiple platforms around the Internet. A web service might be a single application hosted by an Application Service Provider (ASP) or it could be a combination of several different vendor's web services making up one application experience for the user. For example, consider a typical online transaction such as buying a pair of jeans. You may use one web service to authenticate your login to the manufacturer's web site, another to help get you the perfect fit, and another to determine delivery details and payments.
Microsoft's Passport was the first example of a web service. Passport allows you to use a single login name and password for all web sites that support Passport authentication. It has tens of millions of users and it has had a series of security issues over the years. In one such instance in May of this year, it was discovered that a remote attacker could send a rather trivial, malicious URL to hotmail.com, be able to change anyone's password and take over the passport account. Maliciously altered Passport accounts can be used to buy goods online and to view confidential data.
The idea that a single, widespread web service with a vulnerability that can immediately expose tens of millions of people to new threats has security experts paying attention. Today's conventional worms and viruses are infecting millions of computers in ten minutes. But a crafty web service worm could potentially conduct millions of falsified commercial transactions in a matter of minutes, something a MS-Office macro virus can't hope to do.
The complexity and popular use of .NET's execution model worries security experts. The widespread sharing of applications, code, and data around the Internet is bound to culminate in interesting future exploits. Lucky for us so far, .NET exploits have been limited to some 'growing pain' problems with Microsoft Passport and a few worms and viruses.
.NET Viruses
There are already at least three .NET worms and viruses: Donut, Serot and Sharpei. Donut, discovered on January 9, 2002, was the first .NET virus. Sent only to researchers as concept malware, the buggy Donut attempts to infect all the .EXE files in the current folder and up to 20 folders above it. It contains a never-executed payload display message and only a small amount of MSIL code. It is mostly normal 32-bit assembly language and the .NET files it infects are turned into regular looking PE files. Donut was the first .NET virus, but it only had a short lead on the others.
Donut was quickly followed up by the Serot, worm which arrives as an impersonated email from support@microsoft.com. It infects all .NET (MSIL) .EXE files on drive C: and will attempt to send itself to all email addresses in the Windows Address Book and those it finds in the Internet Explorer cache folder. Like the virus that followed it, Serot contains a VBS file that does the mass mailing effort. This appears to be easier to do in a script language for the crackers than in MSIL. Serot attempts to terminate antivirus processes on infected PCs and contains a plug-in architecture similar to the one successfully used in the Hybris worm.
Then the Sharpei virus was discovered on February 26, 2002. It arrives in email pretending to be a Microsoft patch, MS02-010.EXE. Written in C#, it drops a Sharp.VBS file that sends itself to all contacts in the Microsoft Outlook address book. After messages are sent, the evidence is deleted from the Sent Items folder in Outlook.
Both the Sharpei and Donut viruses are direct action infectors, meaning they execute and do their damage upon running, and then exit until the next execution. All three "concept" programs have their problems and are unlikely to spread far. Antivirus researchers expect the future to bring memory-resident .NET viruses.
Note: Peter Szor, with Symantec, did detailed write-ups on Donut and Sharpei for the Virus Bulletin publication. You can visit www.peterszor.com or www.virusbtn.com for detailed reading on .NET infections.
Because all three .NET malware programs are very buggy and require .NET to be installed, none spread very far outside research laboratories. But a crucial point, that malware writers are ready to exploit the .NET framework, has been proven. It won't be a five-year wait this time. Meanwhile, new features in other Microsoft platforms have raised concern among AV experts.
Windows XP Concerns
Windows XP has an improved model of NT's HAL, kernel, and user mode processes. Overall, with XP and Server 2003, Microsoft has increased the stability and security of their operating systems. True, Internet Explorer and Outlook continue to be the weak points in Microsoft's Trustworthy Computing initiative, but their core operating systems are becoming more secure out of the box. At the same time, Microsoft cannot resist (and consumers demand) new features, and XP has plenty of those. Some have been exploited, most haven't...yet. The next part of this article will briefly discuss the new feature XP sets that concern computer security analysts.
Windows Media Player
It used to be that you only had to worry about malicious executable content. Data was data was data, and it could not be launched as an attack. Times change and data content is often exploited in today's multimedia world. The content itself can be used maliciously, in a buffer overflow or through embedded script languages. Another common ruse is for the file to have a header claiming it is one type of file, but instead it contains something completely different, bypassing security-checking mechanisms. The multimedia program itself is often used for the attack. If the interface allows scripting or "skin" updating, rogue coders can instruct the program to do things that would otherwise be constrained by one of Internet Explorer's security zones.
Microsoft's Windows Media Player is installed by default on every version of Windows. The original release of XP came with version 8.0, although anyone can upgrade to version 9 for free. Several holes have been found with the Windows Media Player over the last few years, and Microsoft has patched them when reported. The older versions of Windows Media Player have more security holes than the newer versions, but many people are hesitant to upgrade because of their bulkiness and the restrictive Digital Rights Management features of the newer versions. To be fair to Microsoft, let's not forget that Flash files, RealPlayer, Winamp, and just about every other popular media distribution content has be found to have one or more exploit holes over the past year. But network administrators would appreciate it if Windows Media Player was not installed by default and upgrades were not offered to end-users via Windows Update when it has been removed on purpose.
WebDAV (Web Digital Authoring and Versioning)
WebDAV is a feature installed on machines with XP or IIS 5, or greater. WebDAV is a HTTP protocol extension that allows users to publish and collaborate on documents that are stored on the web. Contrary to common belief, WebDAV is a popular open standard and not just a Microsoft feature. There have been a handful of exploits against Microsoft's implementation of WebDAV, including DoS and buffer overflows. The biggest problem with WebDAV is that it is installed and turned on by default when most people don't use it. It's a good, powerful collaboration tool, it just needs more security analysis and should not be turned on by default. WebDAV is not turned on by default on Server 2003 and IIS 6.
Remote Desktop Connection
Remote Desktop Connection allows one XP Pro PC to remotely connect and control another XP Pro PC with a PC Anywhere-style session. Remote Desktop, as it is called in the System Control Panel applet, uses Terminal Server's Remote Desktop Protocol (RDP) over TCP port 3389. It is not turned on by default, and so far has not been exploited. Still, knowing that it is installed as an inactive shell on every Windows XP computer, many of which are poorly secured, raises some concerns.
Remote Assistance
Unlike Remote Desktop Connection, Remote Assistance is turned on by default. It allows one XP user to invite, using either email or instant messaging, another XP user to have remote control access over their PC. Besides desktop control, the remote user can participate in chat sessions and transfer files. Invitations can be open for many days, and the default is 30 days. One of the main concerns is that there is no vetting mechanism to guarantee who is who in the remote assistance scenario. There exists the possibility that a malicious remote user may impersonate a tech support person and plant malicious files. While there have been no public exploits using Remote Assistance, AV experts worry about poorly password protected connections and buffer overflow attacks.
Internet Connetion Firewall (ICF)
Microsoft's first attempt at a desktop firewall is laudable, but comes up a bit short. ICF's main deficiency is that it lacks the ability to block outgoing port traffic. Many malware programs, once installed, will initiate outbound communications to continue their maliciousness. It could be a remote access trojan contacting its originating hacker to advertise the successful intrusion or an email worm with its own SMTP engine sending itself out around the world. In either of these two cases, because ICF allows all outgoing requests by default, the end-user will not be warned. Most of today's personal desktop firewalls would stop the request and alert the user. I hope if Microsoft continues to support ICF as firewall product that additional features sets will be added and its usefulness increased. ICF is also installed on Server 2003.
UPnP
Universal Plug and Play is another feature that should be turned off by default. UPnP allows a Windows machine to discover UPnP devices (ex. printers, scanners, etc.) on the network and to auto-configure their use. UPnP ended up being XP's first big publicly touted hole in December 2001. It was a buffer overflow and could be successfully exploited over the Internet, and if a firewall did not block UDP port 1900, it could be used to gain complete control of the machine. Luckily, UPnP is not even installed on Microsoft's latest offering, Windows 2003.
Simple File Sharing
XP the Home Edition has a feature called Simple File Sharing. When a folder is shared, it is immediately accessible to everyone on the local network and no specific permissions can be set. The folder can be set as read-only, but if changes are allowed, full control is given to anyone who can see the folder. AV experts worry that if a virus or worm gets loose on a home network with Windows XP Home, the malware will have no problem traveling machine to machine using network shares
Windows Messenger
Microsoft's Windows Messenger is installed by default on XP Pro and Home editions. Instant messaging (IM) clients open additional avenues for attacks. First, there have been many buffer overflow attacks against instant messaging clients, even when not turned on and only installed. Second, IM clients allow yet another avenue for the unsuspecting Joe User to receive malicious files. Many antivirus programs do not monitor IM file transfers. Third, there are malicious programs and viruses that specifically target Microsoft's IM clients. Although not attacked nearly as much as IRC and AOL's AIM clients, instant messaging is a technology being used before the security is all in place.
Office XP
Although only affiliated with Windows XP by name only, here's a good point to discuss a potential security problem in Microsoft Office XP. One of the most touted features of Office XP is its ability to read and write files in XML format. Macro viruses, which for several years were the number one infection type, have been mostly tamed by Office's macro security and antivirus software. XML has the potential to allow yet another round of new technology viruses into our Office documents. This is because XML is an everyman's language. An XML file is what you define it to be. Besides text, it can contain executable code, scripting, multi-media content, whatever programmers might want it to contain. As has been proven so many times in the past, flexibility and choice increases the risk of malicious exploitation.
I'm sure there are some features I missed that may be exploited in the future, but at the moment these are the main ones garnering increased scrutiny by security professionals.
Windows XP Security
Before this paper ends, I want to point out that security has been strengthened in Windows XP, and much more so in Windows 2003. XP was the first Microsoft operating system to offer a firewall (ICF), and it's better than nothing for the consumer that isn't motivated to install another vendor's personal firewall product. XP has Encrypted File System (EFS), Windows File Protection (WFP), Certificate Services, IPSEC, Kerberos, Software Restriction Policies, and System Restore. All of these additional features fight malicious code and are welcome additions to the Microsoft family. All security reviews of Server 2003 have been positive. More unnecessary features have been turned off by default and file and registry settings strengthened.
Summary
The complexity of the .NET execution platform worries security experts. Once it is widespread, malicious coders will find holes in between the interoperable layers and then execute security exploits. The persuasive nature of web services means that one malware threat could quickly compromise a large number of machines. There are already three .NET viruses and worms. Although they are buggy, future viruses and worms will be able to perform without error as crackers begin to target .NET.
Windows XP contains much new functionality, some of which has been exploited, and other features which have yet to be maliciously explored. XP also contains many new security features, like Windows File Protection and Internet Connection Firewall, which strengthens the OS's response to security threats.
Roger A. Grimes, CPA, MCSE (NT/2000), CNE (3/4), A+, has been fighting malicious code since 1987 and is the author of Malicious Mobile Code: Virus Protection for Windows (O'Reilly). He is a frequent writer and speaker on computer security topics. His next book, Honeypots for Windows (APress) will be available near the end of the year.
Malware Analysis for Administrators
1. Introduction
The threat of malicious software can easily be considered as the greatest threat to Internet security. Earlier, viruses were, more or less, the only form of malware. Nowadays, the threat has grown to include network-aware worms, trojans, DDoS agents, IRC Controlled bots, spyware, and so on. The infection vectors have also changed and grown and malicious agents now use techniques like email harvesting, browser exploits, operating system vulnerabilities, and P2P networks to spread. A relatively large percentage of the software that a normal internet user encounters in his online journeys is or can be malicious in some kind of way. Most of this malware is stopped by antivirus software, spyware removal tools and other similar tools. However, this protection is not always enough and there are times when a small, benign looking binary sneaks through all levels of protection and compromises user data. There may be many reasons for this breach, such as a user irregularly updating his AV signatures, a failure of AV heuristics, the introduction of new or low-profile malware which has not yet been discovered by AV vendors, and custom coded malware which cannot be detected by antivirus software. Though AV software is continually getting better, a small but very significant percentage of malware escapes the automated screening process and manages to enter and wreak havoc on networks. Unfortunately, this percentage is also growing everyday.
It is essential for users and absolutely essential for administrators to be able to determine if a binary is harmful by examining it manually and without relying on the automated scanning engines. The level of information desired differs according to the user's needs. For instance, a normal user might only want to know if a binary is malicious or not, while an administrator might want to completely reverse engineer the binary for his purposes.
Traditionally, malware analysis has been considered to be very complicated, and in fact some of the techniques are still very complicated and beyond a normal user's access. Nevertheless, looking at the current scenario, we can see that there is a clear need for people to learn how to analyze malware themselves. But the caveat is that the analysis techniques have to be simplified and the learning curve has to be made smaller for mass consumption among the general public. Unfortunately, there is not much organized information in the public domain dealing with easy to use malware analysis techniques. This paper tries to fill this void. The focus is on malware reversing but these techniques can be applied to reverse engineer any binary.
Besides the uses mentioned above, malware analysis is used for forensics, honeypot research, security vulnerability research, etc.
2. Background, goals, assumptions and tools
2.1 Background
There are basically two broad categories of techniques that are used for analyzing malware: code analysis and behaviour analysis. In most cases, a combination of both these techniques is used. We will consider code analysis first.
Code analysis is one of the primary techniques used for examining malware. The best way of understanding the way a program works is, of course, to study the source code of the program. However, the source code for most malware is not available. Malicious software is more often distributed in the form of binaries, and binary code can still be examined using debuggers and disassemblers. However, the use of these tools is often beyond the ability of all but a small minority because of the specialized knowledge required and the very steep learning curve needed to acquire it. Given sufficient time, any binary, however large or complicated, can be reversed completely by using code analysis techniques.
On the other hand, behaviour analysis is more concerned with the behavioural aspects of the malicious software. Like a beast kept under observation in a zoo, a binary can be kept in a tightly controlled lab environment and have its behaviour scrutinized. Things like changes it makes to the environment (file system, registry, network, etc), its communication with the rest of the network, its communication with remote devices, and so on are closely observed and information is collected. The collected data is analyzed and the complete picture is reconstructed from these different bits of information.
The best thing about behaviour analysis is that it is within the scope of an average administrator or even a power user. The learning curve is very small and existing knowledge can be leveraged to make the learning process faster. This makes it ideal for teaching newbies the art of malware reverse engineering. These reasons are consistent with our stated goals, focused on the typical administrator, and therefore this paper is mostly concerned with behaviour analysis.
Though reverse engineering using behaviour analysis does not lead to the complete reversing of a binary, it is sufficient for most users' needs. For instance, it is not sufficient for an antivirus researcher but for most other users, behaviour analysis can fulfill all their needs.
2.2 Goals in the analysis
As stated before, our goal is to provide a set of behaviour analysis techniques for reverse engineering malware. Also, the learning curve should be small so that it is within the scope of most people.
Using these methods, people should be able to analyze an unknown binary and determine whether it is malicious or not. Those who require more in-depth knowledge should be able to reverse engineer the binary, understand and document its workings completely.
2.3 Assumptions and definitions
This paper makes a few assumptions for the sake of convenience and clarity. These are:
1. We assume that the malware under consideration is a Win32 based binary on an Intel x86 machine. This is just for the sake of clarity. The basic principles can be just as easily applied to any other platform.
2. We sometimes refer to the malware as "the binary". This does not however mean that the principles are applicable only to a malicious application that is composed of a single binary.
3. The host machine on which the binary is executed is referred to as the "victim host" or the "victim machine".
4. The other machine on the test network is referred to as the "sniffer machine".
2.4 Tools
Since the goal of this paper is to propose a generic set of techniques, the tools mentioned in this paper are just "proposed" tools and are available as references at the end of this document. Any other tool that has the same or similar functionality can be used in place of the proposed ones.
3. Methodology
The framework proposed is broadly divided into six stages. They are:
1. Creating a controlled environment
2. Baselining the environment
3. Information collection
4. Information analysis
5. Reconstructing the big picture
6. Documenting the results
3.1 Creating a controlled environment
The setting up of a controlled and sanitized environment is absolutely essential for analyzing malware. A special "test lab" is created for this purpose. Some essential features of the test lab are:
* At least two machines should be used. One machine is for hosting the malicious binary (victim machine) and the other is for baselining and sniffing the network traffic (sniffer machine). They should be networked in such a way that each of them is able to sniff the other's network traffic.
* The two networked lab machines should be isolated from the rest of the network.
* Fresh copies of Operating Systems should be installed on each of the two machines. It is preferable to have a WinNT kernel family OS on one machine and a *nix based OS on the other. Since we are assuming a Win32 binary, the WinNT machine acts as the "victim host" and the *nix machine is used as the "sniffer machine".
* Tools should be transferred to the relevant machines.
* The binary that is to be examined should be transferred to the relevant machine. Since we are assuming a Win32 binary, it is transferred to the Win32 machine in this case.
* It is highly preferable not to install any other application upon the "victim host" apart from the tools required for analysis.
This is the most basic setup for a malware analysis lab. Apart from this and depending on the situation, more modifications can be carried out. For instance, if the malicious binary tries to communicate with a remote server xyz.com, a DNS server has to be setup in one of the lab machines and a DNS entry for xyz.com has to be created. An excellent paper that discusses the creation of a malware analysis lab is "An Environment for Controlled Worm Replication and Analysis".
We may have to return to this "creating a controlled environment" stage many times during the analysis process. Sometimes, in the light of new information generated during the later stages, the lab will have to be tweaked and modified.
3.2 Baselining the environment
Baselining the environment is the next major step. "Baselining" means taking a snapshot of the current environment. This is the most vital stage in our analysis. If baselining is not done properly, it has a serious effect on the information gathering stage, which in turn seriously effects our understanding of the binary. If baselining is done efficiently, the information generated during the next stage becomes very accurate and the rest of the stages become easy to execute.
To accomplish our goals, the binary which is to be analyzed is executed in a controlled environment and the changes it makes to that environment are captured. Before executing the binary, a snapshot of the environment is created (baseline) and then after execution another snapshot is created. In theory, the difference between the baseline and the final snapshot gives the changes made by the binary.
The elements of the environment that have to be baselined are:
3.2.1 Victim machine
Some of the elements that are to be baselined in the Victim Machine are:
o Filesystem: The file system on the victim host has to be baselined. There are many programs that can create a snapshot of the file system and after a few changes occur, they can point out the modifications. Some of the programs we can use are Winalysis and Installrite.
o Registry: The registry is the next component that is to be baselined. Most malware applications rely on registry entries. Therefore it is crucial to capture registry modifications. Winalysis as mentioned above is one of the available programs that can be used for registry baselining.
o Running processes: A snapshot of the running processes can be created using a number of programs. Some of them are available from Sysinternals.
o Open Ports: A snapshot of the open ports can be created using the 'netstat' utility. However, it does not list the name of the process that is tied to the port. For this, we can use Fport available from Foundstone.
o Users, Groups, Network Shares and Services are some of the other elements that should be baselined.
3.2.2 Network traffic
The next element that has to be baselined is the network traffic. Even when there is no application running on either of the test machines, there will still be some network traffic. This traffic has to be recorded and the "normal traffic" in our test network has to be defined. This is because when deviations occur in the "normal traffic" pattern, we can assume it to be generated by the binary and perform further testing on it.
Sniffing software that is installed on our "sniffer machine" is used for this purpose. Any sniffing software running in verbose mode is sufficient for our purposes. However, to make our task easier, it is preferable to use a protocol analyzer like Ethereal.
3.2.3 External view
Although we have created a snapshot of the open ports in the victim machine, it is always better to create one more snapshot from an external machine. A port scanner running on our "sniffer machine" can achieve this task for us. It goes without saying that Nmap will be the port scanner of choice for most users.
3.3 Information collection
Now that the preparations are over, we can go ahead with our task. This is the only stage where we have an actual interaction with the binary. A lot of raw information about the binary is collected during this stage which is analyzed in the next stage. Therefore, it is very important to carefully record all the information generated in this stage. The steps in the information collection stage are:
3.3.1 Static analysis
During the static analysis stage, we collect as much information about the binary as possible, without executing it. This involves many techniques and tools. Static analysis reveals the scripts, HTML, GUI, passwords, commands, control channels, and so on. Simple things like the file name, size, version string (right-click>properties>version in Win32), are recorded.
Human-readable strings are extracted from the binary and these strings are recorded. A program like Binary Text Scan can be used for this purpose. These strings reveal a lot of information about the function of the binary.
Resources that are embedded in the binary are extracted and recorded. A program like Resource Hacker can be used for this purpose. The resources that can be discovered through this process include GUI elements, scripts, HTML, graphics, icons, and more.
3.3.2 Dynamic analysis
During this stage, we actually execute the binary and observe its interaction with the environment. All monitoring tools including the sniffing software are activated. Different experiments are done to test the response of the running malware process to our probes. Attempts to communicate with other machines are recorded. Basically a new snapshot of the environment is created like in the baselining the environment stage.
After taking a snapshot of all the changes the binary performs in the system, the binary process is terminated. Now, the differences between the new snapshot and the baseline snapshot are determined. The dynamic analysis step is very similar to the baselining the environment stage. Therefore, the tools are reused for this stage. Winalysis and InstallRite can be used for this purpose. Apart from these tools, Filemon and Regmon from Sysinternals can be used for monitoring the file system and the registry dynamically. These tools are used for observing the changes to the file system and the registry.
This information is recorded and forms the input for the next stage of our analysis. The information generated here can be new files, registry entries, open ports, etc.
Sometimes, the static analysis step has to be repeated once more after doing a dynamic analysis.
3.4 Information analysis
This is the stage where we can finally reverse engineer the binary based on all the information collected during the previous stages. Each part of the information is analyzed over and over and the "jigsaw puzzle" is completed. Then the big picture automatically begins to appear and the reverse engineering process is finished. However, before this is achieved, we may have to repeat the previous stages (See figure) several times.
The goals of the individual or organization evaluating the binary determine the type of analysis and because the goals differ, no standard methodology is provided for this stage. Looking for deviations from the stated security policy of an organization based on the information can be the determining factor in some cases.
Although a complete methodology for information analysis is beyond the scope of this paper, a few techniques are presented here. In many cases, these techniques are sufficient for analysis.
3.4.1 Internet searches
A search engine can be used for searching for more information on the binary. Keywords for the search engine can be drawn from the information generated during the "Static Analysis" step during the previous stage. Things like filenames, registry entries, commands, etc. often reveal a lot of information about the malware. Some good sources of information on the internet include Online Virus Databases (mostly maintained by Antivirus Vendors), News Groups and Mailing Lists. Many times, internet searches reveal almost all there is to know about the malware and no further research is needed.
3.4.2 Startup methods
Every malware needs a way to ensure that it is executed when a system reboots. This is the most vulnerable aspect of the malware. There are only a limited number of ways in all operating systems that a program can use to restart automatically when a machine reboots. The information collected during the previous stage can be analyzed to identify the startup method of the malware. A very good source for Startup Methods related information on the Internet is the Paul Collins' Startup List.
3.4.3 Communication protocol
A network protocol analyzer like Ethereal in many cases can identify the communication protocol used by the binary. When this is not the case, the protocol has to be reverse engineered. This is beyond the scope of this document.
3.4.4 Spreading mechanism
If the malware under scrutiny is a self-spreading worm or virus, the collected network traffic data will easily reveal its spreading mechanism. In most cases, a cursory glance is enough.
3.5 Documenting the results
Documenting the results of the malware analysis and reverse engineering exercise is essential. One of the main advantages is that the knowledge incorporated into the documentation can be leveraged for later analysis exercises. The documentation needs differ from individual to individual and organization to organization. The method preferred by the concerned party can be used here.
4. Conclusion
From this article we've seen that a basic behavioral analysis of a binary can be easily performed by an administrator, or indeed by a power user. While this approach does not give the same level of detail as code analysis would, it is sufficient for most people's needs when figuring out what a potentially malicious binary is capable of.
About the author
S.G.Masood is the founding CTO of the Chicago, Illinois based application security startup Circle Technologies. He currently stays in Hyderabad, India and manages the development center.
References
"An Environment for Controlled Worm Replication and Analysis" by Ian Whalley Bill Arnold, David Chess, John Morar, Alla Segal, Morton Swimmer - www.research.ibm.com/antivirus/SciPapers/VB2000INW.htm
"Reverse Engineering Malware" by Lenny Zeltser - www.zeltser.com/sans/gcih-practical/revmalw.html
"Paul Collins' Startup List" - http://www.sysinfo.org/startuplist.php
Archives of the various security and malware related mailing lists, most notably, Bugtraq, Full-Disclosure, Focus-Virus, Incidents.
VMWare - www.vmware.com
Winalysis - www.winalysis.com
Installrite - www.epsilonsquared.com
Fport - www.foundstone.com
Nmap - www.insecure.org
Binary Text Scan - netninja.com/files/bintxtscan.zip
Resource Hacker - www.users.on.net/johnson/resourcehacker/
Filemon and Regmon - www.sysinternals.com
Ethereal - www.ethereal.com
Detecting Complex Viruses
There are many metrics by which to measure the efficiency and effectiveness of an antivirus product and the response organization that is backing it. Some of the commonly used metrics today include the antivirus company's response time to new threats and well as the availability of proactive detection. But are these metrics enough?
The purpose of this paper is to examine the difficulties of detecting complex viruses, including polymorphic, metamorphic and entry-point obscuring viruses. Whether or not an anti-virus technology can detect these viruses can be a useful metric to consider when evaluating AV products.
In this article, we will show how complex viruses can offer an entirely different threat to organizations. It is important to step into the world of complex viruses by defining what a metamorphic, polymorphic, and entry-point obscuring virus is, understand when it is considered a real threat, and then see some real-life examples of complex viruses that have been discovered. This will lead into a discussion on the limitations of current anti-virus engine technology, and then finally, we will try to gauge the importance of detecting these complex viruses accurately, and in a timely fashion.
Overview of complex viruses
At one time, the aggregate number of viruses a product detects was considered a useful and popular metric, but this has largely been abandoned in favor of other more useful and scientific measures. Today, an AV company's response time to new threats and the proactive detection that their product offers are both considered more important evaluation criteria. But these criteria often do not consider complex viruses, a different kind of threat. Detecting a complex virus means detecting a threat that is either inherently difficult to detect, or exposes engine limitations that make it difficult to detect. We will start with a few definitions.
A polymorphic virus is a virus that changes its appearance in host programs. For instance, it encrypts its body with a different key each time, and prepends a decryption routine to itself. The decryption routine (known as the "decryptor") is mutated randomly across virus instances, so as to be not easily recognizable.
A metamorphic virus, by comparison, is a virus that also changes its appearance in host programs, however it does so without necessarily depending on encryption. The difference in appearance comes from changes made by the virus to its own body. There are several techniques that can produce such an effect.
One of these morphing techniques used by metamorphic viruses is with the insertion and removal of "garbage" instructions. These are instructions that have no effect on the function of the virus, but simply take up space and which can make analysis more difficult when they appear in large quantities. Another technique is to change the basic encoding of instructions at the opcode level. That is, switching between two different opcodes that are functionally-equivalent.
Perhaps the most complex transformation of a metamorphic virus is the replacement of entire blocks of logic with functionally-equivalent blocks of logic. Consider the task of multiplying x by 3. One expression of this is "3*x". However, an alternative expression is to replace the single multiplication with a repeated addition instead: "x+x+x". Both expressions will result in the same answer, yet they look very different.
An entry-point obscuring ("EPO") virus is a virus that gets control from the host program in an indirect way, rather than straightforwardly through the main entry-point. Typically, it involves patching a variable location in the host program code, perhaps a function prologue or an API call sequence, and redirecting control flow to the virus code from there.
An inherently difficult virus could be a polymorphic Win32 virus whose appearance varies greatly between samples. Regardless of what technology is available to detect the virus, the first hurdle is to analyze and understand the way the virus works, and invent an algorithm capable of detecting all virus replicants. This can be a daunting task, even assuming the ability to write the detection as a standalone program in a language of one's choice.
Determining the threat
Complex viruses do not represent a real threat until they are discovered outside of a laboratory and "in the wild". Herein lies the problem: the difficulty is in defining what it means for a virus to be "in the wild".
The industry definition of a virus "in the wild" is typically a virus that has been seen by at least two independent submitters in at least two different regions. However, this definition overlooks the existence of localized outbreaks, in which one or more companies in a single region might be heavily infected. In that case, a virus might be considered "in the wild" based solely on the number of submissions, but this can be misleading if people submit the same virus sample repeatedly. This also overlooks the case of virus "seeding", in which a virus is placed in a public location, such as the Usenet newsgroups, in the hope that enough people will be tempted to run it -- but no one actually does.
The fact remains that many of the most complex viruses are not especially widespread. If a sample of this virus has not been submitted by a "sufficient" number of outsiders, in a short period of time, it may be considered a "zoo" virus with minimal widespread threat. However, it's important to remember that this level of threat can change at any time.
Examples of "zoo" viruses
Examples of infamous "zoo" viruses include the complex Win32 viruses known as W95/SK (PDF document), W95/Zmist (PDF document), W32/Simile (PDF document), W32/Efish (PDF document) (from the W32/Chiton family), and W95/Perenast. Just mention any of these names to an AV researcher and watch their terror-stricken face. W32/Gobi (PDF document) and W32/Zelly are two of the most recent such brain-teasers. Both are very polymorphic, employing multiple encryption layers and entry-point obscuring.
These examples are all worth a few days (and nights) of work at the least, taking into account reverse-engineering, replicating the virus, and writing the detection signature. It can help a researcher to start writing the detection as a standalone C program before integrating it into one's AV product.
Limitations in AV engine technology
Unfortunately AV researchers do not have the luxury to write standalone programs from scratch to respond to new viruses. Instead they are constrained by a framework imposed by an AV product. The framework may be more or less flexible, and usually comes with a set of constraints that largely determine how efficient a response will be possible.
A comparatively simple virus affecting an emerging platform (say, Win64) may expose AV engine limitations that make it just as hard to detect as a tough Win32 polymorphic virus, in a subjective way -- depending on what AV engine technology is available to respond. Maybe the affected file format is not parsed by the engine, or only incompletely supported. Emulation may or may not be available. These factors greatly influence the ability to detect the virus.
Some of the new viruses that affected the Win64 platform in 2004, and were relatively difficult to detect, included W64/Rugrat (PDF document) (IA64), W64/Shruggle (AMD64), plus some new viruses with MSIL infectors. The corresponding executable file formats are varied, and even the job of picking a simple search string for an immutable virus can turn into a contortionist's exercise if the underlying AV engine lacks support for these file formats.
Naturally, there is the fear of an inherently difficult virus affecting an esoteric or emerging platform like Win64. Such viruses do occasionally surface in zoo collections, to the delight of no one except a virus researcher. Two examples of these new viruses, both released in early 2004, are MSIL/Impanate (PDF) and MSIL/Gastropod (PDF document) - viruses for the Microsoft .NET framework. The first of these, MSIL/Impanate, is an EPO virus. It appends its code to a random method in the file, and rebuilds the host around it. The second of these, MSIL/Gastropod, is a metamorphic virus. Its appearance is altered by the virus intentionally adding and removing "garbage" instructions.
The importance of detecting complex viruses
You may rightfully ask: why does it matter to detect such viruses, if they belong to "zoo" collections? Well, first of all, sometimes they do find their way into the wild. W32/Toal, for instance, a difficult polymorphic worm, was discussed on an emergency virus mailing list after being spotted actively spreading. Some complex viruses currently registered as zoo samples spread aggressively enough that they would stand a chance to infect machines in the real world if some mischievous soul were to release them.
Moreover, even for purely zoo viruses unlikely to ever cause problems in the wild, the response (or lack thereof) of AV companies to such viruses can reveal a lot about limitations in the engine technology available, and perhaps the skill and dedication of the response teams. Some companies provide detection quickly, in a matter of hours or days, while some others finally ship a solution after months of work (or years in some extreme cases, like W95/Zmist!), and yet other companies simply give up.
Besides the speed of response, the quality of detections also varies greatly, as measured by the ability to detect all samples of a polymorphic virus for instance, and doing so with an acceptable false-positive rate. What is an acceptable false-positive rate? While this varies from company to company, usually no more than a handful of false positives would be considered acceptable -- however, there are exceptions to this. One recent example, W32/Zelly, was allowed an enormous (up to 50%) false-negative rate by some anti-virus companies just to be among the first to detect it.
What if your AV company gives up on difficult zoo viruses? It certainly says something about either the flexibility of their technology, or the skill and dedication of their response team. What if tomorrow's Mydoom is heavily polymorphic? Will they be able to respond to it in a timely manner?
If you think it's an unlikely scenario, compare it to the following analogy: if you had to pick a surgeon, would you choose the one who carried out hundreds of successful open-heart surgeries, or the one who only ever did appendectomies? Even for an appendectomy, most would choose the first one.
Conclusion
In this article we've looked as some of the difficulties in detecting complex viruses, by first discussing what they are and why they can be difficult to discover. We then looked at a few examples of "zoo" viruses and how they can uncover limitations in various AV engines. As we have seen, finding complex viruses can be another useful metric in determining which anti-virus technology is best suited to the needs of an organization -- in addition to other common metric such as response time to new threats, and how effective the pro-active detection offered really is.
A new way to bypass Windows heap protections
Windows heap overflows have become increasingly popular over the last couple of years. Papers like, "Third Generation Exploitation" [ref 1] or, "Windows Heap Overflows" [ref 2] introduced the internal structure and handling mechanisms of Windows heaps, and presented ways to exploit heap-based buffer overflows. Techniques to make highly reliable exploits were presented in the paper, "Reliable Windows Exploits" [ref 3]. Heap exploitation is now mastered for systems such as Windows XP, Windows XP SP1 and Windows 2000. However, the introduction of Windows 2003 -- and later, Windows XP SP2, brought another level of protection hackers would have to bypass in order to exploit heap overflows on these systems. In this paper, we'll remind readers of the principles of classic heap overflow exploitation, and explain why these techniques do not work with the newest Windows platforms. Then, we'll present a way to bypass a first level of protection, to trigger a memory overwrite. Each chunk contains a header (shown in Figure 2), detailing its size, the size of the previous block, if it's busy or not, in which memory segment it is located, and so on. This header is usually 8-byte long, and following it begins the real storage area of the chunk. If the chunk is free, two pointers will be concatenated to this classic header, referencing the previous and next (not necessarily adjacent) free blocks of the same size. These pointers are called FLink and BLink, which respectively stand for "Forward" and "Backward" links. When an overflow occurs in a chunk, the header structure of the next adjacent chunk is overwritten. By forging "malicious" values, a subsequent heap operation can trigger an arbitrary 4-byte memory overwrite. Of course, this is not the result of voodoo magic, but simply the exploitation of a heap mechanism called "unlinking". Several exploitation scenarios exist; the author will remind readers only of the simplest one. Suppose we overflow the contents of a free block. When this block is allocated, it will be removed from its doubly-linked list; this process takes place in two steps. First, the FLink pointer of the previous chunk will be updated to reference the next chunk; then, the BLink pointer of the next chunk will be updated to reference the previous chunk. This is the unlinking process, which is achieved in two assembly instructions: Thus, forging FLink and BLink will lead to a 4-byte memory overwrite. Gaining control is the next step; please see the References section to learn more about this. Others protections have been introduced as well, mainly PEB randomization, and exception pointers encoding. The goal is to minimize the amount of fixed and well-known function pointers, used globally by the process. These locations were priviledged targets to exploit a heap overflow the old way. This first public method to bypass the new heap protections consists of exploiting the inexistent checks on the lookaside list (refer to the paper, "Defeating Windows XP SP2 Heap protection and DEP bypass" [ref 4] if you want to learn more about lookaside lists). The first dword of a lookaside entry is the start of a simply-linked list of chunks, marked as busy, but ready for allocations. When an allocation occurs, the first block of a matching lookaside list may be returned: It is simply removed from the list by replacing the forward link pointer (FLink) in the lookaside entry by the FLink pointer of the newly allocated block. This process is explained in Figure 3. This new technique is good in theory, but practically, it is hard to use. The following heap operations must occur, by forging good input values, if we want the N-byte overwrite to happen: 1 -- Allocation of a block of size N (<0x3F8 bytes). As you can see, these conditions can be hard to produce in practice, especially in complex programs. The heap must also have an active and unlocked lookaside table for the operation to succeed. The process default heap, as well as others system-created heaps, is used by many Windows APIs to store information concerning the process and its environment. When a dynamically-linked library (DLL) is loaded, its main function is executed (DllMain, or similar) and often, data can get stored on the process heap. What if these pieces of data are overwritten? The fact that even the simplest program, like Widows Notepad, needs so many libraries to run is particularly interesting. If we examine the default heap, before the main thread even starts to execute, we'll notice that a fair amount of heap chunks have been allocated. A quick look at the default heap reveals that many of these chunks have a length of 40 bytes (including 8 bytes for the header) and have the structure described in Figure 4: Where: A is the Address of the next "40-byte long structure". B is the Address of the previous "40-byte long structure". Note: If you create the process with a debugger, these structures will be 56-bytes long. By default, a heap trailer of 16 bytes is added by the system when the process is created with the "DEBUG_PROCESS" flag. The first noticeable thing is that A and B play the roles of backward and forward pointers. It also happens that the structure pointed by X is in fact a critical section. When a critical section is initialized, an associated "40-byte long structure" -- we will call it a linking structure -- is also created to keep track of the critical section. A few of these structures are located in the data section of ntdll.dll; when all of them are used, the linking structures are created in the default heap. Figure 5 shows how all critical sections of a process are linked together. This doubly-linked list reminds us the way free chunks are handled by heap management routines. During the destruction of a critical section, the associated linking structure will be removed from its list. If we replace A and B, we should then be able to overwrite a 4-byte portion of memory. And in fact, we can easily find the code in charge of the unlinking process (with a debugger, just replace A and B by invalid addresses, and destroy the critical section to trigger a memory access violation exception). The following assembly lines are executed by RtlDeleteCriticalSection (ntdll.dll version 5.1.2600.2180): These lines probably remind you what we've discussed earlier. And in fact, the principle is the one of classic heap overflow exploitation: if we can't use the chunk pointers anymore, let's use the pointers of another linked list! We are very lucky here because these structures are very common in the process heap, and absolutely no sanity checks are performed on them. Moreover, critical sections are often destroyed during process termination, which ensures that the overwriting will occur. The old couples (fixed "CALL" instruction, Exception handler pointer) and (Pointer to payload, PEB function pointer) do not work anymore, mainly because of memory protections introduced with the Service Pack 2 of Windows XP: These protections were also ported in the Service Pack 1 of Windows 2003 -- Windows 2003 SP0 only implemented heap protections. Therefore, new places remain to be found in order to produce reliable exploits. Nonetheless, producing a memory overwrite on the newest Windows systems is possible, and this is the first step towards exploitation of heap overflows. [ref 2] David Litchfield [ref 3] Matt Conover, Oded Horowitz [ref 4] Alexander Anisimov
A quick overview of Windows heap overflows
A heap is a collection of contiguous chunks of memory, as shown below in Figure 1. When one decides to allocate dynamic memory in a program, the allocation occurs in a heap. Functions like malloc(), GlobalAlloc(), LocalAlloc() or HeapAlloc() are only wrappers of the core function RtlAllocateHeap(); this API, exported by ntdll.dll, is in charge of allocating memory in a heap. Other Rtl*Heap() functions exist as well, to create and destroy heaps, and manipulate chunks. 
Figure 1. A heap is a collection of contiguous heap chunks.
Figure 2. A regular heap-chunk. mov [reg1], reg2 ; reg1=FLink
mov [reg2+4], reg1 ; reg2=BLinkIntroducing heap protections
These techniques worked well with Windows XP (SP0, SP1) and Windows 2000 operating systems. (Un)fortunately, things changed with the arrival of Windows 2003. Microsoft modified heap management routines and heap structures in order to check the validity of a chunk before allocating or freeing it. The protection was flawed
Unfortunately, the protection was not 100% heap-overflow-proof, as Alexander Anisimov showed at the beginning of 2005. 
Figure 3. Allocation of a block A from the lookside table..
2 -- Freeing of this block: the block gets referenced in the lookaside table.
3 -- The overflow occurs in a previous adjacent block: we can manipulate the FLink pointer of the previously freed block.
4 -- A block of size N is allocated: our fake pointer is written in the lookaside table.
5 -- A second block of size N is allocated: our fake pointer is returned.
6 -- A copy operation from a controlled input to this buffer occurs: these bytes are written to our chosen location.Another way to bypass heap protections
This method presents a way to overwrite at least 4 bytes of memory, by overflowing special structures stored in the process default heap. 
Figure 4. A 40-byte long heap chunk, found in the process default heap.
Figure 5. Critical sections and linking structures. mov [eax], ecx ; eax=B
mov [ecx+4], eax ; ecx=AThe upcoming issue: gaining control
Overwriting memory is the first step of heap-based buffer overflows exploitation; the second and third steps are to choose which value (A) and place (B) to overwrite. Conclusion
The major drawback is that critical sections are often destroyed at process termination, which would force a potential exploiter to crash the program in order to trigger the overwrite. Moreover, the overflow must occur in the process default heap, and a minimal flexibility is required to overwrite a linking structure. Proof of concept
The author has provided a proof-of-concept to demonstrate an implementation of his technique. References
[ref 1] Halvar Flake
"Third Generation Exploitation"
http://www.blackhat.com/presentations/win-usa-02/halvarflake-winsec02.ppt
"Windows Heap Overflows"
http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchfield.ppt
"Reliable Windows Exploits"
http://cansecwest.com/csw04/csw04-Oded+Connover.ppt
"Defeating Windows XP SP2 Heap protection and DEP bypass"
http://www.maxpatrol.com/defeating-xpsp2-heap-protection.pdf
Microsoft Office Security, part two
1. Continuing from part one Feature: 'Track Changes' is used in case several revisions are made to the same document by one or more users. It displays all modifications made to the document including any insertions, deletions, changed lines and comments. Investigator's Interest: If the 'Track Changes' feature is turned on, even after distributing the file (via e-mail, on the local network or through a physical device), by default, the file opens in the 'Track Changes' mode to reveal all changes made. It also shows up with all the comments, if added, by other authors/reviewers of the document along with the name of the author. Note: by default, the 'Make hidden markup visible when opening or saving' option is enabled to refrain the user from accidentally distributing the document with any sensitive information. This was the procedure for disabling the feature in Word 2003. However, in Word 2002, the markup text can be hidden through the reviewing toolbar as showin in Figures 7 and 8, and it will not show up on opening or saving the file. Sometimes, even the comments show up 'as is' when the document is re-opened. These can be hidden as shown above. However, a technique exists for deleting a large number of comments in a document. This can work for MS Word and MS Excel documents. A simple macro can do the trick and rid you from the painful task of deleting each comment manually. Macro for deleting comments from MS Word: add the following macro to the desired document or document template: Investigator's Interest: If the document is sent through Outlook, when the recipient opens the document and views the file properties (Files > Properties > Custom), entries such as _TentativeReviewCycleID and _ReviewCycleID, _EmailSubject, _AuthorEmail, and _AuthorEmailDisplayName are shown. The details of this 'Custom' tab are also stored on the recipient's system in a file called 'Adhoc.rcd' or 'Review.rcd' (depending upon the version of MS Office used; it's 'Review.rcd' in the case of Office 2003). They are usually found in the following location: System_Drive>User's_Documents_and_Settings>\Application Data\Microsoft\Office. The Adhoc.rcd or Review.rcd file typically contains the same information as shown in the Custom Properties tab. The entry reveals the following: For any reason, if the investigator needs to access the email message, he/she can route back to it via the Exchange server or any other convenient technique. You can avoid this by: Investigator's Interest: An exhaustive listing of the file properties reveals information which may turn out to be crucial evidence, may help build a timeline, or may help make certain deductions during the analysis phase of the forensic investigation. No known workaround or solution exists to stop an MS Office application from being recovered. We cannot stop MS Office from recording metadata but we can definitely take measures to hide it. Thus when sending any files, one can: Feature: This is feature which displays the list of recently opened files. A maximum of nine entries can be displayed: Investigator's Interest: Such a listing undoubtedly serves as a quick reference as to where to begin from and saves the investigator the trouble of going through the metadata of several Office files individually. The number of entries in the 'Recently Opened Files' option can be set to 0, as shown below in Figure 14. One can avoid the Task Bar from showing up each time an Office application is opened as well. This is shown below in Figure 15. The 'Privacy Options' feature is used to secure the document primarily against information disclosure. The first feature is that it helps secure personal information associated with any document. Personal Information refers to the document details which are written and archived across users and authors of the same document. Its important to understand that 'Personal Information' is not the 'User Information' included in the file as shown in Figure 16: This kind of personal information may be confidential. No one would (even accidentally) like their prospective employer to know who helped them make changes/revisions to their resume nor would anyone like to disclose this to their potential client. Consider the number of revisions made to a price quote before sending the final proposal, as well as knowing who all made the revisions! The following option can save the reader from embarrassment and ensure the security of the document. Tools > Options There are times when you would like to keep the names of the authors confidential but show the comments and modifications through Track Changes. There is a somewhat tedious way to change the name of the authors/reviewers of the document as shown below: Step 1: Save the file in rich text format (.rtf) using the 'Save As' option. The above method shows the list of authors of the document. There are other ways of accessing this information and investigating much more with the help of a file viewing utility called the DocFile View. This utility provides the property set IDs of the OLE Structured Storage and its corresponding values saved in the document's SummaryInformation stream. The PropID shown in Figure 23 should be mapped with the Property ID hexadecimal value (column 3) in Figure 24. As seen from the screenshots, a forensics investigator may quickly collect important document information like the Author, User and so on who saved the document last, the time and date of the last save, revision number, and more. One may wonder why this procedure is needed when one can simply open the file and visit the 'Properties' sub-menu to access all of the above information. The answer is quite simple. Such tools help the forensic investigator to retrieve all the information without actually opening the file. He can scan a large number of files one after the other to get any evidence. Note: This method will not prove helpful if the file is in the 'Read Only' mode or if it has been encrypted. The best way to remove all personal information before sending any document is by using an Add-in from Microsoft which can permanently remove hidden data and collaboration data, such as change tracking and comments, from Microsoft Word, Microsoft Excel, and Microsoft PowerPoint files. MS Office overall provides very good security features and recovery options. Some are well-known while others are not. The suggested techniques in this article could be implemented to secure one's written communication. The forensic investigator's perspective was shown to highlight the areas of possible forensic interest. The features highlighted do not play against the user but guide the user to be careful with the documents and set the security options after deciding the confidentiality and sensitivity of the document.
The flood of recent Microsoft Office vulnerabilities has brought forth the need to understand the mechanics of the MS Office security architecture and the possible fault injection points. The first part of this article primarily discussed Microsoft Office's OLE Structured Storage and the nature of recent dropper programs and other exploit agents, in an effort to scrutinize the workings of some of the recent MS Office exploits. Now the second part looks at some forensic investigation avenues with different MS Office features. Parts of the article sample different MS Office vulnerabilities to discuss their nature and the method of exploitation.
2. Avenues for MS Office forensic investigation
During the 'analysis' phase of a forensic investigation involving MS Office files, some features which investigators would fancy are explained below. Known to aid the efficiency of the software, these features can turn out to be excellent sources for information for vital evidence. 2.1 Track Changes turned on (Tools > Track Changes) (Ctrl+Shift+E)
2.1.1 Turn off 'Track Changes' (Tools > Options > Security)
Note that for continuity with part one of this article, which had five illustrations, we'll start with Figure 6. 
Figure 6. Making hidden markups visible in MS Office 2003. 
Figure 7. Making hidden markups visible in MS Office 2002. 
Figure 8. Making hidden markups visible in MS Office 2002. 2.1.2 Deleting a large number of comments in a document
'Function to delete and confirm the deletion of comments
Sub DeleteAllCommentsAndConfirm( )
'Variable Initialization
Dim i As Integer
Dim iNumberOfComments As Integer
If MsgBox( _"Are you sure you want to delete
ALL comments in this document?", _vbYesNo) = vbYes Then
iNumberOfComments = ActiveDocument.Comments.Count
For i = iNumberOfComments To 1 Step -1
ActiveDocument.Comments(i).Delete
Next i
MsgBox iNumberOfComments & " Comment(s) Deleted", vbInformation
End If
End Sub2.2 Document sent for review through MS Office applications
Feature: 'Send to Mail Recipient for Review' allows documents to be sent to the default e-mail application. It should be used very carefully as it has the details of the entire document. This is shown below in Figure 9. 
Figure 9. Mail recipient option (for review). 2.3 Recover unseen metadata
Feature: The 'Recover Text From Any File (*.*)' File Open option. This option rips the formatting off the document and displays all the text along with the exhaustive file properties. This is shown below in Figures 10, 11, and 12. 
Figure 10. 'Recover Text From Any File (*.*) Option. 
Figure 11. Dialogue when file recovered (Select Close). 
Figure 12. Sample contents of the recovered file. 2.4 'Recently Opened Files' Listing
Figure 13. Recently opened files listing. 
Figure 14. Highlighted Entry to be set to '0'. 
Figure 15. 'Startup Task Pane' viewing option to be unchecked. 2.5 MS Office 'SummaryInformation'
Figure 16. Sample 'User Information'. 
Figure 17. Personal Information: Different author details with 'Track Changes' turned on. 
Figure 18. Personal Information: Different author details with 'Track Changes' turned on. 
Figure 19. Removing 'Personal Information' from file properties.
Step 2: Open the document in any rich text editor or even Notepad.
Step 3: Look for the string '{\*\revtbl'.
Step 4: The content of the braces following this string has the list of authors/reviewers.
Figure 20. Author Identification with '{\*\revtbl' string. 
Figure 21. Entry modification. 
Figure 22. Changed entry in MS Word. 
Figure 23. SummaryInformation viewed through DocFile View. 3. Conclusion
Part one of this article looked primarily at the OLE Structured Storage of Microsoft Office documents. Part two looked at forensic avenues that can be used by investigators, post-compromise. Some of the features shown in part two are more appropriate for a proactive approach towards incident response. Usually, forensic investigators do not start the application on the compromised system, they make an image of the disk and begin to investigate the contents using sophisticated tools and techniques. 4. References
4.1 Web references
4.2 Selected book references
5. About the author
Khushbu Jithra, is an Information Developer and Security Researcher at NII Consulting, an Information Security Consulting firm based out of India. She writes at iScribe on her main interest - Information Security Documentation 6. Comments?
The comments section of this article is to be used for technical clarification and discussion only. Submitted comments must have technical merit in order to be approved. 7. Copyright
This article is © Copyright 2006, SecurityFocus. Reproduction without prior authorization is prohibited.
Microsoft Office Security, part one
The flood of recent Microsoft Office vulnerabilities has brought forth the need to understand the mechanics of the MS Office security architecture and the possible fault injection points. This article discusses Microsoft Office's OLE Structured Storage and the nature of recent dropper programs and other exploit agents, in an effort to scrutinize the workings of some of the recent MS Office exploits. The second part of this article then collates some forensic investigation avenues through different MS Office features. Parts of the article sample different MS Office vulnerabilities to discuss their nature and the method of exploitation. In the high frequency band of 'Remote Code Execution' vulnerabilities, all the vulnerabilities are of varying risk levels. However these vulnerabilities are the ones that pose the highest risk to systems. Denial of Service and Memory Corruption vulnerabilities, in comparison, pose a medium to high risk to systems. Vulnerability distribution for different MS Office applications, and collectively for all applications, is shown below in Figure 2. The reader is given this overview of different vulnerabilities affecting MS Excel, MS Word and MS Powerpoint, respectively. Each bar in Figure 2 represents individual application vulnerabilities, however the MS Office bar is not an aggregate of the three bars. Instead the MS Office bar represents the vulnerabilities which affect all MS Office applications collectively. The following sections will now provide a better understanding of some of these vulnerabilities. In the context of this article, OLE Structured Storage is defined as a systematic organization of components of any MS Office document. Each document has a root component which contains storage and stream components. The OLE Structured Storage is synonymous with the file system structure, such that 'storage' components are equivalent to directories and 'stream' components are equivalent to files, as shown below in Figure 3. A storage component may exist as a standalone component. Each storage component may have one or more sub-storage components and stream components. Also the root component may have stream components directly within it. MS Office 2000 and later versions support two file formats: OLE-binary based and the XML-based. Both are two forms of structured storage with the latter being a more browser-friendly option for storing documents. Figure 4 shows the mapping of the OLE Structured Storage to a sample Word document structure. The 'MS Word' component is the root component containing several streams and one storage item. Different parts of the document such as the actual contents, any table inserted, the CompObj associated with the DLL files for the objects, the Summary Information for the content, any image inserted, and the Document Summary Information, all take the form of streams under the root component. The ObjectPool is the collective storage of all the sub-storage components. The figure samples the sub-storage Excel component. The Excel Sheet itself is a storage component within the ObjectPool and has its own streams of information – the Workbook, SummaryInformation, and DocumentSummaryInformation. Different MS Office files are structured similarly. Different objects can be embedded into the document and are accessed and updated from their respective stream/storage components. Some COM and OLE vulnerabilities allow for an escalation of privileges and lack proper input filtration, leading to the compromise of systems running MS Office applications. Another instance of insertion of malicious objects is the Microsoft Word Malformed Object Pointer Remote Code Execution Vulnerability. This attack is illustrated below in Figure 5. Steps to exploitation: Step 1: The targeted victim opens the malicious MS Word document via an email attachment or a web page. In the above attack, if we were to break the vulnerability into different stages, the first vulnerable stage is when the attacker was able to draft or create a malicious Word document. The OLE Structured Storage fails to verify the content of the storage components and allows executables like Trojans to be inserted. The second stage is when the victim is lured into opening the malicious MS Word document via an email attachment or by downloading it from a Web page. The third stage is the malformed object pointer, which allows the malicious storage component to get executed as soon as the Word document is opened. Once the seed is planted, the Trojan is put into action. The fourth stage helps the embedded Trojan install a backdoor which can help the remote attacker to execute arbitrary code on the victim's system and eventually compromise it. To understand this further we can investigate the working of dropper programs in the next section of this article. A Trojan dropper typically extracts all its files to a temporary folder and executes all of them simultaneously. Dropper programs are seldom caught by any anti-virus programs or vulnerability scanners. This is due to the following reasons: Several other MS Office vulnerabilities have been exploited due to improper input filtration, inadequate string parsing capabilities of the OLE Structured Storage functions, inadequate validation of a stream component variable (causing buffer overflows), memory corruption, and faulty rendering of the OLE Property Sets. Discussing each vulnerability in detail is out of the scope of this article, but an observation can be made about the vulnerabilities overall. Almost all the vulnerabilities require the target to gauge the nature of the MS Office document before it is opened. This becomes increasingly difficult when anti-virus software is fooled by exploit agents like the dropper programs. Thus, the only solution is to correct the mechanism of the OLE Structured Storage itself. While many vulnerabilities have been addressed in the Microsoft Security Bulletins, some quick workarounds for different vulnerabilities can also be implemented. These will be discussed in the next section. As we all know, the MS Office architecture is very user-friendly and provides good backup and recovery options. It also provides excellent capabilities for reviewing documents in groups and inserting and embedding third-party application objects into MS Office applications. However, these same capabilities give us an interface to several forensic avenues which can turn out to be very useful during a forensic investigation. In the following section we'll conclude this article and then take a look at a preview of part two, which will discuss some of the ways a forensic investigator can look for document information and collect author evidence and view hidden information in MS Office documents. We'll also look at recovering unseen metadata in Office applications, Microsoft's 'SummaryInformation' features, and various ways of deleting personal data from with a document. Stay tuned.
1. Overview of recent MS Office vulnerabilities
MS Office vulnerabilities have aroused concerns, particularly for MS Office documents received through e-mail or downloaded from web sites. Some published vulnerabilities allow memory corruption or lead to buffer overflows, whereas others escalate privileges - all leading to compromising the victim's system. An approximate number of vulnerabilities in different MS Office documents against the vulnerability type, calculated at the time of this writing, are shown in the Figure 1 below. 
Figure 1. MS Office vulnerability overview. msoff1-thumb.jpg 
Figure 2. Vulnerability distribution across MS Office applications. 2. OLE Structured Storage
One of the earliest MS Word vulnerabilities this year was exploited with the help of dropper programs embedded in the file structure of a MS Word file. Several vulnerabilities related to malformed images and media objects in MS Office similarly require the understanding of OLE Structured Storage, the MS Office file structure. 
Figure 3. OLE Structured Storage. 2.1 MS Office Documents and its components
Let's take a look at the structure of a Word document with an embedded Excel object, shown below in Figure 4. 
Figure 4. Sample Word document storage format. 3. Sample mechanism of an attack
In a common attack scenario, the vulnerability is exploited via a simple insertion of a malformed or malicious object into the document structure. Some MS Excel and MS Word vulnerabilities are affected by such an attack. 
Figure 5. Exploitation - malformed object pointer vulnerability.
Step 2: The malicious storage component (dropper program) within the OLE Structured Storage gets executed as the Word file is opened.
Step 3: The Trojan is dropped on the victim's system.
Step 4: The trojan operates with a backdoor which allows the remote attacker to collect system information, access the command shell and take screen shots and store them to %System%\Capture.bmp.3.1 Dropper Programs
A dropper is a program that has been designed or modified to "install" standalone malware (such as Trojans, worms, backdoors) onto the target system. The malware code is usually contained in a dropper in such a way that it won't be detected by virus scanners. 4. Consolidated Workarounds
Nearly all workarounds start with warning users to avoid any unsolicited attachments from both known and unknown entities. However, more can be done to save systems from being compromised. There are workarounds provided by Microsoft on different occasions and for different MS Office vulnerabilities which can be used as common guidelines to deal with MS Office documents until updates or patches are released: Winmail.dat to store the TNEF information. Blocking this file and blocking the application/ms-tnef MIME type could help protect both Exchange Servers and other affected programs from attempts to exploit this vulnerability. 5. Concluding part one
In the first part of this two-part series, we've taken a very cursory look at some of the security issues within Microsoft Office applications. Recent vulnerabilities and their subsequent exploitation has brought renewed interest in office document security within corporations, government and at home. 6. Preview of part two
Part two of this article will aid investigators with the 'analysis' phase of a forensic investigation. There are a number of features or tools available to help with the forensic process, and these will be discussed in some detail. We'll start with the popular track changes feature, making hidden markups visible in MS Office 2003 and 2002, and provide a script to aid in the deletion of a large number of comments from within a document. Then we'll look at issues when a document is sent through Office's send through e-mail feature with Exchange. 7. References
7.1 Web references
7.2 Selected book references
8. About the author
Khushbu Jithra, is an Information Developer and Security Researcher at NII Consulting, an Information Security Consulting firm based out of India. She writes at iScribe on her main interest - Information Security Documentation 9. Comments?
The comments section of this article is to be used for technical clarification and discussion only. Submitted comments must have technical merit in order to be approved. 10. Copyright
This article is © Copyright 2006, SecurityFocus. Reproduction without prior authorization is prohibited.
Introduction to Windows Integrity Control
This article takes a look at the Windows Integrity Control (WIC) capabilities in Windows Vista by examining how it protects objects such as files and folders on Vista computers, the different levels of protection offered, and how administrators can control WIC using the ICACLS command-line tool. WIC is intended to protect a system from malware and user error by helping to establish different levels of trust on objects.
System integrity - Who can you trust?
When the developers at Microsoft set out to create the latest version of their operating system, Windows Vista, they set out to ensure it was the most secure version of Windows yet. One of the functions that has been built in to Windows Vista which helps to make it more secure is Windows Integrity Control, or WIC.
The purpose of WIC is to protect objects, whether they are files, printers, named pipes, registry keys, and so on from attacks, malware or even innocent user error. The concept of WIC is based on establishing the trustworthiness of the various objects and controlling the interactions between objects based on their integrity, or level of trustworthiness.
The integrity levels of WIC are a mandatory control and override discretionary controls such as NTFS file and folder permissions which most administrators are familiar with. The primary objective of WIC is to ensure that only objects with an integrity level equal to or greater than the target object are allowed to interact with it. Essentially, if an object is less trustworthy, it is prohibited from acting on, or interacting with more trustworthy objects.
Again, WIC trumps normal permissions. That means that even if a file or process has Full Control permissions to another object, if the file or process has a lower integrity level than the object it is trying to interact with WIC will override the permissions and the interaction will be denied.
Determining trustworthiness using WIC
In order to police the interactions between objects, Windows must first determine the trustworthiness, or integrity level of each object. WIC assigns one of the following six integrity levels to each object:
* Untrusted – processes that are logged on anonymously are automatically designated as Untrusted
* Low – The Low integrity level is the level used by default for interaction with the Internet. As long as Internet Explorer is run in its default state, Protected Mode, all files and processes associated with it are assigned the Low integrity level. Some folders, such as the Temporary Internet Folder, are also assigned the Low integrity level by default.
* Medium – Medium is the context that most objects will run in. Standard users receive the Medium integrity level, and any object not explicitly designated with a lower or higher integrity level is Medium by default.
* High – Administrators are granted the High integrity level. This ensures that Administrators are capable of interacting with and modifying objects assigned Medium or Low integrity levels, but can also act on other objects with a High integrity level, which standard users can not do.
* System – As the name implies, the System integrity level is reserved for the system. The Windows kernel and core services are granted the System integrity level. Being even higher than the High integrity level of Administrators protects these core functions from being affected or compromised even by Administrators.
* Installer – The Installer integrity level is a special case and is the highest of all integrity levels. By virtue of being equal to or higher than all other WIC integrity levels, objects assigned the Installer integrity level are also able to uninstall all other objects.
In terms of the impact on Windows Vista security, these integrity levels and WIC protect objects from intentional or unintentional modification or deletion by less trusted objects. By setting the Medium integrity level as the default mode for standard users and for all unlabeled objects, Vista protects the majority of objects on the computer from being affected in any way by threats from the Internet, which run at the Low integrity level by default.
Similarly, although Administrators are more powerful than standard users and operate at the High integrity level, the operating system kernel and core functionality receive a higher System integrity level, ensuring that even an absent-minded Administrator or compromised Administrator account can not adversely impact the core system.
To reiterate, the WIC integrity levels and controls are very similar to normal NTFS file and folder permissions. The primary difference is that NTFS permissions are discretionary controls while WIC integrity levels are mandatory controls. Basically, file and folder access privileges and permissions are assigned by the object owner or an administrator, while WIC integrity levels are dictated by the operating system.
While the upper four levels receive little practical use, the differentiation between Low integrity and Medium integrity is where the majority of WIC’s functionality lies. Implementing mandatory controls rather than relying only on the discretion of users or administrators certainly provides more security at all levels. But, the ability to segregate files and processes from the Internet and protect the computer from Internet-borne malware is one of the primary reasons for the existence of WIC.
Protecting Vista from Internet threats
While standard users operate at a Medium integrity level and Administrators are designated as High integrity, WIC assumes that the Internet, and any associated files or processes, are completely untrustworthy and assigns them a Low integrity level by default.
When a user receives an email with a link to a malicious web site (the sort of email they have been told a thousand times to delete), and he clicks on it, the malicious web site may attempt to install some sort of nasty malware. The malware will typically copy itself to some location on the hard drive and modify Registry keys to ensure its continued existence. It may also try to modify or delete other files or execute processes to initiate other malicious activity.
Windows Anti-Debug Reference
This paper classifies and presents several anti-debugging techniques used on Windows NT-based operating systems. Anti-debugging techniques are ways for a program to detect if it runs under control of a debugger. They are used by commercial executable protectors, packers and malicious software, to prevent or slow-down the process of reverse-engineering. We'll suppose the program is analyzed under a ring3 debugger, such as OllyDbg on Windows platforms. The paper is aimed towards reverse-engineers and malware analysts. Note that we will talk purely about generic anti-debugging and anti-tracing techniques. Specific debugger detection, such as window or processes enumeration, registry scanning, etc. will not be addressed here.
[1] Intro
This paper classifies and presents several anti-debugging techniques used on Windows NT-based operating systems.
Anti-debugging techniques are ways for a program to detect if it runs under control of a debugger. They are used by commercial executable protectors, packers and malicious software, to prevent or slow-down the process of reverse-engineering.
We'll suppose the program is analyzed under a ring3 debugger, such as OllyDbg on Windows platforms. The paper is aimed towards reverse-engineers and malware analysts.
Note that we will talk purely about generic anti-debugging and anti-tracing techniques. Specific debugger detection, such as window or processes enumeration, registry scanning, etc. will not be addressed here.
[2] Anti-debugging and anti-tracing techniques
- Exploiting memory discrepancies
(1) kernel32!IsDebuggerPresent
IsDebuggerPresent returns 1 if the process is being debugged, 0 otherwise. This API simply reads the PEB!BeingDebugged byte-flag (located at offset 2 in the PEB structure).
Circumventing it is as easy as setting PEB!BeingDebugged to 0.
Example:
call IsDebuggerPresent
test eax, eax
jne @DebuggerDetected
...
(2) PEB!IsDebugged
This field refers to the second byte in the Process Environment Block of the process. It is set by the system when the process is debugged.
This byte can be reset to 0 without consequences for the course of execution of the program (it is an informative flag).
Example:
mov eax, fs:[30h]
mov eax, byte [eax+2]
test eax, eax
jne @DebuggerDetected
...
(3) PEB!NtGlobalFlags
When a process is created, the system sets some flags that will define how various APIs will behave for this program. Those flags can be read in the PEB, in the DWORD located at offset 0x68 (see the reference).
By default, different flags are set depending if the process is created under a debugger or not. If the process is debugged, some flags controlling the heap manipulation routines in ntdll will be set: FLG_HEAP_ENABLE_TAIL_CHECK, FLG_HEAP_ENABLE_FREE_CHECK and FLG_HEAP_VALIDATE_PARAMETERS.
This anti-debug can be bypassed by resetting the NtGlobalFlags field.
Example:
mov eax, fs:[30h]
mov eax, [eax+68h]
and eax, 0x70
test eax, eax
jne @DebuggerDetected
...
(4) Heap flags
As explained previously, NtGlobalFlags informs how the heap routines will behave (among other things). Though it is easy to modify the PEB field, if the heap does not behave the same way as it should when the process is not debugged, this could be problematic. It is a powerful anti-debug, as process heaps are numerous, and their chunks can be individually affected by the FLG_HEAP_* flags (such as chunk tails). Heap headers would be affected as well. For instance, checking the field ForceFlags in a heap header (offset 0x10) can be used to detect the presence of a debugger.
There are two easy ways to circumvent it:
- Create a non-debugged process, and attach the debugger once the process has been created (an easy solution is to create the process suspended, run until the entry-point is reached, patch it to an infinite loop, resume the process, attach the debugger, and restore the original entry-point).
- Force the NtGlobalFlags for the process that we want to debug, via the registry key "HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options": Create a subkey (not value) named as your process name, and under this subkey, a String value "GlobalFlags" set to nothing.
Example:
mov eax, fs:[30h]
mov eax, [eax+18h] ;process heap
mov eax, [eax+10h] ;heap flags
test eax, eax
jne @DebuggerDetected
...
(5) Vista anti-debug (no name)
Here's an anti-debug specific to Windows Vista that I found by comparing memory dumps of a program running with and without control of a debugger. I'm not sure of its realiability, but it's worth mentionning (tested on Windows Vista 32 bits, SP0, English version).
When a process is debugged, its main thread TEB, at offset 0xBFC, contains a pointer to a unicode string referencing a system dll. Moreover, the string follows this pointer (therefore, located at offset 0xC00 in the TEB). If the process is not debugged, the pointer is set to NULL and the string is not present.
Example:
call GetVersion
cmp al, 6
jne @NotVista
push offset _seh
push dword fs:[0]
mov fs:[0], esp
mov eax, fs:[18h] ; teb
add eax, 0BFCh
mov ebx, [eax] ; pointer to a unicode string
test ebx, ebx ; (ntdll.dll, gdi32.dll,...)
je @DebuggerNotFound
sub ebx, eax ; the unicode string follows the
sub ebx, 4 ; pointer
jne @DebuggerNotFound
;debugger detected if it reaches this point
;...
- Exploiting system discrepancies
(1) NtQueryInformationProcess
ntdll!NtQueryInformationProcess is a wrapper around the ZwQueryInformationProcess syscall. Its prototype is the following:
NTSYSAPI NTSTATUS NTAPI NtQueryInformationProcess(
IN HANDLE ProcessHandle,
IN PROCESS_INFORMATION_CLASS ProcessInformationClass,
OUT PVOID ProcessInformation,
IN ULONG ProcessInformationLength,
OUT PULONG ReturnLength
);
When called with ProcessInformationClass set to 7 (ProcessDebugPort constant), the system will set ProcessInformation to -1 if the process is debugged.
It is a powerful anti-debug, and there is no easy way to circumvent it. However, if the program is traced, ProcessInformation can be modified when the syscall returns.
Another solution is to use a system driver that would hook the ZwNtQueryInformationProcess syscall.
Circumventing NtQueryInformationProcess will bypass many anti-debug techniques (such as CheckRemoteDebuggerPresent or UnhandledExceptionFilter).
Example:
push 0
push 4
push offset isdebugged
push 7 ;ProcessDebugPort
push -1
call NtQueryInformationProcess
test eax, eax
jne @ExitError
cmp isdebugged, 0
jne @DebuggerDetected
...
(2) kernel32!CheckRemoteDebuggerPresent
This API takes two parameters: a process handle, and a pointer to a DWORD. If the call is successful, the DWORD value will be set to 1 if the process is being debugged.
Internally, this API calls ntdll!NtQueryInformationProcess with ProcessInformationClass set to ProcessDebugPort (7).
Example:
push offset isdebugged
push -1
call CheckRemoteDebuggerPresent
test eax, eax
jne @DebuggerDetected
...
(3) UnhandledExceptionFilter
When an exception occurs, with Windows XP SP>=2, Windows 2003, and Windows Vista, the usual way the OS processes the exception is:
- If any, pass control to the per-process Vectored Exception Handlers.
- If the exception is not processed, pass the control to the per-thread top SEH handler, pointed by FS:[0] in the thread that generated the exception. SEH are chained and called in turn if the exception is not processed by the previous in the chain.
- If the exception has not been processed by any of the previous handlers, the final SEH handler (set by the system), will call kernel32!UnhandledExceptionFilter. This function will decide what it should do depending if the process is debugged or not.
- If it is not debugged, it will call the user-defined filter function (set via kernel32!SetUnhandledExceptionFilter).
- If it debugged, the program will be terminated.
The debugger detection in UnhandledExceptionFilter is made with ntdll!NtQueryInformationProcess.
Example:
push @not_debugged
call SetUnhandledExceptionFilter
xor eax, eax
mov eax, dword [eax] ; trigger exception
;program terminated if debugged
;...
@not_debugged:
;process the exception
;continue the execution
;...
(4) NtSetInformationThread
ntdll!NtSetInformationThread is a wrapper around the ZwSetInformationThread syscall. Its prototype is the following:
NTSYSAPI NTSTATUS NTAPI NtSetInformationThread(
IN HANDLE ThreadHandle,
IN THREAD_INFORMATION_CLASS ThreadInformationClass,
IN PVOID ThreadInformation,
IN ULONG ThreadInformationLength
);
When called with ThreadInformationClass set to 0x11 (ThreadHideFromDebugger constant), the thread will be detached from the debugger.
Similarly to ZwQueryInformationProcess, circumventing this anti-debug requires either modifying ZwSetInformationThread parameters before it's called, or hooking the syscall directly with the use of a kernel driver.
Example:
push 0
push 0
push 11h ;ThreadHideFromDebugger
push -2
call NtSetInformationThread
;thread detached if debugged
;...
(5) kernel32!CloseHandle and NtClose
APIs making user of the ZwClose syscall (such as CloseHandle, indirectly) can be used to detect a debugger. When a process is debugged, calling ZwClose with an invalid handle will generate a STATUS_INVALID_HANDLE (0xC0000008) exception.
As with all anti-debugs that rely on information made directly available from the kernel (therefore involving a syscall), the only proper way to bypass the "CloseHandle" anti-debug is to either modify the syscall data from ring3, before it is called, or set up a kernel hook.
This anti-debug, though extremely powerful, does not seem to be widely used by malicious programs.
Example:
push offset @not_debugged
push dword fs:[0]
mov fs:[0], esp
push 1234h ;invalid handle
call CloseHandle
; if fall here, process is debugged
;...
@not_debugged:
;...
(6) Self-debugging
A process can detect it is being debugged by trying to debug itself, for instance by creating a new process, and calling kernel32!DebugActiveProcess(pid) on the parent process.
In turn, this API calls ntdll!DbgUiDebugActiveProcess which will call the syscall ZwDebugActiveProcess. If the process is already debugged, the syscall fails. Note that retrieving the parent process PID can be done with the toolhelp32 APIs (field th32ParentProcessID in the PROCESSENTRY32 structure.
(7) Kernel-mode timers
kernel32!QueryPerformanceCounter is an efficent anti-debug. This API calls ntdll!NtQueryPerformanceCounter which wraps the ZwQueryPerformanceCounter syscall.
Again, there is no easy way to circumvent this anti-tracing trick.
(8) User-mode timers
An API such as kernel32!GetTickCount returns the number of milliseconds ellapsed since the system started. The interesting thing is that it does not make use of kernel-related service to perform its duties. A user-mode process has this counter mapped in its address space. For 8Gb user-mode spaces, the value returned would be:
d[0x7FFE0000] * d[0x7FFE0004] / (2^24)
(9) kernel32!OutputDebugStringA
This anti-debug is quite original, I have encountered it only once, in files packed with ReCrypt v0.80. The trick consists of calling OutputDebugStringA, with a valid ASCII string. If the program is run under control of a debugger, the return value will be the address of the string passed as a parameter. In normal conditions, the return value should be 1.
Example:
xor eax, eax
push offset szHello
call OutputDebugStringA
cmp eax, 1
jne @DebuggerDetected
...
(10) Ctrl-C
When a console program is debugged, a Ctrl-C signal will throw a EXCEPTION_CTL_C exception, whereas the signal handler would be called directly is the program is not debugged.
Example:
push offset exhandler
push 1
call RtlAddVectoredExceptionHandler
push 1
push sighandler
call SetConsoleCtrlHandler
push 0
push CTRL_C_EVENT
call GenerateConsoleCtrlEvent
push 10000
call Sleep
push 0
call ExitProcess
exhandler:
;check if EXCEPTION_CTL_C, if it is,
;debugger detected, should exit process
;...
sighandler:
;continue
;...
- CPU anti-debug
(1) Rogue Int3
This is a classic anti-debug to fool weak debuggers. It consists of inserting an INT3 opcode in the middle of a valid sequence of instructions. When the INT3 is executed, if the program is not debugged, control will be given to the exception handler of the protection and execution will continue.
As INT3 instructions are used by debuggers to set software breakpoints, inserting INT3 opcodes can be used to trick the debugger into believing that it is one his breakpoints. Therefore, the control would not be given to the exception handler, and the course of the program would be modified. Debuggers should track where they set software breakpoints to avoid falling for this one.
Similarly, note that INT3 may be encoded as 0xCD, 0x03.
Example:
push offset @handler
push dword fs:[0]
mov fs:[0], esp
;...
db 0CCh
;if fall here, debugged
;...
@handler:
;continue execution
;...
(2) "Ice" Breakpoint
The so-called "Ice breakpoint" is one of Intel's undocumented instruction, opcode 0xF1. It is used to detect tracing programs.
Executing this instruction will generate a SINGLE_STEP exception. Therefore, if the program is already traced, the debugger will think it is the normal exception generated by executing the instruction with the SingleStep bit set in the Flags registers. The associated exception handler won't be executed, and execution will not continue as expected.
Bypassing this trick is easy: one can run over the instruction, instead and single-stepping on it. The exception will be generated, but since the program is not traced, the debugger should understand that it has to pass control to the exception handler.
Example:
push offset @handler
push dword fs:[0]
mov fs:[0], esp
;...
db 0F1h
;if fall here, traced
;...
@handler:
;continue execution
;...
(3) Interrupt 2Dh
Executing this interrupt if the program is not debugged will raise a breakpoint exception. If the program is debugged, and the instruction is not executed with the trace flag, no exception will be generated, and execution will carry on normally. If the program is debugged and the instruction traced, the following byte will be skipped, and execution will continue. Therefore, using INT 2Dh can be used as a powerful anti-debug and anti-tracer mechanism.
Example:
push offset @handler
push dword fs:[0]
mov fs:[0], esp
;...
db 02Dh
mov eax, 1 ;anti-tracing
;...
@handler:
;continue execution
;...
(4) Timestamp counters
High precision counters, storing the current number of CPU cycles executed since the machine started, can be queried with the RDTSC instruction. Classic anti-debugs consist of measuring time deltas at key points in the program, usually around exception handlers. If the delta is too large, that would mean the program runs under control of a debugger (processing the exception in the debugger, and giving control back to the debuggee is a lengthy task).
Example:
push offset handler
push dword ptr fs:[0]
mov fs:[0],esp
rdtsc
push eax
xor eax, eax
div eax ;trigger exception
rdtsc
sub eax, [esp] ;ticks delta
add esp, 4
pop fs:[0]
add esp, 4
cmp eax, 10000h ;threshold
jb @not_debugged
@debugged:
...
@not_debugged:
...
handler:
mov ecx, [esp+0Ch]
add dword ptr [ecx+0B8h], 2 ;skip div
xor eax, eax
ret
(5) Popf and the trap flag
The trap flag, located in the Flags register, controls the tracing of a program. If this flag is set, executing an instruction will also raise a SINGLE_STEP exception. The trap flag can be manipulated in order to thwart tracers. For instance, this sequence of instructions will set the trap flag:
pushf
mov dword [esp], 0x100
popf
If the program is being traced, this will have no real effect on the flags register, and the debugger will process the exception, believing it comes from regular tracing. The exception handler won't be executed. Circumventing this anti-tracer trick simply require to run over the pushf instruction.
(6) Stack Segment register
Here's a very original anti-tracer. I encountered it in a packer called MarCrypt. I believe it is not widely known, not to mention, used.
It consists of tracing over this sequence of instructions:
push ss
pop ss
pushf
nop
When tracing over pop ss, the next instruction will be executed but the debugger will not break on it, therefore stopping on the following instruction (NOP in this case).
Marcrypt uses this anti-debug the following way:
push ss
; junk
pop ss
pushf
; junk
pop eax
and eax, 0x100
or eax, eax
jnz @debugged
; carry on normal execution
The trick here is that, if the debugger is tracing over that sequence of instructions, popf will be excuted implicitly, and the debugger will not be able to unset the trapflag in the pushed value on the stack. The protection checks for the trap flag and terminates the program if it's found.
One simple way to circumvent this anti-tracing is to breakpoint on popf and run the program (to avoid using the TF flag).
(7) Debug registers manipulation
Debug registers (DR0 through DR7) are used to set hardware breakpoints. A protection can manipulate them to either detect that hardware breakpoints have been set (and therefore, that it is being debugged), reset them or set them to particular values used to perform code checks later. A packer such as tElock makes use of the debug registers to prevent reverse-engineers from using them.
From a user-mode perspective, debug registers cannot be set using the privileged 'mov drx, ...' instruction. Other ways exist:
- An exception can be generated, the thread context modified (it contains the CPU registers at the time the exception was thrown), and then resumed to normal execution with the new context.
- The other way is to use the NtGetContextThread and NtSetContextThread syscalls (available in kernel32 with GetThreadContext and SetThreadContext).
Most protectors use the first, "unofficial" way.
Example:
push offset handler
push dword ptr fs:[0]
mov fs:[0],esp
xor eax, eax
div eax ;generate exception
pop fs:[0]
add esp, 4
;continue execution
;...
handler:
mov ecx, [esp+0Ch] ;skip div
add dword ptr [ecx+0B8h], 2 ;skip div
mov dword ptr [ecx+04h], 0 ;clean dr0
mov dword ptr [ecx+08h], 0 ;clean dr1
mov dword ptr [ecx+0Ch], 0 ;clean dr2
mov dword ptr [ecx+10h], 0 ;clean dr3
mov dword ptr [ecx+14h], 0 ;clean dr6
mov dword ptr [ecx+18h], 0 ;clean dr7
xor eax, eax
ret
(8) Context modification
As with debug registers manipulation, the context can also be used to modify in an unconventionnal way the execution stream of a program. Debuggers can get easily confused!
Note that another syscall, NtContinue, can be used to load a new context in the current thread (for instance, this syscall is used by the exception handler manager).
- Uncategorized anti-debug
(1) TLS-callback
This anti-debug was not so well-known a few years ago. It consists to instruct the PE loader that the first entry point of the program is referenced in a Thread Local Storage entry (10th directory entry number in the PE optional header). By doing so, the program entry-point won't be executed first. The TLS entry can then perform anti-debug checks in a stealthy way.
Note that in practice, this technique is not widely used.
Though older debuggers (including OllyDbg) are not TLS-aware, counter-measures are quite easy to take, by the means of plugins of custom patcher tools.
(2) CC scanning
A common protection feature used by packers is the CC-scanning loop, aimed at detecting software breakpoints set by a debugger. If you want to avoid that kind of troubles, you may want to use either hardware breakpoints or a custom type of software breakpoint. CLI (0xFA) is a good candidate to replace the classic INT3 opcode. This instruction does have the requirements for the job: it raises a privileged instruction exception if executed by a ring3 program, and occupies only 1 byte of space.
(3) EntryPoint RVA set to 0
Some packed files have their entry point RVA set to 0, which means they will start executing 'MZ...' which corresponds to 'dec ebx / pop edx ...'.
This is not an anti-debug trick in itself, but can be annoying if you want to break on the entry-point by using a software breakpoint.
If you create a suspended process, then set an INT3 at RVA 0, you will erase part of the magic MZ value ('M'). The magic was checked when the process was created, but it will get checked again by ntdll when the process is resumed (in the hope of reaching the entry-point). In that case, an INVALID_IMAGE_FORMAT exception will be raised.
If you create your own tracing or debugging tool, you will want to use hardware breakpoint to avoid this problem.
[3] Conclusion
Knowing anti-debugging and anti-tracing techniques (un)commonly used by malware or protectors is useful knowledge for a reverse-engineer. A program will always have ways to find it is run in a debugger - the same applies for virtual or emulated environments, but since ring3 debuggers are some of the most common analysis tools used, knowing common tricks, and how to bypass them, will always prove useful.
[4] Links
MSDN
Portable Executable Tutorial, Matt Pietrek
Syscall Reference, The Metasploit Project
Undocumented Functions for MS Windows NT/2K
Intel Manuals
- Common exception codes - Microsoft Windows SDK, ntdll.h
- Status codes list (including common exception codes) - Microsoft Windows DDK, ntstatus.h
- Context Structures documentation - Microsoft Windows SDK, ntdll.h
[5] Data reference
- CONTEXT structure for IA32 processors
struct CONTEXT_IA32
{
// ContextFlags must be set to the appropriate CONTEXT_* flag
// before calling (Set|Get)ThreadContext
DWORD ContextFlags;
// CONTEXT_DEBUG_REGISTERS (not included in CONTEXT_FULL)
DWORD Dr0; // 04h
DWORD Dr1; // 08h
DWORD Dr2; // 0Ch
DWORD Dr3; // 10h
DWORD Dr6; // 14h
DWORD Dr7; // 18h
// CONTEXT_FLOATING_POINT
FLOATING_SAVE_AREA FloatSave;
// CONTEXT_SEGMENTS
DWORD SegGs; // 88h
DWORD SegFs; // 90h
DWORD SegEs; // 94h
DWORD SegDs; // 98h
// CONTEXT_INTEGER
DWORD Edi; // 9Ch
DWORD Esi; // A0h
DWORD Ebx; // A4h
DWORD Edx; // A8h
DWORD Ecx; // ACh
DWORD Eax; // B0h
// CONTEXT_CONTROL
DWORD Ebp; // B4h
DWORD Eip; // B8h
DWORD SegCs; // BCh (must be sanitized)
DWORD EFlags; // C0h
DWORD Esp; // C4h
DWORD SegSs; // C8h
// CONTEXT_EXTENDED_REGISTERS (processor-specific)
BYTE ExtendedRegisters[MAXIMUM_SUPPORTED_EXTENSION];
};
- Process Environment Block structure (from The Wine Project)
struct PEB
{
BOOLEAN InheritedAddressSpace; // 00
BOOLEAN ReadImageFileExecOptions; // 01
BOOLEAN BeingDebugged; // 02
BOOLEAN SpareBool; // 03
HANDLE Mutant; // 04
HMODULE ImageBaseAddress; // 08
PPEB_LDR_DATA LdrData; // 0c
RTL_UPROCESS_PARAMETERS *ProcessParameters; // 10
PVOID SubSystemData; // 14
HANDLE ProcessHeap; // 18
PRTL_CRITICAL_SECTION FastPebLock; // 1c
PVOID /*PPEBLOCKROUTI*/ FastPebLockRoutine; // 20
PVOID /*PPEBLOCKROUTI*/ FastPebUnlockRoutine; // 24
ULONG EnvironmentUpdateCount; // 28
PVOID KernelCallbackTable; // 2c
PVOID EventLogSection; // 30
PVOID EventLog; // 34
PVOID /*PPEB_FREE_BLO*/ FreeList; // 38
ULONG TlsExpansionCounter; // 3c
PRTL_BITMAP TlsBitmap; // 40
ULONG TlsBitmapBits[2]; // 44
PVOID ReadOnlySharedMemoryBase; // 4c
PVOID ReadOnlySharedMemoryHeap; // 50
PVOID *ReadOnlyStaticServerData; // 54
PVOID AnsiCodePageData; // 58
PVOID OemCodePageData; // 5c
PVOID UnicodeCaseTableData; // 60
ULONG NumberOfProcessors; // 64
ULONG NtGlobalFlag; // 68
BYTE Spare2[4]; // 6c
LARGE_INTEGER CriticalSectionTimeout; // 70
ULONG HeapSegmentReserve; // 78
ULONG HeapSegmentCommit; // 7c
ULONG HeapDeCommitTotalFreeTh; // 80
ULONG HeapDeCommitFreeBlockTh; // 84
ULONG NumberOfHeaps; // 88
ULONG MaximumNumberOfHeaps; // 8c
PVOID *ProcessHeaps; // 90
PVOID GdiSharedHandleTable; // 94
PVOID ProcessStarterHelper; // 98
PVOID GdiDCAttributeList; // 9c
PVOID LoaderLock; // a0
ULONG OSMajorVersion; // a4
ULONG OSMinorVersion; // a8
ULONG OSBuildNumber; // ac
ULONG OSPlatformId; // b0
ULONG ImageSubSystem; // b4
ULONG ImageSubSystemMajorVersion; // b8
ULONG ImageSubSystemMinorVersion; // bc
ULONG ImageProcessAffinityMask; // c0
ULONG GdiHandleBuffer[34]; // c4
ULONG PostProcessInitRoutine; // 14c
PRTL_BITMAP TlsExpansionBitmap; // 150
ULONG TlsExpansionBitmapBits[32]; // 154
ULONG SessionId; // 1d4
};
- Thread Environment Block structure (from The Wine Project)
struct TEB
{
NT_TIB Tib; // 000 Info block
PVOID EnvironmentPointer; // 01c
CLIENT_ID ClientId; // 020 PID,TID
PVOID ActiveRpcHandle; // 028
PVOID ThreadLocalStoragePointer; // 02c
PEB *Peb; // 030
DWORD LastErrorValue; // 034
ULONG CountOfOwnedCriticalSections; // 038
PVOID CsrClientThread; // 03c
PVOID Win32ThreadInfo; // 040
ULONG Win32ClientInfo[0x1f]; // 044
PVOID WOW32Reserved; // 0c0
ULONG CurrentLocale; // 0c4
ULONG FpSoftwareStatusRegister; // 0c8
PVOID SystemReserved1[54]; // 0cc
PVOID Spare1; // 1a4
LONG ExceptionCode; // 1a8
BYTE SpareBytes1[40]; // 1ac
PVOID SystemReserved2[10]; // 1d4
DWORD num_async_io; // 1fc
ULONG_PTR dpmi_vif; // 200
DWORD vm86_pending; // 204
DWORD pad6[309]; // 208
ULONG gdiRgn; // 6dc
ULONG gdiPen; // 6e0
ULONG gdiBrush; // 6e4
CLIENT_ID RealClientId; // 6e8
HANDLE GdiCachedProcessHandle; // 6f0
ULONG GdiClientPID; // 6f4
ULONG GdiClientTID; // 6f8
PVOID GdiThreadLocaleInfo; // 6fc
PVOID UserReserved[5]; // 700
PVOID glDispachTable[280]; // 714
ULONG glReserved1[26]; // b74
PVOID glReserved2; // bdc
PVOID glSectionInfo; // be0
PVOID glSection; // be4
PVOID glTable; // be8
PVOID glCurrentRC; // bec
PVOID glContext; // bf0
ULONG LastStatusValue; // bf4
UNICODE_STRING StaticUnicodeString; // bf8
WCHAR StaticUnicodeBuffer[261]; // c00
PVOID DeallocationStack; // e0c
PVOID TlsSlots[64]; // e10
LIST_ENTRY TlsLinks; // f10
PVOID Vdm; // f18
PVOID ReservedForNtRpc; // f1c
PVOID DbgSsReserved[2]; // f20
ULONG HardErrorDisabled; // f28
PVOID Instrumentation[16]; // f2c
PVOID WinSockData; // f6c
ULONG GdiBatchCount; // f70
ULONG Spare2; // f74
ULONG Spare3; // f78
ULONG Spare4; // f7c
PVOID ReservedForOle; // f80
ULONG WaitingOnLoaderLock; // f84
PVOID Reserved5[3]; // f88
PVOID *TlsExpansionSlots; // f94
};
- NtGlobalFlags
FLG_STOP_ON_EXCEPTION 0x00000001
FLG_SHOW_LDR_SNAPS 0x00000002
FLG_DEBUG_INITIAL_COMMAND 0x00000004
FLG_STOP_ON_HUNG_GUI 0x00000008
FLG_HEAP_ENABLE_TAIL_CHECK 0x00000010
FLG_HEAP_ENABLE_FREE_CHECK 0x00000020
FLG_HEAP_VALIDATE_PARAMETERS 0x00000040
FLG_HEAP_VALIDATE_ALL 0x00000080
FLG_POOL_ENABLE_TAIL_CHECK 0x00000100
FLG_POOL_ENABLE_FREE_CHECK 0x00000200
FLG_POOL_ENABLE_TAGGING 0x00000400
FLG_HEAP_ENABLE_TAGGING 0x00000800
FLG_USER_STACK_TRACE_DB 0x00001000
FLG_KERNEL_STACK_TRACE_DB 0x00002000
FLG_MAINTAIN_OBJECT_TYPELIST 0x00004000
FLG_HEAP_ENABLE_TAG_BY_DLL 0x00008000
FLG_IGNORE_DEBUG_PRIV 0x00010000
FLG_ENABLE_CSRDEBUG 0x00020000
FLG_ENABLE_KDEBUG_SYMBOL_LOAD 0x00040000
FLG_DISABLE_PAGE_KERNEL_STACKS 0x00080000
FLG_HEAP_ENABLE_CALL_TRACING 0x00100000
FLG_HEAP_DISABLE_COALESCING 0x00200000
FLG_VALID_BITS 0x003FFFFF
FLG_ENABLE_CLOSE_EXCEPTION 0x00400000
FLG_ENABLE_EXCEPTION_LOGGING 0x00800000
FLG_ENABLE_HANDLE_TYPE_TAGGING 0x01000000
FLG_HEAP_PAGE_ALLOCS 0x02000000
FLG_DEBUG_WINLOGON 0x04000000
FLG_ENABLE_DBGPRINT_BUFFERING 0x08000000
FLG_EARLY_CRITICAL_SECTION_EVT 0x10000000
FLG_DISABLE_DLL_VERIFICATION 0x80000000
The ISA Community
ISA helps automation professionals around the globe, with careers in engineering, R&D, technology, management, and sales. They work in a diverse array of industries, building, operating and maintaining the processes that do everything from monitor air quality to build airplanes.
Automation professionals are essential to every manufacturing process. All industrial endeavors are the result of a series of complex operations or systems. And the complex systems must be regulated using various measurement and control devices. And most often these systems and instruments employ programmable response and action devices - automation.
For automation professionals, technology is changing at a rapid pace, with more information out there than professionals have time to sort through alone. Through input from professionals throughout the world, ISA has the answer to nearly any technical question, saving the time it takes to search in multiple places for information.
By participating in the Society, automation professionals are smarter on industry issues, more valuable to their companies, and more effective at their jobs. Pure and simple, ISA is the one essential unbiased source to the world’s knowledge of automation.
Monday, October 1, 2007
The NT Local Administrator and Shared Passwords
There is a Local Administrator account on every NT machine currently deployed. This account can be renamed, but not removed. It is extremely common to find many NT machines in an enterprise sharing the same password for this Local Administrator account. This article will establish that this shared password constitutes a security vulnerability, discuss various steps to mitigate the risk arising from the shared password, and make a case for applying unique passwords to every Local Administrator account in your enterprise.
The Security Issue of Shared Local Administrator Passwords
Workstations share the same Local Administrator password for a number of reasons. First and foremost, a shared password eases the daily burden of support personnel. No desktop support staff person wants to carry around a massive list of passwords or go through the cumbersome process of querying a centralized database of passwords. Secondly, automated build processes, which are very common, result in the deployment of a shared password. This is because disk imaging software ensures that each cloned machine has the same Local Administrator password as the original, and scripted installations reapply the same Local Administrator password each time the script is executed.
So how does a shared Local Administrator password constitute a security vulnerability? Very few of us have an enterprise in which the Local Administrator account cannot be cracked. This is usually by choice, we choose to give some users Administrator access so that the users can install his/her own software packages. We choose to leave bootable floppy drives in workstations and servers. Either of these choices may result in easy access to the Local Administrator account. Since this is a "shared" password, once the account name and password are obtained for one machine, this information can be used to access all the other NT machines that share the same password for the Local Administrator account. In short, successfully hacking a single machine results in access to multiple machines - and you don't have to be a CISSP to know that this is bad news!
Administrator access + common password = major security hole.
This is the vulnerability: access to one resource allows access to a second resource. Now, how does the access of the first machine lead to access of the second machine? Pay attention here, this material will get your manager's attention in a hurry! If your enterprise is normal and uses a common password for the Local Administrator account then any employee sitting at an NT workstation could own your CEO's access in less than a week. Let's imagine?
A contractor is hired to do some menial programming for your company. The programmer is immediately provided with a freshly-installed NT workstation built to enterprise standards. Using a DOS boot disk and an NTFS tool he copies the local SAM to a floppy disk. Next, using L0phtCrack software he cracks the Local Administrator account on his workstation. Now, posing as "Local Administrator", the contractor can gain access to any workstation because all the workstations have the same Local Administrator password. What is he going to do with this low level of access? Maybe he only wants Administrator access to his own machine so he can install his favorite screensaver. Then again, maybe not.
With Administrator access, he could install a keyboard sniffer on any target workstation and wait for the target to authenticate to the domain. In a short, he will soon know the victim's passwords for NT, Novell, Lotus Notes, mainframes, mail systems, file systems, etc. This points out the importance of securing the NT workstation. The victim of the keyboard sniffing could easily be the CEO of your company! All too often the focus is on the NT servers without sufficient regard to the workstation: securing workstations is as important as securing servers .
All right, so you think the workstation isn't important enough - you only want to worry about your servers? The same vulnerability exists if you have servers with a common Local Administrator password. Suppose your contractor is hired and given access to a single NT server. He may then crack the Local Administrator account on that single server thereby gaining access to all the servers that share the common password. Although your intention may have been for the contractor to have access to the lowly test boxes, he now has access to your production SQL servers. The contractor - who you do not know from Adam - has now bypassed your attempts to restrict his access to a single server!
So, just to recap: in many NT environments, most, if not all, of the NT workstations or servers share a common Local Administrator password. This implementation flaw allows Joe Customer Support to crack the Local Administrator password and use that access to escalate his privileges all the way up to the CEO. Now, how do we fix it?
Solutions to Shared Passwords
One obvious and straightforward solution would be to eliminate shared passwords altogether; however, in some situations this is not feasible. If management won't let you eliminate the shared passwords, the following mitigation steps will at least let you minimize the scope of your exposure.
Limit the Attacker to Machines to Which They Have Physical Access
To accomplish this, deny the Local Administrator network access to each machine. With this restriction in place, the cracker cannot use one machine to access others over the network. This doesn't prevent an attacker from walking over to the manager's machine and logging in as the Local Administrator, it just forces him to physically access the machine. However, be warned, this mitigation only removes the network access from the attacker, they would still have the capacity for local logins. Essentially it limits only the speed and convenience of compromise.
You will need to point User Manager at each NT machine and remove the user right of "access this computer from the network" from the Administrators Group (this is the Local group) and add the same right to the Domain Administrators group. (You'll have to specifically add the domain group while in the User Rights menu). Be sure the Domain Administrators group is in the Local Administrator's group.
Minimize the Time Window for Potential Crackers
With enough time, even the strongest of passwords can be broken by a brute force attack. Time is indeed of the essence in this regard because the stronger the passwords, the longer it takes to perform a successful brute force attack. Consequently, the stronger the passwords you apply, the less often you will need to change them. You can ensure that the window of opportunity for crackers is minimized by is accomplished by changing the passwords faster than they can be cracked.
While we're busy minimizing the time window, we must also maximize the time it takes for a brute force attack by using "strong" passwords. Passwords should be a least 12 characters in length and include some non-alphanumeric characters. You'll definitely want to develop an automated mechanism for applying the new password on a scheduled basis. Pointing User Manager at every machine in a domain is just not an acceptable option. If you really must change passwords manually, then consider a commercial option for synchronizing the Local Administrator password across multiple machines such as User Manager Pro. WARNING - this mitigation doesn't rule out the many fine alternatives to CPU cycles - such as cameras, hardware keystroke capture devices, shoulder surfing, etc.
Minimize the Scope of Exposure From Any Single Machine
Even if we cannot eliminate the use of common passwords completely, we can at least use different passwords for different areas of the enterprise. Functional distinctions provide for some obvious logical groupings. For instance servers and workstations should absolutely not share the same Local Administrator password! Consider using a different Local Administrator password for each resource domain, or perhaps for logical geographical divisions such as campuses or buildings. At the very least, make sure your "mahogany row" executive desktops have a different Local Administrator password than the rank and file workstations!
Protect the Domain Account Used for Applying New Passwords
If we are going to have a common Local Administrator password for all NT machines, then the interval between password changes must be shorter than the time required to brute force the password. We must use a Domain account to affect the Local Administrator password change on all the targeted hosts. The danger here is that now this Domain account NT hash will be exposed to any hostile target machine. As a result, it is crucial to protect this Domain account from compromise! For the same reason that we should frequently change the Local Administrator password, we should also change the Domain account we use when applying new Local Administrator passwords.
Removing the Shared Local Administrator Password
Considering the weaknesses and dependencies of the steps outlined above, it is without doubt preferable to eliminate the shared passwords completely.
Creating Unique, Unpredictable and Strong Passwords
First, let's consider what kind of passwords we want to apply in place of the shared password. The security vulnerability we have been discussing arises from the commonality of a single password; however, the solution is not simply a matter of creating unique passwords, but unique passwords that are also unpredictable. Imagine that every machine in the enterprise had a unique local admin password, but that password was the same as the hostname of the machine! What's the problem with that? Predictability. An attacker must not be able to use the password for machine A to access machine B. Having passwords that are predictable is as troublesome as having passwords that are similar. Clearly, the more unpredictable each password is, the stronger our security posture becomes. Random passwords would be truly unpredictable and therefore are an excellent choice, but we must also consider the strength of a password.
It must be kept in mind that unpredictable doesn't always mean strong. A password such as "37a" might indeed be "random", and thus unpredictable, but is weak and therefore ease to brute force. In order to be truly effective, passwords must combine strength and unpredictability. The idea is to have both 0% predictability and serious strength in order to resist both brute force and logical attacks. Strength is achieved by utilizing a large character set and a sufficiently long password.
Recovery of Passwords
Second, let's consider the administrative issues surrounding the recovery of those passwords. By recovery we mean the ability to determine the Local Administrator password for a particular NT machine in an environment in which the Local Administrator password is not shared. Access to the Local Administrator account on servers or workstations is a requirement for most enterprises. This means that after we apply unpredictable, unique and strong passwords to every NT machine we will need a recovery mechanism.
Why would we need to recover a Local Administrator password? Suppose the "Senior Executive of Irrelevant Paperwork" needs to print that huge Power Point presentation just minutes before the "big" meeting, but her NIC card decides to die at this most inopportune moment. Your support staff can save the day in minutes with the Local Administrator account, or they can lecture her about the value of storing important documentation on the file server instead of her local machine and start one of several time consuming processes to rectify the situation.
It might be a server rather than a workstation - perhaps it is the SQL server in Accounting that requires a new NIC card, or some other high demand machine like the employee internet access proxy server. Whatever the situation, there are inevitably times at which password recovery will be required.
The recovery process must be simple for reasons of expedience. When support staff need to recover the Local Administrator password for a particular machine, they don't want to be given a paper form requiring multiple managerial signatures! You'll need a central database with careful access controls applied appropriately so that only your support staff can access it.
Alternatively, to avoid the central database you could utilize an algorithmic generation mechanism. This simply means that if you provide the same input to the generation algorithm, it will produce the same output. For instance, if you had a secret knowledge key such as "TrailBlazers" and the hostname of an NT machine, then you could run both character strings through the generation algorithm to create a unique password. Hopefully, you will choose a generation algorithm that provides unique, unpredictable and strong passwords. The uniqueness in this scenario comes from the use of the hostname, which must be unique in any NT domain. The recovery process uses the same technique to generate the password whenever you need it. This solution avoids the storage issues surrounding a central database, but introduces the need to manage the secret knowledge key.
In the event that recoverability is not necessary for your organization, you might consider simply applying random passwords to the Local Administrator accounts wherever possible. A good site for random password generators can be found at CNET's WinFiles.com.
Conclusion
A Local Administrator account password shared by many NT machines constitutes a security vulnerability and must be mitigated. If you cannot remove the shared password, then it is vital to minimize security risks by implementing frequent password changes and restricting network access for the Local Administrator account.
If it is possible to operate without a shared Local Administrator password, do so with the following precautions. If support staff does not require access to the Local Administrator account, then consider applying random passwords to this account on each machine. If necessary, make sure that steps are provided to allow for recoverability. I strongly encourage you to create your own solution (see example above) or pursue a commercial package to eliminate this vulnerability. Here's one of many "practical" solutions you can implement yourself:
Divide your enterprise machines into logical groups (Servers, Workstations, Mahogany Row, Sales, Bean Counters, etc..) Use a random password generator to generate passwords for each target machine. Store each hostname/password pair in a central database Secure the database such that support personnel responsible for each logical group can only access the stored passwords for machines in their logical group. Use PERL and the NetAdmin module to script the application of these passwords to each logical group.
Think carefully through the issues of passwords and recovery. Without unpredictable uniqueness you've gained nothing. Without strength you haven't improved your security position. Overlook recoverability and you might be unemployed. Charge blindly ahead without a plan for storage considerations, manual recovery procedures, generation algorithms, and a dissemination process to support staff - and you are definitely asking for a headache.
