Date: Sun, 21 Feb 1999 21:19:42 -0500 From: Weld Pond To: BUGTRAQ@netspace.org Subject: Severe Security Hole in ARCserve NT agents (fwd) ---------- Forwarded message ---------- Date: Sun, 21 Feb 1999 17:44:55 -0500 >From: ELVIS To: news@rootshell.com Cc: hotnews@l0pht.com, CAI , security@microsoft.com 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" To: BUGTRAQ@netspace.org 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 . 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" To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.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. 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 To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM 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. :) <> ----------------------------------------------------------------------------- Date: Thu, 29 Apr 1999 17:29:58 -0400 From: Russ To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM 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, ...... 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