Solved

root login vulnerability

Posted on 2014-03-03
18
471 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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
>>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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Enabling OSINT in Activity Based Intelligence

Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

 
LVL 3

Author Comment

by:pma111
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
Possibly they are aliases and not servernames..
0
 
LVL 3

Author Comment

by:pma111
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
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
Comment Utility
>>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

Highfive Gives IT Their Time Back

Highfive is so simple that setting up every meeting room takes just minutes and every employee will be able to start or join a call from any room with ease. Never be called into a meeting just to get it started again. This is how video conferencing should work!

Join & Write a Comment

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…
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 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…
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.:

763 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

6 Experts available now in Live!

Get 1:1 Help Now