Jenkins is a popular target for penetration testers mainly because certain server configurations expose the Groovy Script Editor which, provided the proper payload, can lead to remote code execution on the server. More and more commonly though, this technique is working less and less.
Despite this, even if you don’t have access to the Groovy Script Editor, you still stand a decent chance of getting something valuable out of it. Jenkins tends to be a treasure trove of information in certain organizations, and it’s all too easy for a developer or operations team to leave something behind “just to get things done”.
A little background – Jenkins is an automation server for developers to automate the building of software, run tests on that software, etc. These “builds” that Jenkins runs, can contain things like the console output of the build process, (basically stdout of a bunch of commands and scripts), associated files in the form of “workspaces”, inherited environment variables, and much more.
Let’s talk about a couple of these:
Console Output
During a pentest, we found a Jenkins server with hundreds of “builds”, each containing a handy button on the left side called “Console Output”.
Intrigued, we clicked on it and saw what ended up being the literal stdout of the build process. Many of the builds’ console output we checked ended up being mostly useless, but some? Not so useless. A couple examples of what we’ve seen:
Curl/wget commands with plaintext creds to different services
Contents of certain automation scripts
Failed test cases containing SOAP requests & developer credentials
SSH private keys as part of a deployment script
Mysql client, JDBC connection strings, and sqlplus credentials
Interestingly, we saw that several instances of the exposed data were actually because some part of the build process failed, and data was exposed as error messages or stack traces. If the build succeeded properly, nobody may have known. This goes to show that failure conditions can be just as important, if not more than success conditions.
We found that the “Console Output” was in every build we came across and was a very reliable source of sensitive information.
Workspaces
Certain project builds are more complicated and require accompanying files to correctly build the project. They could be source code, private keys, certificate bundles, credentials, configs, or anything else. You can think of workspaces the same way you think of directory indexing on web servers.
Workspaces did not appear in as many builds as the console output did, but tended to contain even more sensitive information. A couple of things we found from workspaces:
“Protected” source code
Many web.config files containing DB connection details
.ssh folders with private keys & known hosts files
Client certificates & credentials for connecting to APIs
Included, but unused scripts containing hardcoded credentials
AWS deployment ID & secret keys
We found that workspaces tended to have a lot of data they didn’t need. After all, it’s easier to include a whole directory structure, than specifically say which directories are important or not.
Environment Variables
It’s well-known within the developer community that including credentials in source code is a pretty big no-no. Despite this advice being often ignored, some developers follow the guidance of “include credentials and API keys as environment variables” which is better. Well, Jenkins can expose those too.
You can configure certain builds to inherit particular environment variables that the build can refer to during its creation process. Things we’ve seen from exposed environment variables:
Internal network information for where the build if being deployed
Credentials
Proxy settings
Paths, usernames, emails, and admin URLs
Tool Release
These techniques have been used to compromise multi-billion-dollar corporations and are incredibly useful in today’s application development landscape. If you come across a Jenkins server during a pentest, we highly recommend taking a look at the accessible internals. Unfortunately, grabbing all these pieces manually from the web interface can be tedious and a hassle. We are releasing Jenkins-Pillage to automatically gather this information more quickly and easily.