Vulnerability and Attack Surfaces

0:06Hello and welcome. My name is Keith Barker. And in this set of videos, you and I get to chat about vulnerabilities, or weaknesses, and attack surfaces where vulnerabilities could be compromised. So an attack surface is, pretty much, if we boil it down, any time we have data, information that's moving into or out of the system, over a wired network or a wireless network, through an app or what have you, that's a potential attack surface if we have a vulnerability. And if an attacker finds that vulnerability or discovers it, they could leverage an exploit and compromise us with that.

0:38So in this set of videos, I'd like to talk about vulnerabilities and attack surfaces and also where we should look for him. Because it's not just for breakfast anymore, meaning, it's not just on-prem at our facilities. If we have cloud services, we're not exempt from attack surfaces. We need to be aware of that as well. I also want to share with you some techniques and programs that we could follow that help reduce our vulnerability, reduce our risk, and make us more secure overall. So I look forward to this journey together with you. And in the next video, I'd like to continue by taking a look at vulnerabilities that are not just on-prem, but also vulnerabilities as they exist in cloud services as well.

1:13And we'll tackle that in the next video. So I'll see you there in just a moment.

0:00A lot has changed over the years. That's absolutely true. But the concept of vulnerabilities and threats, they're still there. They're just getting more and more prevalent. In the old days, we had to buy a physical server, put it on the operating system, install the applications, then set them up either locally or in a rack in a data center. Now, today, we have more options now, including cloud-based services and on-prem, meaning, having our gear in a local data center. And a vulnerability, when we boil all down, it's just really a weakness that could be, again, those "could be" compromised.

0:35And an exploit is the thing that's going to take advantage of the weakness. And the risk is the likelihood that it's all going to happen, resulting in a loss. An example would be this. Let's say we have an application that interacts with a SQL database on the back end. And there's no input validation on the data that's provided by the users, such as their username and password. So the application is not doing any checking whatsoever, looking for wacky characters or slashes or less than or greater than symbols or dashes or anything else. It's not checking any of that.

1:06Now, the vulnerability is that an unauthorized person, if they do a SQL injection attack, they could view or modify or even delete the entire database. And the exploit would be the attacker using a tool that-- first of all, they discover the vulnerability. That it exists. And then they use some tool to compromise our data. And what I'd love to do is demonstrate how easy it would be for a hacker to compromise a system if the application that they were using is vulnerable to an injection attack. Now, this web page here is courtesy of OWASP and their Broken Web Application Project.

1:42Every year they come up with a whole list of the top 10 web application vulnerabilities and how to prevent them as you're writing code. But this application and this set of applications is intentionally weak and has problems. So if we wanted to log in, now, normally, if you want to log into something, you'd click on Login. You'd supply a username, like, Keith or whatever. Let me take off the caps lock there. I'm yelling. Like, Keith, and then I'll put in my password. Press Enter. And oh, bummer. The account doesn't exist.

2:12Now, just that alone, by saying the account doesn't exist, that's not good because an attacker, if they're doing an attack against this application, could just go over and over again just looking for valid usernames, let alone whether or not the password is correct. And then if they have a valid username, then they can further go ahead and try to attack the password with a password cracking attempt. Or if they've done some reconnaissance and they know that there is an injection flaw based on input validation or the lack of input validation, it's possible to log in without even providing a valid username.

2:46Check this out. If we go to OWASP here and go to Injection SQL, and then bypass authentication, here it's going to give us tips on how we could go ahead and do a bypass of the authentication. So we click on Help Me! It talks about SQL injection and how some of their attacks work. I'll go ahead and close that. And then over here, if we click on Hints, and we click on SQL Injection, here it talks about one way of bypassing authentication. And that's by taking a single open quote, space, or space 1 equals 1, which is-- does 1 equal 1?

3:18Yes. And then a space and then two dashes. And I'm going to just copy that. And I'm going to put it in Notepad. So I'll go ahead and paste there, and make that a little bit bigger, too. And then I'm going to take that because I want it without any kind of special formatting that the HTML may have given me. I'm going to right-click on that, copy it. And let's go back and log in. So on the login page here, instead of putting in a username, I'll just go ahead and right-click, paste in the password field. And basically, because of lack of input validation, this application is going to be basically tricked into allowing me to log in.

3:51Even though I didn't supply a username, it's going to have me log in. So I'll click on Login. My browser says, do you want to save your password? Doesn't matter. I can use that injection attack again. And check it out. We're now logged in as admin on this application. So an attacker could discover, based on this application, that it has a flaw, and then exploit it by actually logging in with that flaw or using an application that logs in. And then once they're logged in as admin, who probably has full access to the system, this application has now been compromised by the attacker based on an injection flaw that the hacker took advantage of.

4:28So as we consider vulnerabilities, a weak application that doesn't do the proper checks is absolutely an attack surface. And so if you want to put a pretty broad stroke on it, an attack surface is the sum of all paths for data in or out of our system or application. And as a result, we need to consider that when our systems are running on other people's gear as well, as in the case of cloud services. So a server may have network connectivity, as I mentioned, either via wireless or wired. That same server may have physical ports, such as USB ports.

5:01And the server may interact with many other systems and back-end servers using APIs or application programming interfaces. So all of these paths into and out of the server are potential attack vectors, collectively referred to as the attack surface. Now, when we're using cloud services, somebody else is taking care of the physical gear, or depending on the type of service, perhaps even responsible for all the applications and services. An example would be cloud-based storage as a service that we might use. So we think, oh, somebody else is handling all that.

5:33However, we still have a lot of responsibility and should be concerned about weaknesses, aka vulnerabilities. Because if somebody steals our files, what are the risks? And so solutions to help protect the data is to use encryption. So that way if the information is stolen, the attacker would not have the keys to unlock the data. And many of the same on-prem vulnerabilities also affect cloud-based systems and services. And besides, cloud-based systems may introduce new vulnerabilities. So here are some questions that we would probably want to ask for both on-prem as well as cloud services.

6:09So here are some of the questions we should ask. Where is the data geographically being stored? Is it stored in the same state or country that we live in? Or is that data required to reside in a specific geographic location? Another question would be, how is it backed up? And are we doing full backups and then differential or incremental backups? And have we tested it? And that's critical to both know and test because we can't really be sure that data backup is functional and working until we test it.

6:40And we should test it periodically, perhaps every six months or once a year. I was doing some work for a bank that had a fault-tolerant disk subsystem. And I asked them because they were telling me about it. I said, are you sure it's fault-tolerant? And they said it was. So after scheduling some downtime and doing a test, it was discovered that there was a misconfiguration. And a loss of any one drive caused the failure of the whole system, even though it was supposed to be a rated level five storage system. The moral of this story is that testing can help verify functionality, including when something has changed.

7:15So an example is any time there's an update or a patch or some modification, it's wise to test it in a test environment prior to rolling it out into production. So another great question to ask is, which security vendors-- we're using cloud services-- which security vendors and methods are in use? And do those security measures work to protect the data against the most likely vulnerabilities and exploits that we're expecting? And many applications and systems use application programming interfaces or APIs to interact with other systems.

7:48An example would be network automation, one of my favorite things, where we use a controller to interact with all the network devices. And they use APIs to do that. So the negative side is if there is a weak or missing security regarding the APIs that are used, then it would be possible for an attacker to use those same APIs to compromise our network with our own APIs. And that leads to the next question regarding which API methods are in use. Are they requiring appropriate authentication? And remember, the attack surface is the sum of all paths for data into or out of a system or application, including APIs.

8:26Now, what else should we be considering? Oh yeah, another great question for security is what is the underlying OS, the operating system? And are there host-based based or network-based firewall services available to protect it? Because a lot of times, we might have a system that is built on top of some other operating system. And if that lower level operating system has a vulnerability that we aren't paying attention to because we just forgot about it, that would be important to know about. Another great question to ask is what encryption methods are in place, if any, on our systems and on our data?

8:58And that includes data in transit, going over the network, and data at rest. And also, regarding availability, what are the fault-tolerant options or high availability options that we have for our systems and for our data? And do they work? That's another critical test. So in short, for on-prem or cloud services, we want to know the answers. We want to ask those questions and know the answers to those questions with an eye towards what types of vulnerabilities and associated risks we may encounter as a result of those vulnerabilities.

9:28Now, even with proper precautions in place, a compromise may occur by a brand new vulnerability or a recent attack that is not yet known to the general public. And that's known as a zero day attack. And that's what we get to talk about in the next video. So I'll see you there in just a moment. Meanwhile, I hope this has been informative for you. And I'd like to thank you for viewing.

0:00[MUSIC PLAYING] We may have multiple layers of defenses in place, including antivirus or anti-malware software, both on hosts and servers. We may have next-generation firewalls-- grrrr-- with application layer inspection looking for and filtering out malware. However, these devices and systems, they could miss an attack because the attack as of the time it's used may be not yet known to the vendor or the general public.

0:32And that could be a new attack method, new malware, or a combination of both. And this is referred to as a zero-day attack. And a lot of times it's helpful to use the internet as a resource tool, and also third-party products and vendors that are collecting. Like, if we have an antivirus or anti-malware company that has thousands or hundreds of thousands of devices listening to the network, looking for malware and viruses, and so forth, and then reporting it, it'd be awesome to leverage some of that. And part of that is proprietary. And then part of that is open source intelligence.

1:03This website, which is talosintelligence.com, is from Cisco Systems. It is their cloud intelligence ARM that they integrate in many of their products. They're just one of the vendors that do it. Checkpoint does it. Palo Alto does it. And other companies do it as well. But one of the features they have here under Vulnerability Information is they've got options for zero-day vulnerabilities. And that way it's a place we could go to learn more about zero-day or brand new vulnerabilities that are hot off the press. And if we scroll down a little bit-- I'm trying to make this a little bit bigger-- and if we scroll down a bit and click on View All Zero-Day reports, so here it has zero-day reports and disclosed vulnerability reports.

1:43And that's why it's so important to have defense in depth and multiple layers of security, and not just rely on the attitude of, oh, it's crunchy and hard on the outside like a firewall and then soft and chewy on the inside because so many attacks happen inside because once an attacker compromises the network and gets in, or does social engineering and compromises the human and gets in, they can then use that device that they've compromised and pivot. And they can move laterally and find other devices to compromised and then continue the attack.

2:13So it's important to identify our vulnerabilities that we have, that we know about. Put the appropriate countermeasures, which often involve hot fixes or patches or devices in front of our systems that are protecting them from the incoming attacks. And that's referred to as mitigation or defending or putting a control in place to help compensate for the vulnerability. So if we can get rid of the vulnerability altogether, that's awesome-- best option. But if we can't completely get rid of the vulnerability, we also might have some other type of a control, like, a firewall that could help defend against the vulnerability that the system or the application or the network has.

2:47So here under Disclosed Vulnerability Reports, if we just grab one and click on it, it'll give us more details about it, including the CVE number, which stands for common vulnerability and exposures. And then we can scroll down for additional information about this vulnerability. And so if we had Linux, for example, in our environment, a certain flavor of Linux running Apache and a certain flavor of that, and then there was a new vulnerability discovered, hot off the press, regarding that, we'd want to take steps to put in a countermeasure to help protect that system against that vulnerability.

3:17And then eventually, when a patch is created and released, we'd want to apply the patch, which, again, reduces or removes the vulnerability on that system. So the concept of a day-zero or zero-day attack is that nobody knows until after the attack occurs. And then the steps are taken to correct it. And that, again, is why having defense in depth with firewalls and intrusion prevention systems, IPS devices, both in the network and on the critical host, and also using the concept or the idea of least privilege or least access, and having those rules in place, are essential.

3:50And that way the user isn't helping to propagate some vulnerability just based on too many privileges that they currently have as they're logged in. While we're talking about users, practical end user training and verification that that training is taking place and that they understand, that is also critical to keeping our environments absolutely secure. Now, one of the reasons, in general, that vulnerabilities are so prevalent is gravity, like, inertia. Like, if there is an operating system that's been deployed as part of an Internet of Things device, maybe a real-time operating system, or an older version of Linux or something that people have just forgotten about or whatever, if it just sits there and then an attacker discovers, hey, I've got a million of these Internet of Things devices that are all running this version of Linux, and it has this vulnerability, away they go because it's the default.

4:36And oftentimes, we forget about many of those things. Also, the configurations are often very, very weak because when a vendor deploys something, they want the user, the person who buys it, to be able to bring it up, get it installed, and have functionality. And their biggest concern is on functionality and not security. So one of the challenges is overcoming some of those default deployments which have a weak configuration as a default or as a baseline. And that is what we are going to talk about in the next video. So I'll see you there in just a moment. Meanwhile, I hope this has been informative for you.

5:08And I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Hello and welcome back. So let's ask the question, what is and what causes a weak configuration? And the answer to that is a lot of the vulnerabilities come from using the default settings, including default passwords for the root or admin account. If they're not changed, they are easy to look up and they are a significant risk. And that's because rooter admin accounts have open or full permissions and access.

0:31So it's common sense, I suppose. We need to change those defaults and only use accounts with the concept of least privilege. An example would be an unsecure root or admin account with a default or no password. We definitely want to solve that by changing it. And ideally, we'd want to use two-factor or multifactor authentication to make sure that the person who's logging in is the authorized actual user and not an attacker. So this is the Exploit Database. It is such an amazing tool because it makes it very easy to find vulnerable systems.

1:06So over here on the left, if we go to Exploits, we can do a search for, let's say, Linux. And then press Enter. And it's going to basically sort the output here based on the word "Linux." So we can search for virtually anything. And then to make it easier to find vulnerable systems after we have identified vulnerabilities here with the Exploit Database, over here on the left, we have, GHDB, which is the Google Hacking Database. So this is not about hacking Google. It's simply how to use Google search terms to drill down and find via a public search engine, or I should say, Google search engine, how to find vulnerable systems based on the criteria that we're looking for.

1:45So let's do a search for "default password" and press Enter. So by doing a search for a default password, it's showing us these, basically, Google searches that we could do to help discover where those are on the internet. So I'm going to go ahead and-- ooh, that's-- I'm not going to use these. I'm just going to go ahead and look at it. But here is the actual search-- filetypedoc inurl looking for "gov" in text "default password is." So I'm not going to click on that. If I did click on that, it would actually take me to the Google search and do it for me.

2:17And then give us a list of all the hits where it found that, where the file type was doc and the inurl had gov in it. And it had default password is. And then it has a description down here, saying pages from gov domain with default passwords assigned in their systems. Also try "pdf" and "txt" in the file type. Some of the default passwords being-- oh my gosh. OK, so I'm not going to launch this because I don't want to even have a history of my search record of looking for that. But I wanted to share with you how easy it is to, first of all, identify vulnerabilities with the Exploit Database and then have the Google Hacking Database provide a method for easy retrieval and lookup of those devices to further push along the attack.

2:58So in short, we never want to have an account with a default password, especially if it's accessible over the public internet. Now, another reason for a bad or a weak config is just an error. We just misconfigured it. And to solve this, we can build and use and verify a baseline for our settings and configurations for any new systems. And that way, if we're ever rolling out a new server or mobile device or a printer or anything else, we can use a default configuration that we've tested and verified that doesn't accidentally include some vulnerability based on a default of that system.

3:35Now, another challenge is that we might be using a security protocol that's old or weak itself or broken. For example, WEP, Wired Equivalent Privacy-- for wireless, we don't use that anymore because it's weak encryption and it can be compromised due to a wimpy initialization vector that can include plain text for the attack. And as part of the attacker eavesdropping, they could figure out what the key is and basically get on our wireless network. So we don't want to use any kind of broken or old or "wimpy" security protocols.

4:05Now, another challenge would be if we're not even trying to encrypt. That's a problem. So we shouldn't use insecure or unsecure protocols if we're using sensitive data. So data in motion over network or data at rest on a storage device, if we're careless, we may allow clear text sending of data or storing of data, and if it includes usernames or passwords or other sensitive information, that's a huge problem. In fact, let me show you how easy it would be for an attacker to compromise based on using the wrong protocols.

4:36So let's use this network. And let's imagine that-- in fact, we don't have to imagine too much because here is a router named R1. Here is the CLI for it. And if we wanted to communicate over to R2, we want to do a remote session for a CLI over at R2, command line interface, we could use a couple of different protocols. One would be Telnet. And Telnet uses TCP port 23. And that's not the problem. The problem is that Telnet is an insecure protocol. It doesn't bother encrypting anything. And that way, if there's an eavesdropper who's listening to our packets go back and forth, if we're sending a password, they've got the password.

5:10If we're sending our config, they see our config. And as a result, our data integrity has just been compromised. In fact, let's have some fun and do a demo. Let me go ahead and capture the traffic as it's going between R1 and R2. So here in my environment, I'll just do a capture. And I'm going to capture-- what interface is this? Gig 0/1. We'll do a capture of interface gig 0/1. And that capture is now running. Great, I'll put it over here-- fantastic. And with that capture running, we're basically eavesdropping on all the network traffic.

5:40Then from router 1, let's go ahead and do a telnet over to router 2. Let me just check an IP address that we can reach on R2. So show ip interface brief. This is on a Cisco router. I just want to verify what addresses we have. So we have an address of 2.2.2.2. I just want to make sure from R1 I can reach that. So I'm going to do a ping real quick. So let's ping to 2.2.2.2. Oh, unreachable. OK, let's go-- that's not going to be good. Let's go for an address that we can reach. Let's go, or on R2, let's try 25.2.2.2.

6:11So we can't really telnet in unless we have connectivity. So let's try 25.2.2.2. Going back to R1, let's ping 25.2.2.2. All right, that looks better. And let's telnet over there. So we'll telnet to 25.2.2.2. Ah, connection refused. (LAUGHS) Hence the demo. Let me set up R2 to allow telnet traffic to go ahead and come back in. So let's do a show run.

6:41I'll say section line. I just want to take a look at the configuration. So basically, R2 has to be willing to allow a telnet session. And right here it's saying that on the VTY lines, that's the logical way that this router allows incoming SSH or telnet sessions, it says transport input none. You can't come in. So we'll fix that real quick. So we'll go to line vty 0 through 4, which is the five VTY lines. And we'll say transport input. And we'll say all. Basically he's now willing to take everything. All right, with that in place, let's go back to R1, hit the Up arrow key.

7:14We'll telnet over. Oh no. (LAUGHS) All right, I will take a breath. OK, let's make sure we can log in. So over on R2, let's create a user account, username bob. Privilege level 15, which, in the world of Cisco, is King Kong rights. And we'll say his secret, which is like his password, is going to be Cisco!23. Fantastic, so top secret information right there. And let's also go to line VTY 0 through 4 and say login local.

7:51All that means is that when somebody does connect on the VTY lines, it's going to prompt for a local user, Bob. And then Bob can supply his credentials. All right, now That we've done that, let's go back to R1. Hit the Up arrow key. All right, there we go. Now, if we're using an insecure protocol, like, Telnet between R1 and R2 and an eavesdropper is there, which, we are. We're eavesdropping. We're listening. Anything I type in-- so I'm going to put in Bob's username and his password. You notice how Bob, B-O-B, when I type those characters, it reflected back.

8:21And that's because I typed in B and the server the telnet, the R2, echoed back and sent back that character to my screen. And then did it for O and B, too. And then when I put in the password, it didn't echo that back to the screen because it doesn't want to put it on the screen for anybody looking to see. But I have logged in. If we type in who, it shows me that I'm currently logged on on logical VTY line 0. My username is Bob and I'm coming in from this address of 15.1.1.1. Now, the problem within secure protocols is that they are totally wide open, like opening the kimono.

8:53So anybody who wants to eavesdrop now has access to that password. So if we go back here to our packet capture, and I'll bring that full screen and make it a little bit bigger. All right, and I'll stop the capture. And it's going to do a quick search for telnet. So I'm just doing a display filter, which effectively is going to only display or show to the screen out of all the 251 packets it's collected, just those that are related to the telnet application. Let me make it a little bit smaller there-- great. And then we can just grab any one of these and just right click and say Follow. And follow the TCP stream.

9:26And that's going to show us the whole conversation right there. Check this out. I made this a little bit bigger so we can see it. But right here, here is where I'm typing in the username of Bob. So the red characters are what I typed. And then the blue characters are being echoed back to the screen. And then when I put in the password, Cisco!23, right here in the packet capture. So using insecure protocols are dangerous if we have any type of sensitive information. So let's take a moment and talk about insecure protocols. In fact, let's go to this camera and do it. There we go. Much better.

9:56OK, so insecure protocols over a network would be anything that doesn't have encryption of the data or at least encryption of the sensitive data that's being sent across. So HTTP, which is TCP port 80, insecure by default. Telnet, TCP port 23-- and there's nothing that's miserable or weak about the actual port numbers. It's just that's the well-known ports for those applications. So HTTP, Telnet, FTP, trivial file transfer protocol-- all weak protocols that have no encryption whatsoever.

10:27And that's why if we have sensitive information that we need to protect for remote access, instead of Telnet, we'll use SSH. For file transfers, instead of using FTP and TFTP, we'll use file FTP secure. Or we can use SSH versions of FTP, which is SFTP. And for our web traffic that needs to be secure, we'll be using HTTPS, which behind the scenes is using some flavor of SSL if it's really, really old, or a more current flavor of TLS, transport layer security. And as I bring over the mic, you and I are going to have separate sets of videos regarding TLS and HTTPS and what goes on behind the scenes to make that happen.

11:05But the gist here I want to talk with you about is that we are introducing vulnerabilities on our networks if we are ever sending or moving any type of sensitive data within secure protocols that don't encrypt that data as it's being sent over the network. Now, another example of a weakness in an attack vector which could be used to compromise the system is when that system has open ports or open services that aren't needed, but yet they are listening. That means if anybody connects, like, a web server, if it's sitting there running web services, it's listening and paying attention to the well-known port for HTTP, which is 80.

11:42Or if it's running TLS, it has the open listening port of 443. So you know what I'd like to do? Let me share with you how easy it is to identify on a system the open ports on that system. And one of the tools that we can use, and this is available on Windows and Linux-- the options are slightly different depending on the platform-- but if we did a netstat and then a dash help (CHUCKLES) --the reason I'm chuckling is because I typed in dash hlep. And I thought, aw, you need help. Anyway, there's the options for netstat.

12:13And so we could actually-- one of these options is listening ports, display listening server sockets. So if we did a netstat and then a dash l, that would help reveal to us some of the listening ports. So right here, it has SSH, which is TCP port 22. It also indicates it has some listening ports for IPv6 as well that's showing here. And it also shows here for IPv4 TFTP, which is UDP port 69. So part of the idea of hardening a device is to remove unused stuff.

12:45Think of it like clearing out your closet with stuff you've never needed or haven't used in a long time. The same principle applies to a system because this stuff that if we leave the ports and services open, it could provide an attack vector. So attack vectors could include apps and services that are not needed and ports that are not used but are still open or "listening." And so anytime we have non-required open ports and services, they should be closed and disabled. And that's going to reduce our attack vector. We could also reduce our attack vector on a system by verifying that it's booting up cleanly.

13:18For example, when a computer first gets its power, there's a power on self-test. And there's some firmware that's used. And it boots and it reads the first little things off the hard disk or the solid state drive, whatever it's using for storage. And then it continues on booting. If we can verify each of those steps by either using hashes or checksums and verifying each step along the way, we can refer to that as being a secure boot. And as far as USB ports and other data paths it might have, we could secure those, maybe disable them on the system so that even if something is plugged into a USB port, it's not able to be used.

13:52And that helps protect that device by hardening it, again, by removing unused services and locking down those things that are not needed. So those are all examples of hardening a device, making it less vulnerable. Now, sometimes, we introduce our own vulnerabilities and our own weaknesses. And we inflict them on ourselves, like, this finger right here. I slammed it moving some furniture about a month and 1/2 ago. It no longer hurts. But it's a self-inflicted wound. Now, sometimes, we introduce vulnerabilities via products and services that we purchase from a third party.

14:22And these resources are often referred to as part of our supply chain. And if they have vulnerabilities and we use their products, now we have those vulnerabilities. And so in the next video, let's take a look at third-party risks and how we can help mitigate those or reduce those whenever possible. Meanwhile, I hope this has been informative for you. And I'd like to thank you for viewing.

0:07Very few companies are islands. We all use products and services from other vendors, and they are considered to be part of the supply chain. And that's true whether it's goods or services that we use from them. And third parties get introduced vulnerabilities as part of the goods or services that we use from them. So what could possibly go wrong? Well, here's a scenario. Let's imagine a vendor's management software used in our network. We purchased it. We installed it. We use it. And it's part of our supply chain. And let's further imagine an automated software update that unfortunately hackers have compromised.

0:43And now, we have when we do the update, we're going to have a remote access Trojan installed, and we're toast. So part of the solution is to use proper vendor management where we can prepare for and analyze factors such as, how does this product integrate with our system? And how and where do our systems interact? And what are the risks? Now unfortunately, we may buy a product and not realize the lack of vendor support until it's too late. So it's essential to understand what type of support we have from the vendor after we integrate their product or service in our environment.

1:19And another consideration is about code development. Are we hiring a third party company? Are we outsourcing the code development? And what code reviews are we doing that confirms that secure methods and best practices are in play and that no back doors exist? Now, another question, especially if the third party is storing or working with our company data, is data storage. Now, what are they holding? And where do they keep it? And how do they protect it, et cetera? So when we do an IOC, an indicator of compromise, let's say I have some event that happens.

1:52We need to report it. We're not just going to release all the data. We are going to sanitize that data first to avoid exposing or releasing any sensitive data. Now, another vulnerability that plagues most organizations is just keeping up with security updates, and hop fixes, and patches. And so what I'd like to do in the next video is talk about vulnerabilities that we may inherit by simply having an ineffective or a lacking patch management program. And we'll talk about that in the next video in more detail.

2:22Meanwhile, I hope this has been informative for you, and I'd like to thank you for viewing.

0:00[MUSIC PLAYING] So let's begin with a question. Does software ever need to be updated? I imagine you're saying, Keith, of course. Yes, it does, all the time. That's absolutely true. However, and unfortunately, many companies have improper or weak patch management and update management simply because they have not thought it through. They have not asked themselves the questions, such as, what may need to be updated or patched?

0:30Or is it even possible to do an update or a patch? And that could apply to firmware, real-time operating systems, or our general purpose operating system, or applications. So a great example of things that we forget to, or cannot, update stem from legacy systems and platforms. And that includes firmware, embedded OS, as well as the apps that run on those. Let's think about how we onboard a new device. If we have an internet-connected device with a vulnerability, whether it's the firmware or the BIOS or the operating system or its config, whatever it is, that means that even a script kiddie, if it's public-facing, could be able to compromise that system, let alone a professional or a state actor.

1:13So an effective patch management program or system is going to include a few things to make it work. Number one, we need to have an up-to-date inventory of all of our systems and all of our network devices. And that way, when new patches or updates apply to a system, first of all, we know where it applies to. And then, before we apply it, we should have rigorous testing. And then, using change control, rollout a patch or an update into the production environment after all the change control and testing has been done. Now, frequently, the testing is performed in a virtualized environment.

1:45And that way we can replicate, as closely as possible, the production environment. See, our goal is to identify any surprises regarding functionality or security in the testing phase before it goes into production. So the necessary steps for implementing an update or a patch would be to, first of all, identify the systems that need it. An example would be servers running a specific version of Apache, or hosts that are running a particular operating system version. And based on the update, we'd want to prioritize and apply the updates or the patches, whatever it is we're applying, to the most critical systems and the most vulnerable systems first.

2:21Now, part of that decision making process would be to identify the risk or the potential loss, which is going to help steer us to the most critical systems first and get those updater patched. Now, once we've identified the critical systems or the people who get the patches first, that patch or update, it needs to be thoroughly tested first before being rolled out. I remember one of my early experiences, where I didn't do thorough testing, and it was a disaster. There was a new update-- this was back in the '90s. There was a new update of a network driver for a vendor's card, a network card, that we were using.

2:54And this new update was supposed to give us like a 30% or 40% more throughput-- woohoo! We were like, woo, go, go, go. Well, unfortunately, once we did the update, it didn't really have the opportunity to provide us the advanced and increased performance because the system had a panic condition. Think of that, like similar to a blue screen, which means the server completely stopped working. So that was many years ago, but I've never forgotten that lesson to always test in a practice environment first before rolling it out into production, no matter what it is.

3:26So that concept of testing should apply to updates that are supposed to provide additional functionality as well as updates that are supposed to be fixing a security issue. Now, sometimes a patch or an update, it can't be tested as quickly as we need to, or there may be other situations where we cannot provide an update to a critical system. In those cases, we would want to consider some type of a countermeasure or another workaround that can mitigate the risk. So until we apply the patch, what we could do is we could restrict certain traffic patterns or protocols from ever reaching the device or the server by putting up, for example, a firewall in between the users and the server itself.

4:05Now, if there's already a firewall there, we could just possibly tweak or tune the access controls on that firewall to help mitigate or temporarily stop the risk or the vulnerability from being leveraged by an exploit. And that would be a temporary fix until we got the patch or update on the actual server, which then removes the vulnerability. So countermeasures are a great way to help mitigate risk while we're waiting for a full solution. And now, over the years, I've learned a lot, and I've come to really appreciate change control. And as a part of change control, there should be a documented backup and restore plan that should be thought through and available.

4:42So let's imagine that we have a change window that's one hour in length. So it's been communicated. It's all good. And let's also imagine it takes 20 minutes to restore if something goes bad. So that means at 40 minutes in, we would have to make a decision to commit and go forward or roll it back to its previous state. So the benefit of having all that documented is that there's less ambiguity, there's less confusion in the event we do need to roll it back. Now, many operating systems that users are familiar with perform auto updating.

5:14So let's suppose that you and I are in a company that doesn't want those auto updates to happen without in-house testing automatically. In that case, what we could do is we could set up the configuration so that those devices do not-- I repeat-- do not pull from the public repositories regarding security updates or other patches, and then our workstations could point to an on-prem, a local, repository that we manage and control. And then, what we could do is we could facilitate updates and patches after we do our in-house testing regarding those updates and patches.

5:47And so it's kind of a double-edged sword, because if we're going to test them, that means those patches and updates may have to wait a day or two or more before they get on our systems. So at the end of the day, if we boil it all down, one of the benefits of having automated updates, including operating systems and browsers and virus definitions, et cetera, is that we have an excellent possibility of keeping current, which is really important, and thus, reducing risk. So in a perfect world, we want all of our systems updated with any security patches as soon as possible while, at the same time, not causing any loss of functionality by applying those patches.

6:25Now, another important thing to keep in mind is that when we're getting new software and we're going to deploy it, test it and then deploy it, when retrieving updates and patches from a vendor, it's critical to validate that we don't have a compromised version of that software. And so one way of verifying our updates is to download, or at least look at, the hash values that are calculated and published from the vendor's official website. And then, after we download, we could then generate the hash for that file and compare the hash we generated to the hash that they published.

6:57And so comparing the hash values can help us validate data integrity and help ensure that we have a correct and untampered with version of that update, because it would be super devastating if we downloaded a file that we thought we needed or wanted or would help our systems and, at the same time of installing it, because we get a wrong copy of it from an attacker, we've just injected malware onto our systems. So let me share with you an example of how easy it is to do a quick check regarding the hash value, just to make sure that the file we downloaded and are using is the actual file from the vendor.

7:31So let's imagine that we want to download a file, whether it's a patch or an update or anything else. We just want to verify that this file has been modified or tampered with by some third party. So I'm going osboxes.org as an example. And let's imagine we want to download an image for a Raspberry Pi. And so I have a VMware environment behind me. So I'm going to go ahead and just download the VMware flavor of it. And then I can download it. So I click on Download. It's going to download to my local computer. So if we wanted to verify that we got the real file and that we didn't get sidetracked and download it from a malicious source, we could actually look at this SHA256 hash right here that they're publishing, and then we could generate our own hash once we download it.

8:11And if the hash we generate matches the hash they publish, bada bing bada boom, we have data integrity. So here's another critical point. If we are downloading software and we are at a malicious website, where they're saying, oh, here's the software, and oh, here's the hash value, they could have taken the software, injected the malware in it, published it, published the hash that matches the malware-laden version, and then it would just-- it would still match because we're looking at the hash published by the attacker, and it matches the hash on the file.

8:43So we'd also want to verify that we are at a site that we trust and not at a malicious site that's publishing a hash. So in this case, osboxes.org, if we take a look. I'm right here. It says the connection is secure. I could look at the certificate to see who signed it. So it's an important piece to make sure we're at the right site, at a website that we trust. So if we wanted to compare this hash, what we could do is download the file, which I've already done to save us a few minutes, and then, using a tool on our local computer, generate that SHA256 hash and compare it, the one we generate from the hash that they're publishing.

9:15So to do that, I have downloaded that file, which is approximately 2.2 gigs. Let's just a real quick dir. There it is right there, Raspbian-2020-- blah, blah, blah, blah. So let's generate our own hash value. And the way we're going to do that is with a little, teeny utility called certutil that's part of Windows 10. So we'll type in certutil space dash, and we want to generate a hash, so we'll type in hashfile space, and then we're going to put the actual file name.

9:45Now, this is-- I'm going to hit r and tab it out. Because it's unique, it'll bring it down for me. And then I'm going to specify the type of hash. So they're publishing the SHA256 hash, and so what we'd want to do is generate that same hash. So we'll do sha256, press Enter. And if my syntax is correct, in just a moment, it'll just generate the hash for us. All right, so let's go ahead and a pair of few characters here. It says it's 7f3da. And the first characters here are 7f3da. That looks great. And if we scroll to the end and look at the last part, we have 6d46b.

10:20And that's 6d46b. And if we compared every single bit of that hash, they would match here as well. So what's the end game here? What's the point of this? The point is to verify that the file that we have is literally the file that was published by the vendor or a manufacturer or the website that we trust, and we are not downloading or we haven't downloaded a malign copy that has malware injected in it. So in this case, the file that I downloaded is exactly the same as the file provided because the hash matches identically. So the benefit of using a hash, which is a one-way function, where we can run the hashing algorithm against the data, that little digest it creates, that little hash it creates, if the file has not been modified or tainted or changed, the hash values are going to match, which means we have data integrity.

11:04And in the next video, I'd like to chat with you about what we can do to help prevent our attack surface and our vulnerabilities from growing by doing a little bit of management regarding vulnerabilities. And I'd like to touch on that in the next video. So I'll see you there in just a moment. Meanwhile, I hope this has been informative for you, and I'd like to thank you for viewing.

0:00Let's imagine that we have a policy regarding company workstations and the following-- that current patches must be installed, after we've tested them, of course; and local firewall has to be installed on host, has to be running; local IPS or anti-x-- antivirus, anti-malware software-- must be running and current on our hosts. And for our special servers, we want to verify that a list of items are in place, including minimum operating system levels, minimum patches. We want to make sure that specific ports are not open and that the systems are prepared for and resistant to many well-known attacks.

0:37All right, so for us, the question is, with thousands of devices, even if we roll them out correctly, how do we verify over time that our baselines are being followed and we aren't having additional vulnerabilities creep in? One method of doing that is a good vulnerability management program, which has, basically, the goals of identifying, removing, and when they can't be removed, mitigation of vulnerabilities. So here's an example of what we'd want to keep on top of. If we were running Microsoft Windows, we would want to make sure we're looking at their security advisories and any vulnerabilities that they're discovering in their software.

1:12So as of this recording, that's not too far in the past. And we've got for this SharePoint remote code execution vulnerability, it's got a CVE, a common vulnerabilities and exposure ID number, fantastic. So we can research it more there. It also has a CVSS score, which can help us by looking at that number to identify, OK, we have all of these vulnerabilities. Which ones do we focus on first? The answer would be our core systems and servers where we expect the most loss of the most harm. And then, of those devices, which ones have the most significant vulnerabilities exposed?

1:44Now, if we were in a shop, even a Windows shop where we didn't use SharePoint at all, this vulnerability would not be a risk to us. But the key is, whatever operating systems and applications we're running, we need to have those feeds coming to us so we can be aware of what those new vulnerabilities are and then take the appropriate steps once they pop up. And one of the tools that we have in our tool belt that we can use to help maintain our security posture is a vulnerability scan. And they are intended for us to be proactive with them. So we can perform scans to interrogate the network, the web servers, and even specific applications in an automated fashion.

2:18And so we can look at the scan's results and see if the vulnerabilities it was looking for exists. And having visibility to those known issues ahead of time allows us to do the mitigation and the protection regarding those vulnerabilities before the attackers take advantage of us. So let me share with you an example of two of the most popular vulnerability scanners out there. One of them is Nexpose by Rapid7. It is fantastic. And it's modular. So if we're doing vulnerability scans on Linux or Windows, there's modules that we can effectively plug in or remove so we're looking for specific vulnerabilities based on the platform that we're doing the vulnerability scan on.

2:57So Rapid7's Nexpose is a great, full-purpose vulnerability scanner. Another very popular vulnerability scanner is Nessus from Tenable. And again, it's also very modular. So you can plug in modules to do additional scanning based on the type of environment that you're in. So if you're in a Linux heavy or Microsoft heavy or whatever the environment is, you can plug in the modules that will be scanning for certain vulnerabilities based on those platforms. And one of the cool things about a vulnerability scanner is that they get updated. So if there's a new vulnerability that's known and it applies to a Microsoft or a Linux environment, whatever the platform is, that can become part or updated as part of the software for our vulnerability scanner to look for those specific vulnerabilities.

3:40Again, the key is to be aware that it exists so we can fix it, correct it, update it before an attacker compromises it. Other scanners, besides full-blown vulnerability scanners, can also be used to look for open ports and also identify, when possible, the actual operating system that's running on those systems. One example of a tool that can be used to scan a device and look for open ports and help identify what's going on is a tool called Nmap, N-M-A-P, and it's graphical user interface equivalent, which is called Zenmap.

4:11So here on this Kali Linux box, it is a distribution of Linux that has a lot of tools, including Nmap and Zenmap. I'll go ahead and click on Applications and then hover over Information Gathering. And then over here, I've got nmap at the CLI. We also have an option for zenmap. And that's the graphical user interface version of Nmap. So let's go ahead and launch Zenmap. And let's go ahead and do a quick scan of the entire 192.168.1.0 network. And this is in a lab environment.

4:41So I'm not doing anything in my corporate environment or anything else. Because doing a scan is considered malicious if you're not authorized to do it. So as far as the type of scan from the dropdown, I'm going to go ahead and just do a quick, just a quick scan. And click on Scan. And it'll just take a moment. It'll go out. It's going to find every device that responds and give us a list of them. And let me scooch this over just a little bit. And wow, check it out. So I've got 1, 2, 3, 4, 5 hosts that it found on this network. And if we click on Services here, it's going to show us each of the services it found.

5:14So we can click on one of those, like, HTTP. And then it gives me a list of who's supporting that. So the host at 151 HTTP has an open port if, we click on domain we've got .1 and .100. If we click on LDAP, it's going to show us that we have .100, which is my domain controller. And it's using port 389. That's the not secure version of LDAP, which, if an attacker was looking at this, that might be something they want to pursue. And then we go to SSH. It shows me I have two hosts that are supporting SSH.

5:46So if we go back to Hosts it has a whole list. If I wanted to get more information, for example, on this bad boy right here, 151, we could do a more thorough scan just on that one host address. So let's do that. We'll go ahead and put in .151. And we'll go ahead and do-- if I do an intense scan, that's going to take quite a while. Let me do a Quick scan plus. And that's going to help identify the operating system behind it as well. So with that in place, we'll go ahead and click on Scan. And again, this is just like Nmap. We could do all that with the nmap command at the CLI, get the same results.

6:19So let's give it a moment. So now that it's done its scan, it's going to come back and tell us about more details regarding that host. So let's take a look at this bad boy right here, .151. It's identified it as running a flavor of Linux version 2.6.x It's identified a whole bunch of open ports. So 22 is SSH. Port 80 is HTTP. So if this had come back and it said, oh, it's got TCP port 25 open, we would know that that's an SMTP, simple metal transfer protocol. That's the well-known port for SMTP.

6:49Or if it had port 23 open, which is the well-known port for Telnet. That would be a huge option as far as a vulnerability on that device. Or if it had TCP port 21 which is FTP another plain text protocol. So it's got some HTTPS open right here. It's also indicating the services behind it and the flavor, which would be very helpful to an attacker. So the key is, if we are doing a vulnerability scan and we have a policy saying, hey, no port 80 open or no port 23 or no port 21, especially on workstations, we could run a vulnerability scan, have it run across the network, and then as these ports show up, if they're not supposed to be there, we could then take action and shut down those ports because open ports are absolutely part of an attack surface that we don't want exposed.

7:35We don't want that vulnerability. So if we have a system and it's got open ports that should not be there, ports that are listening and waiting for an incoming connection, we'd want to remedy that to reduce our attack surface on that device. Now, another consideration is not doing damage or impacting performance in a negative way on a production system as a result of our scans. See, management frowns on a denial of service attack. And that's either from an attacker or as a result of our scan. So we'd want to test first. So scans can be said to be very nonintrusive, where we're looking for specific open ports.

8:10And that would be considered a passive scan. And when we use our scanners against Microsoft Active Directory with a non Active Directory account looking for unpatched systems and so forth, that would be considered a non credentialed scan, as the user that we're using as part of the scanning software is not part of AD. And so we can get a lot of great information from scanning, even with a non credentialed scan. Another example is scanning, for example, on looking for TCP port 443 to discover not only is that port open, but also to discover, is that server using a self-signed certificate?

8:44So it doesn't take a valid user account to learn that because a server with those open ports will communicate with anybody making those requests. So the cool thing is that we can identify some vulnerabilities, that they exist, without having to actively or aggressively test specific applications. And that's just by doing some simple port-based scans of a device. On the other hand, a scan could be very, very aggressive. And that would be considered an active scan. It's intrusive. It's going to use system credentials. Somebody has a user account that's part of the scanning software.

9:16And that's referred to as a credentialled scan. And here's how it works. In the scanner, we simply provide a user account that has permissions. And then the scan, when it's done, uses that permissions. And that may operate with an agent or other software on each of the systems as well. So when a scanning service runs using the permissions of a valid user account, it can better assess potential vulnerabilities across the domain because it can ask detailed questions to that system because it has, basically, all the permissions of that user account. So we may have the scanner inventory every app and every service on every system.

9:50And so the benefit of doing an active or credentialled scan is that we can get more detail and get reports regarding a system and discover that it's vulnerable to a certain type of an attack, such as an injection attack, like, LDAP or SQL. So here's the payoff for doing aggressive or more aggressive scans, as long as they don't take our systems down is that the more successful scans that we do, that's going to lead to learning more about potential vulnerabilities, which hopefully guides us to correcting those with either configuration changes or patches or additional controls to help mitigate risks if we discover, or when we discover, vulnerabilities in our systems.

10:30There's a few other options, too, that we can use to help reduce the vulnerabilities on a host. And that would include using what's called a secure boot process to verify that rootkits or other changes have not been implemented on a system. Also, many host-based intrusion prevention systems or IPSes have explicit allow lists for applications. And by using this type of control, any applications or access that's attempted that is not explicitly permitted, would be implicitly denied.

11:01So if you have malware or something else that's going wrong, it wouldn't be able to run based on the host based intrusion prevention software. Another good security option is to restrict data from going into or out of USB ports if it's not needed. And that way, even if a user does pick up a USB device and they plug it into their computer, their system can't be compromised if there's a technical control in place that doesn't allow any transfer into or out of that system via the USB ports. So the guiding security principle is less is more.

11:33Fewer permissions, fewer apps, fewer services-- that's going to reduce our attack surface. It's also going to reduce our vulnerabilities as well. So thank you for joining me in this video. And in the very next video, I'd like to do a wrap-up and a review with just a few quiz questions. And I'll see you there in just a moment. Meanwhile, I hope this has been informative for you. And I'd like to thank you for viewing.

0:00[MUSIC PLAYING] Hello, and welcome back. In this review's last quiz, I'd like to present a few questions, which will give you and I the opportunity to both confirm our understanding and also to reinforce many of the concepts that we've talked about in this set of videos. So if you're ready, here is question number 1. What can be done to reduce the attack surfaces and/or vulnerabilities on a system. There's four choices on the board.

0:30Go ahead and pause me. When you're ready, go ahead and click on Resume and we'll address the correct answers together. All right, so here we go. Secure boot is a fantastic option to help verify that a system has integrity. So when a system first powers on-- I'll go ahead and put a little lightning bolt here-- there's some power applied. And then there's going to be some firmware and some BIOS that's read, or the more current UEFI, instructions for the system to get going. Then it's going to read some information from the bootstrap loader on the storage device.

1:01And then it's going to load the operating system. And if we can use secure boot during that process, it can verify with hashes each step along the way that it hasn't been tainted or modified by something else. And that way, if we verify each of these individual steps with a secure boot, and oftentimes we can use a TPM chip as well as part of that for storing those hashes, then we can have more confidence in the system booting up. So by having secure boot, we are absolutely reducing the attack surface because if we're avoiding a rootkit or something else malicious running on the system, we're not going to be as vulnerable.

1:34All right, so I'd say answer A is correct. Answer B says use a security baseline config. And I would say that's also super important because we're rolling out all types of devices. We're rolling out mobile devices and servers. And those servers may be physical or in a data center or they may be, like, in the cloud. But if we have baselines, especially security baselines regarding the best practices of how they should be configured and what services they should be running or not running, that's going to help us improve our security posture and reduce our attack surfaces.

2:07So mobile devices, servers, workstations, and Internet of Things devices, anything else that we're rolling out, if beforehand we can have a security baseline regarding configuring them, we can then use that as a checklist as we roll out those systems or even automate it to help improve our security. All right, so answer B is correct. And answer C says vulnerability management. And that is absolutely true to help reduce attack surfaces. And that way if we're scanning for TCP port 80 and we find it behind the scenes, that implies that HTTP services is running.

2:40And if it's not supposed to be running, that's an attack surface that we don't want on that system and we'd want to go further and investigate that and get it shut down. Maybe the user had the privileges to install some software or perhaps it's some malicious software that's currently running, causing it to be open. Either way, if it shouldn't be open, we'd want to identify that. And vulnerability management and vulnerability scans can help us do exactly that. So answer C is correct. And then answer D, restrict USB ports. And I would say that's also true as far as reducing attack surfaces.

3:11If the USB ports are not functional, you can't get data in or out via a USB port, then you just reduced that attack surface of the USB ports on that system. So every answer on the board here is correct. All right, let's take a look at question number 2. A scan shows open ports of 25, 80, and 443. Let me also throw in there that those are TCP ports. And as a result, if we had that scan report come back, whether it's a vulnerability scan or its Nmap or Zenmap, which services are likely running on the host that has these three ports that are open?

3:47So go ahead and pause me. Take a look at the answers. And when you're ready, click on Resume. All right, so let's take a look at these together. We have five answers on the board. FTP is a clear text protocol-- not secure. And that has a control port by default of TCP port 21. That's the control channel for FTP. That's not up here in this list. So we'll go ahead and take that off our list. HTTP has the well-known server port of TCP port 80. HTTP is also plain text-- not secure, doesn't do encryption.

4:21But as part of our question here, port 80, I would say, yes, we could assume or infer that if TCP port 80 is open on that host, that means that there's an HTTP service or very likely an HTTP service running because TCP port 80 is the well-known port for HTTP. All right answer C is HTTPS, which uses the well-known part of TCP 443. And behind the scenes, it's very likely using TLS, transport layer security, version 1 dot something.

4:52And we'll have separate videos on TLS and how that all works. But the question here is if you see a server or device that has 443 open, it's very likely running some type of HTTPS services. All right, so we've got 80 and 443. All right, answer D is TFTP, trivial file transfer protocol, which is also not secure. That uses UDP port 69. And that's not part of what we found in our scans. So that's not a correct answer here. And then SMTP, simple mail transfer protocol, it uses TCP port 25.

5:25So there's a lot of other ports, also, that SMTP may be using. Also, many that can use encryption. But SMTP, the well-known port is 25. And so if we saw that, we could assume on that system that SMTP services are running on that host. So our answers here are our answers B, C, and E. And I've got one more question for you. It's question number 3. And here it is. Which of the following are full-featured vulnerability scanners? So I've got four things listed on the board.

5:57Go ahead and pause me. And which of these are full-featured vulnerability scanners? All right, welcome back. So if we take a look at the two that are the most popular in the universe, at least the universe that I live in, they are Nessus, made by Tenable, and Nexpose, which is made by Rapid7. So those are the two full-featured vulnerably scanners. Nmap is a great tool that can help us identify open ports. And Zenmap, which we had in an earlier video as a demonstration, that's a great tool, too, to help identify ports.

6:27But it's not a full-featured vulnerability scanner. For example, we don't have plug-ins for Nmap that are specific to a flavor of Linux or Apache and so forth that could help identify vulnerabilities on those specific platforms or applications. And then Nslookup is a great tool that we can use for name server information. And if we wanted to find out what is the IP address for a certain host or if we wanted to validate an MX record or something else in DNS, Nslookup is a fantastic tool. But again, it's not a full-featured vulnerably scanner.

6:59So the answer we're looking for here are answers A and B. So I'd like to thank you for joining me for both this quiz and also this set of videos. And I look forward to seeing you, my friend, in another set. Meanwhile, I hope this has been informative for you. And I'd like to thank you for viewing.