Monday, May 11, 2015

Vulnerability disclosure the good and the ugly

By Cesar Cerrudo @cesarcer

I can't believe I continue to write about disclosure problems. More than a decade ago, I started disclosing vulnerabilities to vendors and working with them to develop fixes. Since then, I have reported hundreds of vulnerabilities. I often think I have seen everything, and yet, I continue to be surprised over and over again. I wrote a related blog post a year and a half ago (Vulnerability bureaucracy: Unchanged after 12 years), and I will continue to write about disclosure problems until it's no longer needed.

Everything is becoming digital. Vendors are producing software for the first time or with very little experience, and many have no security knowledge. As a result, insecure software is being deployed worldwide. The Internet of Things (IoT), industrial devices and industrial systems (SCADA/ICS), Smart City technology, automobile systems, and so on are insecure and getting worse instead of better.

Besides lacking of security knowledge, many vendors do not know how to deal with vulnerability reports. They don't know what to do when an individual researcher or company privately discloses a vulnerability to them, how to properly communicate the problem, or how to fix it. Many vendors haven't planned for security patches. Basically, they never considered the possibility of a latent security flaw. This creates many of the problems the research community commonly faces.

When IOActive recently disclosed vulnerabilities in CyberLock products, we faced problems, including threats from CyberLock’s lawyers related to the Digital Millennium Copyright Act (DMCA). CyberLock’s response is a very good example of a vendor that does not know how to properly deal with vulnerability reports.

On the other hand, we had a completely different experience when we recently reported vulnerabilities to Lenovo. Lenovo’s response was very professional and collaborative. They even publicly acknowledged our collaboration:

"Lenovo’s development and security teams worked directly with IOActive regarding their System Update vulnerability findings, and we value their expertise in identifying and responsibly reporting them."

IOActive approached both cases in the same way, but with two completely different reactions and results.

We always try to contact the affected vendor through a variety of channels and offer our collaboration to ensure a fix is in place before we disclose our research to the public. We invest a lot of time and resources to helping vendors understand the vulnerabilities we find. We have calls with developers and managers, test their fixes, and so on, all for free without expecting anything in return. We do not propose nor discuss business opportunities; our only motive is to see that the vulnerabilities get fixed. We have a great track record; we’ve reported dozens of vulnerabilities and collaborated with many vendors and CERTs too.

When a vendor is nonresponsive, we feel that the best solution is usually to disclose the vulnerability to the public. We do this as a last resort, as no vendor patch or solution will be available in such a case. We do not want to be complicit in hiding a flaw. Letting people know can force the vendor to address the vulnerability.

Dealing with vulnerability reports shouldn't be this difficult. I'm going to give some advice, based on my experience, to help companies avoid vulnerability disclosure problems and improve the security of their products:
  • Clearly display a contact email for vulnerability reports on the company/product website
  • Continuously monitor that email address and instantly acknowledge when you get a vulnerability report
  • Agree on response procedures including regular timeframes for updating status information after receiving the report
  • Always be collaborative with the researcher/company, even if you don't like the reporter
  • Always thank the researcher/company for the report, even if you don't like the reporter
  • Ask the reporter for help if needed, and work together with the reporter to find better solutions
  • Agree on a time for releasing a fix
  • Agree on a time for publicly disclosing the vulnerability
  • Release the fix on time and alert customers
That's it! Not so difficult. Any company that produces software should follow these simple guidelines at a minimum.

It comes down to this: If you produce software, consider the possibility that your product will have security vulnerabilities and plan accordingly. You will do yourself a big favor, save money, and possibly save your company’s reputation too.

Tuesday, March 24, 2015

Lawsuit counterproductive for automotive industry

By Chris Valasek @nudehaberdasher

It came to my attention that there is a lawsuit attempting to seek damages against automakers revolving around their cars being hackable ( The lawsuit cites Dr. Charlie Miller’s and my work several times, along with several other researchers who have been involved in automotive security research. 

I’d like to be the first to say that I think this lawsuit is unfortunate and subverts the spirit of our research. Charlie and I approached our work with the end goals of determining if technologically advanced cars could be controlled with CAN messages and informing the public of our findings. Obviously, we found this to be true and were surprised at how much could be manipulated with network messages. We learned so much about automobiles, their communications, and their associated physical actions. 

Our intent was never to insinuate deliberate negligence on the part of the manufacturers. Instead, like most security researchers, we wanted to push the boundaries of what was thought to be possible and have fun doing it. While I do believe there is risk associated with vehicle connectivity, I think that a lawsuit can only be harmful as it has the potential to take funds away from what is really important:  securing the modern vehicle. I think any money automobile manufacturers must spend on legal fees would be more wisely spent on researching and developing automotive intrusion detection/prevention systems.

The automotive industry is not sitting idly by, but constantly working to improve the security of their past, present, and future vehicles. Security isn’t something that changes overnight, especially in the case of automobiles, which take even longer since there are both physical and software elements to be tested. Offensive security researchers will always be ahead of the people trying to formulate defenses, but that does not mean the defenders are not doing anything. 

While our goals were public awareness and industry change, we did not want change to stem from the possible exploitation of public fears. Our hope was that by showing what is possible, we could work with the people who make the products we use and love on an everyday basis to improve vehicle security. 

- cv

Tuesday, January 27, 2015

Life in the Fast Lane

By Chris Valasek @nudehaberdasher

Hi Internet Friends, 

Chris Valasek here. You may remember me from educational films such as “Two Minus Three Equals Negative Fun”. If you have not heard, IOActive officially launched our Vehicle Security Service offering.

I’ve received several questions about the service and plan to answer them and many more during a webinar I am hosting on February 5, 2015 at 11 AM EST

Some of the main talking points include: 
  • Why dedicate an entire service offering to vehicles and transportation?
  • A brief history of vehicle security research and why it has been relatively scarce
  • Why we believe that protecting vehicles and their supporting systems is of the utmost importance
  • IOActive’s goals for our Vehicle Security Service offering
Additionally, I’ll make sure to save sufficient time for Q&A to field your questions. I’d love to get as many questions as possible, so don’t be shy. 
I look forward to you participation in the webinar on February 5, 2015 11 AM EST. 

- cv

Tuesday, November 18, 2014

Die Laughing from a Billion Laughs

By Fernando Arnaboldi

Recursion is the process of repeating items in a self-similar way, and that’s what the XML Entity Expansion (XEE)[1] is about: a small string is referenced a huge number of times. 

Technology standards sometimes include features that affect the security of applications. Amit Klein found in 2002 that XML entities could be used to make parsers consume an unlimited amount of resources and then crash, which is called a billion laughs attack. When the XML parser tries to resolve, the external entities that are included cause the application to start consuming all the available memory until the process crashes. 

Thursday, November 6, 2014

ELF Parsing Bugs by Example with Melkor Fuzzer

By Alejandro Hernandez @nitr0usmx

(Extract from white paper at )

Too often the development community continues to blindly trust the metadata in Executable and Linking Format (ELF) files. In this paper, Alejandro Hernández walks you through the testing process for seven applications and reveals the bugs that he found. He performed the tests using Melkor, a file format fuzzer he wrote specifically for ELF files.

Thursday, October 23, 2014

Bad Crypto 101

By Yvan Janssens

This post is part of a series about bad cryptography usage . We all rely heavily on cryptographic algorithms for data confidentiality and integrity, and although most commonly used algorithms are secure, they need to be used carefully and correctly. Just as holding a hammer backwards won't yield the expected result, using cryptography badly won't yield the expected results either.

To refresh my Android skillset, I decided to take apart a few Android applications that offer to encrypt personal files and protect them from prying eyes. I headed off to the Google Play Store and downloaded the first free application it recommended to me. I decided to only consider free applications, since most end users would prefer a cheap (free) solution compared to a paid one.

Thursday, October 16, 2014

Vicious POODLE Finally Kills SSL

By Robert Zigweid

The poodle must be the most vicious dog, because it has killed SSL. 

POODLE is the latest in a rather lengthy string of vulnerabilities in SSL (Secure Socket Layer) and a more recent protocol, TLS (Transport layer Security). Both protocols secure data that is being sent between applications to prevent eavesdropping, tampering, and message forgery

POODLE (Padding Oracle On Downgraded Legacy Encryption) rings the death knell for our 18-year-old friend SSL version 3.0 (SSLv3), because at this point, there is no truly safe way to continue using it.  

Google announced Tuesday that its researchers had discovered POODLE. The announcement came amid rumors about the researchers’ security advisory white paper which details the vulnerability, which was circulating internally.