Deserialization Vulnerability Confirmed in Nexmo 3.4.0 SDK
Nexmo has confirmed that their 3.4.0 SDK contained the Jackson-databind vulnerability that we announced earlier this week as widespread amongst SaaS SDKs.
The deserialization vulnerability can be escalated into remote control execution (RCE) by triggering a gadget chain of either certain versions of Java or Spring. This makes the vulnerability particularly tricky for traditional security systems to catch, because it is contextual: The exposure comes from how various libraries interact with each other, not just known CVEs.
We thank Nexmo for their rapid response to our disclosure. They have confirmed that vulnerability is patched in 3.4.1. As disclosed earlier this week, SendGrid and GoodData SDKs were also impacted and we continue to work through the process of responsible disclosure with numerous other SaaS SDK vendors. For further details, an exploit proof-of-concept and video examples, please see our our original blog post:
“Java Deserialization Vulnerability Found to be Widespread Across SaaS Vendor SDKs”
How ShiftLeft Can Help
ShiftLeft can help with the three core problems with this type of vulnerability:
Contextual Vulnerabilities: The contextual severity of this deserialization vulnerability dramatically increases, based on how your application interacts with/leverages other libraries. Managing CVEs across all your libraries is challenging on its own. Confirming the contextual usage of each CVE, versus all the components that make up your application/service, is extremely tedious and time-consuming.
Whack-a-Mole Patching: The whack-a-mole nature of constantly needing to patch is operationally inefficient and inherently insecure. As we have seen, new vulnerable classes can be added to the blacklist hourly. It is likely that more classes will be added before the whitelist approach can be update in 3.x. Hence, even with the latest update, there may still be pre-zero day classes that can be exploited.
Dependency on SDK Providers: Even if you’ve patched all of the Jackson-databind libraries in your custom code, you may still be vulnerably through the SDKs your service leverages. As you will see, as more vendors update their SDKs, there is a difference in speed at which each one patches. As a downstream consumer of the SDK, short of ripping-and-replacing, Security teams don’t have many options prior to the release of the patch from their vendor.
ShiftLeft solves these problems: First, and how we initially identified this issue, is that our Semantic Property Graph analyzes how the application works and extracts “Security DNA” from source code. As part of this process it understands how each component (your custom code, open source libraries and 3rd party SDKs) interact with each other. Hence, automatically identifying contextual vulnerabilities is right smack in our wheelhouse.
Second, we provide runtime protection for any vulnerability that the Semantic Property Graph identifies so you can avoid whack-a-mole all together. Of course, we advise that you ultimately update to the latest versions of any vulnerable SDKs in a timely manner. However, instantly patching isn’t always realistic, and, because both future updates to the jackson-databind blacklist are likely, and your SDK vendor may not update in a timely manner, you probably have exposure, even when you are able to patch instantly.
ShiftLeft’s runtime protection is extracted from your application’s security DNA, so it is customized and defined by exactly what your application is vulnerable. Hence, your application is protected from the universe of possible pre-zero-day-whack-a-mole blacklist/patch updates so you’re no longer dependent on your SDK vendor to update their services and you can update your custom code in accordance with your schedule, rather than in a panic.
Please see screenshots and videos below for how ShiftLeft protects your application from this contextual deserialization vulnerability.
Deserialization Vulnerability Confirmed in Nexmo 3.4.0 SDK was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Andrew Fife. Read the original post at: https://blog.shiftleft.io/deserialization-vulnerability-confirmed-in-nexmo-3-4-0-sdk-4487c9fde494?source=rss----86a4f941c7da---4
