Driver Tom's Blog

  0x00 关于本文     其实我是想复现CVE-2022-23121的，但二进制水平还不够，所以决定先踩着 前人的脚步 复现相同产品的另一个漏洞CVE-2018-1160，多学点东西。     在这次复现过程中我得到了 @povcfe 的许多帮助，在此表示感谢。     文中涉及的代码已放在 Github 。 0x01 环境搭建     这篇文章 介绍了如何搭建环境，但我的系统不是Ubuntu18.04，其运行的新版本Glibc会导致漏洞利用更加困难，因此我需要切换回老的Glibc。     搭建一个Ubuntu18.04的虚拟机并且在上面把各种调试工具装好是最朴素的做法，但这样太麻烦，并且要是下次我需要一个Ubuntu16或者别的版本那又得重头再来。因此我的办法是用Docker启一个Ubuntu18.04的容器，并将它的548端口映射到宿主机上，在这个容器中编译Netatalk并运行。由于容器本质上是受到严格限制的进程而不是虚拟机，我可以直接用宿主机上的调试工具attach到容器内部的进程来调试而不需要在容器内安装这些调试工具。     说了这么多，其实启动这个容器就一行命令的事 docker run -p 548:548 -i -t ubuntu:18.04 /bin/bash     后续的东西按着本段开头的那个文章搭就好了，当然pwntools和pwndbg这些搞pwn必备的东西也是要在宿主机上安装的。 0x02 Netatalk是怎么跑起来的&如何调试它     Netatalk的源码的调用关系在 这里 写的有。简单地说，它对于每一个新的连接都用dsi_tcp_open fork出一个子进程并接收参数，并返回到dsi_getsession中处理连接建立和关闭的过程，而与这个连接后续的交互过程都在afp_over_dsi中实现。基于这个特性，我们可以通过在gdb中追踪子进程来调试Netatalk对连接的处理。     我们可以通过gdb一行命令实现这件事。其中pgrep用于找到它的pid，而设置follow-fork-mode child可以让gdb选择跟踪子进程，directory指令可以设定源码的路径，这样我们在调试的时候可以看C代码而不用啃太多汇编。  gdb -q -p `pgrep -n afp` --ex "set

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 程序整体结构

0x00 关于本文     再过五个小时，在国内进行漏洞披露将有法律风险，趁着最后的时间，公布下之前搞出的一个微不足道的小洞 0x01 怎么就RCE了呢？      WPS Linux可以双击打开嵌入的附件而不管附件的类型      而许多Linux桌面都支持双击打开.desktop       因此把.desktop嵌入docx再搞成透明的就可以了 0x02 如何做一个POC      随便office word搞个文档，嵌入.desktop(Linux WPS自己不能嵌)。      把嵌入的图片搞成透明的，并且拖到全屏，置为底层就可以了（这个需要去解包word文件乱搞一通实现，但是如果只是想演示而不需要武器化的话没必要） 0x03 测试     这里已经制作了一个简单的POC，并且上传至 GitHub      WPS LINUX （11.1.0.10161）       测试的系统是kali Linux 2020       桌面XFCE       POC.docx是POC 打开后随便双击任何一个地方都能弹出计算器     暂时我的Kali机器没在身边，想到了再补图

  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对象是一项烦人又重复的活，因此有大量的工具被开发出来解放黑客们的双手。这些工具可以将整个攻击流程自动化，自动下载项目的所有文件，并且重建整个项目的目录结构。     但是在这个过程中存在一个严重的安全风险，这些工具在重建项目的

  0x00 关于本文 BurpSuite被识别是怎么回事呢？BurpSuite相信大家都很熟悉，但是BurpSuite被识别是怎么回事呢，下面就让小编带大家一起了解吧。 BurpSuite被识别，其实就是用源端口检测，大家可能会很惊讶BurpSuite怎么会被识别呢？但事实就是这样，小编也感到非常惊讶。 这就是关于BurpSuite被识别的事情了，大家有什么想法呢，欢迎在评论区告诉小编一起讨论哦！ 0x01 HTTP/1.1 持久连接 关于HTTP的连接管理相关的知识可以在 这里 找到。 在使用了HTTP/1.1的情况下（也就是我们见到的大部分情况），浏览器都会使用下图中第二种情况所说的“持久连接”，即在访问一个网站后不立即关闭连接，在下一次访问的时候直接用已打开的连接，减少握手次数，以降低流量消耗提升访问速度 0x02 Burp和持久连接 目前来看，Burp仍然没有支持持久连接，当有用户在社区中 询问 时，Burp官方回复的是即使在Burp里面设置了不加Connection:close头，Burp依旧会关闭连接。 0x03 如何搞清楚连接是否被复用了 从上面的叙述中，我们可以很容易地看出，通过检测连接是否被复用了就可以知道客户端是否启用了Burp代理。但是连接的复用似乎是个比较底层的问题，如何在不亲手实现一个HTTP服务器的时候简单地检测呢？ 其实回想下TCP的基础知识就发现很简单，相同的连接，源端口也是相同的，那么只需要查看客户端的源端口就可以知道了。 0x04 用Flask实现并测试 代码放在 https://github.com/TomAPU/checkburp 了 效果如下： 结果表明，通过源端口可以实现检测Burp 0x04 彩蛋 在做实验的时候发现有些知名的代理软件在选取源端口的时候和浏览器的特征不一样，我会抽时间更多地研究下。