转载

CI工具一周课程Day 5：防御措施和其他

欢迎来到CI工具一周教程的第五天。我们将在这一个系列教程中讨论CI工具的安全问题。

第一天 - Jenkins(和Hudson) 第二天 - TeamCity 第三天 - Go和CruiseControl 第四天 - 常见问题集合及利用 第五天 - 防御措施和讨论其他一些事情

第五天也是本系列教程的最后一天，我们首先讨论如何抵御针对CI工具及其用户的攻击，然后聊聊CI工具开发者对于这些安全问题的回应，最后回顾下由CI工具导致的安全事件和之前的一些工作。

下面我们先从如何防御开始讲起。

针对管理员或用户的防御

1、主节点上不能运行构建代理或解释器。如果你默认安装了CI工具，一定要对能够在主节点上使用代理的项目或构建进行严格的控制。如果因为一些特殊需求的确要在主节点上启用代理，那么请尝试一切手段消除这个需求。

2、限制配置构建所需的权限。扪心自问，我们是否真的需要为一个项目一个用户提供本地管理员账号在所有的解释或代理机器上。

3、确保所有的代理都是统一整体给项目使用的。任何一个项目都不应该能随意使用代理。

· Jenkins： NodeLabel Parameter插件和 Job Restrictions插件

· TeamCity： Agent Pools

· Go： Environments

4、确保管理员Web控制台和控制面板的安全

· 确保针对管理员用户启用认证措施并对密码复杂度进行强制要求，即使工具只在内网使用。

· 启用HTTPS。

· 对所有的活动目录进行整合统一要求身份认证。如果工具已经暴露在互联网中，请先权衡利弊。

5、确保所有用户不使用自己的用户名作为密码

6、尽量不要把工具暴露在互联网中(除非你想向全世界展示你的开发人员是如何在日志中留下敏感数据的)。所有人使用VPN？(你也许会喜欢类似像Jenkins的'Google or OpenID login'这种的插件)

7、确保即使是匿名用户也不应该拥有读权限

8、请专业的渗透测试团队对你的CI工具进行渗透测试

针对工具开发人员的防御

1、强制执行密码策略(包括复杂度、有效期和登录失败后需要验证码等)。

2、必须明确告知用户在主节点上安装了代理，并不在安装包中提供代理的安装。如果用户在主节点上安装了代理必须用红色标明警告。

3、请不要在主节点或其他任何地方以明文形式存储凭证和密钥。

4、假设你的用户完全不了解安全，并确保至少默认安装时具有一定的安全性。恕我直言，大部分用户都是冲着“即装即用”来使用工具的，你会发现他们基本都是以默认配置进行安装的。例如：

· TeamCity默认安装时启用了身份认证，为什么Jenkins和Go就不能一样启用？ · Go默认不会在主节点上安装代理，为什么Jenkins和TeamCity就不能这样做？

5、尽可能使得工具在Windows上不要以系统或者管理员权限运行。

开发者对于安全问题汇报的回应

客气点说，CI工具的开发者对于那些关于安全问题汇报的反应我不是很满意。让我们来看些例子。

2014年8月，我发出博文描述Jenkins是如何被利用的。尽管我没有汇报给Jenkins官方(因为没有漏洞)，但有人还是提交给了Jenkins的问题追踪系统： https://issues.jenkins-ci.org/browse/JENKINS-24513

随后得到的官方回复：

1、回应：“这只是一些记录在案的东西” 状态：未完成

2、回应：“这一点都不明显”，因为它没有被记录过

其他人汇报的问题： http://www.th3r3p0.com/vulns/jenkins/jenkinsVuln.html

1、我们承认Jenkins的管理员具有可以直接读取用户凭证的权限，但我们信任管理员用户。

2、但是管理员就应该具有管理员权限

有人将第三天的教程放到了Google Group上面： https://groups.google.com/forum/#!topic/go-cd/TK9hzjO_CsA

下面是一些有趣的讨论：

1、“出于一些显然易见的原因，这肯定是一个坏主意”；

2、“如果考虑渗透测试的话，我喜欢能更彻底一些，考虑更多其他的攻击方式”。

在我结束欧洲黑帽大会的演讲后，我看到了一位TeamCity开发者(不愿透露姓名)的评论：

“通常安全性配置比较繁琐，所以默认配置不应该被认为是安全的”。对于这样的回复，引用其他人的评论“请重视安全”。

建议：如何处理那些报告或没有报告的安全问题

亲爱的$Vendor，我知道当你们听到有人说你们的软件有问题时是非常难受的，特别是这些问题来自于互联网中那些可能完全不了解你的代码或工具的人。我知道你们面对很多的问题需求修复，不过，我还是希望你们能尝试以下几点：

1、“游戏直到拿到管理员权限为止”这是90年代的事了，向前看，尽量尝试减小漏洞横向传播以及后期利用的可能。 2、在一次强调，默认安全配置是大多数人的选择。 3、不要忽视安全问题的汇报，如果你忽视，那么问题会一直存在。 4、好好完善文档！ 5、并不是所有已报告或没报告的安全问题都是0day漏洞。像无需身份认证即可远程执行命令这种都属于安全问题，你们需要明白，很多的攻击事件都是由一些低等和中等的安全问题组合引起的。 6、跟我一起反复念，随机的攻击最致命，随机的攻击最致命，随机的攻击最致命...

在2015年的十月，我曾在推特上面同Go和TeamCity的一些员工有所交流，我同他们分享了我在BlackHat和DeepSec上关于CI工具安全的报告，并进行了一次不错(但没有任何结果)的讨论。

由CI工具导致的安全事件

1、JenKins项目组收到过多起可信的报告表明其是不安全的，恶意软件已经将公共Jenkins实例作为了目标。 https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2015-10-01

2、FaceBook运行一个无需身份认证的Jenkins实例。 http://blog.dewhurstsecurity.com/2014/12/09/how-i-hacked-facebook.html

3、我们受到了攻击。我们在这台机器上运行了一个(无需身份认证)的Jenkins实例。 https://plumbr.eu/blog/plumbr-blog/we-got-hacked

4、“LANDESK发现了由攻击者编译的源码文件及使用的构建服务器。”John说到。“我们已经知道了攻击者拖走了构建服务器和源码服务器中的数据…” http://www.krebsonsecurity.com/2015/11/breach-at-it-automation-firm-landesk/

之前的工作

https://goo.gl/9iTHmz

https://www.pentestgeek.com/penetration-testing/hacking-jenkins-servers-with-no-password/

http://www.labofapenetrationtester.com/2014/06/hacking-jenkins-servers.html

http://zeroknock.blogspot.in/2013/08/protect-your-software-development-web.html

我们没有讨论哪些内容？

1、针对主从节点之间通信的中间人攻击 2、源码及构建过程的安全性 3、Web应用相关的漏洞 4、内存溢出漏洞 5、日志程序相关问题

我想用句智语来结束这一周的教程 – 仅仅一颗枯树，如果着火了，会造成整个森林的大火，同样CI工具中一个配置的错误可能会摧毁整个企业网络。– Chanakya (350-275 BCE)

最后希望你喜欢这一周的教程。

*原文地址： labofapenetrationtester ，FB小编xiaix编译，转自须注明来自FreeBuf黑客与极客（FreeBuf.COM）

正文到此结束

所属分类：编程技术

本文标签： HTML http 测试黑客需求 VPN 编译 https 开发者代码企业服务器 jenkins UI 开发 web node 配置 Google REST 目录 windows 安装管理软件 2015 aix 安全 Facebook 插件 ACE 认证密钥漏洞实例 Word 源码互联网数据
版权声明： 本文为互联网转载文章，出处已在文章中说明(部分除外)。如果侵权，请联系本站长删除，谢谢。
本文海报： 生成海报一生成海报二

其他链接

关于本站

本站定位：个人技术类博客

本站作用：写博客、记日志、闲聊扯淡鼓捣技术。

问题交流

CI工具一周课程Day 5：防御措施和其他

下面是一些有趣的讨论：

热门推荐

相关文章

说给你听

本文目录

随机标签

书籍教程

近期评论

网站信息

其他链接

关于本站

问题交流