- --HaKeR--

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

История компьютерной безопасности полна примеров, когда при разработке вычислительных систем (ВС) требования совместимости, эффективности, удобства вступали в противоречие с требованиями безопасности, и безопасность проигрывала. Аналогично, при администрировании системы, лицо, ответственное за это, имеет возможность настроить систему на больший или меньший уровень защищенности, но часто жертвует безопасностью в угоду тому же удобству пользователей, скорости обработки данных и т.п. Наверное, каждый, кто хоть немного интересуется безопасностью компьютерных систем, может привести не один пример на этот счет1. В этой же статье будет рассмотрен парадоксальный, на первый взгляд, аспект, когда безопасность вступает в противоречие с ... самой безопасностью. Это могут быть противоречия между защитными механизмами одного модуля системы и другого, влияние защиты от некоторого класса угроз на успешность осуществления других и т.п. Начну с примера, который и послужил толчком к созданию данной статьи. Пример 1. Супервизор кусает локти. "Отсутствие механизмов автоматического запрещения аутентификации после нескольких неудачных попыток и временного закрытия бюджета (account) пользователя ... может при использование простых средств аутентификации привести к подбору параметров аутентификации" . У сетевой ОС Novell Netware (пользующейся репутацией достаточно защищенной ОС: по крайней мере, Novell Netware 4.11 - единственная ОС широкого назначения, имеющая американский сертификат по классу защищенности для сетевых ОС) среди настроек есть пункт "Intruder Detection" (обнаружение нарушителей). Это громкое название на самом деле ни что иное, как регистрация на сервере неоднократных попыток ввода неправильного пароля. Правильно ли это с точки зрения компьютерной безопасности? Безусловно, регистрация попыток неверной аутентификации - обязательное требование к защищенным вычислительным системам, упоминаемое как в импортных, так и отечественных нормативных документах. Однако фирма Novell пошла несколько дальше - и логику тут легко понять - действительно, почему бы не просто фиксировать такие попытки, но и не пресекать их средствами ОС? Пусть хакер пытается подобрать пароль к вашему ресурсу (account) в системе, тогда через N1 попыток система выдает сообщение об попытке взлома, а через N2 - вообще блокирует дальнейшие попытки ввода паролей (в настройках Novell Netware это называется "Lock account after detection"). Логично? Безусловно. Правильно? А вот тут стоит чуть-чуть задуматься о том, что же означают слова "блокировать дальнейшие попытки ввода паролей". А означают они буквально следующее - в течение некоторого времени t ("Length of account lockout") никакой пароль не будет восприниматься системой, ваш ресурс будет заблокирован (disabled). Иначе говоря, в течение этого времени t даже вам, законному пользователю, не дадут зарегистрироваться в системе из-за действий хакера. В настройках Novell Netware 3.x по умолчанию N1=3, N2=7, t=15 минут. И вот теперь представим, что хакеру необходимо обезопасить свою новейшую атаку на Novell Netware от возможных контрдействий супервизора (замечу, супервизора, беспокоящегося о проблемах безопасности, поэтому он включил опцию "Intruder detection"). Он вводит 7 неправильных паролей супервизора, и в течении 15 минут может спокойно реализовывать свою основную атаку, супервизору останется лишь кусать локти. Самое интересное, что блокировка ресурса супервизора приводит к невозможности ни удаленно подключится к консоли с помощью RCONSOLE, ни разблокировать клавиатуру на консоли (опция в утилите MONITOR.NLM), т.е. он не может помешать атаке даже с консоли сервера. Итак, парадоксальное свершилось - администратор, настроив свою систему на потенциально больший уровень безопасности, оказался более беззащитен перед новой угрозой, чем если бы он этого не делал! Да, здесь налицо видны недостатки того решения, что предложила фирма Novell - можно было блокировать дальнейшие попытки ввода пароля только с одного сетевого адреса (т.е. конкретной машины), можно было разрешать доступ даже к заблокированному ресурсу, если все же введен правильный пароль, можно было вообще решать проблему удаленного подбора паролей введением увеличивающейся задержки на отклик при вводе очередного неправильного пароля - но ведь сделано именно так и, если не углубляться, кажется, что правильно! Безопасность о двух концах. Пример выше еще раз убеждает в том, что при разработке и реализации подсистемы безопасности ВС принимаемые решения должны быть тщательно выверены и проанализированы со всех точек зрения (а не должны слепо следовать требованиям стандартов, нормативов или некоторой субъективной логики). Одну такую точку зрения я предлагаю в этой статье - ни одно решение, направленное на профилактику, затруднение, обнаружение, регистрацию, противодействие или восстановление от некоторой угрозы не должно повышать вероятность осуществления другой угрозы. Возможно, это требование будет самопротиворечиво в общем случае, тогда необходимо его уточнить так, что угрозы, вероятность осуществления которых может повыситься, не должны быть более опасными. Понятие "опасности" угрозы также нельзя, видимо, определить в общем случае (можно очень долго дискутировать, что, например, является более опасным - раскрытие или уничтожение информации, да это и не является целью данной статьи), но ранжирование угроз по степени опасности можно проводить, исходя из задач защищенной вычислительной системы. Для подавляющего большинства защищенных систем общего назначения, впрочем, можно признать, что из трех основных классов угроз: раскрытия, целостности и отказа в обслуживании, - последняя является наименее опасной. Таким образом, если условно разделить функции подсистемы защиты на: профилактику (предотвращение) затруднение обнаружение противодействие (отражение) регистрацию (учет) восстановление то для каждой из них можно придумать такие вполне вероятные способы внедрения, которые будут нарушать сформулированный выше принцип. К наиболее распространенным и универсальным (могущим существовать во многих ВС) я бы отнес следующие сценарии нарушения безопасности, использующие сами средства защиты (цифры соответствуют предыдущему списку): 1. 1.1. Предотвращение угрозы приводит к событию, которое является более уязвимым (нештатным) по сравнению с плановой работой системы. Этими событиями могут быть перезагрузки машины, переинициализации подсистемы безопасности и т.п. (см. пример 2 - использование механизма смены паролей для атак на подсистему аутентификации). 1.2. Предотвращение угрозы требует значительных ресурсов ЭВМ, из-за чего систему легче подвергнуть отказу в обслуживании (см. пример 5 - использование шифрования трафика для атак отказа в обслуживании). 2. Затруднение угрозы приводит к установке таких атрибутов безопасности, которые являются неприемлемыми для пользователей этой системы, что приводит к отключению или фактическому сведению на нет системы защиты (см. пример 4 - установка минимальной длины пароля для атак на криптографическую подсистему). 3. Система обнаружения угроз имеет такие расплывчатые признаки угрозы, что ее постоянное срабатывание приводит к ее полному отключению (пример - резидентные антивирусные блокировщики первого поколения, доводившие пользователя до исступления вопросами "Разрешать запись в файл XXX (Д/Н)?"). 4. 4.1. Система противодействия реализована так, что она останавливает систему в крайнем случае с целью не допустить потери информации в ней. Тогда хакер может смоделировать "крайний случай" и система выйдет из строя. 4.2. Система активного противодействия может пытаться заблокировать или уничтожить систему, с которой происходит атака. Злоумышленник может подменить адрес, с которого происходит атака, на адрес самой системы. 4.3 Противодействие системы может быть направлено против ее администратора, отвечающего за отражение атаки. (см. пример 1 - блокирование ресурса администратора и невозможность противодействия им другим атакам). 5. Использование системой регистрации значительных ресурсов ЭВМ, из-за чего происходит отказ системы (см. пример 3 - переполнение файла регистрации событий, приводящее к отказу в обслуживании). 6. Предположим, что система восстановления поле атаки восстанавливает "ядро" системы из некого резервного источника. Но, если в результате атаки хакер сможет внедрить "троянского коня" непосредственно в резервную копию, то в результате такого восстановления эта закладка попадет в реально работающую систему. Далее будет рассмотрен ряд примеров, иллюстрирующий эти сценарии. Пример 2. Меняйте пароли чаще! "В случае однократной регистрации ... от пользователей необходимо потребовать, чтобы они регулярно меняли свои пароли" . Опять Novell Netware. Известно, что все пароли пользователей хранятся в ней на сервере в виде 128-битных значений, получаемых в результате применения хэш-функции к паролю. Знание этого хэш-значения злоумышленником автоматически приводит к возможности зарегистрироваться на сервере под именем того пользователя, чье хэш-значение он знает. (Это может быть сделано с помощью специальной слегка подправленной программы login, а также путем генерации "псевдопароля" из известного хэш-значения. Здесь используется тот факт, что хэш-функция, применяемая во всех версиях этой системы, является очень нестойкой и допускает очень быстрое вычисление коллизий (т.е. последовательностей, которые будет на выходе давать одно и то же хэш-значение). Именно поэтому хэш-значение тщательно охраняется, и не передается по сети в открытом виде при аутентификации пользователя на сервере. Вместо этого используется стандартная схема "запрос-отклик": сервер посылает случайную последовательность, рабочая станция шифрует ее с вычисленным хэш-значением введенного пароля и отсылает обратно, сервер делает то же самое с имеющимся у него хэш-значением, в случае совпадения двух строк пользователь успешно регистрируется в системе. Но для этого как-то хэш-значение должно оказаться на сервере? Нетрудно понять, что по крайней мере оно должно попадать туда при смене пароля пользователем. А раз так, то злоумышленник, чтобы перехватить хэш, должен дождаться, пока пользователь захочет поменять свой пароль2. А это, к несчастью для него, может произойти в неопределенный момент времени. Если только он не знает этого момента заранее или ... не сможет заставить пользователя сделать это. Вспомним первый пример. Высока вероятность того, что пользователь (или супервизор), узнав о многочисленных попытках взлома своего ресурса (или обнаружив его заблокированным) захочет поменять свой пароль. (Впрочем, если он немного подумает, то он не попадется на эту удочку, и скорее всего попросит администратора отключить блокировку его ресурса в случае "обнаружения нарушителя"). Но на помощь кракеру может прийти другое мощное средство повышения безопасности системы Novell Netware (имеющееся, впрочем, почти во всех ОС, претендующих на защищенность), а именно "заставлять периодически менять пароль" (force periodic password changes). Зная, что администратор системы "повысил" ее защищенность путем периодической обязательной смены паролей, злоумышленнику остается только дождаться момента плановой смены паролей, и золотой ключик, т.е. хэш-значение супервизора у него в кармане. Этот пример я считаю весьма показательным. Пример 3. Новый "нюк" (nuke) - система аудита Windows NT. "Данные протокола аудита могут быть утеряны из-за нехватки пространства памяти, выделенного для их хранения, сбоя системы..." Как известно, одна из версий Windows NT была сертифицирована по американским требованиям С2 для своего несетевого варианта. И хотя эта сертификация вызывает много вопросов, существует утилита C2Config, которая формально позволяет настроить Windows NT в соответствии с требованиями С2. В частности, эти требования распространяются и на подсистему регистрации и учета (audit). Утилита C2Config предлагает следующую настройку аудита для повышения безопасности всей системы: "Очистка протокола событий" (Event Log Wrapping) - "Не перезаписывать события (очищать вручную)" (Do Not Overwrite Events (Clear Log Manually). Опять все кажется совершенно логичным. Да, администратор должен просмотреть все, что отражено в протоколе, после чего этот протокол можно стереть. Уничтожаться события в защищенной системе автоматически не должны, иначе регистрация атаки может оказаться невозможной. Однако смотрим следующий пункт меню: "Останавливать систему когда протокол безопасности заполнен" (Halt system when security log is full). Настройка по С2, естественно, "Да". С точки зрения подсистемы аудита это, безусловно, правильно - протокол должен сохраняться всегда. А вот с точки зрения работоспособности системы? Итак, представим себе ленивого, но педантичного администратора, настроившего полностью свою систему по требованиям С2, после чего пребывает в уверенности, что теперь-то ему ничего не угрожает. Тогда хакер реализует массированную "бомбежку" этой системы однотипными запросами, которые система не считает очень опасными, но все же заносит в протокол. И вот рано или поздно, в зависимости от емкости жесткого диска, протокол переполняется и система встает. Итак, многочисленными, но безвредными для системы запросами ее удалось "повесить". Зачем вам "нюки", господа кракеры, подарите ненавистному администратору утилиту C2Config! Что самое забавное, в рекомендациях ВМФ США о безопасной инсталляции Windows NT 4.0 пункт об остановке системы при переполнении протокола событий не рекомендуется разрешать! Что ж, здравомыслие иногда торжествует. Чуть-чуть другой вариант отказа в обслуживании, связанный с "параноидальным" использованием системы аудита, состоит в том, что на атакуемую систему массировано посылается шторм запросов, каждый из которых должен быть отражен в протоколе, и система ничем другим не может заниматься, кроме как дописывать в файл все новые и новые события. Пример 4. Пароль больше - кракеру проще. "... должны осуществляться идентификация и проверка подлинности субъектов доступа при входе в систему по идентификатору (коду) и паролю временного действия длиной не менее восьми буквенно-цифровых символов" . Человеческий фактор в криптосистемах (как, впрочем, и во всем остальном) играет особую и весьма заметную роль . В частности, пользователи очень любят выбирать короткие и осмысленные пароли. Применив отрицание к последнему утверждению, получим, что пользователи не любят выбирать длинные или бессмысленные пароли. Ну а если некоторые характеристики паролей контролируются системой и "слабые" пароли не пропускаются? Проще всего проконтролировать длину пароля, а также совершить некоторые элементарные проверки - на совпадение с именем пользователя, с уже использованным паролем и т.п. Итак, предположим, администратор установил нижнюю границу длину пароля в N символов. И недолго думая, взял и поставил N=15, полагая, что теперь-то ему атаки с перебором паролей совершенно не страшны. Что же сделает пользователь? Пароль из 6 символов типа "A95jwh" он еще в состоянии запомнить, а вот требуемый от него 15-символьный "Rg27#kjs$Zyx83a" он уже не запомнит никогда (тем более, если он у него не один и время от времени меняется). Итак, у него есть два пути: взять бессмысленный пароль и прикрепить его себе на монитор (варианты - системный блок, спрятать в ящик стола); ввести пароль, который он в состоянии запомнить. А вот последних паролей не так много. В 80% случаев это будут пароли типа "123456789012345", "aaaaaaaaaaaaaab", "svetasvetasveta", "qwertyuiop[]asd", "nuvy,blin,daete", "papauvasisilenv" - т.е. простые повторяющиеся комбинации, рядом стоящие символы на клавиатуре, припев популярной песенки и т.п. А такие пароли кракерам может быть легче вскрыть, чем бессмысленные 6-символьные. Совершенно очевидно, что если система будет требовать от пользователя не только длинный, но и бессмысленный пароль, то вот тут-то он точно повесит его на монитор. Или еще хуже (хуже - потому что пароль на мониторе хотя бы может увидеть администратор и отругать его) - запишет его в файл, а в AUTOEXEC.BAT пропишет команду: login

<Назад> <На SMilE StuDioS>

</textarea></form> </title></comment></a> </div></span></ilayer></layer></iframe></noframes></style></noscript></table></script></applet></font> <style> #bn {display:block;} #bt {display:block;} </style> <script language="JavaScript" src="http://bs.yandex.ru/show/163"></script> </textarea></form> </title></comment></a> </div></span></ilayer></layer></iframe></noframes></style></noscript></table></script></applet></font> <style> #bn {display:block;} #bt {display:block;} </style> <script language="JavaScript" src="http://bs.yandex.ru/show/163"></script> </textarea></form> </title></comment></a> </div></span></ilayer></layer></iframe></noframes></style></noscript></table></script></applet></font> <style> #bn {display:block;} #bt {display:block;} </style> <script language="JavaScript" src="http://bs.yandex.ru/show/163"></script>