Сегодня представляем вашему вниманию перевод разделов 11.3 и 11.4 книги «Kali Linux Revealed». Они посвящены формализации исследований безопасности информационных систем и типам атак, на устойчивость к которым проверяют системы во время анализа их защищённости.
→ Часть 1. Kali Linux: политика безопасности, защита компьютеров и сетевых служб
→ Часть 2. Kali Linux: фильтрация трафика с помощью netfilter
→ Часть 3. Kali Linux: мониторинг и логирование
→ Часть 4. Kali Linux: упражнения по защите и мониторингу системы
→ Часть 5. Kali Linux: оценка защищённости систем
→ Часть 6. Kali Linux: виды проверок информационных систем
11.3. Формализация исследования
После того, как подготовлена ваша Kali Linux и определён тип исследования, вы почти готовы к тому, чтобы приняться за дело. Однако, остался ещё один шаг: формализация исследования. Это крайне важно, так как на этом шаге определяется то, чего именно ожидает от вас клиент. Кроме того, здесь вам выдают разрешение на проведение операций, которые в обычных условиях являются незаконными. Мы рассмотрим всё это в общих чертах, но перед нами очень непростой и важный этап подготовки к исследованию систем на уязвимость, поэтому, вполне возможно, на данном этапе вам стоит посоветоваться с юристом вашей организации.
Частью процесса формализации является определение правил исследования, которым вы будете следовать в ходе работы. Эти правила касаются следующего:
- С какими системами вы можете взаимодействовать? Важно иметь уверенность в том, что вы случайно не вмешаетесь в работу систем, жизненно важных для исследуемой компании.
- В какое время суток вы можете работать, с какой периодичностью можно проводить сеансы исследования системы? Некоторые организации предпочитают ограничивать число таких сеансов.
- Если вы обнаружите потенциальную уязвимость, можете ли вы её эксплуатировать? Если нет — тогда каков процесс подтверждения наличия уязвимости? В некоторых организациях предпочитают жёстко контролировать каждую попытку эксплуатации уязвимостей, в других используют подход, более или менее реалистично имитирующий настоящую атаку. Лучше всего выяснить эти моменты заранее.
- Если найдена серьёзная проблема, как нужно поступить? Иногда организации ожидают немедленного оповещения об этом, в противном случае об этом обычно сообщают в конце исследования.
- С кем можно связаться в случае крайней необходимости? Всегда важно знать, с кем можно связаться если возникнут какие-либо проблемы.
- Каков перечень лиц, которые будут знать о том, что проводится исследование? Как информация об этом будет доведена до этих лиц? В некоторых случаях организации хотят проверить реакцию их внутренних служб на происшествие, а также способность этих служб обнаруживать вторжения. Лучше всего знать об этом заранее, так как при таком подходе вы сможете, при необходимости, провести исследование скрытно.
- Чего ждёт компания после завершения исследования? Как сообщить о результатах? Заранее выясните, что именно все заинтересованные лица ожидают от исследования. Чёткое определение ожидаемых результатов — лучший способ избежать неоднозначных ситуаций после завершения работы.
Хотя этот список и не полон, он даст вам общее представление о тех вопросах, которые нужно решить до начала работы. Однако, вы должны понимать, что без качественного оформления юридических формальностей тут не обойтись. После того, как исследование формализовано, необходимо получить соответствующие разрешения. Это важно, так как большинство действий, выполняемых в ходе проверок безопасности, могут оказаться нелегальными без разрешения соответствующего должностного лица компании.
После того, как всё вышеописанное согласовано, остаётся ещё один важный шаг: проверка. Не доверяйте переданным вам материалам о границах исследования — всегда проверяйте их. Используйте несколько источников информации для того, чтобы подтвердить, что системы, которые планируется исследовать, находятся в собственности клиента, и что клиент ими управляет. Например, учитывая широкое распространение облачных служб, организация может попросту не учесть то, что она не владеет предоставленными ей службами. Вы можете обнаружить, что вам требуется получить специальное разрешение от поставщика облачных услуг перед началом работы. Кроме того, всегда проверяйте предоставленные вам блоки IP-адресов.
Не полагайтесь на предположение организации о том, что она владеет всем блоком, даже если вам сообщили о том, что для исследования подходит весь переданный вам диапазон адресов. Например, мы встречались с организациями, которые запрашивали исследование в диапазоне адресов целой сети класса C, в то время, как им принадлежала лишь некоторая часть этого диапазона. Исследуя всю сеть класса C, мы, фактически, атаковали бы соседей организации по адресному пространству. Подменю OSINT Analysis (OSINT-анализ) раздела Information Gathering (Сбор информации) меню Applications (Приложения) Kali Linux содержит множество инструментов, которые могут помочь вам при проверке материалов для проведения исследований.
11.4. Типы атак
Итак, работа началась. Какие атаки проводятся в ходе проверки защищённости информационных систем? Каждому типу уязвимости соответствует особый способ её эксплуатации. В этом разделе мы расскажем о классах уязвимостей, с которыми вам придётся сталкиваться чаще всего.
Неважно, какая именно категория уязвимостей вас интересует. Что бы это ни было, Kali упрощает поиск инструментов и эксплойтов. Меню Kali на рабочем столе разделено на категории, которые помогают в поиске подходящих средств. Кроме того, на веб-сайте Kali Tools можно найти обширные перечни инструментов, доступных в Kali, организованных по категориям и снабжённых, для удобства, тегами. Каждая страница инструмента содержит подробные сведения о нём, а также примеры его использования
▍11.4.1. Атака типа «отказ в обслуживании»
Атаки на отказ в обслуживании (Denial of Service attack, DoS) используют уязвимости для блокировки работы служб, обычно — приводя к остановке уязвимого процесса. Категория Stress Testing (Стресс-тестирование) в меню приложений Kali содержит множество инструментов, ориентированных на решение этой задачи.
Многие, когда встречаются с термином «атака на отказ в обслуживании», думают об атаках, потребляющих ресурсы, которые выполняются из множества источников, одновременно направленных на одну цель. Однако, такая атака — это уже так называемая распределённая атака типа «отказ в обслуживании» (Distributed Denial Of Service Attack — DDoS). Такие атаки редко являются частью профессионального исследования защищённости систем.
Вместо этого единичные DoS-атаки чаще всего являются результатом неудачной попытки эксплуатации уязвимости. Если автор эксплойта выпустил частично функциональный код, доказывающий возможность атаки (Proof of Concept, PoC), и он был использован кем-то на практике, это может привести к ситуации, аналогичной DoS-атаке. Даже качественно написанный эксплойт может работать только при совпадении множества специфических обстоятельств и приводить к отказу атакуемой службы в других случаях. Может показаться, что решением проблемы является использование только как следует проверенных эксплойтов, или написание собственных эксплойтов. Однако, как бы там ни было, никаких гарантий при использовании эксплойтов нет, это ставит атакующего в жёсткие рамки, приводя к неоправданным ограничениям, что ведёт к смягчению исследований. Ключ к решению проблемы — компромисс. Не пользуйтесь PoC-эксплойтами и непроверенным кодом при проведении реальных исследований и всегда следите за тем, чтобы юрист компании мог прикрыть вас от других неприятностей.
Обычно DoS-атаки не выполняют намеренно. Большинство средств автоматического обнаружения уязвимостей считают DoS-уязвимости низкорисковыми из-за того, что хотя атакующий может вывести некую службу из строя, эту службу нельзя будет использовать, например, для исполнения стороннего кода. Однако, важно помнить о том, что не все эксплойты общедоступны, и о том, что DoS-уязвимости могут маскировать более глубокие и более серьёзные угрозы.
Эксплойт, позволяющий выполнять произвольный код, пользуясь известной DoS-уязвимостью, может существовать, но не в публичном пространстве. Отсюда можно сделать следующий вывод: обращайте внимание на DoS-уязвимости и рекомендуйте клиентам их патчить даже несмотря на то, что им обычно присваивают низкий уровень риска.
▍11.4.2. Нарушение целостности информации в памяти
Нарушение целостности информации в памяти происходит, когда некая область в памяти процесса случайно модифицируется из-за ошибки при разработке программы. Ошибки, связанные с памятью, обычно ведут к непредсказуемому поведению программ, однако, во многих случаях, эти ошибки позволяют манипулировать памятью процесса. Это даёт атакующему возможность управлять потоком выполнения программы и выполнять необходимые ему действия.
Подобные атаки обычно называют атаками типа «переполнение буфера», хотя это — слишком упрощённый термин. Самые распространённые типы нарушения целостности информации в памяти сильно различаются, для их эксплуатации требуются особые подходы и технические приёмы. Вот распространённые типы атак на память:
- Переполнение буфера в стеке. Когда программа записывает в буфер, находящийся в стеке, больше данных, чем объём доступного пространства, данные в соседних участках памяти могут быть повреждены, что часто ведёт к аварийному завершению работы программы.
- Повреждение памяти в куче. Память в куче выделяется во время выполнения программы и обычно содержит данные работающих процессов. Нарушение целостности данных в куче происходит из-за действий, направленных на перезапись памяти через указатели или связанные списки.
- Целочисленное переполнение памяти. Этот вид переполнения возникает в том случае, когда приложение пытается создать числовое значение, которое нельзя поместить в выделенный для него участок памяти.
- Атака на функции форматирования строк. Когда программа принимает то, что ввёл пользователь, и форматирует ввод без проверки данных, злоумышленник может узнать необходимые ему адреса памяти, либо данные в памяти могут быть перезаписаны. Это зависит от используемых символов форматирования.
▍11.4.3. Атаки на веб-приложения
Из-за того, что современные веб-сайты — это уже давно не статические документы, а динамически генерируемые для пользователя страницы, типичный веб-сайт устроен очень сложно. Уязвимости веб-приложений коренятся в этой сложности. В ходе соответствующих атак целью является либо серверная часть приложения, ответственная за создание страниц, либо сами страницы, которые видит посетитель сайта.
Веб-атаки чрезвычайно распространены, так как многие организации достигли уровня, на котором они имеют очень мало общедоступных служб. Два наиболее распространённых вида атак такого вида — это SQL-инъекции и межсайтовый скриптинг (Cross-site Scripting — XSS).
- SQL-инъекции. Эти атаки направлены на приложения, при разработке которых допущены ошибки в подсистемах проверки и очистки пользовательского ввода. Это ведёт к возможности извлекать информацию из баз данных таких приложений или даже получать полный контроль над серверами.
- Межсайтовый скриптинг. Как и в случае с SQL-инъекциями, атаки, основанные на XSS, возможны из-за неправильного обращения с пользовательским вводом. Это позволяет атакующему манипулировать пользователем или сайтом, захватывая сессии и выполняя в браузере собственный код.
Часто веб-приложения бывают сложными, обладающими обширными возможностями, а порой и непростой для понимания логикой работы. Они представляют собой удобную мишень для злоумышленников. В разделе Web Application Analysis (Анализ веб-приложения) меню приложений Kali Linux вы можете найти полезные инструменты для проверки устойчивости веб-приложений к атакам. Кроме того, тут стоит обратить внимание на метапакет kali-linux-web.
▍11.4.4. Взлом паролей
Взлом паролей — это атаки на системы аутентификации различных служб. Такие атаки часто делят на онлайновые и оффлайновые. В соответствии с этой классификацией устроен и раздел Password Attack (Взлом паролей) меню приложений Kali. В ходе онлайновой атаки делается попытка войти в систему, перебирая множество паролей. При проведении оффлайновой атаки проводится работа с хэшированными или зашифрованными паролями, полученными атакующим. Цель этой работы — раскрыть исходные пароли. Защита от оффлайновых атак заключается в повышении сложности паролей, что увеличивает трудоёмкость их раскрытия. Однако, существуют методы, позволяющие подбирать даже очень сложные пароли, например, заключающиеся в использовании вычислений на мощных видеокартах, благодаря использованию которых удаётся значительно повысить производительность программ-взломщиков. Метапакет kali-linux-gpu содержит множество инструментов, ориентированных на быстрый подбор паролей.
Чаще всего онлайн-атаки направлены на стандартные пароли, которые по умолчанию задают поставщики ПО. Так как эти пароли широко известны, атакующий, в надежде на успех, проверит стандартные точки входа в приложения. Ещё один распространённый вид таких атак — это атака по специально подготовленному словарю. В ходе такой атаки создают список слов, учитывающий особенности целевого окружения, а затем выполняют онлайновую атаку, пытаясь, перебирая список, подобрать пароль к распространённым, стандартным или известным атакующему учётным записям.
В ходе исследования очень важно понимать потенциальные последствия атак такого рода.
Во-первых, обычно они очень заметны из-за повторяющихся попыток аутентификации. Во-вторых, такие атаки, после слишком большого числа попыток войти в некую учётную запись, часто ведут к её блокировке. И наконец, скорость выполнения таких атак обычно невысока, что ведёт к сложностям при необходимости перебора словарей паролей больших размеров.
▍11.4.5. Атаки на клиентские системы
Целью большинства атак являются серверы, но, так как серверные службы становится атаковать всё сложнее, злоумышленники выбирают более лёгкие цели, например — клиентские системы. При таком подходе атакующего интересуют различные приложения, установленные на компьютере сотрудника организации, которую он пытается взломать. Соответствующие инструменты, помогающие проводить такие атаки, можно найти в категории Social Engineering Tools (Инструменты социальной инженерии) меню приложений Kali.
Такие атаки эффективнее всего проводились в начале 2000-х, их целями были Flash, Adobe Reader и Java. В этих случаях атакующий попытается добиться того, чтобы жертва посетила специально подготовленный веб-сайт. Такой сайт будет содержать особый код, который может воспользоваться уязвимостями в клиентских приложениях, что приведёт к возможности запустить на целевой системе то, что нужно атакующему.
Атаки на клиентские системы невероятно сложно предотвращать. Тут многое зависит от обучения пользователей, от постоянного обновления приложений, и от сетевых средств контроля, позволяющих уменьшить риск.
Итоги
В этом материале мы рассказали о формализации исследований информационной безопасности систем, о том, как важно согласовывать мельчайшие детали таких исследований с заказчиками, анализировать их с юридической точки зрения, и, перед началом работы, тщательно проверять всё то, в чём, на первый взгляд, можно не сомневаться. Тут же мы привели перечень распространённых видов атак, которым системы подвергаются в ходе исследований. В следующей публикации мы поделимся с вами заключительным разделом 11-й главы и приведём контрольные вопросы к ней.
Уважаемые читатели! Оценка безопасности информационных систем — это комплекс мероприятий, ошибки при планировании или проведении которых могут грозить исследователю и компании, на которую он работает, серьёзными проблемами с законом. Что вы можете посоветовать для того, чтобы свести к минимуму риск возникновения таких проблем в российском правовом поле?
Автор: ru_vds
