The admin of jabber.ru discovered a MITM attack on the service in the networks of the German hosting providers Hetzner and Linode

The admin of jabber.ru discovered a MITM attack on the service in the networks of the German hosting providers Hetzner and Linode

On October 20, 2023, the administrator of jabber.ru (xmpp.ru) reported the detection of a user traffic decryption (MITM) attack that has been conducted for several months on the networks of German hosting providers Hetzner and Linode. The project server and supporting VPS environments are located on these IT resources. The attack was organized by redirecting traffic to a transit node that replaces the TLS certificate for XMPP connections encrypted using the STARTTLS extension.

Unknown participants in this attack issued a separate SSL certificate and proxied the TCP:5222 connection.

According to OpenNET, the attack was discovered due to an error by its organizers who did not have time to renew the TLS certificate used for the replacement.

On October 16, when trying to connect to the service, the administrator of jabber.ru received an error message due to the expiration of the certificate, but the certificate placed on the server was not expired. As a result, it turned out that the certificate received by the client is different from the certificate sent by the server.

The first fake TLS certificate was obtained on April 18, 2023 through the Let’s Encrypt service, in which the attacker, having the opportunity to intercept traffic, was able to confirm access to the jabber.ru and xmpp.ru sites.

Initially, the administration of jabber.ru had an assumption about the compromise of the project’s server and the replacement on its side. But the audit did not reveal any traces of hacking. At the same time, a short-term turning off and turning on of the network interface (NIC Link is Down/NIC Link is Up) was observed in the vine on the server, which was carried out on July 18 at 12:58 and could indicate manipulations with the connection of the server to the switch. It is noteworthy that two fake TLS certificates were generated a few minutes before – on July 18 at 12:49 and 12:38.

In addition, the replacement was carried out not only in the network of the Hetzner provider, which hosts the main server, but also in the network of the Linode provider, which hosted VPS environments with auxiliary proxies that redirect traffic from other addresses. Indirectly, it was found that the traffic to the 5222 network port (XMPP STARTTLS) in the networks of both providers is redirected through an additional host, which gave reason to believe that the attack was carried out by a person who has access to the infrastructure of the providers.

Theoretically, the replacement could be carried out from April 18 (the date of creation of the first fake certificate for jabber.ru), but confirmed cases of certificate replacement were recorded only from July 21 to October 19, all this time encrypted data exchange with jabber.ru and xmpp.ru.

The replacement of the certificate stopped after the start of the review, conducting tests and sending a request to the support service of the Hetzner and Linode providers on October 18. At the same time, an additional transition during the routing of packets sent to port 5222 of one of the Linode servers is still observed, but the certificate is now not replaced.

The project team believes that the attack could have been carried out with the knowledge of the providers at the request of law enforcement agencies, as a result of the hacking of the infrastructures of both providers, or by an employee who had access to both providers. By being able to intercept and modify XMPP traffic, an attacker could gain access to all account-related data, such as messaging history stored on the server, and could send messages on behalf of someone else and modify someone else’s messages. Messages sent using end-to-end encryption (OMEMO, OTR, or PGP) can be considered uncompromised if the encryption keys are validated by users on both sides of the connection.

Jabber.ru users are advised to change their access passwords and check the OMEMO and PGP keys in their PEP repositories for a possible replacement.

Related posts