至此，我们拿到能够获得进行pickle序列化的所有条件
利用场景
Django创建cache文件夹的默认权限是700，这意味无法通过同组的用户来进行改写，但是Django的服务器一般是用nginx或者apache等来启动。有的情况下，nginx服务器底下可能不止一个服务在运行，也可能是PHP或者其他。那么如果其他服务能够进行对临时文件夹tmp或/var/tmp内部的内容进行读写的话，则可以对Django框架进行攻击
利用场景
Django创建cache文件夹的默认权限是700，这意味无法通过同组的用户来进行改写，但是Django的服务器一般是用nginx或者apache等来启动。有的情况下，nginx服务器底下可能不止一个服务在运行，也可能是PHP或者其他。那么如果其他服务能够进行对临时文件夹tmp或/var/tmp内部的内容进行读写的话，则可以对Django框架进行攻击
我们找到了一个名为FBSharedFramework的 Mach-O 64 位共享库二进制文件。我们将使用Hopper Disassembler打开该二进制文件，由于该文件较大，因此需要一些时间才能完全反汇编该二进制文件。
一个好的开始是使用应用程序上显示的警报错误进行搜索。因此，我们将尝试找到导致OpenSSL 证书验证错误的分支。
我们必须将b.ne（“不相等时分支”的缩写）指令反转为b.eq（“不相等时分支”的缩写）指令，前者当且仅当零标志清零时才会分支或“跳转”到指定的地址，后者当且仅当零标志清零时才会分支或“跳转”到指定的地址。因此，它不会进入导致 OpenSSL 证书验证错误的loc_1491b4分支，而是进入有效分支。
一个好的开始是使用应用程序上显示的警报错误进行搜索。因此，我们将尝试找到导致OpenSSL 证书验证错误的分支。
我们必须将b.ne（“不相等时分支”的缩写）指令反转为b.eq（“不相等时分支”的缩写）指令，前者当且仅当零标志清零时才会分支或“跳转”到指定的地址，后者当且仅当零标志清零时才会分支或“跳转”到指定的地址。因此，它不会进入导致 OpenSSL 证书验证错误的loc_1491b4分支，而是进入有效分支。
Spring 处理
恶意请求/xxxxx/..;/admin通过Shiro的校验后，传递到Spring Boot中进行解析，根据Controller设置的路由选择对应Servlet
org.springframework.web.util.UrlPathHelper#getPathWithinServletMapping
恶意请求/xxxxx/..;/admin通过Shiro的校验后，传递到Spring Boot中进行解析，根据Controller设置的路由选择对应Servlet
org.springframework.web.util.UrlPathHelper#getPathWithinServletMapping
对一种加密保护的思想的一点分析.....
【声明】
我写文章以交流为主，希望大家在转载时能保持文章的完整性。
作者： ljtt
写作日期： 2001-05-08
【前言】
有段时间没有写东东，主要是肚子空空如也，没有什么可写的了，这会只好又拿点葫萝卜加白菜的方法，凑合着向大家推销点东西了。
不巧的是今天正好赶上"欢乐时光"，希望不会在我写到最后来个什么惊.....
【分析对象】一类共享软件的保护机制
此共享软件的合法使用方式：电子注册，一机一码，付钱给码。
保护方法：
1、把用户输入的注册码和用户名进行变换得到一个解密数据的KEY。
2、对加密的数据用KEY进行解密。
3、对解密后的数据进行CRC检验，如果检验值正确，则提示注册成功，并"打开"被禁止(或保护)的功能。
以后用户就可以合法使用软件了。
暗藏机关：
现在得说一说这些加密的数据了。:-) 那些加密的数据是被禁止(或保护)的功能要使用到的一些关键数据。
此保护方法优点：
可对付某些形式的暴破。如果只修改跳转方向并不能得到真正解密的数据，而这些数据由于还要在被禁止(或保护)的功能中用到。
如果是KEY不正确，还原出一堆垃圾，那么会在功能使用中出现一些奇异的错误。:-)
此保护方法缺点：
1、如果有一合法用户泄密了KEY，则整个保护体系崩溃。:-)
2、如果加密的数据有明显的特征，则KEY可能会被推测出来。
3、如果加密/解密算法设计不当，也会出问题。
4、好象有已经针对CRC检验的一些破解办法，所以这里说到的CRC检验只是代表类似这样一种检验方法而已，具体用怎样的检验算法还得小心。
这主要是说明这种保护思路中的说明的重要一点就是不要进行明码比较，加密算法使用得再好，如果最后进行直接明码比较，就功亏一溃。
这种方法主要是针对此薄弱点进行的一种探讨。当然要改进之处也很多了。更多的保护方法还是你来吧，我只有三脚猫的功底，说多了就漏了。:-) 当然我想你至少会把这种方式进行迭加，弄它十个几十个解密/CRC检验方式。当然最后的保护效果如何，还是请暴破工程队来说说吧。
【后记】
当然我相信你知道更多更好的加密思想，如果你希望别人和你分享其中思想的闪光点，那么不妨说说吧。当然你也可以给我写信悄悄地告诉我，我猜这大概你已经用在自己编写的软件上了吧。:-)
【声明】
我写文章以交流为主，希望大家在转载时能保持文章的完整性。
作者： ljtt
写作日期： 2001-05-08
【前言】
有段时间没有写东东，主要是肚子空空如也，没有什么可写的了，这会只好又拿点葫萝卜加白菜的方法，凑合着向大家推销点东西了。
不巧的是今天正好赶上"欢乐时光"，希望不会在我写到最后来个什么惊.....
【分析对象】一类共享软件的保护机制
此共享软件的合法使用方式：电子注册，一机一码，付钱给码。
保护方法：
1、把用户输入的注册码和用户名进行变换得到一个解密数据的KEY。
2、对加密的数据用KEY进行解密。
3、对解密后的数据进行CRC检验，如果检验值正确，则提示注册成功，并"打开"被禁止(或保护)的功能。
以后用户就可以合法使用软件了。
暗藏机关：
现在得说一说这些加密的数据了。:-) 那些加密的数据是被禁止(或保护)的功能要使用到的一些关键数据。
此保护方法优点：
可对付某些形式的暴破。如果只修改跳转方向并不能得到真正解密的数据，而这些数据由于还要在被禁止(或保护)的功能中用到。
如果是KEY不正确，还原出一堆垃圾，那么会在功能使用中出现一些奇异的错误。:-)
此保护方法缺点：
1、如果有一合法用户泄密了KEY，则整个保护体系崩溃。:-)
2、如果加密的数据有明显的特征，则KEY可能会被推测出来。
3、如果加密/解密算法设计不当，也会出问题。
4、好象有已经针对CRC检验的一些破解办法，所以这里说到的CRC检验只是代表类似这样一种检验方法而已，具体用怎样的检验算法还得小心。
这主要是说明这种保护思路中的说明的重要一点就是不要进行明码比较，加密算法使用得再好，如果最后进行直接明码比较，就功亏一溃。
这种方法主要是针对此薄弱点进行的一种探讨。当然要改进之处也很多了。更多的保护方法还是你来吧，我只有三脚猫的功底，说多了就漏了。:-) 当然我想你至少会把这种方式进行迭加，弄它十个几十个解密/CRC检验方式。当然最后的保护效果如何，还是请暴破工程队来说说吧。
【后记】
当然我相信你知道更多更好的加密思想，如果你希望别人和你分享其中思想的闪光点，那么不妨说说吧。当然你也可以给我写信悄悄地告诉我，我猜这大概你已经用在自己编写的软件上了吧。:-)
确保文件无损写入。
❯ md5 /tmp/mstlsapi.dll
MD5 (/tmp/mstlsapi.dll) = 99cbcb346f7d2473bde579fbbe979981
PS C:\Users\Public\Downloads> Get-FileHash .\mstlsapi.dll -Algorithm MD5
Algorithm Hash
--------- ----
MD5 99CBCB346F7D2473BDE579FBBE979981
因为 redis 是 Administrator 启动的，所以我们可以写入劫持文件到 C:\Windows
❯ md5 /tmp/mstlsapi.dll
MD5 (/tmp/mstlsapi.dll) = 99cbcb346f7d2473bde579fbbe979981
PS C:\Users\Public\Downloads> Get-FileHash .\mstlsapi.dll -Algorithm MD5
Algorithm Hash
--------- ----
MD5 99CBCB346F7D2473BDE579FBBE979981
因为 redis 是 Administrator 启动的，所以我们可以写入劫持文件到 C:\Windows
寻找Fastjson 1.2.68 AutoCloseable利用链
我在Java漏洞方向没有长期积累，水平有限，细究这个洞后找不到rt.jar中的利用链。我没有那些大框架、大中间件的测试环境，所以也没有触及潜在的高危链。后来我想开了，咱也装不了Java大拿，就在第三方库中找软柿子捏，于是就有了文字。
不作漏洞分析，[87]把该讲的都讲清楚了，没啥好分析的。论文给出一个现实世界的极小众PoC，利用第三方库向指定文件写入指定内容。严格标准讲，也不算现实世界的PoC，因为所用的两个第三方库可能并不会同时出现，但至少比自己写一个纯原理性的PoC劝告力一些。另外，本文写了我是怎么找到利用链的，简单点说，写程序在maven的本地仓库中愣找，先得到一个大致范围，再手动过滤。
☆ 1.2.68漏洞复现尝试
1) 清空指定文件
1.1）AutoCloseable_TruncateFile.json
我在Java漏洞方向没有长期积累，水平有限，细究这个洞后找不到rt.jar中的利用链。我没有那些大框架、大中间件的测试环境，所以也没有触及潜在的高危链。后来我想开了，咱也装不了Java大拿，就在第三方库中找软柿子捏，于是就有了文字。
不作漏洞分析，[87]把该讲的都讲清楚了，没啥好分析的。论文给出一个现实世界的极小众PoC，利用第三方库向指定文件写入指定内容。严格标准讲，也不算现实世界的PoC，因为所用的两个第三方库可能并不会同时出现，但至少比自己写一个纯原理性的PoC劝告力一些。另外，本文写了我是怎么找到利用链的，简单点说，写程序在maven的本地仓库中愣找，先得到一个大致范围，再手动过滤。
☆ 1.2.68漏洞复现尝试
1) 清空指定文件
1.1）AutoCloseable_TruncateFile.json
FindSomeClass3.java
纯手工找这三类不太可能，曾经在rt.jar中手工过，学艺不精，未能得逞。退而求其次，在maven的本地仓库中寻找潜在可用的第三方库，这需要写程序完成
FindSomeClass3.java是个示例性框架，根据需要写自己的过滤逻辑即可。有些代码没必要，懒得删减，领会精神
今天跟金超前吐槽，为啥我这么执着找一条这个洞的利用链，主要是看不惯除原发现者外面的一群2B藏着掖着的德性。原发现者不给PoC我理解，后面还有一些吹NB的一通神吹装个B完事，这种特看不惯。他们应该是找到了一些链，但我觉得这没必要藏着掖着，尤其不是自带库的情况下。如果找到了，不吹这个牛，自己留着用，这也无可厚非
纯手工找这三类不太可能，曾经在rt.jar中手工过，学艺不精，未能得逞。退而求其次，在maven的本地仓库中寻找潜在可用的第三方库，这需要写程序完成
FindSomeClass3.java是个示例性框架，根据需要写自己的过滤逻辑即可。有些代码没必要，懒得删减，领会精神
今天跟金超前吐槽，为啥我这么执着找一条这个洞的利用链，主要是看不惯除原发现者外面的一群2B藏着掖着的德性。原发现者不给PoC我理解，后面还有一些吹NB的一通神吹装个B完事，这种特看不惯。他们应该是找到了一些链，但我觉得这没必要藏着掖着，尤其不是自带库的情况下。如果找到了，不吹这个牛，自己留着用，这也无可厚非
一些细节的坑点就不展开说了，总之就是各种反射各种 try/catch，我尽了最大的努力来提高其对各种 Tomcat 环境的兼容性，文章最后会将这个成果分享给大家。有了这个比较好用的回显 payload，搭配 K1/K2 来触发反序列化流程，就打造成了 xray 高级版/商业版中 Shiro 反序列化回显检测的核心逻辑，回显效果如下
使用 xray 扫到过 xss 的同学应该都有所体会，xray 扫到的 xss 漏洞不一定可以直接弹框，但相关参数一定存在可控的代码注入，经常会遇到网站存在 waf 但 xray 依然可以识别出 xss 的情况。纵观整个 Shiro 反序列化的流程，步步都是在针尖上跳舞，一步出错便前功尽弃。倘若目标站点部署了 RASP 等主机防护手段，很有可能导致反序列化中断而与 RCE 擦肩而过，有没有什么办法能够像 xss 一样大幅的提高其检测能力的下限呢？和 l1nk3r 师傅交流了一下，他提到一种检测 Shiro Key 的方法很不错，据说原理来自 shiro_tool.jar ，详情可以参考这篇文章一种另类的 shiro 检测方式 ，我这里简单复述一下结论
使用 xray 扫到过 xss 的同学应该都有所体会，xray 扫到的 xss 漏洞不一定可以直接弹框，但相关参数一定存在可控的代码注入，经常会遇到网站存在 waf 但 xray 依然可以识别出 xss 的情况。纵观整个 Shiro 反序列化的流程，步步都是在针尖上跳舞，一步出错便前功尽弃。倘若目标站点部署了 RASP 等主机防护手段，很有可能导致反序列化中断而与 RCE 擦肩而过，有没有什么办法能够像 xss 一样大幅的提高其检测能力的下限呢？和 l1nk3r 师傅交流了一下，他提到一种检测 Shiro Key 的方法很不错，据说原理来自 shiro_tool.jar ，详情可以参考这篇文章一种另类的 shiro 检测方式 ，我这里简单复述一下结论
案例研究
让我们看看将这种方法应用于真实网站时会发生什么。在本节中，我将探讨一系列缓存密钥处理漏洞，这些漏洞来源于有漏洞赏金计划的网站，并分享一些可以与之结合的小工具。
无键查询检测
最常见的缓存键转换是从键中排除整个查询字符串。我确信有些人在我之前就已经认识到并利用了这种行为，但它肯定没有得到充分重视。与直觉相反，它也很难被发现，因为它将动态页面伪装成静态页面。您可以通过更改参数的值并观察响应中的某种差异来轻松识别大多数动态页面
让我们看看将这种方法应用于真实网站时会发生什么。在本节中，我将探讨一系列缓存密钥处理漏洞，这些漏洞来源于有漏洞赏金计划的网站，并分享一些可以与之结合的小工具。
无键查询检测
最常见的缓存键转换是从键中排除整个查询字符串。我确信有些人在我之前就已经认识到并利用了这种行为，但它肯定没有得到充分重视。与直觉相反，它也很难被发现，因为它将动态页面伪装成静态页面。您可以通过更改参数的值并观察响应中的某种差异来轻松识别大多数动态页面
WebLogic coherence UniversalExtractor 反序列化 (CVE-2020-14645) 漏洞分析
该漏洞是针对于CVE-2020-2883的补丁绕过，CVE-2020-2883补丁将MvelExtractor和ReflectionExtractor列入黑名单，因此需要另外寻找一个存在extract且方法内存在恶意操作的类，这里用到的类为com.tangosol.util.extractor.UniversalExtractor,存在于Coherence组件。
其本质上，都是通过ReflectionExtractor调用任意方法，从而实现调用Runtime对象的exec方法执行任意命令，但补丁现在已经将ReflectionExtractor列入黑名单，那么只能使用UniversalExtractor重新构造一条利用链，这里使用poc2的入口即CommonsCollections4链的入口进行构造。
该漏洞是针对于CVE-2020-2883的补丁绕过，CVE-2020-2883补丁将MvelExtractor和ReflectionExtractor列入黑名单，因此需要另外寻找一个存在extract且方法内存在恶意操作的类，这里用到的类为com.tangosol.util.extractor.UniversalExtractor,存在于Coherence组件。
其本质上，都是通过ReflectionExtractor调用任意方法，从而实现调用Runtime对象的exec方法执行任意命令，但补丁现在已经将ReflectionExtractor列入黑名单，那么只能使用UniversalExtractor重新构造一条利用链，这里使用poc2的入口即CommonsCollections4链的入口进行构造。
是在PriorityQueue的构造函数中被赋值的，并且这里可以看到，queue对象数组也是在这里被初始化的。那么结合上述所分析的点，我们需要构造一个长度为2的queue对象数组，才能触发排序，进入siftDown()方法。同时还要选择一个comparator，这里选用ExtractorComparator。继续跟进ExtractorComparator.compare()方法
各种 Linux 权限提升技术，例如内核和服务漏洞、理解 SUID、管理计划任务和导航密码发现。
这些技术和工具，从利用错误配置的 sudo 权限到利用易受攻击的服务，都是渗透测试人员工具包的重要组成部分。您已经学会了如何通过手动方法和自动化工具进行枚举。
一个以明文形式存储的用户名“root”和密码“john@123”。让我们看看是否可以使用找到的密码切换到 sickos 用户。有时密码会在多个服务中重复使用。
将 www-data 用户提升为 sickos 用户。与往常一样，让我们使用该sudo -l 命令检查我们是否有任何 sudo 权限。
以 root 用户身份运行所有命令，因此我们运行sudo su。现在有一个 root shell。
这些技术和工具，从利用错误配置的 sudo 权限到利用易受攻击的服务，都是渗透测试人员工具包的重要组成部分。您已经学会了如何通过手动方法和自动化工具进行枚举。
一个以明文形式存储的用户名“root”和密码“john@123”。让我们看看是否可以使用找到的密码切换到 sickos 用户。有时密码会在多个服务中重复使用。
将 www-data 用户提升为 sickos 用户。与往常一样，让我们使用该sudo -l 命令检查我们是否有任何 sudo 权限。
以 root 用户身份运行所有命令，因此我们运行sudo su。现在有一个 root shell。