Безопасностьпротив безопасности

ПавелСемьянов, ЦентрЗащиты Информации СПбГТУ


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

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

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

Пример 1.Супервизор кусает локти

"Отсутствие механизмов автоматического запрещения аутентификации после нескольких неудачных попыток и временного закрытия бюджета (account) пользователя ... может при использование простых средств аутентификации привести к подбору параметров аутентификации" [1].

У сетевой ОС Novell Netware (пользующейсярепутацией достаточно защищенной ОС: по крайнеймере, Novell Netware 4.11 - единственная ОС широкогоназначения, имеющая американский сертификат поклассу защищенности для сетевых ОС) срединастроек есть пункт "Intruder Detection"(обнаружение нарушителей). Это громкоеназвание на самом деле ни что иное, какрегистрация на сервере неоднократных попытокввода неправильного пароля. Правильно ли это сточки зрения компьютерной безопасности?Безусловно, регистрация попыток невернойаутентификации - обязательное требование кзащищенным вычислительным системам, упоминаемоекак в импортных, так и отечественных нормативныхдокументах. Однако фирма Novell пошла несколькодальше - и логику тут легко понять -действительно, почему бы не просто фиксироватьтакие попытки, но и не пресекать их средствами ОС?Пусть хакер пытается подобрать пароль к вашемуресурсу (account) в системе, тогда через N1 попытоксистема выдает сообщение об попытке взлома, ачерез N2 - вообще блокируетдальнейшие попытки ввода паролей (в настройкахNovell Netware это называется "Lock account after detection").Логично? Безусловно. Правильно? А вот тут стоитчуть-чуть задуматься о том, что же означают слова"блокировать дальнейшие попытки вводапаролей". А означают они буквально следующее -в течение некоторого времени t ("Length of accountlockout") никакой пароль не будетвосприниматься системой, ваш ресурс будетзаблокирован (disabled). Иначе говоря, в течениеэтого времени t даже вам, законномупользователю, не дадут зарегистрироваться всистеме из-за действий хакера.

В настройках Novell Netware 3.x по умолчанию N1=3,N2=7, t=15 минут. И вот теперь представим, чтохакеру необходимо обезопасить свою новейшуюатаку на Novell Netware от возможных контрдействийсупервизора (замечу, супервизора, беспокоящегосяо проблемах безопасности, поэтому он включилопцию "Intruder detection"). Он вводит 7неправильных паролей супервизора, и в течении 15минут может спокойно реализовывать своюосновную атаку, супервизору останется лишькусать локти. Самое интересное, что блокировкаресурса супервизора приводит к невозможности ниудаленно подключится к консоли с помощью RCONSOLE, ниразблокировать клавиатуру на консоли (опция вутилите MONITOR.NLM), т.е. он не может помешать атакедаже с консоли сервера.

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

Безопасность о двухконцах


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

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

Таким образом, если условно разделить функцииподсистемы защиты на (см. рис. 1):

    1. профилактику (предотвращение)
    2. затруднение
    3. обнаружение
    4. противодействие (отражение)
    5. регистрацию (учет)
    6. восстановление

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

Рис. 1. Функцииподсистемы защиты.

К наиболее распространенным иуниверсальным (могущим существовать во многихВС) я бы отнес следующие сценарии нарушениябезопасности, использующие сами средства защиты(цифры соответствуют предыдущему списку):

1.

2. Затруднение угрозы приводит кустановке таких атрибутов безопасности, которыеявляются неприемлемыми для пользователей этойсистемы, что приводит к отключению илифактическому сведению на нет системы защиты (см. пример 4 - установка минимальной длиныпароля для атак на криптографическуюподсистему).

3. Система обнаружения угроз имееттакие расплывчатые признаки угрозы, что еепостоянное срабатывание приводит к ее полномуотключению (пример - резидентные антивирусныеблокировщики первого поколения, доводившиепользователя до исступления вопросами"Разрешать запись в файл XXX (Д/Н)?").

4.

    4.1. Система противодействия реализована так, что она останавливает систему в крайнем случае с целью не допустить потери информации в ней. Тогда хакер может смоделировать "крайний случай" и система выйдет из строя.

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

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

5. Использование системой регистрациизначительных ресурсов ЭВМ, из-за чего происходитотказ системы (см. пример 3 -переполнение файла регистрации событий,приводящее к отказу в обслуживании).

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

Далее будет рассмотрен ряд примеров,иллюстрирующий эти сценарии.

Пример 2.Меняйте пароли чаще!


"В случае однократной регистрации ... от пользователей необходимо потребовать, чтобы они регулярно меняли свои пароли" [2].

Опять Novell Netware. Известно, что всепароли пользователей хранятся в ней на сервере ввиде 128-битных значений, получаемых в результатеприменения хэш-функции к паролю. Знание этогохэш-значения злоумышленником автоматическиприводит к возможности зарегистрироваться насервере под именем того пользователя, чьехэш-значение он знает. (Это может быть сделано спомощью специальной слегка подправленнойпрограммы login, а также путем генерации"псевдопароля" из известного хэш-значения.Здесь используется тот факт, что хэш-функция,применяемая во всех версиях этой системы,является очень нестойкой и допускаеточень быстрое вычисление коллизий (т.е.последовательностей, которые будет на выходедавать одно и то же хэш-значение) [3]).

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

Но на помощь кракеру может прийтидругое мощное средство повышения безопасностисистемы Novell Netware (имеющееся, впрочем, почти вовсех ОС, претендующих на защищенность), а именно"заставлять периодически менять пароль" (forceperiodic password changes). Зная, что администратор системы"повысил" ее защищенность путемпериодической обязательной смены паролей,злоумышленнику остается только дождатьсямомента плановой смены паролей, и золотой ключик,т.е. хэш-значение супервизора у него в кармане.Этот пример я считаю весьма показательным.

Пример 3.Новый "нюк" (nuke) - система аудита Windows NT


"Данные протокола аудита могут быть утеряны из-за нехватки пространства памяти, выделенного для их хранения, сбоя системы..." [1]

Как известно, одна из версий Windows NTбыла сертифицирована по американскимтребованиям С2 для своего несетевоговарианта. И хотя эта сертификация вызывает многовопросов, существует утилита C2Config, котораяформально позволяет настроить Windows NT всоответствии с требованиями С2. В частности, этитребования распространяются и на подсистемурегистрации и учета (audit). Утилита C2Config предлагаетследующую настройку аудита для повышениябезопасности всей системы:

"Очистка протокола событий" (EventLog Wrapping) - "Не перезаписывать события (очищатьвручную)" (Do Not Overwrite Events (Clear Log Manually).

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

Однако смотрим следующий пункт меню:"Останавливать систему когда протоколбезопасности заполнен" (Halt system when security log isfull). Настройка по С2, естественно, "Да". Сточки зрения подсистемы аудита это, безусловно,правильно - протокол должен сохраняться всегда. Авот с точки зрения работоспособности системы?

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

Итак, многочисленными, но безвреднымидля системы запросами ее удалось "повесить".Зачем вам "нюки", господа кракеры, подаритененавистному администратору утилиту C2Config!

Что самое забавное, в рекомендацияхВМФ США о безопасной инсталляции Windows NT 4.0 [4] пункт об остановке системы припереполнении протокола событий нерекомендуется разрешать! Что ж, здравомыслиеиногда торжествует.

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

Пример 4.Пароль больше - кракеру проще


"... должны осуществляться идентификация и проверка подлинности субъектов доступа при входе в систему по идентификатору (коду) и паролю временного действия длиной не менее восьми буквенно-цифровых символов" [5].

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

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

Что же сделает пользователь? Пароль из6 символов типа "A95jwh" он еще в состояниизапомнить, а вот требуемый от него 15-символьный "Rg27#kjs$Zyx83a"он уже не запомнит никогда (тем более, если он унего не один и время от времени меняется). Итак, унего есть два пути:

  1. взять бессмысленный пароль и прикрепить его себе на монитор (варианты - системный блок, спрятать в ящик стола);

  2. ввести пароль, который он в состоянии запомнить.

А вот последних паролей не так много. В80% случаев это будут пароли типа "123456789012345","aaaaaaaaaaaaaab", "svetasvetasveta", "qwertyuiop[]asd","nuvy,blin,daete", "papauvasisilenv" - т.е. простыеповторяющиеся комбинации, рядом стоящие символына клавиатуре, припев популярной песенки и т.п. Атакие пароли кракерам может быть легче вскрыть,чем бессмысленные 6-символьные.

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

login <password.txt

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

Пример 5.Шифрование сетевого трафика


"К программным методам защиты в сети Internet можно отнести прежде всего защищенные криптопротоколы, с использованием которых появляется возможность надежной защиты соединения" [6].

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

Рассмотрим вероятность успеха одногоподвида атаки, направленного на отказ вобслуживании. Он "состоит в передаче с одногоадреса такого количества запросов на атакуемыйобъект, какое позволит трафик (направленный"шторм" запросов)" [6].

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

Теперь рассмотрим систему, защищеннуюот угрозы раскрытия применением методовшифрования. (Рассуждая с точки зренияэффективности, совершенно очевиден тот факт, чтокакими бы быстрыми не были применяемыекриптографические алгоритмы, пропускнаяспособность такой системы всегда будет меньше(обычно в 2-5 раз), чем системы без шифрования - т.к.пакеты нужно зашифровывать и расшифровывать). Вэтом случае хакер может несколько изменить своюатаку на шторм "псевдошифрованными" запросами.Допустим, криптографические алгоритмы вполнесовершенны, и хакер не может подделатьзашифрованный пакет так, чтобы он воспринималсякак правильный4. Но он вполнеможет подделать пакет так, чтобы он проходилпервую (быструю) проверку "по внешнему виду"и поступал в процедуру расшифровки. И вот толькоона сможет его отвергнуть, расшифровав.Теперь уже совершенно очевидно, что системасможет обрабатывать значительно меньше запросовв секунду, чем N, из-за необходимости ихрасшифровки. А такое снижение N (до 2 порядков)вполне может привести к тому, что для хакера оностанет достижимым!

Резюме


Так что же получается? Не надо менятьсвои пароли? Не надо использовать аудит? Не надошифровать трафик? Или же сформулированныйпринцип "неповышения вероятности другихугроз" невыполним? Я думаю, выполним. Простопри каждом решении, направленным на борьбу снекоторой угрозой, надо тщательнопроанализировать, как это решение скажется надругих угрозах. И, мне кажется, всегда можно найтиболее правильный вариант реализации решения.Фирме Novell надо было запрещать идентификацию приподборе паролей только с определенного сетевогоадреса (или, еще лучше, всегда разрешатьидентификацию с некоторого безопасного адреса).Администратору надо было поставить ограничениена длину пароля в 6 символов и объяснить, какпридумывать и запоминать неосмысленные пароли.Регистрацией некоторых событий в протоколепридется жертвовать, если он переполнен и еслибезотказность системы важна. При реализациисистемы шифрования пакетов надо придумать некуюсхему, которая позволяла бы отвергать пакет безего (полной) расшифровки, сведя к минимумуколичество необходимых для этого машинныхопераций.

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

 

1 Вот один изпоследних, упоминаний о котором я не встречал.Windows NT можно настроить так, чтобы она не надоедаласвоим требованием нажать Ctrl+Alt+Del и ввести пароль,а делала это сама - например, с помощью программы Autologon МаркаРуссиновича. Но при этом имя пользователя и егопароль будут хранится в реестре в открытом виде!Нужно ли говорить о том, что реестр иногда можетбыть просмотрен удаленно, а без установки Service Pack3 это делается вообще элементарно!

2 Знатоки NovellNetware не преминут меня подловить, сказав, что присмене пароля новое хэш-значение шифруетсястарым, и перехват его ничего не даст. А на этовозражу, что в некоторых случаях, а именно, еслипароль меняет супервизор через программу SYSCON,старое значение пароля у него не спрашивается.

3 Экспериментыпоказывают, что для компьютера класса Pentium/166 эточисло равно порядка 10000. Причем Windows NT (сустановкой даже Service Pack 4) при шторме такой силысбрасывалась в "синий экран".

4 А такжестоит защита от посылки повторных пакетов.

Литература

  1. П. Степанов. Анализ общих угроз безопасности в современных вычислительных системах. // Материалы конференции "Информационная безопасность автоматизированных систем", Воронеж, 1998 г.
  2. Уильям Вонг. В поисках собственного Я. // LAN, N 7, том 3, 1997.
  3. Павел Семьянов. Почему криптосистемы ненадежны. // Hackzone - территория взлома, N 1-2, 1998.
  4. Secure Windows NT Installation and Configuration Guide
  5. Руководящий документ. Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации. Гостехкомиссия России. - М., 1992.
  6. Медведовский И.Д., Семьянов П.В., Платонов В.В. Атака через Internet. - СПб.: "Мир и семья-95", 1997.