A pentester gets root - step by step example
kaizoku.dev
kaizoku.dev
This will never find most UDP services. If you don't send a service-specific probe, the service will most likely simply not answer and the situation will look like there is no service running at all.
Sometimes you get an "ICMP port unreachable" in which case you know there is no service running, but more often than not you won't.
You should at least use `-sV`, so nmap sends service-specific probes. This will increase scan time substantially, so if you have more than one host you might want to limit yourself to the top 100 ports with `-F`.
There are surprisingly many subtleties involved with UDP scans, so I recommend reading this article: https://nmap.org/book/scan-methods-udp-scan.html
Also, check out nmap's timing templates (e.g. `-T4`) instead of simply setting the minimum package rate to a ludicrous value. Nmap's man page (which, in my opinion, is the best man page I ever read) says this:
> Specifying a minimum rate should be done with care. Scanning faster than a network can support may lead to a loss of accuracy. In some cases, using a faster rate can make a scan take longer than it would with a slower rate.
A min rate of 10000 may work in a lab environment, but I'd stick to T4 in real environments.
To be fair, I bet there are a lot of things like that out there, along with folk using “password1” as their login.
…but it felt like a bit of let down in the story.
1) Get shell access!
2) look for a commit entitled “root key here”
3) profit!
I was a bit disappointed, I was hoping for some exploit… but I guess often this stuff is just mundane human failures.
…also, is it fine to only partially redact a private key in an image?
I mean, tell me I’m wrong here, but isn’t that kinda bad? (Maybe it’s just a mock image for the post, who knows).
Regardless of technical details, this is a dummy key for a CTF server - it's not used for anything meaningful.
The majority of exploits take advantage of basic mistakes in configuration or code. Most of those issues are well understood, which is why you've seen this rise of detection tools and automation. Big hacks nowadays are necessarily a daisy-chain of exploits, because we're better at security at certain layers.
But overall, we're far from perfection. Solid configuration and code takes thought and planning - two luxuries rarely afforded to product teams when the business is screaming for release.
Past that point, it’s daisy chains of exploits as you say. It’s not uncommon for sophisticated attackers to sit on a number of 0-day exploits until they find a venue to deliver them. This is one of the reasons the Log4j announcement was scary—it opened up a venue to a wide variety of applications and infrastructure that were previously protected through other means.
> But overall, we're far from perfection. Solid configuration and code takes thought and planning - two luxuries rarely afforded to product teams when the business is screaming for release.
I’ve found a big part of a good security program is helping an organization calibrate it’s actual risk appetite. If business ending events are known and understood, everyone should know in what cases a security issue becomes a blocker.
In many companies, it is just a box to be checked (by a separate Compliance department who does not have access to the codebase only emails to designated contacts in Engineering), and thinking about it beyond that will merely impede one's ability to achieve designated objectives. For anyone actually "making stuff" in this kind of environment, security is (at best) documenting having followed procedure to deflect blame if something bad happens.
It is not: https://blog.cryptohack.org/twitter-secrets
What was the admin password for this huge hosting company?
"internet"
Another anecdote. Worked for a startup 20 years ago. We had millions of users. For some reason we left all the passwords in plaintext in the DB. One day we decide to query the DB for a sorted list of the most common passwords. They were: password trustno1 12345 123456 12345678
That 2nd one had to have been due to the X-Files still being shown at that point.
BTW, there could be a motive behind this as well, to let the victim know deliberately who they were and how they were doing it. But this is very rare, and only useful if it is a one-off attack. But the attack that was analysed by Check Point was that from repeat offenders, so to me it looked like someone who had just taken an online cracking 101 lessons and targeted few state institutions of a country :)
Being a football player is also applying comprehensive checklist, question is who does it faster and is able to execute it.
Like I do understand all the exploits but executing them and executing them quickly or iterating over possible solution space is taking me 4 days on HTB easy boxes.
There are people who break really hard boxes in matter of hours or even minutes.
So for me it is comparison like I am playing soccer with my neighborhood friends and playing premier league. Like I do know the moves that should be done but I do not have reflexes built for that and building those reflexes takes years of focusing on playing football. Having reflexes on which exploit to choose or which tool you should pick up to go through with hack is something like that and you need years to build it up.
This begs the questions: why is this the default? If you know you need it, you can be required to pass a flag to explicitly allow instead of having to disallow. I'm going to hope modern XML libraries handle this the opposite way and chalk this up to PHP being on the older side.
I'd be curious to know the history too. Did they really not forsee that external entities are a security hole?
Even worse than a full time security person or team is the dev who cares a little more than usually and gets manipulated into doing "security" part time while still being part of a normal team. That is just a fast track to burnout: massive responsibilities with almost no power. I've seen it multiple times now and it never seems to end well.
Seeing a formulaic approach to pen-testing is inspiring. I feel as though if I were to practice, I would eventually be able to develop routines and understanding of how to test for and detect common errors. It would be nice to build additional competence and collaborate more effectively with expert sysadmins, even if I don't plan to masquerade as one.
What sort of basic checks should one perform after provisioning a server or making a service available? (Perform a port scan, validate that an internal server is inaccessible from the wider net, etc.)
Automate everything, as in the provisions. Even if it's a one-shot job. This way if something does go wrong you can go look back at the script and it will give you an idea of where things went wrong (misconfiguration, etc).
I'm accustomed to writing automated unit and integration tests for my code. What sort of tests should I add to the provisioning routine to prove that I got it right?
I appreciate that a skilled pentester would likely uncover service-specific or instance-specific vulnerabilities, but there are surely some testing principles that would make sense for every single server.
Or is it really that at a high level, a port scan suffices and from there everything is service-specific (or at least requires going through a port)? I don't know what I don't know, here. Is there any way that a machine can be vulnerable from a network connection except through a port? (Let's ignore attacks which require physical access for the time being.)
>nmap -Pn -sT -p- --min-rate 10000 \ -oN nmap/tcp_ports_scan
I understand that nmap is a very versatile port scanning program, and I haven't used it since I was a kid, but I have no idea what about this particular situation calls for -Pn -sT -p- -oN. Is that an ideal configuration to use when you're scanning a target that you know nothing about?
This way you can read the full command sort of like a custom pamphlet. To your point, more context beyond the manpage is always helpful.
Only if you know the host is alive and at the same time does not want to be seen, then it may make sense to use it, otherwise it messes with nmap's rate calibration.
The website also doesn't really explain why those switches were chosen.
And it's not clear to me either: unless you lack permissions or you find yourself in some other special circumstances, `-sS` is superior over `-sT` (as the man page explains). The latter creates a full TCP connection, while the former sends only a SYN packet and waits for the response: SYN-ACK means port open, RST means port closed. Then it moves on, leaving the half-opened connection dangling.
`--min-rate` was chosen to increase speed, but it comes at the cost of accuracy. `-T4` is the better switch to increase speed. See the man page for details.
This submission is a _single_ write-up of _one_ box on HackTheBox (HTB), which is one of the most popular platforms for redteam-like practice for the price of a common subscription service.
You often see it very directly compared to the hundreds (or thousands) of dollars you would cough up for similar lab material but which also comes with the benefit of OSCP certification (if you pass the exam), thought by some (albeit not all, if you pay attention to this topic on HN) to be one of the more reputable entry-level pentesting credentials.
Just like for CTFs, you can search everywhere in search engines for writeups. (Do note that boxes are split between "Active" and "Retired" machines, and public-facing writeups are only allowed for those that have been retired.)
The most popular (and fantastic, IMO) video walkthroughs are done by the yt channel IppSec
This platform is great fun, and I'll be honest: when I started from zero, I needed to straight-up monkey-see-monkey-do follow-alongs with IppSec videos for most of the boxes that I have done. It is probably also the most hands-on knowledge I have picked up out of anything I've ever done that I have not had to figure out by myself.
Also, you would have been labeled a script kiddie and laughed at for this kind of mostly automated hack in the late 90s.
Gosh, I miss those times when hacking was mostly for fun and challenge. Now it seems to be only for work, money or malice.
I don’t work in security, but I’ve always been very intrigued by it and have enjoyed some success in CTFs. Having said that, is automating stuff not a goal of every software engineer? DevOps has exploded in popularity; terraform didn’t exist in the 90s. Am I a script kiddie for using pre-built (and tested!) terraform modules?
As for the “mostly for fun” quip… OP is literally writing up a HackTheBox challenge, performed purely for fun. If you want something fun and security adjacent to play around with I can’t recommend microcorruption strongly enough; I really really enjoyed that.
Do you communicate with web servers using netcat? Do you open raw sockets and forge your own SYN packets? Do you compute cryptographic signatures with you pocket calculator? Do you write programs in Assembler instead of C or Python? No, because in most cases it would be a tremendous waste of time.
Why insist on others going through the same motions you did instead of just publishing your exploit or offensive security tool? Why would you reinvent the wheel if the problem has already been solved by someone else? (Unless for academic purposes.)
There is nothing wrong with tapping into the gigantic hive mind that is modern whitehat hacking. Today, we tend to go for the "standing on the shoulders of giants" approach instead hindering progress by gatekeeping our own achievements.
As someone who abandoned hacking two decades ago, I was really taken aback by that usage of a local web server to transfer shell scripts. What happened to the plain old copy and pasting of scripts through your existing ssh connection, for crying out loud? ;)
- SCP doesn't always work, the SFTP/SCP subsystems can be turned off. This makes it unreliable. In practice, most targets will have it enabled but this could bite you when it doesn't.
- Copy and pasting a 130KB script is not always reliable either, especially if it contains shellcode (you get lovely session- or term-breaking binary data shoved into it). It can work in a pinch but it's less reliable than pretty much all your other options.
- There are categories of attacks that require an out of band connection to exploit, which means you want the server with your tools available somewhere anyways. If it's already set up, why not leverage it?
- You may not have the ability to reliably open a new ssh connection.
Conversely, you have to consider that HTTP traffic may be filtered on egress, monitored, etc.
In my experience, actually getting SSH into the system is typically unnecessary anyways.
Also, you would have been labeled a script kiddie and laughed at for this kind of mostly automated hack in the late 90s.
You know, like devs using boilerplate, or people coding using standard libraries, or using a presentation template.
Gosh, I miss those times when hacking was mostly for fun and challenge. Now it seems to be only for work, money or malice.
and use tar to stdout, untar from stdin to transfer directories. It can even be compressed while archiving or at ssh level.
or rsync over ssh.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future. They're here: https://news.ycombinator.com/newsguidelines.html.