原理

rootkit通常是指攻击者拿到root权限以后在行为这块做隐藏的恶意软件，其工作环境包括用户态和内核态，用户态的手法一般是通过ld_preload hook glibc，内核态则是写lkm去hook系统调用。hook系统调用技术其实也有细分，包括kernel inline hook、kprobe、sys_call_table hook等，这篇博客所记录的就是最基础的sys_call_table hook这块的内容。

研究过程

sys_call_table modify

sys_call_table地址获取

sys_call_table地址获取方式有如下几种：

1、从/boot/System.map中获取

2、从/proc/kallsyms中获取

3、idt劫持

4、暴力搜索

背景

在进程网络日志捕获的技术选型这块的当初想了很久，备选方案有如下几种：
1、cn_proc
2、proc遍历
3、netfilter
4、auditd
5、libpcap
综合考虑得出利弊如下：
1、cn_proc用进程回调代替网络回调，只能抓到进程创建后立即产生网络连接的日志，对于具有潜伏特性或多线程发包的进程这种方式会存在大量漏报；
2、遍历/proc/net/tcp(6)，只能拿到inode，要做进程关联需要去做二次遍历，cpu消耗较大，走调度的话则会漏掉很多数据，无法做稍细的检测，不优雅；
3、netfilter是内核提供的机制，但调研显示不同系统的内核函数具有较大差异，需要做适配，且其hook内核tcp协议栈在大流量环境下会有一定性能影响，但比较好的一点是可以拿到数据包的关联进程信息，不用做二次遍历；
4、auditd同样是内核提供的机制，稳定是其一个优点，但由于是对所有内核系统调用去做过滤，不可避免对内核的负载会较高。
5、libpcap底层基于bpf，稳定是一个特点，但也同样存在无法执行关联进程、性能影响较大的问题。
因为曾经用到过libpcap，且在其性能问题上踩过坑，这边对libpcap的性能问题做下总结。

一、背景

hw前面试的时候被问到这个问题，自我感觉回答的挺凌乱的，明明这块的经验也很多，但感觉自己做的还是不够好，缺少体系化的整理和思考，这边简单做下记录，顺带着理一下思路。

二、入侵检测

挖矿的直接特征相对僵木蠕来说比较单一和容易排查，即较高的CPU占用；当然也存在一些特意控制CPU不超过指定阈值的挖矿病毒，其经常出现在攻击者已经拿下域控之后的利用场景，这种你好我也好的挖矿方式相对比较隐蔽，特别是在拥有较大规模主机集群的内网中，这种挖矿很难引起管理员注意，也就不容易去排查，但需要注明的是其使用的入侵、挖矿等手段和前一种几乎是一样的，只是稍温和一点，一旦发现了异常，后续的检测也是一样的。
首先定位到异常主机，观察命令操作是否卡顿，查看CPU状态是否远超正常主机，若cpu资源占用高居不下，则有可能是中挖矿了；此时看下crontab里是否有被写连接未知服务器下载文件并执行的操作，若是，则90%以上是中挖矿了，之后进行溯源，主要对其入侵方式、恶意行为等进行整理，说白了就是检测怎么进来的，进来后干了什么，主要是这两个过程。

四年时间转瞬即逝，转眼间，那个刚入大学校门还蹦蹦跳跳的自己，已经正式脱离学校这座象牙塔，正式步入社会了。
以后的生活可能就更是全量的职场生活了，尽管整个大四一直是在实习；这边记录下入职以后的新规划，来帮助自己在职场上获得更快的成长。
这边的规划主要集中在三个大方面，包括生活、工作和未来，其中涵盖各个小方面，不再细述。

一、make && Makefile

在相对比较大的项目中，项目通常会被模块化，使用make和makefile有助于简明的记录各个模块之间的复杂引用关系；如此之多的源文件，如果每次编译都要去敲gcc指定源文件和头文件以及链接库进行编译的确是个灾难；针对上面的问题，make应运而生。make根据makefile中定义的编译方式进行自动化的、定制化的编译，且能灵活地只对makefile中上次修改的部分进行重编译。

前言

hw期间需要准备红队不同生命周期中使用的工具，作为一名二进制选手（伪），理所应当的承担起了主机层内网权限维持这块的工作输出，包括手法、自动化工具（开源、自写）、rootkit、多版本适配的魔改系统so等等。整理的过程也是学习的过程，这里打算分三部分进行记录，主要包括ptrace注入、预加载、rootkit三块。以下首先进行的是ptrace注入这块的分析，包括原理、源码、其它三个部分。

原理

在linux上，想要去做so库的动态注入无非这么几步：
1、注入器（injector）使用ptrace挂载目标进程
2、注入器注入加载器（loader）到目标进程
3、加载器被触发进行so库注入
4、目标进程初始状态还原和卸载ptrace

下面简单展开一下：

一、漏洞介绍

Citrix Systems Citrix ADC and NetScaler Gateway等都是美国思杰系统（Citrix Systems）公司的产品。Citrix ADC and NetScaler Gateway是一款应用交付控制器。该产品具有应用交付控制和负载均衡等功能。 安全专家在Citrix Application Delivery Controller和Citrix Gateway产品中发现一个严重的代码执行漏洞，该漏洞使158个国家的超过8万家公司面临风险。由于利用该漏洞的攻击者无需身份验证即可访问公司的内部网络，因此该漏洞尤其危险。成功利用该漏洞可导致任意代码执行。

一、漏洞介绍

Log4j是美国阿帕奇（Apache）软件基金会的一款基于Java的开源日志记录工具。通过使用Log4j，我们可以控制日志信息输送的目的地是控制台、文件、GUI组件，甚至是套接字服务器、NT的事件记录器、UNIX Syslog守护进程等；我们也可以控制每一条日志的输出格式；通过定义每一条日志信息的级别，我们能够更加细致地控制日志的生成过程。Log4j 1.2.x版本中包含一个SocketServer类，在未经验证的情况下，该SocketServe类很容易接受序列化的日志事件并对其进行反序列化，在结合反序列化工具使用时,可以利用该类远程执行任意代码。

一、漏洞介绍

Django的密码重设表单使用不区分大小写的查询来检索与请求密码重设的电子邮件地址匹配的帐户。因为这通常涉及显式或隐式大小写转换，所以知道与用户帐户关联的电子邮件地址的攻击者可以制作与该帐户关联但地址不同的电子邮件地址。攻击者可以输入精心构造的带Unicode字符的邮箱并让Django解析成受害者的关联邮箱地址，在这种情况下，攻击者可以收到受害者帐户的有效密码重置令牌进行恶意的用户密码重置。

一、前言

CVE-2019-14271是一个通过宿主机docker cp容器文件导致任意命令执行的漏洞，目前已知的影响版本只有docker 19.03.0(包含几个beta版)，19.03.1以上以及18.09以下都不收影响。漏洞起源于docker开源项目issue上docker19.03.0版本docker cp产生的报错:

Error response from daemon: error processing tar file: docker-tar: relocation error: /lib/arm-linux-gnueabihf/[libnss_files.so](http://libnss_files.so/).2: symbol __libc_readline_unlocked, version GLIBC_PRIVATE not defined in file [libc.so](http://libc.so/).6 with link time reference : exit status 127

这边给出docker源码issue链接地址：https://github.com/moby/moby/issues/39449

CVE官方也放出漏洞细节：https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-14271

贴一下漏洞发现者的博客：https://unit42.paloaltonetworks.com/docker-patched-the-most-severe-copy-vulnerability-to-date-with-cve-2019-14271/

目前国内对CVE-2019-14271漏洞所做的分析基本都是来自漏洞发现者博客的文章翻译，缺少具体复现细节。

这边做一下漏洞分析和复现。