How to get the password file?

[Sean OB_1]

Howdy.

I have a person who claims to have gotten a copy of the password file from one of our servers. He was on out internal network at the time, but as far as I know did not have access to the server via an account (telnet, ssh, etc.)

Does anyone know of a list of exploits that would be able to be used to get a copy of the password file?

I need to figure out if this was done, and if so, how it was done.

Thanks!

Sean

[Pete Randall]

Sean,

Doesn't your company have a computer access policy or a security policy (there's so many different possible name for such things)? If there's any sort of policy at all, you should be able to rub his nose in it and tell him that unless he explains just how he got ahold of the passwd file he's going to be looking for new employment.


Pete

[John Poff]

Hi Sean,

It's not too hard if you can hack into the machine, since the /etc/passwd file has to be world readable. The trick is if you are using shadow passwords or not. If so, the culprit has a list of valid user accounts but no passwords. If not, they can run a password cracking program and start figuring out passwords.

The exploits are numerous. FTP, sendmail, telnet packet sniffing, etc. Depending on the exploit used it may be tough to backtrack and figure out just how and when this person got your password file.

JP

[doug mielke]

It looks like anyone with a user account can read /etc/passwd. However, the passwords are encripted, so, while it's not good to have lists of your users floating around, at least there is no password knowledge.

[Jerome Henry]

No access, no passwd...

If he had something, then he accessed somehow. Does he have the file, or the passwords ? Good thing would be to have him show sth, not believing too much about what he claims.

If it appears that he does have sth, then let's think about how he did... But start by calling him script kiddy and liar...

J

[Todd McDaniel_1]

Do you have any kind of equivalency on the servers via .rhosts? He could have used remsh...

#remsh hostname cat /etc/passwd > file.out

IS it possible that he could have su'ed to an application name on his host that also exists on the other server? Then executed an r* command like rcp or remsh? If you do I might suggest using the nologin shell which forces users to login as their userid and then su over to an application account for work purposes... I use it on my boxes for non-SecurID accounts.

What services are you running that you may not need? We shutdown any unneeded services as I am sure you do as well.

What about ftp, do you have anonymous ftp allowed?

I might use something similar to what I have in my /etc/hosts.allow & deny files. to
lockout some unauth use...

Deny all in deny file and allow only those protocols you wish to have run on your host from a remote system.

Sorry if this is redundant/trivial info for you...but could be helpful for you.

# cat /etc/hosts.deny
# Deny all hosts
ALL : ALL


# cat /etc/hosts.allow
#all : all : banners=/usr/localcw/opt/sysguard/banners : allow
ftpd : all : banners=/usr/localcw/opt/sysguard/banners : allow
telnetd : all : banners=/usr/localcw/opt/sysguard/banners : allow
tftpd : all : banners=/usr/localcw/opt/sysguard/banners : allow
logind : all : banners=/usr/localcw/opt/sysguard/banners : allow
rlogind : all : banners=/usr/localcw/opt/sysguard/banners : allow
remshd: all : banners=/usr/localcw/opt/sysguard/banners : allow
sidftpd : all : banners=/usr/localcw/opt/sysguard/banners : allow
rexecd : all : banners=/usr/localcw/opt/sysguard/banners : allow
sshd : all : banners=/usr/localcw/opt/sysguard/banners : allow

[Sean OB_1]

Sorry, should have given more information.

This person works for a security company and was invited in (not by IT, and with no knowledge of IT) to give a seminar on information security.

From what I know he had no login to any machine on our network.

From what I've been told he was able, via his PC to display the passwd file on one of our servers. I have no proof of this, and was only told via third person.

The server does not have anonymous FTP enable, but does have telnet, remsh, rlogin, rexec, rcp, smtp, and a few other services turned on. Don't ask why, I've been fighting the battle to shutdown those services for a year, an so far only have a bruised forehead from banging it against the desk.

So assuming that the person did not have a login to the machine, nor to any machine that would have rhost access to the machine, does anyone have any thoughts on what other exploits he could have used to view the password file?

BTW, he says he'll tell us if we hire his company. I told my boss to call legal and have them go after him for illegal access to company property since he was not authorized to access any of our machines. Personally I'd like to meet him so I can smack him up side the head. :-) But on a good note, it may be a wake up call to the powers that be that we need to lock down the machines tighter.

Thanks again.

[Todd McDaniel_1]

Sean, no points here...

My suggestion is to give this guy the old heave ho... let the door hit him where the good Lord split him...

You dont want this kind of unprofessionalism and/or arrogance associated with your company.

Extorting service from you for information just doesnt fly with me.

Like city buses, another vendor, plying his trade, will come along in the next 10 minutes.

Im not usually one for prosecuting folks, but in my company's line of work. That would be a major violation of our company policies for a vendor who had access to our network. who used it in such a manner.

If I were you, I would advise him to turn over any company property, and then you might consider not prosecuting him.

[Sean OB_1]

I agree 100% with you Todd.

Unfortunately I don't even know who it is. This was something setup by someone else, at another site in the company.

My boss is trying to do exactly what you said, track him down and tell him to hand over the goods or face legal issues.

In the meantime I've been asked to figure out how he could have done it.

[Todd McDaniel_1]

First place I'm sure you looked was the syslog... turn on all logging with inetd -l. I think it is, if you don't already...

he couldnt have covered his tracks since he cant login.

Look for any services executed remotely... and find out what IP range he was logged in on the network from.

It very easily could have been done via sendmail since that port is always listening.... id check mail.log as well. Check for any connections that are during the period he was there.

[John Dvorchak]

I have a suggestion that I got from a hack site maybe this is some help to you:

On
some systems there is a file called PHF in the /cgi-bin directory. If there
is then you are in luck. PHF allows users to gain remote access to files
(including the /etc/passwd file) over the world wide web. To try this method
goto your web browser and type in this URL:
http://xxx.xxx.xxx/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd
Then substitute the site you are trying to hack for the xxx.xxx.xxx.


The site url is:

http://www.totse.com/en/hack/hack_attack/bghkunix.html

I just did a simple Google search. You have to believe that Hackers love to brag, maybe you can find out more by searching the web.

[Steven E. Protter]

It is unethical to test security without the knowledge of the sysadmin.

There that being said, there should be a record of the actvitity.

I would gather up all of the .sh_history files and syslog.log files and conduct an analsysis. Anything that involves /etc/passwd

I would most definitely make the system trusted. That would make the passwd file useless.

The file itself is as noted world readable. Anybody cat cat /etc/passwd to a local file and then copy it on out.

Obvioiusly someone gave them a logon to the network and thats how they got the file. Thats cause for termination in or organization.

There is a book called halting the hacker that tells how sytems are epxloited. Its a good read. HP's Network Security course will help as well.

A common exploit is to break out of a startup script with ctrl-c. That gets you a prompt and all the access you need to grab the file.

Any service in inetd.conf is vulnerable to exploit, but I doubt thats how it was done.

Go through the logs and see if you can figure out how it was done. It was probably right out in the open.

SEP

[Pete Randall]

Sean,

You say he was on your internal network at the time. Does this mean he was on-site? Is there any chance he used a previously logged-on machine while someone was at break or something?

I agree that this amounts to out and out extortion and would take great pleasure in explaining that to him as I was throwing him out the door.


Pete

[John Poff]

Sean,

We've had a couple of security audits done here and the very first thing they do is get the powers that be to sign a document authorizing them to snoop around and poke for security holes. If your man has a similar signed agreement your legal stance may be limited, otherwise I would call the lawyers and circle the wagons. The events of the last couple of years have prodded our legislators to strengthen the laws against such nonsense, so this guy may be in more trouble than he realizes.

For him to refuse to explain how he acquired the information without hiring his firm seems unethical and arrogant.

Good luck, and please keep us posted. I'd like to hear what develops.

JP

[Bill Hassell]

Tell your direct manager that you are going to the president of your company and inviting coporate legal to discuss this matter. The consultant may have only pilfered one password file or may have pilfered dozens along with exploiting many other security weaknesses. This is totally unethical and your legal department may need to take immediate action to determine what else has been compromised. Of course, you need to also explain that the action taken by another employee to bring in a security consultant without IT management approval may be a violation of company policy. If it isn't, it should be. Your server may have had a root kit installed, your firewalls may have a security tunnel installed, your DNS servers may have been compromised, and the list goes on. All of this could be automated on a laptop and performed during the lecture in the background.

[Zigor Buruaga]

Hi,

Not sure of this because I've never tried it, but maybe that person was using some sort of sniffer to listen on your network. Perhaps he was waiting until some of your users log in into your machine and he could view some user and passwd in plain text.
Only an idea.

Kind regards,
Zigor

[Bonny Jose_2]

Hello there,
those rwho and finger commads can give passwd entries of remote machine if they are running respective daemons. Stop those services if you dont require them
Regards
Bonny

[Brian Markus]

I recommend downloading a copy of NESSUS, then running a scan on your system for general exploits.

http://www.nessus.org/

Harden your machine! You can download a copy of the Bastille project for HP-UX that will do a pretty good job of locking your system down. Shut down all unnecessary services. Use SSH instead of telnet. Get tripwire or an equiv installed.

http://www.bastille-linux.org/

Check www.securityfocus.com They have a lot of good articles on locking machines down, as well as exploit databases, and mailing lists you can get on that will keep you up to date.

You can get this guy canned, or put the fear of god in him if you so desire.

Good luck.

-Brian.

[Hemanth Gurunath Basrur]

Hello Sean,

Refer to the foll. links on how one can access the password file.

http://www.iwar.org.uk/hackers/resources/digital%20rebels/cupw.htm

http://www.iwar.org.uk/hackers/resources/digital%20rebels/bunix.htm

http://www.securiteam.com/securityreviews/5QP032A4UU.html

http://groovyweb.20m.com/gif/docs/unixpasswdcrack.htm

http://www.itc.virginia.edu/desktop/security/damage.html

http://www.fau.edu/irm/css/network/hacker.html

http://h71036.www7.hp.com/hho/cache/836-0-0-225-121.aspx

I hope these links would suffice for you to prepare a strong case.

All the best!

HTH.

Regards,
Hemanth

[Christian Gebhardt]

Hi Sean

is there an Oracle database on this sever ?
You can do unbelievable things with the Oracle Listener from a remote machine,
My advice: use a password for all Oracle Listeners.

Chris