01-13-2013 04:08 PM
As per this HP document I've setup keystroke logging for SSH login sessions using HP-UX RBAC B.11.31.05.01 and HP-UX SSH A.05.90 on 11iv3 (1109).
However, when I checked the keystroke log files I discovered that passwords are stored in clear text!! I've raised a case with HP in relation to this but they don't consider this to be a bug report - as far as they are concerned changing this behaviour constitutes a feature enhancement!!
I don't get it - I want to implement keystroke logging to increase system security and user/admin accountability - not reduce and/or compromise it. Having passwords stored in clear text is a BIG issue particularly in relation to securing and auditing systems against insider attacks.
Seems to be the people who deisgn these security 'solutions' have no real world experience in working in a secure environment.
01-14-2013 08:03 AM
Honestly, this is the behavior I would expect from any keystroke logging facility. Getting user names and passwords has been one of the purposes behind keystroke loggers since their inception.
Auditing is a new use for them. I think the logic involved in looking at prompts and trying to figure out what may be a password prompt and what is not would be significant.
Would I expect different behavior from HP's RBAC / SSH implementation -- Possibly, but I'm can't say that I am surprised at the behavior as it is currently.
01-14-2013 07:07 PM
What are the permissions for the keystroke log? If the file is 600 owned by root, then it doesn't represent any greater risk than any of the other root-only security files. Since the file is onwed by root and unreadable by any other user, the information is safe. If an intruder gains root access, then it really doesn't matter that user passwords are readable in the keystroke file - the intruder can do anything to the system.
The usual reason for keystroke logging is to educate novice users that are making mistakes. Or when there are sysadmin problems where no one will take responsibility.
01-14-2013 10:35 PM
>it really doesn't matter that user passwords are readable in the keystroke file - the intruder can do anything to the system.
But it matters if you are going to another system. :-)
01-15-2013 04:17 PM
... it really doesn't matter that user passwords are readable in the keystroke file ...
When considering the 'threat from within' It matters for two at least reasons:
1. Attributable Actions - a rogue/malicious root user would be able to find out the passwords of other users and login as those users and make unauthorised changes and/or gain unauthorised access to information - these actions would be attributed to the user(s) whose login(s) had been compromised; and
2. Backups - managing system backups/Ignite images that include keystroke logs containing clear text passwords would become an issue. The workaround for this would be to exclude the contents of the directory in which the keystroke logs are stored from being backed up in addition to implementing log-shipping.
01-16-2013 06:08 AM
> 1. Attributable Actions
Unless the keystroke logs are immediately transmitted to some other location that is inaccessible to the rogue/malicious root, the logs can be forged. Since root can do everything, s/he can see the logs on the local system, do whatever s/he wants, edit the logs to show whatever s/he wants, change the timestamps on the logs to whatever s/he wants, and otherwise manipulate *everything* that is stored locally.
> 2. Backups
Your backups are already sensitive - they contain the password hashes of all local users, *and* the sensitive data on the system that you're trying to protect. If a malicious person can get your Ignite image, s/he can start cracking your password hashes while you're completely unaware of it. If you're not treating your Ignite images and other system backups as sensitive, you're not doing a very good job.
And at last, my counterargument: any mechanism that would allow keystroke logging to avoid storing passwords has a potential of being seen by the intruder as "a mechanism I can abuse to turn keystroke logging off for my session."
01-16-2013 01:07 PM
>> Attributable Actions - a rogue/malicious root user...
If you have a rogue / malicious root user, you're already screwed. The keystroke logs would be irrelevant as root could change any users password, or grab the encrypted passwords to attempt to crack them, or do anything else they please on the system.
01-31-2013 09:29 PM
1. Attributable Actions
If the environment is properly secured against insider and external threats (eg, Bastille, HIDS, TripWire, log shipping, no removable media at desktop, no external network connectivity, physical security and real-time access monitoring for data centre, etc) it would be very difficult for a malicious root user to modify logs and/or hack passwords. However, storing passwords in clear text negates the need for a malicious root user to resort to such risky activities.
Our backups are stored appropriately - the problem is that it is illegal for us to store passwords in clear text on any of our servers and if we did implement keystroke logging in its current form we would end up with contaminated backups.
The intent of my original message was to warn others of this issue - I've since found others with keystroke logging that render it unusable in its current form (eg, when stdin is logged and a text file is copied from one server to another server the *contents* of the file being copied are written to the keystroke log file on the receiving server as if each line had been typed at the command prompt).