Getting the name of the server software through netcat or curl or any other method, is really useful?
I mean, OS fingerprinting is useful in order to tailor an attack. For example with regard to OS command injection it's obviously important since command syntax is OS dependent. But if I know that a specific site has an Apache server, does that really matter? If so, can you explain it to me?
Like when doing car maintenance, when you know which constructor, you will take the right maintenance manual (Don't try to repair a Ford Granada with the manual of a Honda civic).
When trying to break a particular system, you will browse for known exploit that could help you for this particular system.
Every net servers (From Sendmail to Apache, with Samba, wuFTPd and all others) have a bunch of published exploits which let an attacker to execute arbitrary code by using previously discovered security failure. All critical failure are quickly patched and newer version are published...
If a server use Zebulorglub V2.0.1, don't try exploit concerning Zebulorglub V2.0.0 or older, but could try exploit working on V2.0.1 or higher...
(Nota: Zebulorglub is a dummy name;)
Knowing the exact version of the web server (and application server and DBMS) helps you a lot when performing a test.
First and foremost, it helps you when checking for public exploits and vulnerabilities.
Let's look at a famous example: kingcope's killapache.pl. The script targets a specific vulnerability found in several versions of Apache HTTP Server, which was later fixed by the vendor.
If you knew the version of the web server on the target host, you could use the public exploit only if the version is known to be vulnerable and you wouldn't bother to test exploits made for, say, Microsoft IIS.
Furthermore, knowing the version of the web server allows you to make use of default resources (e.g. Apache's) and possibly exploit them.
The same principles apply to the application server and, even more, to the DBMS. Knowing the version of the database used by the target web application, for example, allows you to test using the correct SQL syntax right away.
Server names may be useful, depending on what the name is. For example, if the server name is "db3", then its role is probably a database server, while if it's name is "dev1", then it's probably a development server. What does that tell you? It might tell you which one to attack first.
Alternately, if it contains a real domain name, then that might clue you in as to who owns the server, which might help focus your attack.
If the server's name is "galileo" or "sasquatch", that probably doesn't tell you anything at all.
It's considered one of the things to certainly test according to the owasp testing guide. If the server is advertising the version number, an attacker can reduce his scope of attacks significantly. Refer to https://www.owasp.org/index.php/Information_Leakage
Yes, service fingerprinting is useful during a pentest. Information gathering is a critical (many would say the most critical) portion of a penetration test. Understanding everything you can about the target environment not only can help you gain an initial foothold, but it can be of much use after an initial foothold is obtained.
I will juxtapose two very common situations we see during pentests: one where the test is only able to tell what the OS is and if the port is open, and another in which the tester is able to obtain detailed information on a service.
The port is open and OS is known but not service version info -- Considering an FTP service, you may be able to connect to the service and try some generic FTP checks such as anonymous login; however, at this point you are (for all intents and purposes) limited to these generic checks and simple attacks such as brute-forcing the service to obtain valid credentials.
The port is open, the OS is known, and the specific version info is known -- Considering an FTP service, say an nmap <target> -sV scan identifies the server as PwnMeFTP 1.1.3. This is extremely useful as you are no longer limited to generic checks for the service. Now you can take meaningful next steps such as (there are more too ;D):
PwnMeFTP 1.1.3, and see if any exploits are available. This could be a quick win.1.1.3 in this example) and set up a lab matching the target environment. The closer your vuln analysis/exploit development lab mirrors the intended target, the higher likelihood your actual exploit will be successful. If you don't have service version information a lot of this process can turn into a fruitless shot in the dark.PwnMeFTP 1.1.3, you can leverage it to elevate privileges to a more powerful user after obtaining initial code execution on the target via another service such as a web application vulnerability.1. above I mentioned potential brute-force attacks. If you know the service version, you can have well-informed attacks that are more likely to succeed. If PwnMeFTP has a default admin user of pwnme with a default password of pwnm3, it may be as simple as trying that credential set.As a quick anecdote, we recently did a pentest for a client with approximately one week to cover several hundred IPs. After conducting deep information gathering, we were able to obtain version information for software running on a server that was missed by automated checks. Knowing this information allowed us to identify vulnerabilities associated with the software, of which there were a few. Knowing this, we dedicated a few days to working with this attack path and in the end were able to get an exploit working at the last minute. None of this would have been possible in this time period without knowing the version information.
Along with the Server header, there are other headers that can give valuable information, like X-Powered-By. This can help you to find out what framework/language was the site coded with. There are attack vectors only applicable to certain languages, so that gives you an idea of what attacks you can start with.
When thinking about a penetration test it is useful, but it depends upon the stage of the test. This would fall under the category of information gathering this phase is when you would be gathering information similar to this. This information can be used to compile a more complete look at an organizations infrastructure. If you discover an Apache server you now know which platform and hopefully version you will need to research for potential vulnerabilities.
The way hacking works is by using an attack vector such as a PHP script letting you write a file to the server and then execute it.
Say you have a website which allows for uploading files to:
/var/www/my-app/files/here.php
And then you did not protect that folder meaning that you can execute that file:
http://www.example.com/files/here.php
At that point, the hacker has full control of your machine. This here.php script probably lets him upload more PHP, do a git clone super-bad-stuff.git, etc. and possibly find ways to gain root access on the machine.
What the hacker had to do is check your web app and see whether a certain attack vector exists.
At first the hacker wants to learn more about your server and web app. With knowledge about your app, the hacker can decide on which script to run to gain access. So determining the names and, if possible, the version of your web server and web app. is important.
The Apache server on its own may be a vector of attack, although in most cases it's going to be an Apache module or a web app such as Wordpress. This is because Apache is much less likely to have a vector of attack (although I've seen one where you could crash the server and it had a small window of time when you could connect in such a way that you could gain a certain amount of access rights not otherwise available...)
So... the first script tries to connect to port 80 and/or 443. If that fails, maybe try a few more like 8080 or 8443...
Once connected, the script sends a first request, in most cases a GET. Just a simple GET from the home page is likely to indicate a lot of things. The HTTP Server: ... header, as you mentioned, is likely going to tell us the name of the server and, if not changed, the version and OS it is running on:
Server: Apache/2.4.18 (Ubuntu)
Note: Here I show the default for Ubuntu 16.04. If you check on a different Ubuntu version, the Apache server will have a different version. So even though the
Server: ...did not directly reveal the version of Ubuntu you are running, the Hacker already knows it from this. Also if you are running Apache, you are likely to have Linux. If you run ASP, you have to have MS-Windows.
The HTML header will also often have information about the Webapp. For example, you often get a meta tag describing the service:
<meta name="generator" content="wordpress 1.2.3"/>
Now you have yet another piece of information! Again, many of the tags in a file will indicate which version of the webapp you are running. Nothing too complicated, just time consuming to get it all right.
With all of this data, the hacker is not unlikely to be able to pinpoint one or two possible vectors of attack out of his database of thousands of possible attacks, although if you keep your software up to date, a good firewall, etc. probably zero known possible vectors of attack at the moment.
This work is done using another script run on the hacker's backend. This script does a form of lookup in a database. How that works probably varies greatly between the various hacker scripts available. It may even be a manual task for some.
If a vector of attack exists, then the database query returns the name of the next script to run against your server. This one is the one which will penetrate your server using the known vector of attack.
Note: when the query script fails finding an attack vector then either everything stops or some of the existing scripts are still run against your machine to see whether it was patched or not. After all, you may be lying about the version you are running...
At times, the database search may ask for more data. For example, the hacker now knows you are running Wordpress, but nothing enlighten him about the version. To determine the version, he needs to access another page. If that page exists, then we know it's at least version 1.2. Another request to another page/data file may tell use that it's at least version 1.2.5 (i.e. a theme added a PNG image at that version.) The possibilities are large and wide. If a certain theme does not exist, it may mean you have a newer version. If a certain script return 2 instead of 3 when accessed in this or that way, then it's version x.y.z, etc.
If you ask me, for most CMS, it's pretty much impossible to hide their version. If you do a diff between two versions, you are very likely to find a way to write a query such that you'll get the version information. It's work for the hacker, but it's not that complicated.
With the name of the script to be run, now you are ready to penetrate the service you found. The complexity of this script may vary greatly. The example of attack on Apache I mentioned above can take a very long time. You have to purposefully crash the server and reconnect at the right time. I've seen such at attack on one of my servers, it lasted weeks (I did not see it immediately...) and the script never worked. Some other scripts will gain access in well under 1 second.
Once the penetration has occurred, the hacker installs its own software and takes over the computer. From there on, it's very much like the hacker has gained full access to your machine (as if he owned it.)
The best hackers will have a server where they run a genuine spider. This spider will check millions of websites in an attempt to determine the software they are running and save that information in their database.
This is step 1. above.
They may check just the home page, all the pages they can find as Google does, it will vary greatly. They may also try to access pages that mean certain tools are installed on your system (i.e. myPhpAdmin.php) but in most cases this first step has to look clean so they should limit themselves to a regular spidering scheme.
This is fantastic because you could have an amorphous website which has a static home page and then Wordpress for the blog, Drupal for your book, phpBB for your forum, etc. All of that gets registered in that database.
Well... Actually, it's much more than that. Remember Step 2. above. This is the search for a possible attack vector against a website. In most cases, assuming people keep their website up to date, that should be zero. However, a hacker may find a new way to penetrate a certain type of website (say Wordpress 1.2.3) Now the hacker already has thousands if not millions of websites in his database, he can do a cross product search between the new vector of attack and all the websites that already exist in his database. If he finds matches, he can start Step 3. on all of those. People who already upgraded to Wordpress 1.2.4 will be safe. People who still are on Wordpress 1.2.3 will have their website hacked.
Many of the servers that get hacked do get destroyed. But some hackers will use the hacked site to add a few pages, send spam emails, etc. Do rather nondestructive albeit unwanted work with your machine. The smartest would try to use a minimal amount of your CPU and bandwidth so they don't get detected (not easily) and can keep using your computers for months...
