Solved

root login vulnerability

Posted on 2014-03-03
18
480 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
  • 11
  • 6
18 Comments
 
LVL 14

Assisted Solution

by:sentner
sentner earned 250 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 250 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
3 Use Cases for Connected Systems

Our Dev teams are like yours. They’re continually cranking out code for new features/bugs fixes, testing, deploying, testing some more, responding to production monitoring events and more. It’s complex. So, we thought you’d like to see what’s working for us.

 
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

PRTG Network Monitor: Intuitive Network Monitoring

Network Monitoring is essential to ensure that computer systems and network devices are running. Use PRTG to monitor LANs, servers, websites, applications and devices, bandwidth, virtual environments, remote systems, IoT, and many more. PRTG is easy to set up & use.

Question has a verified solution.

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

I have been running these systems for a few years now and I am just very happy with them.   I just wanted to share the manual that I have created for upgrades and other things.  Oooh yes! FreeBSD makes me happy (as a server), no maintenance and I al…
I promised to write further about my project, and here I am.  First, I needed to setup the Primary Server.  You can read how in this article: Setup FreeBSD Server with full HDD encryption (http://www.experts-exchange.com/OS/Unix/BSD/FreeBSD/A_3660-S…
Learn several ways to interact with files and get file information from the bash shell. ls lists the contents of a directory: Using the -a flag displays hidden files: Using the -l flag formats the output in a long list: The file command gives us mor…
Learn how to find files with the shell using the find and locate commands. Use locate to find a needle in a haystack.: With locate, check if the file still exists.: Use find to get the actual location of the file.:

831 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