NICER Protocol Deep Dive: Internet Exposure of IMAP and POP

Last updated at Mon, 19 Oct 2020 13:04:45 GMT

Welcome to the NICER Protocol Deep Dive blog series! When we started researching what all was out on the internet way back in January, we had no idea we'd end up with a hefty, 137-page tome of a research report. The sheer length of such a thing might put off folks who might otherwise learn a thing or two about the nature of internet exposure, so we figured, why not break up all the protocol studies into their own reports?

So, here we are! What follows is taken directly from our National / Industry / Cloud Exposure Report (NICER), so if you don't want to wait around for the next installment, you can cheat and read ahead!

IMAP (143/993) and POP (110/995)

Hey, only 55% of email is technically considered spam!

WHAT IT IS: Internet Message Access Protocol, a stateful protocol nearly always used to read and send email, and Post Office Protocol, which operates essentially like a bulk download protocol for mail.

HOW MANY: 4,045,472 nodes running cleartext IMAP instances on TCP/143 and 3,848,675 nodes running ciphertext IMAPS. 4,331,314 nodes running cleartext POP and 3,714,171 nodes running ciphertext POPS.
3,240,919 75%) have Recog fingerprints (nine total service families)

VULNERABILITIES: Lack of two-factor authentication (2FA) in virtually all implementations can turn IMAP and POP into a serious password liability against focused attacks.

ADVICE: Ensure that IMAP and POP accounts are configured with an app-specific password. Consider dropping POP service entirely.

ALTERNATIVES: Whenever possible, prefer IMAPS, with its SSL wrapping, over IMAP.

GETTING: Better! Between 4% and 11% fewer mail client services are exposed than in 2019.

Discovery details

SMTP handles mail inbound to organizations, while POP and IMAP handle the action of individual users collecting that mail to read and reply to. As with SMTP, we've broken down the prevalence of cleartext versus encrypted versions of these services in the charts and tables below, both overall and by country and cloud.

While there are fewer choices in the end-user-accessible mail protocols, we were able to fingerprint IMAP servers by vendor:

With that said, we have very little telemetry on a per-version basis. IMAP and POP don't tend to reveal this information in a pre-authenticated way, and we don't have any good tricks in Recog to suss out versions with any sort of accuracy.

Attacker’s view

The charts below graph our honeypot connections to IMAP and POP, and while the spikes may, at first, seem like outliers, in fact, IMAP and POP probing seems to always be pretty spikey. For reasons unknown, these scans have a “high seasonality” in statistical parlance—they tend to come in bursts, rather than the usual constancy that we see in other protocol scans.

Over the course of the measured period, we saw about 7,500 unique usernames being tested for IMAP and POP.  The top 20 usernames tested are:

1. admin
2. test
3. webmaster
4. backup
5. info
6. marketing
7. contact
8. support
9. office
10. sales
11. postmaster
12. mail
13. abuse
14. service
15. spam
16. master
17. helpdesk
18. mailing
19. newsletter
20. recruit

Each of these were tried between 4,000 and 8,000 times. Interestingly, on most runs, each user name is tried precisely once, but sometimes, attackers try one username with 500 to 1,000 passwords in a given attempt.

Our advice

IT and IT security teams should routinely review the costs involved in running their own on-premises mail infrastructure, in terms of not just money, but time and expertise. If at all possible, they should see about moving off to a professionally maintained email provider, like Outlook 365 or Google G Suite (which offer TLS-backed client mail services by default), and reap the benefits of uptime assurance and spam-scrubbing being Someone Else's Problem.

Cloud providers should, similarly, steer people away from maintaining their own email infrastructure, and gently encourage customers to investigate the sane and stable alternatives. At the very least, cloud provider documentation should clearly explain the differences between POP and IMAP and why you might not need one or the other, then guide customers toward TLS-wrapped client mail services.

Government cybersecurity agencies should advocate for strong encryption alternatives to the cleartext IMAP and POP protocols, and educate the public on the fact that POP and IMAP are often convenient backdoors to password testing, since they are rarely secured with multi-factor authentication.