Cross-Build Injection attacks: how safe is your Java build?

Editor's Notes

• #2: Things I’d like to show:\n1) unknown dangers in software builds\n2) what you can do to improve build security\nThis talk is not about security flaws in libraries (CSRF or SQL injection etc), but rather deliberate injection of harmful code during the build process\n
• #3: \n
• #4: Tell the story about the self-modifying C-compiler. Compile perfectly legal code, and get trojan horses in your output... Even CPU microcode could be rigged! \n
• #5: OpenSSH: OpenBSD’s port tool downloaded, compiled and installed tainted OpenSSH source code. Allowed hacker to connect with priviliges of installer\nSendmail: buildsystem was compromised, and trojan horse shipped with Sendmail distribution\n
• #6: Demo consists of compiling and running a plain Java class with Maven, with surprising results. The ‘attack’ is performed by introducing a malicious version of the maven-compiler-plugin.\n\nWe use Maven here, but the problems apply to any build tool that fetches dependencies from the internet.\n
• #7: We warn our parents not to download and run arbitrary binaries. Yet we do this very thing ourselves everytime we run a build.\n\nExplain what just happened. Cross-build injection is about attackers targeting your build to introduce malicious code (remote code execution attack: game over).\nThe Maven install is uncompromised, as is the javac. The problem is introduced by a malicious version of maven-compiler-plugin. So how can this end up in your build?\nSo how could this malicious version of the maven-compiler-plugin end up in our local repository?\n
• #8: Free service for community, first by Jason van Zyl, now Sonatype\n
• #9: Possible attack vectors because of http. Maven Central not https accessible (only for Sonatype customers)\nAnother, more extreme possibility: Maven Central itself compromised.\n
• #10: Term Crossbuild injection/XBI coined by Fortify in a whitepaper in 2007. Sounds like XSS/SQL injection.\nAnother, more extreme possibility: Maven Central itself compromised.\n
• #11: Term Crossbuild injection/XBI coined by Fortify in a whitepaper in 2007. Sounds like XSS/SQL injection.\nAnother, more extreme possibility: Maven Central itself compromised.\n
• #12: Using https prevents aforementioned attacks, but does nothing to ensure authenticity of dependency downloads per se. If Maven Central were somehow compromised, you wouldn’t know.\n\nThe alternative is not really an alternative: smaller selection of artifacts, and cannot withstand the load of Maven Central.\n\nOf course, you can also object how safe is https (Diginotar, Comodo). Security is always a continuum! (though this is pushing it...)\n
• #13: Most extreme case: shun automatic dependency management all together (not practical). Alternative: introduce local repo-manager. Either disconnected and managed by hand (again not practical, and how good is the vetting process?) or directly proxying other public repos.\n\nStill, same attack vectors apply, only attack surface decreased by downloading once into local managed repo once.\n
• #14: MD5/SHA-1 offers no authenticity check, only integrity. But since checksums are served from same http-repo as the binary, both can be replaced/faked. MD5/SHA-1 can be easily recalculated on malicious jars.\nStill, there’s no good reason to ignore checksum failures!\n
• #15: PGP has many uses, here we focus on creating signatures for artifacts. Private key of author is used to create signature. End-user can obtain corresponding public key to verify authenticity and integrity of artifact. Problems: where to get the key, and can you trust the key/signer?\n
• #16: Before library is synced to central, signature must be present and key distributed to Mit keyserver. Pom must be signed as well, it is equally important (otherwise adding transitive deps/repos would go undetected)\nSigning ensures both integrity (like checksums) and authenticity.\nMultiple keys because Maven Central filled by different contributors. Other systems like Windows/Apple update have it comparatively easy: they can use a single key because they control the client and all binaries that are pushed!\n
• #17: \n
• #18: PGP keys need to be in the keyring for succesful signature verification. Here example of manual key retrieval.\nNotice the warning though: even if the signature is valid, is it made by the person we think??\n
• #19: PGP keys need to be in the keyring for succesful signature verification. Here example of manual key retrieval.\nNotice the warning though: even if the signature is valid, is it made by the person we think??\n
• #20: PGP keys need to be in the keyring for succesful signature verification. Here example of manual key retrieval.\nNotice the warning though: even if the signature is valid, is it made by the person we think??\n
• #21: PGP keys need to be in the keyring for succesful signature verification. Here example of manual key retrieval.\nNotice the warning though: even if the signature is valid, is it made by the person we think??\n
• #22: So we have a way of obtaining the key, but how do we know that the key belongs to the stated identity? Hard problem, solved by PGP with the Web of Trust. You assign trust to a key based on ‘out-of-band’ communication (fingerprints can be used for this). Not practical, so there is a notion of transitive trust. Public keys can be signed by different people. If you already trust a person who has signed the key you’re interested, you automatically trust this other key. \n\n-> contrast with Certificate Authorities for SSL certificates: centralized vs. distributed trust.\n
• #23: -> Key signing party at Sonatype booth, get your web of trust started!\n\n
• #24: Here, I have a trusted key from a Sonatype developer in my keyring. Then, I instruct PGP to automatically retrieve the necessary key from the keyserver to verify the .asc signature. Since I have the trusted developer in my keyring (who signed the Sonatype release key), the Sonatype release key is transitively trusted. Hence, the signature is deemed good.\n
• #25: By now, you’re probably thinking to yourself: too much effort! Can’t this be automated? Unfortunately not using Maven itself.\nNexus Pro can download & check PGP checks automatically, and ban dependencies which have no PGP-sig or where check fails. Still, which keys do you trust automatically?! \n
• #26: Preventing XBI is one thing, but says nothing about the ultimate security of libs.\n\nThese measures are never enough by themselves, nor scalable, but offer another layer of defense to the systems security.\n
• #27: We’ve seen some technical approaches to authenticity/integrity, but the solutions can’t only be technical. Just because you didn’t write the code doesn’t mean you’re not ultimately responsible! Be aware of what is happening with your code and what you’re putting into your applications.\n
• #28: \n
• #29: Small recap: all repository based tools have to face this problem. Solution is part technical, part process. There is a serious awareness issue!\n\nSecurity is not binary: secure/unsecure. Nothing is 100% secure, but the default used in many organizations is definitely insecure as shown in this talk. Applying PGP signing/verification is not a panacea. It has associated costs, but also increases security and safety of software development. There are countless high-profile, high-value builds that are potentially vulnerable.\n\nAgain, everything discussed applies not just to Maven: Perl CPAN, .Net NuGet, Ruby Gems all have the same underlying dangers. ‘Software is eating the world’, and it’s our duty to ensure it is as secure as possible.\n
• #30: \n