The Complete Course from ExamCollection industry leading experts to help you prepare and provides the full 360 solution for self prep including SY0-601: CompTIA Security+ Certification Video Training Course, Practice Test Questions and Answers, Study Guide & Exam Dumps.

1.3 Analyze potential indicators associated with application attacks

4. Replay attacks

In this video, we're going to be talking about something called replay attacks. Now, with replay attacks in particular, we're going to be talking about something called a session replay. Now for this one, I'm going to draw you guys a little diagram just to give you guys a good illustration of this. Now, this is really done by sniffing people's traffic. It's mostly done by using a "man in the middle" attack. Now I'm going to actually do a lab with you guys with a man in the middle attack coming up later in the course in the next section, when I'll actually show you guys how to do a man in the middle attack using a particular piece of software and how we can sniff the line and do ARP spoofing. So for now, I just want you guys to get an understanding of how this attack works. So let us go here to my desktop. And where is my desktop button? There you go. All right. I was teaching the class here. Okay, so here we go with a particular session, a session replay attack. Now, a session replay attack basically builds on the concept of stealing someone's session information and replaying an attack against the server. It's a very simple thing. So let's say you have a client machine. Let's say workstation one So this is workstation one, and the workstation wants to talk to the server. SEO: Verify the client wants to authenticate and talk to the server. So at the bottom, you're going to have a hacker listen into the communication between the workstation and the server. So basically, the workstation wants to authenticate to the server. So what the workstation does is that it sends.Now, if you know how passwords work, you basically hash your passwords, right? Passwords are hashed. So what happens at the workstation? Maybe his name is Bob, and let's say his password is all ones, okay? Three or five of them So, this is the hash. This is not his password. It's the hash of his password. So Bob wants to authenticate to the server. So Bob sends his username and password to the server to authenticate as Bob with five ones. But what happens is the hacker sniffs this information, grabs the hash, and then the username. Now, what the hacker does is replay it against the server, telling the server, "Hey, I'm Bob; replace the hash against the server." And the server believes that it's basically workstation one, right? It's Bob who's trying to login to that particular server. So this is the man. This is why you notice it looks like a man-made object. I was about to say that this is a session replay because it's replaying the credentials of Bob against the server. Very similar is "a man in the middle," and "a man in the middle" is what you're going to use to sniff this data to get it again. There's a whole video on that where I do an actual lab with you, and I'm going to show you more of this when I get there. Okay, so you're probably saying to yourself, "Well, how do we fix this?" One of the ways to fix this is to use what are called session tokens. Session tokens now rely on a challenge process in which the server sends workstations in which the server sends "bob" something bob. Then it rehashes it and computes it, then sends it back to the server. The server already knows the hash, and it will fix it. Just know that, in your case, session tokens are a solution. Encryption, of course, can help with this as well. Okay, so for your exam, just know exactly what a replay attack is and particularly session replay.

5. Request forgeries

In this video, we're going to be talking about something called request forgeries. Now, request forgery attacks basically come in two types: client-side and the server side.Now the client side is called cross-site request forgeries. Then there are Request Forgeries on the server side. You should know the acronym. Now, I'm going to be going through these attacks with you, and I'll basically show you some diagrams, and we'll also take a look at some URLs and see how these things work. Let me give you the head's up. These kinds of attacks, basically, one ofthem attacks the users themselves and theother one basically attacks the server. That's why one is called client side and the other one is called server side. So the first one up we're going to take a look at is something called "cross-site request forgeries." Now I was going to draw you guys one of my famous diagrams, but I decided, you know what, I'm just not that good at drawing. I found some great websites that had good diagrams on them to make it a lot easier to understand. They also had all the URLs on hand to make it a lot easier. Now remember, for your exam, you don't need to go in and know how to do these things. You basically just need to understand it and how to fix it. So let's take a look. OK, so I have a website here, and I'm going to put the URL into this video so you guys can get these URLs, OK? So let's take a look here. Cross site. request forgery attack. Now, the cross-site request forgery attack is referred to as CSER for session rider, which is a term you should be familiar with. Now this is a very popular term: session rider. Now, what this attack does is that when you login to a website, I'm going to send you a link. You're going to click on it, and it's going to execute codes against your browser, which asks you because you've already logged on to the website for the benefit of me. So let me show you the actual diagram. And I thought this diagram would zoom in here a little bit. I thought this diagram was nicely done here for us. So let's say you log into a website, particularly a banking website. Let's say you log into ChaseBank.com, right? So you logged in, you put your ID in, and you logged in. What I'm going to do is forge a request for a fake bank transfer, and I'm going to send it to you as a hyperlink in an email. So the perpetrator embeds the request and sends the hyperlink over to the visitor. Now the visitor basically clicks. Let's say I'm going to make a URL that has codes to transfer money to my account. I'm going to send you that URL; you're going to click it, and you're going to visit that website. You click the link. It basically executes that link, sends in the request directly to the server via the website, and basically the website validates the request and transfers the funds to me. Now, I wanted to show you the HTML part of this. So in that sense, this is a valid one. This is valid HTML. Basically, if you wanted to do a bank transfer, you would have run Get and then the HTTP command and noticed it was putting $100 into your personal account. It's transferring it to you. But in my modified one, I'm going to use the same command that I'm going to say, "Get," but you'll notice it's into my hacker account for the amount of $100. So it says "account" here. It's given me $100. Now, realistically, we really don't allow this. All right, this is probably not going to work. But what could work sometimes in today's world is going to be JavaScript. So they can actually put JavaScript in there and make this thing work. So the question you might be saying is, "Wow, that's pretty scary." How can you protect yourself? But before I come back to this, you have to remember: This thing could get pretty dangerous. Let's say you have an Amazon account and you're logged in. You have your browser saving your username and password on Amazon. So what could happen is that you could be logged into Amazon. I'm malicious. I'm a bad person. I'm going to send you a link. You're going to click on it. Basically, that link will allow me to purchase something on Amazon and send it to me, all while using your credentials or executing something on your credential. So the question is, "You're saying, okay, that's pretty dangerous. How do we fix it? Let's go back to the website. So the best practises are you guys, and I know a lot of people do this. Many people abandon their browsers. Leave the browser to remember the username and password for this one. I'm guilty of that. Sometimes you shouldn't do that. You want to secure your username and password. Log off. For example, if you're not using a web application and you log in, make sure to log it off and avoid logging into multiple things or browsers or multiple applications at the same time that you have logged in. When you finish using one, log off. Okay, so that's a cross-site request. Forgery is done on the client's side because it basically hits the client. The client has to click that link. It's executing the code there. The next one is a little bit more complex, and this one is called server-side request Request Forgery.Now, once again, I found a great diagram with some codes that we can look at to analyse this. Let's take a look. So this is a cross-site request forgery. I'm sorry. server-side request. Forgery or SSRF The other one here was known as S CSRF.You may want to note the terms. Sometimes the terms in your exam may pop up terms.You may just want to know the acronyms. OK? So I wanted to show you this one. So in this particular one, first of all, websites nowadays are not powered up by just plain old HTML pages. Websites nowadays have a giant back-end system that stores data in databases. And sometimes there are multiple web servers, and so on. So you notice there's an attacker who sees a bad guy, right? He has a crossbones on his shoulder there. Here's an attacker; he'll basically go to a website and execute codes onto the general, sometimes the URL of that website and allow them to be executed against the internal servers, the internal system, allowing them to extract and manipulate data on that website's internal systems. And that's why it's called server-side, because this type of forged request is affecting the server itself. So here is the guy; he's going in here, he's typing the URL in here, and he's taking control of the internal system. I'll show you a quick example of this. As a result, attacks are directed at the server. to give you an example here. So let's say in this example, they're basically going to be using an API. So in this example, they run a code to see what the stock is, to find the inventory of a particular product that they are purchasing, right? So, as you may have noticed, here is the application. They're saying stock the API ID; they're looking for this, and he's running it on that server itself. But then what the hacker does is change the API. He says, You know what, don't look for the API. That tells us how much inventory is in that store. Execute this: give me a local host admin, which will then give him admin access to that particular server. If he wants to get direct access to that particular server or even another server, he can then change the API to point it somewhere else. Now, that's the basic idea behind this. Now, if you're thinking, "Is this complex to do?" Not really. It's not very complex to do. You just have to find a system that's vulnerable. So you're probably saying, well, how do you fix something like that? Because if they execute these codes, they can take control of your entire Web server. The best way to do this is with what's known as "input validation," which limits what the server is willing to accept into the URL itself. If this is done right, it will not accept things like a local host, which is just that local computer, or a particular private IP address. So you have to do some input validation and ensure that it doesn't contain characters or anything like that. Okay? So that's request forgeries, cross-site request forgeries, and server-side request forgeries.

6. API Attacks

In this video, we're going to be talking about application programming interface attacks, or API attacks. Now before I get into the attack, it's really important for you guys to know exactly what an API is. This is a term you're going to probably hear a whole lot of. as you go through your IT career because it's something we use a lot. Let me give you an explanation. Here's what an API is. I'm going to give you a really easy explanation that a lot of people use. So let's say you go to a restaurant. Now you go to a restaurant, and you ask them. Now you ask the waitress for a menu. So the waitress comes to you and gives you a menu, and you start to go through the menu. The waitress will now be your procedurequote unquote procedure quarter, able to communicate with the people preparing your food in the back. So in the back of the restaurant, you have the cooks that are actually preparing the food. So you go through the menu and you tell the cook, and you start to tell the waitress, "Well, I want a hamburger and I want some French fries." So she writes it down. She then goes to the back end. She tells the cooks, "Hey, let's say the cook's name is Bob." She says, "Hey Bob, can you get me a hamburger and some French fries for Andrew?" So Bob makes it and gives it back to her. She comes back and gives it to me. That's a good analogy of an API. Now you wonder: What is the API? API, or application programming interface, is a piece of software that lives in the middle, directly between some kind of server database and some kind of application you're using. It's basically an intermediate piece of software between two different pieces of software. So I'll give you guys an example here on my phone. So I'm going to open up my phone here and go to, and you'll see an API that you're probably pretty familiar with. It's a little hard to see that, but this is an API. How do I know? Well, you'll notice that this is the weather app that comes on my Samsung phone here. Now the Samsung No weather. Are they available in the weather? Whoever made this app, are they the ones who provide the weather? Not really. See if I scroll down to the bottom; it's hard to see there. I know it's a little hard to see that, but just trust me. It says so on the Weather Channel. So how is this app-making procedure linked to the actual weather channel database of information? Well, they use an API, right? So, an API is basically how we get different software to communicate with each other. APIs are all around. You go to any kind of booking or vacation site and book a vacation or something. You'll notice that I want airfare. So the website will show you all the airfares and different planes, different companies that have maybe American Airlines, Southwest, or whoever), How is that site getting all this data? Well, that means there's got to be some kind of connection between that popular website, maybe Expedia, and American Airlines. It has to be some kind of API (application programming interface). So that's what an API is, right? It's a piece of software that lies in between them. Now, there are two APIs, and I'm going to go over this very briefly because I don't think you need to know this for your exam. I think you need to go thatfar in for your particular exam. But I'm going to show you quickly. Now, I do cover this in my cloud security class, my CCSP class. But for your exam, I don't think you need to dive much into it. But I'm going to show you our website here. And of course the links will bein, the links will be with video. Here we go. There are two main APIs. There are two types of APIs: soap API and rest API. So Soap API stands for Simple Object Access Protocol. And this one is more XML base.It uses WS security standards, XML encryption, and XML signatures. Is the other rest or representational? State transfer. This one uses more HTTP, HTTP based on the URL, and so on. It supports SSL authentication and https now; there are a lot of threats to the API, and this is the part of it we need to review now that you know what an API is. So there are a few threats that we need to know about. Number one, the man in the middle attacks. There are ways for an attacker to intercept the connection between you and the API and steal the data to obtain sensitive information. Let's say you're booking a let'ssay you're booking an airfare. You put in your credit card information, and you're rebooking that airfare using this particular application. You can steal the data from that application before it hits the actual airfare company or the plane company. There are API injection attacks, something called XSS or SQLi. In this particular one, they're injecting information into the API. So this is cross site scripting,which we talked about previously. So there are also DDoS attacks against the API systems. Again, you need to go into the specifics here. So some people say, "So what are the best practices?" "What can we do to help fix these APIs, right?" So the best practises we can follow here are to ensure we have good authentication. You won't be able to authenticate the user, identify that particular user, and then authorise it. So, authorization ensures that the user has access to the appropriate set of resources and nothing else. If you're giving too much access, then people can get into the API and take control of it or get access to sensitive data that they don't need. Okay, so now that you have a good understanding of APIs, do understand that they are a tax against APIs. Now, APIs are something that we use in many, many apps. Right now, there are APIs that can call for weather services like I did, or call the GPS. You see them all the time when you open the app and it's like, "Hey, show me your location." But don't forget, they are attacks against these particular APIs.

7. Driver manipulation

In this video, we're going to be talking about driver manipulation. So what exactly is this? Well, there are two ways to manipulate rivers that we need to know. For example, number one is Shimmin and number two is refactoring. But before I get into that, let's talk about drivers in particular up.So I'm going to go here to my Device Manager just so we can take a look at drivers. So I'm going to right click on my start button. I'm going to go up here to Device Manager. And here you have all the device drivers. So I'm missing a driver on my wireless LAN adapter. No one that wasn't working. Okay, so let's take a look at some different device drivers. You'll notice I have, let's say, a device driver here. And by the way, this is Device Manager. This is an eight plus if you're not sure how to use it. But if I go in here and I go to the video card and I go to driver, it will tell me that I have this version of the driver that's installed; it's from Nvidia that makes it, and it is Windows compatible. Now I do want to say it's a digital signer. So Microsoft's Windows Hardware Compatibility Publisher has digitally signed this driver. That's going to be important to understand. It's coming up in a little while. So, driver manipulation Now there are two things here. Now your Security Plus exam talks about Shiman and refactoring. So let's talk about this. What exactly is it? So first of all, you saw the driver there. Now, drivers are basically what will sit in the operating system and allow the hardware to communicate with the operating system correctly. So the operating system knows how to use the hardware correctly. Drivers operate at a very low level in the operating system, despite having extensive permissions. So drivers require a very low level of integration into the core, basically, of the OS. So what malicious hackers do, or people that write malicious code, is if they can get their code into a driver, then what happens is the operating system will execute that code at a low level. So the first one up we'll talk about is something called "refactoring." So refactoring is essentially when you take this legitimate driver. But the bad thing is that you have to get the source code for the driver. This is not easy. You have to get the source code to the driver, and you're going to rewrite the source code to contain your malicious code and then give it out to users. And they'll install it, thinking they have a legitimate driver. Now they install it, and then the actual operating system starts to use it, thinking it's a legitimate driver. And before I know it, it's actually executing your malicious code or the hacker's malicious code. So let's refactor it. Now, what the shimmin is Shimonis are basically inserting shims. You may insert a Shimano door or something to hold it there. So Shiman takes a legitimate driver and then writes malware around the driver and gives it to the operating system. So the Shim is going to be writing it around it. Now, your operating system does have Shim. Shims are basically things on top of something. So one mode in Windows is Windows Compatibility, in which case you can run programmes in compatibility mode. I'll show you that right away. If you ever have an old programme that you want to run in Windows that's not working correctly, you can actually right-click on the program. You go to properties. You go to compatibility. So this is a type of shim here. In other words, it's going to wrap this older compatibility mode around the application to make it compatible with this version of Windows. So what Shiman does with the drivers is basically take a good driver and write malicious codes around it, then give it to the operating system. The operating system executes the driver, thinking that, you know what, this is a great driver; this is good stuff. But in actuality, it is not only running the driver, but it's also executing the malicious code. So the question would be: How do we fix this? So the way to fix this is to ensure that a lot of the drivers out there are digitally signed. And because the drivers are digitally signed, any manipulation of the driver will be detectable by the operating system. So that's why you always want to make sure when you download drivers, you download them from good sources, such as straight from the manufacturer's website, where they may come with a CD, memory stick, or something like that. When you buy the actual piece of hardware, just don't download drivers from sources that you're not familiar with.