____________________________________________________________________________ ____________________________________________________________________________ 01010111 01001001 01010010 01000101 01000100 01010011 -> 01000101 01000011 01010101 01010010 01001001 01010100 -> 01011001 ____________________________________________________________________________ HOW TO BASH FINGERPRINTING TOOLS (BASED ON APACHE) ____________________________________________________________________________ _______________________________ || 0x00: ABOUT ME || 0x01: INTRODUCTION || 0x02: USING MOD_SETENVIF || 0x03: USING MOD_SECURITY || 0x04: USING ERRORDOCUMENT || 0x05: SUMMARIZING THIS || 0x06: LINKS ____________________________________________________________ ____________________________________________________________ _________________ || 0x00: ABOUT ME Author: SkyOut Date: 2006/2007 Website: http://wired-security.net/ ______________________ || 0x01: INTRODUCTION Okay, you are here and interested in understanding what it does mean to "bash fingerprinting tools", right? If yes, go on reading ... First of all, what are so called fingerprinting tools and which ones do we bash here: Fingerprinting tools are tools, that are are coded to find out information in a specific way about a specific target. In our case we mean application layer fingerprinting tools, which are trying to find out our server (Apache) and the version of it. Later we will see that you can even do a bit more by using ErrorDocument and bash tools like Nikto for example. So what we want is simple, we do not want, that people can find out what runs on our server and in which version or at least we want to make it hard for them to find this out by using those application layer fingerprinting tools (examples: nmap, vmap, amap etc.). The code itself will be very simple, but you should understand the theory and idea behind all this and of course you should know how those tools work. Nmap for example uses a very simple technique to find out the version, it looks for the banner and believes, that it is true, what the banner says. So you could fake this easily, but we will do even more. Because more advanced tools do something special to find out the specific version, that is running on a system. They send broken requests to the server and analyze the way the server reacts. A normal HTTP 1.0 requests looks like this "GET / HTTP/1.0", now those tools do something similar to "GET/HTTP/1.0". So what we want is to block out those requests and as a result the server will not react, the tools will get nothing to analyze and become mostly useless. To annoy Nikto users a bit, we will use an ErrorDocument redirect. Nikto checks for running software on the system and compares it with its database to see if there might be a known vulnerability in this version of software. Later we will redirect server requests, that would normally display an error to the main page and Nikto will show a lot of successfull requests to the server. As a result the user has to filter out a lot of false positives. So let's start now! ____________________________ || 0x02: USING MOD_SETENVIF The mod_setenvif module is preinstalled in Apache and therefore a very good one to use and it is very useful for our plans. With this module you are able to set environment variables, which we will use to block out false requests. === code ===>>> 1 SetEnvIf Request_Method . bad_http=y 2 SetEnvIf Request_Method . bad_get=y 3 SetEnvIf Request_Protocol HTTP\/1\.0$ !bad_http 4 SetEnvIf Request_Protocol HTTP\/1\.1$ !bad_http 5 SetEnvIf Request_Method GET !bad_get 6 SetEnvIf bad_http y BadRequest=y 7 SetEnvIf bad_get y BadRequest=y ==========>>> Okay this is nothing, that should shock you. It is really a simple trick. First of all we set two variables (bad_http and bad_get) and if the request is a right GET request they will be unset (bad_http (3,4) and bad_get (5)). In the end the variable BadRequest will be set, even if only one of the other two variables (bad_http and bad_get) was not unset and as you will see later this will then block the whole request. === code ===>>> 1 2 Options FollowSymLinks 3 AllowOverride None 4 Order Deny,Allow 5 Deny from env=BadRequest 6 ==========>>> So, I will be so free to jump over the first lines and will go over to explain the important lines 4 and 5. Those will do the real blocking now! As you can see we first set the order "Deny->Allow" and in line 5 we let Apache know, that requests should be denied from the environment variable BadRequest. You should now see how it works. With mod_setenvif we build a structure, that will set a BadRequest variable if the request is not a valid GET request and here Apache will block requests if BadRequest is set. Or in other words: ONLY valid GET requests will come through. Job done? No, not yet... ____________________________ || 0x03: USING MOD_SECURITY We will now fake the banner by using the mod_security module, this is not a standard, in the meaning of preinstalled, module, but it is very often used and therefore shouldn't be difficult to install it. Take care to install the mod_security module, that fits your Apache version (there is one version for the Apache 1.x and one for the Apache 2.x). === code ===>>> 1 ServerSignature Off 2 ServerTokens Prod ==========>>> So what do we have here? Line one will turn off the serversignature and line two will only display the product ("Apache") in the banner. If this sounds strange to you, then look: This is a normal server signature: "Apache/2.2.3 (Linux/SUSE) Server at software.opensuse.org Port 80" We have now turned this off and our banner will not display it anymore, so visitors only get to know, that we are using an Apache, not more. But we will fake even this later. If you are using PHP on your webserver please set the variable "expose_php" to "Off" in your php.ini file, otherwise PHP will try to display itself in the servers banner. So now let's go over to fake our banner finally! If you have installed mod_security just put the following lines of code in your apache config file (on some systems it is necessary to add the line in the configuration, that loads the module, manually!): === code ===>>> 1 2 SecFilterEngine On 3 SecServerSignature "FAKE" 4 ==========>>> What we are doing here should be understandable for everybody. Anyway I'll shortly explain it. On line two we turn on the engine, that will filter requests and on line three we will change the servers signature (banner). Now the user will see a "FAKE", of course you can write there everything you want. You could even write the signature string of an IIS server there and then tools like nmap, which just check for the banner will tell the user, that the server is running the IIS of Windows operating systems. Job done? No, not yet... _______________________________ || 0x04: USING ERRORDOCUMENT This time we will not use any module, this time we will use a function, that is implemented in Apache and called "ErrorDocument". This function gives you the possibility to redirect the user to a specified page, when an error occurs. I will show you now the errors, that I would suggest you to redirect, of course you can add even more errors to that list, it is up to you, these are just the most important ones and the ones, that could show interesting information. 400: Bad Request 401: Unauthorized 403: Forbidden 404: Not found 405: Method not allowed 500: Internal server error In our example we will redirect all those errors to the main page of our server, doing this the following way: === code ===>>> 1 ErrorDocument 400 http://example.com 2 ErrorDocument 401 http://example.com 3 ErrorDocument 403 http://example.com 4 ErrorDocument 404 http://example.com 5 ErrorDocument 405 http://example.com 6 ErrorDocument 500 http://example.com ==========>>> I will not explain the lines above, they should be clear now... Why does this help us in our specific case? If a user uses Nikto for example to scan our host for running software and known vulnerabilities all requests, that would normally result in a 404 error and therefore would not be shown by Nikto will now be redirected to the main page. As a result the user will see a lot of those messages: "+ /admin/config.php - Redirects to http://example.com/ , PHP Config file may contain database IDs and passwords." This will be annoying and means a lot of work to filter out, what is wrong and what is interesting. Nikto even knows this and let the user know, that there will be a huge amount of false positives: "+ Server does not respond with '404' for error messages (uses '302'). + This may increase false-positives." Summarizing this we could say, that Nikto is useless or let's say, it is not that automatic as it was before our changes because now the user does have to do A LOT of work by him- or herself. Job done? YES! _________________________ || 0x05: SUMMARIZING THIS As you have seen above it is often very simple to make it harder for attackers to get information about your system and as a result to plan an intrusion effectively. In the digital world and for an attacker information is the most important thing and here we have seen, how to stop people from getting any information or at least only those, that are useless and full of false positive warnings, erorrs etc... This will make it very hard to plan an attack against your server precisely, but realize one thing: This does not secure your server in a way, that would stop a worm for example, which uses exploits without even testing for the running version. So if you have an unpatched server and think, that this document will help you securing it, you are really living risky! ______________ || 0x06: LINKS Apache HTTP Server Project: http://httpd.apache.org/ Apache HTTP Server Version 2.2 Documentation: http://httpd.apache.org/docs/2.2/en/ mod_setenvif: http://httpd.apache.org/docs/2.2/en/mod/mod_setenvif.html mod_security: http://modsecurity.org/documentation/index.html Happy Hacking ____________________________________________________________________________ ____________________________________________________________________________ EOF