The security landscape is always changing. New features are coming out all the time, but often backward compatibility is maintained too. What this means is that while the new features may be present and active by default, it's possible for users to be completely unaware of them and continue using the legacy functionality.
SSH
Many years ago operating systems shipped with unencrypted remote administration features like Telnet, Rlogin, and RSH. SSH came out in 1995 and started out as a third-party package that you had to go out of your way to install, configure and enable. While SSH was inherently more secure, it was generally only used by more advanced users.
Come the late 90s and early 2000, operating systems started shipping with SSH by default, but they also kept the traditional plain text protocols because were familiar with them and comfortable with them. Although SSH was now present by default on an increasing number of systems, many users continued using the old unencrypted options because they were more familiar with them. Many of these users were not even aware that SSH existed, let alone that it was installed and active on their newly updated systems.
Around this time I had a close friend of mine who stated that he could tell me his root password, and I still would not be able to hack his Linux machine. Why did he think this? Because neither telnet nor rlogin allows root logins by default. The root user could only log in on the local console of the system, and as he was in another country at the time his presumption was that I wouldn't be able to do this.
Turns out he was wrong. He had recently upgraded to a newer version of Linux, and this one shipped with an OpenSSH service enabled by default. The configuration at the time did indeed allow the root user to log in via SSH, so furnished with his root password that's exactly what I did. Needless to say, he was shocked.
Another similar instance, was when the CRC32 vulnerability (CVE-2001-0144) in some implementations of SSH came out. We performed a test of a client, found a vulnerable version of SSH, and reported it. Their response came back "this is a false positive, we do not use SSH, we use telnet". In this instance, they too had upgraded some of their systems to a newer operating system that had SSH by default, but had continued using telnet and were not aware that SSH was now running. When the CVE-2001-0144 announcement came along they simply ignored it because they falsely assumed it did not affect them.
SSH was not the problem. SSH offers many benefits over telnet and other unencrypted login protocols, the problem here was that they had installed new software but blindly continued using legacy functionality and were totally unaware of the new functionality. Instead of switching to SSH, understanding it, and taking advantage of the benefits it offers, they completely ignored it. For many there was a kneejerk response of "disable SSH", but this was a fool's errand. SSH was clearly the future direction taken by all operating systems, even Microsoft now ships SSH with Windows, and most operating systems no longer ship with telnet by default - some no longer even have it as an optional install. SSH was not going to go away, and trying to fight against progress instead of moving with the times is never a good plan.
PowerShell
A similar case exists with Microsoft PowerShell. PowerShell came out in 2006 and was included by default with Windows 2008 and all subsequent versions. When it first came out, people either ignored it or weren't even aware of its presence. Typically only advanced users would explore this new functionality and find uses for it.
Amongst those advanced users were a lot of hackers. People soon realized that PowerShell was far more convenient for writing various attacking tools. PowerShell did not enable any new attacks that could not be performed before. It just made many things much easier and faster. So rather than writing complex native code for many tasks, people found that it was much easier to write PowerShell scripts. This is exactly what PowerShell was designed for, except malware authors were (as usual) ahead of users.
This flood of PowerShell malware prompted a kneejerk response. Users tried various ways to block PowerShell, remove it, prevent it from working. Many companies created policies that PowerShell was banned within their organization.
As always, trying to stifle new technology did not prevent attacks, all it did was handicap those users. Microsoft moved more towards PowerShell so that many things now become far more difficult to do if you don't use PowerShell.
Eventually, these organizations were forced to relent, rescind their banning of PowerShell and start implementing proper policies of using, configuring, and monitoring PowerShell. This, of course, is what they should have done right from the start.
IPMI
Modern server-grade systems typically have a lights-out management controller. These devices are extremely useful because they allow the sysadmin to gain full control of a server remotely irrespective of what state the operating system is in. You can even use IPMI to access a server that has no operating system installed at all, and use it to install the system from scratch onto totally blank drives.
But with great power comes great responsibility, IPMI controllers are a prime target for attack because they provide an equivalent of physical access to a server. Irrespective of how well configured the operating system on the server is if you can access the IPMI controller you can boot the system from virtual media that you control. This would allow attackers to access the hard drives directly just as if you were physically present in the datacenter armed with a LiveCD or bootable USB stick.
Older servers typically did not have IPMI controllers or they used a serial port as a simpler form of remote access which required you to explicitly set up a serial console server connected to the port. Newer servers on the other hand typically come with IPMI controllers which are enabled by default and often share a single network interface with the host system. As such unless you have explicitly turned IPMI off, the IPMI controller will be accessible via the network.
IPMI controllers may auto-configure an address via DHCP, DHCPv6, or SLAAC and could be assigned a routable address. In the absence of automatic address configuration mechanisms like this, they may still be accessible from within the local network via a default address, a link-local address, or a fallback APIPA address.
IPMI controllers like any computer system have been susceptible to a large number of attacks over the years. There are known vulnerabilities in older revisions of the IPMI protocol, vulnerabilities within specific vendor implementations, and in many cases devices ship with well-known default passwords.
If you deploy a modern server without being aware of and explicitly configuring IPMI, then the IPMI interface is likely to be sitting on your network just waiting to be attacked or worse - simply logged into using the default password. If you're not aware that IPMI is present you probably also haven't changed the default password, probably aren't monitoring it and you almost certainly haven't applied patches for any known security holes.
On the other hand, if you are aware of IPMI then you can configure it securely and take advantage of the benefits it provides.
IPv6
Now we see the same thing happening with IPv6. Any version of Windows since Vista ships with IPv6 enabled by default, and other operating systems typically enabled it several years earlier than Windows. If you drop a modern operating system onto a legacy IPv4 network it will still work because it still includes an IPv4 stack for backward compatibility purposes, but the primary networking stack is IPv6 and it will sit there active waiting to be connected to a modern IPv6 network.
Now this enables a number of potential attacks to be performed from within the local network segment.
Firstly all IPv6-capable devices have a link-local address starting fe80:: which is accessible within the local network segment. Most network listening services will listen on both IPv6 and IPv4 by default so these services can be connected to over the link-local addresses. However, it is possible for services to listen to only one or the other - either by binding to a specific address or by using local firewall rules to restrict access to one or the other.
If the system owner is not aware that IPv6 is active, then they may not apply local firewall rules to the IPv6 address. Similarly, they are unlikely to perform vulnerability scanning against the link-local address. There may be services that were not intended to be reachable, but which are reachable via the link-local address.
Another potential attack takes advantage of the fact that the default configuration for IPv6 is automatic configuration and IPv6 is the primary networking protocol. When active it will supersede any legacy networking protocols. You can simulate an IPv6 router, assigning a default route and DNS servers to any active client on the local network. As IPv6 is the primary networking protocol, the target hosts will now try to use your DNS server and route allowing for DNS hijacking and man-in-the-middle attacks to be performed.
These attacks are extremely common because despite being the default for more than 15 years many users are still unaware of IPv6 and still continue placing modern hosts onto antiquated legacy networks. When we find such vulnerabilities and report them, we are often met with a response of "we don't use IPv6". This is again a classic case of lack of awareness, if you've deployed any operating system made in the last 15 years it does indeed use IPv6, and the fact you didn't realize that is the sign of a major problem.
What makes matters far worse is that if you're not aware that you have IPv6, then chances are you're not going to perform vulnerability scans or testing against the IPv6 addresses. Serious vulnerabilities may go undetected, and your scan results will only serve to reinforce your own lack of awareness.
Again we also see the classic kneejerk response of trying to disable IPv6. This, just like the attempts to disable SSH and PowerShell is only going to cause additional cost and inconvenience. IPv6 is the future, it is the direction all of the major OS vendors are heading in. Microsoft considers IPv6 a critical component of Windows and Apple doesn't provide any way to disable IPv6 through the standard UI. Some functionality breaks if IPv6 is not available, other things require reconfiguration and because IPv6 is the default, most software is being written assuming that it's present and may fail if it's not. Attempts to disable or block IPv6 may also get reverted when you install updates. Trying to disable IPv6 is an uphill battle, and it won't solve the root cause - your own lack of awareness and experience. And sooner or later you would be forced to deploy IPv6 anyway, which would then mean undoing all the mess you made trying to disable it.
On the other hand, many organizations have successfully deployed IPv6 already and several major world governments are making a serious push towards not just deploying IPv6, but also entirely removing IPv4. When properly configured, IPv6 is often more secure than IPv4 and is never any worse.
TL;DR
The true solution then is to solve the lack of awareness. Instead of ignoring new technologies and trying to stay in the past, embrace new technologies, learn about them and how they can benefit you. Move forward, not backward.
