CompTIA CYSA+ CS0-002 – Analyzing Application Assessments part 2

  1. Dynamic Analysis (OBJ 1.4)

Dynamic analysis. So up to this point we’ve talked about static analysis and going through the code line by line using our decompiler. In this lesson, we’re going to talk about why you might want to do dynamic analysis instead. Now when you do static analysis, we’re going to be looking through the disassembled code. But that’s far from perfect because a lot of times it’s been changed and modified so we can’t see what’s going on. So when a malware writes, takes their code and tries to hide their intent, stack analysis can be really difficult. So what we might want to do instead is do a dynamic analysis. Now with a dynamic analysis, this involves the execution of a compiled program. And then we’re going to analyze the way it executes and interacts with the host, the system, or the network.

By doing that, we can figure out how this thing works. So if you think back to our different types of testing with whitebox and black box, dynamic analysis is more like black box, right? We’re going to run it and see what comes out the other side, what changes it makes. With static analysis, we’re trying to essentially do a white box test, right? We’re trying to get to something that looks like code so we can analyze all the moving pieces inside of it. Now when you’re doing dynamic analysis, there are a couple of different tools you’re going to use. You might use a Debugger, a stress test application, a Fuzzing application, and we’re going to talk about each of these three in this lesson. Now when we talk about a Debugger, this is a dynamic testing tool that’s used to analyze software as it’s being executed.

Now essentially what the Debugger allows you to do is step through the program instruction by instruction.If you looked in IDA, we had that pseudo code. There was 50 lines of code there. Now in a real program, there might be 5500 or even 5000 lines. With a Debugger, I can go and run one line at a time through that code or one instruction at a time based on the assembly code that that binary has. Now I can stop it at any point and then start looking at it. And that’s what a Debugger allows us to do. The Debugger is going to allow us to pause the execution and monitor or adjust the value of variables at different stages through its execution. Again, this allows us to control a little bit what’s inside that black box so we can see what comes out the other side and then we might be able to figure out how it actually works.

Now when you use a Debugger, it looks something like this. In this example, you can see a breakpoint. That little stop sign was set at line 209. This means the program will start running and when it gets to line 209, it’s going to stop. Now once it stops there and pauses at this point, I can highlight that line and I can look at the different values of the command or the value of a particular variable. In this case, it’s letting me see what the value of WCO EF bracket one is going to be. In this case, minus zero point 72. Now, does that mean anything to us right now? Not really. But if we were going through and analyzing this program, it might be helpful to know what all those things are. Now, debuggers are legitimately used by programmers to find errors in their code and then identify how to fix them. But as a malware analyst, we can use them, too.

Now, we’re not the only ones who use them, though. Some attackers and reverse engineers can use debuggers as well to step through a binary and determine how to best exploit any weakness or vulnerability in it. This is used by both sides, defense and attack. And so it’s really something that’s useful for you to understand if you happen to be a programmer and you’re working as a reverse malware engineer. Now, the next thing we’re going to talk about is known as a stress test. Now, a stress test is a software testing method that evaluates how software performs under Extreme Load. Now, that Extreme Load can come as lots of different things. It might be extreme processor load, extreme memory load. Extreme network load. That’s up to you and what you’re trying to stress inside your test.

Now, a stress test can be used to determine what could trigger a denial of service. So a lot of times we’ll stress test our own applications and our own networks. Because, for instance, when I’m setting up my new website and I’m going to have all my students come on to it, I want to know how many students can I take before the site crashes? Well, I can run a stress test against it. And when we’ve done this, we figured out that we can support 10,000 students simultaneously, or 100,000 students simultaneously, or ten students simultaneously. We have to know what that number is so we can actually sell the right number of students without giving you bad quality of service. And that’s what a stress test allows you to do.

Now, as a cybersecurity analyst, you might do a stress test of your systems to see what would make them fall down, what would make them have a denial of service. And so you can use a program like this web application Stress. You can run this program against your server and it will run a bunch of different scripts against it. And that way it’ll be able to figure out what would cause that denial of service for you. Again, this might be resource exhaustion. It could be something like you’re using up all the processor, all the memory, all the disk space, all the network bandwidth. Whatever the limitation is, you can find it by doing a stress test. And so often when you’re deploying a new network or a new web application, you would be asked as a cybersecurity analyst to test that system by putting it through some stress testing.

The next area we’re going to talk about is fuzzing. Now, Fuzzing is a dynamic code analysis technique that involves sending a running application random and unusual input to evaluate how the application responds. Now, let me give you a simple example of how fuzzing is used to see if it can crash something. For example, on my website we have a checkout page and you’re going to enter your credit card. Now, we expect what to be entered. There your credit card, right? It should be 16 digits. What if you start adding in things like special characters or letters? Will that crash our system? Well, if we do a fuzz test, we’re going to send some of those random things in there to see if we can crash it and then we can find out. Have we done proper input validation to prevent this from crashing? That’s what Fuzzing does.

It tests your input validation and your other systems to make sure you have the right protections in place. Now, fuzzing is a technique that’s designed to test your software for various bugs and vulnerabilities. Like I said, I can test your application and see if it’s going to crash when you send it some kind of wacky input. That’s what Fuzzing is all about. Now, when you use a fuzzer, there are three different ways to inject that manipulate input into your application. You can use the application user interface, which identifies input streams that are accepted by the application, such as an input box or a form or a command line switch, and then send information that way. Another way you can do it is by using the protocol and you can transmit the manipulated packets into the application. For instance, maybe you’re used to accepting things over the web so I can go ahead and modify the headers or the payloads and see if that will crash you.

And then the third way is to use a different file format. Now, when you’re doing a file format, we’re going to try to open some kind of file, but we’re going to manipulate that file. So you might think that you’re uploading a PNG file and when I actually send it to you, it’s labeled as a PNG, but it might be an executable and we’ll see if it causes issues with your system. Now, fuzzers may craft the input using semi random input or specific inputs. If we use semi random input, we call this a dumb fuzzer if we use specific inputs. On the other hand, we’re using things based on what we know works based on other exploit vectors or certain vulnerabilities that we’re trying to target. Specifically, we’re not just using anything that’s random in that case.

Now, one of the examples of a fuzzer is what’s known as peach fuzzer. The peach fuzzer platform is one of the most advanced commercial fuzzers out there. It is used by a lot of people in the industry. Now, if you want to play with it, there’s also a free community version like a lot of the tools we’ve talked about. There’s the commercial side that makes the money and then they have these free tools for us to use as we’re learning and protecting our own home based networks. Now, as you go and do something like this, you can use it against your own systems. Don’t take this and target other people’s websites without their permission. That’s hacking.

That can lay you in jail. Instead, you can target your own websites or sites you’ve placed in your lab. Now, this platform has a lot of built in test cases. Now, test cases are these different precond figured things that we’re going to work against different types of products and systems. So we have some test cases that will go against network appliances, we have test cases that go against web applications, we have test cases that go against financial data, test cases that go against healthcare. And we can use these to test these different applications. And they have different data sets that we would expect to use and different things that we would expect to cause issues.

  1. Web Application Scanners (OBJ 1.4)

Web application scanners. In this lesson we’re going to talk about a couple of Web application scanners. But first we need to define them. What is a Web application scanner? Well, it’s a specific type of vulnerability testing tool and it’s designed to identify issues with Web servers and Web applications. So we talked before about using things like Nessus and Qualis to look at the infrastructure of your network. We can scan it and identify what things have been installed or not installed across all of your network devices and all of your hosts and servers. But I said at that time that there are specific ones that we can use when we’re testing a Web application because they do a better job of it. Now, Web application scanners are set up to detect cross site scripting, SQL injection, and other types of Web attacks. And so they’re really important to use as a cybersecurity analyst who’s testing Web applications.

Now, there are two we’re going to talk about specifically in this lesson. These are Nikto and Arachni. Now Niko is one of the most widely available and widely used Web application scanners. This is a vulnerability scanner that can be used to identify known Web server vulnerabilities and misconfigurations. It will also be used to identify Web applications running on that server and identify any potential known vulnerabilities in those Web applications. Now when you use Nicko, it is a text based tool. Now when you run Nick Doe, you’re going to use it from the command prompt. You’re going to type in Nikto. You’re going to type in the host and the port you want to test. In this case, I’m testing the Web server located at 696434 144 over port 80, the unencrypted port.

Now you can see here, it shows me the target IP, the target host name, the target port, and the start time. Then it identified the server. It tells me what information it can get, and it shows me any kind of server leaks that we see. In this case, we have some. Then it starts telling me about there’s some anti clickjacking going on with X frame header options that isn’t present. And it goes in to tell me there’s some cross site scripting errors, there’s some other Xtype content errors, and other things like that that it’s identifying as it goes through the scan. Just like you use something like Nessus or Qualis, you can use Nikto to test those Web applications. Now, the one bad thing about Nyto is that it’s really this text based program.

It’s not nearly as clean and easy to see all of these errors because it’s just a bunch of text being outputted to the screen. Now, I can redirect that into a file, but again, it’s text based. So if I want to do something a little bit prettier, I can use Arachne. Arachne is another open source Web scanner application and it actually has a graphical user interface. So it looks a little bit more like what you’re used to when you’re using something like open Voss or Nessus or Qualis. Now when you’re using Arachni, it can actively test different vulnerabilities, including code injection, SQL injection, cross site scripting, cross site request, forgery, local and remote file inclusions, session fixation, directory traversal, and many more.

All of those bad things we talked about back in the web application section, all of that can be tested by this tool. And when it does it, it’s going to show you a report like you see here on the screen. And you can see in this case, we have path traversals, we have cross site scripting, we have SQL injection, we have cross site scripting in the XML tags, and we have unencrypted password forms, as well as a lot of other issues. Arachne will also tell you what is more severe or less severe based on the color. As you can see here, these red ones that are at the top of the list are the most severe. And as we go lower down the list, we get down to blues and then eventually whites, which are the least severe.

  1. Burp Suite (OBJ 1.4)

Burp Suite. In this lesson we’re going to talk about Burp Suite. And Burp Suite is a proprietary interception proxy and web application assessment tool. Now that probably brings up the question what is an interception proxy? Now an interception proxy is essentially a piece of software that sits between the client and the server. So essentially it becomes a man in the middle of and this allows a request from the client to go through and stop at that proxy and then the responses from the server can also be stopped by that proxy. By doing this it can analyze and modify those things before they’re going from the client to the server or from the server to the client. Essentially, you are the man in the middle and we use this a lot in security testing.

Now Burp Suite is a great tool for this because it allows for the automated scanning of vulnerabilities and crawling of an application to discover content while providing the tools for automating, the modification of requests and insertion of exploits, all well being. This interception proxy. Now when you use Burp Suite, it is a graphical user interface. Burp Suite has a commercially available paid version that has a lot of features or a free community version. It runs on most operating systems including Windows, Linux and Mac. If you have something like Kali Linux or Parrot OS which are both penetration testing suites, they come with Burp Suite already built in. Now Burp Suite, because of this, is often used by penetration testers and security analysts to test the different web applications.

Now, for the exam, you do not need to know how to use Burp suite, but I want to jump into my lab environment here for a second and show you a little bit about how to use Burp suite. And what I mean by it being this interception proxy, right between your client, the web browser, and the server you’re trying to talk to. Now for the exam, again, you do not need to be able to perform the actions that I’m going to in this demonstration. But I wanted to give you an idea of how to get started with a tool like Burp Suite. Now in this demonstration you’re going to notice that I’m using Burp Suite’s interception proxy function and it’s going to be used to capture information going between my web browser and a web application.

This web application is connected to a database to be able to get information from it and then display it back to the user. Now I’m going to use the information that I capture to be able to connect to that SQL database directly using another tool called SQL Map and I’m going to use SQL Map to perform an SQL injection. So this demonstration, I’m really going to show you how we kind of put some of these concepts together. Now this demonstration is one that I also do in my Pen test plus course because over there, they need to understand how to use these tools to perform these attacks as a Pen tester. But as an analyst, you need to understand how these attacks are performed so you can defend against them. And that’s why I’m showing it to you here as well.

Because all the things that an attacker might do against your web apps, you’re responsible for doing the security testing and designing and protecting those web applications too. As we said inside the objectives for the cysapplus, one of those objectives is being able to do Pen testing because that is one of the job functions of a cybersecurity analyst if you happen to be working on the red team instead of the blue team. Now if you want to learn more about how to use Burp Suite or SQL map in the real world, there are thousands of great videos on YouTube, Udemy and other learning sites that will give you that in depth training. Again, I’m just going to scratch the surface here. And for the exam, you do not need to know how to use Burp Suite, you just need to know what it is and why it would be used.

So with that said, let’s jump into my lab environment. In this lesson I’m going to show you how we use something like Burp Suite, which is a web proxy to grab cookie and session data to be able to feed it into an SQL injection.

So to begin this SQL injection, we first need an SQL injection vulnerable website or database. And so on the left of my screen you can see the damn vulnerable web app version 10 seven, which is being run inside the Metasploitable two virtual machine. Mycolly machine is going to make a connection to it, which I’ve done here, to be able to access this website. Now, the way this form works is if you put in a user ID, for instance, record number two and hit Submit back will pop up the first and last name of the person. That’s all this database interaction is doing for us.

Now, what I want to do is I want to be able to grab that information, stop it from being sent to the web server from my browser by using my web proxy, and then I can capture the data from it that I need. To do that I have to go to my proxy setting inside of Burp Suite. And right now you can see my intercept is on. Now I need to configure my web browser to actually use that proxy. So I’m going to go down to my Preferences and from Preferences we’re going to go to Advanced, click on Network and then click on Settings under Connection. From here we can set up the manual proxy and I’m going to use the localhost one hundred and twenty seven zero zero one on port 80 80. This will tell it to use my Burp Suite tool. So if I go ahead and close that.

Now if I go in and say I want to get record number three, notice when I submit it I don’t get the answer back in my web browser because my web browser hasn’t actually made a connection to the web server that’s going to give me that information. Instead it sent it to the right over to Burp suite which has captured it. And notice that Burp suite now has that cookie information that I need. It tells me the security level, it tells me the PHP session ID and I’m going to be able to use that as part of my attack against this web server. So the first thing I want to do is I want to capture some of this information. First I need to know the website that we were trying to go to. So I’m going to go ahead and copy that and I’m going to go ahead and go into my terminal.

And so what we’re going to do is we’re going to use SQL mapu and we’re going to provide the website that we’re going to so I’m just going to paste that in and then I’m going to use cookie equals and I’m going to copy the information from my cookie. So let me go ahead and bring that back over to Burp suite and we will copy this cookie information and then we will paste that in and from there we’re going to go ahead and hit enter. So at this point it’s going to start querying the database. The first thing it notices is that this is in MySQL database. So it’s asking do I want to skip all the test payloads for other databases? And in this case we’re going to just use the default of yes. And it’s going to say do you want to include all of the tests from MySQL? And we’ll go ahead and say yes and it’s going to go through and start querying that database and trying to do different injections.

So you’ll notice here that it is trying to do different testing based on the version of MySQL, trying to do things that are stack queries and other errors to figure out what this is vulnerable to. So now it finds that it found an ID parameter that was vulnerable that said ID equals two or ID equals three. Do we want to keep testing others? We’ll go ahead and say no because we already found a way into this database and now we’re going to see everything that it found. So if I go ahead and scroll up a little bit, we find that the get ID is vulnerable. We also found that it was vulnerable based on a boolean based blind. It was vulnerable based on an and or time based blind and it was vulnerable based on a union query. We also were able to find out that the web server was Linux Ubuntu eight four.

We found the version of Apache, the version of PHP and the version of this database and all of that information is now saved to this file as shown in green on the screen. But that really didn’t give me a lot of details yet that I want to use. It just tells me information about our target. And so now what I want to do is I want to enumerate the databases. So I’m going to add a dash dash DBS at the end and hit enter. This is going to go through and find what databases are on that server. Notice it found seven databases dvwa, Information, schema, metasploit, MySQL, OAS, ten, Tikiwiki, and Tikiwiki 195. Now the one we want to target here is the Dvwa, the damn vulnerable web app. And so now that we know what database we want to target, which is the Dvwa, I want to select that database with my command.

So I’m going to go arrow up again, go backspace, put a capital D which stands for database and the database I want to select and then I want to enumerate it for the tables to figure out what tables exist inside that database. So I’m going to put tables and that will tell me what tables are associated with it. Go ahead and hit enter. And it goes through and scans and it finds two tables, guestbook and users. So now I want to be able to dump the columns from those tables. Again, I went from the database down to the table. Now I want to dig in a little bit further and get those columns. So to do that we’re going to arrow up, we’re going to backspace out of tables and do t and give it the table we want, which is users and then columns. And off we go. We now have six columns, the user avatar, first name, last name, password, and user ID.

Wouldn’t it be great if we can get those passwords for those users? I think it would. So let’s go a little bit further here and what we’re going to do is arrow up, take out the word columns and put in the word dump. And here we go. Do we want to save this hashes to a temporary file? We’ll say no. And what it’s doing is it’s grabbing any password hashes from the password column and it’s going to attempt to do a dictionary attack to crack them. And then we’re just going to go ahead and use the standard default dictionary of number one and we want to use common suffixes. No, we’re just going to use the default things and it’s grabbed those hashes and it’s already starting to crack those passwords. Notice that I already have a password for Charlie and ABC one and password and let me in.

And here it is on the screen. And so you can see that the first user ID is admin and their password in parentheses is password. The second user is Gordon B and his password was ABC. One, two, three. The third username was 1337 and their password was Charlie. The fourth was Pablo with Let me in and the fifth was Smitty with password. Again, these were all very simple passwords and easy to crack, but you can see the power of an SQL injection. We can interact directly with that database because we’ve been able to break through the PHP front end and be able to inject into the the database and get information back that we shouldn’t be able to get back. And because SQL map is such an easy to use program, it makes our injections very automated and very easy to use.

 

img