Attack_Code_Part(2)
Attack Code PART 2 - Common Develop Service
Codebase
CodeBase 在这里我分为两类: 一类是 Git 这种 版本控制, 这种比较常见 也是基本都存在的. 第二种是 package library, 有些公司具有类似的 Maven 包管理中心. 对编写的代码和依赖做更为严格的控制和统一的管理.
Version Control Platform
当你写完代码, 进行提交, 代码就会被存到 GIT SVN 一类的版本控制软件或者代码托管平台.
这里也是渗透测试人员可以仔细搜寻的脆弱点或者敏感区域.
常见的有 Github 等公开平台的 私有项目 或者 Gitlab 自建 ( GItea 等 ) 甚至是云厂商的 一站式 Devops 平台的 Code Space.
这里稍微提一下隔壁腾讯云的 Coding 平台.
是腾讯云的 一站式 Devops 平台中的一环, 也是其中的代码托管平台. 他在 e.coding.net.
这是企业的代码资产中最最核心的部分, 针对这些东西的利用和漏洞也是数不胜数, 尤其是 GITLAB, 所以现代企业往往都会在内网建立这类的代码托管. 并且正确的安全策略应该是禁止外网访问并且加上强验证强访问控制的, 并且需要注意安全性问题, 及时提供补丁. 比如 2FA.
针对代码本身的审计, 硬编码, 成熟的配置文件 这些属于是最基本最基本的攻击面. 就不重复了.
Git 中也会存有大量的注释 or 文档信息. (很多开发都那么干) 这些暴露出来的额外信息也是需要检查的. 比如说 某些 IP 下具有数据库资产, 哪些是测试环境, 哪些是是开发环境, 在 Gitlab snippets 和 WIKI 可能会留存一些开发或者维护信息之类的东西. (当然大多数情况是不会去使用的)
同样 Git log 中的历史也为攻击者表明了开发者个人信息. 或许在社会工程学钓鱼等等方面会做到更近一步的利用
此外 拿下代码控制平台, 对对方代码进行审计和调试, 常常也是安全人员喜欢做的事情之一. 这意味着, 如果有更多的地方运用了这些代码 (或是组件), 安全人员可能会对这些漏洞进行复用, 再拿下更多的目标, 获取到更多的代码, 形成一个正反馈的循环.
Package Library
较为大型的公司常常会有属于自己的包管理工具. 之前看到有报告说可以进行下毒. 不过我并不是很懂这里应该怎么去 Do Some Evil. (思路不够开阔)
并且我只是遇到过一次而已. 当时遇到的是一个 JAVA 的 MAVEN 私服, 类似于 Nexus 这种. 而且很多厂商其实到现在为止还是属于在使用 Java 的样子. 可能算是比较常见?
不懂 Java
CICD
CICD 这个玩意也算是很常见的重点目标了.
为什么?
因为他能执行 shell 代码 或者脚本, 而且正常跑起来的时候需要的权限要的还不少. 少说是个能运行命令的 Root. 或者具有集群创建变更权限的 Root.
想通这点. 接下来具体情况就就是看滥用它就是了. 主要的滥用集中在他的自动构建和自动部署上, 修改他的流程脚本或者是脚本控制台来执行命令/代码. 然后复用返回的信息.
因此这些东西的洞一般是不会少的. 大佬们都是瞄着的. 再看看 Jenkins 更新多勤快, 你就明白了.
最最离谱的是, 我之前安装了一个 Jenkins 才过半天, 就是一个 DDOS 洞的更新.
Jenkins
Jenkins 这已经属于是行业标准了, 基本说到 CICD 就是它了. 以至于在基本的信息收集的阶段, 基本都能扫出以 jenkins 开头的域名.
Jenkins 相关的滥用非常的多 可以看看 Hacktricks - Jenkins 从枚举信息的滥用开始到具体的漏洞他都有相关的说明. 这个文档确实写的不错.
就是 Jenkins 这玩意属实是不太轻量. Java 嘛总是有 Java 的样子.
当然现在比较可以的还有 Webhook (Go写的那个), 我觉得还可以. 而且我的某些系统也在用. 这个目前来看问题不是很大. 轻量 但是功能不是很多, 很多时候需要写 Shell.
Drone
比较新的东西是 Drone 无人机. 以 container 作为特色的 CICD, 除了脚本之类的内容, 往往还会伴随着还有不少 Kubernetes 和 docker 的综合利用. 这一部分将在下一部分继续说明.
Online Testing
测试服务也是开发过程中比较重要的一个环节. 而且往往为了和真实环境更加类似, 都会存在公网可以访问的在线测试的网站. 一般会有诸如 test 字眼出现在域名中. 这部分我想通过 代码审计测试 与 在线测试集群 两个部分. 主要是第二部分 Online Testing (Clusters)
Code Audit
这种服务我没咋个遇到过. 就看到过一次 Sonatype 安装在系统中, 并且作为 CICD 中间的一个自动测试服务运行, 似乎是进行静态代码检查和测试. (这里没有深入研究, 先挖一个坑.)
看介绍和 DEMO 说可以保证一定的代码安全性和质量. 有些厂商会用这种东西保证代码的可靠性.
当然这玩意也是能执行命令(代码)的. https://help.sonatype.com/repomanager3/integrations/rest-and-integration-api/script-api 甚至在官方文档开头还是能看到 Unsafe 的.
不过基本很少有看到有代码静态检测的. 撑死一个扫描和一个代码格式化 lint 一类的
Online Testing (Clusters)
当然我知道很多开发都是开在线灵车的. :- )
比如 “我”
在线测试是就是一个在开发过程中很容易被忽略的点, 但又是安全人员可以去关注的点. 当一个团队快要进行上线发布之前的几个版本(或者从一开始)就进行测试的时候, 一般都会开一个和线上环境类似的服务器或者是多一个 k8s 集群.
在线测试环境对开发而言, 提供了一个和生产环境类似的虚拟环境, 主要目的是为了上线前 Debug, 在 Bug 影响生产环境之前就被测试出并且去除, 拥有更加拟真的数据, 从而得到测试和预期效果的差距, 帮助开发更好的进行开发工作.
说人话就是排练
其中资源 配置 监控 等等和正式的服务基本都是类似的 甚至是一样的, 但往往密码却都是弱密码, 同时也因为不是生产环境, 所以 Debug 调试信息也会更多, 更常见, 更频繁.
例如前端就会开启 Webpack 的 SourceMap, 时常还有辅助的控制台输出.
正因此, 这些内容的暴露使得开发的测试环境往往漏洞百出, 高风险更高. 往往保护也非常欠缺. 比如测试环境不在诸如防火墙 Waf 一类的安全产品的保护范围之中, 甚至他们就根本没有可能存在这类安全产品(当然现在企业这种情况非常的少, 所以 Bypass WAF 这种也是安全人员的必修课之一).
此外 测试环境中的测试内容可能会部分流入到正式的生产环境, 当然只是可能. 就例如之前我提到的 SSO Login 和 测试账号导致正式环境全授权的问题.
在云上这种风险会更高, 不过云上的事情下一章节再说. 这里先留下一个伏笔.
通过这些漏洞或者简单的弱密码, 我们就可以一脚踹进对方测试环境的大门, 进行信息的搜集. 我们可以很轻松的就收集到对方的一些偏好. 虽然这些不是生产环境的敏感信息, 但是明锐的红队成员中能嗅出其中的味道. 例如: 对方喜欢的技术栈 , 喜欢用的弱密码或者密码习惯 ( 比如 是偏好 123456 还是 111111 或者 888888 还是更喜欢其他的), 测试环境配置/监控 等. 密码之类的可能会改变, 但是密码偏好不会很快改变. (有些人就喜欢 中文名称+数字(生日或者123456)的 组合). 复用这些收集到的东西, 复用到正式服务或者其他公司的服务, 那么总会可以带给你意外的收货.
之前我总是因为打下对方测试环境而感到难受, 但是经过仔细的一番搜寻之后其实测试环境暴露出来的问题往往更多更敏感.
在测试环境中我们更希望横向移动到生产和内部, 所以更需要注重配置中公共服务的信息(例如公共数据库 公共配置中心 AKSK) 权限情况(存不存在越界访问等) 和 API 文档(这种定好了很难去改变的) 主要是这类可以复用到其他服务的信息, 何况测试环境本身对红队来说其实价值不是很高.
Configs/Creds
Config Server
Cross Service
有些企业常常会有 Config Server 这种服务, 通过一个 Creds 来访问和区分每个服务需要的凭证信息和内容, 可以做到给服务需要的资源. 如果配置的恰当, 一般暴露出来的内容其实很不利于继续横向的. 这种突破点一般是去寻找业务与业务之间相关的数据. 往往可以越过去, 这些地方很容易因为偷懒而获得高权限. 比如说共享数据库的账号的服务, 共享一些资源的凭证以及 API 调用的 KEY. 这种服务间的跨越往往更为简单有效.
Man In the Middle
此外, 这类配置服务需要注意预防中间人. 配置信息一般是较为敏感的内容. 这里需要注意.
比如有些服务的配置交流内容是 HTTP 交互的, 没有 TLS 加密. 这里只要一个 Wireshark 就能把他交互的内容和结果抓出来. 如何通讯如何获取, 配置又是什么一清二楚. 这确实是发生过的.
e.g. 拿到了对方服务的二进制文件, 但是没有对方服务的 Config. 对方启用了 Config Server ,但是却是 明文交互的. 这里我们就可以直接启动二进制 + 本地抓包, 逆向都不用逆了.
Creds
还有些是相关的人的凭证, 又到了 喜闻乐见的账号接管欺诈 辣.
比如搞到了员工的账户或者系统服务的账号, 在静默情况下可以维持相当长一段的监听. 尤其是系统级别的账号. 比如说 XXXSYSTEM在其他系统 (比如说邮箱) 的账号密码.
没啥大事(被盗号或者强制), 否则他们真的不会改密码. 你也不会 ;-)
这里可以监听可以钓鱼, 做蛮多的事情. 还有本身有权限拿到的一些内容和数据.
服务类的账号接管, 比如 System 或者 admin 这种, 在域中可以类比为 Silver Ticket 的攻击. 通过接管系统中的服务性账号将更具有迷惑性和隐蔽性, 所以非常适合作为一种后门在对应的系统中持久化留存.
Attack Coder
本来这一章节我是打算删除的. 但是昨天发现某数据库泄漏和可能略有相关的某篇 CSDN 的文章 实在有些蚌埠住了.
这个章节我想探讨一下一种可能性. 即为通过社工或者其他方式得到企业员工账号, 监控他们的代码类社交网站(CSDN, Juejin)或者公共代码托管(Github, Gitlab) 是否存在一种可能可以通过员工的提交内容和社交网站的帖子, 旁敲侧击出对应公司内部技术栈和技术实现 甚至账密泄漏和 APIKey 的泄漏.
数据处理不当很容易出现这种事故. 有些程序员在研究了新的技术或者工具之后, 在文章中想要用一些例子来进行一些说明, 此时会涉及到一些代码的粘贴. 当代码的脱敏很容易因为这些内容导致泄漏. (比如那篇文章)
这类泄漏基本都有相关的利用和检查工具.
但是我还是认为这种方式的可行性是很低的, 因为并不一定能找到泄漏, 也不是所有 Key 都可以, 也有可能对方程序员的安全素养非常的高或者根本没有这种平台的账号, 当然 Github 之类的平台还会有泄漏的检测和泄漏的警告邮件, 在种种原因下, 如果寄希望于此是非常容易导致竹篮打水一场空. 这也是为什么之前我打算删除这方面的内容.
Last updated