Category: Security

Tracking The Shellshock BASH Vulnerability – News, Tools and Links

shellshockWith all the attention today to the Shellshock vulnerability, I need a place to keep track of it for my own purposes.  If this page or list helps anyone else, that’s great, but this is primarily a tool for me to capture what’s going on.  I intend to be updating it regularly while this is all happening.  Suggestions are of course welcome in comments.

Note that I have links here to discussion threads on Hacker News.  The comment threads are often fully of incredibly useful information.

Security Advisories

Testing Tools

News about actual exploits

News about the Shellshock vulnerability in general

What Shall We Call Our New Topic Area On “Anti-Spoofing” Of IP Addresses?

question markWe need your help.  We are struggling with what to name the new topic area we are planning to launch related to preventing the “spoofing” of IP addresses.

In routing security circles this topic is generally referred to as “anti-spoofing” and we’ve talked about it ourselves that way such as in our report on an anti-spoofing panel at RIPE66 and the associated videos and whitepapers.  But that name has a couple of problems I’ll talk about below.

First, for some context, back in January 2014 we announced that we were changing how we covered the general topic of “routing resiliency and security”.  Rather than one broad – and vague – topic on “Routing”, our plan was to launch smaller focused topic ares – and with that announcement we  launched our “Securing BGP” topic.

The second focused topic area we want to launch is about steps that network operators and others can do to prevent the spoofing of IP addresses on their networks – and how this can help with prevention of distributed denial-of-service (DDoS) attacks.  Essentially we want to promote the validation of source IP addresses through using tools such as network ingress filtering.  Those who are aware of IETF RFCs/BCPs will know this as BCP 38 and BCP 84.  (And yes, there are the cynics out there who say that getting people to implement BCP 38 is right up there with seeing unicorns and with getting people to deploy IPv6, but hey, we are collectively making some progress with IPv6!  Unicorns are still not walking around, though.)

The simple answer (and where we might end up) would be to call this new topic area: “anti-spoofing“.  But if you look at our other topic areas, they are all technologies that can be deployed:

Okay… so “Securing BGP” is a bit squishy and not as specific as the others, but still, it is about a technology.  All of the topic area names are also short and easy to add to menus.  They all yield nice easy URLs of the form “/deploy360/<topic>/”.

The problems we have with “anti-spoofing” include:

  • “anti-spoofing” … of WHAT?   A web search will show that outside of the routing community the same term is used for efforts against the spoofing of Caller ID, email messages, face recognition, GPS signals, and more.  Many of the results seem to be about spoofing of IP addresses, but not all.
  • It does not reference a technology.

What we are really talking about is preventing the spoofing of source IP addresses inside of a network and the prevention of those spoofed addresses from leaving a network.  We are seeking validation of the original IP address.  However, calling it “IP Spoofing” speaks to the thing we want to prevent, rather than the technology or standards that we want to see deployed.  We want the topic name to reflect what we want people to deploy.

We tried a number of different names:

  • Anti-spoofing
  • Source Address Validation
  • IP Address Source Validation
  • IP Anti-spoofing
  • Ingress Filtering
  • Preventing IP Spoofing
  • Preventing IP Address Spoofing
  • Preventing IP Address Fraud
  • IP Address Validation
  • Stop Spoofing
  • Stop IP Address Spoofing
  • Illegitimate Traffic
  • BCP 38  (or BCP 84)
  • DDoS Prevention

We didn’t find any of those particularly appealing.  Keep in mind that the topic name needs to appear in a number of places on the Deploy360 website including the home page graphic slide, the navigation menus, sidebars, categories, etc.  It also needs to fit in with the other topic areas mentioned earlier.

We thought about “Ingress Filtering”, because that is the technology we ultimately want deployed – but that name is probably even less familiar to people than “anti-spoofing” and just seemed too long.

We toyed with “DDoS Prevention”, as that is really the end goal, and quite frankly would have some SEO/publicity value given the increased reports of DDoS attacks in the news.  But as our summer intern so aptly put it, that “sounds like we are on a crusade” and is also too broad.  We realized that if we open up a topic area on “DDoS Prevention” it is much more than source address validation – we could wind up getting into global load balancers, CDNs and so many other approaches.  And maybe that’s a good thing – but our goal right now is to get out deployment information related to why network operators should deploy source address validation to help the overall resiliency of the Internet.

And so here we are… we want to start promoting some of the tools and methods network operators can use to prevent IP address spoofing.  We want to do this because it is a way to make the Internet more secure and more resilient – and also in part to support some of the other Internet Society efforts underway such as the Routing Resiliency Survey.  We want to be able to talk here on the Deploy360 blog about why is is important to do this.

But we’re struggling with the name because “anti-spoofing” doesn’t seem to fit well with our other names. We’re looking for something specific, short and ideally focused on the technology we want to see deployed.

What do you think?  What should we call this new topic area?  Should we just go with “anti-spoofing”?  Or “ingress filtering”? Or “DDoS Prevention”?  Or one of the other names here? Do any of you have some idea for another name that we’ve missed here?

Any suggestions, ideas and feedback would be greatly appreciated as we’re kind of sitting here spinning our wheels while we try to sort out what name would work best.

Please leave a comment here on the blog or on Twitter, Facebook, Google+ or any of the other social networks where we post this.  Or just send us an email at deploy360@isoc.org if you share your thoughts privately with us.  We’d greatly appreciate any comments BY THIS FRIDAY, JUNE 20, 2014, as we’re trying to move ahead with this topic area soon.

Many thanks!


UPDATE: We’ve had a couple of suggestions coming in already:

Please do keep them coming!

Video: IPv6 Security Myths and Reality by Chris Grundemann (RIPE 68)

What is the reality behind IPv6 security?  What is different (or not) about IPv6 vs IPv4 in terms of security?  What are some of the common myths about IPv6 security?  At the recent RIPE 68 conference in Warsaw, Poland, our Chris Grundemann spoke about common beliefs about IPv6 security and what people should really be thinking about.  His talk, “Security in an IPv6 World: Myth & Reality” is now available for viewing from the RIPE 68 site.  His slides are also available for download.

Chris Grundemann at RIPE68When you are done watching, you may want to check out our page on IPv6 security resources to learn more about how you can secure your installation of IPv6.  And if you don’t have IPv6 in your network yet, what are you waiting for?

 

Watch LIVE NOW – IPv6 Security Session Out of LACNIC 21

lacnic21-promohomeInterested to learn more about IPv6 security? Our Chris Grundemann will be speaking about “Security In An IPv6 World” at LACNIC 21 in Cancun in just a few minutes.  He is the second speaker in a session that is scheduled to start at 9:30am local time (which is 10:30 US EDT and 14:30 UTC)… which is pretty much right now!  You can view the session live at:

http://on.mediastre.am/lacnic

You can view the live stream in Spanish, Portuguese or English… although Chris will be speaking in English! :-)

Chris will also be speaking about the Deploy360 Programme tomorrow, May 7, 2014, at 9:05am local time (14:05 UTC).  (You can read more about what Chris is doing at LACNIC 21 this week.)

Our colleague Mat Ford will be speaking on Friday at 9:15-9:30am local time (14:15-14:30 UTC) about our routing resilience survey.

You can see the full agenda for LACNIC 21 at their website.

New IETF Mailing List To Discuss Privacy and Confidentiality of DNS

IETF LogoHow can we better protect the privacy and confidentiality of DNS queries? While DNSSEC protects the integrity of answers coming back from DNS (i.e. ensuring they aren’t modified in transit), what can be done to protect the confidentiality and privacy of information retrieved from DNS?  Particularly against the kind of pervasive monitoring and large-scale network sniffing we’ve become aware of?

We mentioned previously that at IETF 89 this month in London there was the “Encryption of DNS requests for confidentiality” (DNSE) BOF looking at these topics.  There was vigorous discussion during that BOF and then at the DNSOP working group meeting.  That large amount of interest has now sparked the creation of a new mailing list for all those interested in participating.  This “dns-privacy” list is public and open to anyone to subscribe:

List address: dns-privacy@ietf.org
To subscribe: https://www.ietf.org/mailman/listinfo/dns-privacy
Archive: http://www.ietf.org/mail-archive/web/dns-privacy/

As you can see from the mailing list archive, there is already some discussion underway.  If you want some background the Internet drafts draft-bortzmeyer-dnsop-dns-privacy and draft-koch-perpass-dns-confidentiality may be useful.

While this doesn’t specifically related to the DNSSEC topic we cover here on Deploy360, it is part of the same overall space of “making DNS more secure” and so I thought it would be useful to point people to this new list.

Working together as an industry and community, we can make DNS more secure!  Please do join in and help out.

RFC 7123 – Security Implications of IPv6 on IPv4 Networks

What are the security issues around IPv6 support and IPv6 transition mechanisms on an IPv4-only network?  Could the unplanned and perhaps even unknown support of IPv6 by operating systems introduce additional security concerns into an enterprise network?

In an Informational RFC 7123 published in February 2014, Fernando Gont and Will Liu explore the security implications of native IPv6 support and also of IPv6 tunneling mechanisms.  They walk through the different transition mechanisms, explain potential security issues and outline ways to potentially mitigate the security concerns.  The document is available at:

http://tools.ietf.org/html/rfc7123

The introduction of the document gives a taste of what the rest of the document covers:

Most general-purpose operating systems implement and enable native IPv6 [RFC2460] support and a number of transition/coexistence technologies by default. Support of IPv6 by all nodes is intended to become best current practice [RFC6540]. Some enterprise networks might, however, choose to delay active use of IPv6.

This document describes operational practices to prevent security exposure in enterprise networks resulting from unplanned use of IPv6 on such networks. This document is only applicable to enterprise networks: networks where the network operator is not providing a general-purpose internet, but rather a business-specific network. The solutions proposed here are not practical for home networks, nor are they appropriate for provider networks such as ISPs, mobile providers, WiFi hotspot providers, or any other public internet service.

In scenarios in which IPv6-enabled devices are deployed on enterprise networks that are intended to be IPv4-only, native IPv6 support and/or IPv6 transition/coexistence technologies could be leveraged by local or remote attackers for a number of (illegitimate) purposes. For example,

  • A Network Intrusion Detection System (NIDS) might be prepared to detect attack patterns for IPv4 traffic, but might be unable to detect the same attack patterns when a transition/coexistence technology is leveraged for that purpose.
  • An IPv4 firewall might enforce a specific security policy in IPv4, but might be unable to enforce the same policy in IPv6.
  • A NIDS or firewall might support both IPv4 and IPv6, but might not be configured to enforce on IPv6 traffic the same controls/policies it enforces on IPv4 traffic.
  • Some transition/coexistence mechanisms could cause an internal host with otherwise limited IPv4 connectivity to become globally reachable over IPv6, therefore resulting in increased (and possibly unexpected) host exposure.
  • IPv6 support could, either inadvertently or as a result of a deliberate attack, result in Virtual Private Network (VPN) traffic leaks if IPv6-unaware VPN software is employed by dual-stacked hosts.

In general, most of the aforementioned security implications can be mitigated by enforcing security controls on native IPv6 traffic and on IPv4-tunneled IPv6 traffic. Among such controls, is the enforcement of filtering policies to block undesirable traffic. While IPv6 widespread/global IPv6 deployment has been slower than expected, it is nevertheless happening; and thus, filtering IPv6 traffic (whether native or transition/coexistence) to mitigate IPv6 security implications on IPv4 networks should (generally) only be considered as a temporary measure until IPv6 is deployed.

Weekend Project: Join the XMPP “Security Test Day” today to test DNSSEC / DANE

XMPP logoIf you have a bit of time today, February 22, 2014, and want to help an effort aimed at making the Internet more secure, the XMPP Standards Foundation (XSF) is holding their second “Security Test Day” today.  The goal is to encrypt all traffic between servers and clients on the public network of XMPP servers. (Note that some of you may be more familiar with XMPP as its original name of “Jabber”.) This is all laid out in their manifesto for ubiquitous encryption on the XMPP network.

The connection to the work we are doing here at the Deploy360 Programme is that many of the XMPP servers have DNSSEC-signed domains and many are implementing DANE to secure the usage of TLS/SSL certificates in both server-to-server and client-to-server communication.  The XSF provides guidance on securing DNS via DNSSEC for XMPP servers and the IM Observatory provides two lists of interest:

It is outstanding to see the number of servers that have implemented both DNSSEC and DANE!  

Anyway, if you have an XMPP server, or want to set one up, today is a test day when the XMPP community is working on encrypting all their communication.  Visit their “Second Security Test Day” post to understand more about how you can participate.

This is great work that will definitely help make part of the Internet more secure. If you have time to help today, it would be great!

Slides: Security In An IPv6 World – Myth & Reality

What are the myths about IPv6 security?  What is the reality? How secure is IPv6 really?  What new security advantages does it offer? What should IT system administrators be thinking about with regard to security as they move into an IPv6 world?

In a talk to the South Asian Network Operators Group (SANOG) today, our Chris Grundemann discussed these questions and many more in a talk titled “Security In An IPv6 World – Myth & Reality“.  His slides are now online for viewing:

If a recording of the presentation becomes available we’ll update this post with more information.

UPDATE: Chris’s slides are now available as a PDF download.

Deploy360@IETF88: Day 3 – Perpass, IPv6 Operations and Operational Security

IETF LogoOn Day 3 of IETF88 our focus is again on IPv6 as well as the overall topic of hardening the security of the Internet.  The first sessions we’re primarily tracking is the IPv6 Operations (V6OPS) which has a whole range of documents under consideration relating to IPv6 addressing. The second session is Operational Security (OPSEC) where there are two drafts related to IPv6 security.

On a broader topic, we’ll be watching the IETF 88 Technical Plenary focused on “Hardening The Internet” and then the “Perpass” working group coming up after that.

My earlier posts about DNSSEC sessions and IPv6 sessions at IETF 88 explain in more detail what we’ll be watching.

Information about the four sessions today, including the links for the audio streams, the slides and the Jabber chat rooms, is:

For these sessions and all the others, the “tools-style agenda” for IETF 88 provides many helpful links for remote participants.

If you’d like to meet with the Deploy360 team here at IETF88, please see our post about where we’ll be at IETF88.

2 Asterisk Security Vulnerabilities Could Lead To Remote Crashes

Asterisk logoThe great folks on Digium’s security team published two security advisories this week that could lead to remote crashes of an Asterisk server.

The first, AST-2013-004, Remote Crash From Late Arriving SIP ACK With SDP, has this description:

A remotely exploitable crash vulnerability exists in the SIP channel driver if an ACK with SDP is received after the channel has been terminated. The handling code incorrectly assumes that the channel will always be present.

The second, AST-2013-005, Remote Crash when Invalid SDP is sent in SIP Request, has this description:

A remotely exploitable crash vulnerability exists in the SIP channel driver if an invalid SDP is sent in a SIP request that defines media descriptions before connection information. The handling code incorrectly attempts to reference the socket address information even though that information has not yet been set.

My one critique of the security advisories is that they don’t contain any “mitigating circumstances” that explain the circumstances under which the vulnerabilities could be exploited. For instance, it would seem from reading the documents that at least in the first case there would need to be a successful SIP connection established first – and then ended – before the packet could be received that would cause the crash. Unfortunately I don’t personally know Asterisk’s internals well enough to comment on that.

Regardless, the fix here is to upgrade to the latest versions of Asterisk as documented in the security advisories.

Kudos to the Digium folks for issuing these advisories and continuing their clear process of letting people know about security within Asterisk.