PwnBox is a recent new feature that is added by Hackthebox, which provides user a virtual parrot instance which carries all the pre-installed tools, terminal for pentesting purpose .
According to HTB, it is providing this facility to every user by creating their own unique instance with having username=htb- & password=random alphanumeric series with 8 characters.
I think the pwnbox feature is suffering from Information Exposure through query strings bug in URL as the service is passing sensitive password information to parameters in the URL.
DETAILS
The password of your Instance can be seen in view instance details
And when you open the desktop of your instance then you will notice that the password of instance is passed to parameters in at the end of URL in the format like- https://vnc.htb-cloud.com/index.html?host=proxy-in.htb-cloud.com%2Fbird%2Fhtb-pw02yuukr0.htb-cloud.com&password=1a2s3dFG
This could allow attackers to obtain access to your instance and disturb the activity in process
I think that showing of password in an open manner is nothing but a security Hole , and if you try to execute the same on your own then you will find that atleast the password of ur instance could have been delivered through POST request in an encrypted manner so that it can’t be exposed so openly in the search bar.
I think that showing of password in an open manner is nothing but a security Hole
Often yes. Lots of technologies work with plaintext passwords though.
, and if you try to execute the same on your own then you will find that atleast the password of ur instance could have been delivered through POST request in an encrypted manner so that it can’t be exposed so openly in the search bar.
An un-encrypted POST request isn’t exposed URL bar either.
As @sparkla has said, this is probably something best raised directly with HTB. I’d suggest raising a JIRA ticket to see if they will remediate it. I dont know if HTB has a bug bounty program but they do seem to give out badges to people who find mistakes.
However, I would also suggest getting into the practice of adding detail. For example if you were submitting this to a non-technical organisation, it is rarely sufficient to say “you shouldn’t expose passwords in a GET request.”
For better or worse, people (pentests, bug bounties etc) want you to explain why it is bad, give examples of what could happen and make them fully understand the issues and risk.
It’s worth seeing if you can message ch4p, egotistical, egre55, felamos, diogt, Roadrunner or Cry0l1t3
Picking up on the tips @sparkla has given though, it’s worth having an idea why the password (*) is a problem over a TLS connection.
For example, if the risk is that a 3rd party can intercept the traffic, it would help if you have an idea of how the interception would take place, where the attacker would be situated and what compensating controls might exist.
At the very least, this is awesome practice for pentests.
(*) it’s more a token than a password as it appears to be randomly generated each time. In the “authentication factors” scale, I’d describe it more as “something you have” rather than “something you know.”
EDIT: Nevertheless it’s best practice not to add passwords to a visible URL, I give you that. Which raises the question for me, is that link actually visible in the browser bar or is it just sent via like XMLHttpRequest as a REST endpoint call?
As far as I can see (big caveat) it is part of the GET request and visible in the browser URL bar. It doesn’t appear to be sent as a REST API thingy.
