Joe Klein guests on The Average Guy podcast – Preparing for the Next Generation Internet: IPv6 and the Internet of Things
Recently Joe was a guest on The Average Guy podcast along with Christian Johnson, discussing the Next Generation Internet, IPv6, and the Internet of Things.
Catch the podcast here:
For those of you not familiar with Healthy Paranoia, it is an excellent podcast on PacketPushers, hosted by the wonderful and brilliant Mrs Y. Check out some of the shows on which Joe had the pleasure of being a guest:
Healthy Paranoia Show 13: To CISSP, or Not to CISSP takes on the question of “the profound problem of security certifications.
Healthy Paranoia Show 9: Live and Let Scada discusses Scada and ICS security issues.
Healthy Paranoia Show 4: IPv6 Security Smackdown offers up an amusing and informative take on security issues and common vulnerabilities of IPv6.
Joe Klein was interviewed along with Roger G. Johnston and Jacob Williams on the Internet of Things:
Network World today published an article by Bruce Sinclair on IPv6 security risks (https://www.networkworld.com/news/tech/2013/110413-ipv6-security-275583.html?hpg1=bn), based on a survey of the 95,000 community members at the gogo6 discussion forum (http://www.gogo6.com/forum).
So what are the Top 6 IPv6 Security Risks you ask?
1. Lack of Training/Education – Based on the DHS Framework Categories (http://csrc.nist.gov/nice/Sept2011-workshop/presentations/Tuesday/Tues_Framework_Maxson_and_Homeyer.pdf) was created based on the category type and user type to help provide a career path for professionals and provide a framework for hiring. IPv6 needs seven unique flavors of IPv6 training to address the requirements of: Securely Provision; Analyze; Operate and Maintain; Support; Operate and Collect; Protect and Defend; and Investigate. Currently all training I have reviewed is focused on partially educating the “Protect and Defend” and “Operate and Maintain” communities, and not fully focused towards addressing the unique concerns and needs.
2. Security device bypass and unfiltered IPv6 and tunneled traffic – This is a hard one, as we have so many tunnels, and by default tunnels are never officially provisioned and approved, but more likely setup to fix a point problem. In support of the transition of users from native IPv4 network, through dual stack and finally to the native IPv6 networks, we now have over 24 methods applied, some for a reason and other accidently. Sadly the vast majority of Intrusion Detection Systems (IDS), Intrusion Prevention System (IPS), Deep Packet Inspect (DPI) and Next Generation Firewalls (NGF) have little if any ability to detect or stop these tunnels.
Stay tuned to this blog, future book and classes for more details on how to detect and bypass existing security controls using IPv6.
3. Lack of IPv6 support at ISPs and Vendors – for over 12 years I have been banging the drum to security vendors and ISPs about support of IPv6. Just within the last two years we have seen support from both, but not at the level which will mitigate the security risk. Based on the capital expense (CAPX) of changing our current technology and the lack of procurement policies requiring all new product insertions over the last few years to support IPv6, they are budgeting to integrate systems into the environment which in many cases leads to security and connection problems for their customers. Both the ISP’s and Vendors have been claiming for years that customers are not asking for it, but in many cases no systems exist to document these requests.
4. Congruence of security policies in v4 & v6 – Each time I talk to a customer, speak at a conference or teach a class, I am surprised at the number of people that apply their knowledge of IPv4, and very limited knowledge of IPv6 as justification for not making policy changes. In support of the assessment, auditors and security management, I have begun collecting changes in policies required to support IPv6 and eventually change the policies when IPv4 is no longer used. Some changes are simple, but others require a re-think of the architecture and processes.
As a reference we will use the National Institute of Standards and Technology (NIST) Special Publication 800-54 revision 4 (csrc.nist.gov/publications/drafts/800-53–rev4/sp800-53–rev4-ipd.pdf), to provide some of the details needed for security IPv6 networks to be integrated into the people, processes and technology across the lifecycle of all systems.
Example 1: “AT-3 ROLE-BASED SECURITY TRAINING”, requires among other things, the procurement manager to take security training, and in this context training on procurement of IPv6 devices, and some sample language to use. In addition,
Example 2: “PL-7 SECURITY CONCEPT OF OPERATIONS”, requires the people developing the security CONOPS for information systems to update the existing document, and create an all new document with the knowledge of IPv6 being the network layer of these systems.
Example 3: “IR-5 INCIDENT MONITORING”, requires that organizations track and document information system security incidents. Is the field that contains the IP address fixed? Does it support IPv6 sized addresses?
In short, IPv6 requires many large and small changes to integrate this new network protocol into the security of an organization.
5. Bugs in new code – Bugs can enter code by way of the protocol specification, business decisions on what should be included, programming libraries, Integrated Development Environment (IDE), meshing old code with new code, direct coding mistakes, or interface oversights. With IPv4, it has been over 43 years and we are still finding problems. Last year, I wrote a one-day class on common coding bugs and processes of migrating to IPv6 network securely. With only limited interest, I had one group engage me on the training, and as a result discovered a code bug when using a dual stack proxy in front of an IPv4 only Windows 2003 server with IIS.
6. Absence of NAT – This protocol is not a security feature; if it were then why did IETF create multiple specifications on how to bypass this feature? Understanding how to securely architect an IPv6 network is different than architecting an IPv4 network. Yes, many vendors want to tell you they are the same, because they are generally unaware of the agile security methods and do not have products in that space. I spoke about this at Internet Security Days 2013, only a month ago about the changes required and the benefits of easier management and far more immunity to attack. You can find the slides at this link: https://scientifichooligan.files.wordpress.com/2012/02/isd2013-shifting-security-paradigm-joe-klein-v4.pdf
I am scheduled to speak on the last day of gogoNet Live 4 (http://gogonetlive.com/) on the topic of tunnels, based on the research I am doing for the book and class. In addition, I will be demonstrating a tunnel detection tool, which will help manage the use of tunnels in a network.
If you are attending the event, please introduce yourself, but if you are unable to attend, you might be interested in the Virtual pass (http://gogonetlive.com/gogonetlive-vpass.asp). In any case it will be great to see old friends and talk about IPv6 and the Internet of Things security.
Last night I spoke to the SRA security team at one of the scheduled Security Nights, with the topic of “IPv6 Hacking – Fear the Big Packets”. I have added a section on “RECON via Stupid Human Tricks”, about methods used to number the router and endpoint devices which simplifies the ability to quickly scan and attack these devices. It seems many organizations implementing IPv6 are making it easier for both the network and system administrators as well as the attackers. I guess they will continue mapping the IPv4 constrained addressing model onto the abundant IPv6 resources.
It has been some time since I posted to the blog, and I figured that some of the readers might be interested to know that I am working on a book and upgrading the Training class on “Hacking and Defending IPv6”.
My current task is enumerating through all of the tunnels protocols: how to set them up, abuse them, detect the abuse, and identify security controls and processes to mitigate the risks long term. The process is slow, but I am getting through it. To amplify the work, I am testing on Windows 8, Ubuntu 13.10, Open BSD, and an attack took kit called Kali.
The book is scheduled to be published next summer, and the original class I have been teaching since 2008 will be fully rewritten and available in March 2014. The current plan is to begin teaching the class at security, network and hacker conferences starting in April. If you have suggestions on where I should teach the class, please contact me.