Как выявить подмену системных библиотек в .so-файлах Linux

Системные библиотеки — это то, на чём держится всё в Linux. Замените один .so-файл на модифицированную версию, и вы получите скрытый бэкдор, который не увидит ни один антивирус. Программа выглядит как обычная часть системы, её цифровая подпись может быть валидной, а поведение — неотличимым от нормы. Разбираться с этим приходится инженерам безопасности и администраторам, которые получили инцидент или подозрение на компрометацию. В этой статье — практические способы обнаружить такую подмену от простых проверок до глубокого анализа.

Почему вообще кто-то подменяет .so-файлы

Атакующему не нужно ломать вашу систему через уязвимость, когда можно тихо заменить одну библиотеку, при загрузке которой его код выполняется с правами того процесса, который её подключил. Замена libssl.so позволяет перехватывать трафик. Троян в libc.so даёт контроль почти над всеми процессами. Некоторые зловредные программы просто добавляют свои вызовы внутрь штатных функций, чтобы оставлять бэкдоры или воровать данные, активность которых не проявляется.

Первые шаги: признаки, что с системой что-то не так

Перед тем как лезть в библиотеки, стоит проверить, есть ли вообще подозрения. Нужный вам способ — проверка контрольных сумм, мониторинг файловой системы, анализ сетевой активности. Начните с простого:

• Процесс, который вы не запускали, потребляет необычно много CPU или памяти и держится постоянно.

• Сетевые соединения с неизвестными удалёнными адресами, особенно если они появляются через равные промежутки времени.

• Изменение размера или даты модификации системного файла, которое произошло не после обновления.

• error сегментации в стабильном приложении, которое раньше работало без сбоев.

Если вы отвечаете на эти признаки в своей системе, стоит проверять действительно ли библиотеки, с которыми работают процессы, не были заменены.

Проверка контрольных сумм: быстро, но не всегда полезно

Первое, что приходит в голову: сверить файл с эталонным. В пакетных менеджерах Debian/Ubuntu и Red Hat/CentOS встроены утилиты, которые умеют проверять целостность установленных пакетов.

Для Debian/Ubuntu:

dpkg --verify
debsums -e

Для основанных на RPM:

rpm -Va

Команда rpm -Va проверяет все файлы, зафиксированные в базе RPM, сравнивая их размеры, права, контрольные суммы и другие атрибуты. Если библиотека была заменена, вы увидите изменения в выводе.

Но у этого метода есть серьёзный ограничение: он опирается на базу пакетного менеджера. Если зловред проник в систему и модифицировал саму эту базу (а это вполне реально при получении root-прав), проверка ничего не покажет. Кроме того, на скомпрометированном сервере вы не можете доверять ничему, что вам говорит система.

Что делать в этом случае:

1. Скачайте эталонный .rpm или .deb пакет с официального источника на чистую машину.

2. Извлеките из него библиотеку: rpm2cpio package.rpm | cpio -idmv ./path/to/lib.so или dpkg-deb --extract package.deb ./extract_dir.

3. Сравните контрольные суммы эталона и файла на сервере: sha256sum обоих файлов.

Если суммы различаются — у вас проблема. Но имейте в виду: подмена могла быть сделана и с учетом того, что атакующий знал о таких проверках. Серьёзный зловред может подменять файл только при чтении определёнными способами, оставляя на диске оригинал. Поэтому одних контрольных сумм недостаточно.

Проверка цифровых подписей и бинарных файлов

На современных дистрибутивах многие библиотеки подписаны разработчиками. Проверить подпись можно через gpg для самих пакетов, а для ELF-бинарей используется встроенная проверка через pesign (в системах с UEFI Secure Boot) или вручную через readelf.

Более практичный подход — извлечь информацию из самого файла:

readelf -d /path/to/library.so
file /path/to/library.so
strings /path/to/library.so | grep -i "backdoor\|hook\|inject"

Команда readelf -d покажет динамические секции — если там есть необычные записи, сомнительные зависимости или изменения в адресах это сигнал. file быстро определит, действительно ли перед вами корректный ELF-файл ожидаемой архитектуры, а если это скрипт или просто текст — значит, что-то пошло не так. Через strings можно найти подозрительные строки и URL, которых в штатной библиотеке быть не должно.

Мониторинг в реальном времени: а что сейчас загружено?

Серьёзный инструмент обнаружения подмены — мониторинг того, какие библиотеки реально загружены в процессы прямо сейчас. Даже если файл на диске выглядит правильно, зловред может быть загружен динамически из скрытого места.

lsof и ltrace — ваши друзья:

lsof -p PID | grep "\.so"
ltrace -p PID -e "*dlopen*"
strace -p PID -e trace=open,openat

lsof покажет все открытые файлы процесса, включая загруженные .so. Посмотрите, нет ли библиотек из нестандартных путей (всё, что не в /lib, /usr/lib и подобных — подозрительно). ltrace перехватывает вызовы динамических библиотек в реальном времени, а strace с фильтром на open и openat покажет все попытки открыть файл.

Ещё один полезный приём: проверьте, что видит сам процесс в /proc/[pid]/maps:

cat /proc/$(pgrep suspected_process)/maps | grep "\.so"

Это покажет все загруженные в память библиотеки с их полными путями. Если путь ведёт во временную директорию или к файлу с нелогичным именем — бейте тревогу.

Сравнение загруженного в память и на диске

Один из самых надёжных методов — сравнить, что файл на диске идентичен тому, что загружен в оперативной памяти. Для этого есть инструмент memfd_create и анализ /proc/[pid]/mem, но на практике проще использовать готовые решения.

Volatility Framework для анализа дампов памяти позволяет извлечь загруженные модули и сравнить их с дисковыми версиями. Это уже уровень форензики, но если у вас есть подозрение на серьёзную компрометацию, такой анализ может выявить расхождения, которые не видны штатными средствами.

Инструменты для автоматизированного поиска

В таблице основные инструменты, которые реально используются на практике:

Как отличить подмену от штатного обновления

Сложность в том, что библиотеку могли обновить легитимно, и ваша проверка покажет расхождение с эталоном. Не нужно сразу бить в колокола. Разберитесь:

• Проверьте историю пакетного менеджера: grep "install\|upgrade" /var/log/dpkg.log для Debian, rpm -qa --last | head -20 для Red Hat. Если библиотека обновлялась — расхождение ожидаемо.

• Сравните версий файла с соседними серверами аналогичной конфигурации, если они есть.

• Проверьте размер и дату изменения: штатное обновление обычно меняет файлы согласовано, в определённый день. Подмена часто имеет дату, выпадающую из общего паттерна.

Частые ошибки при выявлении подмен

Не надейтесь только на контрольные суммы — их легко обойти. Если вы ищете реальное решение, используйте многоуровневый подход.

Не проверяйте файлы из скомпрометированной системы utilities вроде ls, md5sum, dpkg могли быть заменены. Загружайтесь с live-USB и монтируйте диск для анализа.

Не забывайте про дампы памяти — саботаж мог произойти до перезагрузки, но в памяти ещё остались следы. // Формулировка нечёткая, переделаем совет.

Частые заблуждения:

• «Если rpm -Va ничего не показывает, значит, подмены нет» — нет. Зловред мог подменять вызовы на уровне загрузчика или работать только в памяти.
• «Мы проверяем контрольные суммы раз в суток, этого достаточно» — если зловред активен, он может откатить ваши изменения в ту же секунду.
• «Библиотека без изменений, потому что дата не вызывает подозрений» — серьёзные зловреды подменяют временные метки, чтобы скрыть следы.

Как лучше поступить: зависимость от вашего случая

Если вы админ и получили сообщение об изменении системного файла:

1. Не паникуйте. Запустите rpm -Va или debsums и зафиксируйте, что изменилось.

2. Сверьте с историей обновлений. Нет ли там легитимной причины?

3. Если расхождение подтверждается и не объясняется — выключите сетевой доступ для этого сервера и загрузитесь с live-носителя для анализа.

4. Скачайте эталонный пакет и сравните sha256sum ключевых библиотек.

Если вы реагируете на уже подтверждённую компрометацию:

1. Делайте дампы памяти и диска в текущем состоянии для последующего расследования.

2. Начинайте анализ с загрузочного live-окружения, доверяя только внешним носителям.

3. Проверьте все .so-файлы, которые были загружены из нестандартных мест.

4. Онлайн-базы вроде VirusTotal могут помочь идентифицировать известные зловредные файлы, но не дадут 100% гарантии.

Если вы поддерживаете парк из сотен серверов:

1. Автоматизируйте инвентаризацию библиотек с помощью систем вроде Ansible + скриптов, собирающих хэши всех .so.

2. Настройте OSSEC или Wazuh на контроль целостности с реакцией на изменения.

3. База хэшей должна храниться в защищённом хранилище и обновляться только через контролируемый канал.

Что в итоге

Выявить подмену .so-файла — это не одна волшебная команда, а последовательность шагов: от простой проверки контрольных сумм до анализа дампов памяти. На чистом сервере начните с rpm -Va или debsums. Если подозрение серьёзное — загрузитесь с live-USB и сравнивайте с эталонами извне. Для постоянной защиты используйте AIDE, OSSEC или аналоги, но помните, что их базу тоже нужно беречь от модификации.

Главное правило: не доверяйте системе, которую подозреваете. Любые инструменты, запущенные на ней, могут показывать подчищенные результаты. Только анализ вне среды даёт объективную картину.