The reconnaissance and scanning phases of a penetration test are arguably the most important of the entire process. Without a clear understanding of the bigger picture and the avenues potentially available to you, you won’t be going very far at all. As part of this process, it’s very likely that you regularly come up against web servers and just as likely that these servers will be hosting web applications. I mean, what’s the point of a web server otherwise, right? With this in mind, it’s critically important to be able to properly enumerate and gather information from these servers as you go about your penetration test. In this article, I’ll be discussing the usage of some of the most common automated tools created for this task as well as getting our proverbial feet wet with manual enumeration. Ready? Then read on!
Ok actually, before I go any further I’m going to make some assumptions about you, dear reader. For this discussion, I’m assuming that you are already familiar with the concept of port scanning and tools like Nmap. With that, I would assume that you know the core networking principles behind this, chiefly common port numbers, protocols, and TCP/IP networking in general. If you’re not quite there yet, I’d recommend checking out the “Bootcamp” section of Pentesterlab for a great introduction to those topics. If you are already familiar with these, then now you really are ready to read on.
Getting the Party Started with Nmap
Ok so to start things off let’s, well, start things off. We need to first run our port scan to see what web servers are being hosted on the target system. As a refresher, you would run a command such as “nmap -sS -sV -v -p 80,443 192.168.52.131” which, as you likely remember, would launch a port scan directed at HTTP and HTTPS services on the target, assuming there’s no funny business with the port numbers. This scan will reveal some fun facts about the web server/s such as what you see in the screenshot below.
Just a basic scan targeted at the common web server ports.
This is a rather basic scan of the ports and a fine place to start, however, it doesn’t take advantage of some of the greater powers of Nmap. Let’s take a minute to discuss how we can use this tool to get more detailed information through the Nmap scripting engine, which also happens to be known as NSE. There are a couple of approaches to this and it really comes down to how specific you want to be. The NSE contains a lot of HTTP enumeration scripts that can be chosen individually, if that’s your style, or you can also run the same command as above but swap out the “-sV” switch for “-A”. This switch activates the so called aggressive scan which launches a slew of detailed enumeration scripts based on the discovered services. It also includes the functionality of “-sV”, which only enumerates the version, and this is why we replaced it instead of just appending the “-A” switch. Running that scan again with the new command generates a lot more detail, as shown below.
As you can see, we received a lot more information this time. As you can also see, the scan took noticeably longer to complete but, alas, that is the price we pay for detail. For more information on Nmap and the NSE, check out the official documentation at:
https://nmap.org/book/nse.html
https://nmap.org/nsedoc/lib/http.html
Digging Deeper with Nikto and Gobuster
Using NSE can provide a lot of useful information about a web server, but to get really detailed you’ll need to use tools made just for the job. For that, I’m going to talk about two of my go to friends: Nikto and Gobuster.
Nikto is, by the creators’ description, “an open source web server scanner which performs comprehensive tests against web servers for multiple items…” That’s a nice succinct description of what Nikto does but to understand its full capabilities, check out the developers’ website at:
https://github.com/sullo/nikto
One of the drawbacks we need to be aware of, which is discussed on the developers’ site, is that “Nikto is not designed as a stealthy tool.” Basically, it launches a large-scale assault against the web server, leaving behind obvious tracks and traces everywhere it goes. This may not be an issue from a blue team perspective but if you are on a red team engagement or penetration test where stealth is a priority, keep this in mind.
Running a basic Nikto scan really couldn’t be more complicated. I mean, just look at the syntax of this command: “nikto -host 192.168.52.131”. Joking aside, this really is all you need to do to get quick standard scan up and going. Depending on the configuration and other details of the server, Nikto will return output looking suspiciously similar to what’s shown in the screenshot below. Go ahead and pause here to run a Nikto scan against your test VM (Nikto comes default with Kali Linux) to get used to the output and see what kind of information you can expect to glean from using it.
Nikto is a good automated solution to force your way around a web server and enumerate a lot of different potential vulnerabilities, but directory brute forcing isn’t its forte by default. For that, my personal favorite tool is Gobuster.
First, let’s talk about what directory scanning or brute forcing is and why it’s an important step in the penetration testing process. When you access a web server in your browser through the server’s address, you are brought either to the default homepage of the server, most commonly Apache or IIS, or the homepage of the hosted web site. This is a great place to be and get started, but there’s almost always far more to the story than that. Now, I won’t be getting into the details of web design or structure in this article but I need to mention that there is a difference between web servers and web applications or websites.
The web servers’ purpose in life is to host the applications or sites and provide access to/from the outside world. As such, a server can host multiple applications or sites. Moreover, a single cohesive site will almost always contain multiple directories and sub-directories which themselves may contain things like configuration files, PHP/Javascript/CSS source code, etc. As an example, when you see something like “www.sup3r1337stuff.com/other/dir” you are looking at the contents of the sub-directory “/dir” contained within the “/other” directory. This concept is very important when it comes to enumerating web servers as the route to exploitation may very well be contained in another directory.
Fortunately, tools like Gobuster automate the process of scanning for directories so that you don’t have to sit around typing hundreds or thousands of common directory names in a browser. Assuming you’re using Kali Linux (and let’s face it, you probably are), this tool doesn’t come standard and you’ll need to download it with “sudo apt-get install gobuster” in the terminal. Once you have that, you’re ready to roll.
The basic syntax for this tool on Kali is “gobuster -u http://192.168.52.131:80 -w /usr/share/wordlists/yourwordlist.txt”. This will set Gobuster off on a directory scan for directories matching whatever is in your chosen wordlist. Keep in mind that you can also use HTTPS and/or change the port number appropriately based on your needs.
I wonder what treasures Gobuster will reveal.
Another very useful feature of Gobuster is that it can also scan for given filename extensions on the web server and not just directories. This can be done by appending “-x .php”, or whatever extension you like after the -x, and is a good idea if you want to be more thorough in your scan.
These two tools are great and usually my first stop for automation when I discover a web server. However, there are times when automated scanning isn’t enough and you need to manually enumerate a server or application. Continue on to learn some basic methods for doing so.
Doing the Dirty Work Manually
I call it the dirty work affectionately. Truth be told, manually enumerating the server or app is something I actually like to do and it’s always a good feeling finding something on your own that an automated scan either didn’t or couldn’t. Alright so let’s talk about some of the most basic tactics for finding useful information or exploit opportunities.
One of the first places you should start when going the manual route is with the “robots.txt” file in the main directory. The purpose of this file is to disallow access to specified directories on the server by search engine bots and crawlers. When a bot reaches out to return search results, it checks the contents of the robots file and skips over anything listed as disallowed. If you haven’t noticed yet, take a minute to think about why accessing this file manually could be a fruitful exercise.
If the administrator or site developer abides by the “security through obscurity” concept of information security, it’s quite possible you will find something useful in this file that the misinformed admin thought would be hidden from view. So let’s say you’ve done this and found a potentially interesting directory to explore. You may have guessed that the next step would be to manually browse to that directory to see what it contains. What you do next is going to depend on the situation at hand, but for the sake of this article, I’m going to get into a particular example using the open-source web application October CMS.
Taking a Look at October CMS
Older versions of the October CMS application contain some serious security flaws and I’ll be walking through finding and exploiting a couple of them. To start, upon first accessing the October application back end, you will be brought to a login screen. This itself leads to one of the first pieces of interesting information that can be used in enumeration. Take a look at the screenshot below and think about what’s going on and how you or a malicious threat actor could use this to their advantage.
Notice that if you enter a username, the application responds with an error message that tells you directly whether the username exists in the database or not. If we were going to try brute forcing the login credentials, having a valid username is half the battle and gets us one step closer to access. For this article, I’m going to skip the brute forcing process and assume that one way or another, we took advantage of this error message to find a valid username and get a working password.
Alright, awesome, we’re in! Now, this is where the mentality of exploring like a user and not like a hacker comes into play. When you’re enumerating, your goal isn’t to just break the system right off the bat, you are looking for information. What can I access through the portal? What can an admin user do or not do? Can I view a database or upload a file or find other credentials, etc? Automated scans like Nikto or Gobuster discussed previously cannot do this, but the human mind can.
If you have done your directory scanning, though, you should come across a sub-directory in the “/backend” directory called “/system/updates” that shows the current build number, aka version, of October CMS that is installed. In this case, we’ve determined that we’re dealing with version 1.0.412 (build 412). A simple search through exploitdb reveals a known file upload vulnerability for authenticated users as described here:
https://www.exploit-db.com/exploits/41936
Reading section 1 of the exploit disclosure indicates that a user could upload a (malicious) file to the server if it has a .php5 extension. I’m going to skip over the process of generating a malicious payload for this article but let’s say that we craft a payload and successfully upload it using this vulnerability. You know what that means? Simply browsing to our file will cause it to trigger a reverse shell connection granting us access to the underlying server. All of this because we did some digging manually and found a way in.
Conclusion
Throughout the course of this article, I’ve discussed some of the basic methods of enumerating a web server/application both with automated tools and manual digging. Note that this is only an introduction to the topic and there is a whole world out there to explore in more depth. If you enjoyed this article and found it useful, be sure to follow my blog where I will be posting a series of similar articles geared toward beginners in the field as well as more in-depth technical articles suitable for those with more advanced knowledge and skills.
Feel free to drop a comment below if you have any questions. See you next time!
The Be0vlk Saga 