[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 518
  • Last Modified:

root login vulnerability

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
pma111
Asked:
pma111
  • 11
  • 6
2 Solutions
 
sentnerCommented:
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
 
pma111Author Commented:
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
 
woolmilkporcCommented:
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
Hire Technology Freelancers with Gigs

Work with freelancers specializing in everything from database administration to programming, who have proven themselves as experts in their field. Hire the best, collaborate easily, pay securely, and get projects done right.

 
pma111Author Commented:
>>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
 
pma111Author Commented:
and can you check ""rcmds=deny" to see if its currently set to deny or (I presume) permit?
0
 
woolmilkporcCommented:
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
 
pma111Author Commented:
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
 
pma111Author Commented:
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
 
woolmilkporcCommented:
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
 
pma111Author Commented:
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
 
woolmilkporcCommented:
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
 
pma111Author Commented:
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
 
pma111Author Commented:
Possibly they are aliases and not servernames..
0
 
pma111Author Commented:
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
 
woolmilkporcCommented:
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
 
pma111Author Commented:
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
 
pma111Author Commented:
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
 
woolmilkporcCommented:
>>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

Get expert help—faster!

Need expert help—fast? Use the Help Bell for personalized assistance getting answers to your important questions.

  • 11
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now