Sometimes to go forward, you must go backward. Understand how you can use decompiling and debugging to work backwards to learn a programs secrets and weaknesses, so you can determine the best way to attack it. There are many resources, so you don’t have to do the work yourself, sometimes the work has already been done for you. Learn what those sites are and how to use them.
- Penetration testing is a lot like peeling an onion, you go layer by layer and get closer and closer in, and sometimes, you end up crying. But it's a fun process in the process. And what we're going to be doing now is kind of just peeling one more layer of that onion. We've started off planning, we've now gotten a little bit of an idea of what's out there, the different targets we may want to start attacking, or at least working toward the attacks.
And now, we need to learn more about these targets and try to figure out how we can find some of their soft spots, look for the vulnerabilities. So, let's peel away one more layer of the onion, and let's take a look at one particular type of attack, or rather, type of target. What if the target is an application? What are the things we can do to help target an application and find its soft spots. Well, first off, we can attempt to take an executable and turn it back into source code, that's called decompilation.
So, let's back up for a second, and talk about how programs become programs. In the very beginning, application developers will write source code. Source code is code that's written in text form, and it's generally readable, and then they will take that source code and give it to another program as input, as a compiler, the program is typically called a compiler. The compiler translates source code into object code or executable code.
Now, that's very, very general, there's different types of compilers, and some languages are actually interpreted, which means they're kind of compiled and executed on the run, but if you have an executable file, you can actually take that file and reverse the compiling process, and that's called decompiling. A decompiler makes an attempt to convert executable instructions back into source code. Now, it's awkward when you do it this way because the output is very difficult to read, it's awkward to read, at best, because it's one thing to take really nice-looking code and compile it, but then, when you go the other direction, the decompiler just kind of has to guess at what the programmer was really doing.
And so, what you end up with is tough to read, but it gives you an idea of what the program was trying to do. Sometimes, however, you don't have executable code. As I mentioned earlier, sometimes, you're using an interpreted environment. Java is a perfect example of that. In Java, you don't end up with executable instructions, you end up with opcode, or it's a code that's compiled to be run in a specific environment. In the Java environment, it's called the Java Virtual Machine, or the JVM.
So, you can take that, and you can still run it backwards and see what the programmer may have intended to do, and you can use that to find weaknesses in what the programmer did. So, that's one way that you can use a particular type of tool, a decompiler, to try to figure out where the weak spots of an application would be. But that's not the only thing you could do. You can use another tool that programmers tend to use, called a debugger. A debugger is a very interesting type of tool set, and there's a lots of different debuggers out there, that allows programmers to run a program in a controlled environment, so that they can stop the program anywhere they want to and examine memory, which is very helpful whenever you're attempting to get software errors out of your program.
Now, software errors are typically called bugs. There's a really cool historical reason for that because way back in the olden, golden days of computing, back in the 1960s, when computers were the size that would have to fit into gymnasiums, they were that big, and all of the connections, the switches inside them were mechanical switches, they would actually be electrical switches that would move back and forth, there was apparently a bug, or rather, an error, in one of the switches, it wasn't closing properly.
And it caused everything to just be wrong. It messed up the whole computing process. And finally, a technician was crawling around in the inside portion of the computer and found that a moth actually had gotten lodged in one of the contacts. And so, when they pulled that moth out, everything worked properly, and that was the first computer bug. And from that point on, software errors are called bugs because it stops things from working the proper way.
Programmers spend most of their times debugging their own code, or somebody else's code, because writing perfect code is nearly impossible. So, you end up writing code, and then you need a tool, like a debugger, to be able to step through and figure out what's going on and what's going wrong. Well, debuggers work great for attackers because if you can take a program and then step through the execution, and stop and look at memory at will, you can, in many times, find problems.
One of the tools that we're going to be looking at, and you'll be responsible for on the exam, will be windbg, W-I-N-D-B-G, that's a debugger for Windows executables. That program, as well as any other debuggers that we may encounter, are helpful because it can, as I said, reveal the secrets of an application and the weaknesses, and help us determine the best way to attack them. And whether your attack target is an application or not, there're many places where you can find sources of information.
In fact, what we want to do is, once we identify the target, again, it can be an application, it can be a user, it can be a particular operating system, or host running a specific operating system, once we can identify what we're trying to attack, then we want to go find other sources of intelligence to determine what are the known weaknesses for that particular type of target. So, there's lots of open-source intelligence repositories that help us do this research and makes it, well, fairly easy to us to find lists and lists of known vulnerabilities.
Let's take look at a few of those. We're going to look at the process called open source intelligence gathering, or OSINT, is the way it's normally referred to. And there's lots of those sources, starting with, one of the most common would be CERT, the computer emergency response team. And here is the URL, it's us-cert.gov. So, let's go take a look at CERT and see what we can find. So, this is the US-CERT website, again, us-cert.gov.
You can subscribe, using your email address, to their updates, and they'll send you lots of updates whenever new vulnerabilities are uncovered. You can also download the report, and you can search through their vulnerability database. And if we just scroll down a little bit, it shows you recent vulnerabilities by date. So, there's lots of vulnerability notes, you can look at updates, there's lots of articles, but it gives you a lot of information about current vulnerabilities.
And you can dig back into history to find older vulnerabilities, as well. Another great resource would be NIST. This is the NIST Computer Security Resource Center. And again, this is another place you can search through various vulnerabilities, and it gives you up-to-date information on vulnerabilities and announcements for computer security. You can look at ongoing projects, specific topics, you can search through CSRC and find lots more information.
Now, the idea behind all of these are open-source intelligence gathering. So, we're going to go find more and more information, the latest information, on known vulnerabilities for specific environments or specific targets. Another one is JCERT, which is Japan's version of CERT. And here, we find JVN. JVN is Japan Vulnerability Notes. Again, it's a entry-level point for vulnerabilities. These three are the most common three, or the first three vulnerability sources that a lot of people start looking at, but it's by no means the only options that we have.
In fact, there's lots and lots more. And those include CAPEC, Common Attack Pattern Enumeration and Classification. I'm not going to go through each one of these, but I do encourage you to visit each one of these and be aware of what they are. Full disclosure, which is a mailing list from the same people that brought us Nmap, and CVE. Now, many people would argue that CVE, the Common Vulnerabilities and Exposures list, may need to be number one in our list. So, since it's so important, I do want to go back and check on this and take a look at CVE.
CVE is a list of all the common vulnerabilities, and it shows the participation groups, who all's participating across the world, so lots and lots of people are participating in providing CVE input. We can download CVE, or we can search the CVE list. So, let's assume I want to search the CVE list, and let's take a look at Windows 10, see if we find anything there. Well, actually, yeah, we do.
I'm going to scroll a few times, but let me point out to you, look at the scroll bar on the right-hand side. These are all vulnerabilities which mentioned Windows 10. So, I'm going to scroll back up to the top and just pick one. If I pick one, it gives the CVE ID, a description, and all kinds of information about that particular vulnerability. So, if you can find the target of your attacks, or identify a target, you can then go to a list like CVE and search for that target's name, that target ID, in this case, we use Windows 10 because let's assume that we found that one of the computers was running Windows 10, and we can search for lots of vulnerabilities, and these are ideas for us to attack the actual computer.
So, that's the idea behind using these different sources of intelligence. And lastly, in our list of repositories that you need to be aware of for the exam, is CWE. It's the Common Weakness Enumeration, which is an alternative to CVE. So, take a look at CVE, as well as CWE. Those kind of complement one another. And this gives us a rich repository of known vulnerability information. It can serve two purposes: It can help us, as pen testers, know what to look for to help protect our systems; unfortunately, it also helps the attackers know where they need to attack, as well.
So, the more that you know about it, the better you'll be able to keep your own client's systems more secure.