1.如何看待最新爆出的漏洞s漏'红雨蘑菇'iis服务器远程代码执行漏洞?
2.CVE-2021-3019 Lanproxy 目录遍历漏洞
3.浅谈URI中的任意文件下载
4.FastAdmin前台文件上传漏洞讲解
5.容易被忽略的ErrorHandling错误处理
如何看待最新爆出的'红雨蘑菇'iis服务器远程代码执行漏洞?
Apache ActiveMQ官方发布新版本，修复了一个远程代码执行漏洞（CNVD-- CVE--）。源码该漏洞允许攻击者通过Apache ActiveMQ的漏洞s漏端口发送恶意数据，从而导致远程代码执行，源码完全控制服务器。漏洞s漏影响的源码修改java jar包源码版本包括环境搭建的多个阶段。考虑到没有找到合适的漏洞s漏Docker镜像，我们尝试自己编写并分析Dockerfile，源码结合官方文档，漏洞s漏使用docker-compose.yml进行环境配置。源码
在漏洞分析阶段，漏洞s漏我们下载源代码，源码并在apache-activemq-5..2\bin\activemq文件中开启调试模式。漏洞s漏通过github.com/apache/activm找到新版本修复的源码漏洞位置，即org.apache.activemq.openwire.v.BaseDataStreamMarshaller#createThrowable方法。漏洞s漏该方法允许控制ClassName和message，进而调用任意类的String构造方法。结合ActiveMQ内置的Spring框架，利用org.springframework.context.support.ClassPathXmlApplicationContext加载远程配置文件实现SPEL表达式注入。
为了深入学习，android studio源码开发我们整理了一份全套资料，包括网安学习成长路径思维导图、+网安经典常用工具包、+SRC分析报告、+网安攻防实战技术电子书、权威CISSP认证考试指南、最新网安大厂面试题合集、APP客户端安全检测指南（安卓+IOS）等资源，帮助网安学习者全面成长。
在寻找漏洞触发点的过程中，我们关注到org.apache.activemq.ActiveMQSession#asyncSendPacket和org.apache.activemq.ActiveMQSession#syncSendPacket函数可以发送command，最后调用org.apache.activemq.transport.tcp.TcpTransport#oneway或((ActiveMQConnection)connection).getTransportChannel().oneway/expetionResponse;进行触发。由于ExceptionResponse实例化需要Throwable类型，我们修改ClassPathXmlApplicationContext继承Throwable类型以实现触发。
通过数据流触发ExceptionResponseMarshaller，主要是依据ActiveMQ协议，利用伪造类实现触发ExceptionResponse。利用org.apache.activemq.transport.tcp.TcpTransport#readCommand与wireFormat.unmarshal数据处理逻辑，我们找到对应的领取POS机源码wireFormat.marshal，最终通过本地重写TcpTransport类优先触发本地实现，将发送请求修改为触发ExceptionResponseMarshaller。同样，修改ClassPathXmlApplicationContext继承Throwable类型以满足ExceptionResponse实例化需求。
总结以上步骤，我们完成了对Apache ActiveMQ远程代码执行漏洞的复现与分析，强调了安全实践的重要性并提供了一系列资源支持，以帮助网络安全专业人士深入学习与应对类似威胁。
CVE-- Lanproxy 目录遍历漏洞
Lanproxy 0.1版本存在路径遍历漏洞，允许攻击者通过访问“../conf/config.properties”获取到内部网连接的凭据。Lanproxy是一个用于局域网穿透的代理工具，支持各种tcp流量转发。
修复前，开发者需通过补丁修复此漏洞，方法为在路径中检测到“../”时直接返回“Forbidden”。漏洞成因在于对用户输入路径未进行过滤，攻击者可利用该漏洞访问任意文件。
环境搭建包括漏洞复现步骤，首先拉取源码，驱动读写sys源码然后回退到漏洞修复之前版本。使用命令“git clone”拉取代码，回退版本并进行Maven编译，编译完成后在项目根目录生成distribution目录，包含服务端与客户端。
测试漏洞时，运行启动命令并访问端口验证环境是否成功启动，利用Payload获取config.properties文件内容，此文件包含管理页面用户名、密码、以及ssl相关配置信息。
深入分析，通过启动脚本中的debug参数开启调试模式，使用IDEA配置动态调试，打断点至HttpRequestHandler.java#outputPages处。通过URI实例获取uriPath，进行路径判断，最终通过RandomAccessFile()读取config.properties文件。
对于该漏洞的jsp实现拍照源码修复建议是安装最新版本的Lanproxy，可通过源码或最新安装包进行更新，以确保安全。
浅谈URI中的任意文件下载
文件下载业务中，URI的正确处理是关键。通常，接口形式如//download?fileName=xxx.png，若未过滤目录穿越符号如...或未限制下载路径，传入参数如../../etc/passwd即可实现路径穿越，下载任意文件。解析URI以得到文件名，如/file/test.jpg，尝试访问/file/../../test.jpg时，中间件或框架在解析路由时会有所处理。那么，能否通过此途径进行目录穿越并利用呢？
在实际项目中，一个文件下载的实现使用了Spring框架的FileCopyUtils.copy()方法。文件路径filepath通过req.getRequestURI()获取，此方法不规范URI中的特殊字符，直接拼接路径并读取文件，未限制下载目录且未过滤敏感关键字，存在任意文件下载风险。
当前项目的upload目录结构如下：
访问../WEB-INF/web.xml，成功穿越到上级目录WebContent，并获取web.xml配置信息。中间件处理../，使其等同于直接访问/userfiles/WEB-INF/web.xml。若尝试读取更敏感文件如/etc/passwd，需要多级../，但tomcat处理后已不在有效目录范围内，返回异常。尝试扩大漏洞危害，编码请求触发 Invalid URI错误，tomcat对保留字符;进行截断并处理为参数。在编码基础上再次访问，获取路径为/upload/;/../../../../../../../../etc/passwd，返回状态码。
结合网站其他业务，可以创建名为;的目录，访问/userfiles/upload/;%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2f..%2fetc%2fpasswd，成功下载敏感文件。
引入@PathVariable注解，用于接收请求路径中的占位符值，可以实现文件下载，如访问/var/work/download/{ filename}，下载名为{ filename}的文件。参数在URI中，利用还需探究。
通常，直接使用../../../目录穿越尝试下载/etc/passwd等敏感文件，中间件解析时已处理../，参数filename无法利用。处理后URI为/file/etc/passwd，未找到映射，返回。
尝试对/编码访问，tomcat源码检测到%2F斜杠返回状态码。源码流程包括解码和格式化URI。Spring对URI进行一次解码，如/file/get/..%fetc/passwd变为/file/get%2fetc/passwd。
在前端用JS对URL编码，忽略Spring的解码操作。使用双重URL编码处理../请求，绕过中间件和Spring的URLDecode，实现目录穿越，成功下载内容。
集成Shiro框架时，案例一中的;可能需要编码为%3b。Shiro高版本对编码进行处理，继续利用需深思。
FastAdmin前台文件上传漏洞讲解
漏洞点定位在FastAdmin的application \ api \ controller \ Common.php，触发漏洞的网址为/index/ajax/upload。要求是在application \ extra \ upload.php中设置chunking为true，即启用分片上传。
复现过程解析如下：
在分析脆弱点时，需确保post请求参数齐全，包括chunkid、action、chunkindex、chunkcount、filename。调用chunk函数chunk($chunkid, $chunkindex, $chunkcount)后，程序进入分片文件上传流程。
具体步骤为：
1. 声明变量$destDir为RUNTIME_PATH / chunks，其中RUNTIME等于ROOT_PATH，表示运行路径。
2. 根据输入的参数，动态生成文件名$fileName为$chunkid-$chunkindex.part。
3. 将$destDir与$fileName连接，形成最终的文件路径。
4. 判断RUNTIME_PATH / chunks路径是否存在，若不存在则创建文件夹。
5. 将临时文件移动至RUNTIME_PATH / chunks路径。
之后，触发合并函数，要求action参数为“合并”。此步骤中，$chunkDir变量取自RUNTIME_PATH “块”。
执行合并逻辑如下：
1. 首先，计算文件路径为RUNTIME_PATH 'chunks' + $chunkid。
2. 根据$chunkcount进行循环，判断$filePath- $i-.part文件是否存在。
3. 如果文件存在，在/ runtime / chunks路径下创建以$filePath作为文件名的新文件。
4. 打开文件并锁定。
5. 通过$chunkcount参数控制循环读取与写入操作，文件路径动态构建为$filePath。
6. 循环读取并写入文件内容，直至完成所有分片的合并。
在执行合并操作时，需关注参数控制，确保文件路径的动态生成过程不会导致路径穿越或文件系统破坏等风险。
更多深入分析与实验案例可参考以下链接：
exp地址：/post/
