基于netfilter的rootkit

字数统计: 1.8k字   |   阅读时长≈ 8分

暂无简介

背景

蜜罐产品有个功能是对任何端口的访问都会被记录，即使是"nmap扫描后显示关闭"的端口访问也会被记录。它的实现原理是iptables的NFLOG。

学习NFLOG概念后，我想到也可以用它来做rootkit通信。

本文包括以下内容

  • 讨论NFLOG是什么
  • 用NFLOG机制实现后门的优势分析
  • NFQUEUE rootkit demo

希望能对主机安全感兴趣的读者有点帮助

NFLOG是什么

它是一个target，就像ACCEPT、DROP等可以作为iptables -j后的参数值。

[root@instance-h9w7mlyv ~]# iptables -A INPUT -p tcp -m multiport --dports 1:65535 -j NFLOG --nflog-group 2333

比如上面规则就会告诉内核协议栈，在收到包时，目的端口是1到65535的包，全部执行NFLOG动作。

man iptables-extensions 文档中也有关于NFLOG的说明

NFLOG
This  target  provides  logging of matching packets. When this target is set for a rule, the Linux kernel will pass the packet to the loaded logging backend to log the packet. This is usually
used in combination with nfnetlink_log as logging backend, which will multicast the packet through a netlink socket to the specified multicast group. One or more userspace processes may  sub-
scribe to the group to receive the packets. Like LOG, this is a non-terminating target, i.e. rule traversal continues at the next rule.
--nflog-group nlgroup
   The netlink group (0 - 2^16-1) to which packets are (only applicable for nfnetlink_log). The default value is 0.
...

-j NFLOG和-j LOG有些类似，都可以记录数据包信息，执行动作后会继续匹配iptables规则中的下一条。区别是-j NFLOG可以让用户态程序通过netlink从内核获得数据包信息。

下面你可以和我一起做个小实验来验证一下,用户态程序是否可以通过netlink获取到数据包。

用tcpdump验证

第一步，你需要配置iptables的nflog规则。

[root@instance-h9w7mlyv ~]# iptables -A INPUT -p tcp -m multiport --dports 65530:65535 -j NFLOG --nflog-group 2333

第二步，使用tcpdump订阅netlink消息。

[root@instance-h9w7mlyv ~]# tcpdump -i nflog:2333

第三步，访问主机，验证tcpdump是否能获取到数据包。

curl x.x.x.x:65533 后，可以抓到数据包。

[root@instance-h9w7mlyv ~]# tcpdump -i nflog:2333
...
listening on nflog:2333, link-type NFLOG (Linux netfilter log messages), capture size 262144 bytes
11:42:15.175375 IP 111.197.238.30.22293 > instance-h9w7mlyv.65533: Flags [S], seq 3599662212, win 65535, options [mss 1452,nop,wscale 6,nop,nop,TS val 3053845653 ecr 0,sackOK,eol], length 0

或许你会有一个问题：tcpdump -i nflog:2333和tcpdump -i eth0都可以获取数据包，有啥区别。

从编程实现来看是有区别的，tcpdump -i eth0是基于AF_PACKET获取数据

[root@instance-h9w7mlyv ~]# strace tcpdump -i lo
socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL)) = 3
...
setsockopt(3, SOL_PACKET, PACKET_RX_RING, 0x7ffeef157d10, 28) = 0 // Packet MMAP提高抓包性能，参考 https://github.com/torvalds/linux/blob/master/Documentation/networking/packet_mmap.rst
mmap(NULL, 4194304, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0x7fedba9a5000
...
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=1, filter=0x7ff0a4ee8000}, 16) = 0   // bpf filter
setsockopt(3, SOL_SOCKET, SO_ATTACH_FILTER, {len=1, filter=0x56436b7fe480}, 16) = 0
...
poll([{fd=3, events=POLLIN}], 1, 1000)  = 0 (Timeout)
poll([{fd=3, events=POLLIN}], 1, 1000)  = 1 ([{fd=3, revents=POLLIN}])
write(1, "12:27:16.575888 IP localhost.416"..., 16512:27:16.575888 IP localhost.41616 > localhost.http: Flags [S], seq 3517707840, win 43690, options [mss 65495,sackOK,TS val 1304864277 ecr 0,nop,wscale 7], length 0

tcpdump -i nflog:2333是基于AF_NETLINK获取数据

[root@instance-h9w7mlyv ~]# strace tcpdump -i nflog:2333
socket(AF_NETLINK, SOCK_RAW, NETLINK_NETFILTER) = 3
...
recvfrom(3,[\{\{len=184, type=NFNL_SUBSYS_ULOG<<8|NFULNL_MSG_PACKET, flags=0, seq=0, pid=0}, {nfgen_family=AF_INET, version=NFNETLINK_V0, res_id=htons(2333), [\{\{nla_len=8, nla_type=NFNETLINK_V1}, "\x08\x00\x01\x00"}, \{\{nla_len=5, nla_type=0xa}, "\x00"}, \{\{nla_len=8, nla_type=0x4}, "\x00\x00\x00\x02"}, \{\{nla_len=16, nla_type=0x8}, "\x00\x06\x00\x00\xfa\x16\x3e\xd1\x8d\x2d\x00\x00"}, \{\{nla_len=6, nla_type=0xf}, "\x00\x01"}, \{\{nla_len=6, nla_type=0x11}, "\x00\x0e"}, \{\{nla_len=18, nla_type=0x10}, "\xfa\x28\x00\x0d\x3f\xff\xfa\x16\x3e\xd1\x8d\x2d\x08\x00"}, \{\{nla_len=20, nla_type=0x3}, "\x00\x00\x00\x00\x63\x08\x57\x83\x00\x00\x00\x00\x00\x03\x49\x03"}, \{\{nla_len=68, nla_type=0x9}, "\x45\x00\x00\x40\x00\x00\x40\x00\x32\x06\x1e\xc0\x6f\xc5\xee\x1e\xac\x10\x20\x04\x5b\x41\xff\xfd\x5a\x0c\x47\xf0\x00\x00\x00\x00"...}]}, \{\{len=184, type=NFNL_SUBSYS_ULOG<<8|NFULNL_MSG_PACKET, flags=0, seq=0, pid=0}, {nfgen_family=AF_INET, version=NFNETLINK_V0, res_id=htons(2333), [\{\{nla_len=8, nla_type=NFNETLINK_V1}, "\x08\x00\x01\x00"}, \{\{nla_len=5, nla_type=0xa}, "\x00"}, \{\{nla_len=8, nla_type=0x4}, "\x00\x00\x00\x02"}, \{\{nla_len=16, nla_type=0x8}, "\x00\x06\x00\x00\xfa\x16\x3e\xd1\x8d\x2d\x00\x00"}, \{\{nla_len=6, nla_type=0xf}, "\x00\x01"}, \{\{nla_len=6, nla_type=0x11}, "\x00\x0e"}, \{\{nla_len=18, nla_type=0x10}, "\xfa\x28\x00\x0d\x3f\xff\xfa\x16\x3e\xd1\x8d\x2d\x08\x00"}, \{\{nla_len=20, nla_type=0x3}, "\x00\x00\x00\x00\x63\x08\x57\x84\x00\x00\x00\x00\x00\x03\x4b\x6c"}, \{\{nla_len=68, nla_type=0x9}, "\x45\x00\x00\x40\x00\x00\x40\x00\x32\x06\x1e\xc0\x6f\xc5\xee\x1e\xac\x10\x20\x04\x5b\x41\xff\xfd\x5a\x0c\x47\xf0\x00\x00\x00\x00"...}]}, \{\{len=20, type=NLMSG_DONE, flags=0, seq=0, pid=0}, 0}], 262272, 0, NULL, NULL) = 388

不知道为什么实现监听流量时，厂家选择了基于NFLOG而不是AF_PACKET来做。

而在实现rootkit中，我们也可以用NFLOG作为被控端和主控端的通信方式，下面来看一下它有什么好处。

利用NFLOG做rootkit有什么好处

就像在 聊一聊基于"ebpf xdp"的rootkit 中我看到的: "rootkit用xdp ebpf和bpf技术都是为了通信时不监听端口，从而在网络行为上隐藏痕迹"。同样NFLOG也可以达到这个目的，甚至使用NFLOG相对于基于AF_PACKET的bpf后门从网络行为上看更隐蔽一点。为什么这么说呢？

举个例子，chkrootkit反入侵工具会通过/proc/net/packet检查哪些进程创建了PF_PACKET类型socket，因此可以发现bpf后门痕迹。

[root@instance-h9w7mlyv tmp]# gcc ifpromisc.c
[root@instance-h9w7mlyv tmp]# ./a.out
eth0: PF_PACKET(/usr/decoy/decoysvc, /usr/sbin/NetworkManager)
docker0: PF_PACKET(/usr/sbin/NetworkManager)

AF_PACKET 和 PF_PACKET 同义

chkrootkit目前就不会检查NFLOG后门。虽然从/proc/net/netlink也可以看到哪些进程创建了AF_NETLINK类型socket，但是系统上正常进程也会创建很多AF_NETLINK类型socket，比如我在centos8虚机上看到有30多个记录。

[root@instance-h9w7mlyv tmp]# cat /proc/net/netlink | wc -l
32

聊一聊chkrookit的误信和误用 文章提到chkrootkit会扫描PF_PACKET

利用NFLOG也应该比较稳定。为什么我这么认为呢？

一种HTTP隧道内核态远控的实现方法 文中提到一个思路: 在内核态基于netfilter实现一个可回显的后门。

而NFLOG有现成的lib库做用户态编程，相比于内核编程，我想用户态程序应该更稳定、适配性更好吧。

另外，iptables还提供了一个和NFLOG类似的扩展NFQUEUE，man iptables-extensions文档提到NFQUEUE可以修改数据包。所以是不是可以用NFQUEUE在用户态基于netfilter实现一个可回显的后门呢？

NFQUEUE后门demo

我们可以基于libnetfilter_queue写一个后门demo

代码我放在了 https://gist.github.com/leveryd/f70bd0adbf8088446d98ec11ef16f478

运行效果如下

因为我懒，所以这个后门没有实现回显。

总结

NFLOG在蜜罐、rootkit上都可以用到。

实现rootkit时，它的优点包括通信较为隐蔽、稳定、可回显。


  • 本文作者： leveryd
  • 本文来源： 先知社区
  • 原文链接： https://xz.aliyun.com/t/11673
  • 版权声明： 除特别声明外，本文各项权利归原文作者和发表平台所有。转载请注明出处！
赏

谢谢你请我吃糖果

支付宝
微信

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

俗话说“好记性不如烂笔头”，各个安全社区各自为战，当我们想要搜索某一方面的文章的时候总是得在各个平台之间来回横跳，于是乎，一个平台文章聚合搜索的想法诞生了。
然后正好我想有一个自己的博客，于是乎两者融合在了一起。
下面简单介绍各个导航的区别：
个人文章：本人的笔记、复现、总结等或者本人参与的共同创作。
收集文章：手工从公众号收集保存的文章，更新频率看本人喜好所以比较慢。
聚合文章：从各大平台收集整理，由工具实现，每天更新。
很惭愧，只做了一点微小的工作。