【爬虫逆向】逆向破解某租车微信小程序，sign的解析
最近临近暑期,想去海边玩.
想自驾游，无车呀，咋办，只能上某租车平台租车,打开一看价格不菲啊
当我准备租的时候，改了时间，发现价格居然变少了，灵机一变的我突发奇想，会不会改了一个取车网点会不会也很便宜了呢？
果不其然，价格变低了不少，也就是说【时间+地点】可能会决定价格的变动，那怎么样做最优解呢？
最暴力的方式就是循环时间并且循环地点获取最低价格，那么怎么样调用这个查询接口呢？
思路：通过抓包的方式抓取到接口，然后动态的修改参数去获取查询结果的列表即可
通过抓包软件fildder可以看到响应数据找到对应的请求接口
入参研究
通过postman请求是ge请求，并且有四个参数，并且无需header的任何参数，那看起来应该是不难了
cid：猜测是城市id
q：不知道是什么，通过百分号看出来应该是encodeURIComponent过的参数
sign：一看就是加密的签名密钥，这个估计是重点
uid：未知的参数
做过爬虫的都知道有些参数不一定需要的，通过一个一个参数取消来判断哪些参数是不必要的，减少不必要的逆向工作
见名知起义，可以大胆的先猜测它的含义，用于后续研究
pickupCityId:应该是取车城市
returnCityId:还车城市
pickupDeptId:取车网点
returnDeptId:还车网点
大胆假设一下，如果我修改了还车时间再编码一下发过去请求,会不会成功呢（校验sign的参数跟哪些参数有关，一般sign都是混合多个参数进行加密的）
修改还车时间为2024-08-30 12:30,然后再次发送请求看看结果
最近临近暑期,想去海边玩.
想自驾游，无车呀，咋办，只能上某租车平台租车,打开一看价格不菲啊
当我准备租的时候，改了时间，发现价格居然变少了，灵机一变的我突发奇想，会不会改了一个取车网点会不会也很便宜了呢？
果不其然，价格变低了不少，也就是说【时间+地点】可能会决定价格的变动，那怎么样做最优解呢？
最暴力的方式就是循环时间并且循环地点获取最低价格，那么怎么样调用这个查询接口呢？
思路：通过抓包的方式抓取到接口，然后动态的修改参数去获取查询结果的列表即可
通过抓包软件fildder可以看到响应数据找到对应的请求接口
入参研究
通过postman请求是ge请求，并且有四个参数，并且无需header的任何参数，那看起来应该是不难了
cid：猜测是城市id
q：不知道是什么，通过百分号看出来应该是encodeURIComponent过的参数
sign：一看就是加密的签名密钥，这个估计是重点
uid：未知的参数
做过爬虫的都知道有些参数不一定需要的，通过一个一个参数取消来判断哪些参数是不必要的，减少不必要的逆向工作
见名知起义，可以大胆的先猜测它的含义，用于后续研究
pickupCityId:应该是取车城市
returnCityId:还车城市
pickupDeptId:取车网点
returnDeptId:还车网点
大胆假设一下，如果我修改了还车时间再编码一下发过去请求,会不会成功呢（校验sign的参数跟哪些参数有关，一般sign都是混合多个参数进行加密的）
修改还车时间为2024-08-30 12:30,然后再次发送请求看看结果
如何从 Kubernetes 节点权限提升至集群管理员权限？
我有幸参加了去年的 KubeCon 并分享议题，议题的其中一个攻防案例讲述了如何从一个边缘业务的开发者权限逐步提升至 Kubernetes 集群管理员权限；其中最后一步的手法，是描述关于节点上利用 DaemonSet 和 Pod 上的 ServiceAccount token 进行提权，那一年我在补天上的议题也简述了这个手法。在今年的 KubeCon 欧洲上，这样的攻击手法被命名为了"蹦床"。快速过完国外的这篇 slide 之后，深感他们研究的细致和用心，对比我去年的形色匆匆熬夜赶稿，他们倾注了更多的时间和资源，完成了我的很多遗憾和不甘；也让我重拾了这块研究的很多记忆
我有幸参加了去年的 KubeCon 并分享议题，议题的其中一个攻防案例讲述了如何从一个边缘业务的开发者权限逐步提升至 Kubernetes 集群管理员权限；其中最后一步的手法，是描述关于节点上利用 DaemonSet 和 Pod 上的 ServiceAccount token 进行提权，那一年我在补天上的议题也简述了这个手法。在今年的 KubeCon 欧洲上，这样的攻击手法被命名为了"蹦床"。快速过完国外的这篇 slide 之后，深感他们研究的细致和用心，对比我去年的形色匆匆熬夜赶稿，他们倾注了更多的时间和资源，完成了我的很多遗憾和不甘；也让我重拾了这块研究的很多记忆
AppSheet 中的 SSRF 漏洞 - Google VRP
Webhook 中的 SSRF
我研究了 AppSheet 的功能，发现了一个名为 Workflows 的部分（今天被“AppSheet Bots”取代）。AppSheet Workflow 通过定义特定规则实现了应用程序行为的自动化。例如 - 当用户在表中创建新行时发送电子邮件通知。定义这些规则有多种选项。其中一个选项是在规则触发器上调用 webhook。这听起来很有希望，所以我研究了这个功能
我创建了一个新的工作流，规则如下：当表中的数据发生变化时调用 webhook。我尝试做的第一件事就是调用元数据 API。但是，我遇到了第一个问题。没有创建 GET 请求的选项，而这是获取元数据所必需的（至少我是这么认为的）。我只能使用 POST、DELETE 和 PATCH 发出请求。经过一段时间的思考和谷歌搜索，我想到了一个主意，那就是使用重定向从 POST 创建 GET 请求。
在 HTTP重定向文档中，我发现某些重定向类型“可能会或可能不会”将 HTTP 方法更改为 GET。我用一些 HTTP 客户端和库进行了测试，实际上，它们都将方法更改为 GET。这正是我需要的。
因此，在我拥有的域名上，我创建了一个 301 重定向（使用 Location 标头）：
Webhook 中的 SSRF
我研究了 AppSheet 的功能，发现了一个名为 Workflows 的部分（今天被“AppSheet Bots”取代）。AppSheet Workflow 通过定义特定规则实现了应用程序行为的自动化。例如 - 当用户在表中创建新行时发送电子邮件通知。定义这些规则有多种选项。其中一个选项是在规则触发器上调用 webhook。这听起来很有希望，所以我研究了这个功能
我创建了一个新的工作流，规则如下：当表中的数据发生变化时调用 webhook。我尝试做的第一件事就是调用元数据 API。但是，我遇到了第一个问题。没有创建 GET 请求的选项，而这是获取元数据所必需的（至少我是这么认为的）。我只能使用 POST、DELETE 和 PATCH 发出请求。经过一段时间的思考和谷歌搜索，我想到了一个主意，那就是使用重定向从 POST 创建 GET 请求。
在 HTTP重定向文档中，我发现某些重定向类型“可能会或可能不会”将 HTTP 方法更改为 GET。我用一些 HTTP 客户端和库进行了测试，实际上，它们都将方法更改为 GET。这正是我需要的。
因此，在我拥有的域名上，我创建了一个 301 重定向（使用 Location 标头）：
http://<MY_DOMAIN>/<ROUTE>到http://169.254.169.254/<ROUTE>
预期的行为是 AppSheet HTTP 客户端将 POST 方法更改为 GET：
POST http://<MY_DOMAIN>/<ROUTE>到GET http://169.254.169.254/<ROUTE>
我在具有以下设置的 webhook 中使用了此重定向（请求指向旧式元数据 API）：
发布 http://<我的域>/computeMetadata/v1beta1/instance/service-accounts/default/token
我保存了工作流程并通过在 AppSheet 应用程序的表中添加新行来触发操作。
几分钟后，我打开应用程序日志并找到了 webhook 调用的记录。日志显示了来自元数据服务器的响应主体。响应中包含 AppSheet 应用程序的访问令牌。
CVE-2022-0778
发现的漏洞会BN_mod_sqrt()在解析椭圆曲线密钥时触发 OpenSSL 函数中的无限循环。这意味着恶意制作的 X.509 证书可以对任何未打补丁的服务器实施 DoS 攻击。
该漏洞的核心在于解析压缩格式的点的 EC 密钥：解析此类密钥时，OpenSSL 将尝试扩展压缩点，尝试计算p定义曲线的素数的平方根模数。但是，在任何地方都不会检查素数p，即使在要求素数的情况下也不会BN_mod_sqrt()；因此，实现中的错误将导致无限循环，因为p不是预期的素数
函数BN_mod_sqrt()实现了求模平方根的Tonelli-Shanksa算法，即给定一个整数和一个素数p，返回一个值r使得r^2 == a (mod p)。
通过分析修补漏洞的提交i，我们发现罪魁祸首是寻找最小索引的循环b^(2^i)==1 (mod p)，其中b已经在算法中定义过。
发现的漏洞会BN_mod_sqrt()在解析椭圆曲线密钥时触发 OpenSSL 函数中的无限循环。这意味着恶意制作的 X.509 证书可以对任何未打补丁的服务器实施 DoS 攻击。
该漏洞的核心在于解析压缩格式的点的 EC 密钥：解析此类密钥时，OpenSSL 将尝试扩展压缩点，尝试计算p定义曲线的素数的平方根模数。但是，在任何地方都不会检查素数p，即使在要求素数的情况下也不会BN_mod_sqrt()；因此，实现中的错误将导致无限循环，因为p不是预期的素数
函数BN_mod_sqrt()实现了求模平方根的Tonelli-Shanksa算法，即给定一个整数和一个素数p，返回一个值r使得r^2 == a (mod p)。
通过分析修补漏洞的提交i，我们发现罪魁祸首是寻找最小索引的循环b^(2^i)==1 (mod p)，其中b已经在算法中定义过。