Re: Tuning false positives - SIM is not the answer

[Brent Stackhouse <brent () solissecurity com>]

Look at this new Cisco advisory:

http://www.cisco.com/en/US/products/products_security_advisory09186a00805e3234.shtml

My favorite part:

"Exploitation and Public Announcements

The Cisco PSIRT is not aware of any public announcements or malicious 
use of the vulnerability described in this advisory."

Well, I sure didn't tell PSIRT since everyone in MARS support already 
knew about it.  Interesting timing but at least they're addressing it.

Brent Stackhouse, GSEC/GCIH
VP of Security
Solis Security, Inc.
Austin, Texas
512-417-9772
www.solissecurity.com

Hellman, Matthew wrote:
> 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:brent () solissecurity com]
> Sent: Monday, January 09, 2006 9:25 AM
> To: Jason
> Cc: focus-ids () securityfocus com
> 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 Connect () principal com 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.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature