PROJET AUTOBLOG


Shaarli - Les discussions de Shaarli

Archivé

Site original : Shaarli - Les discussions de Shaarli du 23/07/2013

⇐ retour index

Neither Snow Nor Rain Nor MITM . . . An Empirical Analysis of Email Delivery Security

mercredi 28 octobre 2015 à 20:55
GuiGui's Show - Liens
« This security patchwork — paired with opportunistic encryption that favors failing open and transmitting messages in cleartext, so as to allow incremental adoption — enables network attackers to intercept and surveil mail. In one such attack, network appliances corrupt STARTTLS connection attempts and downgrade messages to non-encrypted channels. We identify 41,405 SMTP servers in 4,714 ASes and 193 countries that cannot protect mail from passive eavesdroppers due to STARTTLS corruption on the network. We analyze the mail sent to Gmail from these hosts and find that in seven countries, more than 20% of all messages are actively prevented from being encrypted. In the most severe case, 96% of messages sent from Tunisia to Gmail are downgraded to cleartext.

In the second attack, DNS servers provide fraudulent MX records for the SMTP servers of common mail providers. We searched for DNS servers that provide fraudulent addresses for Gmail’s SMTP servers, and we find 14,600 publicly accessible DNS servers in 521 ASes and 69 countries. We investigate the messages that Gmail received from these hosts and find that in 193 countries more than 0.01% of messages from each country are transited through these impostor hosts. In the largest case, 0.08% of messages from Slovakia are relayed from a falsified IP, which can intercept or alter their contents.

[...]


To find servers where STARTTLS is blocked, we build on the fact that SMTP servers frequently report back invalid commands they receive — which would include any corrupted STARTTLS command. We performed a TCP SYN scan of the public IPv4 address space on port 25 and attempted to perform an SMTP and STARTTLS handshake with responsive hosts. We performed this scan on April 20, 2015, from the University of Michigan campus using ZMap [19]. We found 14.1M hosts with port 25 open, 8.9M SMTP servers, and 4.6M SMTP servers that supported STARTTLS (see Table 10). Of the 4.2M hosts that failed to complete a TLS handshake, 623,635 (14%) echoed back the command they received. We classify these responses in Table 11. 617,093 (98.95%) of the responding hosts returned STARTTLS (and indeed do not to support it), 5,750 (0.92%) returned XXXXXXXX, 786 (0.14%) responded with STAR or TTLS, and 6 responded with BLUF. The STAR and TTLS commands are four-character command trun- cations and are likely not due to an attack. Prior to ESMTP, SMTP commands were all four characters, and we were able to confirm that all commands were truncated to four characters on these servers. However, the XXXXXXXX and BLUF commands appear due to the STARTTLS command being altered to prevent the establishment of a TLS session.

Excluding four-character truncations, our scan found 5,756 servers that display evidence of a corrupted STARTTLS command. However, given that only 14% of servers reported back the received command, this is likely an underestimate. We extended our search for servers where the STARTTLS command was corrupted in the server’s list of advertised features, which is returned in response to the EHLO command. This identified an additional 35,649 servers. When combined with the initial set, this yields a total of 41,405 servers that apparently have STARTTLS messages corrupted. These 41K servers are located in 4,714 ASes (15% of all ASes with an SMTP server) and 191 countries (86% of countries with SMTP servers). They transit mail for 2,563 domains in the Top Million. In 423 ASes (736 hosts), 100% of SMTP servers are affected by STARTTLS stripping. The AS performing stripping on 100% of the inbound and outbound mail with the most SMTP servers (21) belongs to Starwood Hotels and Resorts (AS 13401). We show the classification of ASes with 100% stripping in Table 12. Overall, no single demographic stands out; the distribution is spread over networks owned by governments, Internet service providers, corporations, and financial, academic, and health care institutions. We note that several airports and airlines appear on the list, including an AS belonging to a subsidiary of Boingo (AS 10245), a common provider of in-flight and airport WiFi. Our scanning methodology does not comprehensively find all servers where STARTTLS is blocked. Local SMTP servers may not be accessible from the University of Michigan, STARTTLS might only be stripped for outgoing messages, or the command might be removed altogether instead of being corrupted in place. However, it appears that the practice is widespread.

The XXXXXXXX replacements are likely caused by security products that intercept and strip the command. In one prominent example, Cisco Adaptive Security Appliances (ASA) [7] and Cisco IOS Firewalls [8] both advertise replacing the STARTTLS command with Xs to facilitate mail inspection as part of their inspect smtp and inspect esmtp configurations.

[...]

Internet-wide scans and logs of SMTP connections to and from one of the world’s largest mail providers over a sixteen month period. Our measurements show that the use of these secure mail technologies has surged over the past year. However, much of this growth can be attributed to a handful of large providers, and many smaller organizations continue to lag in both deployment and proper configuration. The fail-open nature of STARTTLS and the lack of strict certificate validation reflect the need for interoperability amidst the gradual rollout of secure mail transport, and they embody the old adage that “the mail must go through.” Unfortuately, they also expose users to the potential for man-in-the-middle attacks, which we find to be so widespread that they affect more than 20% of messages delivered to Gmail from several countries. We hope that by drawing attention to these attacks and shedding light on the real-world challenges facing secure mail, our findings will motivate and inform future research. »

Via https://twitter.com/aeris22/status/659290965023334400
(Permalink)