За последние годы исследований появилось множество инструментов, которые позволяют нам анализировать большое количество сервисов на предмет различных типов уязвимостей. Они варьируются от недостатков уровня инфраструктуры, таких как уязвимости Heartbleed или NTP-усиления, до ошибок на уровне приложений, таких как межсайтовый скриптинг на стороне клиента (XSS). В то время как большая часть исследований в первую очередь сосредоточена на средствах обнаружения таких ошибок в масштабе, мало внимания уделяется процессу эффективного уведомления затронутых сторон.
Предыстория раскрытия уязвимостей
В то время как исследовательское сообщество стало более продуктивным в обнаружении уязвимостей в широком масштабе, уведомление затронутых сторон в основном рассматривалось как побочное примечание, например, Кроме того, дополнительные исследования были сосредоточены на уведомлении об инфицированных, а не уязвимых сайтах. Проанализировали процесс уведомления уязвимых сервисов в масштабе, одновременно измеряя точное влияние различных переменных, например, каналов связи или языков. В своей работе мы раскрыли разным сторонам более 35 000 уязвимых веб-сайтов. Наряду с доверенными третьими сторонами (например, CERT и доверенным списком рассылки) и поставщиками хостинга уязвимых сайтов мы также включили прямые контакты, которые используют затронутый домен в качестве якоря. С этой целью мы уведомили регистранта домена и отправили электронные письма на общие псевдонимы (например, info @ или security @) для домена. Для процесса поиска регистранта домена мы использовали информацию, полученную из записей WHOIS для каждого домена. Эти данные, однако, по своей сути неполны: для 18,5% всех доменов в нашем наборе данных мы не смогли найти точку контакта. Несмотря на то, что наши результаты были статистически значимыми, скорость фиксации была неудовлетворительной: к концу нашего эксперимента почти 75% уведомленных доменов все еще оставались уязвимыми.
Наш набор данных состоял из двух типов ошибок: хорошо известные уязвимости WordPress и ранее неизвестные уязвимости ClientSide XSS. В то время как установки WordPress входили в число первых 1 млн сайтов, клиентский XSS был ограничен 10 тысячами сайтов. Мы обнаружили, что одни и те же каналы уведомлений показали интересные различия между наборами данных: в то время как CERT работали лучше всего для сайтов с высоким рейтингом, они работали сравнительно плохо для средней установки WordPress. Вероятно, это связано с тем, что CERT отдают приоритет высокопоставленным веб-сайтам над 1 миллионами сайтов. Мы обнаружили, что самый крупный CERT в нашем наборе данных, отвечающий за более чем 50% всех доменов, отреагировал только после окончания нашей кампании. Точно так же другой косвенный канал, то есть поставщики, показал худшие результаты для высокоуровневых веб-сайтов. Частично это можно объяснить тем фактом, что 5 ведущих провайдеров (на долю которых приходится примерно 25% всех доменов) вообще не отреагировали на наше уведомление, тем самым остановив усилия по уведомлению. В параллельной работе мы уведомили администраторов об уязвимостях на уровне инфраструктуры. С этой целью они уведомили CERT, а также о злоупотреблениях со стороны хостинг-провайдеров по поводу общедоступных промышленных систем контроля (ICS), неправильно настроенных межсетевых экранов IPv6 для хостов с двойным стеком и серверов, уязвимых для использования в атаках с усилением. В общей сложности они уведомили примерно 6500 сущностей об обнаруженных ими уязвимостях. Чтобы найти соответствующих хостинг-провайдеров, они также использовали протокол WHOIS для IP-адресов уязвимых систем. В зависимости от типа уязвимости они обнаружили, что до 20% рассматриваемых хостов не имели никакой информации о контактах для злоупотреблений для определенного диапазона IP-адресов, что подчеркивает проблемы, с которыми мы столкнулись для владельцев доменов. Тем не менее, хостинг-провайдеры показали лучшие результаты, чем CERT. Для ICS и IPv6 они обнаружили, что их кампания по уведомлению улучшила коэффициент фиксации статистически значимым образом. Однако они обнаружили, что помимо контрольной группы только 11% уведомленных контактов исправили недостатки. Более того, для усилителей не наблюдалось значительного улучшения. Помимо этих результатов, они также поэкспериментировали с разной многословностью сообщений и ссылкой на дополнительную информацию. Они обнаружили, что сообщения с подробным описанием проблемы в исходном письме работали лучше всего. Авторы также попытались уведомить стороны на их родном языке. Вопреки интуиции, это привело к снижению ставки фиксации. Что касается конкретных каналов, которые они использовали, они обнаружили, что обращение к хостинг-провайдерам работает лучше всего, в то время как их собственный CERT, то есть US CERT, вообще не реагирует на их уведомления. В этих двух работах впервые рассматривается проблемное пространство уведомления в масштабе. Они приходят к такому же неудовлетворительному выводу: влияние на общую уязвимость населения очень низкое. Более того, не наблюдалось никаких долгосрочных выгод. При анализе поведения исправлений для установок WordPress мы обнаружили, что среднее время установки исправлений безопасности для сайтов, которые ранее действовали после нашего уведомления, было лишь немного меньше, чем в контрольной группе.
Технические проблемы
Выделенные контакты по вопросам безопасности. Предыдущие работы показали, что необходимо преодолеть ряд технических проблем, чтобы обеспечить успешную массовую рассылку уведомлений. Обе работы частично полагались на WHOIS для определения контактных лиц, но не могли сделать это для 20% затронутых сторон. Вдобавок ко всему, информация WHOIS для диапазонов IP-адресов обычно содержит только контакт со злоупотреблением, а не контакт по безопасности. Несмотря на то, что в зависимости от поставщика, группа по борьбе с злоупотреблениями и группа безопасности могут частично совпадать, мы обнаружили доказательства того, что наши уведомления об уязвимостях были неверно истолкованы как жалобы на злоупотребления, в результате чего поставщики угрожали своим клиентам удалением учетных записей. Следовательно, мы утверждаем, что для диапазонов IP-адресов должен быть установлен специальный контакт по вопросам безопасности, чтобы уведомления об уязвимостях могли достигать правильного контакта.
Новые каналы связи. В нашем исследовании мы напрямую уведомили владельцев доменов и общие псевдонимы электронной почты для рассматриваемого домена, т. Е. Отправили одно (владельцы) и четыре (общие) сообщения электронной почты для каждого домена соответственно. При этом мы провели масштабный анализ, то есть таким образом зарегистрировали почти 18 000 доменов. Электронные письма, которые мы получали на протяжении всей нашей кампании, показывают, что эта массовая почтовая кампания иногда вызывала проблемы с фильтрацией спама. Несмотря на то, что мы приняли необходимые меры предосторожности при настройке нашего почтового сервера, такие проблемы не всегда можно предотвратить. Таким образом, мы пришли к выводу, что отправка электронных писем для уведомления большого количества уязвимых сторон далеко не оптимальна, и необходимо исследовать новые каналы связи. Мы предполагаем, что это может быть сделано централизованными властями. Такой орган может однажды установить доверие к исследователю, позволяя ему затем использовать инфраструктуру для уведомления владельцев сайтов. Примером такой инфраструктуры является Google Search Console, которая позволяет владельцам доменов регистрировать свои домены, чтобы впоследствии получать уведомления о проблемах, обнаруженных на их сайтах, через веб-интерфейс. В этом случае, однако, доступ к исследователям ограничен, поскольку только Google может получить доступ к этому каналу связи для связи с затронутыми сторонами.
Надежность канала. В общем, одна проблема, которая может серьезно повлиять на успех информационной кампании, - это доверие к раскрываемой информации. При общении по электронной почте такое доверие может быть установлено с помощью подписанных электронных писем, для которых получатель может проверить цепочку доверия от корня до отправителя. В целом, однако, мы не можем предположить, что все почтовые клиенты правильно отображают подписи (например, веб-почтовые программы) и, более того, что получатель осведомлен о концепции подписанных электронных писем. В эксперименте, который мы провели после окончания нашего исследования, мы обнаружили, что отправка электронных писем, содержащих все подробности уязвимости, приводит к меньшему количеству исправлений по сравнению с исходным уведомлением, где электронные письма содержали ссылки на веб-сайт с поддержкой HTTPS. Поскольку браузеры позволяют пользователям легко определять, является ли соединение безопасным, информация, передаваемая на этом надежном сайте, могла быть более эффективной. Следовательно, мы утверждаем, что любая форма архитектуры, используемая для выявления уязвимостей в масштабе, должна гарантировать, что доверие к ресурсу может быть установлено независимо от программного обеспечения, используемого для доступа к нему. В общем, многие проблемы, обнаруженные в ходе уведомлений, могут быть решены с помощью централизованной архитектуры. Создание такой инфраструктуры, пользующейся доверием, само по себе может легко вызвать доверие к исследователям, раскрывающим уязвимости, и хорошо масштабируется для большого количества уведомлений, что является ключом к обеспечению более успешных уведомлений в будущем.
Человеческие проблемы
Репутация отправителя и недоверие пользователей. В частности, при получении электронного письма от ранее неизвестного отправителя пользователи могут проявлять определенное недоверие к сообщению. Количество писем, которые были получены, но отклонены из-за недоверия получателя, остается неясным, поскольку ни одна из работ не использовала, например, пиксели отслеживания. Точнее, немецкий CERT был более склонен пересылать нашу информацию просто потому, что имел дело с нами раньше. Кроме того, мы обнаружили, что некоторые хостинг-провайдеры не реагировали на наши уведомления, а обрабатывали уведомления, полученные от CERT. Следовательно, изучение влияния репутации отправителя остается жизнеспособным направлением для будущих исследований.
Неправильно понятые отчеты. Еще одна проблема - неправильная реакция из-за того, что получатель не понял природу уведомления. В своей работе мы обнаружили несколько случаев, когда провайдеры угрожали отключить учетные записи, для которых мы сообщили об уязвимостях. Более того, провайдеры также отключили домены своих клиентов просто потому, что они неправильно поняли наше сообщение об уязвимости как сообщение о злоупотреблении. Помимо очевидной проблемы принятия таких суровых мер в отношении неконтролируемых сообщений о злоупотреблениях, следует более подробно изучить основные проблемы этих недоразумений. Мы считаем, что это еще раз подчеркивает необходимость специальных контактов по вопросам безопасности, а не только контактов со злоупотреблениями.
Субъективные решения посредников. Информационные кампании, проведенные Li et al. и мы показали, что использование посредников, таких как CERT, часто снижает успех кампании. Хотя точные причины этого не известны, одно из возможных объяснений - приоритет, отдаваемый входящим отчетам. Однако проблема здесь в том, что эта приоритезация субъективно осуществляется сотрудниками CERT. Уязвимость в WordPress, хотя и может использоваться в тысячах доменов, может не рассматриваться как важная, учитывая, что у этих доменов нет профиля с высокой посещаемостью. С другой стороны, особенно учитывая XMLRPC Multicall aw, который позволяет злоумышленнику легко подобрать комбинации имени пользователя и пароля [6], может быть более критичным для сайтов с более низким рейтингом. Если исходить из предположения, что средний пользователь WordPress менее осведомлен о проблемах безопасности, у них с большей вероятностью будут простые пароли. Следовательно, злоумышленнику будет легче взломать такие сайты, например, чтобы затем разместить на них вредоносное ПО. Однако мы считаем, что с такой проблемой можно справиться только в сочетании с архитектурой, которая позволяет раскрывать информацию с меньшим вмешательством человека, так что рабочая нагрузка CERTS может быть уменьшена.
Повышение скорости фиксации - Ли и др. и мы заметили, что даже при просмотре отчетов об уязвимой службе удалось решить только около 30-40% проблем. Ли и др. обсудил ряд возможных причин этого, начиная от уведомления, которое не дошло до соответствующей стороны, чтобы устранить ошибку, до недооценки воздействия раскрытого ошибки. Наши выводы подчеркивают эти возможные причины. В качестве примера мы обнаружили, что только 10% отчетов, раскрываемых через регистрантов доменов, в конечном итоге приводят к исправленной уязвимости для клиентских XSS-ошибок. Это может быть вызвано тем фактом, что официальный регистрант является менеджером, а не техник и, следовательно, может не понять основную проблему. Поэтому мы считаем, что необходимо изучить факторы, которые привели к таким относительно низким коэффициентам фиксации. Например, возникает вопрос, должно ли содержание отчета зависеть от предполагаемого получателя (например, группы безопасности сайта, менеджера или обычного пользователя WordPress). Кроме того, следует исследовать другие переменные, такие как длина сообщения или выбранный язык, чтобы определить, оказывают ли они значительное влияние на скорость фиксации.
Обучение администраторов. Предыдущие работы показали, что нельзя наблюдать никаких долгосрочных улучшений как эффекта уведомлений. В частности, мы могли наблюдать лишь незначительные различия в поведении исправлений сайтов, которые успешно отреагировали на наше уведомление, при сравнении их с контрольной группой. Однако в случаях, когда уведомления успешно доходили до человека, который может исправить ошибку, в предыдущих работах упускалась возможность информировать администраторов о безопасности их развернутых систем. Следовательно, возникает еще один интересный вопрос: может ли уведомление в сочетании с информацией об общих передовых методах безопасности принести долгосрочную выгоду для затронутых сторон.
В этой статье мы составили карту текущего ландшафта крупномасштабных уведомлений об уязвимостях. С этой целью мы рассмотрели уроки, извлеченные из двух основных работ в этой области, которые позволили впервые заглянуть в проблемное пространство. Основываясь на наших наблюдениях над проблемами, с которыми столкнулись эти работы, мы задали ряд дополнительных вопросов с точки зрения как технических, так и человеческих аспектов таких уведомлений. Мы утверждаем, что необходимо провести много исследований, чтобы понять, как можно решить обозначенные проблемы, и что только в этом случае уведомления могут иметь положительное, долгосрочное воздействие на экосистему уязвимости.
Предыстория раскрытия уязвимостей
Наш набор данных состоял из двух типов ошибок: хорошо известные уязвимости WordPress и ранее неизвестные уязвимости ClientSide XSS. В то время как установки WordPress входили в число первых 1 млн сайтов, клиентский XSS был ограничен 10 тысячами сайтов. Мы обнаружили, что одни и те же каналы уведомлений показали интересные различия между наборами данных: в то время как CERT работали лучше всего для сайтов с высоким рейтингом, они работали сравнительно плохо для средней установки WordPress. Вероятно, это связано с тем, что CERT отдают приоритет высокопоставленным веб-сайтам над 1 миллионами сайтов. Мы обнаружили, что самый крупный CERT в нашем наборе данных, отвечающий за более чем 50% всех доменов, отреагировал только после окончания нашей кампании. Точно так же другой косвенный канал, то есть поставщики, показал худшие результаты для высокоуровневых веб-сайтов. Частично это можно объяснить тем фактом, что 5 ведущих провайдеров (на долю которых приходится примерно 25% всех доменов) вообще не отреагировали на наше уведомление, тем самым остановив усилия по уведомлению. В параллельной работе мы уведомили администраторов об уязвимостях на уровне инфраструктуры. С этой целью они уведомили CERT, а также о злоупотреблениях со стороны хостинг-провайдеров по поводу общедоступных промышленных систем контроля (ICS), неправильно настроенных межсетевых экранов IPv6 для хостов с двойным стеком и серверов, уязвимых для использования в атаках с усилением. В общей сложности они уведомили примерно 6500 сущностей об обнаруженных ими уязвимостях. Чтобы найти соответствующих хостинг-провайдеров, они также использовали протокол WHOIS для IP-адресов уязвимых систем. В зависимости от типа уязвимости они обнаружили, что до 20% рассматриваемых хостов не имели никакой информации о контактах для злоупотреблений для определенного диапазона IP-адресов, что подчеркивает проблемы, с которыми мы столкнулись для владельцев доменов. Тем не менее, хостинг-провайдеры показали лучшие результаты, чем CERT. Для ICS и IPv6 они обнаружили, что их кампания по уведомлению улучшила коэффициент фиксации статистически значимым образом. Однако они обнаружили, что помимо контрольной группы только 11% уведомленных контактов исправили недостатки. Более того, для усилителей не наблюдалось значительного улучшения. Помимо этих результатов, они также поэкспериментировали с разной многословностью сообщений и ссылкой на дополнительную информацию. Они обнаружили, что сообщения с подробным описанием проблемы в исходном письме работали лучше всего. Авторы также попытались уведомить стороны на их родном языке. Вопреки интуиции, это привело к снижению ставки фиксации. Что касается конкретных каналов, которые они использовали, они обнаружили, что обращение к хостинг-провайдерам работает лучше всего, в то время как их собственный CERT, то есть US CERT, вообще не реагирует на их уведомления. В этих двух работах впервые рассматривается проблемное пространство уведомления в масштабе. Они приходят к такому же неудовлетворительному выводу: влияние на общую уязвимость населения очень низкое. Более того, не наблюдалось никаких долгосрочных выгод. При анализе поведения исправлений для установок WordPress мы обнаружили, что среднее время установки исправлений безопасности для сайтов, которые ранее действовали после нашего уведомления, было лишь немного меньше, чем в контрольной группе.
Технические проблемы
Новые каналы связи. В нашем исследовании мы напрямую уведомили владельцев доменов и общие псевдонимы электронной почты для рассматриваемого домена, т. Е. Отправили одно (владельцы) и четыре (общие) сообщения электронной почты для каждого домена соответственно. При этом мы провели масштабный анализ, то есть таким образом зарегистрировали почти 18 000 доменов. Электронные письма, которые мы получали на протяжении всей нашей кампании, показывают, что эта массовая почтовая кампания иногда вызывала проблемы с фильтрацией спама. Несмотря на то, что мы приняли необходимые меры предосторожности при настройке нашего почтового сервера, такие проблемы не всегда можно предотвратить. Таким образом, мы пришли к выводу, что отправка электронных писем для уведомления большого количества уязвимых сторон далеко не оптимальна, и необходимо исследовать новые каналы связи. Мы предполагаем, что это может быть сделано централизованными властями. Такой орган может однажды установить доверие к исследователю, позволяя ему затем использовать инфраструктуру для уведомления владельцев сайтов. Примером такой инфраструктуры является Google Search Console, которая позволяет владельцам доменов регистрировать свои домены, чтобы впоследствии получать уведомления о проблемах, обнаруженных на их сайтах, через веб-интерфейс. В этом случае, однако, доступ к исследователям ограничен, поскольку только Google может получить доступ к этому каналу связи для связи с затронутыми сторонами.
Надежность канала. В общем, одна проблема, которая может серьезно повлиять на успех информационной кампании, - это доверие к раскрываемой информации. При общении по электронной почте такое доверие может быть установлено с помощью подписанных электронных писем, для которых получатель может проверить цепочку доверия от корня до отправителя. В целом, однако, мы не можем предположить, что все почтовые клиенты правильно отображают подписи (например, веб-почтовые программы) и, более того, что получатель осведомлен о концепции подписанных электронных писем. В эксперименте, который мы провели после окончания нашего исследования, мы обнаружили, что отправка электронных писем, содержащих все подробности уязвимости, приводит к меньшему количеству исправлений по сравнению с исходным уведомлением, где электронные письма содержали ссылки на веб-сайт с поддержкой HTTPS. Поскольку браузеры позволяют пользователям легко определять, является ли соединение безопасным, информация, передаваемая на этом надежном сайте, могла быть более эффективной. Следовательно, мы утверждаем, что любая форма архитектуры, используемая для выявления уязвимостей в масштабе, должна гарантировать, что доверие к ресурсу может быть установлено независимо от программного обеспечения, используемого для доступа к нему. В общем, многие проблемы, обнаруженные в ходе уведомлений, могут быть решены с помощью централизованной архитектуры. Создание такой инфраструктуры, пользующейся доверием, само по себе может легко вызвать доверие к исследователям, раскрывающим уязвимости, и хорошо масштабируется для большого количества уведомлений, что является ключом к обеспечению более успешных уведомлений в будущем.
Человеческие проблемы
Репутация отправителя и недоверие пользователей. В частности, при получении электронного письма от ранее неизвестного отправителя пользователи могут проявлять определенное недоверие к сообщению. Количество писем, которые были получены, но отклонены из-за недоверия получателя, остается неясным, поскольку ни одна из работ не использовала, например, пиксели отслеживания. Точнее, немецкий CERT был более склонен пересылать нашу информацию просто потому, что имел дело с нами раньше. Кроме того, мы обнаружили, что некоторые хостинг-провайдеры не реагировали на наши уведомления, а обрабатывали уведомления, полученные от CERT. Следовательно, изучение влияния репутации отправителя остается жизнеспособным направлением для будущих исследований.
Неправильно понятые отчеты. Еще одна проблема - неправильная реакция из-за того, что получатель не понял природу уведомления. В своей работе мы обнаружили несколько случаев, когда провайдеры угрожали отключить учетные записи, для которых мы сообщили об уязвимостях. Более того, провайдеры также отключили домены своих клиентов просто потому, что они неправильно поняли наше сообщение об уязвимости как сообщение о злоупотреблении. Помимо очевидной проблемы принятия таких суровых мер в отношении неконтролируемых сообщений о злоупотреблениях, следует более подробно изучить основные проблемы этих недоразумений. Мы считаем, что это еще раз подчеркивает необходимость специальных контактов по вопросам безопасности, а не только контактов со злоупотреблениями.
Субъективные решения посредников. Информационные кампании, проведенные Li et al. и мы показали, что использование посредников, таких как CERT, часто снижает успех кампании. Хотя точные причины этого не известны, одно из возможных объяснений - приоритет, отдаваемый входящим отчетам. Однако проблема здесь в том, что эта приоритезация субъективно осуществляется сотрудниками CERT. Уязвимость в WordPress, хотя и может использоваться в тысячах доменов, может не рассматриваться как важная, учитывая, что у этих доменов нет профиля с высокой посещаемостью. С другой стороны, особенно учитывая XMLRPC Multicall aw, который позволяет злоумышленнику легко подобрать комбинации имени пользователя и пароля [6], может быть более критичным для сайтов с более низким рейтингом. Если исходить из предположения, что средний пользователь WordPress менее осведомлен о проблемах безопасности, у них с большей вероятностью будут простые пароли. Следовательно, злоумышленнику будет легче взломать такие сайты, например, чтобы затем разместить на них вредоносное ПО. Однако мы считаем, что с такой проблемой можно справиться только в сочетании с архитектурой, которая позволяет раскрывать информацию с меньшим вмешательством человека, так что рабочая нагрузка CERTS может быть уменьшена.
Повышение скорости фиксации - Ли и др. и мы заметили, что даже при просмотре отчетов об уязвимой службе удалось решить только около 30-40% проблем. Ли и др. обсудил ряд возможных причин этого, начиная от уведомления, которое не дошло до соответствующей стороны, чтобы устранить ошибку, до недооценки воздействия раскрытого ошибки. Наши выводы подчеркивают эти возможные причины. В качестве примера мы обнаружили, что только 10% отчетов, раскрываемых через регистрантов доменов, в конечном итоге приводят к исправленной уязвимости для клиентских XSS-ошибок. Это может быть вызвано тем фактом, что официальный регистрант является менеджером, а не техник и, следовательно, может не понять основную проблему. Поэтому мы считаем, что необходимо изучить факторы, которые привели к таким относительно низким коэффициентам фиксации. Например, возникает вопрос, должно ли содержание отчета зависеть от предполагаемого получателя (например, группы безопасности сайта, менеджера или обычного пользователя WordPress). Кроме того, следует исследовать другие переменные, такие как длина сообщения или выбранный язык, чтобы определить, оказывают ли они значительное влияние на скорость фиксации.
Обучение администраторов. Предыдущие работы показали, что нельзя наблюдать никаких долгосрочных улучшений как эффекта уведомлений. В частности, мы могли наблюдать лишь незначительные различия в поведении исправлений сайтов, которые успешно отреагировали на наше уведомление, при сравнении их с контрольной группой. Однако в случаях, когда уведомления успешно доходили до человека, который может исправить ошибку, в предыдущих работах упускалась возможность информировать администраторов о безопасности их развернутых систем. Следовательно, возникает еще один интересный вопрос: может ли уведомление в сочетании с информацией об общих передовых методах безопасности принести долгосрочную выгоду для затронутых сторон.
В этой статье мы составили карту текущего ландшафта крупномасштабных уведомлений об уязвимостях. С этой целью мы рассмотрели уроки, извлеченные из двух основных работ в этой области, которые позволили впервые заглянуть в проблемное пространство. Основываясь на наших наблюдениях над проблемами, с которыми столкнулись эти работы, мы задали ряд дополнительных вопросов с точки зрения как технических, так и человеческих аспектов таких уведомлений. Мы утверждаем, что необходимо провести много исследований, чтобы понять, как можно решить обозначенные проблемы, и что только в этом случае уведомления могут иметь положительное, долгосрочное воздействие на экосистему уязвимости.
