BASH must die

Иван Скляров

Xakep, номер #061, стр. 061-060-1

(sklyarov@real.xakep.ru)

Или как противостоять шеллкоду

Пожалуй, самая лакомая цель для хакера – это получение интерактивного доступа к командной оболочке атакуемой машины. Немалую роль в этом играют так называемые эксплоиты, открывающие доступ к оболочке через определенную уязвимость в одном из сервисов (демоне). Для защиты от таких атак разработаны специальные технологии. Пример этому: StackGuard, FormatGuard и OpenWall. В этой статье я хочу предложить еще один способ. Возможно, он уже где-то описан, однако мне еще не попадались подобные решения.

Суть способа

При обычном входе в систему после выполнения login и авторизации запускается командный интерпретатор с определенными правами (здесь и далее речь будет идти только о Linux-системах). Однако shellcode обходит авторизацию и выполняет /bin/sh с правами уязвимого демона (обычно root). Большинство известных шеллкодов для запуска оболочки пользуются следующим кодом (см. Phrack 49-14, «Smashing The Stack For Fun And Profit» by Aleph One):

Сишный шеллкод

#include <stdio.h>

int main() {

char *name[2];

name[0] = "/bin/sh";

name[1] = NULL;

execve(name[0], name, NULL);

}

Сразу возникает такая мысль: а что, если бы авторизация происходила не ДО запуска оболочки, а сразу ПОСЛЕ ее старта? В таком случае, даже после успешного выполнения шеллкода, хакеру все равно понадобятся знания логина и пароля! Однако на практике такой идеальный случай осуществить проблематично или просто невозможно. Но что нам мешает сделать двухступенчатую авторизацию?! Т.е. после прохождения login уже сама оболочка в обязательном порядке требует повторной авторизации. Конечно, это внесет некоторое неудобство в работу легального пользователя, однако практически на 100% отпугнет от системы полчище script-kiddies, которые как раз и являются самым большим проклятием для администратора. Рассмотрим реализацию этого способа на наглядном примере, а также выявим некоторые его плюсы и минусы.

Реализация способа

В общем случае можно обозначить два варианта:

1. Оболочка требует ввода логина и пароля (или только пароля), идентичных тем, которые вводились при прохождении login.

2. Оболочка использует отдельную систему авторизации и требует логин и пароль (или только пароль), отличающиеся от стандартных в /etc/shadow.

Второй способ лучше в плане безопасности, т.к. некоторые шеллкоды могут добавлять новую учетную запись в /etc/shadow. Понятно, что если система защищена с помощью второго способа, то все эти действия не будут иметь особого значения, т.к. для получения полноценного доступа к оболочке нужно будет знать ее собственную систему авторизации, которая может быть реализована совершенно непредсказуемым способом. Однако первый способ легче в реализации, поэтому я опишу именно его. Но в реальной системе лучше использовать второй вариант.

Для наглядности напишем прототип оболочки, выполняющий все ее основные функции (исходник можно взять на нашем сайте или на диске к журналу). Назовем нашу псевдооболочку - xsh (расшифровку аббревиатуры оставляю на твоей совести). Компиляция осуществляется следующей строкой: gcc xsh.c -o xsh -lpam -lpam_misc -lncurses –lreadline. Несмотря на то, что я называю xsh псевдооболочкой, на самом деле она является почти полноценным шеллом. В ней отсутствуют лишь некоторые возможности, присущие любой нормальной оболочке, а именно: конвейеры, перенаправления, фоновое выполнение команд и собственный язык скриптов. Кратко рассмотрим работу xsh.

Содержание  Вперед на стр. 061-060-2
ttfb: 3.3469200134277 ms