Y0n3er

练手地址：https://github.com/0ctDay/encrypt-decrypt-vuls JsRpc：https://github.com/jxhczhl/JsRpc JsRpc基本使用首先观察一下原始的数据包 可以看到除了请求体需要解密，还有请求头中的timestamp、requestId、sign 需要实时更新，所以请求包中总共有四个地方需要处理，由于是直接只用JsRpc，那么就只需要找到对应的处理位置然后调用即可，不需要弄清楚具体的处理逻辑 可以看到就是图中的几个地方处理的，具体逻辑就不分析了，主要是学会使用jsrpc 首先把这几个函数先提升到全局，需要先断点让其加载到作用域 然后在控制台执行下面语句提升至全局作用域 12345678window.requestId=p//requestIdwindow.v1 = v//函数vwindow.sign=a.a.MD5//签名signwindow.l=lwindow.d=d 然后注入jsrpc中的js文件JsEnv_Dev.js ，注意注js的时候断点就得停止了 然后启动jsrpc服务端 再客户端连接 1 ...

为什么说是假呢？因为这个”权限绕过“只是方便开发测试，毕竟应该没人会把开发环境直接放到公网吧 项目地址Releases · 1024-lab/smart-admin https://gitee.com/lab1024/smart-admin/ 漏洞分析（权限绕过）首先看了看项目的依赖，基本上没得搞，fastjson为2，看一下拦截器在MvcConfig 下注册添加了AdminInterceptor 为拦截器 123456@Overridepublic void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(adminInterceptor) .excludePathPatterns(SwaggerConfig.SWAGGER_WHITELIST) .addPathPatterns("/**");} excludePathPatterns 方法为不需要拦截的路径，即SWAGGER_WHITE ...

看到p神的vulhub环境更新了，正好是个权限绕过，对这块不太熟复现一手 影响版本及编号Affected versions：>= 1.0.0, < 1.5.0 CVE-2024-43441 漏洞分析既然是权限绕过，那么就得分析鉴权，直接找login，在hugegraph-server下的hugegraph-api找到登录接口src/main/java/org/apache/hugegraph/api/auth/LoginAPI.java 但是奇怪的是无法走进这里生成token的逻辑，直接就进入了AuthenticationFilter#filter 中进行token的校验了，那么就可以先看一下校验，进入authenticate 方法，当设置好jwt格式的请求头后就会走到下面的jwt校验 1Authorization: Bearer ... 继续跟进来到下面的代码 1234public HugeAuthenticator.User authenticate(Map<String, String> credentials) throws ...

SU_ez_solon solon框架触发getter新链，结合h2 rce 调试我这里是用cfr进行的反编译（有时候又不太行），然后启动项目进行的调试，用上面方法似乎只能调那个框架 前不久ccb也遇到过这个框架的Java题，不过那个是利用Linux jdk中的类作为sink点，懒得搭环境看了下wp没复现 这个题是直接给了hessian反序列化，然后调用了toString方法 12345678910111213@Controllerpublic class IndexController { public IndexController() { } @Mapping("/hello") public String hello(@Param(defaultValue = "hello") String data) throws Exception { byte[] decode = Base64.getDecoder().decode(data); Hes ...

前言遇到两个之前没练过的Java题类型，做一下学学 一写一个不吱声 💡 fatjar rce 根据描述肯定是存在一个任意文件写入的，看依赖有个aspectjweaver-1.9.5.jar，简单分析一下这个jar的任意文件写入 在\org\aspectj\weaver\tools\cache\SimpleCache.class下有个内部类StoreableCachingMap 在里面的put方法中存在文件写入 1234567891011public Object put(Object key, Object value) { IOException e; try { e = null; byte[] valueBytes = (byte[])((byte[])value); String path; if (Arrays.equals(valueBytes, SimpleCache.SAME_BYTES)) { path = "IDEM" ...

这个题链子很简单，都是已经公开的，就是有些点有点坑 拿到附件反编译，本地起环境用cfr就行，确实比较方便 题目分析这里我一开始是直接找反序列化的点，在UserControler 下 但是这里有shiro权限校验 看shiro版本1.2.4是可以绕过的，加个/ 即可绕过 所以可以直接来到反序列化这里，然后就是黑名单了 12private static final String[] blacklist = new String[]{"java.lang.Runtime", "java.lang.ProcessBuilder", "com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl", "java.security.SignedObject", "com.sun.jndi.ldap.LdapAttribute", "org.apache.commons.beanutils", "or ...

随手记录一下 触发点分析我这里的代码是FineBI5.1.0的，在这个版本路由是通过注解形式实现的，因为是复现所以直接来到漏洞接口 可以看到这个channel接口就是我们漏洞点了，在这个文件的接口都是在/remote/design 路由下 但是实际访问需要加上包名/decision/至于/webroot/应该就是整个项目的目录名了，具体的路由定义没找到，只能这样猜测了，关于路由分析还是得再练练。。。 可以看到在channel接口下获取了request请求，将其转化为输入流，然后写进输出流（感觉Java的IO流也得好好学学，整的我一愣一愣的），过程中调用了WorkContext.handleMessage() **对请求进行了处理，直接跟进这个方法 然后*messageListener* 是WorkspaceMessageHandler 的对象自然也就跳转到这个接口了，这里实现了这个接口的类应该只有一个，我点击跟进直接就跳转了 看到了类似反序列化的方法deserializeInvocation 跟进 此时就得注意了，除了我们可控的参数流 ...

本文首发于先知社区：https://xz.aliyun.com/t/14957 前言看到星球发布了一个作业，由于考试没及时弄。所以就自己随便看看了，这套系统确实漏洞很多，可以说是靶场。。。危险操作几乎都没有做过滤，而且很久没更新了 后台任意文件删除这个洞提了cve，看大家都在水我也水一个 漏洞很简单，甚至不需要白盒，黑盒能直接测出来，但是代码审计还是看代码吧，我审这个的时候也是直接看的代码，代码位置在src/main/java/com/cms/controller/admin/DatabaseController.java 文件下的/delete 接口 跟进这个delete方法 可以看到对这个参数没有做任何的检测，仅仅只看了文件是否存在 poc如下 123456789101112131415161718192021POST /admin/database/delete HTTP/1.1Host: 127.0.0.1:8888Cache-Control: max-age=0sec-ch-ua: "Chromium";v="113", " ...

SQL注入点寻找当时的通报是这个，当时在3.2.5版本根本没有修复这个sql注入，对着commit提交的那几个路由一直找也没找出注入点。。。不久后发布了3.2.6版本一眼就能看出注入点 很明显看到对item_id 进行了修复做了应该是预处理，来到源码看一下 记得当时分析的时候对page_id/d 这种写法看了很久，后面调试的时候一步步跟进去才明白作用，其实就是做强转处理 所有这里的I接收的参数后面只能为空或者s这两种，否则就会被强转为其它的，很明显没有做任何处理，直接拼接进了sql语句中符合要求即注入点 注入过程在注入的过程中遇到了一个点就是下面这段检测代码 1234if (!D("Captcha")->check($captcha_id, $captcha)) { $this->sendError(10206, L('verification_code_are_incorrect')); return;} 当时半天没搞懂这怎么绕，后面翻译了一下这个单词，其实就是验证码。。。那么就只需要去弄个 ...

先看看C3p0是干什么的 C3P0是一个开源的JDBC连接池，它实现了数据源和JNDI绑定，支持JDBC3规范和JDBC2的标准扩展。目前使用它的开源项目有Hibernate，Spring等。 JDBC是Java DataBase Connectivity的缩写，它是Java程序访问数据库的标准接口。使用Java程序访问数据库时，Java代码并不是直接通过TCP连接去访问数据库，而是通过JDBC接口来访问，而JDBC接口则通过JDBC驱动来实现真正对数据库的访问。 连接池类似于线程池，在一些情况下我们会频繁地操作数据库，此时Java在连接数据库时会频繁地创建或销毁句柄，增大资源的消耗。为了避免这样一种情况，我们可以提前创建好一些连接句柄，需要使用时直接使用句柄，不需要时可将其放回连接池中，准备下一次的使用。类似这样一种能够复用句柄的技术就是池技术。 说实话，还是没能理解在开发中的作用，还是得开发实战一下才能理解。。。依赖 12345<dependency> <groupId>com.mchange</groupId> &l ...

前言好久没更新博客了，感觉学到后面不懂的东西更多，通常学一个东西为了理解它就要学更多的东西，所以越来越不想更新博客了。。。 环境项目地址：https://gitee.com/LinZhaoguan/pb-cms/tree/v1.0.0/ shiro反序列化漏洞直接来看pom.xml文件，搜到shiro1.4.1版本，采用的加密模式还是AES-CBC，从1.4.2版本开始采用的是AES-GCM所以直接拿工具一把梭即可然后命令执行在这里1.4.1版本其实shiro550不能打，打shiro550版本要小于1.2.4。但是在shiro反序列化漏洞修复的时候如果仅对shiro版本升级而没有重新生成密钥那么AES加密的默认密钥硬编码仍然会在代码里面，就会同样存在反序列化风险，这里去看看是否存在确实存在，位置在src/main/java/com/puboot/common/config/ShiroConfig.java搜了一下这里怎么生成一个新的shirokey，可以利用官方提供的方法生成一个 123456789101112131415161718import org.apache.shiro.c ...

黑名单绕过（常规手段）这个绕过就是利用黑名单之外的函数去执行命令，但是我在测试这个黑名单绕过的时候发现了一个很迷惑的点，在Windows下我禁用了eval和system函数hackbar确实不能执行system函数了但是蚁剑上面任然可以命令执行另外eval函数也任然可以执行岂不是相当于禁用eval函数没用？？这个时候的php版本为5.4.45，然后是Linux下的测试，我也禁用了eval、system做测试，eval函数照样正常执行然后尝试system函数然后尝试用以蚁剑去执行命令蚁剑还是可以正常执行命令，然后我再网上找了一下经常禁掉的函数全部加上去 1exec,passthru,popen,shell_exec,proc_open,proc_terminate,curl_exec,curl_multi_exec,show_source,touch,escapeshellcmd,escapeshellarg,eval,system 此时蚁剑无法正常命令执行了然后我在Windows下也加上那一堆函数，然后蚁剑此时也无法正常命令执行了然后把system放出来之后可以正常执行命令，此时就猜测 ...