OK, it has been a couple of weeks and haven't heard anything back from HP).
When a pop client requests access to the VMS POP server (Alpha VMS 8.3, TCPIP Services 5.6) and provides incorrect username/password, this event is not logged in the audit server. A simple message is sent to OPCOM. This message does not contain any clue on the origin of the request.
So overnight, it becomes possible to run brute force attempts on usernames via POP since no intrusion detection/evasion is made, and short of many messages in operator.log, there is nothing in AnA/AUDIT and no information on the IP address of the client that made those attempts.
(I got such an attack with thousands of attempts).
The whole intrusion detection scheme needs to apply to ALL services which grant access to VMS via user/password combination and all such application should comply to whateer calling standards to ensure that all attempts with invalid credentials are properly logged, including IP address and the username that was attempted.
> OK, it has been a couple of weeks and haven't heard anything back from HP).
> When a pop client requests access to the VMS POP server (Alpha VMS 8.3, > TCPIP Services 5.6) and provides incorrect username/password, this event > is not logged in the audit server. A simple message is sent to OPCOM. > This message does not contain any clue on the origin of the request.
> So overnight, it becomes possible to run brute force attempts on > usernames via POP since no intrusion detection/evasion is made, and > short of many messages in operator.log, there is nothing in AnA/AUDIT > and no information on the IP address of the client that made those attempts.
> (I got such an attack with thousands of attempts).
> The whole intrusion detection scheme needs to apply to ALL services > which grant access to VMS via user/password combination and all such > application should comply to whateer calling standards to ensure that > all attempts with invalid credentials are properly logged, including IP > address and the username that was attempted.
That is a nasty one, since much of what makes VMS resistant to such attacks is the ability to sense a breakin attempt and deny access from the breakin source even when it gets the password correct.
Did the attempt seem to target VMS or was it a script kiddie hacking at a Windoze box or Unix box (accounts like administrator or root being tried)
Michael Moroney wrote: > That is a nasty one, since much of what makes VMS resistant to such > attacks is the ability to sense a breakin attempt and deny access from > the breakin source even when it gets the password correct.
> Did the attempt seem to target VMS or was it a script kiddie hacking at > a Windoze box or Unix box (accounts like administrator or root being > tried)
Works okay in IUPOP3 server <V2.0-4/NETLIB/(DECC) and TCPware V5.7-2.
Still broken in:
"HP TCP/IP Services for OpenVMS Industry Standard 64 Version V5.6 - ECO 1 on an HP rx2620 (1.60GHz/3.0MB) running OpenVMS V8.3"
Both IUPOP3 and TCPware POP3 log intrusions for each failed access and then put you in "INTRUDER" state and initiate break-in evasion after the appropriate number of failures. TCPIP (UCX) just logs the failures to OPCOM.
There are a bunch of logical names that control TCPIP's POP3. None of them seem to enable breakin evasion, though.
Plain vanilla POP3 isn't very secure since the usernames and passwords are transmitted in plain text. There is an alternate APOP authorization method that uses shared secrets instead. I haven't tried setting this up. It can also be run over an SSL connection, where everything is encrypted. I haven't tried setting this up either. (All my users are either on the LAN or coming in over encrypted VPN connections, no WAN access to POP, and they are all company employees with privileged VMS accounts anyway, so it doesn't worry me very much.) Both of these alternate access methods can be configured by logical names to be used in addition to or in place of the standard plain-text access on port 110.
If you're letting the outside world get at port 110, then I would either disable it or firewall it or use one of the alternatives (APOP or SSL) instead.
-- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539
Michael Moroney wrote: > That is a nasty one, since much of what makes VMS resistant to such > attacks is the ability to sense a breakin attempt and deny access from > the breakin source even when it gets the password correct.
> Did the attempt seem to target VMS or was it a script kiddie hacking at > a Windoze box or Unix box (accounts like administrator or root being > tried)
Brute force. And VMS is even worse:
$ telnet/port=110 chain %TELNET-I-TRYING, Trying ... 10.0.0.11 %TELNET-I-SESSION, Session 01, host chain, port 110 +OK TCPIP POP server V5.6-9, OpenVMS V8.3 Alpha at chain.vaxination.ca, up sinc> USER canada -ERR No such user "canada" USER system +OK Password required for "system" PASS chocolate -ERR password supplied for "system" is incorrect. %TELNET-S-REMCLOSED, Remote connection closed -TELNET-I-SESSION, Session 01, host chain, port 110
So by checking whether the USER command returns an -ERR or +OK, you can narrow down which usernames are valid, and then proceed to guess their passwords by brute force.
JF Mezei wrote: > Brute force. And VMS is even worse:
> $ telnet/port=110 chain > %TELNET-I-TRYING, Trying ... 10.0.0.11 > %TELNET-I-SESSION, Session 01, host chain, port 110 > +OK TCPIP POP server V5.6-9, OpenVMS V8.3 Alpha at chain.vaxination.ca, > up sinc> > USER canada > -ERR No such user "canada" > USER system > +OK Password required for "system" > PASS chocolate > -ERR password supplied for "system" is incorrect. > %TELNET-S-REMCLOSED, Remote connection closed > -TELNET-I-SESSION, Session 01, host chain, port 110
> So by checking whether the USER command returns an -ERR or +OK, you can > narrow down which usernames are valid, and then proceed to guess their > passwords by brute force.
Good job IUPOP3 does intrusion detection, and is easily available & installable - I'd often wondered whether I ought to ditch it in favour of the latest ucx/tcpip offering, but hadn't got around to it.
You make a convincing case for IUPOP3. It's source code, too, so if it allows checking of user names in isolation, that would be easily fixable.
Chris Sharman wrote: > Good job IUPOP3 does intrusion detection, and is easily available & > installable - I'd often wondered whether I ought to ditch it in favour > of the latest ucx/tcpip offering, but hadn't got around to it.
> You make a convincing case for IUPOP3. It's source code, too, so if it > allows checking of user names in isolation, that would be easily fixable.
I some time ago also switched from IUPOP3 to TCPIP services, because it serves the SSL port, and our domain requests that for outside connections. I know one could tunnel SSL POP (using e.g. STUNNEL, which I do for IMAP in my aging TCPIP 5.3), but this has the ugly effect of being one connection at a time (and others get connection timeout and have to retry).
Although TCPIP services POP implementation seems to be based on IUPOP3, is there a newer IUPOP3 implementation serving the SSL port ?
"(All my users are either on the LAN or coming in over encrypted VPN connections, no WAN access to POP, and they are all company employees with privileged VMS accounts anyway, so it doesn't worry me very much.) "
This means that the usernames and passwords for privileged vms accounts are going over your corporate LAN unencrypted. You may wish to reconsider this.
Joseph Huber wrote: > Chris Sharman wrote: >> Good job IUPOP3 does intrusion detection, and is easily available & >> installable - I'd often wondered whether I ought to ditch it in favour >> of the latest ucx/tcpip offering, but hadn't got around to it.
>> You make a convincing case for IUPOP3. It's source code, too, so if it >> allows checking of user names in isolation, that would be easily fixable.
> I some time ago also switched from IUPOP3 to TCPIP services, because it > serves the SSL port, and our domain requests that for outside connections. > I know one could tunnel SSL POP (using e.g. STUNNEL, which I do for IMAP > in my aging TCPIP 5.3), but this has the ugly effect of being one > connection at a time (and others get connection timeout and have to retry).
> Although TCPIP services POP implementation seems to be based on IUPOP3, > is there a newer IUPOP3 implementation serving the SSL port ?
No idea at all where to download, since Indiana University closed the IUPOP3 web-page. So I do not expect any new development. Anyone any idea where to get the latest version?
JF Mezei wrote: > OK, it has been a couple of weeks and haven't heard anything back from HP).
> When a pop client requests access to the VMS POP server (Alpha VMS 8.3, > TCPIP Services 5.6) and provides incorrect username/password, this event > is not logged in the audit server. A simple message is sent to OPCOM. > This message does not contain any clue on the origin of the request.
> So overnight, it becomes possible to run brute force attempts on > usernames via POP since no intrusion detection/evasion is made, and > short of many messages in operator.log, there is nothing in AnA/AUDIT > and no information on the IP address of the client that made those > attempts.
> (I got such an attack with thousands of attempts).
> The whole intrusion detection scheme needs to apply to ALL services > which grant access to VMS via user/password combination and all such > application should comply to whateer calling standards to ensure that > all attempts with invalid credentials are properly logged, including IP > address and the username that was attempted.
IanMiller wrote: > "(All my users are either on the LAN or > coming in over encrypted VPN connections, no WAN access to POP, and > they > are all company employees with privileged VMS accounts anyway, so it > doesn't worry me very much.) "
> This means that the usernames and passwords for privileged vms > accounts are going over your corporate LAN unencrypted. You may wish > to reconsider this.
You're wrong, because you are making incorrect assumptions. I won't say any more.
-- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539
<jfmezei.spam...@vaxination.ca> wrote: > Michael Moroney wrote: >> That is a nasty one, since much of what makes VMS resistant to such >> attacks is the ability to sense a breakin attempt and deny access from >> the breakin source even when it gets the password correct. >> Did the attempt seem to target VMS or was it a script kiddie hacking at >> a Windoze box or Unix box (accounts like administrator or root being >> tried)
> Brute force. And VMS is even worse:
> $ telnet/port=110 chain > %TELNET-I-TRYING, Trying ... 10.0.0.11 > %TELNET-I-SESSION, Session 01, host chain, port 110 > +OK TCPIP POP server V5.6-9, OpenVMS V8.3 Alpha at chain.vaxination.ca, > up sinc> > USER canada > -ERR No such user "canada" > USER system > +OK Password required for "system" > PASS chocolate > -ERR password supplied for "system" is incorrect. > %TELNET-S-REMCLOSED, Remote connection closed > -TELNET-I-SESSION, Session 01, host chain, port 110
> So by checking whether the USER command returns an -ERR or +OK, you can > narrow down which usernames are valid, and then proceed to guess their > passwords by brute force.
What happens if you disable telnet and only allow ssh?
>> Michael Moroney wrote: >>> That is a nasty one, since much of what makes VMS resistant to such =
>>> attacks is the ability to sense a breakin attempt and deny access fro= > m >>> the breakin source even when it gets the password correct. >>> Did the attempt seem to target VMS or was it a script kiddie hacking= > at >>> a Windoze box or Unix box (accounts like administrator or root being = > =
>>> tried)
>> Brute force. And VMS is even worse:
>> $ telnet/port=3D110 chain >> %TELNET-I-TRYING, Trying ... 10.0.0.11 >> %TELNET-I-SESSION, Session 01, host chain, port 110 >> +OK TCPIP POP server V5.6-9, OpenVMS V8.3 Alpha at chain.vaxination.ca= > , =
>> up sinc> >> USER canada >> -ERR No such user "canada" >> USER system >> +OK Password required for "system" >> PASS chocolate >> -ERR password supplied for "system" is incorrect. >> %TELNET-S-REMCLOSED, Remote connection closed >> -TELNET-I-SESSION, Session 01, host chain, port 110
>> So by checking whether the USER command returns an -ERR or +OK, you ca= > n =
>> narrow down which usernames are valid, and then proceed to guess their= > =
>> passwords by brute force.
> What happens if you disable telnet and only allow ssh?
He is using TELNET from the source end. The destination is POP. If he disables TELNET he can't get out of his box. :-) Somehow, I don't think that will solve a problem with incoming POP connections.
bill
-- Bill Gunshannon | de-moc-ra-cy (di mok' ra see) n. Three wolves b...@cs.scranton.edu | and a sheep voting on what's for dinner. University of Scranton | Scranton, Pennsylvania | #include <std.disclaimer.h>
On Jul 2, 2:00 am, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> So by checking whether the USER command returns an -ERR or +OK, you can > narrow down which usernames are valid, and then proceed to guess their > passwords by brute force.
Yes, but that behavior is up to the system manager. Messages generated by the POP server can be either FRIENDLY or SECURE. For example, if you don't want a potential attacker to be able to tell whether or not a particular username exists, you can do:
Of course, you'll also want to make appropriate settings around other ways to scan for valid usernames, such as SMTP, FINGER, FTP, and other services you have enabled. Otherwise, the attacker who wants to know whether user JONES exists will just try sending mail and see whether it bounces.
For the POP server, the source of all access attempts (whether successful or not) is captured in the file:
SYS$SYSDEVICE:[TCPIP$POP]TCPIP$POP_RUN.LOG
If the target username exists, the login failure count is also incremented so that the user will be notified of the failures upon the next valid login.
>>> Michael Moroney wrote: >>>> That is a nasty one, since much of what makes VMS resistant to such =
>>>> attacks is the ability to sense a breakin attempt and deny access fro= >> m >>>> the breakin source even when it gets the password correct. >>>> Did the attempt seem to target VMS or was it a script kiddie hacking= >> at >>>> a Windoze box or Unix box (accounts like administrator or root being = >> =
>>>> tried)
>>> Brute force. And VMS is even worse:
>>> $ telnet/port=3D110 chain >>> %TELNET-I-TRYING, Trying ... 10.0.0.11 >>> %TELNET-I-SESSION, Session 01, host chain, port 110 >>> +OK TCPIP POP server V5.6-9, OpenVMS V8.3 Alpha at chain.vaxination.ca= >> , =
>>> up sinc> >>> USER canada >>> -ERR No such user "canada" >>> USER system >>> +OK Password required for "system" >>> PASS chocolate >>> -ERR password supplied for "system" is incorrect. >>> %TELNET-S-REMCLOSED, Remote connection closed >>> -TELNET-I-SESSION, Session 01, host chain, port 110
>>> So by checking whether the USER command returns an -ERR or +OK, you ca= >> n =
>>> narrow down which usernames are valid, and then proceed to guess their= >> =
>>> passwords by brute force.
>> What happens if you disable telnet and only allow ssh?
> He is using TELNET from the source end. The destination is POP. > If he disables TELNET he can't get out of his box. :-) Somehow, I > don't think that will solve a problem with incoming POP connections.
> bill
What I meant was, can ssh be similarly exploited to attempt breakin?
> For the POP server, the source of all access attempts (whether > successful or not) is captured in the file:
> SYS$SYSDEVICE:[TCPIP$POP]TCPIP$POP_RUN.LOG
From my examples posted yesterday:
> 2007-07-02 01:59:23 thread 0: sys$getuai: %RMS-E-RNF, record not found > 2007-07-02 01:59:23 thread 0: User account "canada" is invalid. > 2007-07-02 01:59:23 thread 0: No such user "canada" > 2007-07-02 01:59:40 thread 0: password supplied for "system" is incorrect. > 2007-07-02 01:59:40 thread 0: Max # of authentication attempts exceeded. > 2007-07-02 04:05:51 thread 0: read iosb: %SYSTEM-F-LINKDISCON, network partner d > isconnected logical link > 2007-07-02 04:05:52 thread 0: abnormal disconnect
Where is the source of the attempt ? I see no IP address there.
> If the target username exists, the login failure count is also > incremented so that the user will be notified of the failures upon the > next valid login.
On Jul 2, 1:38 pm, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:
> Where is the source of the attempt ? I see no IP address there.
Whoops, you're right. I forgot that we have TCPIP$POP_LOG_LEVEL defined to THREAD on our systems, which adds to the detail recorded in the logfile. For normal operation, especially if you have hundreds of clients, each configured to check its mailbox every 5 minutes, you may not want to capture that much information. I agree that logging the client address should probably be the default, at least in cases where there has been an invalid access attempt.
Note that this was posted to the ovms-li...@openvms.org by Hoff:
From: SMTP%"ovms-li...@openvms.org" 2-JUL-2007 21:50:28.68 To: "Patch and Security Alerts" <ale...@openvms.org> Subj: [OVMS-Alert] TCP/IP Services POP3 Security Vulnerability Report in Wild
From Stephen Hoffman, Hoffman Labs:
JF Mezei has posted details of a security vulnerability in the OpenVMS TCP/IP Services POP3 implementation (current versions) into the comp.os.vms newsgroup, reportedly after contacting HP with the initial report of the vulnerability. Mr Mezei indicates a local OpenVMS Alpha system was targeted by a POP3 dictionary attack.
Remote IP-based POP3-based dictionary attacks appear feasible against passwords using this vulnerability, and no breakin evasion processing is performed.
I've posted a quick review of the newsgroup report and some suggestions at the HoffmanLabs site:
It is unclear if other components of TCP/IP Services are similarly afflicted.
_______________________________________________
NOTICE: Patches/Kits may not be available for several hours. -KF _______________________________________________ You are subscribed to: ale...@openvms.org To subscribe: alerts-subscr...@openvms.org To unsubscribe: alerts-unsubscr...@openvms.org
Send administrative queries to <alerts-requ...@openvms.org>
Please forward to friends and co-workers.
OpenVMS.org lists are not affiliated with HP. OpenVMS is a trademark of HP.
>> Michael Moroney wrote: >>> That is a nasty one, since much of what makes VMS resistant to such =
>>> attacks is the ability to sense a breakin attempt and deny access fro= >m >>> the breakin source even when it gets the password correct. >>> Did the attempt seem to target VMS or was it a script kiddie hacking= > at >>> a Windoze box or Unix box (accounts like administrator or root being = > =
>>> tried)
>> Brute force. And VMS is even worse:
>> $ telnet/port=3D110 chain >> %TELNET-I-TRYING, Trying ... 10.0.0.11 >> %TELNET-I-SESSION, Session 01, host chain, port 110 >> +OK TCPIP POP server V5.6-9, OpenVMS V8.3 Alpha at chain.vaxination.ca= >, =
>> up sinc> >> USER canada >> -ERR No such user "canada" >> USER system >> +OK Password required for "system" >> PASS chocolate >> -ERR password supplied for "system" is incorrect. >> %TELNET-S-REMCLOSED, Remote connection closed >> -TELNET-I-SESSION, Session 01, host chain, port 110
>> So by checking whether the USER command returns an -ERR or +OK, you ca= >n =
>> narrow down which usernames are valid, and then proceed to guess their= > =
>> passwords by brute force.
>What happens if you disable telnet and only allow ssh?
Telnet in this instance is just being used to setup a connection to the POP server port and then to pass the same commands that a pop client would send. Telnet is often used in this manner. The telnet connection could come from anywhere and the only way to stop telnet connections to the POP server port would basically be to stop anyone connecting to that port eg not to run the POP server.
David Webb Security team leader CCSS Middlesex University
The problem is that an application that accepts a username/password and attempts to validate using $HASH_PASSWORD and $GETUAI *must* also make explicit calls to $SCAN_INTRUSION, otherwise it provides a back door around the intrusion detection mechanism. I have seen this on many applications, including POP servers and web scripts to change your password. With the benefit of hindsight, it might have been a better idea to provide a $VERIFY_PASSWORD service which combines the three functions above, because it is so easy for a developer to overlook it.
Another place to check is if the UCX SMTP server supports SASL (this is the "my-server-requires-authentication" checkbox in the POP client). SASL allows the client to pass a username/password in the ESMTP dialog so that you can allow authenticated clients to relay through your server irrespective of what IP address they are coming from . Even PMDF overlooked putting this through $SCAN_INTRUSION when it first came out (it was fixed pretty quickly). Only slightly more difficult to script an attack on this one.
To check if your SMTP server supports SASL, telnet to port 25 and issue an EHLO command. Look for the AUTH extension. It is harder to test using telnet because the username/password pair need to be BASE64 encoded.
--------------------------------------------------------- Tom Wade | EMail: tee dot wade at eurokom dot ie EuroKom | Tel: +353 (1) 296-9696 A2, Nutgrove Office Park | Fax: +353 (1) 296-9697 Rathfarnham | Disclaimer: This is not a disclaimer Dublin 14 | Tip: "Friends don't let friends do Unix !" Ireland
> The problem is that an application that accepts a username/password and > attempts to validate using $HASH_PASSWORD and $GETUAI *must* also make > explicit calls to $SCAN_INTRUSION, otherwise it provides a back door > around the intrusion detection mechanism. I have seen this on many > applications, including POP servers and web scripts to change your > password. With the benefit of hindsight, it might have been a better > idea to provide a $VERIFY_PASSWORD service which combines the three > functions above, because it is so easy for a developer to overlook it.
> Another place to check is if the UCX SMTP server supports SASL (this is > the "my-server-requires-authentication" checkbox in the POP client). > SASL allows the client to pass a username/password in the ESMTP dialog > so that you can allow authenticated clients to relay through your server > irrespective of what IP address they are coming from . Even PMDF > overlooked putting this through $SCAN_INTRUSION when it first came out > (it was fixed pretty quickly). Only slightly more difficult to script > an attack on this one.
> To check if your SMTP server supports SASL, telnet to port 25 and issue > an EHLO command. Look for the AUTH extension. It is harder to test > using telnet because the username/password pair need to be BASE64 encoded.
> --------------------------------------------------------- > Tom Wade | EMail: tee dot wade at eurokom dot ie > EuroKom | Tel: +353 (1) 296-9696 > A2, Nutgrove Office Park | Fax: +353 (1) 296-9697 > Rathfarnham | Disclaimer: This is not a disclaimer > Dublin 14 | Tip: "Friends don't let friends do Unix !" > Ireland
On Jul 2, 12:10 am, John Santos <j...@egh.com> wrote:
> Plain vanilla POP3 isn't very secure since the usernames and passwords are > transmitted in plain text. There is an alternate APOP authorization method > that uses shared secrets instead. I haven't tried setting this up.
APOP works well in TCP/IP Services and setup is trivial. The username is still passed in the clear, but the password is not. Setup can be summarized as:
1. Create a POP_SECRET.DAT file with your passphrase in your VMSmail directory (secure it so that only the owner has access). 2. If necessary, tell your client that you're going to use APOP.
Full details for the server side can be found in the following section of the TCP/IP Services User's Manual:
In the case of Thunderbird, you don't have to do anything extra -- when you connect, it asks for your password: simply provide your passphrase.
You would still be able to use this thread's described attack vector to identify user accounts, but it removes the ability to sniff passwords on the wire, as only an MD5 hash of the passphrase is sent.
|
