Project Mayhem: Security in Managed Operations. Controlled Anarchy

I had the pleasure of sitting in on a talk by Glenn Brunette regarding Immutable Service Containers (ISC).

First, I believe the Sun Systemic Security framework is proof that Sun is committed to a secure computing infrastructure.  We are using the principals of self-preservation, defense in depth, least privilege, compartmentalization and proportionality as building blocks for our products. It's one thing to use security methodology in deploying a product, but that is made easier and better when that methodology is built into the product.

Anyone with an interest in security should have a look: http://wikis.sun.com/display/ISC/Home;jsessionid=79DE09EA34FB1AD0CE775999E0C39B9D

I have customers that are already using ISC in their environments to create an extremely secure, extremely flexible, easily expandable SAS infrastructure. Provisioning a new server take a matter of minutes. In the time it used to take to start a jumpstart client, I can have a new server up and running.

The best part? You can try it for free by downloading OpenSolaris! Sun...making the world a better place one datacenter at a time.

First, the link to research signatures: http://tools.cisco.com/security/center/home.x

Now a tip for using the Cisco IDSM module without purchasing their overpriced control station. The IDSM module will not syslog alert, it also will not SNMP trap by default. So how do I get the IDSM module to trap when an event is triggered?

The Key is the "Event Action Override", this allows you to set a default action for all signatures that fall withing a specified Risk Rating (RR) range. In my case I set the default action of sending an SNMP trap for signatures with a RR of 18-100. 100 is the max RR, 18 is the lowest RR of signatures that by default alert. This will ensure that all signatures that are set to "alert" will produce an SNMP trap.

What about signatures that have a RR that is 18 or more, but shouldn't alert? Such as signatures that are apart of meta-events?

That is where the "Event Action Filter" comes into play. It allows us to specify signatures that we don't want to send a trap. You can specify signature(s), sub-signature(s), RR, etc.. Then you simply select to over-ride the SNMP trap action.

You might be thinking that this seems convoluted, why not simply adjust the signatures to trap? Well, because there are hundreds of signatures and they will need to be reviewed everytime they are updated. By using the "Event Action Override" new signature will automatically send a trap by default. The Event Action Filtering will only be needed for a few noisy signatures based on your environment.

http://www.networkworld.com/news/2008/072108-open-source-security-risk.html

 I would like to see the full report and criteria, but a few things that stood out to me were quote like the following:

"not having a specific e-mail alias for submission of security vulnerabilities. 'You don't want to report bugs to a general mailing list because it would go to the general public,'"

Wasn't transparency a benefit of open source software? The general public is given the source code, the general public is asked to contribute to open source...why would your want to obscure the transparency at this stage? How many bugs have been reported to proprietary software vendors that are basically sat on for years? Does this make it any less vulnerable, or is it an ostrich approach to security where we stick our head in the sand and assume that no one else can see the bugs?

I'm not saying that a dedicated email alias for security issues shouldn't be done. This would definitely benefit the various communities, but I don't think bug reporting should be a closed loop process.

"The reality is that while open source software may appear more cost-effective and just as functional as commercial software in some instances, the question of maintenance must be examined very carefully."

This I will agree with. Who maintains your OpenSource software? Where do you turn when you have issues with it? This sounds more of a perception problem by the user than a flaw in open source. If you do not have the in-house skills to maintain the software, you need to purchase a service contract. That service contract will help support the community that is fixing these bugs...it will also help fund features being implemented that you need.

Maybe the open source community does need to change their modus operandi. Maybe the open source model needs a little update to reflect the fact that they have gone from an underground movement to a major player in the field. I'm not sure...its definitely time to rethink the way the community operates. Hopefully this report will kick off discussions in that are.

Kris Kapersky, who has written several books on hacking and secure programming as well as developed his own Internet security suite, has announced he has found the ultimate backdoor. 

Now, this is not the first time an exploit of the intel chips has been announced. Way back in 1999 when Pentium IIIs where just coming on the scene, it was shown that the serial code of the chips could be retrieved without the consent or knowledge of the user. Those of us who prefer to surf the net anonymously, certainly did not like the idea of big brother tracking us by the chip serial number. Then there are those in other countries where the ability to surf anonymously is a necessity. Still, a rather benign flaw overall that was quickly forgotten.

 Now comes the announcement that intel chips can be remotely exploited via tcp or javascript! What makes this so important is that it is OS independent. You could be running the most secured OS available...and it wouldn't matter. The details of the exploit aren't currently available, and Kapersky has decided that mums the word until the Hack In The Box Conference scheduled for October. I know I'm not the only one that will be VERY interested in seeing the details of the exploit.

 This is the second bombshell exploit to be announced. The first being the Cisco IOS rootkit that was revealed at the EuroSecWest. Add to that the multi-vendor DNS vulnerability that was recently announced, and now an Intel exploit. Yup...this could end up being a very fun year for security engineers.

Upgraded a pair of ASA firewalls from 7.2(2) to 7.2(4) in an attempt to address some of the recent vulnerability announcements. Seems like an easy enough upgrade, since it's only going from one minor revision to the next....right? Wrong.

Jul 03 2008 08:11:16: %ASA-7-713236: IP = xx.xx.xx.xx, IKE_DECODE RECEIVED Message (msgid=1337c959) with payloads : HDR + HASH (8) + SA (1) + NONCE (10) + ID (5) + ID (5) + NOTIFY (11) + NONE (0) total length : 176

Jul 03 2008 08:11:16: %ASA-7-715047: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, processing hash payload

Jul 03 2008 08:11:16: %ASA-7-715047: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, processing SA payload

Jul 03 2008 08:11:16: %ASA-7-715047: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, processing nonce payload

Jul 03 2008 08:11:16: %ASA-7-715047: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, processing ID payload

Jul 03 2008 08:11:16: %ASA-7-714011: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, ID_IPV4_ADDR ID received

Jul 03 2008 08:11:16: %ASA-7-713025: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, Received remote Proxy Host data in ID Payload:  Address 172.16.16.1, Protocol 0, Port 0

Jul 03 2008 08:11:16: %ASA-7-715047: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, processing ID payload

Jul 03 2008 08:11:16: %ASA-7-714011: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, ID_IPV4_ADDR_SUBNET ID received--xx.xx.xx.xx--255.255.255.0

Jul 03 2008 08:11:16: %ASA-7-713034: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, Received local IP Proxy Subnet data in ID Payload:   Address xx.xx.xxx.xx, Mask 255.255.255.0, Protocol 0, Port 0

Jul 03 2008 08:11:16: %ASA-7-715047: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, processing notify payload

Jul 03 2008 08:11:16: %ASA-3-713227: IP = xx.xx.xx.xx, Rejecting new IPSec SA negotiation for peer xx.xx.xx.xx. A negotiation was already in progress for local Proxy xx.xx.xx.xx/255.255.255.0, remote Proxy xx.xx.xx.xx/255.255.255.255

Jul 03 2008 08:11:16: %ASA-3-713902: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, QM FSM error (P2 struct &0x6413a88, mess id 0x1337c959)!

Jul 03 2008 08:11:16: %ASA-7-715065: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, IKE QM Responder FSM error history (struct &0x6413a88)  <state>, <event>:  QM_DONE, EV_ERROR-->QM_BLD_MSG2, EV_IS_REKEY-->QM_BLD_MSG2, EV_CONFIRM_SA-->QM_BLD_MSG2, EV_PROC_MSG-->QM_BLD_MSG2, EV_HASH_OK-->QM_BLD_MSG2, NullEvent-->QM_BLD_MSG2, EV_COMP_HASH-->QM_BLD_MSG2, EV_VALIDATE_MSG

Jul 03 2008 08:11:16: %ASA-7-713906: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, sending delete/delete with reason message

Jul 03 2008 08:11:16: %ASA-7-713906: Received unexpected event EV_REMOVE in state MM_WAIT_DELETE

Jul 03 2008 08:11:16: %ASA-3-713902: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, Removing peer from correlator table failed, no match!

Jul 03 2008 08:11:16: %ASA-7-713906: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, IKE SA MM:5a58159b rcv'd Terminate: state MM_ACTIVE  flags 0x0001c042, refcnt 1, tuncnt 0

Jul 03 2008 08:11:16: %ASA-7-720041: (VPN-Primary) Sending Phase 1 Terminate message (type L2L, remote addr xx.xx.xx.xx, my cookie 5A58159B, his cookie 94006566) to standby unit

Jul 03 2008 08:11:16: %ASA-7-713906: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, IKE SA MM:5a58159b terminating:  flags 0x0101c002, refcnt 0, tuncnt 0

Jul 03 2008 08:11:16: %ASA-7-713906: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, sending delete/delete with reason message

Jul 03 2008 08:11:16: %ASA-7-715046: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, constructing blank hash payload

Jul 03 2008 08:11:16: %ASA-7-715046: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, constructing IKE delete payload

Jul 03 2008 08:11:16: %ASA-7-715046: Group = xx.xx.xx.xx, IP = xx.xx.xx.xx, constructing qm hash payload

Jul 03 2008 08:11:16: %ASA-7-713236: IP = xx.xx.xx.xx, IKE_DECODE SENDING Message (msgid=34d011ee) with payloads : HDR + HASH (8) + DELETE (12) + NONE (0) total length : 76

Jul 03 2008 08:11:16: %ASA-4-113019: Group = xx.xx.xx.xx, Username = xx.xx.xx.xx, IP = xx.xx.xx.xx, Session disconnected. Session Type: IPSecLAN2LAN, Duration: 0h:00m:00s, Bytes xmt: 0, Bytes rcv: 0, Reason: Unknown

A show isakmp sa give me a few tunnels in the state:

37  IKE Peer: xx.xx.xx.xx

    Type    : L2L             Role    : responder 

    Rekey   : no              State   : MM_WAIT_DELETE

A peek over on the secondary:

18  IKE Peer: xx.xx.xx.xx

    Type    : L2L             Role    : responder 

    Rekey   : yes             State   : MM_WAIT_DELETE

Well, after a bunch of troubleshooting, and finally calling TAC I find that this is realted to bug CSCse45327

Now, if you will notice this bug was FIXED in 7.2(2), and is not listed for any versions after 7.2(2), after all it was fixed. However, that appears to not be the case. Just a warning for all that might tread this way