The Java community was rocked by a major serialization bug in 2015 that affected nearly every Fortune 500 company, but many other bugs followed that year. Among the flurry of serialization vulnerabilities, I was amused to see this informative talk on exploiting serialization by Mattias Kaiser. His presentation also included several WebLogic exploits in the T3 protocol, a proprietary protocol, unique to WebLogic, that I hadn’t heard of since my days at BEA Systems.
Since XML is known to have risks associated with XXE, and YAML has the known risks listed above, many organizations have standardized on JSON as a safe way to do serialization.
But JSON is subject to these vulnerabilities, as I described above with the AirBnB situation. And, at DEF CON and Black Hat USA this year, there was an excellent talk by Alvaro Muñoz and Oleksandr Mirosh titled “Friday the 13th: JSON Attacks,” covering vulnerabilities in the use of JSON that should puncture any false sense of security in either Java or .NET.
What you can do
Knowing is half the battle. All languages have quirks that can result in unexpected evaluations of untrusted data. This comes not only from the language itself, but from frameworks incorporated into your application to enable faster or more elegant implementation. A typical application could have hundreds of third-party frameworks. These provide great power, but there is a risk that the power can be turned on the application itself.
In light of this situation, keep these best practices in mind:
- Learn your language. “Wat” talks are not only entertaining (and disheartening), but educational.
- Know your frameworks. In that elegantly expressed logic using the framework, what is the framework actually doing?
- Use a static code analyzer such as Brakeman for Ruby to avoid common mistakes.
- Keep up to date with packages. Use a tool to check which of your packages have vulnerabilities, and upgrade ASAP. Once a vulnerability has been publicized, script kiddies are locked and loaded—scanning as many websites as possible for these vulnerabilities.
- Test and inspect. Ensure you have expert pen testers to evaluate your software for vulnerabilities.
- Design with security in mind. Security cannot be an afterthought. The implementation of your system should be done with a security focus.
- Make security everyone’s job, not just people with “security” in their titles. Security is not just a technology aspect, but a cultural aspect of how things get done.
Most people do much, if not all, of the above, yet compromises keep happening. Why? Because there is an underinvestment in a layered defense.
Layer your defenses
Vulnerabilities will happen, despite everything we do to prevent them. We must accept this fact and use a defense-in-depth approach that incorporates runtime monitoring for threats and automated response to stop attacks before damage is done or information is lost.
Defense-in-depth, or layered defense, is simply having more than one layer, so that if something fails, you have other mechanisms in place to mitigate the breach. Many companies rely on testing and scanning tools to ensure that they have no vulnerabilities. No such assurance is possible. Those tools provide only a single line of defense that is done pre-production. Defense-in-production is just as important.
Without runtime defenses, attackers have free rein to exfiltrate valuable data, causing lasting and catastrophic damage. Zero-day exploits are shopped on the dark web and by state actors constantly. The best approach is to assume that vulnerabilities will be exploited sooner or later. When they are, make sure you have fail-safe mechanisms in place to minimize what a malicious actor can accomplish.