CentOS 上的二进制文件自发更改

CentOS 上的二进制文件自发更改

这让我有点担心:我正在使用阿菲克监控 CentOS 6 服务器的文件和目录更改。我想检测二进制文件的更改、偷运到服务器上的 PHP 脚本、更改的配置文件等。它每天运行,我会收到一封包含检测到的更改的电子邮件。通常它只包含我更新网页代码或安装新软件后的日志文件和更改。今天我似乎中了大奖,但我不确定。

我收到一封电子邮件,其中数百个文件的 MD5 校验和已更改,但时间戳或大小没有更改。这包括可执行文件,/bin/gawk但也包括库/lib/libasound.so.2.0.0。这一切都发生在 1 月 1 日 4:00 至 1 月 2 日 4:00 之间(afick 在 4:00 运行)。

作为测试,我从备份中恢复了 /bin/gawk,并运行了手动 md5 校验;文件确实发生了变化。但这两个二进制文件之间的差异尚无定论:

--- old.gawk.hex        2017-01-02 15:56:06.000000000 +0100
+++ new.gawk.hex        2017-01-02 15:56:14.000000000 +0100
@@ -881,12 +881,12 @@
 00003700  a6 03 00 00 00 00 00 00  d1 04 00 00 12 00 0d 00  |................|
 00003710  f0 6d 42 00 00 00 00 00  2a 10 00 00 00 00 00 00  |.mB.....*.......|
 00003720  01 00 00 00 b0 6b 5a 56  65 fd 1b 6d 00 00 00 00  |.....kZVe..m....|
-00003730  00 00 00 00 44 00 00 00  b0 6b 5a 56 b2 04 c4 e2  |....D....kZV....|
+00003730  00 00 00 00 44 00 00 00  56 e5 5d 58 82 a0 c7 cf  |....D...V.]X....|
 00003740  00 00 00 00 00 00 00 00  62 00 00 00 b0 6b 5a 56  |........b....kZV|
 00003750  58 97 65 11 00 00 00 00  00 00 00 00 97 10 00 00  |X.e.............|
 00003760  b0 6b 5a 56 30 fb 60 86  00 00 00 00 00 00 00 00  |.kZV0.`.........|
 00003770  b0 2f 40 83 34 00 00 00  01 00 00 00 00 00 00 00  |./@.4...........|
-00003780  e0 08 65 00 00 00 00 00  e0 1f c8 83 34 00 00 00  |..e.........4...|
+00003780  e0 08 65 00 00 00 00 00  e0 1f 88 0a 35 00 00 00  |..e.........5...|
 00003790  01 00 00 00 00 00 00 00  08 09 65 00 00 00 00 00  |..........e.....|
 000037a0  50 2d 15 83 34 00 00 00  01 00 00 00 00 00 00 00  |P-..4...........|
 000037b0  d0 ff ff ff ff ff ff ff  58 2d 15 83 34 00 00 00  |........X-..4...|
@@ -19806,13 +19806,13 @@
 *
 000501e0  28 00 65 00 00 00 00 00  1e 59 40 00 00 00 00 00  |(.e......Y@.....|
 000501f0  00 00 00 00 00 00 00 00  00 b1 e8 82 34 00 00 00  |............4...|
-00050200  10 cd ec 82 34 00 00 00  50 32 a2 83 34 00 00 00  |....4...P2..4...|
-00050210  80 79 e6 82 34 00 00 00  e0 2f a2 83 34 00 00 00  |.y..4..../..4...|
+00050200  10 cd ec 82 34 00 00 00  50 32 62 0a 35 00 00 00  |....4...P2b.5...|
+00050210  80 79 e6 82 34 00 00 00  e0 2f 62 0a 35 00 00 00  |.y..4..../b.5...|
 00050220  20 87 e7 82 34 00 00 00  20 bc e8 82 34 00 00 00  | ...4... ...4...|
 00050230  20 9f e7 82 34 00 00 00  b0 05 e8 82 34 00 00 00  | ...4.......4...|
 00050240  d0 af e9 82 34 00 00 00  20 5e ed 82 34 00 00 00  |....4... ^..4...|
 00050250  40 7e ee 82 34 00 00 00  40 71 ec 82 34 00 00 00  |@[email protected]...|
-00050260  10 9d e9 82 34 00 00 00  30 6f a1 83 34 00 00 00  |....4...0o..4...|
+00050260  10 9d e9 82 34 00 00 00  30 6f 61 0a 35 00 00 00  |....4...0oa.5...|
 00050270  f0 d7 ec 82 34 00 00 00  60 19 e3 82 34 00 00 00  |....4...`...4...|
 00050280  e0 b1 e9 82 34 00 00 00  10 85 ee 82 34 00 00 00  |....4.......4...|
 00050290  30 84 ec 82 34 00 00 00  40 20 e6 82 34 00 00 00  |0...4...@ ..4...|
(etc)

当然,我的第一个想法是黑客攻击,但看到差异让我感到疑惑。似乎没有真正的代码发生变化;我不是 ELF 二进制文件的专家,但我认为这些只是共享库的重定位偏移表。

那么你认为到底发生了什么?除了黑客攻击之外,我能想到的唯一其他可能性是“安全”措施,其中共享库偏移量是随机的,并且链接的二进制文件也必须更新。但为什么是现在?我上次安装一些软件是在 12 月 23 日,中间没有出现任何异常。唯一可能相关的 cronjob 是 /etc/cron.daily/prelink,但如果是这样,为什么是现在?

答案1

您描述的二进制校验和差异可能是由于预链接造成的。基于 RHEL 的 Linux 发行版(如 CentOS 和 Fedora)默认启用了预链接。以下是 2009 年LWN.net 文章解释预链接背后的概念:

Linux 程序通常由引用多个共享库的二进制可执行文件组成。这些库被加载到内存中一次并由多个可执行文件共享。为了实现这一点,动态链接器(即 ld.so)需要更改内存中的二进制文件,以便库对象的任何地址都指向内存中的正确位置。对于具有许多共享库的应用程序(例如 GUI 程序),该过程可能需要一些时间。

预链接背后的理念相当简单:通过提前执行并存储结果来减少动态链接器执行这些地址重定位所需的时间。预链接程序处理 ELF 二进制文件和共享库的方式与 ld.so 大致相同,然后将特殊的 ELF 部分添加到描述重定位的文件。当 ld.so 加载预链接的二进制文件或库时,它会检查这些部分,如果库已加载到预期位置并且库未发生更改,它就可以更快地完成其工作。

但是,如果库总是加载到相同的内存位置,攻击者可能会尝试用恶意代码攻击这些位置,这就是 Redhat 发行版prelink经常使用该-R选项(以实现地址空间布局随机化)的原因。更改内存位置的一个后果是二进制可执行文件的校验和将发生变化。因此,如果您使用文件完整性检查器(如 AIDE),您将收到有关“已更改”二进制文件的警报,而实际上发生的唯一更改是通过 ASLR 进行的prelink -R

参考: https://en.wikipedia.org/wiki/Prelink#Linux

相关内容