博文

复现基于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 程序整体结构

【最后的披露】WPS For Linux RCE(CNVD-2021-35581)

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

用请求源端口识别Burp代理

图片
  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 彩蛋 在做实验的时候发现有些知名的代理软件在选取源端口的时候和浏览器的特征不一样,我会抽时间更多地研究下。

Packer-Fuzzer漏扫工具RCE 0day(当前已被官方修复)

图片
  0x00关于本文 今天朋友丢我一个授权测试的站,那个站用vue写的前端,因此前端js包含了所有的接口。 而另一方面整个前端就一个登录框堵在那儿,因此翻js几乎成了唯一的思路。 翻着翻着,我烦了,于是估摸着网上已经有前辈们写出了专门针对webpack的扫描工具,一搜就搜到了Packer-Fuzzer( https://github.com/rtcatc/Packer-Fuzzer ) 当我浏览这个工具的介绍的时候,我注意到了这句话 “本工具将会通过PyExecJS运行原生NodeJS代码,故我们推荐您安装NodeJS环境” 看到这句话我一下就警觉起来,毕竟nodejs是可以执行命令的,而相关的安全问题已经让蚁剑翻过车了( https://xz.aliyun.com/t/8167 ),于是一瞬改变目标开始研究这个工具,并且挖掘出了RCE 当前漏洞已经被官方修复,并且奖励800(由于我Twitter上提前公开了漏洞导致高危->中危) 本文将会从分析者的角度分析漏洞 0x01定位js执行点 简单搜索execjs就可以找到执行点,位置在Recoversplit.py的57行 0x02 防护绕过 作者在写这个代码的时候也意识到了被反打的可能性(“防止黑吃黑被命令执行”),所以当js出现了exec和spawn的时候就不会执行,但是这样的简单的防护几乎是没有用的。 且不说nodejs沙箱逃逸已经被师傅们玩出花来了,单是这里eval没有过滤掉就可以通过字符串拼接或者url编码的方式绕过这个限制 比如说这里就用了url编码了能弹出计算器的payload,解码并eval之后就能弹出计算器 0x03 调用分析 那么这个执行点是怎么被调用到的呢 看了下代码,发现执行点在RecoverSplit类的jsCodeCompile里,这个函数被同一个类的checkCodeSpilting调用,而checkCodeSpilting又被这个类的recoverStart调用,recoverStart被Project类的parseStart调用,而parseStart,而再往前追溯就是命令参数处理之类乱七八糟的地方了 知道了这些东西之后,我们就可以根据它的调用一步一步走,一点一点写出RCE的POC了 0x04 如何进入recoverStart函数?让程序相信这个网站使用了webpack 我们看到这

局域网监控软件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