IIS 6 semicolon vulnerability

Độ này tôi đang bận tối mắt tối mũi vì đang triển khai và hiệu chỉnh hệ thống WAF (imperva) ở một khách hàng thuộc loại hàng khủng trong Hồ Chí Minh, cho nên còn nợ quý bạn phần II của chuyến đi Huế vừa qua, mấy bữa nghỉ lễ rảnh rỗi tôi sẽ phóng bút tiếp các bạn tiếp nha.

Trở lại vấn đề chính, khách hàng này thuộc loại thân thiết như anh em với tôi, vì thế bao nhiêu vấn đề bảo mật hệ thống từ Web Application, Network, Policy ... Họ đều trao đổi và có vài câu hỏi nhờ tôi giải đáp, trợ sức để giúp họ thắt chặt an ninh lại. Tôi có một quy tắc là tuyệt đối không Public thông tin khách hàng, bạn bè của mình khi chưa hỏi ý họ, nên chỉ nói chung chung, mong quý bạn không giận vì tôi không nêu rõ danh tính nhé

Trong quá trình hiệu chỉnh WAF, tôi phát hiện ra rằng tại hệ thống của bạn tôi, còn rất nhiều lỗ hổng mà các "hacker" ở VN hiện nay cho là "xưa cũ" rồi . Thử một chút thống kê, tôi phân loại vài lỗ hổng dựa trên Top 10 của OWASP năm nay, như sau : 

 
- SQL Injection chiếm 50%

- XSS chiếm 20% 

- Unrestricted File Upload 20%

- Security Misconfiguration chiếm 10%

Điều đáng nói ở đây là bạn tôi bị giới hạn khả năng chỉnh sửa code các website nằm trong vùng WAF bảo vệ, khách hàng tự code, mỗi người code 1 kiểu, sơ qua cho thấy các lập trình viên Website ở VN nhận thức và hiểu biết về vấn đề bảo mật trong khi lập trình còn rất hạn chế.

Bảo mật phải đồng hành cùng với hiệu suất hoạt động của ứng dụng,đối với Web Application, việc cẩu thả trong khi lập trình, không kiểm soát kỹ các giá trị đầu vào, các hàm, các biến, sẽ biến mình trở thành miếng mồi cực kỳ ngon của các Hax0r. Tôi nhớ có lần nghe anh Nam Bluemoon chia sẻ kinh nghiệm, khi còn làm việc ở nước ngoài, tại vị trí lập trình ứng dụng anh đã được tiếp xúc và học hỏi quy trình bảo mật rất nghiêm khắc của công ty nước ngoài, quý bạn sẽ phải tuân thủ tuyệt đối những điều sau :

• Ứng dụng viết ra phải qua tay rất nhiều nhóm, trước tiên phải chính các coder viết lên nó kiểm tra thật kỹ, sau đó qua tới nhóm tester, nhóm kiểm định chất lượng của ứng dụng viết ra. Chỉ cần không thoả điều kiện ở một trong các nhóm kể trên, coi như bỏ, làm lại từ đầu .

• Họ có một cơ sở dữ liệu các biến, hàm có khả năng bị lợi dụng bởi hax0r, nếu trong sản phẩm xuất hiện các hàm nguy hiểm ấy, nhóm kiểm định sẽ yêu cầu lập trình viên phải nghĩ cách hoặc chọn hàm khác để viết thay cho các hàm trên, nếu không thì loại ...

Còn vài điều nữa tôi không nhớ rõ, để hôm nào hỏi lại anh Nam sau .

Trở lại vấn đề chính, tôi và các chuyên gia bảo mật thuộc ADC Center của Imperva đang brainstorm vì lỗ hổng IIS 6 Semicolon, vấn đề là Imperva WAF hoàn toàn có khả năng phát hiện và phòng chống lỗ hổng này, đúng theo quy trình tấn công của nó .

Nhưng ... Đấy, ở đời lắm cái nhưng, bạn tôi đưa ra trường hợp muốn chống lại những WebShell đã bị upload qua lỗ hổng semi-colon còn tồn tại trong hệ thống, điều đó có nghĩa là WAF phải phát hiện và block được các URL theo cấu trúc sau : 

part=".asp;" , rgxp="\.asp;[A-Za-z0-9]*\.extension"

Lúc ban đầu tôi thử viết một basic rule theo quy tắc của Imperva :

part=".asp;.jpg"

Kết quả không thành công, tôi bắt đầu viết suy luận của mình lên tờ paper note, tôi có thói quen khi research thường hay có một cây bút chì và tờ giấy ghi chú, để tiện quẹt quẹt vẽ vẽ suy nghĩ của mình, đôi lúc xả stress bằng cách vẽ bậy nữa ( lol ) .

Imperva WAF có một chức năng mặc định được turn on là "Default Ignored Static File List"

Mặc định hãy Extensions nào nằm trong danh sách này, Imperva sẽ bỏ qua không kiểm tra.

Đây là một điểm cần lưu ý đối với những ai khi triển khai, vận hành hệ thống an ninh mà cứ để mặc định, không chịu xem lại cấu hình của mình .

Ví như hax0r attack và upload Webshell dạng : .php.rar ; .php.jpg *inject jpg comment* hoặc chính xác nhất là semicolon thì dù cho bạn viết rule kỹ tới cỡ nào đi chăng nữa thì nó cũng sẽ qua mặt được hết !

Tôi phát hiện ra điều này khi viết hẳn một rule đặt static filename luôn, chỉ rõ tên file shell luôn, hãy : filename;.jp thì block, màfilename;.jpg là qua !

Sau đó ADC Center gửi cho tôi một email, hướng dẫn và chỉ rõ rule theo yêu cầu bạn tôi đưa ra, tuy nhiên hiện giờ vẫn không phù hợp . Tất nhiên lão bạn tôi cũng hiểu đây là lỗi ở IIS 6 bắt buộc phải patch lên IIS 7, và Imperva thoả yêu cầu phòng chống lỗ hổng này khi nó bắt đầu diễn ra, nghĩa là nó có thể phát hiện và drop khi hax0r upload shell lên, bằng cách nhận biết qua Parameter, để tôi show cho quý bạn coi thử cái rule đó hen, nó có hẳn một Filter search IIS Code Upload luôn :

Nhưng hôm nay tôi mạn phép xin được giải thích lại một lần chi tiết cách tìm kiếm, kiểm tra cũng như tại sao lại xuất hiện lỗ hổng này trong IIS, mục đích cũng để ôn lại cho khoá học Infosec Attack Research sắp khai giảng trong đầu tháng 10 (still available slots - contact me ! ) ha ha quảng cáo tí quý bạn đừng giận hen.

Trước tiên, tôi rất vui và đánh giá cao cho ai cho ai đặt câu hỏi "Tại sao IIS 6 lại bị lỗ hổng này ?" hơn là "Khai thác bằng cách nào ?"

Tại sao lỗ hổng semicolon lại qua mặt được IIS 6 ? 

Trong trường hợp "shell.asp;.jpg", Web Application sẽ xem nó như file hình ảnh JPEG, sau khi vượt qua cơ chế kiểm soát extension, IIS lại xem nó như một file ASP và forward tới "asp.dll" . Lỗ hổng này không hoạt động đối với ASP.NET, không hề có dạng "shell.aspx;.jpg", quý bạn có thể thử và sẽ nhận được error "Page not found" quen thuộc.

Ngoài việc sử dụng semi-colon, ta còn có thể dùng dấu ":" để tạo ra một empty file với bất kỳ extension nào bạn muốn, bằng cách đó hax0r có thể upload lên máy chủ của chúng ta một file dạng "test.asp:.jpg", một file rỗng sẽ được tạo trên máy chủ nằm trên NTFS partition. Đây chỉ là ví dụ tôi kể thêm, liên quan đến NTFS Alternate Data Streams và hoàn toàn khác với lỗ hổng semi-colon nghen, tại tôi thấy nhiều bạn bảo ";" hay ":" cũng đều được hic hic, sợ lắm các "hacker",

Để bảo vệ bản thân trước lỗ hổng này, các lập trình viên cần chú ý hai điều sau : 

1. Không bao cho phép thực thi chính xác filename người dùng upload lên máy chủ

2. Chỉ chấp nhận alpha-numerical strings xem như là tên filename và extension luôn

Giải pháp tối ưu nhất là cập nhật IIS 6 lên phiên bản IIS 7.5 để đảm bảo an toàn cho hệ thống, để tôi tìm thử xem có mấy bản patch cho IIS 6 không, nếu có sẽ cập nhật vào đây cho quý bạn có nhu cầu .

Bài cũng đã dài, tôi viết xong bài này là 7g:15 sáng, phải ngủ chút chứ không chịu không nổi, trưa lại lên chỗ bạn tôi để theo dõi và tinh chỉnh tiếp, hic hic mọi người được đi chơi, có mỗi mình phải ở lại để đảm bảo an toàn, chứ không lỡ nó hú hay false positive xảy ra nữa thì khổ .

DucNguyen

Tactical Security Researcher
Contact : ducnguyenrs\x40\gmail\2e\com

Blog : langbatgiangho.com