Security Notes

Credentials

Use strong credentials, and use them carefully.

We recommend using strong credentials not only for your TeamCity server, but also for all other services that are involved in a build or that your software requires in production.

Make especially sure to keep your credentials out of:

• Repositories, such as GitHub and GitLab.

• Environment variables, as they are often logged or shared with third-party monitoring systems.

• The build log — make sure you don't randomly log sensitive information.

• If you are using versioned settings (in Kotlin DSL or XML format), never store your credentials in your configuration files. Instead, use tokens.

TeamCity users with administrative permissions should have complex passwords.

Store secure data using parameters with the "password" type.

To store passwords or other secure data in the TeamCity settings, you are strongly advised to use the typed parameters. This will make sure that sensitive values never appear in the web UI and are masked with asterisks in the build log. Make sure passwords are stored as parameters with the password type.

Use a secret management tool.

Although password parameters are masked in the UI, encrypted at REST, and protected from being exposed in the build log as plain text, this often does not provide a high enough level of security.

You may consider using a tool like HashiCorp Vault, which lets you manage and rotate all the sensitive credentials you'll be using in a build and which integrates well with TeamCity.

Permissions

Use predefined roles.

Out of the box, TeamCity offers several predefined roles:

• System Administrator

• Project Administrator

• Project Developer

• Project Viewer

You can create user groups that match your organizational structure and assign the above roles to those groups. Then add your users to the respective groups, granting them the lowest level of privileges they need for their day-to-day work.

It is also strongly recommended that you create new roles with additional permissions, instead of immediately assigning the Project Administrator role to anyone who needs slightly more privileges. (This does not work if you disable per-project permissions.)

Use per-project authorization.

To tighten security even more, you can also make use of per-project authorization. This way, your developers could, for example, have access only to the compilation part of your build chain, while devops could access and run the deployment part.

Do not enable Guest Login.

By default, logging into TeamCity anonymously is disabled. Make sure not to enable it on the production TeamCity server instances that are exposed to the internet, unless you want external users to be able to see all your builds and the associated log files/artifacts. If enabled, user roles should be carefully reviewed for guests and the All Users group.

Create a separate user for REST requests.

If you access the TeamCity REST API from an external script or program, we recommend that you create a separate user with a limited number of permissions for it. It would also be wise to create autoexpiring access tokens, instead of using the username/passwords to access the API.

Restrict deployment build permissions.

Make sure that your deployment build chains do not allow personal builds. Limit the number of developers who can trigger those builds, and use a separate pool of clean agents for those builds.

Thoroughly manage permissions granted to users and user groups.

Note the following nuances:

• Users who can change the code that is used in the builds run by TeamCity (including committers in any branches/pull requests if they are built on TeamCity):

  • can do everything the system user, under whom the TeamCity agent is running, can do; have access to OS resources and other applications installed on the agent machines where their builds can run.

  • can access and change source code of other projects built on the same agent, modify the TeamCity agent code, publish any files as artifacts for the builds run on the agent (which means the files can be then displayed in the TeamCity web UI and expose web vulnerabilities or can be used in other builds), and so on.

  • can impersonate a TeamCity agent (run a new agent looking the same to the TeamCity server).

  • can do everything that users with the "View build configuration settings" permission for all the projects on the server can do (see below).

  • can retrieve settings of the build configurations where the builds are run, including the values of the password fields.

  • can download artifacts from any build on the server.

• Users with the "View build configuration settings" permission (by default, the Project Developer role) can view all the projects on the server.

• Users with the "Edit project" permission (the "Project Administrator" TeamCity role by default) in one project, by changing settings can retrieve artifacts and trigger builds from any build configuration they have only the view permission for (TW-39209).

• Users with the "Change server settings" permission (the "System Administrator" TeamCity role by default): It is assumed that the users also have access to the computer on which the TeamCity server is running under the user account used to run the server process. Thus, the users can get full access to the machine under that OS user account: browse file system, change files, run arbitrary commands, and so on.

• The TeamCity server computer administrators: have full access to TeamCity stored data and can affect TeamCity executed processes. Passwords that are necessary to authenticate in external systems (like VCS, issue trackers, and so on) are stored in a scrambled form in TeamCity Data Directory and can also be stored in the database. However, the values are only scrambled, which means they can be retrieved by any user who has access to the server file system or database.

• Users who have read access to the TeamCity server logs (TeamCity server home directory) can escalate their access to the TeamCity server administrator.

• Users who have read access to <TeamCity Data Directory> can access all the settings on the server, including configured passwords.

• Users who have read access to the build artifacts in <TeamCity Data Directory>/system/artifacts get the same permissions as users with the "View build runtime parameters and data" permission (in particular, with access to the values of all the password parameters used in the build).

• TeamCity agent computer administrators: same as "users who can change code that is used in the builds run by TeamCity".

• When storing settings in VCS is enabled:

  • Any user who can access the settings' repository (including users with "View file content" permission for the build configurations using the same VCS root) can see the settings and retrieve the actual passwords based on their stored scrambled form.

  • Any user who can modify settings in VCS for a single build configuration built on the server, via changing settings can retrieve artifacts and trigger builds from any build configuration they have only the view permission for (TW-39192).

  • Users who can customize build configuration settings on a per-build basis (for example, one who can run personal builds when versioned settings are set to "use settings from VCS") via changing settings in a build can retrieve artifacts and trigger builds from any build configuration they have only view permission for (TW-46065).

Build Agents

Run clean production builds.

We recommend enforcing clean checkout for your production builds to prevent tampering with the source code on an agent.

Use disposable, network-protected build agents.

Note that the builds running on the same build agent are not isolated, and they can potentially affect each other, which might give an opportunity to perform malicious actions.
If possible, try using disposable, one-off build agents. The shorter the agent's lifetime, the smaller the chance of a compromise. Also make sure to use OS-dependent firewall rules to disable incoming network access to your cloud agents.

Use agent pools for different projects.

In general, it is recommended to distribute projects among agents, so that one TeamCity agent would not run builds of several projects whose developers and administrators should not get access to each other's projects.

If you run several agents on the same machine and do not enable clean checkout, beware that compromised agents or untrusted projects could potentially modify source code in the "neighbor" working directories. To mitigate this risk, consider running just one agent per machine and use different agent pools for different (private/public) projects. Make sure that the "Default" agent pool has no agents as a project can be assigned to the Default pool after a certain reconfiguration (that is when there is no other pool the project is assigned to).

Control permissions of the OS user who runs a TeamCity agent.

It is advised to run TeamCity agents under an OS account with only a necessary set of permissions.

Version Control

Use a recent version of Git.

Make sure to always use the latest stable Operating System and Git version on your build agents. Update regularly.

Properly manage your SSH keys.

If you are using SSH keys to access your repositories, do not store them on your build agents. Instead, use TeamCity's SSH key management to upload them to the TeamCity server.

Instead of disabling known hosts checks, make sure to maintain an .ssh/known_hosts file on the server and build agents for every host you are connecting to.

Use a dedicated VCS user.

If you are not using advanced features like Kotlin DSL or, in general, if you don't need to commit to your repository as part of your build process, we recommend keeping a dedicated VCS user without write permissions to connect to your repositories.

Build History and Logs

Keep your build history.

Keep your build history and logs for a longer period of time, especially for builds doing critical deployments, by specifying corresponding clean-up rules for your project. Also, make sure to not grant the "remove build" permissions to developers, as this could prevent the archiving.

Both measures may help with tracing malicious activities, even if they happened a long time ago.

Collect build agent logs in an archive and put them under a properly secured storage.

Integrations

Be careful when building public pull requests.

If you build pull requests from unknown users or users outside your organization, be aware that pull requests could contain malicious code that would be run on your build agent.

Either disallow building public pull requests, or use separated, isolated, throw-away agents. TeamCity also offers a built-in health report, which detects and reports pull request builds.

Be aware of the security implications when using versioned settings.

When you use versioned settings (Kotlin DSL, XML) and those settings are placed in the same repository as the source code, any malicious developer can potentially modify and leak project configuration settings. This could be done, for example, by adding a build step that prints out passwords or sends them somewhere as a file.

As an option, you could use a separate repository that only a limited number of users can commit to for your versioned settings.

Heartbleed, ShellShock

TeamCity distributions provided by JetBrains do not contain software/libraries and do not use technologies affected by Heart bleed and Shell shock vulnerabilities. What might still need assessment is the specific TeamCity installation implementation which might use the components behind those provided/recommended by JetBrains and which can be vulnerable to the mentioned exploits.

POODLE

If you have configured an HTTPS access to the TeamCity server, inspect the solution used for HTTPS as that might be affected (for example, Tomcat seems to be affected). At this point, none of the TeamCity distributions include HTTPS access by default and investigating/eliminating HTTPS-related vulnerability is out of scope of TeamCity.

Depending on the settings used, TeamCity server (and agent) can establish HTTPS connections to other servers (for example, Subversion). Depending on the server settings, those connections might fall back to using SSL 3.0 protocol. The recommended solution is not TeamCity-specific and it is to disable SSLv3 on the target SSL-server side.

GHOST

CVE-2015-0235 vulnerability is found in the glibc library which is not directly used by the TeamCity code. It is used by the Java/JRE used by TeamCity under *nix platforms. As Java is not bundled with TeamCity Unix distributions (Docker images use a newer glibc version), you should apply the security measures recommended by the vendor of the Java you use. At this time there are no related Java-specific security advisories released, so updating the OS should be enough to eliminate the risk of the vulnerability exploitation.

FREAK

CVE-2015-0204 vulnerability is found in the OpenSSL implementation. TeamCity does not bundle any parts of the OpenSSL product and so is not vulnerable. You might still need to review the environment in which the TeamCity server and agents are set up, as well as the tools installed in addition to TeamCity for possible vulnerability mitigation steps.

Apache Struts

CVE-2017-5638 affects Jakarta Multipart parser in Apache Struts. CVE-2016-1181 also affects multipart requests processing in some older versions of Apache Struts.

TeamCity bundles IntelliJ IDEA which contains JARs from both Apache Struts 1.x and Apache Struts 2.x. These JARs are only used by IntelliJ IDEA Struts plugin when IntelliJ IDEA collects inspections for a project on a TeamCity agent.

Under no circumstances these versions of Apache Struts are used to handle any HTTP requests. Thus neither TeamCity server, nor TeamCity agent are affected by these vulnerabilities.