[ Site Map ]


Member Login

Home Server Security Linux Banner Grabbing
Linux Banner Grabbing E-mail
User Rating: / 0
PoorBest 
Wednesday, 13 July 2011 08:05
Documentation explaining the hazards of displaying full banner details for Apache, FTP and SendMail.



Banner Grabbing:


Banner grabbing is one of the basis of a successful attack brought fourth on computers, and servers. Banner grabbing allows a remote attacker the ability to view the Software Version, and vendor of specific running processes on listening ports. The attack, is rather intrusive as it requires direct-connections to the target utilizing telnet or netcat / cryptcat which can be utilized to connect to ports and gather software information. The later mentioned cryptcat utilizes encryption (which can avoid IDS as they do not check encrypted data).

Although the level of intrusiveness to this type of attack is rather high (and higher if you are not providing limited, or false information in regard to services in which you are providing.) As a successful banner grabbing session may provide server information leakage via software vendor and version; this information can set the wheels moving in regard to exploit searches. At this point in the game, the attacker is pretty much locking your organization into a checkmate. If you would like to see weather your version of a perticular application is susceptible to an attack, or exploit code check Security Focus, and Security Focus - Vulnerabilities. Utilizing these services will allow you to see where the vulnerabilities lay (if they have been reported) and the steps you can take to minimize the threshold of damages in which these threat agents may provide.

On Linux systems banner information can be blocked utilizing configuration files for the services in which you are providing. If you are installing the service from a tarball, you should inspect the code and files involved with the creation of the service or application. Within the files, if you notice version information which needs to be blocked; you should edit out the lines appropriately. FTP, Web and Sendmail information for banners will be discussed in this documentation. However, you should always test to see if you can gather the banner information of your server. As, if you can. You need to re-do the configuration files.

If you haven't already done so, you should update your search database. Updating the search database can be done from the shell prompt utilizing the updatedb command. After the information is returned, you should begin entering the configuration files in which you are searching for, to edit. If you are modifying your files make sure that you are creating backups before doing so. And, always perform your testing on a test server before going live. This is to avoid the event horizon of failure. Also, before making any changes you should request the approval of the IT / IS dept. of your organization. Always make sure you have the proper backing from upper management before making changes. As, if it is coming from upper management; it's supported and will be enforced. If it's not, it's dead in the water before it was ever conceived.

Apache Configurations:



Depending on your apache version (apache or apache2) you can find the configuration file by entering apache2.conf for apache2 and apache.conf for older versions of apache. It should be returned as /etc/apache2/apache2.conf Where the apache2 is, older versions will just be represented by apache (/etc/apache/apache.conf). Within your apache configuration file, you should search for the line which states ServerTokens on this line you can edit and input the following statements: Full, Minor, OS, Minimal, Major and Prod Below is a chart which provides which each statement will provide to an attacker.

Configuration Option

Information Displayed to Attacker

Full Apache Version, Additional packages and OS.
OS OS Only
Minor Apache version using x.x instead of x.x.x
Minimal Apache Version as x.x.x
Major Apache / Apache/2
Prod Only Displays Apache Server


To test to see if your configurations are working properly open a shell prompt, and enter the following




Figure 1.0: Banner Grabbing Where PORT represents the port to connect on.




As described above, you can gather the information utilizing telnet, as this can also be done for SMTP, and FTP (given you are using the ftp program), and other services. The information attackers will enter values to get information from the server. To download, or view the log, Banner Grabbing Log for netcat in Linux. To import this log into netcat, you can enter the following command(s):



Figure 1.1: Netcat Banner Grabbing from File
Where DF is, is the data file to output to.
banner.log is the data file for banner grabbing.


Other techniques to banner grabbing can be performed from within the browser. Doing so can eliminate (not fully) the usage of telnet. This can be performed by inserting invalid characterizations into the url them itself. Below, is an example of doing so:


Figure 1.2: Using invalid URL characters
The text underlined in blue is the characters used.

Although banner grabbing doesn't only stop with Apache web servers, it can also be mitigated against other services after a successful portscan; this helps the attacker determine what services and vendors you are utilizing. We will also discuss Mail, and FTP as well as SSH (which is a dead giveaway based around the fact that at this time SSH can only be utilizied on Linux operating systems and Windows can be excluded.)

SMTP Banner Grabbing:



Although banner grabbing doesn't only stop with Apache web servers, it can also be mitigated against other services after a successful portscan; this helps the attacker determine what services and vendors you are utilizing. We will also discuss Mail, and FTP as well as SSH (which is a dead giveaway based around the fact that at this time SSH can only be utilized on Linux operating systems and Windows can be excluded.)

If you are attempting to configure a mail server, you should have a few things disabled. Of those things, you will want to disable mail relaying, expn and vrfy. Mail relaying allows spammers, and attackers to spoof e-mails off your mail server to another one, in hopes of getting users to perform actions, or even changing passwords. Of the most dangerous, is getting users to either download applications from web locations or changing passwords for login access. The VRFY and EXPN commands allow users to check if a specific name, or e-mail address is enabled, or exists. Based around the premises that if accounts exist, they can begin to crack them, or utilize them as a metric to send spoofed e-mails. Modifying and limiting what a banner says, is the safest bet, as seen through the Apache configurations above. Typically a banner providing too much information looks like the one below:


Figure 1.3: Banner Grabbing on SMTP showing full details

As seen above, the yellow designates that the remote system in this case is running ESMTP sendmail, version 8.13.8, and is running on debian. Where debian is the OS of the remote mail server. This is enough information for an attacker to put the wheels in motion to find an exploit to gain access to your mail server. Additional attacks will include the VRFY and EXPN techniques we discussed briefly earlier. These attacks can be mitigated against a server as follows:


Figure 1.4: Utilizing the EXPN and VRFY Commands.

In the above demonstration, you can clearly see that the red ''server'' text is where you would say hello server. This will pretty much be your introduction to the server. After which, the attacker can continue to issue the expn root and vrfy root commands. Although they are blocked out in red, you can clearly see that the server gave the information about the root account, and to whom it belongs to. If mail relaying is enabled on this account, a spoofed e-mail can be sent, laying the foundation for a successful Social Engineering attack. Our next and final attempt to hopefully squeeze this server for information would be to attack the weakest link, the users for this, if we have properly done our homework, we can ascertain who works for the organization, including contact information and possibly e-mail addresses. And now, we are ready to begin social engineering. For this we will attempt to see if this remote server is allowing mail relaying. If it is, we can successfully send the information utilizing a spoof attack.


Figure 1.5: Mail relaying enabled - successful spoof.

A secure server will limit the information it is displaying for send mail. In addition to which, it will also disable mail relaying, and VRFY and EXPN Commands. For sendmail, you can do this by modifying the sendmail.conf file, and changing the following lines:



and add the novrfy and noexpn options. Furthermore, you can also confuse users who are attempting to root your server by modifying the following lines: DZmailer/Microsoft This will limit somewhat of the information they will be able to grab through the means of banner grabbing. To deny users from mail relaying through your server, you should utilize the access file in /etc/mail/access. This can allow you to configure your services listing by ipaddresses, and senders.

One of the older attacker tricks (and one which may still work on misconfigured servers) sending e-mail to accounts known not to exist. The whole purpose of this is to have the mail server error upon attempting to deliver the e-mail message, and send back an error. Inside the error, the e-mail header, or e-mail body would contain some information in regard to the server being utilized, version and additional locations of where other MX servers may lay in the network. Also limiting the error information which your server sends back (from Mailer-Raemon) is essential if you don't want the attacker to gain too much information.

FTP Banner Grabbing:


FTP banner grabbing is the final segment in which we will be discussing in this document. As most of this information can serve on the premises for the gathering of information, and banner grabbing (not only limited to these services). An incorrectly version of FTP will display it's banner before the login screen is even displayed; and not to mention at the end after a disconnect or failed attempt to login. Below in figure 1.6 if a failed login attempt, and the remote systems banner information (which has not been modified yet.)


Figure 1.6: Banner Grabbing proftpd for Debian Unix.


Modifying the banner information from the /etc/proftpd/proftpd.conf file, we can add ''CentOS'' to the line ''ServerName'' to make it appear as this remote debian system is in fact running CentOS. When users connect to the remote FTP, they will see the following banner in figure 1.7.


Figure 1.7: Displaying Banner as CentOS. Last Updated on Friday, 26 August 2011 14:26  



© 2007 Network Defense Solutions, Inc.
All Rights Reserved