Threat Level: green Handler on Duty: Rob VandenBrink

SANS ISC InfoSec Handlers Diary Blog


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

CISCO Security Advisories

Published: 2009-09-23
Last Updated: 2009-09-24 01:24:05 UTC
by Mark Hofman (Version: 1)
2 comment(s)

 CISCO has released a number of security advisories.   The following table summarises the information.  for more details check out the full advisory on the CISCO site. 

#

Product

CVSS Score

Base/Temp

Impact

Work Around/Fix

Mitigation

Exploit avail?

cisco-sa-20090923-cm*

Unified Communications Manager

7.8 / 6.4

DOS

reload of device

N / Y

Filter 5060/5061 on screening devices

Not known

cisco-sa-20090923-acl

IOS

4.3 / 3.6

Unauth access to protected resources

N / Y

Disable Object Groups for ACL feature

Not known

cisco-sa-20090923-cme*

Unified Communications Manager Express

7.6 /6.3

Code execution/DOS

N / Y

Disable Extension Mobility

Not known

cisco-sa-20090923-h323*

IOS

7.8 / 6.4

H.323 DOS Reload of device

N / Y

Disable H.323

Not known

cisco-sa-20090923-ios-fw*

IOS-FW

7.8 / 6.4

DOS

reload of device

Y / Y

Disable SIP Inspection

Not known

cisco-sa-20090923-ntp

IOS

7.8 / 6.4

DOS

reload of device

N / Y

Disable NTP

Not known

cisco-sa-20090923-sip*

IOS

7.8 / 6.4

DOS

reload of device

N / Y

Disable SIP 

Not known

cisco-sa-20090923-ipsec

IOS-IPSEC

7.8 / 6.4

DOS

exhaust all SAs

N / Y

None

Not known

cisco-sa-20090923-tls**

IOS

(ASA is not vulnerable)

7.8 / 6.4

DOS

reload of device

N / Y

Disable web VPN, protect SSH access

Not known

cisco-sa-20090923-auth-prox

IOS

7.1 / 5.9

Auth Bypass

N / Y

None

Not known

cisco-sa-20090923-tunnels

IOS

7.1 / 5.9

DOS

reload of device

Y / Y

Disable CISCO express Forwarding

Not known

 *Issues are VoIP related so may not apply to you 
** Possible the more urgent one as a specific packet sent to the device will cause it to reload.  

For more information on the CVSS score see http://nvd.nist.gov/cvss.cfm?vectorinfo make sure you apply your site specific modifiers to get a score relevant to your organisation.

As always, test, test again and have a backout plan before applying updates.

 

Mark H 

Keywords:
2 comment(s)

Storing passwords

Published: 2009-09-23
Last Updated: 2009-09-23 23:59:11 UTC
by Mark Hofman (Version: 1)
46 comment(s)

I have a problem, no a challenge, for you all.  How do you store passwords that have to be shared between team members. 

I'm confident in saying that every IT environment has this problem.  You have passwords for service accounts, printers, switches, routers, firewalls, admin passwords for products, build passwords when building servers or desktops, etc, etc, etc.  Many of these can only be accessed through limited userid and can't be hooked into a radius Many of these don't need to be used often, but they do need to be recorded and in a typical IT environment there are likely to be a number of people that need these.  So how do you share them in a sane manner?

Some of the examples I've come across include the traditional word document or spreadsheet, sometimes it even has a password.  Other examples are databases, Lotus Notes, MS Access, Sharepoint pages, wiki pages, post-it notes, commercial tools, some are better solutions than others.  So I'd like to know what you do when faced with this issue?  Send some in and we'll share your experiences in an update.

UPDATE

Thank you all for contributing, the response has been excellent.  Most of the methods used have been reflected in the comments.  

Mike has one for the *nix users out there.   

"My preferred method is an encrypted file (using vi -C) read/write only by root on a system like a nis master, where you have to log in as you then using either pfexec or sudo to access the file.

This satisfies the theory that you need to have a user account on the correct system, the correct privs and know just one more password - this is reasonably straightforward.
One additional safeguard is using a version control system like the builtin (on Solaris) sccs to keep a good record."

Joost uses Keepass like many in the comments.  

"On a share only accessible by IT we have 2 keepass (http://keepass.info/) databases. Both are protected by a password and a keyfile (on a usb stick).

database 1 is for all passwords that are for the helpdesk, network- and systemadmins.
database 2 is only for network- and systemadmins."

Several people wrote in regarding the eDMZ product. 

Bryan mentions their own application:

"we used to have a commercial app, then we started having problems. So we built our own internal PHP-MySQL webapp. It is only accessible via HTTPS, and the database uses MySQL's built in AES encryption to store the password data encrypted. Users must enter a username, password, and encryption key to login. This does make the encryption key short, but it is never stored in the application itself.

It is a stand-alone webapp at the moment, but we are planning on having it connect to AD for authentication, and writing in permissions to limit user/group access to passwords.
"

A few readers also use the good old piece of paper and safe method, after all you don't really need to use these shared accounts often, if at all.  

Thank you all for your excellent contributions.   

Mark

 

Keywords:
46 comment(s)

Addendum to SRI's Conficker C Analysis Published

Published: 2009-09-23
Last Updated: 2009-09-23 01:24:17 UTC
by Marcus Sachs (Version: 1)
0 comment(s)

SRI recently updated their Conficker C analysis with another addendum, this one covers Conficker C's P2P protocol and implementation.  Here's the abstract of the new addendum:

This report presents a reverse engineering of the obfuscated binary code image of the Conficker C peer-to-peer (P2P) service, captured on 5 March 2009 (UTC). The P2P service implements the functions necessary to bootstrap an infected host into the Conficker P2P network through scan-based peer discovery, and allows peers to share and spawn new binary logic directly into the currently running Conficker C process. Conficker's P2P logic and implementation are dissected and presented in source code form. The report documents its thread architecture, presents the P2P message structure and exchange protocol, and describes the major functional elements of this module.

As always, this is a GREAT report from the Malware Threat Center at SRI. 

Marcus H. Sachs
Director, SANS Internet Storm Center

Keywords: conficker sri
0 comment(s)
Diary Archives