基于HPP参数污染的Web服务器指纹识别技术

0x00 关于本文

         关于web服务器指纹识别的技术，已经有十万甚至九万个文章描述，十万甚至九万个工具实现。但目前来看，本文或许是首先提出基于HPP参数污染技术来识别web服务器指纹的。
通过HPP参数污染技术来探测服务器的指纹可以有非常高的准确率，此方法通过不依赖可以随意删除的特征关键字（比如服务器返回头），不会被啊D那样能够把IIS伪装成Apache2这样的伎俩欺骗。但是缺点是只能够识别Web服务器中间件类型，无法识别CMS，并且自动化有一定困难（为自己的懒惰找借口）

0x01 HPP是什么以及为什么HPP可以用来识别Web服务器指纹

         HPP全称HTTP Parameter pollution，就是HTTP参数污染。简单来说就是提供多个同名的参数给服务器，比如说一般提交的是?id=1你提交一个?id=1&id=2。由于HTTP标准并没有写明该怎么办，各个不同的服务器/中间件会有不同的处理方式，而通过观察他们的处理方式的差异即可判断服务器类型
         比如对于网站http://example.com/?color=red&color=blue，不同的服务器认为自己收到的参数如下

Web Application Server BackendParsing ResultExample
ASP.NET / IISAll occurrences concatenated with a commacolor=red,blue
ASP / IISAll occurrences concatenated with a commacolor=red,blue
PHP / ApacheLast occurrence onlycolor=blue
PHP / ZeusLast occurrence onlycolor=blue
JSP, Servlet / Apache TomcatFirst occurrence onlycolor=red
JSP, Servlet / Oracle Application Server 10gFirst occurrence onlycolor=red
JSP, Servlet / JettyFirst occurrence onlycolor=red
IBM Lotus DominoLast occurrence onlycolor=blue
IBM HTTP ServerFirst occurrence onlycolor=red
mod_perl, libapreq2 / ApacheFirst occurrence onlycolor=red
Perl CGI / ApacheFirst occurrence onlycolor=red
mod_wsgi (Python) / ApacheFirst occurrence onlycolor=red
Python / ZopeAll occurrences in List data typecolor=['red','blue']


0x02对于常见情形的的识别

         上表的类型太全面了，我们一般只需要覆盖几个常用的就可以了，因此整理出如下粗略的判断方式



         不过这个判断较为粗糙，而且还有种种因素造成的误差导致想要实现一个完美的判断工具的工作量远大于手动判断，在实际操作的时候建议手动判断

0x03手动判断

         手动判断则更为灵活，现拿██带学的██研究院官网开刀
         发现存在搜索功能，从搜索功能处下手，因为服务器一般会打出搜索字符串，如下图我搜索了nmsl发现结果被打出来了
       
接着再参数污染一个1234

发现都被服务器接收了，类似于iis的情形，但是按理来说用来分割的逗号没有了（经过测试可知逗号被过滤了）
接着进行最后一项测试，在keyword参数前面加一个&符号

0x04工具实现

本人实现了一个很粗糙的工具，代码过于丑陋不予开源，看个图吧
结果返回正常，排除ASP,识别结果ASP.NET






评论

发表评论

此博客中的热门博文

局域网监控软件WFilter ICF 鸡肋0day RCE漏洞挖掘

图片
  0x00关于本文 逛freebuf的时候看到了这篇文章， 关于PDD员工发帖溯源联想到的相关技术与实现 ，其中提到了一个叫做wfilter的局域网监控软件。 这个软件官网提供了下载链接，支持10天实用，于是我就下下来研究一番。 作为一个搞安全的人，我最感兴趣的是这个软件本身是否存在缺陷，毕竟这类用于监控的安全软件自身出现漏洞是最有戏剧性的事情了 0x01不同寻常 Web管理 Wfilter通过串联/旁路的方式进行部署，同时提供一个Web管理接口供管理员进行远程管理。而作为一个Web狗，我自然把重心放在了这个Web管理接口上了。 这个Web管理接口不同寻常的第一点就是登录之后不会返回任何Cookies，而且请求接口的时候也不会带Cookies或者任何特殊的Headers 那它是怎么进行鉴别的呢？ 测试了一番之后发现居然是根据IP地址来鉴别的，一旦管理者登录，wfilter就会记录下管理者的IP地址，然后允许其访问这些接口。 这么诡异的鉴别方式大概率搭配了一个诡异的后端实现，结果我用火绒剑一看，发现后台是通过CGI运行的。也就是说想要审计这个软件还得去逆向这个EXE！ 算了，逆向就逆向吧，正好试试IDA7.5效果怎么样 0x01对于cgiproj.exe的逆向分析 这个Web接口的特点是通过/fcgi?cmd=【功能名】来调用，因此在IDA里面搜索相关的字符串就可以找到实现通过功能名来执行不同功能的函数了。 这个函数非常的大，以至于我需要修改IDA的hexrays支持的最大函数大小来让IDA能够成功反编译这个函数（Web狗实在是不想啃汇编了）。 经过一番猜测和实验，我发现这个调用sub_BF65E0中的参数包含了功能名字，而v266[1]中存放的则是其对应的函数。通过这些信息我可以查看具体接口是如何实现。 0x02 思路1：找到无需鉴权的功能，直接拿下服务器！ 实现这个思路，简单来说就两个步骤，第一个是找到无需鉴权的功能，第二个是逆向分析然后找到有漏洞功能然后利用。 为了找到无需鉴权就能使用的功能，简单起见，我搜集了那个大函数中的所有的字符串，然后拿到接口中去fuzz，接着发现viewHelp,helpSearch,login,mobileCode,mlogin,logout,remoteLogin,viewToolTip,ExecuteNoLogin,forget
阅读全文

别想偷我源码：通用的针对源码泄露利用程序的反制（常见工具集体沦陷）

图片
  0x00 关于本文     是的没错 我又去蹂躏安全工具了，和以前我单个单个地欺负不同，这次发现的攻击手段是通用的，可以通杀大部分源码泄露漏洞利用程序。      本文会包含常见泄露漏洞的原理介绍（Git/Svn），利用工具自身的安全风险分析，简单易懂的POC制作方式，针对常见工具的攻击测试，以及提升反制威力的方法及展望。 0x01Git泄露：漏洞原理介绍      Git是什么大家应该都很清楚（不知道Git是啥的人多半是不肯来光临这个博客的）      有些开发人员直接把代码clone到服务器的web目录来部署，但是开发人员或许不知道的是，clone下来的不只是代码，还有一个.git目录，这个目录被叫做版本库。攻击者可以通过访问这个目录，解析其中的文件，dump整站源码。     想要更深入地理解Git泄露漏洞，了解攻击流程，就需要了解.git目录的结构     tree一下这个目录，发现内容如下      index文件中包含了这个项目中的各个文件的信息，包括文件路径和Git对象的对应的40位哈希值。在这里我们不需要对Git对象理解的很深入，只需要知道里面包含了文件内容，是让攻击者垂涎欲滴的东西就可以了。      想要拿到Git对象，就需要转去objects目录。objects目录存放了所有的git对象，对于一个git对象，40位哈希的前两位会作为目录名，而后面的38位会作为文件名，存在objects下面。举个例子，一个Git对象那个的hash是cb75d8439f004f41d5f85ffa5f8d017df395651a，那么它就会被存在cb/75d8439f004f41d5f85ffa5f8d017df395651a。     知道了这些信息之后，就可以知道Git泄露攻击是如何进行的了，首先攻击者访问index文件，解析后得到文件名和对象哈希。接着按着对象哈希一个一个去objects目录获取到Git对象，解析后得到文件。 0x02 Git泄露利用工具的安全风险     显而易见的，手动解析index文件并去下载然后再去解析Git对象是一项烦人又重复的活，因此有大量的工具被开发出来解放黑客们的双手。这些工具可以将整个攻击流程自动化，自动下载项目的所有文件，并且重建整个项目的目录结构。     但是在这个过程中存在一个严重的安全风险，这些工具在重建项目的
阅读全文

复现基于eBPF实现的Docker逃逸

图片
0x00 关于本文     最近搞毕业设计在研究Docker逃逸，如果只把 CDK工具 的东西复现一遍（或者照抄），那诚意不足，也失掉了我刻意选我不熟悉领域的题目的意义所在，于是想自己动手做点东西。     看到 seebug上基于eBPF的逃逸 和 ScUpax0s的容器逃逸文章 ，我意识到基于eBPF的逃逸可以做一做，虽然他们都写了思路贴了部分代码片段，但毕竟没有放完整的代码出来，我自己踩坑实现一遍，可以学点东西，也能算是工作量。     文章中的代码实现已上传至 Github 。     在实现的过程中，ScUpax0s给了我许多指点，让我少走了很多弯路，感谢他！ 0x01 eBPF为什么能帮助Docker逃逸     eBPF技术允许用户在用户态编写代码，被verifier扫描鉴定无问题后，送入内核执行。     e BPF可以在Linux系统的各个地方插桩，在执行到指定位置时，执行用户自定的代码，实现数据搜集和修改。 因此 eBPF使得用户可以在用户态高效安全地监控Linux的方方面面。     能看，还能改，黑客自然也可以拿它来使坏。更妙的是，在Docker环境中，容器和宿主机共享同一个内核，因此如果容器被赋予了CAP_SYS_ADMIN能力，成功在容器中加载了eBPF程序的话，eBPF程序将能够直接在系统的内核中运行，无视容器的各类隔离机制。因此在宿主机环境中作恶的eBPF，在容器中照作不误，它能在宿主机环境里面干上面，那就能在容器里干什么，突破隔离一步到位。 0x02 通过BPF劫持cron进行逃逸     尽管看起来很容易，但真正实现逃逸还需要一番周折。eBPF的代码仅能在触发插桩点的时候执行，它能够读参数，对指定地址的用户内存读写，但无法直接发起一个系统调用，弹一个shell回来。      seebug上基于eBPF的逃逸 给出了一种思路，即利用cron进行逃逸。      cron服务在Linux系统上实现了计划任务，它每隔一段时间检查配置文件是否被更改过，如果更改了就读取配置文件，根据配置文件的描述设定定时的命令执行。因此通过劫持cron对配置文件的访问，篡改文件的更改时间和读取内容，即可欺骗cron执行我们预定的命令，而cron是运行在宿主机上的，因此欺骗cron执行了命令相当于在宿主机中执行了命令，也就是逃逸。 0x03 程序整体结构
阅读全文