Difference between revisions of "SQL injection/Blind/Extraction/Timing"
| Line 14: | Line 14: | ||
:'''By timing these (in seconds) the integer value of the [[ascii]] code of the first character of the database will be attained.''' | :'''By timing these (in seconds) the integer value of the [[ascii]] code of the first character of the database will be attained.''' | ||
| − | This attack can also retrieve varying sizes of data, for example, a full word could be retrieved or a nibble at a time. The time required to perform these attacks can vary, retrieving a full word would take upto 65,535 seconds (18 hours) but would only require a single query per two bytes. A nibble would only require up to 16 seconds per nibble, thirty-two seconds per byte, but requires more requests and is much less evasive. To retrieve a full word the request would be: | + | This attack can also retrieve varying sizes of data, for example, a full word could be retrieved or a nibble at a time. The time required to perform these attacks can vary, retrieving a full word would take upto 65,535 seconds (18 hours) but would only require a single query per two bytes. A nibble would only require up to 16 seconds per nibble, thirty-two seconds per byte (sixty-four seconds per word), but requires more requests and is much less evasive. To retrieve a full word the request would be: |
{{code|text=<source lang="sql"> | {{code|text=<source lang="sql"> | ||
| Line 25: | Line 25: | ||
</source>}} | </source>}} | ||
| − | The advantage of retrieving a nibble is speed, but retrieving a word is much more stealthy (it might take weeks (even years) to complete a single query). | + | This query converts the string to to hex, and takes out the first nibble (up to 0xf), and sleeps for that many seconds, whereas the word query takes the first two bytes (four nibbles). The advantage of retrieving a nibble is speed, but retrieving a word is much more stealthy (it might take weeks (even years) to complete a single query). One SQL query every couple hours is obviously less detectable than one SQL query every 10 seconds, and could easily be mistaken for a random scanner. |
Revision as of 21:20, 19 November 2012
|
If not on a LAN when this technique is utilized, buggy and unpredictable results will be attained. |
This testing is ideal when:
- It is taking place on a relatively low latency network
- There is access to a consistent latency and the remote page has a consistent load time (may not vary by more than 0.5 seconds)
Single byte exfiltration takes less queries to perform the same results, and leaves a smaller log footprint.
- A timer will need to be used to see how long it takes the remote server to serve the page.
Examples of timing-based single-byte exfiltration:
- Exfiltrating the first character of the database name in a single request:
AND sleep(ascii(SUBSTRING(@@DATABASE,1,1))) -- MySQL AND pg_sleep(ascii(SUBSTRING(current_database,1,1))) IS NULL -- PostgreSQL |
- By timing these (in seconds) the integer value of the ascii code of the first character of the database will be attained.
This attack can also retrieve varying sizes of data, for example, a full word could be retrieved or a nibble at a time. The time required to perform these attacks can vary, retrieving a full word would take upto 65,535 seconds (18 hours) but would only require a single query per two bytes. A nibble would only require up to 16 seconds per nibble, thirty-two seconds per byte (sixty-four seconds per word), but requires more requests and is much less evasive. To retrieve a full word the request would be:
id=1 AND sleep(conv(SUBSTRING(hex(version()),1,4),16,10)) |
For a nibble:
id=1 AND sleep(conv(SUBSTRING(hex(version),1,1),16,10)) |
This query converts the string to to hex, and takes out the first nibble (up to 0xf), and sleeps for that many seconds, whereas the word query takes the first two bytes (four nibbles). The advantage of retrieving a nibble is speed, but retrieving a word is much more stealthy (it might take weeks (even years) to complete a single query). One SQL query every couple hours is obviously less detectable than one SQL query every 10 seconds, and could easily be mistaken for a random scanner.
