Conceal

The process to setup the VPN connection was awesome.

I learned a lot! :slight_smile:

(And I’m still discussing with some mates another options and attributes… cool xD)

For those who are having some fun with that strong:

@LegendarySpork said:
@w0rtw0rt that is fair enough as long as there is some reasonable inferential way to get to the appropriate background information. The maddening part for me is simply not turning up what I’ve needed on google or man pages.

I have no issues with doing plenty of homework. Fortunately folks have been sharing some general references. I still am lost but at least at this point I have stuff to research.

HTB and the box creators get to make the rules but I’m just saying that if you want to keep my interest there has to be at least a viable research path.

PS right now I am working through the mighty waterfowl example network diagram and configuration. Good stuff to know.

I will admit I am a little biased with this particular box because my background is in networking and security architecture. Therefore, I have a lot of background in this kind of stuff (although from the linux side of things, it’s a new ballgame). However, the knowledge you gain from this box would be immensely helpful for either offensive or defensive security specialists because of the literal construction of a configuration. Understanding what’s going on in the engine, so to speak, so that you can know exactly what’s going on.

All this to say is that every single resource you need is out there. There is nothing in the construction of the configuration that is left to chance here. It’s truly not a guessing game. There are definitely ways that are explained to get around things you do not or cannot know. This goes for the user portion and the root portion.

Progress. I installed ALL of the bigbird stuff and then used the relevant start command to fire up the relevant daemon. Am working through the documentation. There are actually some good examples with pictures. Thanks again folks for the pointers.

Rooted…

Unfortunately, this machine will be one of the few boxes I give a dislike, solely because of the terrible vpn setup experience…

Having to spend hours and hours of guessing the correct vpn configuration and learning how to use an obsolete services -which BTW lacks basic documentation- is completely useless for pen testing, unless you are practicing for CCNP security, which I believe HTB is not the right place for.

From the beginning, I had all of the settings correct, expect for one word or even one letter, and it wouldn’t work, and I wouldn’t know why because the service keeps us completely blind.
If it wasn’t for the guys help, I would have never found out why it wasn’t working, even though I had 99% of the configurations correct.

Side note: I believe the priv esc method I used can only run once, and then it wouldn’t work, so the box needs to be reverted in order for it to work again, or a certain process needs to be killed.
This is what happened to me, and it says so in the PoC. But I could be wrong.
Either way, there seems to be more than one way to do it.

In general, if it wasn’t for the vpn setup experience, or at least if the vpn setup was straightforward, this would’ve been a great box, and a great practice for OSCP. But, Alas!

Thanks everyone for the help, and thanks to the box creators for their efforts.

I wanted to root this machine just to downvote it.
Here is why:

The actual entry is just …
EVEN if you are good at networking, it takes good “guessing” to actually connect!
You need to GUESS most of the configurations !
I find this to be a disaster. It is just like bruteforcing, except that, you will actually bruteforce everything?!

Aside from that, once you’re in, user is pretty straight forward.

Root was another guessing game especially with the different VMMs involved. I also realized that there is more than 1 way to get root. So have fun with guessing !

Edit: I don’t hate the guessing game for the root, it is actually pretty realistic. There are at least 3 confirmed ways to get root. So it depends on what approach you take.

guys, check and read carefully every parameter in the man page of s*w ic.conf

@TheJ0k3r said:
guys, check and read carefully every parameter in the man page of s*w ic.conf

there are 1000 parameters any hints on which ones are important ? been 3 days at this config guessing game

@n00kie said:

@TheJ0k3r said:
guys, check and read carefully every parameter in the man page of s*w ic.conf

there are 1000 parameters any hints on which ones are important ? been 3 days at this config guessing game

I’m focusing on the left|rightsubnet params based on the debug output I get when I run i***c start and this link posted here earlier: Troubleshooting — Troubleshooting IPsec VPNs | pfSense Documentation

Guys… remember… You have the ik*-**** output. It is not a guessing game… :slight_smile:

Yes, the parameters are right there. You need to read the man page for i***c.conf to see how to get them into your connection. Edit: Phase2 is another story though.

I can get past the NO_PROP using the ik*-**** output, from what I can tell the issue I’m running into is phase-2.

Yes, phase 2 requires a bit of ‘brute-forcing’. @voncount - as you mentioned the Windows error before, it’s in this case the equivalent of the error you see now on Linux.

I finally managed to make the native client on Windows and the strong bird on Linux behave in the same way. Did the ‘brute-forcing’ on Windows and then confirmed on Linux. With hindsight, it might have been easier to automate on Linux, but I am more familiar with that stuff on Windows.

There is a one parameter with various ‘parts’ that require ‘brute-forcing’.

But while I get a stable and ‘quick’ ‘association’ both of my clients cannot make use of it yet when they fire up the ‘next stage’ of this type of V**. Might be a glitch in the ‘next stage’ config or something fundamental - common to two otherwise very different test systems.

@kekra said:
Yes, phase 2 requires a bit of ‘brute-forcing’. @voncount - as you mentioned the Windows error before, it’s in this case the equivalent of the error you see now on Linux.

I finally managed to make the native client on Windows and the strong bird on Linux behave in the same way. Did the ‘brute-forcing’ on Windows and then confirmed on Linux. With hindsight, it might have been easier to automate on Linux, but I am more familiar with that stuff on Windows.

There is a one parameter with various ‘parts’ that require ‘brute-forcing’.

But while I get a stable and ‘quick’ ‘association’ both of my clients cannot make use of it yet when they fire up the ‘next stage’ of this type of V**. Might be a glitch in the ‘next stage’ config or something fundamental - common to two otherwise very different test systems.

Thanks! I got it on Linux with a bit of help (and discovered mm along the way - thanks schex), though I’m not sure how I’d go back and repeat on Windows. I at least don’t get an error when I fire up that bird on Linux, I guess I should go test that next stage.

@ferreirasc said:
Guys… remember… You have the ik*-**** output. It is not a guessing game… :slight_smile:

Of course, it is not entirely brute force. What you mentioned only gives you 1 unknown. If we needed to bruteforce the info that the tool spits, then it would be something imaginary X20 because there are TONS of combinations. You should also have 3 more things from basic enum. What’s left is completely bruteforce. There is even one thing that (I don’t know how to say this without spoiling) all the fingers point towards the wrong version of the service. Which is why I hated it the machine.

@voncount said:
@kekra said:
Yes, phase 2 requires a bit of ‘brute-forcing’. @voncount - as you mentioned the Windows error before, it’s in this case the equivalent of the error you see now on Linux.

I finally managed to make the native client on Windows and the strong bird on Linux behave in the same way. Did the ‘brute-forcing’ on Windows and then confirmed on Linux. With hindsight, it might have been easier to automate on Linux, but I am more familiar with that stuff on Windows.

There is a one parameter with various ‘parts’ that require ‘brute-forcing’.

But while I get a stable and ‘quick’ ‘association’ both of my clients cannot make use of it yet when they fire up the ‘next stage’ of this type of V**. Might be a glitch in the ‘next stage’ config or something fundamental - common to two otherwise very different test systems.

Thanks! I got it on Linux with a bit of help (and discovered mm along the way - thanks schex), though I’m not sure how I’d go back and repeat on Windows. I at least don’t get an error when I fire up that bird on Linux, I guess I should go test that next stage.

I hope my theories about the next stage are correct. I saw something like a confirmation of that theory in the data you get from a successful ‘association’. But the next post by @Ryan412 about lots of things pointing at the wrong version of something might tell me I should question everything again :slight_smile:

I cannot make it work on Windows either, with and without firewall, with my client in dmz and with ports open on the router, trying all the authentication options for that type of v*n. Assuming I have user pass and key correct, how can I be sure it’s not a problem with my internet provider not allowing that type of connection? Error 789 forever

Oof. Finally have a connection, thanks to some help. Wow. I’m still digesting…

@kekra said:

I hope my theories about the next stage are correct. I saw something like a confirmation of that theory in the data you get from a successful ‘association’.

Follow-up on my own post, so that I don’t mislead anybody. My theories were incorrect - the setup is way simpler than I expected it to be! The alleged info on ‘the next stage’ was actually not ‘from the server’ but merged from a backup conf file I ‘forgot’.

This also explains why it cannot fully work the native client, @voncount and @halfluke

It was an interesting experience so far as I made too much assumptions based on what would be ‘common’ in the Windows VPN world …

Does the rightsubnet config need to include specific protocol/port config?

@xirax said:
Does the rightsubnet config need to include specific protocol/port config?

Yes!