Tuesday, February 18, 2014

Light weight Web vulnerability scanner - Nikto!


Since I received useful feedback on the article on SSL scanning tools. Here is another useful tool "nikto" that I use frequently to check the common security related misconfigurations on my Apache httpd web server. Basically a lot of times we try fixing a web server for security problems, most of the times we are not sure if we fixed the issue. Using a light weight scanner to quickly test your results could be extremely useful as you dont want to wait for those bulky Qualys and Nessus scan reports.

Nikto is a perl script and requires you to have a perl setup installed. It is a web based vulnerability scanner that tests your web server for common misconfigurations. Read more on its homepage.


Get it from here:


Use cases

My favorite use of Nikto is to test three very important things on my web server:

  1. The HTTP methods that are allowed on my web server
  2. Is directory listing enabled ?
  3. How much information my server is revealing about itself, the version numbers, modules being loaded etc.

Short info on those 3 points:
As a short rule, you should not have methods other than HEAD/GET/POST and OPTIONS allowed on your web server. Why? Because the other methods like TRACE/PUT/DELETE etc are rarely used these days and it is a good practice to turn them off.   

Directory listing is when the web server starts displaying the contents of a directory.

Information revealed: Your web server might be reporting some information to an attacker that could be of use for further attacks. Like the following HTTP headers reveal that an Apache is running version 2.2.3 and the platform is RedHat linux.

https://1x.xx.xx.xx/RSA-Crypto/ GET /RSA-Crypto/ HTTP/1.1Host: 1x.xx.xx.xxUser-Agent: Mozilla/5.0 (Windows NT 6.1; rv:21.0) Gecko/20100101 Firefox/21.0Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8Accept-Language: en-US,en;q=0.5Accept-Encoding: gzip, deflateReferer: https://1x.xx.xx.xx/Connection: keep-alive HTTP/1.1 200 OKDate: Mon, 24 Jun 2013 04:01:47 GMTServer: Apache/2.2.3 (Red Hat)Content-Length: 1118Connection: closeContent-Type: text/html;charset=ISO-8859-1

Trial Run

Now suppose after enabling enough of security settings on your web server, you quickly want to test how does it look from the outside:
So you fire up Nikto:

root@bt:/pentest/web/nikto# perl nikto.pl -host https://xx.xx.xx.xx
- Nikto v2.1.4
+ Target IP: xx.xx.xx.xx
+ Target Hostname: xx.xx.xx.xx
+ Target Port: 443
+ SSL Info: Subject: /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
Ciphers: DHE-RSA-AES256-SHA
Issuer: /C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root@localhost.localdomain
+ Start Time: 2013-06-22 10:36:12
+ Server: Apache/2.2.3 (Red Hat)
+ OSVDB-3268: /: Directory indexing found.
+ Hostname 'xx.xx.xx.xx' does not match certificate's CN 'localhost.localdomain/emailAddress=root@localhost.localdomain'
+ Apache/2.2.3 appears to be outdated (current is at least Apache/2.2.17). Apache 1.3.42 (final release) and 2.0.64 are also current.
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST
+ OSVDB-3268: /./: Directory indexing found.
+ OSVDB-3268: /?mod=node&nid=some_thing&op=view: Directory indexing found.
+ OSVDB-3268: /?mod=some_thing&op=browse: Directory indexing found.
+ /./: Appending '/./' to a directory allows indexing
+ OSVDB-3268: //: Directory indexing found.
+ //: Apache on Red Hat Linux release 9 reveals the root directory listing by default if there is no index page.
+ OSVDB-3268: /?Open: Directory indexing found.
+ OSVDB-3268: /?OpenServer: Directory indexing found.
+ OSVDB-3268: /%2e/: Directory indexing found.
+ OSVDB-576: /%2e/: Weblogic allows source code or directory listing, upgrade to v6.0 SP1 or higher. http://www.securityfocus.com/bid/2513.
+ OSVDB-3268: /?mod=&op=browse: Directory indexing found.
+ OSVDB-3268: /?sql_debug=1: Directory indexing found.
Check out the following lines:

+ Server: Apache/2.2.3 (Red Hat)
+ OSVDB-3268: /: Directory indexing found.
+ Hostname 'xx.xx.xx.xx' does not match certificate's CN 'localhost.localdomain/emailAddress=root@localhost.localdomain'
+ Apache/2.2.3 appears to be outdated (current is at least Apache/2.2.17). Apache 1.3.42 (final release) and 2.0.64 are also current.
+ OSVDB-877: HTTP TRACE method is active, suggesting the host is vulnerable to XST

So Nikto tells us that it found the directory listing enabled on this server, it found an undesirable method enabled on this server i.e TRACE and it tells us about the Apache version and its platform. It also tells you are running a very old apache version and the latest available version is 2.2.17.

Now you are sure that the changes you placed in apache config worked or not.

Want SSL support on Nikto?
Use cpan to install SSLeay module in perl. I hope you already have perl installed.

cpan[5]> install Net::SSLeay

Using SSLScan and ssl_tests for testing weak ciphers

I came to know about the following good tools to check the ciphers running on you SSL service and SSL vulnerabilities.
Often we have this situation where we have various SSL enabled services running on the product, but we do not have a way of verifying the SSL cipher quality.

Use SSLScan and ssl_tests to test for weak ciphers running on your SSL service. I tested it for Apache httpd (443), tomcat (8443).
ssl_tests also tests for common SSL vulnerabilities like the SSL/TLS cipher renegotiation. sslscan primarily does a brute force for Low, medium and high grade ciphers and lists their status as 'Accepted' or 'Rejected' depending on the SSL service's response.

ssl_tests is a shell script that relies on the sslscan tool for making the checks.

Compiling sslscan is generally easy and straight forward but in case you face errors like the one I faced:

gcc -g -Wall -lssl -o sslscan sslscan.c
sslscan.c: In function ‘getCertificate’:sslscan.c:992: warning: implicit declaration of function ‘EC_KEY_print’sslscan.c:992: error: ‘union ’ has no member named ‘ec’sslscan.c:995: error: ‘union ’ has no member named ‘ec’make: *** [all] Error 1

You can tweak the source code to comment out the lines related to EC keys in sslscan.c (most probably you wont be using EC keys) :

//EC_KEY_print(stdoutBIO, publicKey->pkey.ec, 6);
//EC_KEY_print(fileBIO, publicKey->pkey.ec, 4);



Tuesday, December 14, 2010

Mount an ntfs drive with read only permissions in Linux

Say I have booted a Linux using Live cd or something, and I cant modify any windows file since the windows ntfs file system is in a read only mode. So this is how we can remount it in a read write mode:


umount /mnt/hda1
modprobe fuse
ntfsmount /dev/hda1 /mnt/hda1


else find the google cache if the page is unavailable :(


Commands to set network settings in Ubuntu

ifconfig eth0 netmask

route add default gw

echo nameserver > /etc/resolv.conf

ifconfig eth0 up

Tuesday, June 8, 2010

Manual Removal of sguza.exe and shey.exe worms

New malwares in town. Not much info available on Google.

Again my AV failed to recognize a malware, but when I saw autoruns and hidden folders named muza and carpet in my pen drive, I got suspicious. These files and folders are system files, so if you cant see them, then you need to go to Tools->Folder options->View and set the following settings:

enable Show hidden files and folders
Hide protected operating system files.

Malwares often attribute themselves as system and hidden to stay invisible.
Unfortunately Autoruns and Autoplay were enabled by default on my new system. And it popped the option of "action=Open folder to view files using Windows Explorer". Which could be misleading
as I found the same action in autorun.inf as well. After inspecting the autorun.inf, I believe even if you right click and explore/open its copy gets executed. It has variants in the name of shey.exe and sguza.exe and moves through removable drives. Once its executed you cannot remove the autorun.inf or the hidden folders. I took the help of utility Handle (http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx) by Sysinternals to find out which app has opened the Autorun.inf.
Execute Handle.exe using command prompt and output the results to a text file. And search using CTRL-F for autorun.inf.

explorer.exe pid: 540 administrator
6E4: Section \BaseNamedObjects\MSCTF.MarshalInterface.FileMap.ECE.B.NMKKAD
6F0: Section \BaseNamedObjects\MSCTF.Shared.SFM.ECE
6F8: File (RWD) C:\Documents and Settings\lada\My Documents\Downloads
700: File (---) E:\autorun.inf

And as always it was explorer.exe:
which means the malware is using explorer.exe as a host.
I killed and restarted explorer using task manager.

Alternatively we can use Process Explorer (a tool by sysinternals, which is kindof an advanced Task manager) to inspect the explorer.exe and search for SHEY.EXE or other handles and then close them.
Start process explorer and do a CTRL-F search for any handle with the names: SHEY.EXE, SGUZA,EXE,
mrpky.exe 194.EXE, 21782259.EXE OR KITA375[1].EXE, OR autorun.inf:

Search for the file names.
If found, close those handles.

After you kill the malware instance, using Proc Explorer OR by restarting explorer.exe, you will be able to delete the muzo and carpet and autorun.inf files.

I deleted the autoruns and the hidden folders named muza and carpet.
The next step was to clean the registry. So you search for all occurrences of shey.exe and sguza.exe and delete them. The malware may use some other names as well, which I found here:


I found the malware still running inside the explorer with the name :
This file is located in C:\Documents and Settings\your_username\Application Data

Again searching the registry I found an entry in the WinLogon startups: (You may use Autorun and ProcessExplorer tools from Sysinternals for this)

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Taskman with a value of C:\Documents and Settings\username\Application Data\mrpky.exe

So I deleted this registry entry and deleted the mrpky.exe as well. I searched for other names but as of now couldnt find any.

I restarted my system, and I am not seeing any weird behavior as of now. If I insert a pen drive, it doesnt show any autorun.inf. Nor I am seeing any suspicious exe or dll in explorer. (using process explorer)

Thats all for now.

1. If you cannot delete the hidden folder muza or carpet, then kill the explorer.exe using task manager and restart explorer.exe. This will kill the malware instance.
2. Now delete the hidden folders muza or carpet and then delete then autorun.inf as well from your removable drives.
3. Open registry and search for all keys containing sguza.exe or shey.exe and all other probable names here :
http://www.prevx.com/filenames/X285138109880396664-X1/SHEY.EXE.html and delete them.
4. Disable autorun and autoplay.(use links section)
5. If at all, the malware still works then it suggests we missed a copy of it. So when you restart your computer, it will be executed again. But all the instances use explorer.exe as a host, so if you want to kill them, restart explorer. But any undeleted registry entry will restart the malware when you restart windows. That doesnt sound good, but we can wait for the AVs to create a tool or reverse engineer it for more details.

Prevention tips:
Disable autoruns and autoplay for all removable drives. http://support.microsoft.com/kb/967715

For more details about the malware, you can upload the exe on virustotal.com which provides the AV detection results from various Anti Viruses.

Here are the results from the unpacked mrpky.exe:

Handle by SysInternals: http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx
Turn off autoplay: http://support.microsoft.com/kb/967715
VirusTotal: http://www.virustotal.com/

Sunday, April 25, 2010

Getting root/administrator on a Windows XP

Getting root/administrator on a Windows XP

Well this is my old school trick, the Sticky keys hack. I kindof discovered (though I wasnt the first person to do it, but it was pretty less known hack a few years back) it years back, and I am surprised to see that it still works. This is not a one-click kiddie stuff, though its simple and easy.
In the end, I will also show you how to stay STEALTHY and cover your tracks.(to some extent)

Let me explain you the case precisely:
You have a guest account or any other NON-ADMINISTRATOR account.
And you want admin privileges. Naturally I assume, your admin doesnot want to share the admin password with you.

There is ATLEAST ONE CONDITION for this hack to work (apart from this, I aint aware of any):
Your non-admin account must have write permissions for the system32 directory. That is you should be able to write/modify any simple file in the system32 directory.
Dont worry, we are not going to mess with the ugly SAM and SYSTEM files.
Now I would like to explain some basic mechanics, if you are not interested you may skip it. But if you understand it, I believe you should be able to find many such hacks.

Basic mechanics:
When a user logs in, and a process is executed, it runs generally with the privileges on the current user. So if you are the user named "Guest" and you run a firefox exe,
in the task manager, under the process list you can see the username as "Guest" for the firefox exe. Now if no user is logged on, and a process is executed, then what will happen?
Our best guess is that it would run with system privilege. So if you can find a file that runs/can be made to run before a user logs in, then it should do our dirty job.
Sometimes it happens that certain softwares like to run their files before a user logs on. If somehow we could replace such files with our shell or any bat file, our dirty job
could be done again :). But its not that easy. The shell is not necessarily executed as expected. Nevertheless, its a possibility. If you like to experiment you can try to find any such files. I ll let you know later,
how to get a sample list of such files.

The Sticky keys Hack

There is something called Sticky keys in Windows XP. If you press SHIFT key >=5 times, a window should pop up,

if it doesnt, you can enable its shortcut through Control panel->Accessbility Options-> KeyBoard Tab, in the Sticky Keys group, click on Settings, under Keyboard shortcuts,
check the setting for "Use shortcut". Good news is that you can enable it from a Guest account as well:

Now if you press SHIFT >=5 times, the file responsible for firing this window is under system32 with the name sethc.exe

You got it, take the backup of this sethc.exe and rename it to say sethc_original.exe. Now copy cmd.exe from system32 to somewhere and rename it as sethc.exe.
Copy the new sethc.exe (which is in fact cmd.exe, our shell) in system32, and press yes, when it asks for the confirmation to overwrite.

You can test by pressing SHIFT >=5 times, and you will see a command window being opened. Its not of much use since the privilege of this shell is the Guest or the
no-admin only.
(We cannot use the following commands from the Guest account,unless we have the admin/system privilege, if you try to do that, you will see an error of type:)

To escalate the privilege, restart you windows, but do not login to any account. And when you are at the logon screen,
press the SHIFT key>=5 times and boom, there you got you shell with SYSTEM privileges.

Now you can add a new administrator account "hacked" with a password "hax0rpassw0rd" using the commands:

net user hacked "hax0rpassw0rd" /add
net localgroup administrators hacked /add

And now you can logon to your new admin account now.
You can also reset the administrator password, using the shell, but I wont recommend that for obvious reasons. Our job should be to stay as stealthy as possible.
Just install your software and clear your tracks. Wwith this SYSTEM privilege shell you can also see the files that execute before a user logs in.
Use the command tasklist for that and save the output in some file, for later viewing.

How to stay stealthy.
Your new account can be easily seen in the Control Panel-> User accounts and in the My Computer in the form of documents as well. This isnt a good sign.

But we can hide our account to a certain extent.

Beware of the Registry, Dont mess around!
Open the registry by regedit, and navigate to the Folder:
HKEY_LOGON_MACHINE->Software->Microsoft->Windows NT->Current Version->WinLogon->SpecialAccounts->UserList

Create a new DWORD value here, set the name as your newly added username, "hacked" in our example, and let the value be zero.

This will stop the display of your user account in Control Panel->User accounts and in the My Computer documents.
However for the expert eyes, your user directories can still be seen in "Documents and Settings" and through the command net user.
So you may need to do some additional tasks, like removing your backdoor account entirely before leaving.

Tuesday, April 6, 2010

Crontab error "/bin/sh: root: command not found"

Crontab error "/bin/sh: root: command not found"

Today I struggled with making the crontab work on my system. I am using cron jobs for the first time.
Although I always wanted to understand how it works, esp as I heard that they are good for periodic backups.
But it was quite frustrating for me to make it work, especially if you prefer to google without reading the man pages
thorougly. Let me just explain what I was trying to achieve and how the error got resolved. Now I realize I
could have saved a lot of time, had I read the man pages :(

But sometimes we are in a hurry and we are not at all interested in understanding how things work, but in
making it work as quickly as possible.

For those who want a quick look at resolution of this error I would say,
check your cron syntax:

1. If you are making changes in a local cron file using crontab -e, the job entry should contain 6 fields (not the username)
like this:

* * * * * /home/build_auto/echo.sh

A wrong entry like this:
* * * * * root /home/build_auto/echo.sh

would cause cron to interpret "root" as a command.

THe syntax "* * * * * root /home/build_auto/echo.sh" is valid for system crontab file /etc/crontab.

Most of the syntax related examples can be found by reading the man page for crontab files:

man 5 crontab

Creating a simple cron job to run a shell script
I am simply trying to create a cron job and which would execute a shell script for me at regular intervals.
So first I read through a simple tutorial from where I learn about the basic syntax and the fields.

Now for my simple cron job, I create a simple shell script which will output some data in another text file.
And for simplicity I would like to run it every minute. (so that I can quickly confirm how it works)

So here is my simple shell script which will append a string ("test") to another text file (test.txt)


echo "test" >> /home/build_auto/test.txt

This way everytime the script echo.sh is executed, it will append a string "test" in a new line in test.txt.
So when our cron job executes perfectly i.e. every minute, we see "test" in every new line.

Say I save my echo.sh in a location : /home/build_auto/

Now you can add a cron job at two places:

1. In the system cron file /etc/crontab
2. And in a new crontab file using the crontab command.

This file is will be stored in /var/spool/cron with the same name as the username.

Editing the System cron file /etc/crontab

This way is not advisable as you would be directly interfering with the system cron file which is required by cron daemon.
Still if you would like to add an entry, open /etc/crontab in an editor and add an entry like this:

* * * * * root /home/build_auto/echo.sh

THere are seven fields seperated by spaces. For details on the fields read the man page.
The first field is for minute, second for hour, third for day of month, month, day of week, user account which will be used for execution and command name which is the full path of our shell script.

The *s indicate the job will be executed every minute, every hour and so on. Save the /etc/crontab and your job should execute every minute. There
is no need to do any service restart.

Editing the user level crontab file using the crontab command

The other way is to create a new crontab file using the option -e (edit) with crontab, which is mostly meant for non-root users.
This file will have the same name as the username and can be found at the location: /var/spool/cron

The crontab syntax is similar to the previous one, except that instead of 7 fields, there are only 6. The username is not required.

Create a new crontab file using the command:

crontab -u root -e

or simply

crontab -e

and add an entry like this:

* * * * * /home/build_auto/echo.sh

Remember, no username here, the crontab command has already taken care of it through the -u option. (or through the current user if -u is omitted)
Save the file and now your cron script should be executed every minute.
Confirm your entry by listing down the crontab list for user root:

99EP68903:/home/build_auto # crontab -u root -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.XXXXosSNdV installed on Mon Apr 5 22:03:11 2010)
# (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
* * * * * /home/build_auto/echo.sh

You can also see the same in the file /var/spool/cron/tabs/root.

Making mistakes

In case, as a noob you create an entry "* * * * * root /home/build_auto/echo.sh" using the crontab -e command, you will get mail error messages like this one:

From root@linux.local Mon Apr 5 22:01:01 2010
X-Original-To: root
Delivered-To: root@linux.local
Received: by linux.local (Postfix, from userid 0)
id CC5ED320408; Mon, 5 Apr 2010 22:01:01 +0530 (IST)
From: root@linux.local
To: root@linux.local
Subject: Cron root /home/build_auto/echo.sh
X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>
Message-Id: <20100405163101.cc5ed320408@linux.local>
Date: Mon, 5 Apr 2010 22:01:01 +0530 (IST)
Status: R

/bin/sh: root: command not found

This can be misleading, and it can be easily misunderstood as if the cron is unable to locate /bin/sh. But in fact cron is trying to execute a command with the name "root", which does not exist.

This is because cron expects a command in the sixth field.

After a few minutes, upon successful executions of the cronjob the test.txt should look like:

99EP68903:/home/build_auto # cat test.txt

And one more thing, ensure that in your shell script the PATH of all files resolves to absolute path, any relative path like ./test.txt would
resolve through the home directory of the user that is executing the cron job.

#end of post