Solved

root login vulnerability

Posted on 2014-03-03
18
477 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
 
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
Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

 
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

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

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

In tuning file systems on the Solaris Operating System, changing some parameters of a file system usually destroys the data on it. For instance, changing the cache segment block size in the volume of a T3 requires that you delete the existing volu…
Installing FreeBSD… FreeBSD is a darling of an operating system. The stability and usability make it a clear choice for servers and desktops (for the cunning). Savvy?  The Ports collection makes available every popular FOSS application and packag…
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…
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.

929 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

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now