How I gained commit access to all Jenkins projects in 30 minutes…and how security warnings to the Homebrew team went unheeded since 2014
I recently read a great write-up by Eric Holmes on Jenkins issues at Homebrew project brew.sh:
https://medium.com/@vesirin/how-i-gained-commit-access-to-homebrew-in-30-minutes-2ae314df03ab
A few years back, someone referred me to Homebrew and brew.sh as a possible open source repository for use on MacOS. I performed a cursory review of the project and found numerous issues, which I emailed the security team about. Back in 2014, Homebrew was still relatively new and didn’t completely enforce HTTPS yet. When Let’s Encrypt became available, their security team still said there were “issues” in enforcing HTTPS for all web infrastructure. OK, so they were run by a few volunteers and their time was limited, which is understandable. So, I offered to help contribute, but my offers didn’t seem to get anywhere and there didn’t really seem to be anyone taking the lead on security issues even though they had some dedicated points of contact. I also had found other issues in hash verification of packages and ways to bypass that by blocking network connections or DNS that would then allow a downgrade attack to build from an unchecked source repo.
Fast forward to 2016, when I found some troubling issues in Jenkins. I attended a Jenkins meetup event and became connected with some developers at CloudBees, the parent company. I notified them of some major issues in Jenkins and that I could control their infrastructure. With such control, I could not only hijack the Jenkins project, but also any project that depended upon Jenkins: Homebrew, Apache, AngularJS, Debian, coreboot, CyanogenMod, Mozilla, UK Government, NASA, GitHub, FaceBook, Intuit, SalesForce, etc. The list is long and you can read more at the “Who is Using Jenkins?” link: https://wiki.jenkins.io/pages/viewpage.action?pageId=58001258
However, the Jenkins and CloudBees teams didn’t believe my reports and they fell on deaf ears. As any security researcher knows from experience, a response such as “that is impossible” usually means that it is in fact very possible, because the developers may be a bit overconfident. As such, I needed to prove the attack in a much more direct way to show I had control of the Jenkins developers’ assets. So I whipped up a PoC in a few minutes for remote code execution against Jenkins…and waited for the payload to ping back.
A few minutes later and I owned Jenkins and everyone using it.
https://github.com/daniel-beck
But alas, I am a whitehat, so I immediately reported the access and did not use this for anything nefarious. But would the bad guys do the same? Or would they silently introduce small changes in the project that can have large downstream impact on all CloudBees customers and Jenkins users?
In addition to Homebrew, I also contacted Debian and CyanogenMod / LineageOS about their Jenkins installs, which just *might* be vulnerable and have had RCE on them at some point ;) How good are their logs? The only way to find out is for them to review and check if they found any *anomalies* in recent times.
I’ll try to dig up some of my old notes that show Debian being vulnerable and the Homebrew API token being exposed for a long while if anyone on their security teams contact me directly.
