Tuesday, 20 October 2015

Insecure autoconfiguration lookups in Thunderbird

Recently I've tried an autoconfiguration feature in Thunderbird. When I was trying to figure out how it works and at what sequence it lookups for the configuration, I noticed that I didn't have SSL configured on my test web server, but Thunderbird received the configuration anyways.

Of course, I have some concerns with not using SSL by Thunderbird when it looks for the configuration. Here I have found a final (?) conclusion about using SSL:
DNS MX: Mail delivery between domains happens via DNS MX lookups,
 which are insecure. In other words, an attacker can already
 re-route and intercept new mails. The risk of interception during
 account setup is not larger than that. More importantly:
Guessed configs: An attacker can easily *prevent* connections,
 making the ispdb lookup (via https), isp fetch (via https) and
 heuristics for IMAP SSL servers and IMAP servers with secure auth mechs
 all fail, making us fall back to plaintext auth, and that's it, game over.
 Therefore, lookups via http don't add risk.
But I cannot agree with that, because intercepting emails is not the only target for the possible attack.

I've made an experiment, and create a network with a specially prepared DNS server, which redirects autoconfig.gmail.com and gmail,com to a local http server, with an autoconfig file that provides addresses to the wrong imap and smtp servers. Thus, when client tries to configure an account and just clicks "Continue" and "Done" without looking at the IMAP server address, an attacker can intercept his password if provide him with the server address for which he has an SSL certificate.

Good news: it's not so easy to use some pretty-looking addresses like the one on the screenshot. Because you need to have a trusted SSL certificate for this name. And if not use SSL in provided IMAP/SMTP configuration, Thunderbird will warn you with a big red window.

However, the attacker can use any server name if he has any stolen server certificate, and user can just don't pay appropriate attention to the values in the configuration.

Attack vector: force user to reconfigure their mail client with fake mail servers.
  • Prepare a router with a transparent proxy and/or a specially configured DNS service.
  • Router shall block all encrypted outgoing IMAP and SMTP connections.
  • Router will redirect all autoconfig.[domainname] and [domainname]/autocinfig... to a web server with a prepared fake configuration. (It can be a script that will response with the configuration for any domain requested)
  • Prepare a server with imap and smtp services with a stolen SSL certificate. DNS service will direct all requests to this server.
  • Put this setup with an open WiFi to any crowded place (hotels, hospitals, bus/train stations, etc.).
  • ... PROFIT

Of course, the configuration above is very simplified. Final configuration can be more intelligent and should allow user to browse Internet and use other services normally, so user will be sure that the only problem is a mail client.

Some users tend to re-configure from scratch their applications if something won't work. Of course, make this setup for collecting the Thunderbird users password only is not effective, but this could be a part of an attacker tools-set aimed to collects the data on public networks.