- .:: HVAOnline ::.

----------------------------------------------------------------------------------
Phần 1: /hvaonline/posts/list/38687.html
Phần 2: /hvaonline/posts/list/38690.html
----------------------------------------------------------------------------------

PHẦN 3. NGĂN CHẶN MỘT SỐ HÌNH THỨC TẤN CÔNG THƯỜNG GẶP VỚI MODSECURITY

Chương này sẽ trình bày một số hình thức tấn công phổ biến nhất vào web application và web server. Tiếp theo là ngăn chặn các hình thức tấn công đó với ModSecurity. Để thực hiện ngăn chặn được, đầu tiên chúng ta phải hiểu rõ đặc điểm của các hình thức tấn công này.

Web application có thể bị tấn công từ nhiều góc độ khác nhau, vì vậy việc ngăn chặn các cuộc tấn công dưới phương diện web application không hề dễ dàng.

Đối với web server, việc phục vụ các request cũng rất dễ bị khai thác, ngay trong cả web server Apache – một trình web server được đánh giá là bảo mật. Ban đầu, web server chỉ phục vụ yêu cầu các trang HTML. Theo thời gian, các ngôn ngữ khác ra đời như JavaScript, PHP… đi kèm theo các nguy cơ bảo mật. Chẳng hạn như mod_php được sử dụng để chạy các script PHP, có thể bị lỗ hổng bảo mật ở chính ngôn ngữ PHP.

3.1. HTTP FINGERPRINTING

Chỉ có những hacker nghiệp dư mới thực hiện tấn công một server mà không biết server đó có hoạt động hay không. Phức tạp hơn, hacker sẽ thu thập càng nhiều thông tin càng tốt về kiến trúc mạng và phần mềm đang chạy trên server. Cụ thể với web server, phương thức tìm kiếm thông tin này gọi là HTTP Fingerprinting (dấu vân tay HTTP).

HTTP Fingerprinting hoạt động bằng cách kiểm tra các đặc tính riêng của web server bằng các response khi được thăm dò và lấy “dấu vân tay” của server từ những thông tin thu thập được. Sau đó dấu vân tay này được so sánh với một cơ sở dữ liệu về “dấu vân tay” cho các web server được biết đến để xác định tên web server và phiên bản mà nó đang chạy.

Trong bài viết này sử dụng công cụ HTTP Fingerprinting là httprecon. Phiên bản đầu tiên của phần mềm này được phát hành vào năm 2007. Chạy trên hệ điều hành Windows.

Thực hiện thăm dò một server đang chạy Apache 2.2.3 với httprecon, ta thấy kết quả trả về chính xác.

Hình 3.1 Phần mềm httprecon

3.1.1. Cách thức HTTP Fingerprinting hoạt động

Có nhiều cách để các phần mềm HTTP Fingerprinting có thể phát hiện phiên bản của web server đang chạy trên hệ thống. Chúng ta sẽ xem xét một số phương pháp phổ biến sau:

3.1.1.1. Server banner

Server banner là một chuỗi được trả về bởi server trong response header (ví dụ: Apache/1.3.3(Unix) (Red Hat/ Linux)) mang thông tin của phần mềm chạy web server cũng như hệ điều hành của web server đó.

Giả sử một hacker muốn tấn công web server của chúng ta, bước đầu tiên của hacker sẽ là gì? Câu trả lời là tìm hiểu hệ điều hành và phần mềm web server đang chạy trên hệ điều hành đó. Vì vậy, ta có thể tạo ra các thông tin “giả” về web server để cho hacker tự do thăm dò..

Để thay đổi được server banner là điều rất khó. Apache không cung cấp lệnh để thay đổi thông tin về về server banner (trừ khi chúng ta thay đổi mã nguồn và biên dịch Apache ngay từ đầu).

Đề thay đổi, chúng ta phải sử dụng ModSecurity. Khi sử dụng ModSecurity, chúng ta có thể thay đổi hoàn toàn thông tin về máy chủ. Ví dụ như Apache 2.2 thành Microsoft-IIS/5.0. Tuy nhiên, để thú vị hơn thì chúng ta nên thay đổi nó thành thông tin của một máy chủ phiên bản cũ có nhiều lỗi bảo mật.

Đầu tiên, chúng ta cần phải “nói” cho Apache để Apache gởi thông tin đầy đủ phiên bản của máy chủ trong response header. Sau đó ModSecurity có thể nhận ra và thay đổi thiết lập.

Đơn giản là trong httpd.conf, thêm vào dòng.

Code:

# Goi full server signature de ModSecurity co the thay doi no 

 ServerTokens Full

Sau đó, thêm dòng sau vào file cấu hình của ModSecurity (ở đây đặt là modsecurity.conf). Khởi động lại apache khi hoàn thành.

Code:

# Thay doi web server signature goi boi Apache 

 SecServerSignature "Apache 1.3.24"

Apache 1.3.24 là phiên bản củ của Apache với rất nhiều lỗ hổng bảo mật. Thấy vậy các hacker rất thích thú và bỏ rất nhiều thời gian và công sức để khai thác các lỗ hổng bảo mật của phiên bản này.. Hy vọng sẽ làm nản chí các đối tượng muốn khai thác hệ thống của chúng ta (nhưng đối với các hacker kinh nghiệm, sẽ có các biện pháp để phát hiện phiên bản thật của máy chủ web).
Bây giờ, chúng ta kiểm tra kết quả của các bước trước đã cấu hình.

Hình 3.2 Kết quả thay đổi server banner với ModSecurity

3.1.1.2. Các response của giao thức HTTP

Để lấy được thông tin web server, có thể sử dụng các request phi tiêu chuẩn (non-standard) hoặc request bất thường để web server gởi về các response kèm theo thông tin về server cần thu thập.
Các request có thể sử dụng để lấy thông tin từ web server:

Request HTTP DELETE không hợp lệ

Như phần 2.3.2 của chương 2 đã trình bày, HTTP DELETE dùng để xoá dữ liệu từ web server. Lệnh này chủ yếu được thực hiện với người dùng đã được chứng thực. Vì vậy đối với người dùng chưa được chứng thực, thông báo lỗi sẽ được trả về. Trong thông báo lỗi có thể có các thông tin về web server.

Ví dụ ở đây sử dụng Netcat để gởi request DELETE đến web server Apache:

Code:

c:\nc>nc ptnd.com 80

 DELETE /HTTP/1.0

 ............

 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

 <html><head>

 <title>405 Method Not Allowed</title>

 </head><body>

 <h1>Method Not Allowed</h1>

 <p>The requested method GET is not allowed for the URL /HTTP/1.0.</p>

 <p>Additionally, a 404 Not Found

 error was encountered while trying to use an ErrorDocument to handle the reques.</p>

 <hr>

 <address>Apache 1.3.24 PHP/5.1.6 mod_python/3.2.8 Python/2.4.3 mod_perl/2.0.4 Prl/v5.8.8 Server at ptnd.com Port 80</address>

 </body></html>

Kết quả trả về lỗi 405 Method Not Allowed. Lỗi trên cho thấy phương thức request DELETE không cho phép request các URL /index.html. Thông báo lỗi này kèm theo thông tin về máy chủ Apache 1.3.24 PHP/5.1.6 mod_python/3.2.8 Python/2.4.3 mod_perl/2.0.4 Prl/v5.8.8.

Request sai phiên bản HTTP

Thực hiện ví dụ tương tự như phần trên bằng cách gởi request GET đế web server với thông số phiên bản của giao thức HTTP không đúng.

Dưới đây là kết quả thực hiện GET với phiên bản HTTP là 5.0
Code:

c:\nc>nc ptnd.com 80

 GET /HTTP/5.0

 ...........

 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

 <html><head>

 <title>404 Not Found</title>

 </head><body>

 <h1>Not Found</h1>

 <p>The requested URL /HTTP/5.0 was not found on this server.</p>

 <p>Additionally, a 404 Not Found

 error was encountered while trying to use an ErrorDocument to handle the request

 .</p>

 <hr>

 <address>Apache 1.3.24 PHP/5.1.6 mod_python/3.2.8 Python/2.4.3 mod_perl/2.0.4 Perl/v5.8.8 Server at ptnd.com Port 80</address>

 </body></html>

Request sai giao thức

Ví dụ dưới đây thực hiện GET với tên giao thức không phải là HTTP mà là VIETHANIT. Kết quả báo lỗi tương tự.

Code:

c:\nc>nc ptnd.com 80

 GET /VIETHANIT/1.0

 ..........

 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">

 <html><head>

 <title>404 Not Found</title>

 </head><body>

 <h1>Not Found</h1>

 <p>The requested URL /VIETHANIT/1.0 was not found on this server.</p>

 <p>Additionally, a 404 Not Found

 error was encountered while trying to use an ErrorDocument to handle the request

 .</p>

 <hr>

 <address>Apache 1.3.24 PHP/5.1.6 mod_python/3.2.8 Python/2.4.3 mod_perl/2.0.4 Perl/v5.8.8 Server at ptnd.com Port 80</address>

 </body></html>

Giới thiệu về ETag HTTP header

Chúng ta có thể quen thuộc với thông số HTTP Last-Modified trong response header. Thông số này cho phép trình duyệt xác định có tải về nội dung web hay sử dụng bộ nhớ cache để hiển thị cho người dùng (chẳng hạn như các file hình ảnh..) để tránh tải về các nội dung không thay đổi kể từ lần truy cập cuối. Các Etag header (viết tắt của "Entity Tag") hoạt động theo cách tương tự, nhưng sử dụng thêm thông tin về tập tin là số inode (inode là số đại điện cho mỗi tập tin trong hệ thống tập tin Unix, số này chỉ thay đổi khi tập tin mà nó đại điện thay đổi thuộc tính như người sở hữu, kiểu tệp, quyền truy cập…).

Etag header cũng được các phần mềm Fingerprinting dùng để xác định cấu hình web server. Ngoài ra, nếu sử dụng Etags có thể làm giảm hiệu suất hoạt động của web server.

Ví dụ: Nếu chúng ta đang chạy nhiều web server để cân bằng tải và cấu hình Apache cho phép response Etag (mặc định Apache cho phép), các web server khác nhau sẽ trả về giá trị ETag khác nhau ngay cả khi thuộc tính của tập tin không thay đổi (do số inode trên các server khác nhau sẽ khác nhau). Điều này sẽ làm cho trình duyệt tải về các nội dung không cần thiết ngay cả khi thuộc tính của tập tin không thay đổi từ lần truy cập trước.

Vô hiệu hoá ETag trong response của Apache sẽ có lợi cho hiệu năng của web server và làm cho HTTP Fingerprinting khó khăn hơn trong việc thăm dò. Để vô hiệu hoá ETag, trong file cấu hình httpd.conf thực hiện thêm vào dòng.

Code:

Header unset ETag

Lưu ý: Nếu web server đang chạy WebDAV với mod_dav_fs, chúng ta không nên vô hiệu hoá ETag vì mod_dav_fs sử dụng nó để xác định các tập tin đã thay đổi.

3.1.2. Sử dụng ModSecurity để ngăn chặn HTTP Fingerprinting

Chúng ta sẽ cung cấp đầy đủ các thông tin cho hacker tìm hiểu, nhưng không phải là thông tin chính xác. ModSecurity cho phép chúng ta tuỳ chỉnh và đánh lừa các công cụ HTTP Fingerprinting. Ví dụ cụ thể:

- Chỉ cho phép các phương thức GET, HEAD, và POST
- Chặn tất cả các request với các giao thức ngoại trừ giao thức HTTP 1.0 và 1.1
- Chặn các request không chứa Host header
- Chặn tất cả các request không chứa Accept header
- Đặt chữ ký là Microsoft-IIS/6.0
- Thêm X-Powered-By: ASP.NET 2.0 header
- Gỡ bỏ Etag header

Dưới đây là các rule để thực hiện

Code:

# Thay doi chu ky server

 SecServerSignature "Microsoft-IIS/6.0"

 # Tu choi cac request khong chua host header

 SecRule &REQUEST_HEADERS:Host "@eq 0" "phase:1,deny"

 # Tu choi cac request khong chua request header

 SecRule &REQUEST_HEADERS:Accept "@eq 0" "phase:1,deny"

 # Chi cho phep GET HEAD va POST

 SecRule REQUEST_METHOD !^(get|head|post)$ "phase:1,t:lowerCase,deny"

 # Chi cho phep HTTP phien ban 1.0 va 1.1

 SecRule REQUEST_PROTOCOL !^http/1\.(0|1)$ "phase:1,t:lowercase,deny"

 # Them X-Powered-By header

 Header set X-Powered-By "ASP.NET 2.0"

 # Go bo ETag header

 Header unset ETag

Và đây là kết quả của phần mèm Acunetix khi thực hiện scan:

Hình 3.3 Kết quả dùng Acunetix khi scan

3.2. NGĂN CHẶN CÁC REQUEST TỪ PROXY SERVER

Các request từ proxy server thường không tốt đối với một số website. Ví dụ nếu chúng ta đang chạy một diễn đàn thảo luận VBB hoặc PHPBB… Hacker thường sử dụng các proxy làm trung gian để ẩn dấu vết của mình và thực hiện các hành động như spam các bài viết lên diễn đàn, thực hiện các cuộc tấn công từ chối dịch vụ Ddos.. Do đó, chúng ta có thể chặn những người truy cập từ các proxy này.

Đặc điểm nhận dạng của các proxy khi request vào web server là có sự hiện diện của chuỗi X-Forwarded-For trong request header, chúng ta có thể dựa vào đặc điểm này để viết rule ngăn chặn.
Rule được viết như sau:

Code:

SecRule &REQUEST_HEADERS:X-Forwarded-For "@gt 0" deny

Lưu ý: Phải xem xét kỹ lưỡng trước khi quyết định chặn các proxy truy cập vào server. Bởi không phải tất cả website đều không nên cho proxy server truy cập vào.

3.3. CROSS-SITE SCRIPTING
3.3.1. Định nghĩa

Cross-Site Scripting hay còn được gọi tắt là XSS (thay vì gọi tắt là CSS để tránh nhầm lẫn với CSS-Cascading Style Sheet của HTML) là một kĩ thuật tấn công bằng cách chèn vào các website động (ASP, PHP, CGI, JSP ...) những thẻ HTML hay những đoạn mã script nguy hiểm có thể gây nguy hại cho những người sử dụng khác. Trong đó, những đoạn mã nguy hiểm được chèn vào hầu hết được viết bằng các Client-Site Script như JavaScript, JScript, DHTML và cũng có thể là cả các thẻ HTML.
Kĩ thuật tấn công XSS đã nhanh chóng trở thành một trong những lỗi phổ biến nhất của Web Applications và mối đe doạ của chúng đối với người sử dụng ngày càng lớn.

4.3.2. Hoạt động của XSS

Về cơ bản XSS cũng như SQL Injection hay Source Injection (sẽ được giới thiệu ở phần sau), nó cũng là các request được gửi từ các máy client tới server nhằm chèn vào đó các thông tin vượt quá tầm kiểm soát của server. Nó có thể là một request được gửi từ các form dữ liệu hoặc cũng có nằm trong request URI, ví dụ:

Code:

http://www.example.com/search.cgi?query=<script>alert('XSS was found !');</script>

Nếu truy cập vào địa chỉ trên, rất có thể trình duyệt sẽ hiện lên một thông báo XSS was found !. Các đoạn mã trong thẻ <script> không hề bị giới hạn bởi chúng hoàn toàn có thể thay thế bằng một file nguồn trên một server khác thông qua thuộc tính src của thẻ <script>. Cũng chính vì lẽ đó mà chúng ta chưa thể lường hết được độ nguy hiểm của các lỗi XSS.

Nhưng nếu như các kĩ thuật tấn công khác có thể làm thay đổi được dữ liệu nguồn của web server (mã nguồn, cấu trúc, cơ sở dữ liệu) thì XSS chỉ gây tổn hại đối với website ở phía client mà nạn nhân trực tiếp là những người khách duyệt site đó. Tất nhiên đôi khi các hacker cũng sử dụng kĩ thuật này đề chiếm quyền điều khiển các website nhưng đó vẫn chỉ tấn công vào bề mặt của website. Thật vậy, XSS là những Client-Side Script, những đoạn mã này sẽ chỉ chạy bởi trình duyệt phía client do đó XSS không làm ảnh hưởng đến hệ thống website nằm trên server.

Mục tiêu tấn công của XSS không ai khác chính là những người sử dụng khác của website, khi họ vô tình vào các trang có chứa các đoạn mã nguy hiểm do các hacker để lại, họ có thể bị chuyển tới các website khác, đặt lại homepage, hay nặng hơn là mất mật khẩu, mất cookie thậm chí máy tính người truy cập có thể sẽ bị cài các loại virus, backdoor, worm ..

3.3.3. Ngăn chặn tấn công XSS

Đề ngăn chặn tấn công XSS, chúng ta phải đảm bảo tất cả dữ liệu mà người dùng gởi lên đều được cản lọc. Cụ thể, chúng ta có thể thay thế hoặc loại bỏ các ký tự, các chuỗi thường được dùng trong tấn công XSS như đấu ngoặc góc (< và > smilie

, script...
Dưới đây là danh sách các ký tự nên mã hoá khi được client cung cấp để lưu vào cơ sở dữ liệu.

Bảng 3.1 Các ký tự nên mã hoá để ngăn chặn tấn công XSS

Nếu chúng ta muốn ngăn chặn tấn công với ModSecurity, dưới đây là các đoạn script XSS phổ biến và các biểu thức chính quy để ngăn chặn người dùng request chứa các chuỗi này.

Bảng 3.2 Các script XSS và biểu thức chính quy

Dưới đây là ví dụ về một rule dùng để chặn XSS đã được trình bày ở phần 2.4.5

Code:

SecRule ARGS "<script" "deny,t:lowercase"

3.4. TẤN CÔNG THỰC THI CÁC LỆNH SHELL

Như chúng ta đã biết, chấp nhận dữ liệu đầu vào từ client mà không cản lọc có thể gây ra nguy hiểm cho ứng dụng web. Cụ thể của việc này là người dùng gởi các request trái phép đến server để hiển thị hoặc thực thi một tập tin nào đó mà người dùng không có quyền.

Hacker thường kết hợp nhiều yếu tố để đạt được hiệu quả tối đa. Các ứng dụng web rất ít sử dụng các lệnh shell bởi nó thực hiện gọi exec() đến hệ thống. Tuy nhiên, chúng ta hãy xem xét quy trình sau đây:

Quy trình trên là sự kết hợp giữa khai thác lỗi SQL injection để tạo ra các file PHP với việc thực thi các lệnh shell. Nếu việc cản lọc dữ liệu đầu vào của web server không thành công, hacker sẽ thực thi scripts thucthi.php và toàn bộ dữ liệu trên thư mục gốc của web server sẽ bị xoá.

Điều này cho thấy, cản lọc thực thi các lệnh shell là công việc hết sức cần thiết đối với người làm bảo mật web server.
Dưới đây là một số lệnh, tên chương trình và đường dẫn thông thường của hệ thống Unix có thể chặn để tránh tấn công thực thi lệnh shell:

- rm
- ls
- kill
- mail
- sendmail
- cat
- echo
- /bin/
- /etc/
- /tmp/

Để chặn các request với đối số là các chuỗi trên, ta có rule sau:

Code:

SecRule ARGS “rm|ls|kill(send)?mail|cat|echo|/bin/|/etc/|/tmp/)” “deny”

3.5. TẤN CÔNG NULL BYTE

Kiểu tấn công null byte (byte rỗng) thực sự bắt nguồn từ ngôn ngữ lập trình C (và các ngôn ngữ liên quan), sử dụng một byte rỗng (0x00) để biểu thị kết thúc một chuỗi. Ví dụ về cách lưu trữ chuỗi viethanit trong bộ nhớ của ngôn ngữ C:

Với các ngôn ngữ lập trình khác như Java, các chuỗi được lưu trữ trong mảng, và giá trị tổng chiều dài của chuỗi (total length) được lưu trữ ở một vị trí riêng biệt. Vì vậy hoàn toàn có thể lưu trữ được các byte rỗng ở giữa chuỗi.
Lợi dụng sự khác biệt trong việc lưu trữ và xử lý chuỗi giữa các ngôn ngữ lập trình, hacker có thể thực hiện tấn công khai thác lỗi null byte bằng cách đánh lừa các phần của hệ thống để phần này nghĩ rằng chuỗi đã kết thúc (vì gặp byte rỗng) và phần kia của hệ thống lại nghĩ rằng chuỗi được nhập đầy đủ.

Xét trang JSP đơn giản được viết để hiển thị nội dung tập tin văn bản cho client truy cập bằng cách sử dụng tên tập tin làm tham số:

Code:

><%

   String filename = request.getParameter("file");

   if (filename.endsWith(".txt")) {

     // Include text file in output page

   }

 %>

Với ví dụ trên, website sẽ đảm bảo tên tập tin yêu cầu hiển thị cho người truy cập phải có phần mở rộng là .txt . Tuy nhiên, nếu hacker sử dụng hình thức tấn công là null byte, hacker sẽ nhập vào đối số tên tập tin là /etc/passwd%00.txt .

Mặt khác, Java lại có khả năng chứa các byte rỗng trong chuỗi, vì vậy yêu cập hiển thị nội dung tập tin trên là hợp lệ và sẽ vượt qua được hàm kiểm tra filename.endsWith(".txt"). Khi yêu cầu hiển thị tập tin được chuyển vào cho hệ thống, chức năng mở tập tin sẽ hoạt động. Một vấn đề phát sinh nếu chức năng đọc tên tập tin của hệ thống dừng khi gặp byte rỗng, hệ điều hành sẽ không mở tập tin /etc/passwd%00.txt mà thay vào đó sẽ mở tập tin /etc/passwd (tập tin hệ thống chứa thông tin về người dùng của các hệ thống Unix). Và nội dung của tập tin này sẽ được hiển thị trên trình duyệt của hacker.

ModSecurity có hai chức năng chuyển đổi đề đối phó với các byte rỗng được gởi lên từ người truy cập đó là replaceNulls và removeNulls. Với replaceNulls, khi thực thi sẽ thay thế byte rỗng bằng khoảng trắng, trong khi đó removeNulls lại thực hiện loại bỏ hoàn toàn byte rỗng. Byte rỗng rất hiếm khi cần thiết cho dữ liệu nhập vào của website, vì vậy có thể thiết lập chuyển đổi byte rỗng trong SecDefaultAction:

Code:

SecDefaultAction "phase:2,deny,log,status:403,t:removeNulls"

Rule trên từ chối các request boby có chứa byte rỗng. Nếu chúng ta muốn cho phép các request này, thực hiện dùng chức năng chuyển đổi để gỡ bỏ hoặc thay thế byte rỗng với rule:

Code:

SecRule ARGS:data "pass,t:-removeNulls"