Several Cisco IOS DOS Issues Resolved

Published: 2013-03-27. Last Updated: 2013-03-27 21:03:55 UTC
by Rob VandenBrink (Version: 2)
1 comment(s)

Thanks Jim, for forwarding a whole raft of Cisco Alerts on DOS issues affecting various features within IOS.  The alerts can be found here:

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-nat
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-smartinstall
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-ike
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-pt
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-cce
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-ipsla
http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20130327-rsvp

JIm (who's last name starts with a "C") generally gets these about 12 hours before I do (I'm a "V"), so thanks again for forwarding them along !

===============
Rob VandenBrink Metafore

Keywords: Cisco DOS IOS
1 comment(s)

Sourcefire VRT Community ruleset is live

Published: 2013-03-27. Last Updated: 2013-03-27 20:53:53 UTC
by Rob VandenBrink (Version: 1)
0 comment(s)

Joel let us know about a new Community rulset for Snort, from Sourcefire's VRT group (Vulnerability Research Team).

For more details, and how it might affect your Snort build, find his article here:  http://blog.snort.org/2013/03/the-sourcefire-vrt-community-ruleset-is.html

===============
Rob VandenBrink
Metafore

Keywords: snort sourcefire vrt
0 comment(s)

IPv6 Focus Month: Guest Diary: Stephen Groat - IPv6 moving target defense

Published: 2013-03-27. Last Updated: 2013-03-27 19:42:06 UTC
by Adam Swanger (Version: 1)
2 comment(s)

[Guest Diary: Stephen Groat] [IPv6 moving target defense]

Today we bring you a second guest diary from Stephen Groat where he speaks about IPv6 moving target defense. By frequency hopping in the large IPv6 address space, we're able to create a moving target defense that protects privacy and avoids attackers.

Virginia Tech has developed a moving target defense for IPv6 that adds privacy, anonymity, and security without impacting communications or operations. The Moving Target IPv6 Defense (MT6D) continually rotates through dynamically obscured network addresses while maintaining existing connections. Static addresses are easy targets for address tracking and network attacks. MT6D prevents attackers from targeting specific addresses by dynamically rotating network and transport layer addresses without impacting preexisting sessions. The dynamic addresses are not linked to specific components, requiring attackers to scan the subnet for targets. The immense address space of IPv6 provides an environment so large that an efficient search is infeasible [6]. In the unlikely event that attackers locate a target, the damage they can inflict is limited to the interval between address rotations; reacquiring the target is infeasible.

MT6D modifies the network and transport layer addresses of the sender and receiver nondeterministically. It is capable of dynamically changing these addresses to hide identifiable information about a host, effectively obscuring communicating hosts from any third-party observer. A key feature of MT6D is that this obscuration can be made mid-session between two hosts without causing the additional overhead of connection reestablishment or breakdown. Changing addresses mid-session protects communicating hosts from an attacker being able to collect all packets from a particular session for the purpose of traffic correlation.

MT6D IIDs are computed using three components obscured by a function, usually a hash. The first component is a value specific to an individual host (e.g. a MAC address). The second component is a secret (e.g. symmetric key) shared by the sender and receiver. The third component is a changing value known by both parties (e.g. time). The only one of these three values that must be kept secret is the shared secret. The function results in a 64-bit output used as the MT6D IID and has the form:

II D' = f {IVx*S*CVi}64

where II D' represents the obscured IID for host x at xi a particular instance i , IVx represents a value specific to the individual host x , S represents the shared secret, and CVi represents the changing value at instance i. The three components are combing using an operation denoted by * which concatenates. The 64-bit function result is denoted by f{•}64.

In our implementation, each packet is encapsulated in User Datagram Protocol (UDP) to prevent Transmission Control Protocol (TCP) connection establishment and termination from occurring every time a MT6D address rotates. Encapsulating packets as UDP has a minimal effect on the transport layer protocol of the original packet. Since transport layer protocols are end-to-end, decapsulation will occur before the host processes the original packet. A session using TCP will still exchange all required TCP-related information. This information will simply be wrapped in a MT6D UDP packet. Additionally, any lost packets that were originally TCP will be retransmitted after retransmission timeout occurs.

MT6D provides the option of encrypting each original packet before appending it

with the MT6D header. By encrypting the original packet, a third party is unable to glean any useful information. For example, if the original packet is sent using TCP, the header gets encrypted so that a third party cannot attempt to correlate network traffic using the TCP sequence numbers. Additionally, the nature of the network traffic is also kept private through encryption.

The architecture of a MT6D device mimics a network bridge. Outbound packets are sent to an encapsulator that constructs a MT6D packet. The MT6D packet contains the entire original packet excluding original addresses. When a MT6D packet arrives at its destination, the packet enters a decapsulator which restores the packet to its original form. The design of MT6D facilitates implementation either embedded directly on components or as stand-alone gateway devices.

Post suggestions or comments in the section below or send us any questions or comments in the contact form on https://isc.sans.edu/contact.html#contact-form
--
Adam Swanger, Web Developer (GWEB, GWAPT)
Internet Storm Center https://isc.sans.edu

2 comment(s)

Which IPS is "The Best"?

Published: 2013-03-27. Last Updated: 2013-03-27 14:18:31 UTC
by Rob VandenBrink (Version: 1)
4 comment(s)

I recently had the privilege of advising on a SANS Gold Paper (GCIA) for Michael Dyrmose, titled "Beating the IPS" ( http://www.sans.org/reading_room/whitepapers/intrusion/beating-ips_34137 ).  In the paper, Micheal uses basic IPS evasion techniques to test the capabilities of many of the "major vendor" IPS Systems.  To be as fair as possible, Michael targeted the MS08-067 vulnerability, the security flaw that Conficker took advantage of - every IPS on the planet should be able to handle that, right?

The verdict?  If you are running a penetration test (and so have permission), once you realize that there's an IPS in play, evading it is as simple as trying.  Without exception, if the first evasion method didn't succeed, the second method did.  And remember, this is against one of the most well-known vulnerabilities there is.

What this illustrates is that IPS systems give you decent protection against scripted/automated attacks.  Against a determined, knowledgable attacker who has the time and resources, on a good day what an IPS system does is buy you time.  Time to shore up your defences, perhaps "shun" or otherwise ACL the attackers address (if they're coming from a single IP), or to deploy additional defences or countermeasures - your IPS does not (or rather, should not) stand alone as a single defence mechanism against all attacks.  To that end, I'm really looking forward to John Strand's Offensive Countermeasures class at SANSFIRE this year!

So, which IPS is the best?  The one you spend the time configuring and tuning for your environment.  The one you are monitoring, so that you know that you are under a targetted attack.  If you've configured and are monitoring an IPS, it's now an application that you know well, and can manipulate as conditions and attacks change.  

What does this imply?  That there is an ongoing time commitment to maintaining and monitoring the IPS.  Too many times I see organizations install an IPS as a "tick-box" in their audit requirements, a one time capital expendiature with no ongoing time commitment.  I try to get folks to see that they should budget at least a few weeks to get everything "just so", then 4-8 (or more) days per month forever, even for a simple IPS.  For a more complex environment, it might be a full person-year, or a full team required  for ongoing care and feeding of the IPS and other associated protections in front of your digital "crown jewels"

What I'd be really interested in is how you see those time estimates?  If you have an IPS infrastructure, how much time per week do you commit to it?  If that's not enough time, how much time do you thing would be more appropriate?  Please take our survey here - http://www.surveymonkey.com/s/HD65GQC.  I'll summarize the results and post them in a couple  of weeks.

For a personal preference on which IPS I'd prefer, you'll need to contact me off list (hopefully over beverages), but if we've met you likely don't need to ask!

You can find more quality papers like this one in the SANS Reading Room == > http://www.sans.org/reading_room/

===============
Rob VandenBrink
Metafore

Keywords:
4 comment(s)

Comments


Diary Archives