将shell.war上传到远程服务器上，在该目录下利用python临时开启一个http服务
填写完成后点击invoke,若成功会提示部署成功，点击下图中的Back to MBean View
填写完成后点击invoke,若成功会提示部署成功，点击下图中的Back to MBean View
通过分析rand.Intn()的源码，可见，在”math/rand” 包中，如果没有设置随机种子， Int() 函数自己初始化了一个 lockedSource 后产生伪随机数，并且初始化时随机种子被设置为1。因此不管重复执行多少次代码，每次随机种子都是固定值，输出的伪随机数数列也就固定了。所以如果能猜测到程序使用的初值（种子），那么就可以生成同一数序的伪随机数
不当的函数地址使用
错误的将函数地址当作函数、条件表达式、运算操作对象使用，甚至参与逻辑运算，将导致各种非预期的程序行为发生。比如在如下if语句，其中func()为程序中定义的一个函数:
if (func == nil) {
...
}
由于使用func而不是func()，也就是使用的是func的地址而不是函数的返回值，而函数的地址不等于nil，如果用函数地址与nil作比较时，将使其条件判断恒为false
不当的函数地址使用
错误的将函数地址当作函数、条件表达式、运算操作对象使用，甚至参与逻辑运算，将导致各种非预期的程序行为发生。比如在如下if语句，其中func()为程序中定义的一个函数:
if (func == nil) {
...
}
由于使用func而不是func()，也就是使用的是func的地址而不是函数的返回值，而函数的地址不等于nil，如果用函数地址与nil作比较时，将使其条件判断恒为false
DataCon2020题解：通过蜜罐与DNS流量追踪Botnet
[CTF]
原题信息
1.1 背景
Datacon Software是一家以IoT产品开发为主要业务的公司，他们在开源的GoAhead web服务器的基础上定制了一款名为XGoAhead的Web server使用在自己的产品中，2022年冬奥会的筹备工作批量采购了Datacon Software的产品。某天冬奥筹委会收到外部安全机构反馈： 公网上有大量使用XGoAhead的设备被某个不知名的僵尸网络感染，为了防范，现在你需要调查这个僵尸网络并尽可能的找到被感染的IP。
1.2 数据说明
目前提供的数据如下：
XGoAhead最新版本源码
公网Web蜜罐数据
Passive DNS数据
提供的XGoAhead软件代码只能运行在Linux操作系统上且须使用make工具构建，推荐使用Ubuntu 18.04或Centos 7。
提供的公网Web蜜罐数据仅为蜜罐服务器接收到的来自公网的流量，远不能覆盖整个互联网的情况，仅为观测样本。
提供的Passive DNS数据仅为小范围Client IP的数据，远不能覆盖整个互联网的情况，仅为观测样本。
2. 初步理解
题目给出的线索如下：
"GoAhead"是个真实的IoT web服务，代码开源。
主办方基于此二次开发了一个名为"XGoAhead"的软件，已给出源码。
这个软件存在漏洞，被僵尸网络攻陷。
目前有一份DNS数据，一份蜜罐数据。
目标是在数据中挖掘出全部被botnet攻陷的机器IP。
首先想到两个问题：
DNS数据可以理解为全网DNS的一个采样；HTTP数据来自蜜罐，经探索后发现全部是各种攻击流量，无正常流量，这两份数据怎么用？
为何要给出源码，是否要做代码审计挖掘漏洞？
3. Botnet建模
3.1 Botnet常规模型
一般情况下，botnet分以下几部分运行：
初始入侵：如通过RCE漏洞、SSH爆破、Redis未授权访问等打入服务器。
载荷投递：server被攻陷之后，会执行黑客预定的命令从Script Server下载恶意脚本/文件并执行，如此一个正常的Server就有了botnet的功能。
中控通信：被感染的服务器会连接黑客的"中控服务器(Control & Command Server)"进行上线，并接收指令（P2P暂不考虑）。
蠕虫传播：宿主机被感染后所植入的恶意文件会自带一些攻击模块，并自动开始对内网/公网机器发起蠕虫攻击，感染更多的服务器成为botnet的一部分。
攻击：黑客或通过中控批量对botnet的节点下发指令，对某一目标发起DDoS攻击。
[CTF]
原题信息
1.1 背景
Datacon Software是一家以IoT产品开发为主要业务的公司，他们在开源的GoAhead web服务器的基础上定制了一款名为XGoAhead的Web server使用在自己的产品中，2022年冬奥会的筹备工作批量采购了Datacon Software的产品。某天冬奥筹委会收到外部安全机构反馈： 公网上有大量使用XGoAhead的设备被某个不知名的僵尸网络感染，为了防范，现在你需要调查这个僵尸网络并尽可能的找到被感染的IP。
1.2 数据说明
目前提供的数据如下：
XGoAhead最新版本源码
公网Web蜜罐数据
Passive DNS数据
提供的XGoAhead软件代码只能运行在Linux操作系统上且须使用make工具构建，推荐使用Ubuntu 18.04或Centos 7。
提供的公网Web蜜罐数据仅为蜜罐服务器接收到的来自公网的流量，远不能覆盖整个互联网的情况，仅为观测样本。
提供的Passive DNS数据仅为小范围Client IP的数据，远不能覆盖整个互联网的情况，仅为观测样本。
2. 初步理解
题目给出的线索如下：
"GoAhead"是个真实的IoT web服务，代码开源。
主办方基于此二次开发了一个名为"XGoAhead"的软件，已给出源码。
这个软件存在漏洞，被僵尸网络攻陷。
目前有一份DNS数据，一份蜜罐数据。
目标是在数据中挖掘出全部被botnet攻陷的机器IP。
首先想到两个问题：
DNS数据可以理解为全网DNS的一个采样；HTTP数据来自蜜罐，经探索后发现全部是各种攻击流量，无正常流量，这两份数据怎么用？
为何要给出源码，是否要做代码审计挖掘漏洞？
3. Botnet建模
3.1 Botnet常规模型
一般情况下，botnet分以下几部分运行：
初始入侵：如通过RCE漏洞、SSH爆破、Redis未授权访问等打入服务器。
载荷投递：server被攻陷之后，会执行黑客预定的命令从Script Server下载恶意脚本/文件并执行，如此一个正常的Server就有了botnet的功能。
中控通信：被感染的服务器会连接黑客的"中控服务器(Control & Command Server)"进行上线，并接收指令（P2P暂不考虑）。
蠕虫传播：宿主机被感染后所植入的恶意文件会自带一些攻击模块，并自动开始对内网/公网机器发起蠕虫攻击，感染更多的服务器成为botnet的一部分。
攻击：黑客或通过中控批量对botnet的节点下发指令，对某一目标发起DDoS攻击。
解题过程
基于以上思路，对每个阶段进行数据探索并验证假设，拆分出的action有：
针对第1、4步：基于XGoAhead源码分析漏洞，提取漏洞利用特征，从honeypot HTTP流量中匹配到这部分攻击流量。
针对第5步：直接分析DNS数据挖掘是否有随机子域名DDoS或其他DNS攻击行为。
针对第2步：直接从全量HTTP流量中提取出payload中包含的域名，并与DNS数据进行关联。
针对第3步：判断直接从DNS数据中挖掘中控域名可行性较小，因此倾向于先做第1、2、4的过程，在样本或payload中分析出bot上线域名。
岔路排除
首先通过对DNS数据的分析（复用了一下去年做DNS题的代码和思路: Data2019 Writeup），逐级抽取子域名并进行统计，未发现攻击痕迹，第5步的假设排除。
之后我们通过类似Hadoop UDF的形式，从全量HTTP蜜罐数据进行URL、Base64的识别与解码，抽取出域名并关联DNS日志，未发现有效关系对。
基于以上思路，对每个阶段进行数据探索并验证假设，拆分出的action有：
针对第1、4步：基于XGoAhead源码分析漏洞，提取漏洞利用特征，从honeypot HTTP流量中匹配到这部分攻击流量。
针对第5步：直接分析DNS数据挖掘是否有随机子域名DDoS或其他DNS攻击行为。
针对第2步：直接从全量HTTP流量中提取出payload中包含的域名，并与DNS数据进行关联。
针对第3步：判断直接从DNS数据中挖掘中控域名可行性较小，因此倾向于先做第1、2、4的过程，在样本或payload中分析出bot上线域名。
岔路排除
首先通过对DNS数据的分析（复用了一下去年做DNS题的代码和思路: Data2019 Writeup），逐级抽取子域名并进行统计，未发现攻击痕迹，第5步的假设排除。
之后我们通过类似Hadoop UDF的形式，从全量HTTP蜜罐数据进行URL、Base64的识别与解码，抽取出域名并关联DNS日志，未发现有效关系对。
【安全资讯】警惕新型nginx后门，目前全杀毒软件免杀
近日，我们捕获一个新型nginx后门，该后门免杀效果非常好，截至目前VT上所有杀毒软件都不能对其进行查杀
网络验证后门方法：
首先通过nc本地监听9999端口：
$ nc -lv 9999
接着使用curl带上特殊cookie对本地地址发起请求：
$ curl "127.0.0.1" -H "Cookie:lkfakjfa0.0.0.0:9999"
如果在监听端口得到shell，说明服务器的nginx已经被黑客替换。
本地验证后门方法：
通过grep命令判断当前运行对nginx里面是否存在"/bin/sh"可疑字符串
$ which nginx |xargs grep "/bin/sh" -la
近日，我们捕获一个新型nginx后门，该后门免杀效果非常好，截至目前VT上所有杀毒软件都不能对其进行查杀
网络验证后门方法：
首先通过nc本地监听9999端口：
$ nc -lv 9999
接着使用curl带上特殊cookie对本地地址发起请求：
$ curl "127.0.0.1" -H "Cookie:lkfakjfa0.0.0.0:9999"
如果在监听端口得到shell，说明服务器的nginx已经被黑客替换。
本地验证后门方法：
通过grep命令判断当前运行对nginx里面是否存在"/bin/sh"可疑字符串
$ which nginx |xargs grep "/bin/sh" -la
WAF Bypass之webshell上传jsp与tomcat
1.开个头
事情是这样的，某一天，笔者闲着无聊，对着Tomcat的示例文件到处点点，希望寻找出点什么，意外发现Tomcat的示例文件中一些有趣的示例：随后笔者翻开Tomcat的解析代码，对其进行了一番静态代码审阅，果然有蹊跷，后面又调试看了看。
2 代码要点简析
对于脚本jsp文件，会通过EncodingDetector进行字符集类型的探测，该处代码要点较多，也是主逻辑，所以整片代码放上来了。
编码探测过程在该类初始化方法中进行，首先会使用processBom方法，根据文件的前4个字节探测字符集类型，这里的代码和xerces的Magic Charset中的字符集类型探测代码有着异曲同工之妙…；之后会使用getPrologEncoding方法尝试获取文件的declare charset，declare charset优先级高于magic charset。
1.开个头
事情是这样的，某一天，笔者闲着无聊，对着Tomcat的示例文件到处点点，希望寻找出点什么，意外发现Tomcat的示例文件中一些有趣的示例：随后笔者翻开Tomcat的解析代码，对其进行了一番静态代码审阅，果然有蹊跷，后面又调试看了看。
2 代码要点简析
对于脚本jsp文件，会通过EncodingDetector进行字符集类型的探测，该处代码要点较多，也是主逻辑，所以整片代码放上来了。
编码探测过程在该类初始化方法中进行，首先会使用processBom方法，根据文件的前4个字节探测字符集类型，这里的代码和xerces的Magic Charset中的字符集类型探测代码有着异曲同工之妙…；之后会使用getPrologEncoding方法尝试获取文件的declare charset，declare charset优先级高于magic charset。
T3反序列化 Weblogic12.2.1.4.0 JNDI注入
近日，Oracle官方发布安全更新，其中包含Weblogic的安全补丁，本着技术研究角度，和大家分享、探讨其中的一个JNDI注入漏洞。
在此前的CVE-2020-2883 将 extract 方法存在危险操作的 MvelExtractor 和 ReflectionExtractor 两个类加入到了黑名单中，因此我们只需要继续找一个 extract 方法存在危险操作的类即可绕过补丁，这里找到的是 Weblogic 12.2.1.4.0 Coherence 组件特有的类 com.tangosol.util.extractor.UniversalExtractor，因此只能影响 Weblogic 12.2.1.4.x。
漏洞报告
入口同 CVE-2020-2883，利用 java.util.PriorityQueue 反序列化时会间接调用 com.tangosol.util.ValueExtractor 接口任意实现类的 extract 方法
看其 extract 方法，虽然if条件中有一个 invoke 操作，但是 this.m_cacheTarget 使用了 transient 修饰导致无法被序列化
近日，Oracle官方发布安全更新，其中包含Weblogic的安全补丁，本着技术研究角度，和大家分享、探讨其中的一个JNDI注入漏洞。
在此前的CVE-2020-2883 将 extract 方法存在危险操作的 MvelExtractor 和 ReflectionExtractor 两个类加入到了黑名单中，因此我们只需要继续找一个 extract 方法存在危险操作的类即可绕过补丁，这里找到的是 Weblogic 12.2.1.4.0 Coherence 组件特有的类 com.tangosol.util.extractor.UniversalExtractor，因此只能影响 Weblogic 12.2.1.4.x。
漏洞报告
入口同 CVE-2020-2883，利用 java.util.PriorityQueue 反序列化时会间接调用 com.tangosol.util.ValueExtractor 接口任意实现类的 extract 方法
看其 extract 方法，虽然if条件中有一个 invoke 操作，但是 this.m_cacheTarget 使用了 transient 修饰导致无法被序列化