Problem Description

E-Mail clients (such as the built-in Android 4.4.2 E-Mail client) violate the IMAP STARTTLS protocol, even if the mail server is properly configured to provide the LOGINDISABLED option, and proceed to log-in to the server using a plaintext password.

Citing from RFC 2595:

"An IMAP server which implements STARTTLS MUST implement support for the LOGINDISABLED capability on unencrypted connections. An IMAP client which complies with this specification MUST NOT issue the LOGIN command if this capability is present."

However, the following is a captured protocol discussion between an Android 4.4.2 E-Mail client and a properly configured IMAP server:

  1. Server: OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS LOGINDISABLED] Dovecot ready. - this shows that the server supports STARTTLS and the server correctly offers LOGINDISABLED- without even offering LOGIN!
  2. Client: ID ("name" "com.android.email" "os" "android" "os-version" "4.4.2; KOT49H" "vendor" "samsung" "x-android-device-model" "GT-I9195" "x-android-mobile-net-operator" "FRYPAN.COM" "AGUID" "MorenaVZMLQWO2nf2JarJIZ60i3F=") - the client is an Android 4.4.2 built-in E-Mail client (package name com.android.email). The client is now identifying to the server.
  3. Server: OK ID completed. - the server accepts the identification.
  4. Client: LOGIN username "password" - now the client just sends a LOGIN command, regardless whether the RFC 2595 explicitly states that it should not and regardless that the server does not even offer LOGIN.
  5. Server: BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed. - the server is shocked and screams that the client's password is now compromised since anybody could have intercepted the plaintext password.

Sniffing Passwords

Using tcpdump, the password can be easily intercepted at any node through which the traffic between the client and the server flows. For instance, by listening on the interface (eth5) through which the conversation takes place:

tcpdump -vvv -e -n -A -i eth5 port imap

the following password has been grabbed from an Android client at 95.173.136.70 authenticating to 23.206.132.14 on port 143:

08:55:45.018490 7c:0d:3c:7c:cf:dd > ca:ac:72:cf:94:e4, ethertype IPv4 (0x0800), length 110: (tos 0x0, ttl 63, id 33234, offset 0, flags [DF], proto TCP (6), length 96)
   95.173.136.70.4721 > 23.206.132.14.143: Flags [P.], cksum 0xae74 (correct), seq 243:287, ack 338, win 245, options [nop,nop,TS val 21873310 ecr 24724117924], length 44
E..`..@.?....f:..f;..................t.....
........564625 LOGIN username "password"

at which the IMAP server responds (shocked) that plaintext authentication is not allowed without SSL/TLS and that the password has just been compromised by the client:

08:55:45.018491 ca:ac:72:cf:94:e4 > 7c:0d:3c:7c:cf:dd, ethertype IPv4 (0x0800), length 319: (tos 0x0, ttl 64, id 40516, offset 0, flags [DF], proto TCP (6), length 305)
    23.206.132.14.143.143 > 95.173.136.70.4721: Flags [P.], cksum 0xfafb (incorrect -> 0x6a5d), seq 338:591, ack 287, win 235, options [nop,nop,TS val 24724117925 ecr 21873311], length 253
E..1.D@.@....f;..f:............B...........
........* BAD [ALERT] Plaintext authentication not allowed without SSL/TLS, but your client did it anyway. If anyone was listening, the password was exposed.
564625 NO [PRIVACYREQUIRED] Plaintext authentication disallowed on non-secure (SSL/TLS) connections.

Mitigation

He, he, told ya to stop using shitty Google products. You get what you pay for.

To mitigate the issue, perhaps it would be best to disallow STARTTLS through the standard IMAP port 143 and only offer SSL thorough IMAPs on port 993. At least this way the client does not automatically assume that, if port 143 is open, then it is an unencrypted connection and attempts to login by sending the plaintext password.

The Android E-Mail client is not to be the only affected product. It seems that an open 143 port is an invitation to E-Mail clients to consider that all traffic should be unencrypted, regardless whether STARTTLS is enabled, regardless that the LOGINDISABLED option is sent and even regardless that the IMAP server does not even offer the LOGIN option!


security/mitigating_password_disclosure_for_non-specification-compliant_imap_clients.txt ยท Last modified: 2022/04/19 08:28 by 127.0.0.1

Access website using Tor Access website using i2p Wizardry and Steamworks PGP Key


For the contact, copyright, license, warranty and privacy terms for the usage of this website please see the contact, license, privacy, copyright.