Hi,
I understand why those examples made it seem like the *output* was being
trimmed, I am quite sure that is not the case.
To demonstrate once again, consider the input to parameter one:
-4230' UNION SELECT NULL,2,':jug:KleqKYCxqt:hor:' --
The output of this input is: [{"id":2,"title":":jug:KleqKYCxqt:hor:"}]
Does this clear it up? The reason the output seemed like it was being
trimmed was that a) the input was cut off at a point where the SQL only
contained those characters, and b) the internal mechanism for making the
SQL valid even if there is a ' by itself (at least, I'm guessing here. I'm
not sure on this mechanism as it is a blackbox test as I said).
The difference between the two examples (the one where it seems cut off vs
not) is of course the length of the input parameters. Here is another
example to show that the input length is causing issues. Keep in mind, the
spaces matter in this example, since they count towards the length:
-4230' UNION SELECT NULL,2
,':jug:KleqKYCxqt:hor:' --
Response: an error
As you can see clearly, even characters such as a space count towards this
input limit to cause an error, which results in the query being truncated
in a place that causes an invalid statement (with the 167 limit, it would
look like "-4230' UNION SELECT NULL,2
,':jug:Kl" which is invalid. If we change this example to
be:
-4230' UNION SELECT NULL,2
,':'--
We get the output: [{"id":2,"title":":"}]
This is of course because the query is now valid, because it does not have
parts cut off in the middle of syntactically important places.
With this information, specifically showing that the output is not cut off,
even with those specific inputs, it should be clear that the output isn't
being manipulated (at least, in the way that it seemed to be from those
examples).
Would like more examples to show you that the idea of the output being cut
off is incorrect if it helps?
Lastly, I really do appreciate the time you're taking to help me out with
this. I'm sorry for doing a poor job of explaining it so far to lead to
this misunderstanding.
Thanks,
Stephen
On Tue, Jun 11, 2013 at 8:22 AM, Miroslav Stampar <
miroslav.stam...@gmail.com> wrote:
> 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 <s...@ss23.geek.nz>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 <
>> miroslav.stam...@gmail.com> 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" <s...@ss23.geek.nz> 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 <
>>>> miroslav.stam...@gmail.com> 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
>>>>> <s...@ss23.geek.nz>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
>>>>>> sqlmap-users@lists.sourceforge.net
>>>>>> 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
>> sqlmap-users@lists.sourceforge.net
>> 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
sqlmap-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlmap-users
