Type packetstorm
Reporter Packet Storm
Modified 1999-08-17T00:00:00


                                            `Date: Sun, 21 Feb 1999 21:19:42 -0500  
From: Weld Pond <weld@L0PHT.COM>  
Subject: Severe Security Hole in ARCserve NT agents (fwd)  
---------- Forwarded message ----------  
Date: Sun, 21 Feb 1999 17:44:55 -0500  
>From: ELVIS <>  
Cc:, CAI <>,  
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!  
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" <Michael.Duncan@CAI.COM>  
Subject: ARCserve 6.5 NT Client Agent Security Protocol Enhancements  
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:  
<> .  
A remote install of this agent that will incorporate the  
changes will be available soon.  
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" <Michael.Duncan@CAI.COM>  
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.  
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 <rwatkins@ZAPCOM.NET>  
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  
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. :)  
Date: Thu, 29 Apr 1999 17:29:58 -0400  
From: Russ <Russ.Cooper@RC.ON.CA>  
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)  
- TF68089 for InocuLAN (requires Release 4.0 build 373 or 375 of  
InocuLAN installed, as well as build 64 of InocuLAN Exchange Agent)  
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  
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).  
Russ - NTBugtraq moderator