procfs是展示系统进程状态的虚拟文件系统,包含敏感信息。直接将其挂载到不受控的容器内,特别是容器默认拥有root权限且未启用用户隔离时,将极大地增加安全风险。因此,需谨慎处理,确保容器环境安全隔离。
在《〈云原生安全: 攻防实践与体系构建〉解读:攻防对抗篇》中,我们为大家介绍了《云原生安全:攻防实践与体系构建》书中精彩的攻防对抗技术与案例。事实上,无论是对于一线负责攻防的同学,还是对于相关安全研究的同学来说,实践是掌握这些技能、理解这些威胁及设计合理防御机制的关键。纸上得来终觉浅,绝知此事要躬行。本篇,我们就为大家梳理一下本书中可以供各位同学动手实践的部分。我们也建议大家,在有需求、有条件的情况下,能够跟随本书,敲下一行行命令,感受其中的奥妙。
RunC是一个基于OCI标准的轻量级容器运行时工具,用来创建和运行容器,该工具被广泛应用于虚拟化环境中,然而不断披露的逃逸漏洞给runC带来了严重的安全风险,如早期的CVE-2019-5736、CVE-2021-30465。就在今年的1月31日,网络安全供应商Synk又披露了runC 命令行工具和BuildKit 组件中的4个安全漏洞,攻击者可以利用这些漏洞逃离容器的边界并发起后续攻击。这些漏洞编号分别为 CVE-2024-21626、CVE-2024-23651、CVE-2024-23652 和 CVE-2024-23653,这些漏洞被 Snyk统称为Leaky Vessels[1][2]。
项目地址:https://github.com/teamssix/container-escape-check
正常情况下用户通过使用docker cp命令可以将文件从host主机拷贝至容器,或者从容器拷贝至host主机,对应具体操作指令如下:
CVE-2022-0543 该 Redis 沙盒逃逸漏洞影响 Debian 系的 Linux 发行版本,并非 Redis 本身漏洞, 漏洞形成原因在于系统补丁加载了一些redis源码注释了的代码
Docker 是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中,然后发布到任何流行的 Linux或Windows操作系统的机器上,也可以实现虚拟化。容器是完全使用沙箱机制,相互之间不会有任何接口。
当获得一个Webshell,我们的攻击点可能处于服务器的一个虚拟目录里,一台虚拟机或是一台物理机,甚至是在一个Docker容器里。
前两天一直在敲代码写工具,主要目的是想方便自己在渗透测试中前期的信息收集。在测试脚本进行批量扫描的时候, 看见一个熟悉的 edu 域名,欸?这不是之前交过 edusrc 平台的某个站点吗, 又给我扫到
runC社区于2024年2月1日披露了高危安全漏洞CVE-2024-21626,攻击者可以利用该漏洞越权访问宿主机文件或执行二进制程序,详细内容参见下文
下图是 Docker 官方给出的架构图,里面包括了 Docker 客户端、Docker 容器所在的宿主机和 Docker 镜像仓库三个部分。
2019年2月11日,runc的维护团队报告了一个新发现的漏洞,该漏洞最初由Adam Iwaniuk和Borys Poplawski发现。该漏洞编号为CVE-2019-5736,漏洞影响在默认设置下运行的Docker容器,并且攻击者可以使用它来获得主机上的root级访问权限。
随着云原生的火热,容器及容器编排平台的安全也受到了行业关注,Gartner在近期发布的《K8s安全防护指导框架》中给出K8s安全的8个攻击面,总结如下:
因为Docker所使用的是隔离技术,就导致了容器内的进程无法看到外面的进程,但外面的进程可以看到里面,所以如果一个容器可以访问到外面的资源,甚至是获得了宿主主机的权限,这就叫做“Docker逃逸”。
由于传播、利用本公众号亿人安全所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,公众号亿人安全及作者不为此承担任何责任,一旦造成后果请自行承担!如有侵权烦请告知,我们会立即删除并致歉。谢谢!
在Docker 19.03. 2-ce和其他产品中使用的runc 1.0.0-rc8允许绕过AppArmor限制,因为libcontainer/rootfs_linux.go错误地检查装载目标,攻击者可以在容器镜像中可以声明一个VOLUME并挂载至/proc,之后欺骗runc使其认为AppArmor已经成功应用从而绕过AppArmor策略,该漏洞由Adam Iwaniuk发现并在DragonSector CTF 2019期间披露,这个CTF题目挑战将一个文件挂载到/flag-<random>,并使用AppArmor策略拒绝访问该文件,选手可以利用这个漏洞来禁用这个策略并读取文件
在2020年Black hat北美会议上,来自Palo Alto Networks的高级安全研究员Yuval Avrahami分享了利用多个漏洞成功从Kata containers逃逸的议题[1]。
本文将以比较简单的的方式让大家理解docker,以平时常用到的测试环境为主,从用开始,慢慢理解docker。
Yapi 是高效、易用、功能强大的 api 管理平台,旨在为开发、产品、测试人员提供更优雅的接口管理服务。可以帮助开发者轻松创建、发布、维护 API,YApi 还为用户提供了优秀的交互体验,开发人员只需利用平台提供的接口数据写入工具以及简单的点击操作就可以实现接口的管理。
近日国外安全研究员发布了可导致容器逃逸的runc漏洞 POC,该漏洞影响runc 1.0.0-rc94以及之前的版本,对应CVE编号:CVE-2021-30465。
绿盟科技研究通讯曾经发表过容器逃逸的技术文章《【云原生攻防研究】容器逃逸技术概览》[1],该文中探讨了已有的容器逃逸技术。本文将沿着上文的思路,主要从Linux内核漏洞的角度对容器逃逸进行深度介绍,包括攻击原理、自动化利用和防御思路等内容。
随着云计算技术的不断发展,越来越多的企业开始上“云”。云原生计算基金会(CNCF)提出了云原生(Cloud Native)的概念,云原生包含了一组应用的模式,用于帮助企业快速,持续,可靠,规模化地交付业务应用。云原生由微服务架构,DevOps 和以容器为代表的敏捷基础架构组成。
Docker实现原理:https://zone.huoxian.cn/d/1034-docker
2020年年末的时候,我们于CIS2020上分享了议题《Attack in a Service Mesh》讲述我们在近一年红蓝对抗演练中所遇到的云原生企业架构以及我们在服务网格攻防场景沉淀下来的一些方法论。回顾近几年腾讯蓝军在云原生安全上的探索和沉淀,我们在2018年的时候开始正式投入对Serverless和容器编排技术在攻防场景的预研,并把相关的沉淀服务于多个腾讯基础设施和产品之上,而在近期内外部的红蓝对抗演练中腾讯蓝军也多次依靠在云原生场景上的漏洞挖掘和漏洞利用,进而突破防御进入到内网或攻破核心靶标;特别是2020年度的某云安全演习更是通过云原生的安全问题才一举突破层层对抗进入内网。
近年来,容器技术持续升温,全球范围内各行各业都在这一轻量级虚拟化方案上进行着积极而富有成效的探索,使其能够迅速落地并赋能产业,大大提高了资源利用效率和生产力。随着容器化的重要甚至核心业务越来越多,容器安全的重要性也在不断提高。作为一项依然处于发展阶段的新技术,容器的安全性在不断地提高,也在不断地受到挑战。与其他虚拟化技术类似,在其面临的所有安全问题当中,「逃逸问题」最为严重——它直接影响到了承载容器的底层基础设施的保密性、完整性和可用性。
细节部分在权限提升章节会详解,常用: CVE-2016-5195 CVE-2019-16884 CVE-2021-3493 CVE-2021-22555 CVE-2022-0492 CVE-2022-0847 CVE-2022-23222
CDK是一款为容器环境定制的渗透测试工具,在已攻陷的容器内部提供零依赖的常用命令及PoC/EXP。集成Docker/K8s场景特有的 逃逸、横向移动、持久化利用方式,插件化管理。
有在关注容器逃逸漏洞,最近在github上发现了一款零依赖Docker/K8s渗透工具包,集成了多个漏洞PoC/EXP,可轻松逃脱容器并接管K8s集群。
上周末,绿盟科技星云实验室在KCon 2022大会上分享了云原生安全相关议题《进退维谷:runC的阿克琉斯之踵》,该议题探讨了DirtyPipe漏洞写runC逃逸的利用手法,分析了“写runC逃逸”的成因、常见场景与手法,最后提出了一种基于ELF文件注入的写runC逃逸方法。本文将为意犹未尽的朋友提供该议题的详细解读。
Docker是当今使用范围最广的开源容器技术之一,具有高效易用的优点。然而如果使用Docker时采取不当安全策略,则可能导致系统面临安全威胁。
http://vulnstack.qiyuanxuetang.net/vuln/detail/6/
随着越来越多的企业开始上“云”,开始容器化,云安全问题已经成为企业防护的重中之重。
Docker 是一个开放源代码软件,是一个开放平台,用于开发应用、交付(shipping)应用、运行应用。Docker允许用户将基础设施(Infrastructure)中的应用单独分割出来,形成更小的颗粒(容器),从而提高交付软件的速度。 Docker 容器与虚拟机类似,但二者在原理上不同,容器是将操作系统层虚拟化,虚拟机则是虚拟化硬件,因此容器更具有便携性、高效地利用服务器。
假期马上结束了,闲暇之时我自己尝试着搭建了一个内网渗透的靶场。靶场是根据比较新的漏洞进行搭建的,质量自以为还可以。
Linux kernel < 4.10.6版本中,net/packet/af_packet.c/packet_set_ring函数未正确验证某些块大小数据,本地用户通过构造的系统调用实现提权,改漏洞亦可用于容器逃逸操作
📷 云原生安全 📷 1 专访腾讯安全副总裁董志强:我们该如何应对愈演愈烈的安全威胁? 腾讯在网络安全方面有二十多年积攒,同时在攻防主战场“云安全”上有着丰富的实践经验。面对网络安全不断变化的趋势,我们
35C3 CTF是在第35届混沌通讯大会期间,由知名CTF战队Eat, Sleep, Pwn, Repeat于德国莱比锡举办的一场CTF比赛。比赛中有一道基于Linux命名空间机制的沙盒逃逸题目。赛后,获得第三名的波兰强队Dragon Sector发现该题目所设沙盒在原理上与docker exec命令所依赖的runc(一种容器运行时)十分相似,遂基于题目经验对runc进行漏洞挖掘,成功发现一个能够覆盖宿主机runc程序的容器逃逸漏洞。该漏洞于2019年2月11日通过邮件列表披露,分配编号CVE-2019-5736。
https://github.com/tangxiaofeng7/Shiroexploit
近期笔者在进行相关调研时,读到一篇总结容器环境下渗透测试方法的2020年毕业论文,作者是Joren Vrancken,就读于荷兰奈梅亨大学计算机科学专业。
MS08067安全实验室不会对圈内任何机构、公司发起任何舆论攻击、诋毁。也欢迎各界朋友各种形式的合作!
其实想写这篇文章很久了,奈何工作比较饱和,涉事单位迟迟没有修复,所以就一直没写,今天接到通知,漏洞已经修复了,所以本着从实战角度出发,不忘记自己对技术的热爱,回归技术本质,从头来一遍真正的意义上的渗透测试,文章由真实事件而成,部分重要位置已做打码处理,核心涉密位置也已做脱敏处理。
选择这个漏洞的原因是和之前那个cve-2019-5786是在野组合利用的,而且互联网上这个漏洞的资料也比较多,可以避免在踩坑的时候浪费过多的时间。
环境 环境地址如下: http://39.98.79.56/vuln/detail/6/ 接下来下载好后在VmWare中进行ovf导入即可,共计三个文件 📷 接下来配置网络环境,在虚拟网络编辑器中添加两个网段 1、192.168.1.0 NAT模式 用于外网 2、192.168.183.0 仅主机模式 用于内网 📷 接下来给三个虚拟机以及攻击机(kali)进行分配 DC: VMet8(192.168.183.130) Web(Ubuntu): VMet4、VMet8(192.168.1.130、192.16
在每一个 Kubernetes 节点中,运行着 kubelet,负责为 Pod 创建销毁容器,kubelet 预定义了 API 接口,通过 GRPC 从指定的位置调用特定的 API 进行相关操作。而这些 CRI 的实现者,如 cri-o, containerd 等,通过调用 runc 创建出容器。runc 功能相对单一,即针对特定的配置,构建出容器运行指定进程,它不能直接用来构建镜像,kubernetes 依赖的如 cri-o 这类 CRI,在 runc 基础上增加了通过 API 管理镜像,容器等功能。
本文将重点探讨Docker容器的安全性加固方法,并深入分析容器漏洞管理的最佳实践。从社区角度、市场角度、领域角度、资源角度、生态角度、层面角度和技术领域应用等多个角度进行综合分析,帮助读者全面了解Docker容器安全的重要性以及如何保障容器环境的安全。
近年来随着云原生服务的大规模应用,互联网上暴露的相应资产越来越多,通过网络空间测绘技术可对暴露的资产进行数据统计及进一步的分析,从而有效赋能态势感知、漏洞预警、风险溯源等技术领域。
BPF 全称是「Berkeley Packet Filter」,中文翻译为「伯克利包过滤器」。它源于 1992 年伯克利实验室,Steven McCanne 和 Van Jacobson 写得一篇名为《The BSD Packet Filter: A New Architecture for User-level Packet Capture》的论文。该论文描述是在 BSD 系统上设计了一种新的用户级的数据包过滤架构。在性能上,新的架构比当时基于栈过滤器的 CSPF 快 20 倍,比之前 Unix 的数据包过滤器,例如:SunOS 的 NIT(The Network Interface Tap )快 100 倍。
领取专属 10元无门槛券
手把手带您无忧上云