Matthew, You could always solicit to have the source for the Linux/GNU/GPL'ed apps to be published from Cisco. Linksys had the same problem because they could have modified the code. The same thing could be applied from another perspective for other products out on the market.
Matt Matthew F. Caldwell Chief Security Architect - Office of the CTO Micromuse (MUSE) acquired by (IBM) -----Original Message----- From: Hellman, Matthew [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 10:43 PM To: Brent Stackhouse; Jason Cc: [email protected] Subject: RE: Tuning false positives - SIM is not the answer Root login via SSH is disabled in /etc/sshd/sshd_config. The "expert process" is most likely some sort of su to root, but I've seen the passwd file and there is another user account as well. If my memory serves it had a normal bash shell too. Bottom line is, I think the crap about "protecting IP" is just that. The ISO can be downloaded right from Cisco and like Brent said, I've got physical access and I think someone who really intended to violate the IP could. What really bugs me is stuff like this: http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCsc07680&; cco_product=Cisco+Security+Monitoring,+Analysis+and+Response+System&fset =&swver=&keyw=&target=&train= If you don't have access, this is Cisco's response to the fact that the Oracle default passwords have not been changed: "Workaround: none. As the mars appliance is hardened from root shell access, this should not be a major security threat." A classic example of a vendor just not getting it. So what else is isn't being properly patched/configured because it's a "hardened appliance"? uhg. To be fair to Cisco, they inherited this problem. Still, I have to wonder if the real reason they haven't been willing to open up access is because without iptables the box is a complete mess. -----Original Message----- From: Brent Stackhouse [mailto:[EMAIL PROTECTED] Sent: Monday, January 09, 2006 9:25 AM To: Jason Cc: [email protected] Subject: Re: Tuning false positives - SIM is not the answer Again, they did NOT access the server directly - I had to login first w/ the pnadmin account. Still, the "expert" account has a pw known only to Cisco and I'm not thrilled with that either. Brent Stackhouse, GSEC/GCIH VP of Security Solis Security, Inc. Austin, Texas 512-417-9772 www.solissecurity.com Jason wrote: > fortunately I do not have MARS to play with but if you did not have to > "set" a password for them to use with the expert account I find it very > suspect. > > When they accessed the box was it through a shared terminal where you > were watching the session or did they access it over the network remotely? > > That you had to log into the system as pnadmin suggests that it was a > shared session and then they performed a sudo or su to expert. This > would then suggest that the expert account has a fixed password. If it > required a local account first that indicates remote access is denied > for expert. While this is preferable it is not fool proof. Any > vulnerability presenting local shell access could then allow expert > access if the password was known. > > I ask because it would not be the first time a Cisco product had an > undocumented account with a default/predictable/easy to guess password. > > Perhaps someone from Cisco can clarify these points. > > Brent Stackhouse wrote: > >>It did cross my mind that there might be a backdoor/default account that >>is remotely accessible but TAC said that "expert" access cannot be used >>without having an existing, valid account on the system. To reiterate, >>per TAC, you cannot simply login to a MARS appliance via SSH or SSL with >>the "expert" account. I have not attempted to verify the veracity of >>that statement but during the specific support issue I worked with TAC >>on, I was instructed to login with the pnadmin account (and a password >>known only to me) before TAC could use the expert mode. >> >>If you have a MARS, go to the CLI and type "expert" - I believe it'll >>prompt for a password. >> >>Part of the point is that a similar issue will happen again which will >>require TAC access to the MARS OS and I'm wondering what Cisco's plan is >>to deal with that in the future. The MARS manager I spoke with during >>this support issue provided this rationale: there is a lot of >>easily-accessible intellectual property, due to their use of shell >>scripts, Java, etc., that they'd prefer stay obscured. I mentioned that >>someone could probably rip out the hard drive and access it anyway but >>he said it would still be protected. Um, okay, maybe so and I'm not >>really a forensics guy. I just know that this is not a typical Cisco >>approach and it caused a major support headache for me and a major client. >> >>Brent Stackhouse, GSEC/GCIH >>VP of Security >>Solis Security, Inc. >>Austin, Texas >>512-417-9772 >>www.solissecurity.com >> >>Jason wrote: >> >> >>>>3. The MARS OS is a Linux distro but users can't get to the actual >>>>OS. This wouldn't normally be a problem but there was a bad MARS >>>>build that was published recently, yanked within a day or so, and >>>>then required a TAC engineer to remotely login to the MARS box to fix >>>>it. This is contrary to every other Cisco device, including >>>>Linux-based 42xx IDS/IPS, that I've worked with. >>>> >>> >>> >>>Can I read into that statement that there is a some form of capability >>>that does allow access to the OS but only to Cisco TAC? Did you need to >>>enable an account and password for that access or simply access to the >>>system? -----Message Disclaimer----- This e-mail message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the intended recipient, any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by reply email to [EMAIL PROTECTED] and delete or destroy all copies of the original message and attachments thereto. Email sent to or from the Principal Financial Group or any of its member companies may be retained as required by law or regulation. Nothing in this message is intended to constitute an Electronic signature for purposes of the Uniform Electronic Transactions Act (UETA) or the Electronic Signatures in Global and National Commerce Act ("E-Sign") unless a specific statement to the contrary is included in this message. ------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly? Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more. ------------------------------------------------------------------------ ------------------------------------------------------------------------ Test Your IDS Is your IDS deployed correctly? Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more. ------------------------------------------------------------------------
