CI tools weekly course Day 5: defense measures and others

CI tools weekly course Day 5: defense measures and others

Welcome to the fifth day of the CI tool's one-week tutorial. We will discuss the security of CI tools in this series of tutorials.
Day 1-Jenkins (and Hudson)
Day 2-TeamCity
Day 3-Go and CruiseControl
Day 4-FAQ collection and utilization
Day 5-defense measures and discussion of other things
The fifth day is the last day of this series of tutorials. We will first discuss how to defend against attacks against CI tools and their users, and then talk about the responses of CI Tool developers to these security issues, finally, let's review the security events caused by CI tools and some previous work.
Let's start with how to defend.
Defense against administrators or users
1. The build proxy or interpreter cannot be run on the master node. If you have installed the CI tool by default, you must strictly control the project or build that can use proxy on the master node. If you want to enable proxy on the master node because of some special requirements, try all means to eliminate this requirement.
2. Restrict the permissions required for configuration building. Ask ourselves whether we really need to provide a local administrator account for a project user on all the explanations or proxies.
3. Ensure that all agents are used by the project as a whole. No proxy can be used for any project.
· Jenkins: NodeLabel Parameter plug-in and Job Restrictions plug-in
· TeamCity: Agent Pools
· Go: Environments
4. ensure the security of the Administrator Web console and Control Panel
· Enable authentication measures for administrator users and enforce password complexity requirements, even if the tool is only used on the Intranet.
· Enable HTTPS.
· Identity authentication is required for the integration of all active directories. If the tool has been exposed to the Internet, weigh the advantages and disadvantages first.
5. Make sure that all users do not use their usernames as passwords
6. Try not to expose tools to the Internet (unless you want to show the world how your developers leave sensitive data in logs ). All users use VPN? (You may like plug-ins like Jenkins's 'Google or OpenID login)
7. Make sure that even anonymous users do not have the read permission.
8. Ask a professional penetration testing team to perform penetration testing on your CI tools.
Defense Against Tool developers
1. Enforce password policies (including complexity, validity period, and verification code required after logon failure ).
2. You must explicitly inform the user that the agent is installed on the master node, and do not install the agent in the installation package. If you have installed a proxy on the master node, the alarm must be marked in red.
3. Do not store creden。 and keys in plaintext on the master node or any other place.
4. Assume that your users do not know security at all, and make sure that at least security is ensured during the default installation. To put it bluntly, most users use the tool for "out-of-the-box installation" and you will find that they are basically installed with the default configuration. For example:
· When TeamCity is installed by default, identity authentication is enabled. Why cannot Jenkins be enabled the same as Go?
· By default, Go does not install proxies on the master node. Why can't Jenkins and TeamCity do this?
5. Try to prevent the tool from running as a system or administrator on Windows.
Developers' response to security issues
Politely speaking, I am not very satisfied with the responses to the CI tool's reports on security issues. Let's look at some examples.
In August 2014, I posted a blog post describing how Jenkins was used. Although I did not report it to Jenkins official (because there is no vulnerability), Someone submitted it to Jenkins's problem Tracking System: https://issues.jenkins-ci.org/browse/JENKINS-24513
The following official reply:
1. Response: "This is just something recorded" status: unfinished
2. Response: "This is not obvious" because it has not been recorded
Problem reported by others: http://www.th3r3p0.com/vulns/jenkins/jenkinsVuln.html
1. We acknowledge that the Jenkins Administrator has the permission to directly read user creden。, but we trust the administrator user.
2. But the administrator should have the administrator privilege.
Someone put the third day of the tutorial on Google Group: https://groups.google.com/forum! Topic/go-cd/TK9hzjO_CsA
Below are some interesting discussions:
1. "For some obvious reasons, this must be a bad idea ";
2. "If you consider penetration testing, I like to be more thorough and consider other attack methods ".
After my speech at the European Black Hat conference, I saw a comment from a TeamCity developer (not to be called:
"Generally, security configuration is cumbersome, so the default configuration should not be considered safe ". For such a reply, the comments "please pay attention to security" from other people are quoted ".
Suggestion: how to handle security issues reported or not reported
Dear $ Vendor, I know it is very uncomfortable when you hear someone say your software has problems, in particular, these problems come from people on the Internet who may not understand your code or tools at all. I know that you are faced with a lot of problems, but I still hope you can try the following:
1. "The game has been granted administrator permissions until it was completed in 1990s." look forward and try to minimize the possibility of horizontal vulnerability propagation and later exploitation.
2. At one time, the default security configuration is the choice of most people.
3. Do not ignore the report on security issues. If you ignore the report, the problem will always exist.
4. Complete the documents!
5. Not all security issues reported or not reported are zero-day vulnerabilities. Remote command execution without authentication is a security issue. You need to understand that many attack events are caused by combinations of low and moderate security issues.
6. read it over and over again with me. random attacks are the most fatal, random attacks are the most fatal, and random attacks are the most critical...
In 2015 of October, I had some conversations with Go and TeamCity employees on Twitter. I shared with them my reports on CI tool security at BlackHat and DeepSec, we had a good discussion (but there was no result.
Security events caused by CI tools
1. The JenKins project team received a large number of credible reports that it was not secure and malware had targeted public Jenkins instances. Https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2015-10-01
2. FaceBook runs a Jenkins instance without authentication. Http://blog.dewhurstsecurity.com/2014/12/09/how-i-hacked-facebook.html
3. We were attacked. We run a Jenkins instance on this machine (without authentication. Https://plumbr.eu/blog/plumbr-blog/we-got-hacked
4. "LANDESK has discovered the source code files compiled by attackers and the building servers used ." John said. "We already know that attackers have dragged data from the build server and source code server ..." Http://www.krebsonsecurity.com/2015/11/breach-at-it-automation-firm-landesk/

Previous work
Https://goo.gl/9iTHmzhttps://www.pentestgeek.com/penetration-testing/hacking-jenkins-servers-with-no-password/http://www.labofapenetrationtester.com/2014/06/hacking-jenkins-servers.htmlhttp://zeroknock.blogspot.in/2013/08/protect-your-software-development-web.html
What did we not discuss?
1. Man-in-the-middle attacks against communications between master and slave nodes
2. Security of source code and construction process
3. Web application Vulnerabilities
4. Memory Overflow Vulnerability
5. Log program Problems
I would like to end this week's tutorial in a wise word-only one dead tree. If it catches fire, it will cause a fire in the entire forest, A configuration error in the Same CI tool may destroy the entire enterprise network. -Chanakya (350-275 BCE)
Finally, I hope you like this week's tutorials.