New about hacking the infrastructure of the Matrix decentralized messaging platform, about which in the morning. The problematic link through which the attackers penetrated was the Jenkins continuous integration system, which was hacked on March 13th. Then, on the server with Jenkins, the login of one of the administrators, redirected by the SSH agent, was intercepted, and on April 4, the attackers gained access to other infrastructure servers.
During the second attack, the matrix.org site was redirected to another server (matrixnotorg.github.io) by changing the DNS settings, using the key to the Cloudflare content delivery system API intercepted during the first attack. When rebuilding the content of the servers after the first hack, Matrix administrators updated only new personal keys and missed updating the key to Cloudflare.
During the second attack, the Matrix servers remained untouched, the changes were limited only to the replacement of addresses in the DNS. If the user has already changed the password after the first attack, there is no need to change it a second time. But if the password has not yet been changed, it should be updated as soon as possible, since the leak of the database with password hashes has been confirmed. We currently plan to force a password reset process at the next login.
In addition to the password leak, GPG keys used to generate digital signatures for packages in the Debian Synapse repository and Riot/Web releases have also been confirmed to have fallen into the hands of the attackers. The keys were password protected. At the moment, the keys have already been revoked. The keys were intercepted on April 4, since then no Synapse updates have been released, but there was a release of the Riot/Web 1.0.7 client (a preliminary check showed that it was not compromised).
The attacker posted a series of reports on GitHub with details of the attack and tips for increasing protection, but these have been removed. However, archived reports .
For example, the cracker reported that the developers of Matrix should have two-factor authentication, or at least not using SSH agent redirection (βForwardAgent yesβ), then penetration into the infrastructure would be blocked. The escalation of the attack could also be stopped by granting the developers only the necessary privileges, rather than on all servers.
Additionally, the practice of storing keys for creating digital signatures on production servers has been criticized; for such purposes, a separate isolated host should be allocated. Still attacking that if the Matrix developers regularly audited the logs and analyzed anomalies, they would have noticed traces of a hack at an early stage (the CI hack went unnoticed for a whole month). Another problem storing all configuration files in Git, which made it possible to evaluate the settings of other hosts when one of them was hacked. SSH access to infrastructure servers limited to a secure internal network, which allowed you to connect to them from any external address.
Sourceopennet.ru
[:in]New about hacking the infrastructure of the Matrix decentralized messaging platform, about which in the morning. The problematic link through which the attackers penetrated was the Jenkins continuous integration system, which was hacked on March 13th. Then, on the server with Jenkins, the login of one of the administrators, redirected by the SSH agent, was intercepted, and on April 4, the attackers gained access to other infrastructure servers.
During the second attack, the matrix.org site was redirected to another server (matrixnotorg.github.io) by changing the DNS settings, using the key to the Cloudflare content delivery system API intercepted during the first attack. When rebuilding the content of the servers after the first hack, Matrix administrators updated only new personal keys and missed updating the key to Cloudflare.
During the second attack, the Matrix servers remained untouched, the changes were limited only to the replacement of addresses in the DNS. If the user has already changed the password after the first attack, there is no need to change it a second time. But if the password has not yet been changed, it should be updated as soon as possible, since the leak of the database with password hashes has been confirmed. We currently plan to force a password reset process at the next login.
In addition to the password leak, GPG keys used to generate digital signatures for packages in the Debian Synapse repository and Riot/Web releases have also been confirmed to have fallen into the hands of the attackers. The keys were password protected. At the moment, the keys have already been revoked. The keys were intercepted on April 4, since then no Synapse updates have been released, but there was a release of the Riot/Web 1.0.7 client (a preliminary check showed that it was not compromised).
The attacker posted a series of reports on GitHub with details of the attack and tips for increasing protection, but these have been removed. However, archived reports .
For example, the cracker reported that the developers of Matrix should have two-factor authentication, or at least not using SSH agent redirection (βForwardAgent yesβ), then penetration into the infrastructure would be blocked. The escalation of the attack could also be stopped by granting the developers only the necessary privileges, rather than on all servers.
Additionally, the practice of storing keys for creating digital signatures on production servers has been criticized; for such purposes, a separate isolated host should be allocated. Still attacking that if the Matrix developers regularly audited the logs and analyzed anomalies, they would have noticed traces of a hack at an early stage (the CI hack went unnoticed for a whole month). Another problem storing all configuration files in Git, which made it possible to evaluate the settings of other hosts when one of them was hacked. SSH access to infrastructure servers limited to a secure internal network, which allowed you to connect to them from any external address.
Source: opennet.ru
[:]