Error checking for time based blind

[arnimr]

Hello,

first: thanks for that great tool, awesome!

I'm experiencing some wrong characters received (printable) from a really slow web/db-server with time based blind, e.g. the table name would be "admin_uLers". That could probably be fixed quite easy and without costing additional time, if everything is ok. The idea would be:

• after receiving the whole string, send one more query like "is this string correct?"
• if yes, fine, we didn't have to wait X seconds
• if not, feed the wrong string in output prediction and try again

luxury would be to have the output prediction continue after the 1st wrong character.

bye
arnim

[stamparm]

We are already doing a verification per character. So, after all bits of one character are received, check for the whole character is done via one extra request. This works pretty ok (out of the sight of a user itself), but thing is that also the verification itself is prone to "network lags" -> there is no definite way how to defend against network lags as the verification itself will eventually fail (as in your case)

[arnimr]

Yep, should be exactly as you describe. The problem is, that with the table names it's quite easy to spot the error in e.g. admin_uLers, but if one character is off in a password-hash, it's probably impossible to spot. Double checking the whole string would be nice.

[stamparm]

Is there a possibility from your point of view that checking for an OK string invalidates it all together?

[arnimr]

Don't know what you mean exactly, but anyway I came up with an even simpler solution: for the final checks of the retrieved characters, increase the sleep time by 5 seconds. That's not perfect either but should solve most problems. If the character is right, nothing is lost. If it's wrong, I'm more than happy to wait those 5 additional seconds to be sure, that I don't get a wrong char. (actually in those 6 sha1-hashes I dumped was one g and one q and probably some more wrong inside the hex range. didn't matter in the end because of the 6 cracked fine to a rockyou.txt-password ;)

[berney]

I'm finding frequent errors, and it seems there's no easy way except --fresh-queries to get the correct names, and then I think the incorrect names would still be in the session.sqlite saved data.

I think checking the whole name, even though each byte is checked as it's determined is a good idea, it's one extra query per table. If the whole name check comes back as failed perhaps the name can be split in half and each half checked, etc. to do a binary search for the error, if both halves come back with no errors then it could be deemed the failed whole name check was a false negative due to server/network lags. Each additional check that comes back verifying the old checks makes in more statistically probable that the answer is correct.

I think it's important to get the correct names, as later enumerations, such as schemas, column names, row counts, etc. depend on the table name being correct.

If people don't desire the extra reliability, perhaps this feature could be have an option to enable (or disable) it.

Another idea is to spell check the names, or components of the name after splitting them on underscores ('_') etc. and to also check the components against other components already enumerated. For example if there are 127 tables and 99 so far enumerated have "dbo" as the schema and one comes back as "djo" it's likely an incorrect bit due to the lag (the bit was wrong, and then the byte check also wrong, so it takes lag twice to occur - if the above idea of whole name check was done it would take 3 bit flips which is even less likely to occur).

Alternatively perhaps some hamming code can be used or something to get more reliability.

Finally an option for the user to be able to instruct sqlmap to enumerate that table name again would be good, say you suspected "bddress_book" is incorrect, suspect it should be "address_book", you should be able to say sqlmap --tables --recheck -T bddress_book and it will go the enumeration again and hopefully find "address_book" as the name, or if it comes back as "bddress_book" again there is more certainty that this unexpected name is in fact correct. The idea being the --recheck option would be used for all/any elements not just table names depending on what options it is combined with.

[stamparm]

@berney just one stupid question. As you probably don't know there is already a validity check per character. It obviously fails in certain situations (network lags). How in your perfect scenario would you distinguish if a validity check for a word is actually a TRUE response or just a network lag. You are actually potentially sacrificing a perfectly valid word in case of a FALSE response for a validity check. I am closing this down because you don't understand the matter enough

[berney]

I know there is already a validity check per byte. I don't think you read my comment properly, as I said "I think checking the whole name, even though each byte is checked as it's determined is a good idea".

I also read you earlier comment about further checks also being vulnerable to the same lag and proposed and algorithm. For distinguishing if a validity check for a word is actually true versus network lag, I proposed that the if the whole word check fails the word is split in half, and each half checked (so 2 more queries if the whole word check fails), if these 2 pass then presume the whole word check failing was a false negative - i.e. the word is actually correct).

By doing redundant checks, each redundant check is adding more certainty that the value is correct and not corrupted due to network or server lag.

[stamparm]

Then why don't you just use a high value for --time-sec? That's also a form of redundancy. Also, checking half and half of word is a perfect nonsense as in case of a VALIDITY MISS you are invalidating a perfect word

[berney]

My understanding is that --time-sec sets the delay time, for example as in WAITFOR DELAY '0:0:x', making it higher means network/server lag is less likely to cause invalid inferences (lag needs to spike above the time-sec delay). If my understanding is correct, --time-sec, does not provide any redundancy. The byte-check in getChar that calls validateByte and then increments timeSec provides redundancy.

The OP suggested a 2nd redundancy check, which I'm backing. Regarding the validity miss problem, my proposal is that each time a validity check fails, you halve the length you are checking, until it's down to a byte, and then you getChar that byte again (in the case that checks keep failing). If the failures are due to lag, the subsequent checks are more likely to pass, in which case it's presumed the failed check was a false negative and the value is actually correct, so the perfect word is not invalidated.

In the current implementation, if a 1 inferred bit of the current char is wrong due to lag, the inferred character is wrong, if the byte check is wrong due to lag, then this incorrect value is used. If there are 8 checks one for each bit, plus 1 additional to check the byte, there's 9 checks per byte. If there's 2 bit-flips in 9 queries due to lag the incorrect value will be inferred.

The OP proposed 1 additional check for the table name, which I'm backing. For a 10-byte table name currently there would be 90 queries, OP proposes 91, I propose 91, if that 91th query comes back bad, then do 2 more, if they come back good then keep the table name as discovered, for each that comes back bad do 2 more until either both halves checked come back good, or a byte appears bad, getChar that byte again.

So if all bytes are inferred correctly and the word check is a validity miss, 2 more queries are done, and they are hits, you have 93 queries to get the same end result, and over head of 3 queries.

If one byte is incorrect, and the whole table name check finds it, further queries narrow it down to bytes 5..9, then to bytes 5..7, then to bytes 5..6, then to byte 6, getChar on byte 6. Check whole table name again. This added redundancy recovers from spurious errors due to lag spikes. The redundant checks improve the certainty that the inference is correct.