Hacker News Reader

Comment by Arathorn | Hacker News Reader

Project lead for Matrix.org here - you can see our initial statement on this at http://matrix.org/blog/2019/04/11/security-incident/.

It will be updated shortly to reflect the DNS defacement linked here (which was because we failed to rotate a leaked cloudflare API token; we aimed to rotate the master API token but rotated a personal one instead). To our knowledge the rebuilt production infrastructure itself is secure.

We've revoked the compromised GPG keys, and are obviously going to do everything we can to improve our production security to avoid a recurrence in future.

We can only apologise to everyone caught in the crossfire of this incident.

View on HN

https://matrix.org/blog/2019/04/11/security-incident/ has just been updated with details on the earlier defacement.

Any more information on how the Jenkins server was compromised? From a cursory read of the CVEs it looks like an attacker must be able to push code in order to exploit? Was the server completely public, or was the attacker able to submit code via pull request or similar for running on ci/Jenkins?

do you have plans to perform an external security audit?

didn't that just happen? ;)

yes.

Have you implemented hole punching?

What is hole punching and how would it have helped against the attack?

I only know the term for UDP firewall transversal.

The lame version of port knocking that solves 99.9% of issues.

1. Default policy for access to all of the development environment is deny all.

2. A developer triggers a temporary addition of developers current address to the allow list with an idle timer, punching a hole for developer's edge IP to access the infrastructure.

3. When the idle timer expires or when the developer says "i'm done", the allow rule is removed.

Obviously, a full blown port knocking with keys and policies would be better for a large organization with hundreds of developers and hundreds of hosts but it is the case where 99.9% of the issues can be solved using a very simple system as in order to get to the vulnerable entry point the attacker would need to do it from an IP address used by a developer at that specific time.

IP whitelisting and port knocking are not serious security methods. They're the very-poor-man's version of a VPN and access control policies, and they're not secure.

You are talking about organizations that have GPG private keys used for signing laying around and those that have Jenkins exposed to the outside world.

Dynamic IP white listing and port knocking are perfectly adequate for 99.9% of the organizations.

Reply on news.ycombinator.com