Hacker News Reader

Comment by wokwokwok | Hacker News Reader

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).

View on HN

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.

I think this is a good take, though depending on your domain and the maturity of your security program you eventually reach a point where the blast radius from misconfiguration becomes manageable through mitigations you have in place.

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.

> 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.

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.

> …also, is it fine to only partially redact a private key in an image?

It is not: https://blog.cryptohack.org/twitter-secrets

> 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.

This is what pentesting is, looking for service misconfigurations and credentials, some companies actually prefer testing for initial footholds only.

I remember in my young and foolish days about 20 years ago getting into a big ecommerce site host (think Shopify) because the site let you upload profile pics and it didn't check the extension. I quickly wrote and uploaded a file explorer as .ASPX and browsed the file system. Found the DB password in the site config file. Used RDP to connect and tried to log in with administrator using the DB password. Worked.

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.

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

Google HTB walkthrough and you will find hundreds of different posts for hundreds of vulnerabilities.

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.

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.

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

Reply on news.ycombinator.com