Dale, arcache was updated a few versions ago to be able to only be run from the server, it no longer offers an option for what host to connect to...so it has to be run locally, which greatly increases it's security....and as you mentioned, if you have that config option set...you can't even do it locally without updating parameters :)
On Fri, Jan 31, 2014 at 9:25 AM, Dale Hurtt <dale_hu...@yahoo.com> wrote: > Just so we are all using the same terminology, a backdoor is intentionally > hidden (although it may be discovered), so anything documented, like Demo, > is not a backdoor. http://en.wikipedia.org/wiki/Backdoor_(computing) > > > Doug Mueller wrote: > > > > Now, there are a bunch of other security settings that I encourage you > to use -- > > > > -- restrict where run processes can run processes > > -- control the shell under which processes can run > > -- use the password management feature to enforce password rules > > -- use the feature that disables an account after x bad password attempts > > (and make x a relatively small number like 5 or at most 10) > > -- disallow blank passwords (except for AREA cross-reference situations) > > -- and a number of other things > > I am sure all of you have used arcache to insert a new admin account into > the system because [cough] someone ELSE changed the password of the admin > account and forgot it. That is not a backdoor either, but a well-documented > front door in breaking into the ARS server. I haven't had to use this in a > while, so I don't know if the security parameters have changed, but you > used to be able to install arcache on your laptop and run it against a > remote server. One of the security measures NOT mentioned above is to > secure arcache by using "Disable-User-Cache-Utilities: T" in the ar.cfg. > This then requires that anyone wishing to use the utility must have access > to the file ON the server, thus providing another layer of security. > > > Doug also wrote: > > > > Remedy should not be vulnerable to attack of the kind described unless > you have > > opened your systems to the outside > > Unfortunately, firewalls don't always help in this regard. Still waiting > for details (that may never come), but malware inserted inside the > firewall, and unfortunately masquerading as another BMC product > (Bladelogic), was used as an intermediary between the POS malware and > dumping the data outside. At least if I read the preliminary forensics > report correctly. > http://blogs.mcafee.com/mcafee-labs/analyzing-the-target-point-of-sale-malware > > > From the above link > > > > Note: The reference to "bladelogic" is a method of obfuscation. The > malware does not compromise, or integrate with, any > > BMC products in any way. The executable name "bladelogic.exe" does not > exist in any piece of legitimate BMC software. > > Regards, > > Dale Hurtt > SPEC IT LLC > Contractor for US Army Information Systems Engineering Command (USAISEC) > > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "Where the Answers Are, and have been for 20 years" > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
