当我们要为我们的代码附加别的功能的时候，我们往往写一个代理类来实现对当前类的封装，该代理类不实现具体的代码逻辑，只是提供了额外的功能，但如果我有很多的类需要封装一样的功能，那么我就得写很多的代理类，这种方式耗时严重且不易维护，是极为不可取的。所以JAVA为我们提供了动态代理的方式来一劳永逸，貌似大名鼎鼎的AOP就是通过动态代理的方式实现的，那我们来写一个动态代理的例子。

嗯，感觉以前对这个概念的理解不是很清楚，今天抽了时间再学习了学习。

JNDI提供了一个统一的接口屏蔽了一些协议负载的调用与使用过程，如RMI、LDAP、COBRA等，主要功能是实现了远程方法调用，针对JNID的攻击一般有以下两种，一种是注册在远程的对象由一些危险的方法，那么我们便可以直接使用注册中兴对外暴露的接口调用这些危险的方法来实现攻击，一类是我们可以直接在客户端向注册中心直接注册一个恶意对象，因为对象在传输过程中时序列化传输的，那么注册中心再加载该对象的时候会进行反序列化操作，那么如果我们的恶意对象的静态代码块中有一些危险操作那么便会直接被执行，因为静态代码块中的方法是在类加载过程中被调用的，且只会调用一次。
关于第一种情况，没什么好说的，只要我们能够远程调用接口便能完成攻击，当然是在你知道对方注册了什么危险对象的基础上。第二种情况也分多种情况，一是我们可以直接向远程注册恶意对象。二是我们可以利用JNDI的动态类加载机制完成攻击，一是利用CodeBase机制，如果客户端的lookup参数内容可控，那么我们便可以自行搭建一个注册中心，注册恶意类。那么客户端在调用的时候就会调用到我们的恶意对象，但是这有一个问题，如果是我们自行注册的恶意对象，那么客户端如果没有这个恶意类，客户端也是不会反序列化成功的，利用CodeBase机制我们可以在服务端指定恶意类的加载地址，当客户端请求该恶意对象的时候，客户端会一并将CodeBase指定的地址发送个客户端，如果客户端没有这个恶意类那么则会使用CodeBase指定的地址去加载恶意类，从而完成恶意类的自动调用。这里注意CodeBase是双向指定的，客户端可以指定，服务端也可以指定，当然优先使用的是服务端指定的地址。麻烦的是一些版本的JDK模式不允许CodeBase远程类加载，而且还涉及到java的安全管理器。另一种情况是利用JNDI Naming Reference，Reference类表示对存在于命名/目录系统以外的对象的引用，如果注册在注册中心的对象为Reference类的子类，那么再客户端获取到远程对象的存根实例的时候将使用Reference对象指定的远程地址与类名去加载恶意类从而完成攻击，可以注意到，这个攻击发生在客户端。因为Reference没有继承UnicastRemoteObject，所以我们需要对Reference类使用ReferenceWrapper对其进行包装，然后绑定在注册中心中才能实现远程调用。两种情况重点都是需要lookup函数参数可控，也就是可以指定远程服务器的位置，当然你如果可以操控对方远程服务器又另说。
这里我们介绍一下通过Reference类来实现JNDI注入，首先我们写一个客户端。

JEP 290是 oracle提供已一套JAVA反序列化机制，其并不是一种必须被强制执行的策略，而是需要程序员或者运维人员进行开发与启用。关于该机制的优缺点借用老外的一篇文章

本文介绍了 OPENSSL拒绝服务漏洞【CVE-2022-0778】

@TOC
前段时间不是爆了个log4j的远程代码执行漏洞吗！趁机我就了解了一下什么事jndi，然后就接触到了ldap与rmi，所有准备好好学习一番……

以上内容纯属瞎编，如有雷同，绝对是巧合。

其实很久以前就了解过jndi，但那时候感觉积累不够深，所有一直对他的原理没有搞清楚，看的各种文章也是云里雾里的，直到最近在反复研磨了网络上的文章之后，终于有了一点点心得，特此在这里记录一下。

这两天没啥工作，一般这时候我都不会发挥自己的主观能动性去主动找活，于是乎只能上网看看博客，提升提升自己的技术。想起在这家公司呆久了把内网方面本来就不多的知识都快丢光了，于是乎趁着难得清闲准备补充补充营养。看了一些与内网穿透相关的博客，准备实操的时候遇到了麻烦。本着逢山开路遇水架桥的精神，今天势必要把这个问题拿下。

问题描述

Regeorg是只提供了对python2的支持，使用python3来运行爆了一大串错我，今天咱就一个问题一个问题得搞定，手把手教你怎么把Regeorg改造成python3版本。看了下这个项目8年前年就停止更新了

上班没有任务你们都干什么，反正我是不会摸鱼的，这辈子都不可能摸鱼的，复现这个漏洞的初衷是看了某公众号关于Vmware Workspace One Access的jdbc注入漏洞，文中值分析到jdbc url可控的部分，但是我不太清楚为什么jdbc可控就会导致任意文件写入，于是上网搜了jdbc注入的文章，于是找到了这儿：

本文提供了ThinkPHP5.0.24反序列化POC

本文提供了ThinkPHP6.x反序列化POC

全公司最大的黑阔在群里发了一张截图是老外发的关于这个漏洞复现的截图，于是我昨天看了很久他的源码，开始还是很难受的，可以知道的信息就是这是一个文件上传漏洞，看了最新发布的版本的修改

https://github.com/wso2/carbon-kernel/pull/3152/files