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

Tiếp theo nội dung Penetration Testing Step 3 – Các thể loại SQL injection phổ biến (Part 2), kỳ này tôi sẽ bay vô phần demo minh họa để làm rõ các nguyên lý với Union Attack đã giới thiệu trước đó.

Lưu ý:

• 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;
• Trong phần demo kỳ này, bạn có thể thao tác chỉnh sửa Request trực tiếp trên Browser. Tuy nhiên, để việc thu thập, đánh giá thông tin và bố trí các đợt tấn công hiệu quả hơn, tôi sẽ ưu tiên sử dụng Burp Suite. Phần sử dụng Browser chủ yếu tôi dùng để minh họa thêm cho rõ các nội dung;
• 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.

#1. Xác định số cột để triển SQL injection UNION attack

Rồi, tôi vào việc ngay luôn cho máu. Sau khi bơi vào giao diện của mục tiêu, bạn có thể thử chọn một Category vớ vẩn nào đấy.

Ví dụ tôi chọn Gifts thì thông tin cặp Request/Response ghi nhận sẽ kiểu như sau.

Sau khi nhận hàng ở HTTP history, tôi chuyển cái Request này sang Repeater để tiện bề thao túng. Như đã trình bày trong kỳ trước, bạn có thể sử dụng NULL để thăm dò số cột. Cụ thể, bạn có thể đút thêm '+UNION+SELECT+NULL-- vào sau cái chỗ category=Gifts như bên dưới.

Lưu ý: Nếu không biết Burp Suite Repeater là gì thì bạn có thể xem thêm nội dung Penetration Testing Step 3 – Thủ thuật chọc ngoáy HTTP/WebSockets message với Burp Suite Repeater.

Với nhát thăm dò đầu tiên, bạn có thể thấy thông tin trả về là Internal Server Error. Với cái Respone này, bạn có thể thử tăng thêm một cái NULL nữa để tiếp tục thăm dò theo kiểu '+UNION+SELECT+NULL,NULL--.

Ở phát thứ 2, bạn có thể tiếp tục ghi nhận Internal Server Error trong Respone. Do vậy, ý tưởng là tiếp tục tăng thêm cái NULL cho đến khi ghi nhận có sự  khác biệt.

Như quan sát ở trên, với bài Lab này, với 3 cái NULL bạn đã nhận được status code 200 – OK, hàm ý cho biết số lượng cột tương ứng là 3. Như vậy bạn đã hoàn thành xong yêu cầu thứ nhất trong công cuộc chuẩn bị cho SQL injection UNION attack.

#2. Xác định cột tương thích dữ liệu dạng string cho SQL injection UNION attack

Sau khi đã xác định được số lượng cột, bạn sẽ bắt tay vô công đoạn kế tiếp của mưu đồ tấn công – đó là xác định xem cột nào tương thích dữ liệu dạng string.

Để triển phần này, bạn có thể mò mẫm theo nguyên lý sau: Lần lượt thay đổi giá trị NULL bằng một string đại khái nào đó (ví dụ ‘HIDZXO’ trong ví dụ bên dưới) cho đến khi nhận được status code 200 trong Respose trả về. Khi đó bạn sẽ có thể xác nhận cột tương ứng với cái string vừa đút vô sẽ tương thích với dữ liệu dạng string.

Như kết quả quan sát được ở trên, bạn có thể xác nhận cột thứ 2 sẽ tương thích dữ liệu dạng string. Và như vậy, bạn đã mần xong luôn yêu cầu thứ 2 để chuẩn bị cho SQL injection UNION attack.

#3. Bắt đầu cào hốt dữ liệu với SQL injection UNION attack

Sau khi đã xác định được số cột cũng như cột nào tương thích với dữ liệu dạng string, bạn có thể bắt đầu chuyển qua chấm mút với SQL injection attack.

Ví dụ, với bài Lab bên dưới, tôi xác định được số cột là 2. Đồng thời cả cột thứ nhất và cột thứ hai đều tương thích với dữ liệu dạng string. Kết quả xác nhận tương ứng với cặp Request/Response như sau.

Với nội dung đã xác nhận như trên, bạn có thể bắt tay vô việc chọc ngoáy để thu lượm dữ liệu. Và thông thường, thứ khiến bạn thèm muốn nhất sẽ dính líu đến thông tin đăng nhập vào hệ thống. Thực tế quá trình mò mẫm, đâm thọc này có thể đòi hỏi nhiều phương án thử nghiệm nên việc sử dụng Burp Suite để hỗ trợ là một lựa chọn hợp lý.

Quay trở lại vấn đề chính, trong khuôn khổ của bài Lab, sau khi thăm dò một số nội dung, bạn sẽ có thể phát hiện ra việc tồn tại bảng users trong cơ sở dữ liệu với 2 cột lần lượt là username và password. Khi đó, cái Request để tấn công (sử dụng '+UNION+SELECT+username,+password+FROM+users--) và Response chứa đựng kết quả thu lượm (thông tin username và password) được sẽ có kiểu như sau.

Bạn cũng có thể chạy lại Request trên Browser để quan sát kết quả thu lượm tương ứng.

Để xác nhận hàng thu được là chính hãng, bạn có thể truy cập đến trang Login và sử dụng để đăng nhập thử.

Nếu kết quả nhận được kiểu như sau thì bạn đã thành công rực rỡ.

#4. Hốt dữ liệu với SQL injection UNION attack khi kết quả thu từ query chỉ nằm trong một cột

Ở Mục 3, bạn có thể quan sát thấy kết quả thu từ query được đẩy vô tương ứng cho 2 cột username và password. Nếu gặp tình huống khi kết quả chỉ đẩy vào trong một cột thì lúc này bạn có thể xem xét sử dụng string concatenation operator (ví dụ || cho Oracle database) và ký tự đặc biệt để làm dấu hiệu phân tách các dữ liệu đã kết hợp lại (ví dụ ký tự ~).

Quay trở lại nội dung demo, tương tự như Mục 3, đầu tiên bạn cũng sẽ cần xác định số cột và cột nào có dữ liệu tương thích với dạng string theo kiểu tương tự như sau.

Kế đến, bạn cũng sẽ có thể tung payload để húp thông tin từ bảng users theo kiểu '+UNION+SELECT+NULL,username||'~'||password+FROM+users--.

Kết quả như bạn có thể thấy ở trên, username và password đã được kết hợp lại và phân biệt nhờ ký tự ~ như ý đồ thiết kế. Tất nhiên, bạn cũng có thể thử chạy Request trên Browser và quan sát kết quả tương ứng.

Sau đó đăng nhập lại để xác nhận thông tin hốt được là chuẩn cmn mực.

Phù! Đến đây coi như tôi đã xong phần múa lửa minh họa rồi đấy. Tôi hy vọng phần demo minh họa kỳ này đã làm rõ phần nguyên lý trình bài trong kỳ trước. Và cũng như mọi khi, tôi cũng muốn nhấn mạnh lại một lần nữa là các bài Lab được thiết kế để bạn “dễ ăn” nhằm nắm bắt ý tưởng chính. Thực tế quá trình tấn công có thể sẽ phát sinh nhiều vấn đề làm bạn đổ mồ hôi, sùi bọt mép chứ không nhẹ nhàng tình cảm thế này đâu nhé.