Tuesday, December 1, 2015

Week of Continuous Intrusion Tools - Day 2 - TeamCity

Welcome to the Day 2 of the Week of Continuous Intrusion Tools. I am doing a series of posts which explore the attack surface of CI Tools.

To read posts of other days refer the table below:

Day 1 - Jenkins (and Hudson) (Click Here)
Day 2 - TeamCity
Day 3 - Go and CruiseControl (Click Here)
Day 4 - Common Abuse Set, Lateral Movement and Post Exploitation (Click Here)
Day 5 - Defense and other discussion (Click Here)

Day 2 is dedicated to TeamCity. It can be found here. Some of the security issues with TeamCity are:
  • Registration of new users is enabled by default. Registered user gets Project Developer privileges.
  • No password complexity/policy for user passwords.
  • Runs with SYSTEM or high privilege user on Windows (most configs settle with an admin account). 
  • Guest login could be enabled. In fact, so many public instances has it enabled. 

The information available with public instances of TeamCity is mind boggling! I saw web portal credentials, database credentials, hidden services and code repositories and much more on some public instances. We may not require compromising TeamCity to get access to intellectual property of an organization, much could be gathered from the instance. 

But to access the Operating System and do more fun stuff we must have a Project Administrator privilege (non-admin). This user role has the capability of Adding/Editing build steps.

Fortunately, TeamCity has some protection against Brute Force attacks. It locks a user for one minute after five consecutive wrong login attempts within a minute. Also, it sends the password in encrypted form in transit. Still, since it does not enforce any password policy on user passwords, it is still possible with reasonable success to brute force it. 

To enumerate users, we can either go through [TeamCityUrl]/viewLog.html?buildId=1 and iterate through it to look for user who triggered the build or a better way is to use its API and iterate through [TeamCityUrl]/app/rest/builds/id:1 and look for "user" tag. There are generally enough manually triggered builds to enumerate a good number of users.
After building a list of users, we can use the API to brute force credentials. TeamCity API allows access using Basic Auth :) We can use Burp Intruder to launch a brute force attack against TeamCity (or any other tool of choice). To use Intruder against Basic Auth see this tutorial. Success looks like this:
Keep in mind that TeamCity blocks a user for one minute after five consecutive login attempts, using delay is advised. We should keep trying unless access to a Project Administrator is achieved.

Having the privileges to Configure builds we can do interesting stuff.

Executing Commands

As a Project Administrator we can add Build Steps. A Build Step with PowerShell runner is an excellent choice on a Windows machine. (On *nix machines Shell commands and scripts could be executed)
And when the Project is run:
Sweet! We have SYSTEM privileges.

Now, lets use some PowerShell hackery to improve the result of the above. In a restricted environment, we may have only limited options for a connect back. Lets use Invoke-PoshRatHttps.ps1 from Nishang. Thanks to Casey, this shell makes a valid HTTPS connection between a target and a listener. Also, its client part is quite small and we just need to execute one line of PowerShell on the target.
On the attacker's machine, just the Invoke-PoshRatHttps listener needs to be started. As soon as the build is triggered:
Awesome! Encrypted traffic between the attacker and the client. I don't stress using PowerShell for nothing :)

Now, if we have the capability of configuring builds on master, few more interesting things can be done.

Super User

TeamCity has a special user called Super User "which allows you to access the server UI with System Administrator permissions if you do not remember the credentials or need to fix authentication-related settings". Documentation about it is here. To login as a Super User we must have the Super User authentication token which could be found in the teamcity-server.log file. In a default installation on Windows, the file is located in the C:\TeamCity\logs\ directory. Following simple PowerShell command could be used to read the token from a Windows master:
After getting the token, it could either be used with a blank username at the TeamCity login page or at [TeamCityUrl]/login.html?super=1. This is how a Super User login looks like:
Great! Interestingly, a Super User token is regenerated only when the TeamCity Server service is restarted. Also, there can be any number of Super User logins simultaneously. It means once you get access to a Super User token, it could provide a reasonable long access to the TeamCity instance.

Fun Fact: We can lock out Super User for one minute by attempting to login with a blank username and password on TeamCity login page. Though I have not tried it, a Super User may be locked for longer duration by scripting the login attempts.

SSH Keys in clear

TeamCity allows users to upload SSH keys for projects. These keys, which are the private ones, are stored in clear on the master! Read the documentation here.Whats worse is we can read the keys if we have the ability to configure builds on the master. The keys are stored in the [TeamCity Data Directory]\config\projects\[project]\pluginData\ssh_keys directory. We can get the Data Directory from the teamcity-server.log file.
Bingo! May I remind you that we are in 2015 :)

Google Dorks

Use the below Google Dorks to spot public instances of TeamCity:
Instances with Guest login enabled: intitle:"Projects - TeamCity"
Instances which allow Registration of new account: "intitle:Register a new account – TeamCity"

TeamCity instances have very sensitive information. The below screenshots are just examples, there is a gold mine out there.

In the below screenshot, the build log contained url of a product under development along with the credentials to access it with admin privileges.
The one below had credentials for the database administrator sa account password. The public IP address of the database was visible in another build log. 

Unserialization Vulnerability

As far as I know, TeamCity does not use the affected library.

Video Demonstration

A quick video demonstration of attacks discussed above:

Hope you enjoyed the post! Feedback and comments are welcome :)

To support my research, join me for a two days training "PowerShell for Penetration Testers" at:

BlackHat, Asia (March 29-30th, 2016) - https://www.blackhat.com/asia-16/training/powershell-for-penetration-testers.html

HITB, Amsterdam (May 24-25th, 2016) - http://conference.hitb.org/hitbsecconf2016ams/sessions/2-day-training-3-powershell-for-penetration-testers/

No comments:

Post a Comment