Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What can we learn from the matrix.org compromise?

medium.com

Post reply on HN
Print view View original

51–60 of 75 posts

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

#51

Post by bifrost »

throwaway_391 wrote: post #50
bifrost wrote: post #49

Earlier quoted context omitted.

Correct, the minion runs as root and doesn't require interactive ssh access. Its controlled by a remote master that you ideally properly protect.

So it's a less audited application than *SSH that the author is recommending over SSH because it doesn't require user authentication but runs in a daemon with root privs?

Not quite. In this case Ansible is enabled by a user logging into the system; The user should not be allowed to login to the system in the first place. Ideally you want your configuration system indepenent of user logins. Ansible has its place, my argument is that it doesn't belong here.

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

#52

Post by andrewshadura »

bifrost wrote: post #36
scurvy wrote: post #34

Earlier quoted context omitted.

Smart cards? They were designed for this.

Ever seen anyone working in a Coffee shop using one? Me neither. Good security technology exists, the problem is that people don't want to use it because its easier to ignore it.

I have, and I have myself used one until it was stolen from me with a bag it was in.

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

#53

Post by andrewshadura »

inetknght wrote: post #15
yjftsjthsd-h wrote: post #5

Earlier quoted context omitted.

Okay, I'll bite. What are you calling a dark pattern in assorted agents? Especially given that dark pattern implies intent to harm. (And I say this as someone looking at using an agent: If there's a gotcha, I'd like to know about it)

1) SSH agent will cache your passphrase. While that's the whole purpose of SSH agent, remember that nothing is more insecure than an unlocked secret. 2) SSH agent often starts automatically, frequently without user interaction (even if you specify `-i keyfile`). SSH client and DBus are both culprits here; there's also other culprits too. 3) There are often multiple different agents installed on Linux desktop systems.…

Seahorse is not an agent.

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

#54

Post by tialaramex »

inetknght wrote: post #15
yjftsjthsd-h wrote: post #5

Earlier quoted context omitted.

Okay, I'll bite. What are you calling a dark pattern in assorted agents? Especially given that dark pattern implies intent to harm. (And I say this as someone looking at using an agent: If there's a gotcha, I'd like to know about it)

1) SSH agent will cache your passphrase. While that's the whole purpose of SSH agent, remember that nothing is more insecure than an unlocked secret. 2) SSH agent often starts automatically, frequently without user interaction (even if you specify `-i keyfile`). SSH client and DBus are both culprits here; there's also other culprits too. 3) There are often multiple different agents installed on Linux desktop systems.…

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 authentication keys it's interested in trying WITHOUT authenticating, counting each such key as an "attempt" is like counting up how many keys a person has in their pockets and arresting them for attempted burglary if they have more than ten different keys.

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

#55

Post by tialaramex »

deathanatos wrote: post #19
yjftsjthsd-h wrote: post #13

Earlier quoted context omitted.

Ah, okay; so it's not the agent that's the problem, but the agent with forwarding . That is a fair point, and probably needs saner defaults or messaging. That said, since I don't use forwarding that should be fine for me.

Agent forwarding defaults to off , AFAIK. You have to ask for it specifically by either requesting it at the CLI with -A, or adding it to .ssh/config. It would be nice if people understood the consequences of it, and I do find in my conversations with developers that people generally do not understand that by forwarding the agent, anyone with sufficient access on the remote can use the agent. (E.g., another user w/ s…

It would be nice if GUI desktop environments that already have miscellaneous notification APIs would give you a transient notification when the agent gets a request. That's a low impact change (you can just ignore it) that highlights to users what's actually going on. It improves security passively by giving users awareness.

Your agent _should_ always be where you are (ie not inside a container, a bastion host, or whatever else) because otherwise that means you aren't actually in possession of the key material and there's plenty of opportunity for much _worse_ surprises than with SSH agents if somebody else has the key material.

Because it's where you are, and you're probably not on a 1970s video terminal link but a laptop or something, the agent could just ask you to OK each request out of band, e.g. popping up a "Really log into machine X?" request. Once such a mechanism existed it could be refined (should it let you say "Yes always to requests from machine X" ? How about "Yes always for the next five minutes" ?) and if necessary SSH auth could even be tweaked to better support any real world behaviours that are popular (e.g. I don't recall off the top of my head if the agent can tell from what it's signing either where you're signing in, or where that sign-in was used, but the binding mechanism in SSH auth could certainly enforce either of those if they're determined to be important and don't exist today)

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

#56

Post by viralpoetry »

netsectoday wrote: post #44
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…

* this idiot claimed "Ansible was used to keep the attacker in the system" which in all reality Ansible did what it was supposed to by altering the correct authorized_keys file and the attacker leveraged an old default in the sshd config. This is a sshd config issue, not Ansible. The sales-pitch for Salt (against Ansible) is ridiculous and misguided. I just checked out the Salt SSH module and even if they used salt t…

Why are you downvoted? Your Ansible explanation is indeed correct. It's SSH default problem not deployment toolkit one.

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

#57

Post by zimbatm »

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.

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

#58

Post by r1ch »

One thing I learned was where to modify the pageant source code (Windows equivalent of ssh-agent) to make my agent prompt before signing (with the default focus on "no"). This feels much safer and is a very minor inconvenience. I wonder why more agents don't have this built in.

Example: https://twitter.com/R1CH_TL/status/1118559239084158977

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

#59

Post by Arathorn »

KirinDave wrote: post #33

Why aren't people reporting the fact that Matrix.org actually lost control of their network a second time within hours of their first all clear sounding? I feel like this is an important part of the story for anyone looking for teachable infosec moments.

The rebuilt infra wasn’t compromised; what happened was that we rotated the cloudflare API key whilst logged into CF with a personal account but then masquerading as the master admin user. Turns out that rotating the API key rotates your personal one, not the one you’re masquerading as, and we didn’t think to manually compare the secret before confirming it had the right value. Hence the attacker was able to briefly hijack DNS to their defacement site until we fixed it.

We will write this up in a full postmortem in the next 1-2 weeks.

Post reply on HN