Ứng dụng kỹ thuật fuzzing trong việc tìm lỗ hổng bảo mật Website

I. Lỗ hổng hệ thống websize là gì?

Lỗ hổng website là những điểm yếu của hệ thống website mà hacker có thể lợi dụng để khai thác nhằm thu thập thông tin về hệ thống, tấn công lấy cắp thông tin, tấn công vào người dùng hệ thống hay tấn công chiếm quyền điều khiển hệ thống. Những lỗi bảo mật này có thể xuất phát từ những sai sót ngay từ trong các khâu thiết kế, lập trình hoặc triển khai hệ thống website. Lỗ hổng website có thể có nhiều nguyên nhân, tuy nhiên chủ yếu là do 3 nguyên nhân sau:

• Lỗi do sự yếu kém và chưa có khái niệm về lập trình an toàn của người lập trình, phát triển ứng dụng. Không kiểm soát chặt chẽ các đầu vào từ người dùng, hacker có thể lợi dụng để khai thác và tấn công hệ thống, người dùng hệ thống.
• Lỗi do việc cấu hình hệ thống yếu, cấu hình hệ thống mặc định, tài khoản hệ thống mặc định, do sử dụng các dịch vụ, nền tảng mà không cập nhật phiển bản mới, bản vá….
• Lỗi nằm trong các giao thức, các nền tảng hay chuẩn xây dựng hệ thống đã được công khai. Lỗ hổng website có thể phân thành một số loại chính như:
• Injection: Các lỗ hổng cho phép hacker chèn những script để thực thi như: SQL Injection, XPath Injection, System Command Injection, LDAP .Injection
• Client Side: Các lỗ hổng tấn công vào client. Ví dụ như Cross Site Scripting .(XSS), Cross-site Request Forgery (CSRF) .
• Parameter Manipulation: Các lỗ hổng như Cookie Manipulation, HTTP .Form Field Manipulation….
• Misconfiguration: Các lỗ hổng thuộc về cấu hình hệ thống chưa an toàn.
• Information Disclosure: Các lỗ hổng cung cấp các thông tin của hệ thống, hacker có thể lợi dụng cho những cuộc tấn công tiếp theo. Ví dụ như: Path .Traversal, Predict Resource Location, Directory Listing

II. Sơ lược về FUZZ

Fuzzing là một kỹ thuật được sử dụng để phát hiện ra lỗ hổng trong các đoạn code trước khi phát hành. Đó là một cách thử nghiệm lỗi hệ thống. Trong kiểm thử này, thay vì gửi các dữ liệu hợp lý (được xử lý trong mã nguồn), hệ thống kiểm thử sẽ nhận được các đầu vào hoặc chuỗi đầu vào không hợp lệ hoặc bán hợp lệ thông qua giao diện tương tác. Chương trình hoặc framework tạo ra các kiểm thử fuzz (fuzz test) hoặc thực thi các kiểm thử gọi là fuzzer. Quá trình fuzzing không chỉ là việc gửi và nhận các thông điệp. Việc giám sát mục tiêu cần được thực hiện liên tục, tất cả các thất bại đều được ghi lại để đánh giá trong các lần sau. Một phần quan trọng của quá trình fuzzing là giám sát mã lệnh, khi nó xử lý một đầu vào không hợp lệ.

III. Những lỗ hổng website thường gặp

Mỗi lỗ hổng bảo mật sẽ có cách khai thác và phát hiện khác nhau. Sau đây sẽ là một số lỗ hổng chính và các biện pháp để phát hiện, khắc phục và phòng tránh các lỗ hổng này.

1. Lỗ hổng Injection (SQL Injection, Xpath injection… )

1.1. Khái quát Lỗ hổng injection là loại lỗ hổng liên quan tới việc thao tác với CSDL. Bao gồm các hệ quản trị CSDL quan hệ (Mysql, MSSQL, Oracle…), các dữ liệu XML… Nguyên nhân: Do người lập trình không kiểm duyệt hoặc có kiểm duyệt chưa tốt dữ liệu nhập vào. Hacker dễ dàng chèn các câu lệnh truy vấn như SQL, Xquery… Khi chèn thành công hacker có thể thao tác trực tiếp CSDL của hệ thống, đọc tệp tin, ghi tệp tin nhằm tạo backdoor và chiếm quyền điều khiển hệ thống. 1.2. Ví dụ: Cho URL .http://example.com/ex1/injection/user.php?id=1 Với một giá trị ID chính xác được nhập vào là 1 hệ thống sẽ trả về người dùng có ID bằng 1. Quá trình xử lý của hệ thống là: PHP Code.$id=$_REQUEST[“id”]; .query = “SELECT * FROM users where userID=”.id;. Hệ thống không có quá trình kiểm duyệt dữ liệu ID từ người dùng.Trong trường hợp này ta thấy, nếu người dùng gửi đường dẫn có giá trị id = x thì kết quả trả về của hệ thống sẽ hoàn toàn bình thường. Tuy nhiên đoạn mã PHP xử lý biến $$d được đưa ngay vào câu truy vấn mà không được kiểm duyệt trước, hacker hoàn toàn có thể chèn một số mã độc để lấy thông tin về hệ thống.

Chẳng hạn, thay vì gửi giá trị id = 1 hacker sẽ gửi giá trị id = .-1 or 1=1. URL http://example.com/ex1/injection/user.php?id=-1or1=1 Khi đó câu truy vấn sẽ trở thành: SQL Query.SELECT * FROM users WHERE userID=-1 or 1=1 Rõ ràng với điều kiện WHERE userID = -1 thì CSDL sẽ không trả về bản ghi nào trả về. Tuy nhiên, nếu chèn vào đoạn mã "or 1=1 " thì điều kiện sau WHERE sẽ trở nên luôn đúng và kết quả là CSDL sẽ trả về tất cả các bản ghi có trong bảng users. Bằng những cách thức nâng cao khác, hacker hoàn toàn có thể chèn các đoạn mã nguy hiểm hơn để lấy toàn bộ thông tin về hệ thống, đọc ghi tệp tin bằng các hàm trong CSDL như: outfile, load_file (MySQL), execute (MSSQL) lên hệ thống từ đó hình thành những backdoor và sau cùng là chiếm quyền điều khiển toàn bộ hệ thống. Với kiểu tấn công Xpath Injection ta cũng có thể khai thác hoàn toàn tương tự. Mức độ nguy hiểm của SQL/Xpath Injection là rất cao bởi vì nó tác động trực tiếp đến CSDL: ăn cắp thông tin người dùng, thay đổi làm sai lệch các thông tin quan trọng, thêm sửa xóa CSDL… Với hệ thống website đặc biệt là các hệ thống có liên quan đến tài chính như ngân hàng, thì việc thông tin bị đánh cắp hay thay đổi sẽ gây những thiệt hại vô cùng lớn. 1.3. Cơ chế phát hiện Có thể phát hiện các lỗi SQL/Xpath Injection bằng 4 phương pháp chính:

• Dựa trên các thông báo lỗi từ hệ thống, từ CSDL của hệ thống.
• Dựa trên kỹ thuật boolean based (kiểm tra kết quả khác nhau của các câu truy vấn khác nhau, ví dụ như khi chèn or 1=1 và or 1=2).
• Dựa trên kỹ thuật nối câu truy vấn (UNION query).
• Dựa trên kỹ thuật timebased: sử dụng các hàm thao tác với thời gian trong hệ quản trị CSDL và kiểm tra timeout của kết quả trả về. Bộ dữ liệu fuzzing sẽ thiết kế dựa trên các kỹ thuật phát hiện này.

1.4. Các thức phòng tránh. Nguyên nhân chung nhất Lỗ hổng SQL Injection/Xpath Injection xảy ra do các biến được nhập vào từ người dùng không được kiểm soát chặt chẽ trước khi xây dựng câu truy vấn tới CSDL. Lỗ hổng SQL Injection/Xpath Injection xảy ra khi có kết hợp cả 2 điều kiện:

• Có sự truy vấn tới CSDL
• Câu truy vấn chưa được kiểm soát sự an toàn .Khi một biến được nhập vào từ người dùng, qua nhiều bước xử lý trung gian xây dựng câu truy vấn tới CSDL mà không có bất cứ bước kiểm tra sự an toàn nào thì chắc chắn sẽ mắc các lỗ hổng Injection.

2. Lỗ hổng Cross Site Scripting.

2.1. Khái quát. Cross-site Scripting (XSS) là lỗ hổng cho phép hacker có thể chèn những đoạn mã client-script (thường là Javascript, JScript, DHTML và cũng có thể là cả các thẻ HTML) vào trang web, khi người dùng vào những trên web này, mã độc sẽ được thực thi trên máy của người dùng và thực hiện các mục đích mà kẻ hacker mong muốn. Khác với SQL Injection tấn công vào CSDL của website, XSS tấn công trực tiếp vào người dùng. Lợi dụng lỗi XSS này, hacker có thể:

• Lừa đảo người quản trị của website, lấy cắp cookie, chiếm session… Từ đó có thể đăng nhập chiếm quyền điều khiển website.
• Thực thi các mã độc javascript tùy ý nhằm tấn công vào người dùng.
• Phát tán các thông tin xấu lên hệ thống. .Hiện nay, kĩ thuật tấn công XSS đã nhanh chóng trở thành một trong những lỗ hổng phổ biến nhất của các ứng dụng web. Mối đe doạ của chúng đối với người sử dụng ngày càng lớn..

2.2. Ví dụ. ví dụ đơn giản: URL http://fuzzing.vn:8001/Vulns/XSS/example.php?msg=I’am chientq Hệ thống thực hiệc việc in ra giá trị của biến GET msg. Đoạn mã PHP:. <?php. if (isset( _GET[&ampapos;msg&ampapos;] ) ){.echo &ampapos;&amplt;h1&ampgt;&ampapos;._GET['msg'].'</h1>';. } .?>. Tuy nhiên một hacker thay vì việc nhập vào dữ liệu hợp lệ có thể nhập vào những thẻ HTML và mã Javascript ví dụ như: http://fuzzing.vn:8001/Vulns/XSS/example.php?.msg=<script>alert(document.cookie)</scsript> Khi đó thay vì hiện dữ liệu như bình thường hệ thống xuất hiện một popup hiển thị cookie của người dùng:

Nếu như thay vì chỉ hiển thị cookie của hệ thống, hacker có thể sử dụng một hàm gửi mail hay một hàm trong javascript để gửi thông tin về cookie của người dùng về cho hacker thì hacker hoàn toàn có thể đăng nhập vào tài khoản của người dùng bằng .cách set giá trị cookie nhận được vào trình duyệt của hacker. hacker sẽ có đủ các quyền như người dùng khi đăng nhập vào hệ thống. Cũng với lỗi này hacker cũng có thể chèn các đoạn virus javascript, cài đặt add-on, download mã độc, … vào trình duyệt và máy của của người dùng. 2.3. Cơ chế phát hiện. Một biến có lỗ hổng XSS nếu như giá trị của biến đó được hiện ra trình duyệt hoặc trong mã nguồn html mà không có bước xử lý thích hợp nào trước đó.Đế phát hiện lỗi này chúng ta sẽ thực hiện tạo fuzzer gửi một chữ ký kèm những đoạn mã đặc biệt tới hệ thống như: .<scipt>alert(1223)</script>.“><scipt>alert(1223)</script>.“ onmouseover=alert(123445) foo=”.….. Thực hiện việc phân tích mã html, nếu tìm thấy sự xuất hiện của các đoạn mã đó trong mã html thì chứng tỏ hệ thống đã mắc lỗi XSS. 2.4. Các thức phòng tránh. XSS là một lỗ hổng rất phổ biến và rất nguy hiểm đối với người dùng hệ thống. Tuy nhiên việc phòng tránh lỗi XSS lại hết sức đơn giản. Đối với các dữ liệu được nhận từ người dùng, khi thực hiện việc hiển thị ta cần encode tất cả các giá trị được in ra.Khi đó các đoạn mã độc sẽ không thể thực thi được. Trong các ngôn ngữ lập trình đều có các hàm hỗ trợ việc mã hóa dữ liệu này. Ví dụ như:

• Hàm htmlentities() – trong ngôn ngữ PHP.
• Hàm htmlEncode() – trong ngôn ngữ C#.
• Trong jsp cung cấp cú pháp: $$specialCharString} để thực hiện encode html .tag..

3. Lỗ hổng File Inclusion.

3.1. Khái quát. Lỗ hổng File Inclusion là loại lỗ hổng xảy ra khi hệ thống thực hiện việc thao tác với tệp tin. Khi hệ thống không có quá trình kiểm duyệt đoạn mã chèn vào chặt chẽ, .hacker có thể lấy các giá trị của các biến Post, Get, Headers từ người dùng gửi lên .để thao tác với CSDL. Bằng việc khai thác lỗ hổng này hacker có thể thực hiện việc .tải các backdoor lên hệ thống và đọc các tệp tin của hệ thống…. File Inclusion được chia làm 2 loại chính là:

• Local File Inclusion: Thực hiện khi các tệp tin mà hệ thống thao tác là các tệp tin của local và không cho phép việc chèn vào hệ thống các đoạn mã .
• Remote File Inclusion: Cho phép việc chèn các đoạn mã từ một hệ thống từ xa và thực hiện trên web server.. 3.2. Ví dụ Với một chương trình có dạng: . URL http://fuzzing.vn:8001/abc/LFI/?color=blue.php. Code xử lý: <?php.color = &ampapos;green.php&ampapos;;.if (isset( _GET['color'] ) ){.$color=$_GET['color'];.}.include( $$olor );.?> Đường dẫn này sẽ lấy giá trị của biến color trong GET link để thực hiện việc hàm include file đó vào ứng dụng. Trong trường hợp này là blue.php, red.php và green.php để hiển thị các dòng chữ có màu lam, đỏ và màu lục tương ứng. Tuy nhiên thay vì để mặc định các giá trị là “green.php”, “red.php” hay “blue.php” hacker hoàn toàn có thể nhập vào giá trị bất thường nhằm đọc các thông tin từ hệ thống. Ví dụ việc đọc tệp tin cấu hình của apache server. http://fuzzing.vn:8001/vulns/LFI/?color= / / /apache/conf/httpd.conf khi đó hệ thống sẽ đọc tệp tin httpd.conf của hệ thống. Do cấu trúc “ /” trong các hệ điều hành là để quay lại thư mục cha của ứng dụng, kẻ tấn công có thể lái việc đọc vào .các tệp tin tương ứng. Khi khai thác lỗi này thành công, hacker có thể thực hiện đọc các tệp tin cấu hình hệ thống, hoặc có thể đọc các tệp tin quan trọng khác như: /etc/passwd, /etc/shadow… . Tuy nhiên hacker cũng có thể chèn vào một đường dẫn đến những đoạn mã nguy hiểm khác và thực hiện include vào hệ thống (nếu như hệ thống cho phép việc include remote file). Như vậy hacker không chỉ là đọc nữa mà hoàn toàn có thể thực thi các đoạn mã đó trên hệ thống và tạo ra các backdoor hay tải các webshell lên server và chiếm quyền điều khiển hoàn toàn web server. 3.3. Phát hiện. Để phát hiện lỗi này chúng ta sẽ thực hiện đưa vào những giá trị của các tệp tin có thể và kiểm tra kết quả trả về để đánh giá việc tồn tại của lỗ hổng. Ví dụ:. / / /etc/passwd.- / / /etc/shadow.- / /apache/logs/access.log. Việc chèn số các “ /” là do chương trình phát hiện sẽ tự động thêm vào.

3.4. Phòng tránh. File Inclusion là một lỗi cực kỳ nghiêm trọng. Để phòng tránh cho chương trình gặp phải các lỗi như vậy. Người lập trình cần quản lý, kiểm duyệt chặt chẽ các giá trị .của các biến mà người dùng nhập vào hệ thống trước khi thực hiện việc đưa các .biến đó vào xử lý. Đặc biệt là khi thao tác với các tệp tin của hệ thống. Khi thực hiện việc include file, không nên sử dụng các dữ liệu được cung cấp từ người dùng, các giá trị này cần được đặt tĩnh trong code của chương trình.

IV. Một số tool sử dụng thuật toán fuzzing trong việc tìm lỗ hổng Web:

Phương pháp kiểm tra fuzzer chủ yếu được ứng dụng trong việc thiết kế các tool để kiểm tra lỗi bảo mật Web.

4.1 Nguyên tắc thực hiện:

Dựa vào các phân tích các lỗ hổng ở trên mà các nhà phát triển sẽ thiết kế bộ dữ liệu fuzzing phù hợp nhằm phát hiện tối đã các lỗ hổng bảo mật website. Sau đó các công cụ sử dụng phương pháp fuzzing để kiểm tra lỗi bảo mật sẽ không thực hiện việc quét cấu trúc thư mục và tập tin của ứng dụng web, mà sẽ là tập hợp tất các lỗi đã được công bố đối với từng ứng dụng web cụ thể và thực hiện đệ trình đến ứng dụng web xem thử ứng dụng đó có bị mắc các lỗi bảo mật hay không? Ví dụ, một fuzzer kiểm tra tất cả các lỗi bảo mật liên quan đến ứng dụng cổng thông tin điện tử Joomla thì nó sẽ tập hợp tất cả các lỗi bảo mật liên quan đến ứng dụng Joomla và thực hiện đệ trình khi người kiểm tra cung cấp.

4.2 Một số tool tiêu biểu

4.2.1 Nikto (http://cirt.net/nikto2) Là một trong những công cụ thực hiện fuzzer các lỗi bảo mật tốt nhất và nhanh nhất hiện nay. Với cơ sở dữ liệu cập nhật hàng trăm lỗi bảo mật được xuất hiện hằng ngày. Đặc biệt là Nikto được sử dụng hoàn toàn miễn phí và có khả năng tùy biến cao. Nikto cũng là một trong những công cụ được insecure.org bình chọn một trong những công cụ quét lỗi bảo mật web tốt nhất trong 10 công cụ. Ngoài ra, Nikto cho phép người sử dụng tùy biến viết các thành phần và nhúng kết với Nikto để thực thi. Hơn nữa, Nikto cũng hỗ trợ nhiều định dạng của những chương trình quét lỗi bảo mật khác như: Nmap, Nessus. 4.2.2 AppScan (http://www.ibm.com/software/awdtools/appscan/) Một công cụ thương mại tập hợp lớn các lỗi bảo mật cho từng ứng dụng web riêng biệt. 4.2.3 Acunetix Web Vulnerability Scanner (WVS) Công cụ này kiểm tra tất cả các lỗ hổng web, bao gồm SQL Injection, Cross Site Scripting và nhiều lỗ hổng khác. Acunetix sử dụng kỹ thuật phân tích động với hướng tiếp cận dựa trên phỏng đoán, sử dụng thuật toán Fuzzing. Ban đầu Module Crawler phân tích toàn bộ trang web bằng cách làm theo tất cả các liên kết trên trang web. Sau đó, WVS sẽ vạch ra cấu trúc trang web và hiển thị thông tin chi tiết về mỗi tập tin. Sau quá trình thu thập thông tin, WVS tự động hiển thị một loạt các lỗ hổng có thể bị tấn công trên mỗi trang được tìm thấy. Khi các lỗ hổng được tìm thấy, Acunetix WVS báo cáo về lỗ hổng này. Dưới đây là một giao diện của phần mềm Acunetix được đánh giá thử nghiệm:

4.2.4 MiniFuzz File Fuzzer Chiếu theo chính sách SDL, một trong những công đoạn bắt buộc khi kiểm tra (test) ứng dụng là fuzzing, tức là kiểm tra bằng các dữ liệu đầu vào ngẫu nhiên. Minifuzz File Fuzzer là công cụ kiểm tra mờ (fuzzy testing) cơ bản, được phát triển nhằm cho phép các chuyên gia không thuộc lĩnh vực an toàn, không có kiến thức về kiểm tra mờ cũng có thể thực hiện được việc kiểm tra này. Công cụ này đưa tới đầu vào của ứng dụng được kiểm tra các giá trị khác nhau nhằm tìm ra những ngoại lệ chưa được xử lý. 4.2.5 SDL Regex Fuzzer Là công cụ kiểm tra mờ các biểu thức chính quy (Regex). SDL Regex Fuzzer cho phép kiểm tra các biểu thức chính quy để phát hiện các lỗ hổng loại “từ chối dịch vụ”. Đây là nhiệm vụ không đơn giản bởi các biểu thức chính quy thường chứa các mệnh đề có độ phức tạp hàm mũ về thời gian. Các biểu thức dạng này có thể bị lợi dụng để thực hiện tấn công từ chối dịch vụ. Công cụ SDL Regex Fuzzer cho phép tìm kiếm và chỉ ra sự có mặt của các biểu thức nguy hiểm này ngay trong quá trình phát triển ứng dụng.