Main image of article Third-Party Developer Libraries Found to Be Widely Insecure
For many developers and engineers, third-party libraries and SDKs are critical for building products. It’s often hard to ship a product without this kind of outside support, but there’s increasing evidence you may want to adjust how you use it. Felix Krause, founder of Fastlane, discovered third-party SDKs are vulnerable to man-in-the-middle (MITM) attacks, with over 600 libraries – including AWS – affected. His research centered on iOS SDKs, but there’s no reason to think these issues are limited to Apple’s mobile platform. Krause says at least 31 percent of "the most popular closed-source" iOS SDKs are vulnerable, along with over 600 CocoaPods libraries. The MITM vulnerability relies on ARP, or Address Resolution Protocol. As Krause describes it, ARP attempts to pair MAC addresses with corresponding IP addresses to send packets of data. A device with the appropriate IP address confirms itself, and data is sent. With interference – a MITM – hackers can dupe devices into sending the packets to a different address altogether. The vulnerability also relies on forwarding to an HTTP address rather than HTTPS, which isn’t difficult; hackers just switch in a remote server. As Krause notes, anyone who has connected to an open WiFi network is at risk (i.e., those who have gone to conferences or coffee shops and attempted to use the free WiFi). In the video below, Krause details just how serious this exploit can be: In an interesting twist, the research shows that closed-source SDKs are worse than open source. “When an SDK is closed-source, it’s much harder for you to verify the integrity of the dependency,” writes Krause. “Based on the numbers… it is clear that in addition to not being able to dive into the source code for closed source SDKs you also have a much higher risk of being attacked.” This underscores a point we’ve made before about third-party libraries. When something isn’t yours, it can be difficult to affect change. Many (possibly most) developers who use third-party libraries simply plug-and-play, dropping them into their own apps without any manipulation. This new research suggests it may be best to avoid this practice. Forking and fixing – or sending pull requests to the master – may be more work, but it goes a long way toward closing gaps that may exist. Similarly, external libraries should be checked into version control when possible for auditing purposes. Unfortunately, this research is another example of how we just don’t know enough about digital security. As always, developers and engineers are responsible for the code they ship.