Common Develop Service
通用开发服务
Codebase
代码库
CodeBase 在这里我分为两类: 一类是 Git 这种 版本控制, 这种比较常见 也是基本都存在的. 第二种是 package library, 有些公司具有类似的 Maven 包管理中心. 对编写的代码和依赖做更为严格的控制和统一的管理.
代码即资产
在现代软件开发中，代码仓库和依赖库早就不是“技术细节”，而是企业的核心数字资产。一旦失守，轻则源码泄露，重则整个技术栈被逆向、漏洞批量复用、供应链全面污染。攻击者常说：“给我 Git，我能拿下一切。”
Version Control Platform
版本控制平台
当你写完代码, 进行提交, 代码就会被存到 GIT SVN 一类的版本控制软件或者代码托管平台.这里也是渗透测试人员可以仔细搜寻的脆弱点或者敏感区域.
🗃️ 常见载体
公有云：GitHub、GitLab.com、Gitee
自建平台：GitLab CE/EE、Gitea、Bitbucket
云厂商 DevOps 套件：腾讯云 Coding（e.coding.net）、阿里云效、AWS CodeCommit
这是企业的代码资产中最最核心的部分, 针对这些东西的利用和漏洞也是数不胜数, 尤其是 GITLAB, 所以现代企业往往都会在内网建立这类的代码托管. 并且正确的安全策略应该是禁止外网访问并且加上强验证强访问控制的, 并且需要注意安全性问题, 及时提供补丁. 比如以下防御策略.
禁止公网访问，强制走内网或 Zero Trust 网关
启用 强制 2FA
定期扫描 硬编码密钥（TruffleHog、GitGuardian）
使用 Pre-commit Hook 阻止敏感文件提交
针对代码本身的审计, 硬编码, 成熟的配置文件 这些属于是最基本最基本的攻击面. 就不重复了.
Git 中也会存有大量暴露出来的额外信息也是需要检查的. 比如说 某些 IP 下具有数据库资产, 哪些是测试环境, 哪些是是开发环境, 在 Gitlab snippets 和 WIKI 可能会留存一些开发或者维护信息之类的东西. (当然大多数情况是不会去使用的)
这些平台存储了：
完整业务逻辑
环境配置（
.env、application-prod.yml）数据库连接串、AK/SK、API Token（常因疏忽硬编码）
内部 IP、服务拓扑、测试账号
💡 最危险的不是代码本身，而是代码里的“注释”和“提交历史”：
// TODO: fix this SQL injection later
git log暴露开发者姓名、邮箱 → 用于钓鱼Wiki / Snippets 中记录“测试环境地址：10.10.5.22”
🔓 攻击路径
1.凭证泄露：员工 GitHub Token 泄露、弱密码爆破 GitLab
2.子域名爆破：
code.company.com、gitlab.internal意外暴露公网3.SSO 配置错误：通过测试账号+SSO 登录内网 GitLab
4.利用平台漏洞：GitLab 历史 RCE（如 CVE-2021-22205）、Gitea 路径遍历
📌 真实案例：
某金融公司因 GitLab 未打补丁，被利用 CVE 拿下 root 权限，进而窃取全部微服务代码。
此外 拿下代码控制平台, 对对方代码进行审计和调试, 常常也是安全人员喜欢做的事情之一. 这意味着, 如果有更多的地方运用了这些代码 (或是组件), 安全人员可能会对这些漏洞进行复用, 再拿下更多的目标, 获取到更多的代码, 形成一个正反馈的循环.
Package Library
包库
大型企业通常会搭建私有包仓库(包管理工具)，用于：
托管内部组件（如
com.company:auth-sdk）代理/缓存公共依赖（Maven Central、npmjs.org）
统一版本控制与安全审计
常见平台：
Java：Nexus Repository、Artifactory、JFrog
Node.js：Verdaccio、Nexus npm proxy
Python：PyPI 私有镜像（如 devpi）
☣️ 为什么这是高危目标？
看到有报告说可以进行下毒,不过我并不是很懂这里应该怎么去 Do Some Evil.AI给出答案：
▶ 场景一：依赖投毒（Dependency Confusion）
攻击者上传同名但更高版本的包到公共仓库
若企业构建系统优先拉取公网（而非私有源），就会自动引入恶意包
恶意包可执行任意代码（如反连 shell、窃取 AK）
📌 微软、Apple、PayPal 均曾中招（2021 年大规模事件）
▶ 场景二：直接攻陷私服
若 Nexus/Artifactory 暴露公网且存在漏洞（如 CVE-2020-10199）
攻击者可上传恶意 JAR，后续所有拉取该组件的服务都会被污染
实现 “一次投毒，全网感染”
▶ 场景三：滥用发布权限
开发者账号被接管 → 发布“合法”但含后门的新版本
CI/CD 自动集成 → 后门进入生产环境
💡 即使你“不懂 Java”，只要理解：私有包 = 信任链的起点，就能明白其价值。
CICD
CICD 这个玩意也算是很常见的重点目标了.
为什么?
因为他能执行 shell 代码 或者脚本, 而且正常跑起来的时候需要的权限要的还不少. 少说是个能运行命令的 Root. 或者具有集群创建变更权限的 Root.
CI/CD（持续集成/持续部署）本意是加速交付，但它天生具备两个致命属性：
能执行任意命令或脚本
通常运行在高权限上下文（如 root、Docker in Docker、K8s cluster-admin）
💡 对攻击者而言，拿下 CI/CD = 拿下整个生产环境的“合法构建通道”。
想通这点. 接下来具体情况就就是看滥用它就是了
为什么 CI/CD 是重点目标？
权限极高：为了拉代码、编译、打镜像、部署服务，CI/CD Runner 通常拥有：
主机 shell 访问权
Docker daemon 权限（可逃逸到宿主机）
K8s RBAC 高权限（可创建 Pod、读 Secret）
云平台 AK/SK（用于部署 ECS、RDS 等）
自动化触发：只要满足条件（如 push 到 main 分支），恶意 payload 就会自动执行
信任度高：安全设备常对 CI/CD 流量放行，认为“这是内部流程”
📌 现实印证：Jenkins 几乎每年都有多个 RCE/CVE，更新频率高得离谱——不是它爱修，是它太危险。
Jenkins
🔍 为什么无处不在？
历史悠久，生态庞大
插件机制灵活（但也复杂）
企业内网常见子域名：
jenkins.company.com、ci.internal
⚠️ 常见滥用路径：
📚 推荐参考：HackTricks - Jenkins 从信息枚举到 RCE，一条龙讲透。
“Jenkins 这玩意属实是不太轻量。Java 嘛，总是有 Java 的样子。”——内存吃得多，漏洞也不少，但企业就是离不开。
Drone
▶ Webhook（Go 写的那个）
轻量、简单，适合小团队
通常通过接收 Git webhook 触发 Shell 脚本
风险点：若 webhook 未校验签名，攻击者可伪造请求 → 执行任意命令
防御关键：必须验证
X-Hub-Signature或类似机制
▶ Drone CI
基于容器的现代 CI/CD
每个任务跑在独立 Docker 容器中
优势：隔离性好
风险：若配置不当（如挂载
/var/run/docker.sock），可实现 Docker 逃逸常与 Kubernetes 深度集成 → 若 ServiceAccount 权限过大，可横向控制集群
比较新的东西是 Drone 无人机. 以 container 作为特色的 CICD, 除了脚本之类的内容, 往往还会伴随着还有不少 Kubernetes 和 docker 的综合利用. 这一部分将在下一部分继续说明.
Online Testing
测试服务也是开发过程中比较重要的一个环节. 而且往往为了和真实环境更加类似, 都会存在公网可以访问的在线测试的网站. 在软件上线前，团队通常会搭建一个 在线测试环境（常带 test、staging、dev 等子域名），用于模拟生产行为、验证功能、排查 Bug。
这部分通过 代码审计测试 与 在线测试集群 两个部分. 主要是第二部分 Online Testing (Clusters)
Code Audit
代码审计测试
这种服务我没咋个遇到过. 就看到过一次 Sonatype 安装在系统中, 并且作为 CICD 中间的一个自动测试服务运行, 似乎是进行静态代码检查和测试
Sonatype Nexus IQ / SonarQube 等工具在部分企业 CI/CD 中作为“代码守门员”存在：
扫描依赖漏洞（如 Log4j）
检查硬编码密钥
强制代码规范（Lint）
但问题在于：
部署率低：多数中小团队仅用基础 Lint，无深度 SAST
自身可被利用：如 Sonatype Repository Manager 的 Script API 明确标注 “Unsafe”，若未授权访问，可执行任意 Groovy 脚本 → RCE
信任过度：以为“过了扫描就安全”，实则业务逻辑漏洞（越权、注入）无法被静态工具覆盖
📌 这类工具本身也是资产，需纳入安全管控——**别让“安检仪”变成“后门”。
Online Testing (Clusters)
当然我知道很多开发都是开在线灵车的. :- )比如 “我”
在线测试是就是一个在开发过程中很容易被忽略的点, 但又是安全人员可以去关注的点. 当一个团队快要进行上线发布之前的几个版本(或者从一开始)就进行测试的时候, 一般都会开一个和线上环境类似的服务器或者是多一个 k8s 集群.
在线测试环境对开发而言, 提供了一个和生产环境类似的虚拟环境, 主要目的是为了上线前 Debug, 在 Bug 影响生产环境之前就被测试出并且去除, 拥有更加拟真的数据, 从而得到测试和预期效果的差距, 帮助开发更好的进行开发工作.
而为什么测试环境如此危险？
其中资源 配置 监控 等等和正式的服务基本都是类似的 甚至是一样的, 但往往密码却都是弱密码, 同时也因为不是生产环境, 所以 Debug 调试信息也会更多, 更常见, 更频繁.
此外 测试环境中的测试内容可能会部分流入到正式的生产环境, 当然只是可能. 就例如之前我提到的 SSO Login 和 测试账号导致正式环境全授权的问题.
🔍 攻击者如何利用？
子域名爆破：
test.company.com、staging.api.company.com弱口令爆破：
admin/admin、test/123456SourceMap 还原前端：获取 API 路径、参数名、内部逻辑
读取配置文件：
.env、application-test.yml中含数据库密码、Redis 地址复用凭据：测试环境的 DB 密码 = 生产环境密码（只是 IP 不同）
🎯 真正的目标：横向到生产
测试环境本身价值有限，但它是情报金矿：
技术栈偏好：用 Spring Boot？Django？NestJS？
密码习惯：
姓名+123、公司名+888→ 可用于钓鱼或撞库API 设计模式：REST 路径、鉴权方式 → 指导对生产 API 的攻击
公共服务地址：配置中心（Nacos）、注册中心（Consul）、消息队列（Kafka）→ 可尝试内网探测
测试环境的价值，不在于它自己，而在于它能带你去哪。
在云上，风险进一步加剧：
测试集群可能使用与生产相同的 VPC，仅靠安全组隔离
若安全组配置错误（如
0.0.0.0/0开放 8080），等于直接暴露内网服务测试 Pod 的 ServiceAccount 可能拥有跨命名空间读权限
AK/SK 复用：测试 ECS 实例绑定了生产级 RAM 角色
⚠️ 在云上这种风险会更高, 不过云上的事情下一章节再说. 这里先留下一个伏笔.
Configs/Creds
配置 / 证书
Config Server
配置服务器
在微服务时代，应用不再硬编码数据库密码或 API Key，而是从统一的 配置中心（Config Server） 或 凭证管理服务 动态拉取敏感信息。
这本是安全最佳实践，但如果设计或实现不当，反而会成为集中式漏洞源—— 一处泄露，全网沦陷。
Cross Service
有些企业常常会有 Config Server 这种服务, 通过一个 Creds 来访问和区分每个服务需要的凭证信息和内容, 可以做到给服务需要的资源. 如果配置的恰当, 一般暴露出来的内容其实很不利于继续横向的. 这种突破点一般是去寻找业务与业务之间相关的数据. 往往可以越过去, 这些地方很容易因为偷懒而获得高权限. 比如说共享数据库的账号的服务, 共享一些资源的凭证以及 API 调用的 KEY. 这种服务间的跨越往往更为简单有效.
交叉服务
🔑 它是什么？
如 Spring Cloud Config、Apollo、Nacos、Consul KV
服务启动时通过 Token / AppID 向 Config Server 请求专属配置
配置内容通常包括：
数据库连接串（含用户名/密码）
Redis / Kafka 地址与认证
第三方 API 的 AK/SK
加密密钥（如 JWT secret）
Man In the Middle
⚠️ 常见风险点
▶ 跨服务权限复用（“偷懒式共享”）
多个服务共用同一个数据库账号
某服务 A 只需读权限，却因“图方便”给了读写权限
攻击者控制服务 A → 利用其 DB 账号 直接写入服务 B 的数据表
💡 “业务之间相关的数据，往往因为偷懒而获得高权限。”——最小权限原则，在赶工期面前总是第一个牺牲品。
▶ 明文传输（无 TLS）
Config Server 与客户端通过 HTTP 明文通信
攻击者只需在内网抓包（Wireshark / tcpdump），即可获取：
所有配置内容
认证 Token
服务间调用的完整上下文
📌 真实场景：
你拿到一个服务的二进制（如 app.jar），但无配置。
若它连接的 Config Server 是 HTTP，直接本地运行 + 抓包，连逆向都不需要——配置自动送上门。
▶ 访问控制薄弱
Config Server 未校验来源 IP 或服务身份
任意内网机器可请求
/config/service-b→ 越权读取其他服务配置
Creds
凭证
🧍♂️ 两类高价值凭证
🔓 服务账号接管：Silver Ticket 式持久化
服务账号通常：
拥有数据库/集群的高权限
密码数年不变（“系统依赖，不敢改”）
无 MFA，仅靠 Token 或静态密码
一旦被接管，攻击者可：
静默监听：长期潜伏，不触发告警
伪装合法流量：所有操作看起来都是“正常服务行为”
作为跳板：从 DB 服务器横向到应用服务器
💡 这正是你在域渗透中熟悉的 Silver Ticket 思维——
不伪造 TGT（黄金票据），而是直接冒充某个服务的身份（白银票据）。
🎣 人员账号的“静默期”
员工账号被盗后，若未触发异常登录（如同城、常用设备）
受害者可能数月不改密码
攻击者可：
监听邮件（获取会议纪要、项目计划）
申请新权限（“我是新来的 Dev，需要 Git 权限”）
发起内部钓鱼（“财务部：请确认付款清单”）
Attack Coder
这个章节我想探讨一下一种可能性. 即为通过社工或者其他方式得到企业员工账号, 监控他们的代码类社交网站(CSDN, Juejin)或者公共代码托管(Github, Gitlab) 是否存在一种可能可以通过员工的提交内容和社交网站的帖子, 旁敲侧击出对应公司内部技术栈和技术实现 甚至账密泄漏和 APIKey 的泄漏.
数据处理不当很容易出现这种事故. 有些程序员在研究了新的技术或者工具之后, 在文章中想要用一些例子来进行一些说明, 此时会涉及到一些代码的粘贴. 当代码的脱敏很容易因为这些内容导致泄漏. (比如那篇文章)
这类泄漏基本都有相关的利用和检查工具.设想这样一个场景：
某程序员在研究公司新引入的内部监控系统后，兴奋地在 CSDN / 掘金 / 知乎 发文：
“用 Spring Boot + 自研 Agent 实现全链路追踪，超简单！”
并附上一段“脱敏”代码：
// 连接内部 Trace 服务
String url = "https://trace.internal.corp:8443/api/v1/submit";
String apiKey = "sk-2024-trace-xxxxxxxx"; // ← 脱敏失败！看似无害的技术分享，却可能暴露：
内部域名（
trace.internal.corp）API 路径与认证方式
真实的 API Key（即使部分打码，也可能被爆破或复用）
类似情况还包括：
在 GitHub Gist 中粘贴“临时调试脚本”，含
.env内容在 Stack Overflow 提问时，截图包含内网 IP 或服务名
在开源项目 PR 中误提交公司内部逻辑片段
📌 工具如 GitGuardian、TruffleHog、Shhgit 正是为此类泄露而生——它们实时扫描公开平台，寻找 AK/SK、密码、私钥。
但是我还是认为这种方式的可行性是很低的, 因为并不一定能找到泄漏, 也不是所有 Key 都可以, 也有可能对方程序员的安全素养非常的高或者根本没有这种平台的账号, 当然 Github 之类的平台还会有泄漏的检测和泄漏的警告邮件, 在种种原因下, 如果寄希望于此是非常容易导致竹篮打水一场空. 这也是为什么之前我打算删除这方面的内容.
尽管上述场景真实存在，但必须清醒认识到：
✅ 防御机制已在加强
GitHub 等平台自动扫描提交内容，发现密钥会立即邮件告警并建议轮换
企业安全意识培训普遍强调“禁止外发内部代码”
越来越多公司使用 DLP（数据防泄漏）工具 监控员工外发行为
❌ 攻击成本高、成功率低
并非所有开发者都写技术博客
并非所有文章都含敏感信息
即使有 Key，也可能是测试环境、已过期、权限极低
安全素养高的团队会严格审查对外内容