Insecure Protocols Still Litter the Internet

Written by

When the foundations of the modern internet were laid in the 70s, people didn’t trust each other much more than they do now. They certainly did not leave their front doors standing open at night in case the neighbors wanted something.

The internet was developed by academics and engineers, though, who did just that when putting those early designs together. Recently, Rapid7 released its National/Industry/Cloud Exposure Report, taking a deep dive into the internet protocols still in common use today. It found that there are still a lot of doors without locks on them at all, with many clear text protocols still putting users at risk.

Examples include Telnet, the remote command line access protocol, which almost always exposes both the authentication data and the content in clear text. Another is rsync, a synchronization protocol that the authors call "an accident of early internet engineering". Almost a quarter of a century old, that protocol has no encryption at all at its core. Enhancements have introduced encrypted authentication, but the session data still travels in clear text.

Some of this code is remarkably clean, suffering from few if any vulnerabilities over the years. Telnet has relatively high-score CVEs, for example, but as the report points out that's because it “makes little to no security assurances at all.” If you don’t promise security, then you can't be accused of violating that promise.

FTP has long been known to have vulnerabilities. The newer version, FTP/S, uses SSH to secure logins. Unfortunately, it still sends the session content in clear text (and hardly anyone uses it). SFTP or secure copy (SCP) are better.

Some protocols that have been properly updated with encryption aren't being used ubiquitously. The most important one is HTTP, the protocol that web servers use to deliver content to browsers. Browser vendors and search engines have made a strong effort to encourage the use of the encrypted HTTPS version and penalize stragglers. They have made great inroads, but HTTP usage is still slightly dominant with 51.5 million discovered HTTP nodes versus 36.1 million HTTPS ones.

The Simple Mail Transfer Protocol (SMTP) is clear text by default but there’s an SSL-wrapped version called SMTPS. There are still many servers (5.8 million of 13.3 million) running vanilla SMTP over port 25, which isn’t encrypted by default. Of the 7.9 million servers using IMAP, an alternative for reading and sending email, 4 million did so in clear text.

There are other services like DNS, which was originally designed to support only clear text, but which vendors are now redeploying with encryption in mind. Uptake of these is still relatively small, but growing.

There are some well-established protocols that are both free and well-designed, foregrounding encryption. One of these is SSH, commonly used to automate server access. This can also solve the encryption problem for some other protocols like rsync. Rapid7 recommended rsync as a file transfer and synchronization protocol but only when used over an SSH session.

Be careful with SSH, though, as it’s still subject to human error. Key management is a perennial problem. Developers frequently expose their SSH keys by mistake in GitHub repositories, for example, enabling others to find and use them. Locking all those open doors is great, but you have to be sure you don’t leave the key sitting on your front doormat.

What’s hot on Infosecurity Magazine?