Archive

Archive for December, 2010

Tổng quan các phương pháp kiểm tra lỗi bảo mật trên ứng dụng


GIỚI THIỆU

Trong quá trình tiếp cận và kiểm tra một ứng dụng liệu có bị các lỗi bảo mật hay không?, có rất nhiều phương pháp tiếp cận. Có thể phân chia thành 3 loại như sau:

1.     Phương pháp kiểm tra hộp đen (Blackbox testing)

2.     Phương pháp kiểm tra hộp trắng (Whitebox testing)

3.     Phương pháp kiểm tra hộp xám (Greybox testing)

Mỗi phương pháp tiếp cận đều có ưu và nhược điểm của chúng. Chúng ta sẽ lần lượt đi qua từng pháp một. Lưu ý, ở đây seamoun chỉ đứng trong phạm vi nhỏ là kiểm tra lỗi bảo mật của ứng dụng, chứ không đặt mình trong quy trình phát trình ứng dụng. Bởi nếu đặt trong quy trình phát triển ứng dụng và kiểm tra ứng dụng thì có rất nhiều phần khác nhau và cũng có nhiều cách kiểm tra khác nhau đối với ứng dụng.

1) Whitebox testing

Theo seamoun đơn giản nhất trong việc định nghĩa whitebox testing là quá trình kiểm tra ứng dụng khi người kiểm tra ứng dụng đóng vai trò là người phát triển ứng dụng đó. Vậy trong vai trò là người phát triển ứng dụng để kiểm tra ứng dụng có bị lỗi hay không thì có một số cách tiếp cận như sau:

a)     Kiểm tra mã nguồn

Kiểm tra mã nguồn là việc người kiểm tra quan sát mã nguồn do người phát triển ứng dụng. Việc quan sát này có thể thực hiện đơn giản bằng việc mở mã nguồn đọc hiểu và quan sát điểm nào có khả năng gây lỗi bảo mật cho ứng dụng. Bạn sẽ đặt câu hỏi là một ứng dụng với hàng trăm dòng lệnh và có cấu trúc phức tạp, do vậy việc đọc hiểu và kiểm tra lỗi bảo mật cho toàn bộ ứng dụng theo cách chỉ quan sát thuần túy thì rất khó đạt được đúng không ? Cho nên cũng phải có công cụ bổ trợ, trợ giúp cho người kiểm tra phân loại, tiếp cận nhanh chóng những điểm mà ứng dụng có khả năng bị lỗi.

Ví dụ một đoạn mã C như sau:

#include <string.h>

int main (int argc , char **argv)

{

char buffer[10];

strcpy(buffer,argv[1]);

}

Nhìn đoạn mã trên thì chắc ai cũng biết có khả năng bị lỗi tràn bộ đệm (buffer overflow) nhưng quan trọng ở chỗ chúng ta phải đọc cả một ứng dụng để tìm ra những hàm có khả năng gây lỗi (strcpy) như trên nếu như không có bất kỳ sự trợ giúp công cụ nào. Do vậy, công cụ scan code ra đời để scan toàn bộ mã nguồn ứng dụng dựa trên tập các hàm có nguy cơ gây ra lỗi bảo mật và xác định vị trí hàm đó được sử dụng trong ứng dụng giúp người kiểm tra có thể tập trung ngay tại vị trí mà công cụ scan code phát hiện.

b)    Công cụ và phân loại

Phân loại công cụ bổ trợ trong whitebox testing có thể chia thành 3 nhóm công cụ sau:

1.     Compile time checkers

2.     Source code browsers

3.     Automated source code auditing

Compile time checkers là quá trình kiểm tra ứng dụng lúc biên dịch. Ví dụ tùy chọn /analyze trong biên dịch Microsoft Visual C++. Vậy các bạn sẽ hỏi là kiểm tra này có tác dụng gì ? có liên quan gì đến kiểm tra lỗi bảo mật ? Mỗi trình biên dịch có rất nhiều tùy chọn khác nhau, có những tùy chọn liên quan đến bảo vệ ứng dụng, tối ưu hóa ứng dụng, … Cho nên việc tìm hiểu và lựa chọn các tùy chọn trong lúc biên dịch ứng dụng cũng rất quan trọng. Ví dụ như tùy chọn /GS hoặc /SafeSEH là những tùy chọn điển hình trong trình biên dịch C++, giúp ứng dụng không bị khai thác trong trường hợp bị lỗi buffer overflow (Vẫn có thể bypass 😉 😉 được nhưng trong phạm vị bài viết này seamoun không đề cập đến :D).

Source code browsers là những công cụ mà trợ giúp người kiểm tra trong quá trình quan sát mã nguồn ứng dụng một cách trực quan. Những công cụ này sẽ tìm kiếm những hàm có khả năng gây ra lỗi bảo mật, tạo các tham chiếu liên quan đến hàm sử dụng, phân loại và sắp xếp quá trình biến sử dụng, cung cấp các kiếm kiếm nâng cao có thể truy xuất nhanh chóng đến tất cả tham chiếu của hàm đang quan tâm, …

Automated source code auditing cũng giống như trên là scan mã nguồn nhưng có thêm phần tự động nhận diện các khu vực lỗi. Tương ứng với mỗi công cụ này cũng đòi hỏi đầu vào phải là ngôn ngữ mà ứng dụng sử dụng.

Một số công cụ thương mại của một số hãng có thể kể đến như:

Tên Địa chỉ website
Fortify http://www.fortifysoftware.com
Coverity http://www.coverity.com
KlocWork http://www.klocwork.com
GrammaTech http://www.grammatech.com

Một số công cụ miễn phí:

Tên Ngôn ngữ OS Link
RATS C,C++,Perl,PHP,Python Unix, Win32 http://www.fortifysoftware.com/security-resources/rats.jsp
ITS4 C,C++ Unix, Win32 http://www.cigital.com/its4
Splint C Unix, Win32 http://clint.cs.virginia.edu
Flawfinder C, C++ Unix http://www.dwheeler.com/flawfinder
Jlint Java Unix, Win32 http://jlint.sourceforge.net
CodeSpy Java Java http://www.owasp.org/software/labs/codespy.html

Những ưu điểm và nhược điểm khi tiếp cận và kiểm tra lỗi bảo mật bằng whitebox testing:

1.     Tính bao phủ toàn diện: Điều này thì không bàn cãi rồi, bởi vì người kiểm tra có mã nguồn của ứng dụng đó. Quan trọng là biết cách tổ chức và tiếp cận như thế nào cho hợp lý.

2.     Độ phức tạp cao: Với khối lượng lớn các mã dòng lệnh và mối liên hệ phức tạp trong ứng dụng thì rõ ràng việc tiếp cận bằng quan sát mã nguồn không phải đơn giản.

3.     Tính sẵn sàng: Không phải ứng dụng nào cũng dễ dàng có được mã nguồn phát triển cho người kiểm tra có thể quan sát.

2) Blackbox testing

Theo seamoun đơn giản nhất cho việc định nghĩa blackbox testing là người kiểm tra đóng vai trò là người dùng cuối (tức là người sử dụng ứng dụng). Lúc này thì người kiểm tra tương tác với dụng thông qua các đầu vào ứng dụng cung cấp và quan sát đầu ra do ứng dụng trả về. Người kiểm tra sẽ không biết nội tại bên trong ứng dụng sẽ xử lý thế nào? (Vì không có mã nguồn ứng dụng sao mà biết nó viết cái gì bên trong được !!!). Do đó người kiểm tra phát hiện các lỗi bảo mật trên ứng dụng thông qua việc đề trình các dữ liệu đầu vào và quan sát dữ liệu đầu ra và từ đó đưa ra kết luận. Cũng tương tự như đối với phương pháp whitebox testing thì người kiểm tra có thể duyệt hết các chức năng của ứng dụng bằng phương pháp thủ công (tức là chỗ nào ứng dụng yêu cầu nhập thì nhập, chỗ nào yều cầu click thì click, …:D 😀 :D) không có sự hỗ trợ của công cụ. Đối với mỗi điểm vào của ứng dụng thì người kiểm tra phải suy nghĩa những dữ liệu nào cho đầu vào có thể làm cho ứng dụng phản ứng sai ý nghĩa vốn có của nó. Ví dụ như muốn kiểm tra lỗi SQL Injection trên một ứng dụng Web thì người kiểm tra cần phải đệ trình với dữ liệu đầu vào là dấu ‘ , vì sao phải đệ trình dấu ‘ ?. (Các bạn tự tìm hiểu ở các topic khác về SQLi, seamoun không đề cập sâu thêm ở đây !).

Nếu phương pháp whitebox testing có công cụ tự động hỗ trợ người kiểm tra thì phương pháp blackbox testing cũng có những công cụ như vậy để giúp người kiểm tra có thể xác định nhanh chóng các điểm vào ứng dụng và cũng ghi nhận đầu ra sau khi đã đệ trình dữ liệu được định nghĩa trước đó, sau đó đưa ra kết luận liệu ứng dụng có bị lỗi hay không ? Quá trình sử dụng công cụ tự động trong việc blackbox testing có thể gọi là quá trình fuzzing. Các công cụ fuzzing, đối tượng fuzzing và các loại fuzzing seamoun sẽ lần lượt giới thiệu sau !!!

Một số ưu điểm và nhược điểm của blackbox testing có thể kể đến như:

1.     Tính sẵn sàng cao: tức là không nhất thiết phải chờ có mã nguồn thì mới có thể kiểm tra được ứng dụng, có thể kiểm tra bất cứ ứng dụng nào !!!

2.     Tính sử dụng lại cao: tức là khả năng sử dụng lại việc kiểm tra đối với ứng dụng. Ví dụ một công cụ dùng để kiểm tra đối với ứng dụng FTP A thì có thể dùng công cụ đó đối với việc kiểm tra ứng FTP B hay FTP C vẫn bình thường, không phân biệt rõ ràng ứng dụng đó như thế nào ?

3.     Đơn giản dễ thực hiện không đòi hỏi phải có nhiều quy trình phức tạp, …

4.     Tính bao phủ hạn chế là một trong những hạn chế lớn nhất của blackbox testing. Tức là phải xây dựng nhiều tình huống kiểm tra cho ứng dụng và phải quét hết tất cả các trường hợp đầu vào mà ứng dụng sử dụng, như vậy mới triệt để trong việc kiểm tra ứng dụng có bị lỗi hay không?

3) Greybox testing

Hai phương pháp blackbox testing và whitebox testing thì đã rõ rồi, phân biệt rất rõ ràng. Một bên là tiếp cần từ mã nguồn ứng dụng một bên là tiếp cận ở các điểm vào của ứng dụng sử dụng. Vậy còn greybox testing là gì ? Nghe cái tên là thấy nửa đực nửa cái rồi ! Mà thật sự quả đúng như vậy 😀 😀 :D. Greybox testing là quá trình kiểm tra một ứng dụng ở dạng “lưng chừng” tức là một ứng dụng có thể chúng ta không có mã nguồn mà nó phát triển nhưng có thể dịch và đọc mã nguồn ở cấp độ thấp (ngôn ngữ assembly) của ứng dụng đó để tìm ra lỗi bảo mật. Ví dụ một ứng dụng phát triển bằng ngôn ngữ C++, sau khi biên dịch thành một ứng dụng để có thể thực thì việc dịch ngược ứng dụng đó trở lại chính ngôn ngữ C++ như nguyên bản ban đầu thì rất khó và gọi quá trình dịch ngược này là decompiler. Hoặc có thể dịch ứng dụng đó sang assembly. Như các bạn đã biết thì mọi ứng dụng đều phải đưa về mã máy để CPU xử lý, cho nên việc dịch từ ứng dụng về assembly luôn luôn là có thể. Quá trình này có thể gọi là disassembler.

Một số công cụ nổi tiếng có thể kể đến trong quá trình disassembler như:

Tên Link
IDA Pro http://www.hex-rays.com/idapro/
Ollydbg http://www.ollydbg.de/
Windbg http://www.microsoft.com/whdc/devtools/debugging/default.mspx
ImmunityDebugger http://www.immunityinc.com/products-immdbg.shtml

Muốn tìm lỗi bảo mật của ứng dụng nào thì hiển nhiên cần download công cụ disassemler ứng dụng đó rồi ngồi đọc mã assembly để tìm lỗi thôi !!! Các bạn sẽ đặt vấn đề là mã nguồn nguyên thủy đọc còn chưa xong, huống gì đọc assembly hoa cả mắt, … 😀 😀 :D. Trên thực tế các researcher tìm kiếm bug toàn làm thế các bạn ạ ! Làm gì sẵn có mã nguồn nguyên thủy để mà đọc. Vậy các bạn sẽ đặt thêm vấn đề là hai phương pháp blackbox testing và whitebox testing nó có công cụ tự động làm thì greybox testing có công cụ tự động như thế không ? Hoàn toàn có các bạn à, sau đây là một số công cụ tự động thực hiện:

Tên Vendor
LogiScan LogicLibrary
BugScam Halvar Flake
Inspector HB Gary
SecurityReview Veracode
BinAudit SABRE Security

Một số ưu điểm và nhược điểm của phương pháp greybox testing như sau:

1.     Tính sẵn sàng cao: nếu như thực hiện BinAudit thì luôn luôn sẵn sàng nếu chúng ta có ứng dụng

2.     Làm tiền đề cho blackbox testing: việc thực hiện greybox testing giúp người kiểm tra xác định rõ hơn vị trí, kiểu dữ liệu đề trình trong quá trình thực hiện blackbox testing.

3.     Hạn chế của greybox là phức tạp, để có thể đọc hiểu và tìm ra lỗi thì đòi hỏi người kiểm tra lỗi phải có background tốt về kiến thức lập trình, hệ thống, phân tích, phán đoán, …

4) Kết luận

Các bạn lưu ý rằng công cụ vẫn là công cụ, nó chỉ giúp người kiểm tra một phần nào đó, không thể thay thế hoàn toàn được. Người kiểm tra phải là trung tâm chính và đóng vai trò quyết định trong việc tìm các lỗi bảo mật trên ứng dụng.

Thông qua bài viết này seamoun muốn các bạn có nhìn tổng quát về phương pháp tiếp cận về đánh giá các lỗi bảo mật trên ứng dụng. Các nhận xét của seamoun mang tính chất cá nhân, chủ quan. Bạn nào có ý kiến xin chia sẻ và đóng góp.

 

Advertisements

RIPS


RIPS is a static source code analyser for vulnerabilities in PHP webapplications.

Download: http://sourceforge.net/projects/rips-scanner/
Features:

  • detect XSS, SQLi, File disclosure, LFI/RFI, RCE vulnerabilities and more
  • 5 verbosity levels for debugging your scan results
  • mark vulnerable lines in source code viewer
  • highlight variables in the code viewer
  • user-defined function code by mouse-over on detected call
  • active jumping between function declaration and calls
  • list of all user-defined functions (defines and calls), program entry points (user input) and scanned files (with includes) connected to the source code viewer
  • create CURL exploits for detected vulnerabilties with few clicks
  • visualization, description, example, PoC, patch and securing function list for every vulnerability
  • 7 different syntax highlighting colour schemata
  • display scan result in form of a top-down flow or bottom-up trace
  • only minimal requirement is a local webserver with PHP and a browser (tested with Firefox)
  • regex search function
Categories: Audit Source Code

RATS – Rough Auditing Tool for Security


RATS – Rough Auditing Tool for Security – is an open source tool developed and maintained by Secure Software security engineers. Secure Software was acquired by Fortify Software, Inc. RATS is a tool for scanning C, C++, Perl, PHP and Python source code and flagging common security related programming errors such as buffer overflows and TOCTOU (Time Of Check, Time Of Use) race conditions.

RATS scanning tool provides a security analyst with a list of potential trouble spots on which to focus, along with describing the problem, and potentially suggest remedies. It also provides a relative assessment of the potential severity of each problem, to better help an auditor prioritize. This tool also performs some basic analysis to try to rule out conditions that are obviously not problems.

As its name implies, the tool performs only a rough analysis of source code. It will not find every error and will also find things that are not errors. Manual inspection of your code is still necessary, but greatly aided with this tool.

Download

Win32: https://www.fortify.com/downloads2/public/rats-2.3-win32.zip

Source tarball: https://www.fortify.com/downloads2/public/rats-2.3.tar.gz

usage: rats [options] [file]…

Options explained:

-d <filename>, –db <filename>, –database <filename>

Specifies a vulnerability database to be loaded.  You may

have multiple -d options and each database specified will

be loaded.

-h, –help      Displays a brief usage summary

-i, –input     Causes a list of function calls that were used which

accept external input to be produced at the end of the

vulnerability report.

-l <lang>, –language <lang>

Force the specified language to be used regardless of

filename extension. Currently valid language names are

“c”, “perl”, “php”, “python” and “ruby”.

-r, –references

Causes references to vulnerable function calls that are not

being used as calls themselves to be reported.

-w <level>, –warning<level>

Sets the warning level.  Valid levels are 1, 2 or 3.

Warning level 1 includes only default and high severity

Level 2 includes medium severity. Level 2 is the default

warning level 3 includes low severity vulnerabilities.

-x              Causes the default vulnerability databases (which are in

the installation data directory, /usr/local/lib by default)

to not be loaded.

-R, –no-recursion

Disable recursion into subdirectories.

–xml       Cause output to be in XML

–html      Cause output to be in HTML

–follow-symlinks

Evaluate and follow symlinks.

Categories: Audit Source Code

Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn(phần 2)


2) RATS (Rough Auditing Tool for Security)

Công cụ RATS cũng là một trong những công cụ thực hiện rà soát mã nguồn đối với một số ứng dụng được viết bằng các ngôn ngữ như C, C++, Perl, PHP, Python và Ruby do Secure Software Inc phát triển. Có download miễn phí công cụ tại (https://www.fortify.com/ssa-elements/threat-intelligence/rats.html). Cộng cụ này cũng chỉ dựa trên tập các hàm mà có nguy cơ gây ra lỗi bảo mật đối với dụng và nó thực hiện scan với tốc độc đáng nể !!!. Sau khi thực hiện chạy công cụ thì công cụ sẽ đưa ra một danh sách các hàm và vị trí trong mã nguồn, giúp người kiểm tra có thể nhanh chóng tập trung ra soát lại các hàm mà RATS đưa ra, kiểm tra liệu khi sử dụng các hàm đó đã an toàn hay chưa ? Một số tùy chọn trong công cụ RATS

usage: rats [options] [file]…

Options explained:

-d <filename>, –db <filename>, –database <filename>

Specifies a vulnerability database to be loaded.  You may

have multiple -d options and each database specified will

be loaded.

-h, –help      Displays a brief usage summary

-i, –input     Causes a list of function calls that were used which

accept external input to be produced at the end of the

vulnerability report.

-l <lang>, –language <lang>

Force the specified language to be used regardless of

filename extension. Currently valid language names are

“c”, “perl”, “php”, “python” and “ruby”.

-r, –references

Causes references to vulnerable function calls that are not

being used as calls themselves to be reported.

-w <level>, –warning<level>

Sets the warning level.  Valid levels are 1, 2 or 3.

Warning level 1 includes only default and high severity

Level 2 includes medium severity. Level 2 is the default

warning level 3 includes low severity vulnerabilities.

-x              Causes the default vulnerability databases (which are in

the installation data directory, /usr/local/lib by default)

to not be loaded.

-R, –no-recursion

Disable recursion into subdirectories.

–xml       Cause output to be in XML

–html      Cause output to be in HTML

–follow-symlinks

Evaluate and follow symlinks.

3) Spike Php Security Audit Tool

Công cụ spikephpSecAudit do SpikeSource phát triển và hoàn toàn miễn phí (có vẻ dự án bị dừng lại từ năm 2007, nhưng không sao, vẫn còn dùng tốt 😀 😀 :D). Có thể download tại (http://developer.spikesource.com/projects/phpsecaudit/) Ngoài ra nhóm này cũng có một số dự án hay liên quan, các bạn có thể vào trang web của nhóm này để tham khảo. Thực hiện kiểm tra mã nguồn rất đơn giản, chỉ cần download về giải nén và thực hiện:

php.exe run.php <thư mục chứa mã nguồn hoặc tập tin cần kiểm tra>

4) Graudit

Graudit cũng tương tự như công cụ RATS hỗ trợ rà soát nhiều mã nguồn. Tuy nhiên công cụ này chỉ chạy trên môi trường Linux. Các bạn có thể download tại đây (http://www.justanotherhacker.com/projects/graudit.html)

5) RIPS

Một công cụ tốt nhất về rà soát và đánh giá mã nguồn ứng dụng Web phát triển từ ngôn ngữ PHP. Thông tin chi tiết và download công cụ các bạn có thể truy cập tại đây http://sourceforge.net/projects/rips-scanner/

Sở dĩ nó là công cụ tốt nhất trong việc rà soát mà nguồn bởi vì công cụ RIPS không đơn giản là dựa vào tập nhận diện các hàm có thể xảy ra lỗi như là các công cụ đã giới thiệu RATS, GRAUDIT,AppCodeScan. Cách tiếp cận và kiểm tra mã nguồn dựa trên việc xác định các điểm vào của ứng dụng, từ đó thực hiện kiểm tra đối với những đối số đầu vào này trong mã nguồn ứng dụng (giống như cách tiếp cận mà seamoun đã giới thiệu ở trên)

Ngoài những công cụ trên thì còn rất nhiều công cụ được phát triển nhằm bổ trợ cho việc rà soát mã nguồn. Toàn bộ những công cụ mà seamoun giới thiệu ở trên là miễn phí. Các công cụ thương mại thì seamoun thấy hình ảnh quảng cáo rất đẹp và có nhiều tính năng nhưng không biết nó thế nào ? 😀 😀 :D. Công cụ chỉ vẫn là công cụ nó chỉ giúp cho người kiểm tra một phần nào đó, không thể có một công cụ nào đủ thông minh mà làm thay thế hoàn toàn con người được. Nếu có một công cụ như thế chắc anh em bị đuổi việc hết 😀 😀 :D. Việc kiểm tra mã nguồn đòi hỏi người kiểm tra phải có cách quan sát tinh tế + độ “quái” khi cần thiết.

AppCodeScan


This tool is designed to help in performing whitebox testing. During whitebox testing one needs to scan complete application code for various different vulnerabilities like XSS, SQL injection, Poor validations etc. It is possible to discover these vulnerable points using this tool and one can follow code walking across the code base to trace this vulnerability.This tool works on following two areas:

Code Scanning – One needs to feed target code folder, rules pattern in regex (sample is provided for ASP) and list of file extension to scan. The tool will take this information and run against the target folder with depth of three (3) and scan each line for matching pattern. If pattern is found then it will report that line in the tool.
Code Walker – This little utility would help in walking across the code base and find variable or function. This will help to trace variables and their entire path in the large code base. This utility would help in negating false positives from the identified pattern.

Link download: http://blueinfy.com/AppCodeScan.zip

Categories: Audit Source Code

Nhận biết lỗi ứng dụng Web thông qua quá trình rà soát mã nguồn (phần 1)


I. Giới thiệu

Nhận biết lỗi ứng dụng Web thông qua quá trình quan sát mã nguồn không phải là một quá trình đơn giản. Mã nguồn của một ứng dụng Web vô cùng phức tạp bao gồm nhiều thành phần (biến, hàm, đối tượng, lớp, …). Cho nên phải có phương pháp tiếp cận phù hợp thì mới có thể kiểm tra đánh giá an toàn ứng dụng Web một cách triệt để thông qua việc kiểm tra mã nguồn của ứng dụng đó. Một câu hỏi đơn giản là: “Người kiểm tra sẽ làm gì với mã nguồn Web ? Anh ta sẽ bắt đầu từ đâu ? Sẽ bắt đầu như thế nào ? … “. Có một số cách tiếp cận như:

1) Xây dựng một công cụ tự động scan toàn bộ mã nguồn và dựa trên tập nhận biết các điểm yếu để đưa ra cảnh báo cho người kiểm tra.

2) Nhận biết các điểm vào của ứng dụng và thực hiện tìm kiếm mối quan hệ giữa điểm vào của ứng dụng và mã nguồn ứng dụng.

Ưu điểm của phương pháp 1 thì rất nhanh trong việc tìm kiểm tra. Nhưng nhược điểm lớn nhất của nó là không triệt để, vì chỉ đơn thuần dựa vào tập nhận biết điểm yếu ban đầu. Phương pháp thứ 2 thì triệt để hơn nhưng nhược điểm của nó là thời gian trong việc kiểm tra mặc dù trong quá trình tím kiếm mỗi liên hệ giữa điểm vào ứng dụng và mã nguồn có công cụ bổ trợ.

Theo seamoun thì tốt nhất nên vận dụng cả hai. Sử dụng phương pháp 1 trước để nhận định sơ bộ về tình hình của mã nguồn. Liệt kê nhanh chóng các điểm yếu có thể có do công cụ nhận diện. Tiếp đến sử dụng phương pháp 2 để xác minh và tìm thêm các lỗi mới. Trong quá trình kiểm tra, theo seamoun thì phải đặt ứng dụng Web trong cái tổng thể của nó. Tức là tự bản thân một ứng dụng Web thì không thể chạy được nếu như thiếu các thành phần khác như máy chủ phục vụ web, database, … Nếu như đặt ứng dụng Web trong cái tổng thể của nó thì trước tiên chúng ta phải nhận diện những thành phần liên quan của nó. Nhận diện các thành phần liên quan ở đây là máy chủ phục vụ web, cở sở dữ liệu mà ứng dụng  sử dụng và các thành phần bổ trợ khác ví dụ như tường lửa cho ứng dụng, tài nguyên khác, … Bước tiếp theo nhận diện các điểm vào của ứng dụng ? Điểm vào của ứng dụng là gì? Tức là thành phần mà ứng dụng Web tương tác (ví dụ như các phương thức GET/POST, các forms, chuỗi truy vấn, cookies,…) với người dùng cuối. Sau khi đã xác định tất cả các điểm vào của ứng dụng, bước tiếp theo sẽ thực hiện truy tìm mối liên hệ giữa các điểm vào của ứng dụng với mã nguồn Web sử dụng. Quá trình này rất quan trọng và điểm mấu chốt để tìm ra lỗi của ứng dụng. Nên có một công cụ bổ trợ để trợ giúp quá trình lần tìm mối liên hệ này. Công cụ bổ trợ này phải phù hợp với từng đặc thù mã nguồn ứng dụng Web. Bởi vì, hiện tại có rất nhiều mã nguồn phát triển ứng dụng Web (ASP.NET, PHP, Perl, JSP, …) nên cách tiếp cận nó cũng phải khác nhau về mặt cấu trúc mà từng ngôn ngữ sử dụng. Không thể một công cụ trace code cho ASP.NET lại dùng cho ngôn ngữ PHP được 😀 😀 :D. Nếu như các công cụ bổ trợ này mà không phù hợp với việc trace code cho ứng dụng Web mà chúng ta đang kiểm tra thì chúng ta cũng phải “è cổ” code riêng một cái sử dụng riêng cho ứng dụng đó. Sau khi đã có được mối liên hệ giữa các điểm vào của ứng dụng thì nên biểu diễn nó bằng sơ đồ quan hệ (dùng hình vẽ hay ký hiệu gì thì tùy miễn sao biểu diễn được mối quan hệ là được!!!). Việc mã xử lý các điểm vào sẽ rất rõ ràng ở giai đoạn này và sẽ phát hiện mã sử dụng có an toàn hay không cho điểm vào đó? Nếu như không an toàn thì đưa ra cách khắc phù triệt để và toàn diện. Có thể tóm tắt tất cả quá trình thực hiện như sau:

1) Xác định các thành phần liên quan đến ứng dụng

2) Xác định các điểm vào của ứng dụng

3) Tìm mối liên hệ giữa các điểm với mã nguồn của ứng dụng

4) Xây dựng sơ đồ các mối liên hệ giữa các điểm vào với mã nguồn của ứng dụng

5) Nhận biết điểm yếu và đưa ra cách khắc phục triệt để và toàn diện.

II. Áp dụng

Phần này seamoun sẽ giới thiệu một số công cụ tiêu biểu được sử dụng trong quá trình nhận biết lỗi bảo mật.

1) Application Code Scanning and Tracing tool (Blueinfy-AppCodeScan) có thể tải công cụ miễn phí tại đây (http://blueinfy.com/AppCodeScan.zip )

Sau khi lựa chọn thư mục có chứa mã nguồn ứng dụng Web cần scan thì phải thực hiện lựa chọn rule (lựa chọn các kiểu cần áp dụng cho quá trình scan).

Công cụ này có một tiện ích nhỏ giúp trace code (có thể trace biến hàm). Công cụ này chỉ thực hiện scan mã nguồn dựa trên các tập điểm yếu xây dựng sẵn để nhận biết các điểm có thể gây ra lỗi bảo mật trong ứng dụng Web.

Giới thiệu tấn công Remote/Local Inclusion


I. GIỚI THIỆU

<?php

include(“config.php”);

?>

Đoạn mã trên sẽ chèn nội dung của file config.php. Và có thể thực hiện chèn nội dung động nếu cung cấp một biến như sau:

<?php

include($page);

?>

Lưu ý: Nếu trong cấu hình của PHP (php.ini), register_global mà thiết lập off thì biến $page không được coi như là một biến toàn cục và do vậy nó không thể thay đổi thông qua URL. Và câu lệnh include sẽ phải là $_GET[‘page’], $_POST[‘page’], $_REQUEST[‘page’] hoặc $_COOKIE[‘page’] thay vì $page.

Giả sử trường hợp register_global được thiết lập và lúc này chúng ta sẽ thực hiện chèn trên URL với đối số bất kỳ, khi đó đoạn mã sẽ thực hiện include file mà chúng ta chỉ định, nếu không tồn tại thì sẽ báo lỗi nhưng vẫn thực hiện script. Một hàm khác của PHP đó là require hoặc require_once cũng có tác dụng tương tự như include nhưng nếu xuất hiện lỗi thì script sẽ ngừng. Sự khác biệt giữa include_once và include hoặc require_once và require là ở chỗ require_once hay include_once là ngăn chặn việc include hay require 1 file mà nhiều lần.

Kiểm tra file robots.txt của website và thực hiện kiểm tra thử website đó với file robots.txt. Ví dụ http://www.example.com/page=robots.txt để xem cách ứng xử của server về câu truy vấn này.

Có thể sử dụng Google CodeSearch để tìm kiếm các lỗi về File Inclusion bằng biểu thức chính qui như sau :

http://www.google.com/codesearch

lang:php (include|require)(_once)?\s*[‘”(]?\s*\$_(GET|POST|COOKIE)

II. KHAI THÁC

1. Null-Byte

if (isset($_GET[‘page’]))

{

include($_GET[‘page’].”.php”);

}

Nếu thực hiện index.php?page=/etc/passwd thì khi chèn vào thì nó sẽ là /etc/passwd.php, không đúng như chúng ta mong muốn, do vậy để khai thác và ngắt phần “.php” sử dụng %00(Null Byte), lúc này URL sẽ là index.php?page=/etc/passwd%00. Cách khai thác này chỉ có tác dụng khi magic_quotes_gpc=Off

2. Remote File Include

Nếu trong cấu hình của file php.ini mà allow_url_open=On và allow_url_include=On thì có thể thực hiện gộp file từ xa và trong nội dung file từ xa này có thể chứa các mã độc. Ví dụ

3. Local File Inclusion

Trường hợp mà allow_url_fopen =Off thì chúng ta không thể khai thác thông qua url từ xa, lúc này khai thác sẽ dựa trên local file inclusion. Khai thác local file cho phép chúng ta đọc các file nhạy cảm trên server, ví dụ như là /etc/passwd, /etc/group, httpd.conf, .htaccess, .htpasswd hoặc bất kỳ file cấu hình quan trọng nào.

Ví dụ như có được thông tin từ /etc/passwd, kẻ tấn công có thể biết được các username có trên server và thực hiện bruteforce, nếu kẻ tấn công có khả năng truy cập shadow thì nguy hiểm hơn nhưng /etc/shadow thì chỉ có root mới có khả năng truy cập và đọc được file này.

Ví dụ một số file nhạy cảm mà kẻ tấn công luôn muốn truy cập

a. httpd.conf: Thực hiện đọc file này để có được thông tin về error_log, access_log, ServerName, DocumentRoot, …

b. .htaccess và .htpasswd: Giả sử có một thư mục admin được bảo vệ bởi htaccess thì chúng ta không thể truy cập được các file .htaccess và .htpasswd trực tiếp, nhưng nếu bị lỗi local file inclusion thì có thể đọc và có được thông tin về username và password được thiết đặt ở trong những file này.

c. Khai thác cục bộ

Giả sử có nhiều website trên một server, nếu như site example1.com bị lỗi local file inclusion. Kẻ tấn công ở vị trí là website với domain là example2.com cũng cùng một server với example1.com thì có thể khai thác site example1.com này thông qua như sau:

d. Khai thác sử dụng Log Files

Chuyện gì sẽ xảy ra nếu chúng ta đệ trình với URL như sau

Tất nhiên site sẽ thông báo lỗi bởi vì file <? echo phpinfo(); ?> không tồn tại, và khi đó trong error_log của Apache nó sẽ lưu thông tin về lỗi này như sau

192.168.1.14 – – [15/Jul/2009:17:54:01 +0700] “GET /demo/index.php?page=%3C?%20echo%20phpinfo();%20?%3E HTTP/1.1” 200 492 “-” “Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090624 Firefox/3.5”

Như vậy trong file log đã encode URL mà chúng ta đệ trình, do vậy chúng ta cần phải gửi request với đoạn code sau:

<?php

$res = ”;

$fp = fsockopen(‘127.0.0.1’, 80);

if(!$fp){

echo “No connection”;

}

fputs($fp, “GET /demo/index.php?page=<?php echo phpinfo();?> HTTP/1.1\r\n”);

fputs($fp, “Host: 127.0.0.1\r\n\r\n”);

while(!feof($fp)){

$res .= fgets($fp, 128);

}

echo $res;

?>

Sau khi thực hiện gửi request với đoạn mã như trên, thì hệ thống log sẽ ghi vào file log và chúng ta có thể thực hiện khai thác bằng cách:

Như vậy với việc đệ trình URL trên nó sẽ thực thi lệnh có trong file log

e. Đặt PHP Script trong file JPEG

Trong file jpg thì có phần Exif là phần đầu của file ảnh JPEG, mà nó ghi thông tin về, độ phân giải, ngày tạo, comment, … chúng ta có thể thực hiện chèn PHP script vào phần comment của file JPEG bằng công cụ jhead như sau:

./jhead –ce hack.jpg, nó sở mở vi cho chúng ta soạn thảo phần comment cho file JPEG, ở đây ta lưu comment với nội dung là <? phpinfo(); ?>. Và thực hiện upload ảnh lên server, nếu như server đó bị lỗi local file inclusion thì có thể thực hiện http://www.example.com/index.php?page=hack.jpg, khi đó mã PHP trong hack.jpg sẽ thực thi.

f. Lỗi trong khi sử dụng các script để lưu log

Ví dụ một đoạn mã sau lưu tấn công SQL Injection

<?

$REQ = print_r($_REQUEST,true);

$ip = ‘IP: ‘.$_SERVER[‘REMOTE_ADDR’];

$time = ‘Date: ‘.date(“d.m.y – H:i:s”);

$ref = ‘Referer: ‘.$_SERVER[‘HTTP_REFERER’];

$browser = ‘Browser: ‘.$_SERVER[‘HTTP_USER_AGENT’];

if(eregi(‘UNION’,$REQ) && eregi(‘SELECT’,$REQ)){

$fp = fopen(“attacks.txt”,”a+”);

fwrite($fp,”$REQ\n $ip\n $time\n $browser\n $ref\n”);

fclose($fp);

header(‘Location: http://www.google.com&#8217;);

}

?>

Khi đó mọi hoạt động tấn công SQL Injection sẽ được lưu ở trong file attack.txt, tuy nhiên nếu kẻ tấn công đệ trình với URL như:

UNION <? phpinfo(); ?>. Khi đó trong file log sẽ chứa thông tin về Reference và lúc này nếu server bị lỗi local file inclusion sẽ thực hiện được đoạn mã PHP với đệ trình sau:

http://example.com/index.php?page=attack.txt

g. Thực hiện PHP Code trong file /proc

Mỗi tiến trình có một file trong thư mục /proc mà dùng để giao tiếp giữa kernel và user, tương ứng với mỗi thư mục mang số hiệu PID của mỗi tiến trình sẽ lưu thông tin về mỗi tiến trình mà nó thực hiện. Và có một file /proc/self/environ lưu thông tin về cấu hình mà nó đang hiện hành thực thi trên file mà không cần quan tâm PID. Do vậy nếu sử dụng Firefox để mở thì nó sẽ hiển thị thông tin liên quan đến Browser như là HTTP_USER_AGENT và HTTP_REFERER. Khi đó nếu website bị lỗi thì có thể thực hiện thiết đặt có chứa mã PHP và thực hiện gộp file để thực thi mã PHP

http://example.com/index.php?page=/proc/self/environ

III. PHÒNG CHỐNG

Sử dụng hàm file_get_contents thay vì include đối với log bởi vì lúc này nó chỉ đọc nội dung của file mà không thực thi ngay cả đối với file php. Vô hiệu hóa hàm eval() trong PHP. Kiểm soát việc sử dụng require và include. Sử dụng đường dẫn tuyệt đối hơn là sử dụng .. hoặc / . Thiết đặt allow_url_fopen=off để chống RFI khi đó hàm file_get_contents cũng vô hiệu hóa theo đối với phiên bản PHP cũ < 5.2.0. Nếu sử dụng PHP 5.2.0 thì thiết đặt allow_url_open=on nhưng allow_url_include=off, và thiết đặt register_global=off và thậm chí thiết lập display_errors=off