After my previous post I’ve been thinking about the next step,
should I start a series where I implement all OWASP TOP10
vulnerabilities and then break them?
It could’ve happened, but I decided to try myself at hackthebox.
I had an account for almost 2 years, and all I had was 2 user owns in the last two months
(which were so basic), and a couple of challenges done. A good first box seemed to be
SwagShop, simply because I like earning stickers, and I thought this one would be cool
(don’t worry, no spoilers here).
Long story short, after rooting SwagShop I just kept going and rooted another 3-4 boxes, in the span of 3 days.
It was a wild ride, tons of new things to learn, same amount of frustration, but when
I got the flag, it was all worth it - in fact it felt so good, I immediately forgot about
the hours of staring at the screen murmuring
it can’t be that, it just doesn’t work
I’ve went from noob rank to hacker during this time, so I thought it’d be good to capture
what I thought during these few days, what I liked, what were the challenges that I faced, and so on.
The Bad
Enumerating non-web related services (like smb shares, rdp)
I come from a software development background, and more specifically, I’ve been writing software for the web.
This makes it easy for me to have a solid guess of the service if I see ports like 80, 8080, 3000, 3306, 5432 etc - but when nmap returned something like 445 - I had no idea what it was.
In fact this was the first time I’ve explored SMB following this handy guide by @pry0cc .
To ease my own pain, I’ve bookmarked a Wikipedia article that I can use as a reference.
Looking at code requires a totally different mindset
At work we do a lot of pair programming (the bane of my existence) and whatever’s left is reviewed.
If you’ve ever worked as a developer in a team, you know that there are many things to check,
code styling, design patterns, architecture, etc - but this is different, and I had to make that switch.
One of the boxes had some source code online that contained key information of rooting the box. After spending
a good chunk of time on it, I already came up with many points, but none of them were relevant!
The important bit is to read the code and think about what the dev(s) could’ve missed,
if they forgot to catch an exception, or clean up some temporary data 
.
This was one of the hardest changes I had to make so far, but one of the most enjoyable ones.
Off by one errors
I mean, we’ve all been there right?
Can you spot what’s wrong with some_command /root/rot.txt? I couldn’t - it was embarrassing.
I cooked up a real cool python script, but did I mess up the operator and used + instead of -? Yes, I totally did.
I’m still thinking about this - but probably for my own scripts, I’ll to stick to TDD - it’s one of the things
that worked really well for me in the past, and I think it’d help me to write more reliable scripts.
The Good
Reimplementing a CVE
What I’ve found to be an absolutely good way to spend my time is to look at an exploit, and then keep rewriting it,
so that a proper script is the end result. The one you can show in your GitHub profile, the one where if you need to make some changes or reuse it on another
service, it’d be a pleasure to do so. It’s also great for learning more in depth about the vulnerability you’re exploiting.
Automate as much as possible
When I first tried SwagShop there were constant resets, and brute forcing attempts, making it hard to even enumerate, let alone proceed.
It👏 was👏 utterly👏 frustrating👏.
Once the box was a bit more stable, I decided to design myself a workflow,
so that I could get back to the part where I was without much effort.
This worked wonders for me in other boxes as well - every time I was in the middle of something and the machine got reset,
I could get back in within a minute and continue where I left off.
For certain boxes this can be as simple as recording the passwords you’ve already obtained, but if you need to do something
in order to get access, I encourage you to automate that bit.
The Ugly
Writing code
I’ve tried - I really did - to write all my scripts in nano/vim/emacs whatever. I just couldn’t bring myself to it.
I’ve been spoiled by great IDEs that’ll tell me how wrong I am, and offer rich refactoring functionality just to mention a few.
I felt like I spent more time doing tasks that are just a shortcut away in my daily work, so I went back to using the IDE for writing scripts.
Applying dev principles
One of the most useful principle I’ve used is to go as slow as possible. I could’ve shaved a few hours off from certain boxes, all I had to
do is just to download a file, run it, 
shell… but I didn’t.
If you go slower, you’ll find more things when enumerating, you’ll better understand the problems at hand, and you’ll have a better chance
of remembering the things you’ve done, as opposed to just doing a quick hit and run. I think if you’re not having fun during these boxes, it might
not be worth doing them anyway.
Closing notes
I really enjoyed learning so many new things and techniques,
and I’m definitely looking forward to get better at boxes.
I’d like to thank all the people I’ve talked to
in the last few weeks, they were all amazing and supportive people!
