Istio自身服务的安全风险

Istio是目前最受关注的服务网格之一,越来越多的公司开始落地Service Mesh架构,并将已有的系统接入Service Mesh。同时随着零信任网络的发展,东西向,南北向流量都需要提供足够的安全保护,因为Istio自身提供了多种安全特性,所以也出现不少基于Istio的零信任架构。在安全中通常关注的重点是南北流量,而我们应该认识到,在云原生的环境下,东西流量安全也应该受到足够的重视。
在Istio默认的配置中,其在集群内暴露了许多未授权和明文传输的服务。通常情况下,这会引起攻击者的注意,当恶意攻击者进入被控制的容器或发现SSRF漏洞后,往往可以利用这些自身的服务扩大攻击范围。

阅读剩余部分 –

Spring Boot中关于%2e的Trick

分享一个Spring Boot中关于%2e的小Trick。先说结论,当Spring Boot版本在小于等于2.3.0.RELEASE的情况下,alwaysUseFullPath为默认值false,这会使得其获取ServletPath,所以在路由匹配时相当于会进行路径标准化包括对%2e解码以及处理跨目录,这可能导致身份验证绕过。而反过来由于高版本将alwaysUseFullPath自动配置成了true从而开启全路径,又可能导致一些安全问题。

阅读剩余部分 –

Service Mesh中的iptables流量劫持

随着软件架构不断的演进,更加快捷部署大型复杂应用成为了人们关注的方向。近几年Service Mesh开始不断出现在大家的视野里,越来越多的大厂开始对其进行实践。事实上在Service Mesh发展中核心就是不断对Sidecar模式配备更加完善的流量管理解决方案。
在Service Mesh中Sidecar是透明的,开发者对其无感知的,而其中对于流量最关键的一步就是Sidecar进行的流量劫持,那么Sidecar又是如何进行流量劫持呢?最常见的方式就是iptables,本文将会带你了解iptables,同时明白Istio中是如何使用iptables进行流量劫持。

阅读剩余部分 –

Kubernetes中使用Helm2的安全风险

Kubernetes是一个强大的容器调度系统,通常我们会使用一些声明式的定义来在Kubernetes中部署业务。但是当我们开始部署比较复杂的多层架构时,事情往往就会没有那么简单,在这种情况下,我们需要编写和维护多个YAML文件,同时在编写时需要理清各种对象和层级关系。这是一个比较麻烦的事情,所以这个时候Helm出现了。

我们熟悉的Python通过pip来管理包,Node.js使用npm管理包。那么在Kubernetes,我们可以使用Helm来管理。它降低了使用Kubernetes的门槛,对于开发者可以很方便的使用Helm打包,管理依赖关系,使用者可以在自己的Kubernetes通过Helm来一键部署所需的应用。
对于Helm本身可以研究的安全风险可以从很多角度来看比如Charts,Image等,详细的内容可以来看CNCF webinars关于Helm Security的一个分享(https://www.cncf.io/webinars/helm-security-a-look-below-deck/
本篇文章主要讨论的是Helm2的安全风险,因为在Helm2开发的时候,Kubernetes的RBAC体系还没有建立完成,Kubernetes社区直到2017年10月份v1.8版本才默认采用了RBAC权限体系,所以Helm2的架构设计是存在一定安全风险的。Helm3是在Helm2之上的一次大更改,于2019年11月份正式推出,同时Helm2开始退出历史舞台,到2020年的11月开始停止安全更新。但是目前网络上主流依然为关于Helm2的安装配置文章,所以我们这里将对使用Helm2可能造成的安全风险进行讨论。

阅读剩余部分 –

认识 WebAuthn

目前来看,密码认证方式早已成为我们一直采用的最直接的身份认证方式。但是我们应该知道的是很多大型企业都有曾出现过明文密码泄漏的事件,而且随着黑产的不断成长,钓鱼,撞库等等一系列的欺骗攻击行为都在不断涌现。由于很大一部分用户习惯于同一密码用于多个网站,这就导致了一次密码泄漏会牵连多个网站,用户密码认证的体系一直都在面临着很大的挑战。
对此而言,一种新的认证方式也已经出现在我们的视线范围内,WebAuthn在2019年3月成为了W3C推荐标准,同年的BlackHat大会上也有一篇议题专门介绍了WebAuthn,直到目前我们常见的浏览器大部分都已经支持了WebAuthn的标准,如Chrome,Safari等。可以看到各方力量都在联合推动着无密码认证的实现与发展,那么接下来我们就来一起认识一下什么是WebAuthn,以及它是如何工作的。

阅读剩余部分 –

Java单向代码执行链配合的动态代码上下文执行

Java反序列化漏洞的危害不光在于普通gadgets能够带来的命令执行,由于Java应用的使用场景以及gadgets大多都是构造出单向代码执行,一般通过利用链构造出的单向代码链能做到的能力往往有限。而我们在多数场景比如需要回显,注入内存shell等情况下,实际上对可以直接运行整个class或者说运行一个全局上下文关联的多行代码来进行动态执行有极大的需求。它往往是需要反序列化利用链配合另一条能够动态代码执行的利用链,这里我们主要讨论的也是这种情况。下面会简要分享下部分相对比较常见同时能够直接动态代码上下文执行的方式。

阅读剩余部分 –

Java“后反序列化漏洞”利用思路

“后反序列化漏洞”指的是在反序列化操作之后可能出现的攻击面。反序列化漏洞是Java中最经典的一种,所以大家可能的关注点都集中在反序列化过程中的触发点而忽略了反序列化之后的攻击面,这里我会分享一些在Java反序列化后的攻击思路。

阅读剩余部分 –

聊聊对目前Passive IAST的思考

之前一直有在研究Java插桩应用于安全防御以及检测方面的东西,主要分为RASP和IAST。IAST又叫交互式应用安全测试,它目前主要分为主动式(Active)和被动式(Passive)两种,上个暑假有机会重点接触了一下Passive IAST的一些研究工作。这里打算简单聊聊,也算是一个总结与思考。不会涉及太多技术细节,简单分享下我对的被动式IAST的应用以及优势还有劣势的看法以及存在的一些问题和新的思路。希望能和大家一起交流探讨。

Passive IAST原理

核心

利用Instrumentation API我们可以提供一个Agent代理用来监测和协助运行在JVM上的程序,可以在程序启动前修改类的定义。简单来说就是在运行的应用中织入一个我们的程序。而在这个程序中我们就拥有了获取当前应用的上下文,在应用运行中实时分析数据流以及调用栈的能力,同时也可以通过ASM对已经加载的class进行分析与修改。

在织入我们检测的逻辑代码后,被动式IAST主要是通过污点跟踪的方法来对漏洞进行检测,因为是实时数据流,所以这里我们称为动态污点传播分析。这是与静态扫描中污点分析的一个小区别,而其优势和劣势也主要在这里。

阅读剩余部分 –

SpringMVC框架任意代码执行漏洞(CVE-2010-1622)分析

CVE-2010-1622很老的的一个洞了,最近在分析Spring之前的漏洞时看到的。利用思路很有意思,因为这个功能其实之前开发的时候也经常用,当然也有很多局限性。有点类似js原型链攻击的感觉,这里分享出来。

介绍

CVE-2010-1622因为Spring框架中使用了不安全的表单绑定对象功能。这个机制允许攻击者修改加载对象的类加载器的属性,可能导致拒绝服务和任意命令执行漏洞。

Versions Affected:
3.0.0 to 3.0.2
2.5.0 to 2.5.6.SEC01 (community releases)
2.5.0 to 2.5.7 (subscription customers)

Earlier versions may also be affected

阅读剩余部分 –

通过HashMap触发DNS检测Java反序列化漏洞

我们常说的反序列化漏洞一般是指readObject()方法处触发的漏洞,而除此以外针对不同的序列化格式又会产生不同的触发点,比如说fastjson会自动运行setter,getter方法。之后又有各种RMI,JNDI姿势去执行命令。现在常见的黑盒检测Java反序列化方式就是执行命令API,比如用一个gadget去执行nslookup xxx 最终通过服务器记录去判断。
但这种方式可能出现的一种问题是,你选择测试的gadget服务器正好没这个jar包或者更新过了,但却有另一个存在漏洞的jar包。这时候单一的gadget构造出的执行命令payload就会漏报。所以为了解决这种问题这里分享一个通过HashMap结合URL触发DNS检查的思路。在实际过程中可以首先通过这个去判断服务器是否使用了readObject()以及能否执行。之后再用各种gadget去尝试试RCE。

阅读剩余部分 –