Some of the most common vulnerabilities are those we create ourselves. In this video, you’ll learn many different ways that misconfigurations can weaken the security of our networks.
One very easy way to get your data into the hands of the attacker is to simply leave all of the information sitting in an open area of the internet. Surprisingly, this happens very often on the internet, so much that the attackers will use this as a method of reconnaissance to see if someone may have put some data on a cloud service and simply forgotten to secure it. They know that eventually, they’re going to run across some data that someone forgot to secure. And from there, they can easily download it and disseminate it to others on the internet.
A popular example of this occurred in June of 2017, when 14 million Verizon records were found on the internet, open and available to be downloaded. A third party had left an Amazon S3 data repository open without any type of passwords or security. Fortunately, this information was found by a researcher and not an attacker. So they were able to close this particular security loophole and confirm that no one else had downloaded any of this information. Although this story turned out to be rather insignificant for the 14 million records that were exposed, there are many other examples of information being made public on the internet without the intention of the data owner.
Another security challenge is with unsecured admin accounts. This, in the Linux world, is the root account. In Windows, this is the administrator account. And sometimes, we refer to both of these as the superuser account.
Usually, there are methods built into the operating system that would prevent you from creating a root or administrator account with no password on it at all. But unfortunately, administrators will often assign a very easy to guess password to the root account, a password like “123456” or “ninja” or “football,” which makes it very easy for an attacker to brute force a password on this root account.
A good best practice is to completely disable the ability to log in with the administrator account. This means you would first have to log in with your normal user account and then use an elevated access by using the su or sudo option to be able to get a root account access. This is very similar in Windows, where you would log in with your user account. But if you needed to run something with elevated access, you would use the Windows feature to run as administrator.
Ideally, you should have very few accounts that have root or administrator access. This would certainly limit the scope of an attack and make it much harder for an attacker to even find an administrator account that they could then compromise.
So far in this course, we’ve talked quite a bit about encryption, encryption algorithms, and ways that we can protect data when we’re sending it across the network. But this encryption isn’t going to help very much if we use protocols that don’t take advantage of any of these encryption technologies. Protocols such as Telnet, FTP, SMTP, and IMAP send all of their traffic across the network in the clear. You would need to use the secure versions of these protocols to be able to enable encryption and other security features.
One way to tell if the data you’re sending across the network is secure or insecure is to simply perform a packet capture. I have the results of a packet capture on the screen here. And you can read everything that is listed in this particular packet. And we know that we can read everything because right at the top, you can see that the protocol that we’re using is HTTP and not HTTPS.
This means we can see information about which version of browser is being used, the referral URLs, information about the cookies, and any other information that’s transferred between these two devices. This is something that a quick packet capture in Wireshark can easily display in the clear data. And it might prompt you to use more secure protocols, such as SSH, SFTP, HTTPS, and others.
This is a picture taken at DEFCON 22, which is a security conference. At this conference, they are constantly monitoring the traffic going across their wireless networks. And if there are any insecure protocols, such as HTTP, IMAP, or POP3, they will pull the data out of those frames, show you the email addresses, part of the passwords associated with this transaction, the IP addresses, and other information that was sent over the network in the clear. They refer to this as the “wall of sheep.” And you can see that there’s a lot of details that are listed when you send this information across the network without any encryption or additional security.
If you’ve connected a device to the network for the first time, you were probably prompted for a username and password. And of course, there is a default username and password for all of these devices. Some of these devices will prompt you to change the password the first time you log in. But a great deal of devices have no security associated with the username or password.
There’s a botnet that takes advantage of these default accounts. It has a list of all of the default account names and passwords for every Internet of Things, or IoT, device that you can think of. There are more than 60 default configurations that this will look for on your network, including cameras, routers, doorbells, garage door openers, and anything else that connects to the network. If this botnet finds one of these devices with the default credentials, it’s able to gain access to that device and then provide the attacker with information on where they can connect as well.
This is also software that anyone can run because the Mirai botnet has been released as open source. So both researchers and attackers are using this open source botnet to identify places where the default credentials may still be in use.
Each time you enable an inbound service on a server, you are opening a port number. That port number is used by someone on the outside to gain access to that specific application. This process of opening port numbers is effectively giving someone a little bit of access into a section of your server. So it’s important to limit the number of open ports that might be accessible by others.
We will often manage this type of access to port numbers using something like a firewall. This gives us the option of allowing or disallowing access to a specific port number on a specific IP address. Unfortunately, this also adds a level of complexity that might cause a security issue. These firewall rule sets tend to be relatively large. And it’s very easy to accidentally provide access to a specific IP address or port number.
This means that the firewall administrator may have enabled access to a device that normally should not be accessible. And of course, if it’s open, the attackers are bound to find it. This is why we should always schedule periodic audits to make sure that our firewall rule base is in good shape and we’re limiting the number of open ports available on our network.