Type your comment> @ion0x0 said:
@malwarepeter said:
something like
root@HTB:~# ls
root.txt
writeup.txt
root@HTB:~# cat root.txt
89djjddhhdhskeke…
root@HTB:~# cat writeup.txt
5hy7jkkhkdlkfhjhskl…And again - writeup hashes are the same for everyone.
yes with my idea… writeup.txt it contain static hash that will be used to unlock any writeups… but root.txt will still be dynamically… problem solved
Type your comment> @ion0x0 said:
One of the problem as well is that writeups are also stored on github.com. I am not sure if they still are, but I saw it like a half year ago. They’re uploaded in a .pdf format, but in order to read you’re prompted to enter password - i.e root flag.
Seems like writeups are going to be removed from github if we go this way. And yeah, it’s good to synchronize writeups only with this site, fairly. Check if a user has rooted a box and give them access to read it. It’s pretty simple, no reasons to make hysterical threads here.
yeah that’s literally the entire point of this thread lol
Type your comment> @malwarepeter said:
Type your comment> @ion0x0 said:
@malwarepeter said:
something like
root@HTB:~# ls
root.txt
writeup.txt
root@HTB:~# cat root.txt
89djjddhhdhskeke…
root@HTB:~# cat writeup.txt
5hy7jkkhkdlkfhjhskl…And again - writeup hashes are the same for everyone.
yes with my idea… writeup.txt it contain static hash that will be used to unlock any writeups… but root.txt will still be dynamically… problem solved
The main problem is that users share root flags with some people, which in turn use these flags in order to open writeups. It can be used by rogues. “You haven’t even started doing the machine, but you have already been given a writeup”.
Type your comment> @ion0x0 said:
Type your comment> @malwarepeter said:
Type your comment> @ion0x0 said:
@malwarepeter said:
something like
root@HTB:~# ls
root.txt
writeup.txt
root@HTB:~# cat root.txt
89djjddhhdhskeke…
root@HTB:~# cat writeup.txt
5hy7jkkhkdlkfhjhskl…And again - writeup hashes are the same for everyone.
yes with my idea… writeup.txt it contain static hash that will be used to unlock any writeups… but root.txt will still be dynamically… problem solved
The main problem is that users share root flags with some people, which in turn use these flags in order to open writeups. It can be used by rogues. “You haven’t even started doing the machine, but you have already been given a writeup”.
well but if that the problem then , their target is to destroy writeups while a machine is active nothing more but if not then a separated writeups hash is the answer
@ion0x0 said:
The main problem is that users share root flags with some people, which in turn use these flags in order to open writeups. It can be used by rogues. “You haven’t even started doing the machine, but you have already been given a writeup”.
I think everyone gets that. It’s clearly stated by HTB. The issue for this thread is how to protect the individual write-ups that people make.
There are lots of legitimate reasons for this and a massive learning value from making the write-up, getting feedback on the write-up and from seeing how other people complete a box.
For some people (me at least), this 75% of the value from HTB. Waiting until a box retires then getting to see how others did it kind of undermines the value, because 3 - 4 months after I’ve attempted a box, I’ve lost a lot of the motivation/memory around decisions.
It also means a lot of people will no longer get any feedback on a box because most people will go for the official write up / ippsec video.
It seems this will kill people trying to legitimately share write-ups for peers but won’t do a thing to people selling write-ups or sharing for other reasons.
Guys, a legitimate way to protect the write ups was already proposed by HTB. Use the hash of the root/Administrator user, meaning the hash of LOGIN password that you would need to legitimately log in to the box, not the hash in root.txt.
For linux boxes, use the hash of the root password. If you are root on the box, just cat out the shadow file and you have it.
For windows boxes, I realized after my last comment that you can use the hashdump command of a meterpreter shell to get the hashes of the Administrator password. If you have root access to the box, you should also be able to get a meterpreter shell going. Although that’s not super practical. Maybe someone else knows a better way?
Having an extra static writeup.txt on the box would be easier and more comfortable, I agree. But at least on Linux boxes there steps you need to take to get a working password aren’t any more difficult than opening a writeup.txt …
Type your comment> @nyckelharpa said:
For linux boxes, use the hash of the root password. If you root on the box, just cat out the shadow file and you have it.
Sorry for breaking your trolling attempt but passwords in shadow file are salted, and not always you can crack them.
Edit: Oh, you said “hash”, I missed it. Sorry, lol. So yeah, that’s better.
Yeah, no need to crack them, just use the hash. Also that is not my idea, it is what the guys of Hack The Box themselves suggest: HTB News | Integrity of Hack The Box
@nyckelharpa read the replies in this thread. Sometimes you get the root.txt file without getting the administrator password hash
{}
@nyckelharpa said:
Guys, a legitimate way to protect the write ups was already proposed by HTB. Use the hash of the root/Administrator user, meaning the hash of LOGIN password that you would need to legitimately log in to the box, not the hash in root.txt.
Like @VbScrub said, this doesn’t solve the boxes where you dont get a root shell or boxes (like RE) where getting Admin / Root creds isn’t the end of the journey.
The problem has no easy solution. The only consistent proof a box has been owned is the root flag. If anything else was consistently usable, we wouldn’t need the root flag in the first place.
@VbScrub @TazWake Yeah, I’ve read the thread. But honestly, do you really think you have completely rooted the machine just because you got the root flag? I don’t. If I don’t really get root and just read out the root.txt somehow, it feels like cheating to me and I’m not satisfied. I also have never done a box here where it was not possible to really root it. I haven’t done RE yet, but if you can get root there… where’s the problem? (And if it’s a problem than it might just be a problem with this specific box)
Maybe it takes a few more steps, sure. But then you also have a bigger learning opportunity. And I think we’re all here to learn how to root machines and not only how to read out a txt file? Granted, I’m still a noob, so things might be different with the difficult machines, but I don’t really see why.
Also, if you find a way to read root.txt… why not just use the same way to read the shadow file? (Again, I realize that Windows boxes are a bit problematic in this regard)
Don’t misunderstand me. I totally agree that having something like a writeup.txt would be way nicer, comfortable, better than the password hash way and it would be cool if HTB would implement it. And I also think that this change wasn’t really necessary. But you make it sound like it’s impossible to publish protected write ups in the meantime, which it isn’t.
Also, has anybods sent a mail to the support/staff with this suggestion? No idea if they are reading this thread here or even the forum.
@nyckelharpa said:
@VbScrub @TazWake Yeah, I’ve read the thread. But honestly, do you really think you have completely rooted the machine just because you got the root flag? I don’t. If I don’t really get root and just read out the root.txt somehow, it feels like cheating to me and I’m not satisfied.
OK, but that is pretty much a personal call. The scope of the engagement is to get the root flag.
I also have never done a box here where it was not possible to really root it.
I have. I’ve done quite a few.
I haven’t done RE yet, but if you can get root there… where’s the problem? (And if it’s a problem than it might just be a problem with this specific box)
The problem with RE (which is retired now) is not that you can’t get NT AUTHORITY\SYSTEM, its that you are still a few steps away from getting the root flag at that point.
This is not the only box like that. It actually makes boxes much more “fun” and teaches people about the extra steps beyond simply rooting a box.
If we are talking about learning and it “not feeling like cheating”, for pentesters, getting root privs on a box is rarely the final goal.
Maybe it takes a few more steps, sure. But then you also have a bigger learning opportunity. And I think we’re all here to learn how to root machines and not only how to read out a txt file?
This is pretty simplistic thinking. The problem isn’t on boxes where it is possible to get a root shell because, on most of these, you dont get the flag until you get a root shell. There are about 20% of the boxes where you won’t get a root shell.
Unfortunately, these also tend to be the boxes where reading how other people have done it carries the most benefit.
So, I agree with you that on the simple boxes where you can get a root shell it is trivially easy to get other things which can be used to unlock writeups. But you probably won’t want them because there isn’t much variation in the path to rooting the box.
See the problem?
Granted, I’m still a noob, so things might be different with the difficult machines, but I don’t really see why.
Other than the boxes which dont let you get a shell?
Also, if you find a way to read root.txt… why not just use the same way to read the shadow file? (Again, I realize that Windows boxes are a bit problematic in this regard)
It depends on the box. Dont forget, box creators constantly try to make them unique and this can lead to esoteric ways to get the flag.
Don’t misunderstand me. I totally agree that having something like a writeup.txt would be way nicer, comfortable, better than the password hash way and it would be cool if HTB would implement it. And I also think that this change wasn’t really necessary. But you make it sound like it’s impossible to publish protected write-ups in the meantime, which it isn’t.
It isn’t impossible and I am not sure anyone said that.
It is impractical and inconsistent though.
It has also led to people on “flag sharing forums” simply sharing write-ups. This kind of undermines the goal.
Also, has anybods sent a mail to the support/staff with this suggestion? No idea if they are reading this thread here or even the forum.
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.
EDIT: Sorry for the double post. In my initial post, the markdown didn’t work for some reason. See my post below where I fixed it. If a moderator sees this post here, please delete it.
@TazWake said:
OK, but that is pretty much a personal call. The scope of the engagement is to get the root > flag.
For me, the flags are just symbols for “I have owned user/root”. If I have not owned root, then why do I have access to the root.txt? But I agree, if it is more difficult to get the root.txt then root access, then it’s of course a different matter.
The problem with RE (which is retired now) is not that you can’t get NT YAUTHORITY\SYSTEM, its that you are still a few steps away from getting the root flag at that point.
This is not the only box like that. It actually makes boxes much more “fun” and teaches people about the extra steps beyond simply rooting a box.
Okay, I was not aware of that and I apologize for my simplistic view. I don’t want to spoil myself and look at a write up of the machine just for this discussion, so I’m sorry that I didn’t directly understand what you said.
However, why not look at it from a different angle:
So what does it matter for your goal of publishing the write up that the root.txt is more difficult to get? Use the password hash and you’re good to go, you’re following the rules etc.
Of course, that leaves room for cheaters to cheat once they have access to the password hash, but not the root.txt. But I think we all agree that cheaters are only cheating themselves, right?
I’m aware that I’m assuming quite a lot here and still, there’s the possibility that the HTB staff might not like that. But what else are we to do, looking at the press release? And if they don’t like this, then they either need to put a different system in place, forbid protected write ups (which I hope they won’t) or live with their proposed solution and its inherent problems.
If we are talking about learning and it “not feeling like cheating”, for pentesters, getting root privs on a box is rarely the final goal.
Of course, this is clear.
There are about 20% of the boxes where you won’t get a root shell.
Again, i was not aware of this and I apologize. But is it truly impossible (or at least
significantly harder then getting the root.txt) to get root access to these machines?
If that is truly not possible/super impractical, then I of course agree that this new method is not well thought through.
Unfortunately, these also tend to be the boxes where reading how other people have done it carries the most benefit.
There is no dicussion from my point here. I completely agree with you and everyone else that much can be gained from studying the way others did the boxes.
It is impractical and inconsistent though.
I totally agree, as I’ve also said before. It’s also an annoyance for everyone who already has published protected write ups of the still active machines before the change.
It has also led to people on “flag sharing forums” simply sharing write-ups. This kind of undermines the goal.
Depends a bit on how you see it. At least the cheaters will have to go through the write ups and at least might learn a tiny bit, compared to just handing in the root.txt. Also it takes more time to create a write up than just publicizing the user.txt/root.txt
So the people that are still cheating are “at least” determined to do so. And there’s the problem: I think there’s no real way around cheaters here. In the extreme case, you could just share your vpn file with someone else, have them do the machine for you and then use the user/root.txt they find using your vpn file.
I believe there is no truly good way to protect against cheaters here. And like it is so often the case, the legitimate users have to live with annoying restrictions, while cheating is still quite easy.
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.
That would be a bummer. As I said, I haven’t been here long. But so far I haven’t seen anything being said about (or against) protected write-ups from HTB directly. I was interpreting the press release in such a way that they do support these write ups…
@nyckelharpa the main issue I have is that the most common place for write ups to be found was the github page, which now says this:
“Machines writeups until 2020 March are protected with the corresponding root flag. But since this date, HTB flags are dynamic and different for every user, so is not possible for us to maintain this kind of system. So from now we will accept only password protected challenges and retired machines”
@VbScrub That is indeed a bummer, but also sounds like the organizers of the github page don’t want to change their system to use the password hashes or are not aware of the option? Or is there any argumentation on their page why they don’t use this new solution proposed by HTB?
By the way, which github page are you talking about? It sounds interesting.
@VbScrub @TazWak Interesting! Have you seen the “Special Note” at the bottom of the page? (GitHub - Hackplayers/hackthebox-writeups: Writeups for HacktheBox 'boot2root' machines) I don’t know when this note was added (must be some time ago though, couldn’t see any changes to that in the last few revisions of the readme.md), but it sounds like the HTB staff is working on directly incorporating the protected sharing of write ups directly in this platform here?
@nyckelharpa yeah i saw that a couple of months ago but the fact HTB didn’t mention that instead of saying we could use the admin password hash (especially in response to my feature request specifically asking for them to integrate this into the site), makes me think this isn’t happening any time soon if at all