Bankrobber

Thanks for the box @Gioo !
Really liked user part and learned quite a lot. Root is good but not being able to restart the app is not so good. Anyways: Cool! Cool! Cool!

For root don’t put too many chars once you got the idea

I really enjoyed the ides of this box but the implementation seemed buggy. I learned a lot from user on this box, root not so much. I had to reset the box twice on that last step as I managed to get in to a state where it no longer responds. Waiting for that timer’s first tick after a reset is something i never want to have to do again.

Type your comment> @jimmypw said:

I really enjoyed the ides of this box but the implementation seemed buggy. I learned a lot from user on this box, root not so much. I had to reset the box twice on that last step as I managed to get in to a state where it no longer responds. Waiting for that timer’s first tick after a reset is something i never want to have to do again.

100% quoted

I don’t understand this machine. I have send the same payload like 20 times and got 4 responses 3 minutes later… This does not make any sense!
How should i be able to get RCE without knowing which payload succeeded, because of the delay?

Edit: It works now. Still sort of unrealiable, but some minor changes to the payload made it more stable.
Got user! Now onto root! :slight_smile:

Edit2: Got root. This was way too easy! Not a easy machine, but definitely not insane.

Just completed. I have this bad feeling that it took me way too much time than it should. I stuck a few times in places I should not. Mostly due to my stupid mistakes and sloppiness. This is another lesson that we should always stay humble and very watchful.
Overall the user part was IMHO basically great. Absolutely MUST DO for every pentester and red teamer. I really enjoyed this part. Kudos to the authors! I will rate the box as 5 just for this part.
Root not so much enjoyable, but well … let’s leave it.

There is enough hints in this thread so I will just give a general advice for this box. Do not hesitate using again what you already did use in the past. Keeping this in mind will help you a lot.

Many thanx to @Chr0x6eOs and @AzAxIaL for giving me a hand.

any hint for initial foothold?
already enumerated with dirb, registered as a normal user, but no way on what to do know…

pls help

Type your comment> @sniperhack said:

any hint for initial foothold?
already enumerated with dirb, registered as a normal user, but no way on what to do know…

pls help

give Owasp a visit

I liked this machine because it presented basic web and application vulnerabilities in one and required some python scripting to gain root access. I think it is a good box for teaching basic techniques. Thanks @Gioo & Cneeliz.

Key factor: search typical vulnerabilities and do not complicate the exploits

First stage: User access

First exploit: After login you can test the application. Test it with simple values and notice the response. Based on the response it is clear which type of exploit you should use. This is the typical example in case of this type of vulnerability. You can easily evade the only protection.

Second exploit: Use the output of your previous action. Now you have two potential vulnerabilities to exploit. Both of them are obvious. You can test the first one manually or using a well-known program but no need to move too deep. Just understand the exploit and use it to understand difficulties of exploiting the third vulnerability.

Third exploit: There is a two-level protection to limit your access through the third vulnerability. You can easily evade the first level but the second one seems to be difficult to bypass. Enumerate again - if it is needed - and find a “wrapper”. Use it to create a reverse shell and get the user hash.

Second stage: Root access

If you find the destination of your attack - it is an easy task - and you know how to communicate with it, you need to cope with a two-level protection again. You need to create a script to pass the first level and execute additional manually tests to pass the second level and get root access.

Speaking of the initial foothold, I get that this type of vuln is difficult to simulate, but a key metric for this type of challenge should be the following: can you distinguish between the failure of your payload and the failure of the server? I have spent too much time guessing which is which. We need more of these scenarios, so thank you to @Gioo & @Cneeliz for the attempt. IMHO, in these mock scenarios there should be some regularity, otherwise I spend more time waiting and guessing than learning.

Finally got through some commands. I can see what I need to do I have a command working on a mock system, but the initial foothold is so spotty I can’t tell if the problem is my request or the one of many times the box drops a request. This would be such a good box if it was reliable. I wish I could have the time back that I used guessing whether a request was dropped or was wrong.

Highly recommend skipping this one. It is not difficult, just frustrating.

nvm.

Really enjoyed this box. I understand the frustration with the initial foothold but overall was a fun journey. Thanks!

For user:
Lots of helpful comments on this part. Focus on client side. When looking at b*********.**p remember what the system is when trying to attack and how to smuggle goods in.

For root:
Communication is key find where to communicate. Bruteforce is a good option here :).

Rooted!
The box itself is cool, but quite unstable and definitely not insane.

Guys, I’m totally stuck.
I’m struggling with admin panel. I’m in it and have two input forms.
Of cause I “enumerated” first one and got a lot of creds, including root. But 36 port doesn’t allow my host to get the access.
Second one is code inj, but only from l
t. I tried a lot of header parameters, but it didn’t work. Of cause found ba******ker.php
Can you give the hint where should I move further?
Thanks a lot.

Hi, currently stuck getting user revshell; i can ping me back and list content but anything else doesnt seem to work; can someone pls pm me and give me sanity check

Spoiler Removed

Type your comment> @l4rm4nd said:

I’m stuck with the initial foothold. I’ve already exploited the client side and received some delicious snack. From here, I gained a more privileged access to some functions.

I successfully exploited the first function with a common tool and by hand, using commands like INTO OUTFILE and load_file(). With this I was able to identify the webroot directory + source code of all its files and thought of uploading a webshell. However, it seems that we lack specific permissions to access and execute our created files in the webroot.

Now I am back at client side and the 2nd function. I already know how to bypass the “limitations” of cmd. I’ve also tried some typical HTTP headers to bypass the ::1 limitation. Nothing works, so I guess I cannot skip the client side exploitation here. Since I already got the source code of Bdc*****r, I tested my client exploit locally - which works. Sending it to the victim however fails, it never connects back.

Need help.

Think about how the first exploit has worked. The important question word is Where.

Type your comment

can anyone give me a nudge on the initial foothold? totally stuck here -_-

I’ve been at this for a few hours and the concept is great (it’s been quite fun) but one of the vulnerabilities (the simulated bit) is very flakey - I get these things are hard to implement but man it is frustrating the f**k out of me! :-/