Penetration Testing Step 3 – Các thể loại SQL injection phổ biến (Part 1)

Tiếp theo nội dung Penetration Testing Step 3 – Dấn thân vào nghiệp chích choác với SQL injection, kỳ này tôi sẽ bàn kỹ hơn về các thể loại SQL injection phổ biến đã giới thiệu trước đó. Vì các nội dung này khá dài nên tôi sẽ phải tách ra thành một số phần. Và trong phần này tôi sẽ tập trung demo minh họa cho rõ thể loại Retrieving hidden data và Subverting application logic.

Cũng lại như các nội dung trước đó, tôi sẽ tiếp tục dựa hơi vô mấy bài lab của ông Portswigger để triển phần demo cho nhanh.

Lưu ý: Trong các nội dung này sẽ có một số chỗ sử dụng Burp Suite. Tôi mặc định cho rằng bạn đã biết cách thiết lập và sử dụng Burp Suite nên sẽ không nói gì thêm. Trường hợp bạn đâm ngang hông vô bài này thì vui lòng xem lại phần giới thiệu Burp Suite trong nội dung Penetration Testing Step 3 – 6 điều bạn nên biết trước khi xài tool khủng Burp Suite.

#1. SQL injection – Retrieving hidden data

#1.1 Thăm dò phản hồi của ứng dụng

Như đã đề cập trong kỳ trước, với dạng này, bạn sẽ có thể thao túng SQL query để database trả về các kết quả mà đáng lý bạn không được phép truy cập.

Xem xét cái trang shopping của bài lab như sau.

Như thấy ở trên, bạn có thể chọn thử một category (ví dụ Pets) và quan sát cái request tương ứng.

Bạn có thể xem với cặp request/response tương ứng trong Burp Suite.

Lúc này ứng dụng có thể đã chạy SQL query để truy xuất thông tin từ database kiểu như sau:

SELECT * FROM products WHERE category = 'Pets' AND released = 1

Câu query này có nghĩa là kêu database hốt tất cả thông tin từ bảng products với category là Pests và loại released = 1 (tương ứng các sản phẩm đã công bố). Cái filter release = 1 này ghi kiểu minh họa đại khái cho bạn dễ hình dung ra vấn đề. Thực tế ứng dụng có thể có sử dụng các dạng thiết lập filter khác để giới hạn người dùng truy cập một số sản phẩm nhất định.

#1.2 Ủ mưu trước khi chọc ngoáy

Với thông tin nhận được ở trên, giờ bạn có thể xem xét các phương án hiệu chỉnh để kiểm tra cách ứng dụng xử lý SQL injection attack. Phương án đơn giản là sử dụng query theo kiểu:

SELECT * FROM products WHERE category = 'Pets'--' AND released = 1

Với query trên, double-dash (“--”) là comment indicator trong SQL, có tác dụng làm cho toàn bộ phần phía sau (AND released = 1) không được thực thi. Việc này có thể dẫn đến câu query sẽ trả về toàn bộ thông tin từ bảng products với categoy Pets bất chấp tình trạng sản phẩm đã được công khai (tương ứng released = 1) hay chưa.

Ngoài ra, bạn cũng có thể mở rộng phạm vi tấn công với cái query cập nhật kiểu như sau:

SELECT * FROM products WHERE category = 'Pets' OR 1=1--' AND released = 1

Với cái OR 1=1 được bổ sung vào, lúc này kết quả query sẽ trả về toàn bộ thông tin từ bảng products, bất kể thuộc categoy Pets hay không.

#1.3 Xơ múi với Retrieving hidden data

Ở trên tôi mới chỉ trình bày diễn biến tâm lý để bạn có thể hình dung rõ vấn đề thôi. Giờ là lúc xắn tay vào việc.

Thực tế, với dạng Retrieving hidden data này, bạn có thể đập vô thẳng vấn đề và hiệu chỉnh cái request để thiết lập nhanh category='+OR+1=1--. Kết quả trả về sẽ kiểu như sau là thành công (với ứng dụng thực tế, có thể bạn sẽ thấy xuất hiện thêm một số sản phẩm mới lạ).

Thông tin cặp request/response tương ứng ghi nhận trong Burp Suite như sau:

Lưu ý: Bạn có thể bật Intercept is on trên Burp Suite để bắt và hiệu chỉnh request. Tuy nhiên, ý tưởng tấn công chỗ này khá gọn nhẹ nên bạn triển luôn trên trình duyệt cho nhanh. Phần sử dụng Burp Suite ở đây chỉ để ghi nhận thông tin cho tiện xem lại sau.

#2. SQL injection – Subverting application logic

Trước hết, tôi cần nhắc lại, với thằng Subverting application logic, bạn sẽ thao túng query để đâm thọc vô quá trình xử lý logic của ứng dụng. Tình huống kinh điển hay gặp là quá trình xử lý đăng nhập. Và mục tiêu của đòn tấn công demo này là cắn xén query nhằm bypass việc cung cấp password xác thực.

#2.1 Lại tung đòn gió thăm dò ứng dụng

Rồi, bơi vô bài lab cụ thể xem thử bạn sẽ thấy vị trí liên quan đến My account như sau:

Bấm vào My account bạn sẽ thấy ứng dụng mở ra trang cho phép đăng nhập. Ở đây, bạn có thể múc thử một nháy với thông tin đăng nhập vớ vẩn như sau.

Một khi bạn submit thông tin liên quan, ứng dụng sẽ chạy query tương ứng kiểu như sau:

SELECT * FROM users WHERE username = 'gamo' AND password = 'incorrect'

Vì thông tin thử nghiệm ở trên là vớ vẩn nên tôi sẽ chỉ nhận lại một câu trả lời lạnh nhạt kiểu như Invalid username or password.

Ở đây, theo phương diện bảo mật, ứng dụng đã xử lý khá chuẩn mực vì méo cho bạn biết là sai username hay password. Việc này có thể sẽ gây khó khăn các đòn tấn công vào quá trình xác thực vì bạn không giới hạn được phạm vi xử lý. Với thông tin phản hồi kiểu này, bạn có thể tiếp tục thăm dò cách ứng dụng xử lý bằng cách tung ra query hiệu chỉnh như tôi đề cập kỳ trước:

SELECT * FROM users WHERE username = ''' and password = 'incorrect' "

Cái query này sẽ tương ứng với thông tin nhập liệu sau:

Ý tưởng ở đây là để coi ứng dụng phản hồi với tình huống cố tình làm phát sinh lỗi ra sau. Và nếu bạn nhận được kiểu thông báo tương tự như sau thì báo hiệu ứng dụng đã đớp mồi, hứa hẹn có khả năng chấm mút.

#1.2 Đòn thử nghiệm thu gọn phạm vi tấn công

Sau khi đã thăm dò nắm địa bàn, bạn có thể bắt đầu thử tấn công bằng SQL comment sequence — như sau:

SELECT * FROM users WHERE username = 'gamo'--' AND password = ''

Ý tưởng của phương án này là cái double dash — sẽ loại bỏ phần AND password = ” tương ứng với điều kiện kiểm tra password nên có thể cho phép bạn login thành công mà chả cần biết password. Phần nhập liệu tương ứng ở trang login như sau:

Thông tin cặp request/response tương ứng trên Burp Suite như sau:

Kết quả nhận được không khả quan lắm, vẫn là Invalid usernamer or password.

Tuy nhiên, trong cái khó ló cái ngu. Ở đây, nếu để ý, bạn có thể nhận ra vấn đề là ở username, không phải password nữa do bạn đã thủ tiêu điều kiện password với double dash. Như vậy nhiệm vụ của bạn bây giờ là tấn công dò tìm cho đến khi múc được một cái username có tồn tại trong database.

#1.3 Tung đòn kết liễu để Bypass authentication

Hiển nhiên ở đây bạn có thể dò tay bằng cách thử đâm lần lượt từng nhát username vào trang login trên trình duyệt. Tuy nhiên, phương án đó chỉ nên dùng nếu bạn rảnh rỗi quá không biết làm gì khác. Giải pháp hợp lý hơn là sử dụng Burp Suite Intruder để dò tìm username như tôi giới thiệu trong nội dung Penetration Testing Step 3 – Bắn tỉa mục tiêu với Sniper attack  của Burp Suite Intruder.

Vì nội dung demo hôm nay là SQL injection nên tôi sẽ tua nhanh qua phần xử lý Burp Suite và đi đến luôn chỗ kết luận cái username chuẩn cmn mực là administrator (bạn có thời gian thì quất thử lại xem thế nào). Và với thông tin đó, bạn có thể chích tiếp một nhát SQL injection tương ứng như sau:

Thông tin cặp request/response tương ứng trên BurpSuite như sau:

Và tada!!! Bạn đã chui tọt vào ứng dụng với quyền admin dù chẳng biết thông gì liên quan đến password sất.

Tóm lại, nếu có thể khai thác SQL injection thành công, bạn đã giảm tải một lượng công việc đáng kể cho quá trình dò tìm password. Tuy nhiên, bạn cũng cần lưu ý, ứng dụng thường sẽ có thêm tính năng account lockout để khóa đăng nhập khi bạn nhập thông tin vớ vẩn quá nhiều lần (ví dụ 3 lần). Do vậy, công việc thực tế của bạn nó không nhẹ nhàng như bài lab này đâu.