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:


2 comments:

  1. Some relevant conversation from their mailing list:
    https://groups.google.com/forum/#!topic/go-cd/TK9hzjO_CsA

    ReplyDelete

Note: Only a member of this blog may post a comment.