?
Solved

root login vulnerability

Posted on 2014-03-03
18
Medium Priority
?
499 Views
Last Modified: 2014-03-04
can anyone give a management freindly low tech breakdown of the risks to an aix server if the lsuser -a rlogin setting is set to true? Whats the risk here? And does setting the policy to false cause any issues for admins/support engineers?
0
Comment
Question by:pma111
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 11
  • 6
18 Comments
 
LVL 14

Assisted Solution

by:sentner
sentner earned 1000 total points
ID: 39901223
If an internal user gets the root password, and can directly log into the box as root via telnet or rlogin, there is no direct way to trace who it was that then logged in, plus you have one less password that the attacker needs to know.  

Having the admins log in as a regular user first, and then su to root is safer since you can have better tracking of who it was that logged in, plus they now need 2 passwords.
0
 
LVL 3

Author Comment

by:pma111
ID: 39901232
so if the root password is highly complex, does that mitigate the risk as such, as they'd need to compromise / guess the password first?
0
 
LVL 68

Accepted Solution

by:
woolmilkporc earned 1000 total points
ID: 39901282
Hi,

the "rlogin" attribute, if set to "true", allows access to the respective machine using "telnet" or one of the "r" commands (rlogin, rsh, rexec, rcp ...) for a user. At least under AIX this attribute also governs the ability to access the machine with ssh. In other words: Setting "rlogin" to "false" disallows access via ssh for the concerned user.


It's common to the "telnet" and "r" protocols that they do not have the ability to encrypt their data.
Sniffer programs can easily detect and collect passwords transmitted in plain-text from any of the programs in question.

Some versions of telnet have the ability to execute non-interactive commands. If a .telnetrc file exists on the target machine any telnet command in that file will be executed as if it were typed in at the prompt. Fortunately, telnet as implemented in AIX does not have this capability.

The "r" programs allow passwordless access for a user if this user has a .rhosts file containing the appropriate host/user entry or if there is an /etc/hosts.equiv file. This latter file is not taken into account for "root", however.
Hosts and users appearing in either of those files are considered "trusted"!
So it's no wonder that those files are the favored target of cracker attacks - to get a picture of the trusted hosts/users topology and then try to hijack these hosts and users.

And, even worse, if an admin placed a single "+" sign into one of the above files (perhaps out of a certain lazyness) then any user from any host can access without password.

So disallowing remote access is basically not a bad idea, but "rlogin=false", as mentioned above, disallows "ssh" access as well.

Better set "rcmds=deny" which disallows the access via "r" commands, and disable telnet system-wide separately in /etc/inetd.conf.
Of course you can also disable all "r" command access in /etc/inetd.conf.
0
Technology Partners: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
LVL 3

Author Comment

by:pma111
ID: 39901292
>>The "r" programs allow passwordless access for a user if this user has a .rhosts file containing the appropriate host/user entry or if there is an /etc/hosts.equiv file. This latter file is not taken into account for "root", however.


Yikes! How can you check, which users have a .rhosts file, or if there is an /etc/hosts.equiv file.

Are you saying if "root" has a rhosts file, then a hacker could access the server without the need to enter a password?

can you disable these r programs? and how could you check if they are active/running or disabled?
0
 
LVL 3

Author Comment

by:pma111
ID: 39901303
and can you check ""rcmds=deny" to see if its currently set to deny or (I presume) permit?
0
 
LVL 68

Expert Comment

by:woolmilkporc
ID: 39901401
If root has a .rhosts file containing "remotehost root" then the "root" user at "remotehost" cann access the machine without having to enter a password.
"remotehost username" allows "username" passwordless root access from "remotehost".
If the entry reads "remotehost +" then any user from "remotehost" can login as root without password.
If there is "+ +" then any user from any machine has passwordless root access.

How to check if userA has a .rhosts file?

ls -la ~userA/.rhosts

How to check if there is an /etc/hosts.equiv file?

ls -l /etc/hosts.equiv

Disable "r" programs system-wide by commenting out "shell", "login" and "exec" in /etc/inetd.conf. Issue "refresh -s inetd" afterwards!

Check with

lssrc -ls inetd

Disable the use of "r" commands per user with

chuser rcmds=deny username

and check with

lsuser -a rcmds username
0
 
LVL 3

Author Comment

by:pma111
ID: 39901405
awesome, thanks. is there a single command to see which accounts have rlogin access? for example in the above I had to specify a username, I didnt know if you could do a rlogin type report for all your users, as I assume the same principles apply for any account?
0
 
LVL 3

Author Comment

by:pma111
ID: 39901412
i.e. I'd like to do all the above commands for all users, in one swoop, or if thats not possible, I can do them manaully, just trying to learn the command syntax for next time..

it would also be useful to see a command to copy the actual contents of the rhosts file to see what its configured as.. (or will the above command show the information, or just whether such a file exists?)
0
 
LVL 68

Expert Comment

by:woolmilkporc
ID: 39901468
There can be only one /etc/hosts.equiv file, so a single "ls -la  /etc/hosts.equiv" command is sufficient to show the file's existence, and a subsequent "cat  /etc/hosts.equiv" command will show its content.

Check all known users for .rhosts:

for user in $(lsuser -a ALL); do echo "--- $user ---"; ls -la ~$user/.rhosts; done 2>/dev/null

Display the contents:

for user in $(lsuser -a ALL); do echo "--- $user ---"; cat ~$user/.rhosts; done 2>/dev/null

If you see just the "--- username ---" line and nothing else then there is no .rhosts file.

Check all users' "rcmds" setting:

lsuser -a rcmds ALL

If you see just the username and nothing else then this means that rcmds is not set and thus enabled by default!
0
 
LVL 3

Author Comment

by:pma111
ID: 39903036
Could you offer any feedback on the following data in relation to the above, thought it may make some sense with the actual data:

Command:  for user in $(lsuser -a ALL); do echo "--- $user ---"; ls -la ~$user/.rhosts; done 2>/dev/null 
--- root ---
-rw-r--r--    1 root     system           95 dateremoved  //.rhosts
--- nobody ---
-rw-r--r--    1 root     system           95 dateremoved //.rhosts
--- lpd ---
-rw-r--r--    1 root     system           95 dateremoved  //.rhosts

Command: for user in $(lsuser -a ALL); do echo "--- $user ---"; cat ~$user/.rhosts; done 2>/dev/null 
--- root ---
removed root
removedservername root
removed root
removedservername root
--- nobody ---
removed root
removedservername root
removed root
removedservername root

command: lsuser -a rcmds ALL 
(just returns a list of usernames, one with=deny)

Command: ls -l /etc/hosts.equiv 
-rw-r--r--    1 root     system         2049 removeddate  /etc/hosts.equiv

Open in new window

0
 
LVL 68

Expert Comment

by:woolmilkporc
ID: 39903077
So root, nobody and lpd do have a .rhosts file each.
But what's this "removed[servername] root" entry in there? Did you obfuscate the hostname by changing it to "removed[servername]", or is there actually the string "removed[servername]"?

I think you obfuscated the entries, and if so, root as well as "nobody" define four servers along with the root user on those servers as "trusted". This means that the "root" users on the servers "removed[servername]" can access your machine without password on behalf of "root" itself and on behalf of "nobody" and "lpd" from the remote hosts configured in the .rhosts files.

All your users except for the one with "rcmds=deny" (I assume it's "pconsole") are allowed to run "r" commands against your machine. This does not mean that they can do this without password, unless they and the respective remote hosts appear in one of the .rhosts files, which is not the case, except for "root". Only root can actually run "r" commands without password on behalf of "root" itself, "lpd" and "nobody" from the configured remote hosts.

Finally, there is an /etc/hosts.equiv" file, obviously. I can't tell you more, because I don't know the content of that file.
0
 
LVL 3

Author Comment

by:pma111
ID: 39903096
Ok thanks, yes removed the servernames. Is there a specific format to the rhosts files, because some seem to be in format:

i.e.

--root--

name (could be a username or servername)

whereas others seem to be in format:

servername username

If the first format is representing a servername, and subsequently does that mean any user with an account on that server can access our server without a password?

And where the format is servername username, I presume that means on that host that only that user account can remotely access our server using that account on that host.


if the entry for the rhosts file was just

--- root ---
server

does that then mean any user with an account on that server can access the root account on our server remotely?
0
 
LVL 3

Author Comment

by:pma111
ID: 39903100
Possibly they are aliases and not servernames..
0
 
LVL 3

Author Comment

by:pma111
ID: 39903109
Here is the output of hosts.equiv

-rw-r--r--    1 root     system         2067 02 Jun 2011/etc/hosts.equiv

Open in new window

0
 
LVL 68

Expert Comment

by:woolmilkporc
ID: 39903111
The first name is the servername, the second is the username.

If there's just the servername then all users on that server are trusted.

If there is "servername username" then only "username" on "servername" is trusted.

Yes, there is an hosts.equiv file, but what's in there? Use "cat" instead of "ls -la"
0
 
LVL 3

Author Comment

by:pma111
ID: 39903124
say for example though, only "remoteserver root" can access your servers root account via this rhosts entry, whats the risk........... as root would normally only be accessible to trusted admins, who likely would have the root password anyway for that server. Is the worry if a server became compromised, then the hacker may also then have access to other servers via remote login trust relationships like rlogin? Or are there ways to spoof where and by whom the connection is actually coming from...

I have just looked at the DISA security guide for AIX 6.1, and in one control they have a CAT 2 level vulnerability if non trusted hostname pairs exist in rhosts, then in the very next control they have a CAT 1 vulnerability if any rhost files exist..
0
 
LVL 3

Author Comment

by:pma111
ID: 39903156
it would also be useful to understand why rhosts type trust relationships are needed, i.e. why would an admin set such a thing up in the first place? and is there a more secure alternative.
0
 
LVL 68

Expert Comment

by:woolmilkporc
ID: 39903730
>>whats the risk... as root would normally only be accessible to trusted admins<<

"Normally", yes. Please don't forget that we're talking about remote servers here which might not be as well-managed as yours. And maybe the people out there don't have your thorough understanding of security (root password on a post-it under the keyboard ...).

 >> if a server became compromised << yep, then your complete infrastructure of trusted hosts and trusted userids becomes compromised.

Please don't forget that communications via "r" commands or telnet are not encrypted, so a hacker equipped with a good sniffing tool can find out and pick almost everything which in fact opens a wide door for things like spoofing (man-in-the-middle attacks etc.)

And NO, an admin would NOT set up such a thing in the first place - not since we have SSH available on pretty much all platforms, i .e. since quite a long time.

SSH is undoubtedly the tool of choice when it comes to setting up secure, encrypted communication. Even if you're using keyboard-interactive authentication via password a sniffer tool will not be able to pick it - it's encrypted, after all.
And you don't even need a password - we have the trusted (public/private) key authentication method with SSH.
0

Featured Post

Free Tool: ZipGrep

ZipGrep is a utility that can list and search zip (.war, .ear, .jar, etc) archives for text patterns, without the need to extract the archive's contents.

One of a set of tools we're offering as a way to say thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Attention: This article will no longer be maintained. If you have any questions, please feel free to mail me. jgh@FreeBSD.org Please see http://www.freebsd.org/doc/en_US.ISO8859-1/articles/freebsd-update-server/ for the updated article. It is avail…
A metadevice consists of one or more devices (slices). It can be expanded by adding slices. Then, it can be grown to fill a larger space while the file system is in use. However, not all UNIX file systems (UFS) can be expanded this way. The conca…
Learn how to get help with Linux/Unix bash shell commands. Use help to read help documents for built in bash shell commands.: Use man to interface with the online reference manuals for shell commands.: Use man to search man pages for unknown command…
In a previous video, we went over how to export a DynamoDB table into Amazon S3.  In this video, we show how to load the export from S3 into a DynamoDB table.
Suggested Courses
Course of the Month9 days, 8 hours left to enroll

762 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question