Sr vì màu mè khó đọc
Hôm nay, đi TetCon nguyên 1 ngày. Mình thì ko thật sự hiểu 2 chủ đề Sandbox và Fuzzing.thôi nói chung không phải chuyên ngành mình nên ko ý kiến, dù rằng nghe bảo rất hay
Tóm tắt về cách anh gamma optimize về Blind SQL Injection là thế này.
Dùng find_in_set (về sau thì gamma dùng instr, mình cũng thấy instr hay hơn) để đánh chỉ mục (index). Tức là nếu
select find_in_set('a','a,b,c,d...z'); thì nó sẽ trả về
1. nếu
find_in_set('b','a,b,c,d...z') -> 2 .
........................
Kết hợp với Bit-Shifting, ta xác định là dù kí tự gì thì cũng phải
7 query/char (8 bit, nhưng fix ngay bit cao nhất là 0, vì sao thì mở bảng ascii ra xem). Mình cũng đã code ra cái tool này rôi, nhưng cuối cùng chả xài.
Vậy nếu kết hợp 2 cái này lại thì ta sẽ tối ưu đc gì ?. Nếu ta find_in_set đủ các kí tự printable (kí tự in ra đc) thì là:
abcdefghijklmnopqrstuvwxyz0123456789_!@#$%^&;*()-+=\."\'~`\\|{}[]:; (khoảng trắng nữa nhé) , tổng cộng là
45 kí tự. vậy nếu ta
Bit-shifting cái con số
find_in_set trả về thì max cũng chỉ là
45 là 101101 (Bin) , vậy tối đa chỉ có
6 q/s (query/char), còn đối với các số nhỏ hơn thì lại càng ít hơn.
Okie. cơ bản là thế, vậy anh gamma đã tối ưu nó như thế nào ?. Lúc đầu thật sự mình tò mò, ko biết
1 q/s là ntn. Xem qua thì ý tưởng của a khá hay. Tức là ta không còn dùng bit-shifting để tìm ra giá trị find_in_set trả về. mà dùng chính kĩ thuật Time-based SQLI. Anh ấy cho SQL sleep luôn giá trị find_in_set trả về, tức là sleep(find_in_set(.....)) ,thế tức là anh ấy sẽ xem thằng SQL nó "ngủ" bao nhiêu giây thì sẽ ra giá trị find_in_set -> char cần tìm -> 1 q/s/ Clear ?
Ưu điểm thì:
- Ý tưởng và cách khai thác của anh hay
- khả năng bị detect qua log ko cao. vì chỉ có 1 query/ 1 char. thay vì 6 q/s.
Ok. Theo mình thì ý tưởng là hay, nhưng cách này cũng còn vài nhược điểm dễ thấy như:
- Time-based SQLI phụ thuộc rất nhiều vào đường truyền giữa Attacker-Server
- Nếu giá trị find_in_set quá nhỏ thì lại gây nhầm lẫn. về sau a ấy có fix thêm 1 chút là thêm 4-5 kí tự đằng trước để các giá trị nhỏ ko còn nhỏ nữa (tự hiểu đê
).
- Nếu giá trị find_in_set quá lớn lại ngủ quá lâu, có thể bị timeout bất cứ lúc nào
- Nói chung ý tưởng của anh thì mình thấy là hay và tốt , nhưng giá trị thực tiễn để áp dụng thì chưa cao lắm. nhưng cũng có thể là a đang gợi ý hoặc cho 1 ý tưởng để các bạn có thể suy nghĩ ra cách khác optimize Blind hay hơn
.
Nói chung là thế. Nhưng chưa hết, ngày mai mình sẽ viết 1 bài về Optimize Blind SQLI của mình nghĩ ra. Nếu hội tủ vài điều kiện (đ/k này thì ko quá khó, mình nghĩ 90% site bị Blind SQLI sẽ hội tủ đc điều này) thì chỉ cần 2 query / char . Và có thể query song song , tức là có thể dùng cURL cho chạy 2 query 1 lúc -> ko phụ thuộc vào time-based. khả năng bị detect qua log ko cao mấy vì chỉ có 2 query. tốc độ nhanh. Nói chung mai các bạn sẽ biết chi tiết...
