What we’re doing in response to the jabber.ru MITM attack

—

by

admin
in , ,

As you may have heard, jabber.ru, a popular XMPP service discovered a sophisticated MITM attack against their service that may have lasted for up to 6 months. They published a great blog post, going over all the details of the attack and measures to prevent this sort of attack from happening on other services.

From reading the post, it was apparent that the same attack could also happen on XMPP.is, and potentially other Unredacted services. We’ve confirmed in multiple ways that this attack is not currently happening on XMPP.is infrastructure. However, it’s important for us to take precautions and be alerted to this sort of attack if it were to happen in the future.

What we’ve done

  • We have utilized CertWatch, a service by xmpp.net to alert us to the potential fact that there is an ongoing MITM attack against our XMPP service. At the time of this post, there is no ongoing MITM attack according to their service.
What it looks like if no MITM is active when manually checking CertWatch
  • To subscribe to CertWatch alerts for XMPP.is, you can open either link in your XMPP client:
  • We have verified that our XMPP.is certificate fingerprint transparency automation is working as intended.
    • If you wish to manually check that the certificate presented to your XMPP client is valid, we have a script that has been running for many years that outputs the fingerprints from newly issued certificates. The output can be found here and is automatically updated.
A screenshot of the current fingerprints as of this blog post
  • We have signed up for Cloudflare’s Certificate Transparency Monitoring on all important domains, so that admins can be notified when new certificates get issued for Unredacted services. This allows us to have 2 sources in which we could be notified of a potential MITM attack.
  • We have double checked and ensured that we utilize CAA records across all domains.

What we will explore

  • We are considering automating the monitoring of default gateway MAC address changes across our dedicated hardware infrastructure. We already ingest metrics via Prometheus node_exporter that allow us to track this historically.
  • We are planning on setting up Cert Spotter, and monitoring all important domains so that we can be notified of certificate changes when they happen.
  • We plan to ensure that all existing XEPs that are mentioned in this blog post (which are supported by Prosody) get implemented on XMPP.is. This will help support channel binding and other existing SASL issues.

Our final thoughts

It is concerning that any attack like this can go unnoticed, and it’s unfortunately something that’s easy to miss. People think as valid certificates as automatically trustworthy. However, in cases where someone has access to your physical infrastructure a lot of things are possible, including what happened with jabber.ru (issuing Let’s Encrypt certificates from their DNS A/AAAA record IP). It’s also equally worrying that there are many certificate authority failures. When they are the root of trust, and they are not trustworthy it creates the potential for many problems with TLS on the internet.