Y0n3er

CVE-2025-24813，跟的不是很细，大概复现了一下 环境搭建可以本地搭，我这里为了方便直接用docker了 123456789101112131415version: '3.8'services: tomcat: image: tomcat:9.0.8-jre8-slim container_name: CVE-2025-24813 volumes: - ./web.xml:/usr/local/tomcat/conf/web.xml - ./context.xml:/usr/local/tomcat/conf/context.xml - ./commons-collections-3.2.1.jar:/usr/local/tomcat/webapps/ROOT/WEB-INF/lib/commons-collections-3.2.1.jar ports: - "8080:8080" - "8000:8000" environment: ...

之前打ctf线下赛遇到过这个系统，一直想分析来着，搁置到现在。。。 影响版本<=1.4.0 环境搭建无敌的p神没得说，还贴心配置了调试端口 https://github.com/vulhub/vulhub/blob/master/aj-report/CNVD-2024-15077/README.zh-cn.md 权限绕过这类的漏洞一般就是Filter之类的写的有问题导致的权限绕过，直接来到TokenFilter 可以看到这里直接用了getRequestURI 获取的接口，这个东西之前就爆出来有解析差异导致的权限绕过，下面刚刚好有个url包含swagger-ui 就直接放行，那么利用; 就可以直接绕过权限校验 可以看到这样直接就绕过了权限校验，之前没分析过，借此分析一下。 Tomcat和getRequestURI结合导致的权限绕过tomcat的处理在CoyoteAdapter.service() 方法中，这里我对getRequestURI 和这个service 都下了断点，首先在service 断住了，说明是tomcat先处理url，调用栈如下 12345678910 ...

本文首发于先知社区：文章 - JsRpc联动burp实现自动加解密（详细版） - 先知社区 练手地址：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 ...

本文首发于先知社区：https://xz.aliyun.com/news/17175 为什么说是假呢？因为这个”权限绕过“只是方便开发测试，毕竟应该没人会把开发环境直接放到公网吧 项目地址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("/**");} e ...

看到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 ...