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

41–50 of 75 posts

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

#41

Post by bifrost »

pm90 wrote: post #38
bifrost wrote: post #31

Earlier quoted context omitted.

If you click through to the GH Issues I linked to there are some pretty good data points as to what happened. I didn't feel the need to copypasta. But yes, publicly exposed jenkins and repos lead to the compromise, not an uncommon story unfortunately. Perimeter - I didn't see much evidence of one existing and I didn't go probing their networks to find out. Security tropes are real for a reason, you don't have to beli…

> They've leaked before and they'll keep on leaking. GitHub even made it harder for people to fork private repos to their own public accounts but it still happens Can you provide some actual instances of this happening? Genuinely curious, as my org is currently migrating from enterprise to cloud.

I've mostly seen this reported in forums and during discussion, if you Google around you'll find some pretty useful hits.

Here's a good one from reddit: https://www.reddit.com/r/github/comments/9odnvw/someone_fork...

Its also discussed reasonably well in the infosec community. Basically GitHub is a great place to find other people's passwords and API keys.

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

#42

Post by bifrost »

driminicus wrote: post #37
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.

Because the second tine was a dns hijack, not a network compromise. I'm a little fuzzy on the details, but it had something to do with cloudflares API not revoking some access token. Either way, a DNS hijack is not great, but not nearly as bad as the initial compromise.

It wasn't CloudFlare's API not revoking a token, they just didn't revoke all the tokens. Basically human error.

"The API key was known compromised in the original attack, and during the rebuild the key was theoretically replaced. However, unfortunately only personal keys were rotated, enabling the defacement."

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

#43

Post by bobwaycott »

bifrost wrote: post #31
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…

If you click through to the GH Issues I linked to there are some pretty good data points as to what happened. I didn't feel the need to copypasta. But yes, publicly exposed jenkins and repos lead to the compromise, not an uncommon story unfortunately. Perimeter - I didn't see much evidence of one existing and I didn't go probing their networks to find out. Security tropes are real for a reason, you don't have to beli…

> But yes, publicly exposed jenkins and repos lead to the compromise …

You mean the past-tense verb led, not its metallic homonym lead. :)

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

#44

Post by netsectoday »

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 they would still have this issue. Then answer here is to not use the default /etc/ssh/sshd_config value of #AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2. Uncomment and remove authorized_keys2.

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

#45

Post by bifrost »

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'll vote yes for this one :)

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

#46

Post by _frkl »

bifrost wrote: post #7
nisa wrote: post #3

It's been a few years since I last used Saltstack but if you have access to the master you have instant root on all minions or did that somehow change? salt '*' cmd.run 'find / -delete' and game-over?

Very true, however I'd rather have that problem than an ever multiplying number of user accounts on systems that can su/sudo.

How does saltstack do tasks that require root access? Use the root user directly?

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

#47

Post by baroffoos »

bifrost wrote: post #41
pm90 wrote: post #38

Earlier quoted context omitted.

> They've leaked before and they'll keep on leaking. GitHub even made it harder for people to fork private repos to their own public accounts but it still happens Can you provide some actual instances of this happening? Genuinely curious, as my org is currently migrating from enterprise to cloud.

I've mostly seen this reported in forums and during discussion, if you Google around you'll find some pretty useful hits. Here's a good one from reddit: https://www.reddit.com/r/github/comments/9odnvw/someone_fork... Its also discussed reasonably well in the infosec community. Basically GitHub is a great place to find other people's passwords and API keys.

Thats unrelated to github though. It sounds like the person did a git clone and then created a new repo and pushed it. You could do that with a self hosted git repo as well. To stop that you would have to have your git server block logins from non company machines and have some serious logging on all company machines to stop anyone moving it off via usb

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

#48

Post by bifrost »

bifrost wrote: post #41
pm90 wrote: post #38

Earlier quoted context omitted.

> They've leaked before and they'll keep on leaking. GitHub even made it harder for people to fork private repos to their own public accounts but it still happens Can you provide some actual instances of this happening? Genuinely curious, as my org is currently migrating from enterprise to cloud.

I've mostly seen this reported in forums and during discussion, if you Google around you'll find some pretty useful hits. Here's a good one from reddit: https://www.reddit.com/r/github/comments/9odnvw/someone_fork... Its also discussed reasonably well in the infosec community. Basically GitHub is a great place to find other people's passwords and API keys.

baroffoos: Thats pretty close to what I'm suggesting, no public repo access. It works.

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

#49

Post by bifrost »

_frkl wrote: post #46
bifrost wrote: post #7

Earlier quoted context omitted.

Very true, however I'd rather have that problem than an ever multiplying number of user accounts on systems that can su/sudo.

How does saltstack do tasks that require root access? Use the root user directly?

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

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

#50

Post by throwaway_391 »

bifrost wrote: post #49
_frkl wrote: post #46

Earlier quoted context omitted.

How does saltstack do tasks that require root access? Use the root user directly?

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?
Post reply on HN