A Case for Questioning Defaults
About two months ago we started seeing massive memcached-amplified DDOS attacks on the internet. Attackers started abusing the UDP support of internet-accessible memcached servers running on port 11211 to substantially increase the amount of traffic they could deliver to a victim. There are a couple key attributes of the abused memcached servers that made this amplification attack so successful:
- They were open to the internet: Had they been on a private network or firewalled properly, attackers would not have been able to access them.
- They were running on port 11211: Uniformity of port allowed for easy discovery of vulnerable servers.
- UDP was enabled: UDP allowed for relatively easy IP spoofing, so the attackers could decide where memcached would send the massive response.
Why were all three of the above attributes true for so many memcached servers?
They were the defaults.
Default 1: Internet Accessible
This one isn't exactly a default, but is still a problem. If you want to set up a server on just about any popular cloud provider, the most straightforward way to make it accessible is to make it public facing, if only on the port you need. To make it more segmented, you have to start messing with whitelists, subnets, and CIDR notation. Your average web developer who just wants their database queries to be faster doesn't want to mess with all of this, and so we end up with lots of public facing servers on the cloud that have no need to be internet accessible.
Ideally, there could be a point and click method when creating a new cloud server to say "I want this server to only be accessible from this other server."
Default 2: Port 11211
Practically every service designed to be accessible via a TCP or UDP socket has a default port. Combined with the above, leaving this default in place enables trivial enumeration of like services on the internet (see Shodan). This is how attackers were able to find thousands of memcached servers; they just scanned for servers listening on port 11211.
If changing the port when setting up services was standard practice, these attacks would have never happened.
Of course, changing the port a service is running on isn't a security measure in of itself. It's purely obscurity; however, it will help prevent your service from falling victim to untargeted attacks.
The only ports that are better left as the default are those that are intended for the public to use; I really don't want to have to specify the port of each website I visit. :)
Default 3: UDP
The main developer behind memcached said it best:
probably a good time to ask; does anyone actually use the UDP interface for memcached? Last I talked to anyone who did was ten years ago. I'm thinking about gating it behind a compile flag and warning distro's to not re-enable.
UDP is not useless, but why have it enabled if you aren't going to use it? Had users gone through the defaults while setting up memcached and seriously considered each option, I would bet most would have noticed this feature and turned it off.
Takeaways
We, as an industry, need to do a better job at making security easier for developers. One of the best ways we can do that is making defaults as secure as possible. Furthermore, developers and admins need to question the default settings of services they use. Service providers and toolmakers will never be perfect, and we shouldn't assume that they always know best.
So my calls to action are:
For tool, library, and service makers
Set high standards for the defaults you choose; you are deciding the settings of most of your users. Do your best to make sure they will be using a secure product.
For tool, library, and service users
Question defaults, use non-standard ports, go through config files and tweak things. You'll have a more optimized experience, and who knows, you might have fun!