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

61–70 of 75 posts

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

#61

Post by Arathorn »

Arathorn wrote: post #60

If it wasn’t clear, this article wasn’t written by the Matrix.org team, nor did the author discuss any of it with us to our knowledge. We’ll publish our own full post-mortem in the next 1-2 weeks.

also, reading this article more carefully, much of this just plain wrong:

> One of the more interesting pieces of this was how Ansible was used to keep the attacker in the system.

Fwiw the infra that was compromised was not managed by Ansible; if it had been we would likely have spotted the malicious changes much sooner.

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

#62

Post by inetknght »

tialaramex wrote: post #54
inetknght wrote: post #15

Earlier quoted context omitted.

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 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 I need to alias one name to another.

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

#63

Post by inetknght »

tialaramex wrote: post #55
deathanatos wrote: post #19

Earlier quoted context omitted.

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 wh…

It's not just giving you a transient notification with the agent gets a request. I'd go several steps further:

1) clearly display what "local" machine is making the connection, under what user

2) clearly display what remote machine is the local connecting, to what user

3) allow me to select a specific key for that connection pair, and only present one key to the remote

4) if the key is unlocked (or, gasp not passphrase-protected), then allow me to accept/deny the agent request

5) give me some mechanism to permanently disable the agent for my user if I decide I don't want to risk some software "accidentally" forwarding an agent (pebcak, bug, malice, whatever)

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

#64

Post by nobatron »

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.

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

#65

Post by bifrost »

bifrost wrote: post #35
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.

I guess I technically glossed over that but I did say "One of the more interesting pieces of this was how Ansible was used to keep the attacker in the system". The attacker was persisted via CM and their public repo, I'm actually surprised this doesn't happen more often.

I should clarify this comment a bit since it seems to be the most controversial.

When I say the attacker was persisted via CM, I'm pointing at his own notes, nodding to broken CM, the requirements of supporting the CM and availability of the config files.

I also sanity checked the sshd_config file on my systems, they're all set to a sane default:

"AuthorizedKeysFile .ssh/authorized_keys"

FWIW I prefer to treat CM data as "valuable" information for this reason.

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

#66

Post by inetknght »

andrewshadura wrote: post #53
inetknght wrote: post #15

Earlier quoted context omitted.

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.

https://linux.die.net/man/1/seahorse-daemon

Seahorse is a GNOME application for managing encryption keys. This is the daemon program which provides services to other parts of Seahorse, and shares your keys over the network if so desired.

It doesn't have agent in its name but it sure sounds like the behavior of a key agent.

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

#67

Post by inetknght »

schoen wrote: post #18
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.

And probably it should have been described as an antipattern rather than a dark pattern.

I think you're correct, that would be a better description. Unfortunately I think it's too late to edit my original comment: the edit link doesn't show up for me.

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

#68

Post by forgotmypw »

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/

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

#69

Post by inetknght »

bifrost wrote: post #4
inetknght wrote: post #2

I have gone on some long verbal rants about the dark patterns (bordering on malicious behavior) exhibited by key agents such as SSH agent, GPG agent, Pageant, and the like. What can you learn from the compromise? Never use an agent. Kill it with fire^H^H^H^H -9.

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

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

#70

Post by ficklepickle »

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/

This is very interesting! I have so many questions. If you see this, kindly send me an email. It's in my profile. I love the idea!
Post reply on HN