[HN Gopher] A pentester gets root - step by step example
___________________________________________________________________
A pentester gets root - step by step example
Author : Jaruzel
Score : 234 points
Date : 2022-02-20 14:27 UTC (8 hours ago)
(HTM) web link (kaizoku.dev)
(TXT) w3m dump (kaizoku.dev)
| mr_mitm wrote:
| _> nmap --privileged -Pn -sU -p- --min-rate 10000 -oN nmap
| /udp_ports_scan $IP_
|
| 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.
| garbagecoder wrote:
| Thank you for this. I know some of this from painful experience
| and will probably want to bookmark that link!
| mikekhusid wrote:
| https://0xdf.gitlab.io has much better HackTheBox write-ups for
| those interested in such things. The IppSec YouTube channel is
| also great.
| sockpuppet69 wrote:
| jjice wrote:
| HackTheBox looks like a neat service to learn some fun skills. I
| used to love CTFs in college, but haven't done any in quite some
| time. Anyone have recommendations for any services for this kind
| of problem/game, or is HTB a solid one to use?
| boneitis wrote:
| The context of this submission will naturally be lost on many,
| and the editorialized headline is arguably wildly
| inappropriate.
|
| 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.
| BeefWellington wrote:
| I love hackthebox. It is an invaluable resource and great for
| practice. It is not as comprehensive as the OSCP course
| material, unfortunately, and even the OSCP material has (or
| at least had, I know they changed things up recently) its
| warts.
| parentheses wrote:
| there's also one called hack this site. that's more focused on
| sql injection and the like.
| cadence- wrote:
| 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? ;)
|
| 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.
| wrboyce wrote:
| I assume it wasn't your intention, but I read this comment as
| very harsh on the author. I, too, remember the 90s and I think
| calling OP a script kiddie was somewhat uncalled for.
|
| 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.
| mr_mitm wrote:
| You seem to look down on automated actions. But where do you
| draw the line? So much is already automated by everything you
| do on the computer.
|
| 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.
| BeefWellington wrote:
| 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? ;)
|
| While sure, it was probably possible at this point to do that,
| I can think of a few really good reasons:
|
| - 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.
|
| A script kiddie wasn't a script kiddie because they used
| scripts sometimes successfully, they were a script kiddie
| because that's all they could do. Most experienced pentesters I
| know use linpeas and similar scripts to see if there's any easy
| low-hanging fruit. It's simpler to do that as a quick check
| than to run down your own checklist each time. That doesn't
| mean that's where they stop.
|
| 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.
|
| I'm not sure how you arrived there in this particular thread.
| Hackthebox and hackthissite and other similar challenge
| systems, the entire concept of CTFs (check out how many are at
| ctftime.org) are all for fun challenges to help people learn.
| bengalister wrote:
| You probably know it but you don't need to copy and paste in
| you terminal, you can use pipes. ssh myuser@myip "cat >
| myfile" < myfile
|
| 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.
| rectang wrote:
| As an experienced software developer I feel like I have decent
| understanding of how to harden my code both line-by-line and
| through sound architectural decisions, avoiding mistakes from
| memory safety to injection to permissions to race conditions to
| what-have-you. But I will gladly acknowledge that I'm not an
| expert system administrator and generally need to rely on others
| who have the necessary skills to set up servers and avoid
| misconfigurations to the standard I feel like can uphold in my
| own code.
|
| 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.)
| CodeGlitch wrote:
| > What sort of basic checks should one perform after
| provisioning a server or making a service available?
|
| 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).
| rectang wrote:
| Thanks, that's a perfect suggestion!
|
| 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.)
| braingenious wrote:
| This is a really interesting topic, but as a newbie I would love
| a little more detail. For example, with the nmap command, why did
| they use those particular switches?
|
| >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?
| bombcar wrote:
| See the other post above but https://nmap.org/book/scan-
| methods-udp-scan.html would be a good place to start.
| phantomread wrote:
| I realize documentation is only half the battle but I get a lot
| from using something like explainshell when I see unknown
| argument lists:
| https://explainshell.com/explain?cmd=nmap+-Pn+-sT+-p-+--min-...
|
| 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.
| braingenious wrote:
| What a cool website! Thanks!
| wokwokwok wrote:
| I mean... this is an interesting write up, but the "got root"
| boils down to "someone committed the root private key to git and
| then left it sitting there".
|
| 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).
| frogger8 wrote:
| Google HTB walkthrough and you will find hundreds of different
| posts for hundreds of vulnerabilities.
| aught wrote:
| I think the "root key here" search was silly but due diligence
| i suppose. There are a lot more tools than there used to be
| thats true but its also a much larger attack space than it used
| to be as well. Scripts and tools make no difference if you
| don't know when or how to use them. That's true overall not
| just pen testing. But I concur with the sentiment all though
| I'm also under the impression the purpose of the chosen example
| was meant in an encouraging way
| icecap12 wrote:
| Nowadays, I tell developers and product owners around me that
| cybersecurity is basically about 'doing IT well.' There tends
| to be this attitude at my $BIGCORP that its a box you tick or
| its something you do to get done - when in actuality its a way
| of living.
|
| 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.
| bingo-bongo wrote:
| Also, why would you put your public key in your own
| authorized_keys on the same host? (that has the private key) Is
| that something people do..? Edit: typo
| Retr0id wrote:
| > ...also, is it fine to only partially redact a private key in
| an image?
|
| It is not: https://blog.cryptohack.org/twitter-secrets
| dogman144 wrote:
| Like you note, it's often mundane exploits that tear the house
| down. Makes security engineering a challenging job as every
| secret in an inadvertent commit is a possible way in. Whacking
| gophers over and over.
| oraoraoraoraora wrote:
| This is what pentesting is, looking for service
| misconfigurations and credentials, some companies actually
| prefer testing for initial footholds only.
| EvanKnowles wrote:
| The number of times we've had developers commit passwords that
| they never should have had to Git, and then "revert" it,
| following which we had to have the passwords changed, is
| annoyingly high.
| bo0tzz wrote:
| > is it fine to only partially redact a private key in an
| image?
|
| Regardless of technical details, this is a dummy key for a CTF
| server - it's not used for anything meaningful.
| vfinn wrote:
| That xxe vulnerability sure was brutal and key to the whole
| thing. It's quite uncomfortable to be responsible for the
| security knowing exploits like this exist (of which you aren't
| aware of)
| jjice wrote:
| Yeah, I had never heard of XXE until now. Just looked into if
| PHP's DOMDocument does this by default and it seems like it's
| based on a configuration setting for the system (very PHP
| like...), though it looks like you can always run something
| like libxml_disable_entity_loader or pass in a flag to the load
| function to not have it do it.
|
| 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.
| WJW wrote:
| That is why being responsible for security is such a shitty
| position in most organizations. You have barely any upside
| since "we didn't get hacked" is the default, but if you do get
| hacked it is at least partly on your plate. Most
| vulnerabilities are things you never have heard of and possibly
| never will. Finally, you will be hated by every PM/dev trying
| to get something shipped and will continuously have to defend
| yourself from executives trying to get their pet project
| expedited.
|
| 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.
| catlifeonmars wrote:
| This is why it's so important for the organization and
| C-level to be fully bought in to security. What I've seen
| work in the past is for the devs/PMs to own security for the
| products they develop, and own the liability for security
| vulnerabilities. In this model, the security team acts more
| like an internal consultant that accepts invitations to
| review products/services.
| freebreakfast wrote:
| There is a YouTuber, STOK, who makes videos explaining how he
| discovers some vulnerabilities. He actually has a video where
| he relied on an xxe vulnerability in an PDF file to snag
| passwd/shadow.[0]
|
| 0. https://www.youtube.com/watch?v=aSiIHKeN3ys
| mathgladiator wrote:
| That's my takeaway as well. In thinking about the log4j, it
| seems like these big things inherit complex escape hatches
| which make you vulnerable.
| lokimedes wrote:
| Having had zero interest in hacking since the late nineties, it
| is facinating to see how "institutionalized" hacking has become.
| People used to bark at script kiddies, but the slick tools
| presented here seem way beyond what was available back then. Very
| cool.
| doopy1 wrote:
| I think these days security testing is just glorified QA. The
| secret sauce is developing your own methodology, which at the
| end of the days is a mega comprehensive checklist.
| ozim wrote:
| Well yes and no.
|
| 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.
| rjh29 wrote:
| There is still creativity at the edges (devising new exploits,
| figuring out how to defeat an input santiser) but day-to-day
| pentesting work is pretty mundane: you go through all the
| ports, services, API endpoints looking for standard
| vulnerablities (CSRF, XSS, SQL injection), look for common
| login and session issues, if you see XML or file upload you try
| some standard ways of subverting those, and you test for access
| control or application logic errors. Proxies like Burp can make
| it easy to intercept and modify requests or replay them with
| different sessions.
| brightball wrote:
| It seems like it's the type of think that should be taught in
| CS programs at this point (if it's not already).
| robin_reala wrote:
| Well, maybe SE programmes. There's some CS in security
| work, but not at a basic level.
| [deleted]
| _448 wrote:
| Even with slick tools, sometimes the crackers do get it wrong.
| Few days ago I was reading on Check Point a technical analysis
| of cyber attack on Iranian state television. And the security
| analysts who were analysing the data were all dealing with
| debug-mode files left behind after the attack! There was no
| attempt by the crackers to clean-up the binaries before
| releasing it on the target.
|
| 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 :)
| haxnotcrax wrote:
| ykevinator2 wrote:
| What a great writeup, thank you for posting.
___________________________________________________________________
(page generated 2022-02-20 23:01 UTC)