Cтуденти кафедри комп’ютеризованих систем захисту інформації
Гулак Д.О., Бєтанов Е.В. , Васильєв А.О.
Національний авіаційний університет, Україна
Основні вразливості Unix-систем
Поточна ситуація на ринку ОС
сигналізує про початок зросту інтересу до
вільних ОС з відкритим кодом, в тому числі і до Unix-подібних
ОС. Саме час звернути увагу на те, що розробники ОС Unix не
надавали особливої уваги питанням захисту, і з цієї причини ні одну з Unix-систем
не можна зробити по-справжньому безпечною. ОС Unix
орієнтована насамперед на зручність у застосуванні, що аж ніяк не припускає
природність і простоту її захисту. Саме безкоштовність та відкритість Unix
залишає її найбільш «захищеною» від спроб зламати її багатьма хакерами. В даній
статті приводиться узагальнена класифікація основних вразливостей Unix,
що дозволить ширше поглянути на проблеми інформаційної безпеки в даних системах
та допоможе у розробленні відповідних засобів захисту.
Першочерговими причинами, за якими відбувається більшість всіх випадків злому Unix -хостів це:
1. Програми з вразливостями.
2. Наявність демонів.
3. Механізм SUID / SGID-процесів.
4. Зайва довіра.
5. Людський фактор з дуже різними способами його
прояву - від паролів у звичайних користувачів, що легко розкриваються, до
помилок у кваліфікованих системних адміністраторів, багато з яких якраз і
відкривають шлях для використання механізмів довіри.
До першої можна віднести класичну ситуацію з переповненням буфера або
розмірності масиву. Зауважимо відразу, що конкретні атаки, незважаючи на
універсальність способу, завжди будуть залежними від системи і орієнтованими
тільки на конкретну платформу і версію Unix.
Рис.1 «Причини вразливості Unix»
Механізми
2 і 3, які є невід'ємною частиною ідеології Unix, завжди являють собою інтерес для хакерів, так як користувач в цьому
випадку взаємодіє з процесом, у яких великі привілеї, і тому будь-яка помилка
або недоробка в ньому автоматично веде до використання цих привілеїв.
Причини,
за яких демони і SUID / SGID-процеси стають вразливими:
· Можливість виникнення непередбачених ситуацій,
пов'язаних з помилками або недоробками в програмуванні.
· Наявність прихованих шляхів взаємодії з програмою,
що звуться "люками" (класичний приклад – це налагоджувальний режим у sendmail).
· Можливість підміни суб'єктів та об'єктів різним
чином.
Що стосується підміни, то для
деяких версій Unix існує атака, пов'язана
з підміною IFS (внутрішній роздільник полів - символ роздільника команд або
функцій) на символ "/". Коли програма викликає
/bin/sh, замість нього викликається файл bin з параметром sh у поточному
каталозі.
І
останнє - не можна применшувати роль людини в забезпеченні
безпеки будь-якої системи. Неправильне адміністрування - теж дуже актуальна
проблема, а для Unix вона особливо гостра,
оскільки складність адміністрування Unix-систем
давно стала частого предмету обговорення. Більш того, якщо говорити про
слабкість людини, захищені системи зазвичай відмовляються і ще від однієї з
основних ідей Unix - наявності
суперкористувача, що має доступ до всієї інформації і нікому не
підконтрольного.
Помилки у програмах. Найбільш поширеними атаками тут є «стан гонки» і атаки переповнення буферу. Стан гонки виконується шляхом ретельного планування певного порядку виконання, що дозволить програмі виконуватися в неправильному порядку. Програмісти можуть уникнути цієї проблеми за допомогою правильних навичок програмування (наприклад, використовуючи метод замка і ключа; ключ дозволяє закривати файл, поки користувач не відкриє ним файл і не надасть сам ключ).
Переповнення буфера може
викликати аварійне завершення або зависання програми, що веде до відмови обслуговування (DoS).
Окремі види переповнення, дозволяють зловмиснику завантажити і виконати
довільний машинний код від імені програми і з правами облікового запису, від якої
вона виконується.
З
виходом версії 8.8.3 sendmail (починаючи з версії 8 містить підтримку MIME),
була виявлена уразливість системи безпеки, яка дозволяє віддаленим користувачам
виконувати довільні команди на локальній системі з привілеями адміністратора.
Відправляючи ретельно оброблені повідомлення електронної пошти в систему з
працюючою уразливою версією sendmail, зловмисники можуть викликати переповнення
буфера і примусово змусити sendmail виконувати довільні команди з привілеями
адміністратора.
У
більшості випадків, MIME-перетворення електронної пошти обробляються по
закінченню доставки, тобто в локальній поштовій скриньці або програмі. Таким
чином, ця уразливість може бути використана в системах, незважаючи на
брандмауери та інші мережеві граничні захисні заходи. Віддалений користувач навіть може
не мати доступ до акаунту в системі та отримати повноваження
суперкористувача на машині під управлінням sendmail версії 8.8.3 або 8.8.4, яка
виконує 7-в-8 біт перетворення MIME.
Виконання коду незареєстрованими користувачами.Очевидно, що будь-який користувач Інтернету завжди має привілеї
третього рівня (псевдо-користувач) на вашому хості, а також, якщо підтримується
відповідний сервіс, привілеї другого рівня (спеціальний користувач). Завданням
хакера є несанкціоноване отримання привілеїв більш високого рівня. Розглянемо
далі типові сценарії отримання привілеїв.
"Відразу в дамки" - маючи привілеї третього рівня, хакер отримує права суперкористувача.
Такий стрибок можливий завдяки механізму демонів Unix, що відповідають за обробку віддалених запитів: sendmail, FTPD, fingerd та ін. Так як ці демони найчастіше виконуються
від імені суперкористувача, то все, що потрібно псевдо-користувачу, - це знати
існуючі "дірки" або помилки в цих демонах, які дозволять експлуатувати
їх нестандартним або забороненим чином (наприклад, віддалено виконати від
їхнього імені команду на вразливому хості).
"Із
спеціального - на звичайного, або вище". Для хакера потрібні початкові
привілеї другого рівня - запущений деякий додатковий сервіс. Привілеї другого
рівня можуть дати можливість хакеру читати деякі файли (наприклад, з ~ftp/pub) і, що найголовніше, записувати свої
файли на ваш комп'ютер (у каталог типу ~ftp/incoming). Типовим прикладом атаки за таким сценарієм є атака, яка по протоколу
TFTP отримує файл паролів /etc/passwd, а потім з
його допомогою підбираються паролі користувачів. Цей приклад показує, що
необов'язково бажані привілеї будуть отримані негайно. Такі атаки можуть лише
створити передумови для можливого їх отримання в подальшому.
Небезпека застосування атрибутів SUID / SGID. Нерозумна кількість SUID-програм, розкиданих по всій системі, може призвести до проблем. Для деяких програм цей атрибут є дійсно необхідним, оскільки без нього звичайні користувачі не зможуть скористатися цими програмами. Загальний підхід у даному випадку наступний: якщо немає дійсно вагомих причин призначати деякому файлу атрибут SUID, робити цього не слід.
Сценарій "зі звичайного - у суперкористувача", мабуть, найбільш простий і широко поширений. Більшість витоків інформації
відбувається через "своїх" - підкупленого співробітника, який хай і
не має великих повноважень, але вже вхідне ім'я на секретний комп'ютер у нього
є.
Своєю здійсненністю атаки даного роду зобов'язані механізмам SUID / SGID-процесів. Стандартним прийомом вважається копіювання файлу з командним інтерпретатором (наприклад, sh) в корінь і установка на нього атрибуту SUID root. Таким чином, зловмисник має під рукою стандартну програму sh, але всі команди в ній він виконує від імені суперкористувача. Найбільш відомий приклад – це програма passwd, яка виконується користувачем коли йому потрібно змінити пароль.
Вразливості на основі проблем довіри. У Unix існує багато підсистем, що використовують довіру. Найбільш простими і
часто вживаними з них є так звані r-служби (r - remote - віддалені). За
наявності файлів .rhosts і hosts.equiv, що містять імена хостів, доступ з них
можливий без вказівки пароля. Наприклад файл
/etc/hosts.equiv може бути використаний системним адміністратором для того, щоб
вказати довірені вузли (як правило, IP-адреса або ім'я хоста). Кожен довірений
хост перерахований у файлі, і якщо користувач намагається увійти в систему (з
використанням rlogin) або виконати команду (з використанням rsh) віддалено з
однієї з систем, перерахованих в hosts.equiv, і цей користувач має обліковий
запис на локальній системі з таким самим логіном, то доступ дозволяється без
запиту пароля. Тому даний механізм вразливий перед атакою IP-спуфінга (полягає
в проставленні у полі зворотного (source) адресу IP-пакета неправильно вказану
адресу.).
Список використаної літератури
1.
Collin Beck, Virus Safety of Linux
2.
Классификация
пользователей и типовых сценариев атак в UNIX. http://bugtraq.ru/library/books/attack/chapter09/01.html