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"

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 thoroughly. 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.sh
#!/bin/sh
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
Return-Path:
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: <HOME=/root>
X-Cron-Env:<PATH=/usr/bin:/bin>
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
test
test
test
test
test
test
test


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

Thursday, April 1, 2010

Getting root on Ubuntu Intrepid Ibex

So this turns out to be the lamest posts of all time. When I am high I just run a list of kernel exploits to gain a local root on my Ubuntu. A bit of uname here:

uname -a Linux r00t3r 2.6.27-7-generic #1 SMP Fri Oct 24 06:42:44 UTC 2008 i686 GNU/Linux

Download the exploit:

http://inj3ct0r.com/sploits/836.rar

Result is in the screensh0t:


As far as I remember it didnt work on kernel 2.6.31, Ubuntu 9.1.
#end of p0st