Re: [sqlmap-users] Fwd: A simple injection case failing
Brought to you by:
inquisb
Menu
▾
▴
Re: [sqlmap-users] Fwd: A simple injection case failing
|
From: Miroslav S. <mir...@gm...> - 2013-06-10 20:22:43
|
Hi.
At start I'll repeat that if you look into a traffic file you'll see that
you are getting trimmed output:
:jug:KleqKYCxq
instead of expected:
:jug:KleqKYCxqt*:hor:*
If you combine that with your last message you could come to the conclusion
that output could be trimmed based on non-alphanumeric characters in
response. That's why you are getting
testtesttesttesttesttesttesttesttesttesttesttesttesttesttest..........
without any problems.
Now, I've made some necessary changes so there is no more character ':' in
boundaries. Please update to the latest revision and retry to run sqlmap
now.
##########
These three don't make any sense:
1) *Note the lack of ending ' or --, results in the response*
2) To demonstrate that the result itself is not being trimmed
3) 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.
Results are being trimmed (based on output, not on length). Period.
##########
Please update to the latest revision and retry it again.
Kind regards,
Miroslav Stampar
On Mon, Jun 10, 2013 at 9:51 PM, Stephen Shkardoon <ss...@ss...>wrote:
> 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
>>>>
>>>
>>>
>
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Windows:
>
> Build for Windows Store.
>
> http://p.sf.net/sfu/windows-dev2dev
> _______________________________________________
> sqlmap-users mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlmap-users
>
>
--
Miroslav Stampar
http://about.me/stamparm
|
