IPsec Vulnerabilities and Software Security Prediction
TA3M May 18, 2015 Javantea
During the talk, the slides will be available on the ResearchNet WiFi network. Simply direct your browser to the url in the upper right. Apologies for not encrypting the data. If you're concerned about man-in-the-middle, please use the signature to verify the authenticity of the tarball. In the upper left of each slide is my PGP key fingerprint. If you take this down, not only can you verify the authenticity of files and communications I provide, but you can also encrypt communcation to me. The paper isn't finished yet, so please wait patiently for the final draft.
Fair warning: If you are an employee of a federal, state, city, or county government, or if you carry a clearance I will be showing documents that you are not allowed to see. If you wish to become employed at such an agency, viewing this talk will make your life more difficult. This is a perfect time to leave because you will not be blowing your cover. If you are offended by coarse language, you are also invited to leave because I will not refrain from dropping the F-bomb when necessary.
IPsec-tools is vulnerable to a 0-day exploit that I am making available today. It is a null dereference crash, so it's a denial of service against the IKE daemon. You may gawk and say that it doesn't deserve a medium rating, but remember that IPsec is critical infrastructure and this attack requires two small UDP packets. This denial of service violates the premise that security is built upon. It is easily detectable if logs are turned on or if users disconnect and reconnect regularly. It may be possible to create an Intrusion Detection/Prevention (IDP) signature, but more likely you will have to run a honeypot to detect a sophisticated attacker. If you're running IPsec-tools, replace it sensibly as soon as possible. Do not replace it with Openswan or Freeswan and do not replace it with an old unpatched version of another IPsec implementation.
This talk is in two parts: IPsec Tools vulnerability and Software Security Prediction.
"Common Raccoon (Procyon lotor) in Northwest Indiana" by Dmytro S. - Own work. Licensed under Public Domain via Wikimedia Commons - http://commons.wikimedia.org/wiki/File:Common_Raccoon_(Procyon_lotor)in_Northwest_Indiana.jpg#/media/File:Common_Raccoon(Procyon_lotor)_in_Northwest_Indiana.jpg
IPsec is a piece of software that is often used for critical infrastructure. It modified the IP stack so that all layers below IP can be encrypted (TCP, UDP, etc) and even Layer 2 can be encrypted using a tunneling daemon. It's often described as a VPN and is used as part of a VPN, but don't confuse yourself about what IPsec is doing.
When the IKE daemon crashes, it may or may not be restarted.
If it is restarted, it gives the attacker as many attempts as they want to get the IKE daemon into the startup state. Result: unknown.
If it is not restarted, the keys do not get changed. When the IV gets repeated, the stream loses some confidentiality and integrity. Replay becomes easy. Result: possible compromise.
If the system decides that the two systems should no longer use IPsec, the system may revert back to IP silently. Result: possible complete compromise. If the system decides to instead stop sending packets to the affected system, this is a complete availability compromise.
When encryption is compromised, the layer below becomes available to the attacker.
IPsec was designed to run over public networks, thus attackers are there.
Man-in-the-middle is not theoretical. It is practical and exploitable on WiFi (road-warrior use-case), corporate networks (flat topology corporation use-case), server racks (DMZ/segmented use-case), and backbone routers (ISP use-case).
I am not trying to be alarmist. The odds of someone compromising your entire corporate network based on this vulnerability are low. It will take someone at least 4 hours to attempt to compromise your network based on this exploit. The NSA compromised an air-gapped network in Iran and destroyed centrifuges. If they want what you have, they can use this or five other things.
Lucky for us, people who use IPsec-tools are pretty vocal about it. IPsec-tools has a unique response signature, so you can write an NMap script to detect it with few or no false positives (many false negatives unfortunately I believe). If you run FreeBSD or NetBSD with IPsec, you are running IPsec-tools. If you are running pfSense, you are running IPsec-tools. I wasn't able to run NetBSD, FreeBSD, or pFSense, so these statements need to be tested. Who wants to e-mail all the authors? Not me.
to find a long list of people using IPsec-tools. Try downloading the Internet survey. Try getting a Pro account at Shodan. Also, nmap doesn't find vulnerable servers as easily as my exploit. I even have a non-harmful way of detecting IPsec-tools.
There are a large number of IPsec scanners currently scanning the whole IPv4 for IKE servers. What do you think they're up to? Some of them are just researching. Some of them are script kiddies. Some of them are spoofing their IP address. But my educated guess is that most of them have 0-day in hand and are exploiting every vulnerable VPN they come across. What evidence do I have to support my hypothesis? Only the packets that each of these are sending.
Hundreds. The reason I found this vulnerability is because I made the mistake of following someone's IPsec howto. Don't trust Howtos written ten years ago. Don't trust howtos written yesterday!
strongSwan, Libreswan, and OpenVPN have recently found bugs.
strongSwan has a maintainer and contributors. Libreswan also. OpenVPN as well.
Libreswan has development as recent as 12 days ago. strongSwan today. OpenVPN had development today.
OpenVPN has been trusted by dozens of security companies.
How many of these can be said of IPsec-tools? No recently found bugs, no maintainer, no development in years, and no self-respecting security company uses IPsec-tools. Or do they?
I am not here to give us a crystal ball or try to accurately predict the next month of Full-Disclosure. Instead of picking stocks, I am going to reveal a software security trend.
Today I provide a tool that will focus our efforts on replacing the bad actors of the software world and testing and fixing bugs in good software. If we decide not to fix these software that everyone uses, we will be worse off for it. Software is not a lemons' market like I have thought so many times before. It is a very complex market where some people know so much they burst at the seams trying to report all the vulnerabilities they find. Some people honestly know nothing and that's okay, so long as their choices are made based on other's expertise and enough data that we can make good decisions with.
Uninstall Windows. Uninstall Adobe Flash. Uninstall Java. I know a lot of people can't do that just yet. When you find the true name of a bad actor, it's important to add them to a list. We won't be glitter bombing these bad actors yet, instead we can start by creating systems that do not have their products installed. Do not put valuable data on systems that have their software installed. Do not type your valuable passwords into systems that have their software installed. This is hard. I know because I have tried it. If you find a solution that doesn't require users to expend enormous effort, please cite my paper.
Step 1: Create a metadata file for each package from your distro. Copy or link all metadata files into a directory. Put a directory listing into a file. Order the list of packages by number of systems that currently use that piece of software.
For starters, this is the code for Gentoo using eix. There are better ways to do this, but this is effective.
Now to get these in order of how many systems. Run the first command on many systems and name the output file differently for each system. Put all these files on one system and do the following:
Now we have a histogram that tells us which are the most important packages because they are installed on a lot of machines. For my four systems, 192 packages are on all 4, while 1102 are on 2 or more. This is out of 2328 packages. While even the smallest package can compromise a system, the ones that aren't used often can be pushed back and the ones that are used more often can be promoted. To use security data, we can use these two lines of code:
As you can plainly see, all of the major offenders are right up top. Don't get me wrong, these are people who have spent countless hours tirelessly searching for vulnerabilities and fixing them. They should be applauded. But we can learn from this which software needs the most work. For those that don't go above and beyond on their testing, their software should be blacklisted until they prove themselves.
Step 3: Once you filter the projects into maintained and unmaintained, start at the top of the unmaintained list and contact heavy users about possibly finding a maintainer.
Step 4: Once you filter the unmaintained projects into possibly maintained and needs to replaced, look for replacements for the project. If one exists, deprecate the project and let users know that a replacement exists. If users refuse to replace the project, let them know that they do it at their own risk and do not allow them to install it using your distro's package management. Instead provide a way for a user to download it manually and install it (like a Windows application). Use your security system to inform the user when they ask that the project is unmaintained.
Step 5: Require maintained projects to increase their security depending on their criticality. This is done by deciding the severity of a compromise of the system compared to date of the last vulnerability found. This will lower the value for projects that need security testing but will eventually decrease the time spent looking at projects that have good security from the get-go. Projects may decide to hide vulnerabilities to make their last bug found more distant, which means that when users report bugs in old software, this data can be integrated into this data rather than being lost in the bug tracker as just being fixed.
Step 6: Require security testing tools used on critical projects to be used against all similar projects (high and low importance projects). While this will uncover many low severity vulnerabilities and waste time, it will improve the overall quality of source code without requiring duplication of efforts.
The cost of looking for bugs is greatly outweighed by the benefit of testing these systems.
Step 7: Create a list of authors who have abandoned projects. Make sure that any project that they work on is treated more critically than it otherwise would be. This prevents serial offenders from contributing to a project during its maintenance phase, becoming the maintainer, and then abandoning it.
Step 8: Use smell test to determine whether a project is being tested as well as it should be. This includes running splint, pylint, and other noisy "bug finder" tools on the software as well as taking into account gripes from users about bugs that aren't being fixed. This type of transparent gripe factory will provide data for users decide whether a piece of software is in high development and shouldn't be used in production or whether it's a lemon, like OpenSSL. This will make it possible to predict security based on the trend of improving security without lemons or bad actors.
Aside: Bad Actors Never Think Of Themselves That Way
Bad actors usually think of themselves as the good guy. They are the main developer of a popular open source software project. They are a well paid developer of a major piece of software. They are the father of two wonderful children. They are the judge that makes hard choices because no one would otherwise. They are the entrepreneur who supplies people medication to people who are in severe pain.
Relativism and Utilitarianism are not a valid excuse for doing harm. A person who does harm consistently marks himself or herself as a bad actor. It is our job to name them and reduce harm.
If security was a trivial matter, we wouldn't need to think very big about it. We'd batten down the hatches and weather the storm. Instead, we're seeing thousands of medium and high severity vulnerabilities each year. I produce a 1-20 each year and I'm only spending a few hours here and there.
We sit on top of a wealth of knowledge. Our inaction causes us harm. Our action causes us harm. Don't worry, I have a plan. Instead of reactive security, we should reward those software projects whose proactive security projects find and fix bugs. If a bug is found in a piece of software with many eyes on it, why? We can't just pat them on the back every time they add a bug and then fix it. We want them to release the tools by which they tested their software. If there are no tools, there is no testing. If they haven't fuzzed, why in the world not? If they haven't run their software with Valgrind, why not? If they haven't run static analysis tools on it, why not? If the static analysis tool produced a ton of false positives, who is staking their reputation on that being true? Who is validating the results of the static analysis tool they use?
University Temple United Methodist Church (43rd & 15th)
I am Javantea and I do a lot of hacking, but my real passion is Nanotechnology. I've been studying for over a year and I am looking for peers. I am planning on taking the month of June off to do radio astronomy, so if I don't respond to your e-mails be patient.
Thanks to Ann, my friends, Neg9, Melody, Batman's Kitchen, the organizers of TA3M. To those who think critically and speak out: Keep it up!
courtesy Edward Snowden and Der Speigel http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html
That's why not.
