What can we learn from the matrix.org compromise? • Hacker News Board

Re: What can we learn from the matrix.org compromise?

#71

Post by bifrost » Wed, Apr 24, 2019, 4:41 AM UTC

nobatron wrote: post #64

pm90 wrote: post #28

This is such a poorly written article: * no detailed analysis of how the attack was undertaken. Its not even clear how the attacker managed to get in (was it a publicly exposed Jenkins? vulnerable bastion? what?) * no analysis of what the existing matrix.org security perimeter looked like or how it could be made better. * repetition of security tropes. Use VPN. Use Github Enterprise (wait wtf? Why not private repos i…

There's a lot wrong with this article. Firstly having a private network for your infrastructure isn't a one stop solution for keeping attackers out. Secondly using Github Enterprise or self hosted GitLab doesn't make up for storing secrets in Git. Looking forwards to the proper write up.

I've never claimed it was a "one stop", but it certainly keeps the random internet users to a minimum.

And yes, using GHE or self hosted GitLab doesn't make up for storing secrets, but it at least keeps them out of the public eye so the effects are less brutal. Its still bad to store secrets in a code repository.

My whole point is that you can reduce risks easily, yet some people don't for some reason.

Re: What can we learn from the matrix.org compromise?

#72

Post by bifrost » Wed, Apr 24, 2019, 4:42 AM UTC

forgotmypw wrote: post #68

I'd like to take this opportunity to plug my in-development decentralized, distributed, completely open forum, using PGP as the "account" system, and text files as the data store. So any reasonably competent hacker can re-validate the entire forum's content and votes, reasonably quickly reimplement the whole thing, and/or fork the forum at any time. http://shitmyself.com/

Very Cool! I'll check it out!

Re: What can we learn from the matrix.org compromise?

#73

Post by bifrost » Wed, Apr 24, 2019, 4:43 AM UTC

zimbatm wrote: post #57

The attacker gained network access through Jenkins. Don't deploy a public-facing Jenkins, especially if it has credentials attached to it. It's really hard to secure, especially if pull-requests can run arbitrary code on your agents. Jenkins / CI is the sudo access to most organizations.

I agree with you 100% here, I would not deploy any CI publicly unless its heavily fenced off into "read only" territory.

Re: What can we learn from the matrix.org compromise?

#74

Post by bifrost » Wed, Apr 24, 2019, 4:44 AM UTC

inetknght wrote: post #69

bifrost wrote: post #4

Earlier quoted context omitted.

The attacker still would have gotten their key in. TBH if you kill the agent people are just going to copy their keys with no passphrases around. Ask me how I know...

If only a password manager could add a sane agent and UI

Someday we will have tools that save us from human problems!

Re: What can we learn from the matrix.org compromise?

#75

Post by tialaramex » Wed, Apr 24, 2019, 7:08 AM UTC

inetknght wrote: post #62

tialaramex wrote: post #54

Earlier quoted context omitted.

For (4) and (5) set IdentitiesOnly as well as Identity (IdentityFile or IdentityAgent). This tells SSH that you've specified the exact identity you want used, not just a hint at an identity that might help. Note that having "trouble with active firewalls" is a sign that the security posture is garbage, those aren't "authentication attempts" the SSH protocol explicitly has a step where the client proposes authenticati…

That's an interesting perspective. Nonetheless, if you load up your agent with a dozen keys and try to log in to a remote server, it will deny you after (typically) three keys being presented. That will show up in the logs as a failed login attempt. Something such as fail2ban will then spot failed login attempts and take action. Edit: +1 about IdentitesOnly and Identity. I use that in my ssh_config, particularly when…

By default OpenSSH _logs_ after three keys but it only gives up (if you don't have a fail2ban script blowing everything up) after six keys. And you can reconfigure the server as appropriate, unlike whatever this "active firewall" (which by the sound of things may just be a fail2ban script) does.

This is a bad fail2ban script, it's inconveniencing real users rather than targeting the bots you care about since they are doing password guessing anyway.