Static CSRF Tokens, Dark Marketplace Forums and Salt
I was unsure whether to publish this, I’m no fan of marketplaces on anonymous networks like TOR, especially ones which decide to sell weapons that could harm someone. While this vulnerability is interesting, I don’t think theres any real value to it to which it’s worthy keeping it secret. I have already informed the developer of the forum software but it seems very inactive, the last update was last year and the forum is very quiet. Many forums on the internet must use this particular software that is vulnerable but I came across it through using an anonymous network, TOR. ‘Dream Marketplace’ and ‘Traderoute’ both use this forum software, there are many little parts that I’ve found that are fairly uninteresting but allow you to understand more about the marketplaces (Confirmed environment like version etc.). For now I want to discuss the problems that face accounts using this software. Some notes before I get on with the technical discussion.
- I reported this vulnerability to the author 4 days ago, I’m aware it’s a short amount of time but I’ve reviewed the updates and it seems fairly slow
- Someone weaponising this vulnerability successfully to the point of account takeover would be exceptional
- As the forum software updates, so will the marketplaces, there is no point in hiding something so unexceptional
Most developers would like to stick to OWASP guidelines which is what I’ve decided to refer to in this post. You can check them here. In regards to CSRF tokens, OWASP states it’s characteristics should be:
- Unique per user session
- Large random value
- Generated by a cryptographically secure random number generator.
Interestingly, this is something that the forum software does not have in it’s CSRF tokens. In fact, it has some interesting values concatenated to make it seemingly random. The CSRF values are static, especially when being in the environment of hidden services, on the internet they hardly change and the property which changes the value is easily captured. There is no cryptographically secure random generator, there is no large random value and it is not unique per user session. Hidden services can be specifically affected due to how TOR is designed and how remote addresses are handled.
A user id can be easily derived from the forum software, some hidden service forums don’t allow the viewing of profiles but some do. The user id of the forum software is quite simply an integer which is incremented with each user registration. It can be very easy to understand the total number of users if this is hidden. The variable of $pun_user[‘password’] is the hardest to guess, but if you have enough time, don’t worry you can probably guess this (Hopefully through wordlists or exhaustive bruteforce). What is interesting is that the CSRF token includes sensitive information such as the hash’d password of the specific user, this is not suitably random enough. We’ll come to that later. Finally, a hashed version of a function called get_remote_address(). You may guess correctly that this function is essentially trying to get the correct IP from the user. It utilises PHP global variables that will always return 127.0.0.1 due to how TOR handles communication between client and hidden service. I have confirmed this and all marketplace forums using this software have not changed how this is done. All forums hash passwords simply in sha1. We can now know that due to the concatenation and final hashing of these values, that this is not unique per session and gives us a reasonable chance of having a successful request.
The web application has further issues because it does not use any salt, it simply uses the SHA1 algorithm to hash passwords. Making it far easier to guess the password correctly through possibly hash reverse-lookup (For note: make sure you have a random salt for every single password hash you store). Although many could reference this as the biggest threat I would say that absolutely no salt hash means we can make some really solid guesses in this CSRF vulnerability. We could possibly do some really creative CSRF attacks which in theory would allow you to identify the password. This is mostly due to the fact that we can understand both the ID and the remote address, simply leaving the password hash. Dependent on the target we could peform some form of Known-plaintext attack. Dream Marketplace and many other forums have the feature that allows you to see the amount of online users and the user id of a user, we can use these features to understand if a password is correct for a user, this of course, requires the user to have a session currently which allows one to visit the site logged in.
If a user was to visit a malicious site which bruteforced there password hash to logout, we could verify this by registered online users decrmenting and also the posts that we could correlate to verify. This is something that would require the user id and be fairly confident of the registered users online integer value. Not the most satisfactory. The only thing really keeping these sites safe from CSRF in changing passwords and other POST forms is the referer check that occurs during requests, where sometimes the CSRF token is for some reason not around. HTTP referers are not adequete for internet users although to my knowledge is for TOR, just. You can confirm a user by using a request which uses URL parameters. The logging out of a user. This is why the number of registered users online can be seen as important. But is of course not 100%. A successful logout would mean the password has been correctly lookedup and it can be used to login to the forum and possibly other areas.
Although not the most horrific of vulns, it does show that if market forums are seized, it won’t take a monstrous amount of computing power to gather passwords in the clear too.