`Date: Sun, 21 Feb 1999 21:19:42 -0500
From: Weld Pond <[email protected]>
To: [email protected]
Subject: Severe Security Hole in ARCserve NT agents (fwd)
---------- Forwarded message ----------
Date: Sun, 21 Feb 1999 17:44:55 -0500
>From: ELVIS <[email protected]>
To: [email protected]
Cc: [email protected], CAI <[email protected]>, [email protected]
Subject: Severe Security Hole in ARCserve NT agents
This is absolutely pathetic.
You can obtain user names and passwords used by ARCserve NT agents when an
NT system is backed up over a TCP/IP network. Usually, for complete access
to the system, these accounts will be granted administrator rights. This
only affects the "stock" NT agents. The Exchange and SQL backup agents
appear to use NTLANMAN authentication (which has its own problems). There
are probably similar exploits available over IPX/SPX and NetBEUI, but this
note only covers TCP/IP.
Set your sniffer (Network Monitor from Systems Management Server will do)
to listen for TCP/IP packets directed to port 6050 (17A2 hex). This will
be the ARCserve server connecting to the remote client. The third packet
you get is the one you want.
The user name will be at offset 0x00EE in clear ASCII text.
The password will be at offset 0x011E. Simply XOR these bytes with the
ASCII values of the string "Ambuf1,et(0,21)", minus quotes of course, to
get the PLAIN TEXT password!
ACK! YOU THOUGHT MICROSOFT WAS BAD!!!! GAG! BARF! These people SHOULD
BE ASHAMED OF THEMSELVES!!!!
If you bother to search, you will find "Ambuf1,et(0,21)" in no less than 17
ARCserve EXE's and DLL's.
It is suggested that all ARCserve customers cease using the NT agents
immediately if not sooner.
-----------------------------------------------------------------------------
Date: Wed, 24 Feb 1999 12:24:46 -0500
From: "Duncan, Michael" <[email protected]>
To: [email protected]
Subject: ARCserve 6.5 NT Client Agent Security Protocol Enhancements
Russ,
Just to let you aware, enhancements have been made to the
ARCserve 6.5 NT Client Agent security protocol. The updated
files are available for download at:
http://support.cai.com/Download/patches/asnt/LO45599.html
<http://support.cai.com/Download/patches/asnt/LO45599.html> .
A remote install of this agent that will incorporate the
changes will be available soon.
Thanks...
Michael Duncan
Computer Associates International Inc.
One Computer Associates Plaza
Islandia, NY 11788
-----------------------------------------------------------------------------
Date: Fri, 26 Feb 1999 09:16:26 -0500
From: "Duncan, Michael" <[email protected]>
To: [email protected]
Subject: Re: ARCserve 6.5 NT Client Agent Security Protocol Enhancements
The ARCserve 6.5 NT Client Agent Security Protocol Enhancement is
temporarily unavailable.
We will be posting a new version that will include remote install
support for this agent, as well as coverage for additional modules.
We will have the updated version available momentarily.
Thanks...
Michael Duncan
Computer Associates International Inc.
One Computer Associates Plaza
Islandia, NY 11788
-----------------------------------------------------------------------------
Date: Mon, 26 Apr 1999 14:48:42 -0700
From: Ron Watkins <[email protected]>
To: [email protected]
Subject: ArcServe Exchange Client Security Issue still unresolved
I just got a call from Computer Associates in regard to the Arcserve Client
for Exchange.
They say that the problem with the password length being left in the
C:\exchverify.log file is still unresolved but 'they are working on it'. The
person who called me says that there have been numerous complaints on this
issue. (big surprise there, eh?) The fellow I spoke to (whose name was
probably Nick but I'm not sure, as I was interrupted before I got the details
written down) claims that the client only encodes the length of *incorrect*
passwords. That may be true of the current build, but has not always been
true. The first versions put a plaintext password in the log file; later
versions put the (correct) length of the system password. I have not verified
the behavior of the current build, and likely won't have time for at least a
couple weeks.
About a month ago, someone posted to the list that the Arcserve Client for
Exchange was still putting in plaintext passwords. To my best knowledge this
is not the case. The client will append to the log file, instead of erasing
it. The original build is actually at fault in these cases, as its log
entries are never removed. I am repeating this because I don't think my reply
to the original post was approved.
It is safe in any case to delete c:\exchverify.log. It is not needed after
installation.
No mention was made of the issue of the weakly-encrypted system password in
the registry. The fellow I spoke to seemed pretty confused about the actual
nature of the complaint, and I didn't think to ask about this problem at the
time. I had, in fact, forgotten about that part of the complaint until I
reviewed my notes.
Note that I first posted about my conversation with Brian Linton on 12/16/98,
so they've had four months to do a couple of very minor fixes. If you're
affected by these security issues, you may want to call and make some noise to
hurry them along a bit. :)
<<RON>>
-----------------------------------------------------------------------------
Date: Thu, 29 Apr 1999 17:29:58 -0400
From: Russ <[email protected]>
To: [email protected]
Subject: Arcserve/InocuLAN Exchange password issues
Today I received a message from Computer Associates regarding the long
standing password issues we've discussed in ARCserve Backup Agent for
Exchange and InocuLAN.
They say they have implemented a new password encryption scheme, and
also say that all occurrences of the password have been removed from the
exchvrfy.log file.
Unfortunately, I no longer have versions of these products which I can
use to test these patches. CAI say;
"We have tested the fixes here, and also sent them out to clients as
well, ...<snip>... You may let anyone know to call into our support line
and our support technicians will make this fix available to them."
There are two separate fixes;
- T146159 for their ARCserve Backup Agent for Exchange (requires Release
6.5 build 622 of ARCserve for NT installed)
and
- TF68089 for InocuLAN (requires Release 4.0 build 373 or 375 of
InocuLAN installed, as well as build 64 of InocuLAN Exchange Agent)
Note:
Both patches include VService.exe. The one supplied with the InocuLAN
patch is a newer version than the one supplied with the ARCserve patch,
therefore I would assume that you should apply the ARCserve patch before
the InocuLAN patch. It may not matter, but I thought I'd point it out.
At the time of writing, neither patch is available from CAI's publicly
accessible patches web site.
If someone who has previously seen the issues discussed could report
back to the list on the effects of these patches, I would be very
grateful.
While we still haven't convinced CAI to participate themselves directly
to the list, it would seem obvious that they are paying some attention
to us. It may have taken them nearly 5 months to address this issue, but
at least its been addressed (hopefully correctly or sufficiently).
Cheers,
Russ - NTBugtraq moderator
`
Data
Build on a solid foundation with Vulners data
We provide the essential building blocks for cybersecurity solutions with comprehensive, structured, and constantly updated vulnerability and exploits data
Api
Power your application with Vulners API
The Vulners REST API offers reliable, high-performance access to vulnerability intelligence, with 99.9% SLA uptime and CDN-backed data delivery for seamless global access
App
Assess and manage vulnerabilities with Vulners tools
Built on top of Vulners' database and SDK, end-user solutions give security professionals and developers lightweight and powerful tools for vulnerability remediation