找到某厂商一大堆公开固件，但是版本太多了，每个固件的加密方式不一样，能用工具解出的固件有三个型号，看到有明显对称加密如RC4的固件也尝试了一下

写了个解RC4的脚本，然而解出来的什么都识别不出来，除了RC4可能还做了别的处理

最后选择v2960的固件作为研究对象，ubi头的直接用工具

设备攻击面并不多，主要研究web的接口

中间件采用的是lighttpd，结构上基本就是操作和请求都通过/www/cgi-bin/mainfunction.cgi，路由和逻辑都在里面，大量的system调用

通过main函数看到路由有两种形式实现

第一种是通过PATH_INFO https://*******/cgi-bin/mainfunction.cgi/xxxxxx

第二种则是通过传入action参数来与函数表作比较，从而确定路由

这个时候去扫了一圈历史漏洞，发现问题都出在检查参数上

修复加上了filter，过滤了特殊字符

这个filter暂时没想到什么绕法，比较完善

还有一类历史洞出在处理文件参数上，CVE-2020-15415，下为1.5.1.1版本截图

结合获取文件的cgigetfile函数介绍

https://manpages.debian.org/jessie/cgilib/cgiGetFiles.3.en.html

（v7+8）即为结构file_s的filename，接收的时候只通过Escape转义了<、>、&，并未对特殊符号进行过滤，导致了RCE

https://github.com/CLP-team/Vigor-Commond-Injection

根据这个看到固件中，发现很多类似的情况，获取文件都采取这种操作，但是不同的是，指针都指向*tmpfile，并且可控

由于他通篇的system调用，那肯定得关注拼接的问题

通过PATH_INFO路由的函数已经被看了好几遍了，那注意力转移到第二种路由方式上

看到rename_table

通过action=rename_table进入路由之后，很明显的能看到有两处参数拼接没有过滤，导致RCE

再看到doswmbackup

通过action=doswmbackup进入也能看到参数没有过滤，可以通过..达成穿越读的效果，但是有0x20的长度限制略鸡肋

定位到ruequest_certificate

也是通过action=ruequest_certificate进入，参数拼接之前没有过滤导致RCE

来到getSyslogFile

通过action=getSyslogFile进入，依旧是个穿越读，不过长度限制相当宽裕

在内存问题上虽然危险函数很多但是经过几轮修复也变得很谨慎了

到这里基本简单分析完毕