Chapter 7 - Keeping access to the machine

There are many ways to keep access to the machine, you will loose

access to many as you as you are learning, but I hope with this manual

and some experience you will become a stable hacker.

Section 7A - Tricks of the trade

Here are some 'tricks' of the trade that will help you keep access

to the machine. After a system admin has found you out, they will be watching

for you and going through everything on the system. They will go as far as

recompiling binary files, changing everyone's passwords, denying your host you

came in from to the machine, going through the passwd or shadow file, looking

for SUID files, etc....

When you see that you have been found out, do not try to get access to the

system again. I have seen others right after being cought, try everyone of

their trojans, other accounts, and other backdoor's they placed for continued

access. Well think about it, they are watching for you ... you are showing

them every in that you have to the system, and every exploitable file you

are making known to them.

NO! WAIT! Give it a few months, they will think everything is ok, and they

will relax and you can come in with one of the backdoor's they missed, and you

can do your thing on the logs for all of the attempts you made on the system

to get back in.

Ok here are some tricks of the trade.

History Files:

--------------

Always put your .bash_history to /dev/null, if you don't make sure you at least

edit it. Remember the .bash_history will always have your last commands until

the logoff. So if you edit it, it will show that you are editing it. You might

try changing your shell and editing it there, but this all seems like a pain,

just set it to /dev/null

1. Delete the file in the user directory .bash_history if it there.

2. Type this command in the home directory: ln -s /dev/null .bash_history

Nested directory:

-----------------

Always find a directory on the system to hide your files. There are a few good

ones that most users never look into.

In the users home directory look for .term, all you will find in this directory

is an executable file called termrc. Admin's and users alike are used to seeing this

hidden directory, and never EVER go into it. if they did what do you think

they would say to an executable file being in there called termrc? You are right!

Nothing .... it belongs there and it is what they expect to see there.

So lets say we make termrc a little bigger, and add suid perm's ... are you

getting the idea???? I hope you guessed it... go to the /bin directory and

type cp bash (or sh whatever is there) ~username/.term/termrc

then type : chown root ~username/.term/termrc

: chgrp root ~username/.term/termrc

: chmod +s ~username/.term/termrc

Now you have a nested file that can get you root on the system any time that

will not be easy for the admin to find. If you want to get fancy, touch

the file date to make it look like an older file.

Another directory off the user accounts expected to be there and unused would

be .elm, .term or Mail, or try making a directory called '...' this is harder

to notice seeing the first directories that show are . and .., so it can go

un-noticed easy. This is how it would look if they did a long ls:

1024 Jan 29 21:03 .

1024 Dec 28 00:12 ..

1024 Jan 29 21:03 ...

509 Mar 02 1996 .bash_history

22 Feb 20 1996 .forward

164 May 18 1996 .kermrc

34 Jun 06 1993 .less

114 Nov 23 1993 .lessrc

1024 May 18 1996 .term

1024 May 19 1996 public_html

see how it seems to just fit into place?

but if it was just a ls -l, this is what would be seen:

1024 May 19 1996 public_html

Remember you can always look for some REAL LONG file path that you are sure

that no one would ever even want to enter into, and use this for your nested

directory. You can even make your own directory there like:(...) ;)

 

Making new commands

--------------------

After you check the cron to see if there is md5 being used there, you might

want to either copy one of your exploits to another filename in the system,

or maybe just overwrite a command that you know would never be used. If

you copy to a new file name make sure you touch the file date. This is not

so long lasting because sooner or later they will patch the exploit and your

new file you made will not work anymore.

It is better to use a shell for the new filename, and then make it suid.

Adding or changing passwd entry's

---------------------------------

Another backdoor that you can use is to add a new user to the passwd file.

This needs to be done with caution making it look like it belongs there.

Never use your passwd addition, never login, it is just for a backup in case

you loose access.

There are different thoughts here: you do not have to make it a root account

that could cause notice to it right away. You know you can have root any time

you want it. Lets practice ...

We want to make our account look like it belongs, so lets keep to the top of

the file.

root:fVi3YqWnkd4rY:0:0:root:/root:/bin/bash

sysop:mZjb4XjnJT1Ys:582:200:System Operator:/home/sysop:/bin/bash

bin:*:1:1:bin:/bin:

daemon:*:2:2:daemon:/sbin:

adm:*:3:4:adm:/var/adm:

lp:*:4:7:lp:/var/spool/lpd:

sync:*:5:0:sync:/sbin:/bin/sync

shutdown:*:6:0:shutdown:/sbin:/sbin/shutdown

halt:*:7:0:halt:/sbin:/sbin/halt

mail:*:8:12:mail:/var/spool/mail:

news:*:9:13:news:/usr/lib/news:

uucp:*:10:14:uucp:/var/spool/uucppublic:

operator:*:11:0:operator:/root:/bin/bash

games:*:12:100:games:/usr/games:

man:*:13:15:man:/usr/man:

postmaster:*:14:12:postmaster:/var/spool/mail:/bin/bash

nobody:*:65535:100:nobody:/dev/null:

ftp:*:404:1::/home/ftp:/bin/bash

Looking at the above passwd file leaves us a few options so i will just list

them here.

1. Look at the user line for operator, ftp, and postmaster. All of these

accounts have shells with no passwd's set yet. From your shell just type:

passwd postmaster

Set the account with no passwd by just pressing enter. Now you will be able

to log into this account any time without a password and the file will still

look right to the admin.

2. add this line to the passwd file:

syst::13:12:system:/var/spool:/bin/bash

Place it in the file where it seems to flow. You can leave the :: for the

passwd or set the passwd to what you want by typing: passwd syst from the

root shell. Set the group and id above to what you like.

 

3. Look at the line above for sync

sync:*:5:0:sync:/sbin:/bin/sync

Change this to :

sync:*:5:0:sync:/sbin:/bin/bash and then run <passwd sync> and leave the passwd

blank. (or set a passwd don't matter) On this account we are even gid=0 <G>rin

Installing games

----------------

You could always install exploitable doom or abuse into the system if they

already have games installed. I will include the root exploits for these

games below in the appendix.

Always be watching

------------------

Always know who the admin's are on a system, you can find them by looking at

the passwd file to see home directories, placement of the uid, group access

accounts, and ALWAYS read all of the bash_history files in the user directories

to see who is using admin commands. You will also learn allot of new commands

from reading history files, but you want to know who is who on the system.

Get to know your system well. Look for users using su: View the log files

to see who is using admin commands.

Always be watching the system, keep track of who is on while you are. Watch

the admin's history to see what commands they are using, ttysnoops? too many

ps commands? finger commands after ps or w or who commands will show they

are watching what other users on the system are doing. Watch your admin's

and get to know how aware they are of users on their system.

Reading system mail

Rember first NEVER to use system mail programs! They will be able to tell you

are reading their mail. I use a combo of a few things. Here you go...

1. cd /var/spool/mail

This will put you into the directory that holds all of the unread mail, or

waiting mail. Now you can do things like:

grep -i security * |more

grep -i hack * |more

grep -i intruder * |more

grep -i passwd * |more

grep -i password * |more

Then if needed pico username, and ctrl w to search for your maeesge. You

can also delete messages if you see some other admin is telling them that

your user name is hacking their machine from their domain.

For a mail reader that will allow toy to read mail without updating pointers

try:

http://obsidian.cse.fau.edu/~fc

has a util on it that can cat /var/spool/mail files without changing the

last read dates.. ie they have no idea that you have read their mail.

Also remember you can find other system mail in user's directories. Make sure

to look in the /root directory. Look for /root/mail or username/mail or other

directories or filders that contain older mail.

Happy Hunting ...

Section 7B - Root and Demon kits and trojans

Root kits are C source for ps, login, netstat and sometimes some other

programs that have been hacked for you. With these kits you will be

able to replace the login files on the hacked box so that you can login

without an account on the machine.

You will also be able to patch ps so that you will not show up when an

admin uses the ps command. With the ps patch you can also have it not show

processes that have certain file names such as any file that starts with

'sniff'.

Demon kits will have hacked programs for identd, login demon, ping, su,

telnetd, and, socket.

Trojans will be any file that you can use that will allow you to exploit

the system in some way. An su trojan placed in the admin's directory would

run the trojan su first after you change the export path for him ;) and report

back that he typed the wrong passwd and delete the trojan file, but saving

the password he typed to the /tmp directory.

A login trojan would save all login passwords to a file on the machine

for you. I think you get the idea ;)

Demon and Linux root kits have been uuencoded and attached to the end of

appendix VI

WB01345_.gif (616 bytes)Next Page