So how do we protect write ups now?

So we have 2 scenarios:

  • Machines which allow extractions of the root \ admin password.
  • Machines which do not allow such extractions.

For the first type it’s easy enough - protect the writeup using the password hash since that’ll remain constant.

For the second type it’ll be harder to solve generally but a quick solution would be either:

  • People who create boxes to agree to put a file named “hash.txt” (or whatever) in the box which will contain the admin\root passwrod hash. – This will require them to be aware of this which might not happen on some boxes.
  • HTB to provide an offical statement requesting box creators to either allow shell to obtain the admin\root user hash (which might impact a lot of boxes) or to add a new file (like I mentioned before).

If what @TazWake said is true:

@TazWake said:
It’s their trainset. They are clear as to the problem they want to solve and believe they have solved it. As far as I am aware, HTB doesn’t really like people sharing protected writeups on live boxes, so I’d be surprised if they took extensive steps to facilitate it.

Then it’d be really difficult to create writeups for certain boxes which might result in one of:

  • Some people being able to get the root\admin password and a majority of people not being able to.
  • No one being able to making writeup for a given box impossible.

If the first one happens (which I believe is inevitable) then in my eyes (disclaimer - also pretty new here so I don’t know how much this actually works) it might constitue a new type of flag which is out of scope of the standard HTB user → root path and might bring a new form of difficulty - again, assuming there is a way (even an unintended one) to gain the root\admin password.

The latest Windows machine Remote is an example of the problem with this btw. You don’t ever get the admin password hash on that machine (you can get a form of it encrypted by a third party program, but you don’t ever need to get the NTLM password hash). There’s also a separate path to root that doesn’t get any password hashes at all and just gets local system access.

Now yes, once you have admin or local system access, you could go and extract the NTLM password hash from the SAM database. But that’s extra (fairly dull) work a lot of people probably don’t want to do when they’ve already got the root flag.

@VbScrub I got the hashes on Remote using the “hashdump” command of meterpreter. Unless its output is not correct, but I don’t really know how to verify that?

And of course, you don’t need the hashes to complete the boxes. But I think the idea behind this is that getting theses hashes is just as easy as getting root.txt if you have root access. Now, we’ve already discussed that it seems like there are machines where this is not the case. And on Windows boxes it does seem quite a bit more annoying than on Linux boxes, were you can just read out the shadow file… (provided you have root access/the machine allows for that)

I’ve never needed to use any metasploit stuff until this point, and I don’t really want to have to start just to get hashes for a write up. But yeah I guess most people won’t have a problem with that

@nyckelharpa said:

@VbScrub I got the hashes on Remote using the “hashdump” command of meterpreter. Unless its output is not correct, but I don’t really know how to verify that?

Its output is probably correct but I dont think many people would bother with meterpreter to root this box. But I suppose the argument is if you want to make a password protected write up you should find more ways to root a box and if you want to read them, you also need to find many ways.

People practising for OSCP may be very reluctant to use meterpreter though and they are the main people making/commenting on and sharing write-ups.

@VbScrub @TazWake Yeah, I also try to avoid using metasploit as much as I can, for the reasons you mentioned (although I’m not entirely againgst it - but since I’ll probably be taking the OSCP sometime in the future as well, I try not to rely on it). And I agree that it’s definitely annoying to take that additional step just for protecting a write up.

It kind of feels that the process will end up being a case of if you root a box in the same way as someone who makes the write-up, you get the read the write-up, but it will be the same way you did it so there isn’t any point.

isn’t there a public HTB API? I notice we have an API key in our profiles. Maybe we could just make a website where people can upload write ups but also let people enter their API key and it uses the API to see which machines they have root for (then allows them to read the relevant write ups)

@VbScrub Something like that would indeed be the best way to go, if HTB doesn’t want to implement something themselves, I think. However, I haven’t looked into the API yet myself. Giving out your personal API key doesn’t seem like such a good idea, though (depending on what exactly you can do with it).

I think the profiles are public, right? And each profile has a list of all the machines/challenges that were done by the specific user. As far as I can tell, it looks like this list is complete and no entries get removed over time. Maybe it would be possible to read that out?

Maybe it would be possible (using the API) to create a site that provides the writeups and user can also connect to the site through the API (we’d probably need some tool for that, then). The site then checks the profile of the user and gives him/her access to all write ups of the machines she/he rooted. Giving out the API key might be simpler, but yeah, need to carefully check first what you’re able to do with it I guess (I don’t really have any experience developing against such APIs, so maybe there’s no risk at all and I’m thinking ahead of myself?)