lgi_brk_disuser and SSH not working

[Aaron Sakovich]

Hi.

OpenVMS 7.3-2, TCPIP 5.4 ECO 6.

I've got lgi_brk_disuser set to 1, and lgi_brk_term set to 0; lgi_brk_tmo is set to 5 minutes (300 seconds), and lgi_brk_lim is 5.

A user yesterday attempted to login using SSH. She tried 18 times(!), failing each time per the audit logs, for about 25 minutes. As expected, after the 5th attempt, her attempts were logged as breakin attempts by the auditing subsystem. However, she should have been disusered once this started happening. She wasn't.

She should have been prevented from logging in for 90 minutes (18 failed attempts * 5 minutes per). She wasn't.

She logged in about 25 minutes later after her SSH session (using Reflection v14 client on her end) prompted for a password change and she changed it.

(First person to say "HP recommends against setting lgi_brk_disuser to 1" gets a big fat 0 points. 8^) (BTW, HP does NOT recommend against it, they say it should be set "only under extreme security watch conditions", which I qualify for. I understand the ramifications of this setting, and I've been running this way for over 5 years WITHOUT a single problem. Discussion over.)

Why are none of these security settings working? Why was a user who flagrantly violated their password policy allowed to login?

[Ian Miller.]

was the source that the user appeared to be loggin in from the same for each login attempt?

[Aaron Sakovich]

Hi Ian,

Good question. Yes, as indicated by the audits and the fact that the intrusion was flagged as a breakin attempt. I should have also mentioned that I have lgi_brk_term set to 0.

Aaron

[EdgarZamora]

From my experience here in my site, when we get failed attempts from SSH users, the username is usually shown as TCPIP$SSH. I would say that's why the system is unable to disuser the user (because it doesn't know what username to disuser at that point).

[Aaron Sakovich]

But that wouldn't take into account the fact that this:

Security alarm (SECURITY) and security audit (SECURITY) on WOODY, system id: 7178
Auditable event: Network login failure
Event time: 22-JAN-2007 07:26:56.27
PID: 2051EC4B
Process name: TCPIP$SS_BG5780
Username: TCPIP$SSH
Remote node fullname: SSH_PASSWORD:1.2.3.4
Remote username: WEBER(LOCAL)
Status: %LOGIN-F-NOTVALID, user authorization failure


gets turned into this:

Security alarm (SECURITY) and security audit (SECURITY) on WOODY, system id: 7178
Auditable event: Network breakin detection
Event time: 22-JAN-2007 07:42:49.46
PID: 205271C4
Process name: TCPIP$SS_BG7054
Username: WEBER
Password:
Remote node fullname: SSH_PASSWORD:1.2.3.4
Remote username: WEBER(LOCAL)
Status: %LOGIN-F-NOTVALID, user authorization failure

[EdgarZamora]

Hmm... you get better info in your messages. Mine comes out like this:

%%%%%%%%%%% OPCOM 23-JAN-2007 10:35:15.20 %%%%%%%%%%%
Message from user AUDIT$SERVER on CLCC
Security alarm (SECURITY) and security audit (SECURITY) on CLCC, system id: 2131
Auditable event: Network breakin detection
Event time: 23-JAN-2007 10:35:15.20
PID: 0017EA95
Process name: TCPIP$SS_BG3042
Username: TCPIP$SSH
Remote nodename: SSH_PASSWORD:MLE
Remote username: SSH_808AF214
Status: %LOGIN-F-NOTVALID, user authorization failure

Maybe because my SSH remote sources are not VMS? Sorry I wasnt of help.

[Aaron Sakovich]

Then permit me to help you: the output I got was from the audit facility, not Operator.log, which appears to be where you got yours.

$ Analyze /audit /full /since=yesterday /before=today sys$manager:security.audit$journal /event=breakin

I've got a job that runs daily and extracts separate reports for login, logfail, breakin, sysuaf, rightsdb, file access, and much more; it prints one copy of each to a hardcopy printer for our audit logs, then a second copy to a web page for me to examine.

[John Gillings]

Aaron,

I think the clue is in the audit messages. Note that they're classified as "Network login failure" and "Network breakin detection". The help for LGI_BRK_DISUSER doesn't qualify what constitutes an attempted breakin, but I'm betting that it only applies to Interactive breakins.

For some reason SSH logins aren't treated the same as other kinds of interactive connection. You may have seen discussion about things like forced password changes, and other stuff associated with interactive logins not happening for SSH connections.

There are fairly good arguments for treating "true" network connections differently from interactive connections in terms of password handling. The trouble here is the way SSH is implemented blurs the distinction (or, is arguably just plain wrong!).

Log another case with HP Customer Support?

[Hoff]

Who knows what evil lurks within the heart of the TCP/IP Services SSH server implementation of user authentication and management? (The Shadow knows...)

But seriously, I'd encourage direct contact with the good folks at the HP support center, particularly given that this does appear to be a security-relevant problem.

Stephen Hoffman
HoffmanLabs

[Aaron Sakovich]

"The Shadow knows..."

Hoff, I thought you WERE the Shadow!?! Oh, wait, no, that's Wizard. Gotcha. 8^)

Thanks for the feedback folks -- based on this sanity check, I'm going forward with logging a call on this one. Even if it is just the subtle distinction between a network vs. interactive login, something really does appear to be wrong.

[M. T. Hollinger · Accepted solution]

Another customer (in the European financial sector) recently requested that we enhance the SSH server to honor the LGI_BRK_DISUSER parameter, and that item is now on our worklist for a future release.

It sounds like you already know what you are getting into, but for the benefit of others reading the thread who may be considering the LGI_BRK_DISUSER=1 setting, let me point out why it can be problematic.

Do not underestimate the risk of a denial-of-service attack against the system manager's account -- or even an inadvertent triggering of the DISUSER by a well-meaning employee. You may need a privileged account with a secret username, just so you can log in during an attack.

If someone is trying to break into the system, having LGI_BRK_DISUSER set makes it very easy for the attacker to disable the SYSTEM and FIELD accounts -- along with every other privileged user on the system, if he knows the username. Imagine that you are the system manager, and your pager or mobile phone goes off at 3 in the morning. You get out of bed and try to log in as SYSTEM, but you can't, because SYSTEM has been DISUSER'd. You drive to the site and sit down at the physical system console, but you still can't log in. The only way in is to force a system crash, then perform a conversational boot and "break in" from the console. Meanwhile, the attacker had access to your system the whole time it took you to drive to the site and decide to go ahead with the crash.

It could even be that there is no attack going on, just some other more-routine problem like a full system disk. It's still the middle of the night, and your onsite assistant, before calling you at home in the middle of the night, attempted to log in, had trouble remembering his password, and then tried SYSTEM, being very careful only to try that once. Oops -- now SYSTEM is disabled, and you can't log in either. Just a single failure from a login source already marked as an Intruder will trigger the DISUSER.

There are a lot of different options for how to handle intrusion records, and it has taken us many years to understand and refine them for TELNET users in order to meet various customer needs. SSH is just starting down this path, and we appreciate your feedback as well as your patience as we work to improve the TCP/IP Services product.

- Mark

[Aaron Sakovich]

"If someone is trying to break into the system, having LGI_BRK_DISUSER set makes it very easy for the attacker to disable the SYSTEM and FIELD accounts -- along with every other privileged user on the system, if he knows the username. ... The only way in is to force a system crash, then perform a conversational boot and "break in" from the console. Meanwhile, the attacker had access to your system the whole time it took you to drive to the site and decide to go ahead with the crash."

Any cracker worth his salt could do the same with a program (either on the VMS host or via any other compromised host) that every few minutes tried to log in to the same account once it's been flagged as an intruder. The only difference is in one case, it's set and forget, the other has to be refreshed every few minutes.

If it's gotten to the point where someone is trying to DoS your priv'd accounts by using this technique, you've got bigger problems than just worrying about having to reboot a system, you've got a malicious individual active on your net. If they're guessing passwords, wouldn't you want to make sure that person is absolutely prevented from getting into your system until you've had a chance to totally investigate and eradicate the pest? If they are already on your system with a compromised priv'd account, they can prevent you from getting in using methods besides just lgi_brk_disuser (e.g., in TCP/IP, reject hosts can be set for any terminal service; hack the sylogin.com; or even get into SysUAF and set the DisUser flag manually).

In the case of an operator locking out their and the System account (yes, I've had this happen, recently in fact), that makes for a good reason for having multiple admin accounts on the system with the privs necessary to rectify such a problem.

***

But, all that said, thanks for letting me know that this is a known missing feature and not a bug. I appreciate your joining the thread!

[M. T. Hollinger]

You might be surprised at the wide variety of network environments in which OpenVMS is deployed. For example, some of our customers run OpenVMS systems directly connected to the Internet, rather than on an isolated corporate network behind a firewall. For those users, having someone make 5 or 10 guesses at the SYSTEM password is a total yawn -- an everyday occurrence barely worth auditing and definitely not sufficient justification for disabling any accounts.

I don't think it would work to lock out a user by writing a script to refresh the intrusion record every few minutes. Remember, intrusion records lock out logins from a particular source. So, just because you are trying an invalid password for my SYSTEM account every 3 minutes, that won't stop *me* from logging in. It will keep you from logging in under any username from that source, even if you get the password right.

When I set LGI_BRK_DISUSER to 1, everything changes (assuming you are using a login method which honors it). Now, all you have to do to stop me from logging in as SYSTEM is try 6 bad passwords. You can then try logging in as FIELD, just once, and that one gets disabled too. If you happen to know that my privileged account for emergency use is EMERGENCY, you can try an invalid password for that one, from the same source, and then I won't be able to log in either. Try watching the alarms on OPCOM sometime as your accounts are getting DISUSER'd; it can be a little scary.

For some reason, this scenario reminds me of the scene in Star Wars where the Imperials can't get through their own blast doors to stop the rebel intruders. From a hacker's perspective, those blast doors (LGI_BRK_DISUSER) can provide good cover. From the system manager's perspective, it might be a problem if the good guys can't get through either.

Still, a central design goal for OpenVMS security mechanisms is to offer system managers a wide variety of options, with plenty of knobs and switches to customize the security level. That is why we do plan to make SSH respect the LGI_BRK_DISUSER parameter. I appreciate your comments and words of advocacy for that feature.

- Mark

[Hoff]

There are ways to avoid the DoS lock-out.

The fully-documented and entirely brute-force approach -- and the original poster may already be using it -- is to scan the intrusions, watch for SYSTEM, and to rescind the DISUSER. There are enough pieces around that warn of the lock-out.

A typical DoS against the SYSTEM username could also be avoided with some small changes to OpenVMS itself, possibly with LGI_BRK_DISUSER set to a "new" value such as bit 1 (bitmask of 2) to enable the differing behavior.

...
in the disuser-related evasion processing
...

if lgi_brk_disuser and 2 and
target_user eql system
then
set_disuser_flag = false
set_force_pwd_chg = true
endif

...
over in loginout, decwloginout, and in ACME
...

if target_user eql system and
terminal eql opa0: and
user_is_disuser_flag eql true
then
user_is_disuser_flag = false
generate_system_disuser_warn_msg = true
endif

With this sort of approach, SYSTEM could be slightly exposed, but we can only hope that the folks picking that password have done a good job choosing it.


And as needing for remote console access for late-night problems, after some small numbers of midnight pages and midnight trips into the shop, most system management folks acquire and configure some sort remote console access. Newer OpenVMS I64 Integrity boxes can have MP processors, which can provide this access without a terminal server or DECserver or such.

[Ian Miller.]

personally I often disuser the SYSTEM username as normal practice (along with the other ones that VMS ships with). At least I ensure that interactive use of SYSTEM is not allowed.

[M. T. Hollinger]

Sure, Hoff, remote console access is very convenient, and I use it too. However, some customers have security policies precluding such access. The MP console on Integrity systems, while convenient and password-protected, does not enforce password aging, dictionary, history, or strength rules, nor does it offer auditing or automatic lockdown features, as far as I know.

- M

[Aaron Sakovich]

Thanks everyone. And just to let you know, Hoff's right -- we do extensive auditing of breakins, logfails, and more. I also have DECW$MessagePanel open on my desktop anytime I'm connected and can get an X session running, by using (shameless plug) this routine:

http://dcl.openvms.org/stories.php?story=05/08/19/9252475

so I can watch login failures and more live, as they happen.

Cheers!