[sqlmap-users] Fwd: A simple injection case failing
Brought to you by:
inquisb
Menu
▾
▴
[sqlmap-users] Fwd: A simple injection case failing
|
From: Stephen S. <ss...@ss...> - 2013-06-10 19:52:09
|
Hi,
Sorry, I think I was unclear in the last email. I'll try explain it more
clearly.
The result isn't being trimmed to 14 characters, instead, the input
parameter is being trimmed (and for some reason internally, the SQL is
still being constructed to be valid. This is a blackbox test so I'm not
sure of the internals of the script currently).
For example, the following payload into the first parameter: -4230' UNION
ALL SELECT NULL,2
,CHAR(58)+CHAR(106)+CHAR(117)+CHAR(103)+CHAR(58)+CHAR(75)+CHAR(108)+CHAR(101)+CHAR(113)+CHAR(75)+CHAR(89)+CHAR(67)+CHAR(120)
Note the lack of ending ' or --, results in the
response: [{"id":2,"title":":jug:KleqKYCx"}]
To demonstrate that the result itself is not being trimmed, consider either
of these:
-4230' UNION ALL SELECT NULL,2,'A string that is very very long but not
truncated' --
Results in: [{"id":2,"title":"A string that is very very long but not
truncated"}]
-4230' UNION ALL SELECT NULL,2,REPLICATE('test', 50) --
Results
in: [{"id":2,"title":"testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttest"}]
So, it's not the result that is being truncated, rather the input parameter
itself being truncated (perhaps with some internal fix for a quote that
still leaves it vulnerable to SQL injection).
While I understand this constraint of 167 characters for the input, I can
see a program like sqlmap still being able to pull out results with this
limitation. If the query was condensed down to: ' UNION SELECT
0,0,':jug:'+(input/join/anything goes here)+':hor'
there would still be 133 characters that could be used for other things
(like the names of fields and databases for exfil).
I realize that sqlmap might not have the functionality for constraint input
like this, but it seems entirely possible to do it with 167 characters of
input in a lot of cases, so I was checking. I think from the previous email
you thought that the *output* from the request was being constrained, which
I believe isn't the case, so I'm hoping this clears it up.
If there is nothing like this built into sqlmap already, would it be
possible to leverage it to pull out the results where I could manually
specify the query (e.g. I set a flag to be "' UNION SELECT 0,0,* -- " or
similar and it could deal with the request automation and extraction from
the resultant queries?
Thanks,
Stephen
On Tue, Jun 11, 2013 at 7:02 AM, Miroslav Stampar <
mir...@gm...> wrote:
> Hi.
>
> sqlmap has problems, as said, because results are trimmed to 14 chars.
>
> It uses 5 chars for prefix (in this case :jug:) and 5 chars for suffix (in
> this case :hor:) to enclose query result. That leaves 4 usable chars.
>
> We use prefix and suffix because sqlmap has to know where result starts
> and where it ends. Without those marks we can't do our job. And no, they
> can't be any shorter. That's an optimal length found through years of
> development. Previously, we've used shorter ones and there were occasional
> reports of false positives or bad result extraction.
>
> As said, please exploit your case manually.
>
> Kind regards,
> Miroslav Stampar
> On Jun 10, 2013 8:28 PM, "Stephen Shkardoon" <ss...@ss...> wrote:
>
>> Hi,
>>
>> After trying to figure out exactly what's going on, it looks like the
>> input ParameterOne is truncated to 167 characters. It's a blackbox test so
>> I'm not sure how it's producing valid SQL, but I guess my next question is,
>> if an input size is constrained like this, does sqlmap have a mechanism for
>> still working?
>> As long as database/table/field names aren't amazing long, it should be
>> possible for sqmap to exfil data, right?
>>
>> Thanks,
>> Stephen
>>
>>
>> On Wed, Jun 5, 2013 at 9:56 AM, Miroslav Stampar <
>> mir...@gm...> wrote:
>>
>>> Hi.
>>>
>>> That site is trimming results (seems to do it to 14 chars in length).
>>>
>>> For example, request [#32]:
>>>
>>> ParamterOne=-4230' UNION ALL SELECT
>>> NULL,NULL,CHAR(58)+CHAR(106)+CHAR(117)+CHAR(103)+CHAR(58)+CHAR(75)+CHAR(108)+CHAR(101)+CHAR(113)+CHAR(75)+CHAR(89)+CHAR(67)+CHAR(120)+CHAR(113)+CHAR(116)+CHAR(58)+CHAR(104)+CHAR(111)+CHAR(114)+CHAR(58)--
>>> &ParameterTwo=10,11,12,35,61
>>>
>>> can be decoded to:
>>>
>>> ParamterOne=-4230' UNION ALL SELECT NULL,NULL,*:jug:KleqKYCxqt:hor:*--
>>> &ParameterTwo=10,11,12,35,61
>>>
>>> while in response there is:
>>> :jug:KleqKYCxq
>>>
>>> In this kind of cases you'll need to (at least try to) exploit it
>>> manually.
>>>
>>> Kind regards,
>>> Miroslav Stampar
>>>
>>>
>>> On Tue, Jun 4, 2013 at 10:47 AM, Stephen Shkardoon <ss...@ss...>wrote:
>>>
>>>> I have a case that sqlmap seems to be acting weird about. I've ran a
>>>> 'sqlmap.py -u "myhost.com/TestFile.aspx"
>>>> --data="ParameterOne=d&ParameterTwo=10,11,12,35,61" --dbms=mssql --hostname
>>>> --technique=U --union-cols=3 -v 6 --flush-session --fresh-queries -t
>>>> traffic_log.txt'
>>>> Manually injecting with ParameterOne looking like "foo' UNION SELECT
>>>> 1,2,3 -- " works as expected. In fact, in the log, you can see it working
>>>> fine in the case of request #32 and #36. However, sqlmap doesn't "find"
>>>> this issue. Most of the queries seem to be doing something like "foo)
>>>> UNION" instead.
>>>> Is there a problem on my end here, or is sqlmap doing something weird
>>>> or what?
>>>>
>>>> Running sqlmap/1.0-dev-3e0f747 (latest git).
>>>>
>>>> Thanks,
>>>> Stephen
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> How ServiceNow helps IT people transform IT departments:
>>>> 1. A cloud service to automate IT design, transition and operations
>>>> 2. Dashboards that offer high-level views of enterprise services
>>>> 3. A single system of record for all IT processes
>>>> http://p.sf.net/sfu/servicenow-d2d-j
>>>> _______________________________________________
>>>> sqlmap-users mailing list
>>>> sql...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/sqlmap-users
>>>>
>>>>
>>>
>>>
>>> --
>>> Miroslav Stampar
>>> http://about.me/stamparm
>>>
>>
>>
|
