上一次简单探索了一下dash之后我把目标转向了p牛提到的很像的一个CVE：shellshock破壳漏洞
简单看一下payload，两者确实很像，了解一番过后就在想p牛的那个payload能不能通过shellshock的方式通过cgi去利用
环境部署：这里选择直接使用vulhub部署docker镜像
在vulhub中shellshock在bash文件夹中
这里我看网上有的叫shellshock，而我这里是按照漏洞编号命名的
部署下来
访问8080端口可以看到是否成功部署
然后打开cgi文件：victim.cgi
测试payload
一开始我还寻思这两个payload这么像感觉利用也差不多，要是真能用的话那p牛这不应该是又挖出来个CVE嘛
打完研究了下才发现有个问题是在cgi文件中并没有使用环境变量，为什么这个写在UA里的payload能打进来
参考文章：
https://blog.csdn.net/a1_pha/article/details/136312282
https://www.cnblogs.com/Cl0ud/p/14248937.html
这里提到当web服务器处理用户请求时，会将请求头中的信息转换为环境变量，也就是说咱们的UA被它转成了环境变量，所以payload能够生效
但是这又让我产生了疑惑，那既然如此，虽然在p牛的文章中使用的环境变量是特定的，那我把它写成自己写的头不就行了吗，但是实际测试并不好使
我尝试了下在shellshock的利用payload中使用env和export等命令查看当前cgi中的环境变量都有哪些，然后发现不使用/bin/xxx这种绝对路径直接调用程序的方式似乎无法执行
不确定是无法执行还是无法看到回显，尝试了下echo
然后发现文件并没有创建，但是echo 123又能正常执行
虽然不知道为什么会显示出源码，难道是跟之前看到的bash的内建命令有关，只能执行内建命令？
看起来这里确实只能直接执行内建命令
而export是个内建命令，env是/usr/bin里的，它们似乎确实能看到环境变量
但是其它的头呢？这里看不到？
思考了半天没想出来什么原因，又回去开始观摩大佬的文章，然后突然想到为什么不换个头来打一下试试呢？
还真是UA头的问题？尝试了一下发现这玩意只接受它指定的这几个头，似乎不会解析其他自己添加的头，不管是不是正规的头
加上Sec-Fetch-Site这种存在的头也一样,而且即使能够接受看这情况也会被加上个HTTP前缀，所以无法用p牛的payload通杀，只能像p牛文章中给出的那种环境，能够控制环境变量并且后边调用了bash才行得通
这里为什么不能直接执行命令，ua头为什么不好使和cgi这里到底是不是只接收执行的请求头想要再进一步分析估计就得看源码了
前面的 dash源码看得头疼，这里的shellshock产生的bash源码也没看，还是等有时间再分析分析吧
标签：cgi,区别,环境变量,源码,shellshock,payload,bash From： https://www.cnblogs.com/theskyforfly/p/18158732