Common Security Issues – CompTIA Security+ SY0-501 – 2.3

The most common security issues can create some of the most uncommon security breaches. In this video, you’ll learn about the most common security problems and how to avoid becoming falling into these common traps.

<< Previous Video: Command Line Security Tools Next: Analyzing Security Output >>


We often put a special emphasis around protecting data that goes over our networks. A good example of this is the authentication process. We’re providing a server with our username and password. And we want to be sure nobody can see that information as it’s going across the network. But of course, protecting data isn’t just about the authentication process. It’s also about the applications that we use. And there are some protocols used in these applications that send information in the clear, with no encryption at all. For example, Telnet console information, FTP for file transfers, and for mail transfers you have SMTP, and IMAP, which are both protocols that transfer information in the clear.

If you’re ever wondering if the communication that you’re sending is encrypted or not, you can always capture the packet yourself and have a look. Very similar to the packet capture that I did here. Simply grab Wireshark or another packet capture application, capture the data, and see if you’re able to read the information within the data part of the frame. If you’re not going to analyze your data going across the network, I guarantee you that someone else will.

For example, this is the Wall of Sheep, presented at DEF CON. This is one where an automated process is simply watching the wireless network, and it’s able to provide information about the applications, the users, the usernames, and the passwords that are sending information over the network. Here’s a closer look that shows the login name, an obfuscated version of the password, they aren’t going to show the entire thing, the embarrassment of having it presented on the wall of sheep was enough, the IP address that was in use, and the application that was sending this data across the network in a non-encrypted form.

Most security professionals will gather as much information about what’s going across the network as possible. They’ll collect logs from routers, and switches, and firewalls, and intrusion prevention systems, and servers, and application devices, and anything else that can provide them with information about what’s happening on the network. All of this information can be consolidated back to a single repository. This is your security information and event management system, or your SIEM. The SIEM is not just a single repository for this data. It can also perform some analysis of the information and begin correlating together these very diverse data sources.

A number of these logging systems can also identify anomalies. These are logs taken from my web server, which are identifying cases where someone from, in this case Dublin, Ireland, is trying to upload certain files to my website. And they’re not only uploading certain files, they’re uploading it to plug-ins that have known vulnerabilities. What’s interesting about these is I don’t have these plug-ins on my web server. So this would, obviously, be an anomaly to have someone trying to access a vulnerability for a plugin that doesn’t actually exist. You can see in each instance where someone was trying to take advantage of the known vulnerabilities in these plugins. But because these plug-ins did not exist on my server, these were obvious cases of an anomaly.

Another common security issue is a simple permission problem. This is one where a certain set of files are put onto a server, but they are not protected properly by the server software. For example, in June 2017 Verizon put 14 million records out on an Amazon cloud repository, and a researcher happened to come across all of this data. Verizon was able to check the logs and see that nobody had gained access to this information, even though it was placed onto the internet with the incorrect permissions. Their permissions on this data should have been checked when they were initially uploaded to the Amazon cloud. And there should have been a process in place to perform periodic audits to make sure those permissions had not changed over time.

A segmentation fault is an error that occurs on your operating system when an application tries to access part of memory that it should not have access to. Your operating system is constantly performing checks, and making sure that applications aren’t going outside the bounds of what they should be doing. This might be something as simple as a programming problem, where the application developer is simply pointing to the wrong part of memory. But occasionally, this can point to a security problem, where a third party application is trying to access memory that normally it should not have access to. The segmentation faults can occur across many different operating systems. It doesn’t have to be Dos or Windows. It could even be something as simple as a credit card authentication terminal.

Another common security issue you might run into is relating to the certificates that were use to either identify a device, or to provide encryption between devices. The trust of this certificate is what all of our devices and applications rely on. These certificates should be signed by someone we trust, such as an internal certificate authority, or an external certificate authority that’s trusted by the applications or the browsers that we’re using. It’s also a good idea to periodically update these certificates.

Some organizations will update their certs every three months or every year. And it’s always a good idea to make sure that you don’t let the certificates get too old. Once you have these certificates in place, It’s also important that the applications that are using these certificates perform the correct checks to make sure the certificates are valid.

I mention this because in February of 2017, a researcher thought to go through a number of iOS applications to see if the applications were actually checking the certificate. This researcher found there were 76 iOS applications that were active in the Apple App Store that were not performing the proper checks on the TLS certificates that were installed for that app. These 76 applications amounted to over 18 million downloads. And without performing the proper certificate checks, that meant that someone could sit in the middle of this encrypted communication with the man in the middle attack and be able to view all of the data going back and forth between the end user’s device and the server.

The data that we have stored in our organization is extremely valuable, not only to us, but this data could be valuable to someone else. And the bad guys want to be able to somehow get the data that’s on the inside of your network and exfiltrate it to the outside of your network. You’ve already made this relatively easy for many of the bad guys, since they can use the existing high- speed internet connection. But we’ve seen a number of cases where people will store this information on DVD ROMs or flash drives, and simply walk it out of the building.

One of the exfiltrations that appears to have occurred across the network happened in July of 2017. This was with Time Warner and their Home Box Office division, where 1.5 terabytes of data was exfiltrated. This exfiltration appeared to contain a number of programs and series on HBO. And HBO commented that they recently experienced a cyber incident which resulted in the compromise of proprietary information.

We spoke earlier of leaving our digital doors open by not assigning the correct permissions. But you can also perform the same type of open door by misconfiguring the devices on your network. For example, the routers and the switches that are on your network have a default username and password. And normally, when you’re installing these devices one of your first steps is to change both the username and password to something that no one could easily guess. But if you leave the defaults in place, this would make it very easy for someone to authenticate to those devices, and begin changing the configurations.

Another misconfiguration might be the use of outdated software. Especially, if that outdated software has known vulnerabilities that someone could then use to gain access to the system without even using a username and password. Another misconfiguration might be the use of running debug or maintenance code on a device. And when that device is used, it provides the end-user with more information than would normally be available. And that might give the bad guys enough information to gain access to those systems.

Another type of misconfiguration that might be difficult to identify, is in a firewall. Some organizations might have hundreds or even thousands of rules in their firewall rule base. And it becomes difficult to perform an audit to know exactly what kind of traffic might be allowed through the firewall, and what traffic might be blocked by the firewall.

Other devices may not provide enough configurations. For example, a URL filter may not provide a specific enough URL to provide blocking. And in some cases, the URL filter might not block anything using a particular protocol, such as HTTPS.

And on our wireless access points, we need to make sure that we provide the proper encryption mechanisms, so that all of the data going over the wireless network is encrypted. And make sure that the protections for managing this device are such that you can’t access the management console from the wireless side. The security technologies that we’re using today work extremely well. But we may find that in 10 or 20 years, we may not want to be using those same security technologies to protect our networks of the future.

A good example of this is the Data Encryption Standard encryption, or DES. This was created in 1975, that used 56-bit keys. The keys were so small and the encryption mechanism was relatively simple compared to what we use today, that we could easily brute force a desk key using today’s technologies. So you’ll find that many of the technologies we use today are no longer using this older desk encryption mechanism.

Sometimes we will find a flaw with the technology. For example, the encryption technologies we initially used on our wireless networks used Wired Equivalent Privacy, or WEP. We found that this 802.11 security technology had a cryptographic flaw. So everyone migrated away from WEP and changed all of their encryption on their wireless networks to WPA2.

And another weak security configuration would be to use a hashing algorithm that was susceptible to collisions. A collision is when you might have different documents that have exactly the same hash associated with them, which makes it very difficult to verify that nothing inside of that document might have been changed. A good example of this was with SHA-1, the Secure Hash Algorithm 1, where hash collisions were found. And we decided to migrate away from SHA- 1, and use other hash algorithms that were not susceptible to these collisions.

When we configure a router, or a switch, or a firewall, we know those devices are going to do exactly what we tell them to do. It doesn’t work exactly the same way with the people inside of your organization because human beings are susceptible to making mistakes. We sometimes will see this when somebody violates an Acceptable Use Policy, or an AUP. We can find the policy violation and see that somebody transferred some data or visited a website they should not be visiting.

Part of the problem with these personnel issues is that we’ve spent a lot of time and a lot of money making sure that the borders of our network are very secure. That link between us and the internet has firewalls and intrusion prevention systems and other security technologies in place. But once you get to the inside of the network, it becomes a lot easier to move around freely. There aren’t as many security technologies in place on the inside of the network. And so if somebody is an employee, they become an insider threat. They’re able to move around the network a lot more freely than someone who’s on the outside. And because they’re already authenticated, they already have access to a number of the resources inside of your network. This is why it’s important to make sure that everybody’s being assigned just the right amount of permissions to be able to perform their job. So that nobody is able to gain access to data that they really should not have access to.

Human beings are also susceptible to being fooled. We see this often with social engineering, where someone might make a phone call and try to gain information about the inside of the network, or ask someone to give up their username and their password. The people using these social engineering techniques know that most people would like to help. And they use that to be able to steal as much information as they can. Sometimes you don’t even have to contact anybody in an organization. They will simply post the information publicly available to everyone. We see this often on social media, where internal information might be made available to anybody on the outside.

Many organizations already have a policy that prevents someone from posting this kind of information. And often, it’s a centralized function based around a marketing or communications team within the organization. And our email systems provide another security concern for personnel. Anybody who posts anything or sends an email to a third party, is effectively sending this on behalf of the organization. And of course, it’s very easy to attach information and send that data out over email.

If you’ve ever worked for a company that has a controlled environment for their computers, you know that they’ll tell you that you’re not allowed to install unauthorized software. That’s because the IT department doesn’t know where you received that software. It’s not been tested in their environment. And it could potentially include malware, spyware, viruses, ransom-ware, or other types of malicious software.

Third party software could also potentially create a conflict with important software that you use within your organization. You may be using a very important application. And by installing a piece of third party, it may cause that application to no longer function properly. There’s also a concern that the software has to be purchased and licensed properly. So the IT department often likes to centralize this function, to know that all the software that they’re using is legal.

And of course, there’s a need to provide ongoing support of the software. When a new version is released, there needs to be a new version installed on your computer. If there’s a security patch, there needs to be a process in place to install that security patch. And all of these support issues become very important as time goes on.

The IT department and security teams like it when everything is documented. Everything is a known quantity. You know exactly what to expect. You can look at a user’s workstation or their laptop, and you know exactly the way it should be configured. There should be a way to identify when changes occur, if that change is something that a user has done, or if that change is something done by a malicious piece of software. Alerts can be sent the information technology team and the security team, to be able to identify why that change occurred. And if that change is something that should be considered part of an attack.

We often see these devices analyzed for changes during a VPN connection. We have all of these devices on the outside of our network. And when they initially connect to the inside of the network over the virtual private network, there will be a series of tests performed, to make sure those devices are running anti-virus, that they have the latest signatures, that all of their operating system patches are in place, and those systems are secure to be let inside of the network. If these devices don’t match the baseline that has been set by the security team, they’re quarantined and given a chance to make the proper changes before gaining access to the internal network.

Software licenses can become a significant security issue. There are licenses associated with every piece of software we’re using. It could be an operating system or an application. And even hardware appliances have software running on them that require a valid license. Each one of these different technologies requires a different form to purchase the license. And it’s a different method to enable the license on that device. From a security perspective, we want all of these devices and applications to always be available. If the license suddenly becomes invalid, we may find that an application may stop working completely. And from an integrity perspective, we may find that an invalid license may only allow an application to work part of the time. Or some of the data may be available, and other parts of the data may not be. That’s why it’s so important to make sure that all of our licenses stay in compliance.

We also need some way to track the assets that are used in our organization. This is something that’s usually an automated process. And something that’s constantly updated in a master database. This allows us to respond faster there’s a security issue. We know on a laptop, exactly what software is installed, what operating system is running on that particular device. This is also a way to keep track of where your most valuable assets might be. You know exactly where your mobile devices, your laptops, and all of your desktop devices may be located. This is a good way to also track licenses. So if you’re trying to make sure that all of these devices stay up to date with all of their software licenses, you can do it based on these automated asset management systems. This is also a great way to make sure that all the latest security patches have been installed, that all of the anti-virus signature updates are in place and working, and you can make sure that all of your systems stay as secure as possible.

Authentication is also a common security issue. This is used by every single person who is connecting to the network. They’re providing a number of authentication factors, such as a username and password, a thumbprint, or a one time access code. If any part of this authentication process fails, you may find that people are not able to gain access to the resources they need. Or perhaps even worse, we allow people who don’t have the proper access into parts of the network, where they never should have gained access.