09.04.2021 12:06
ramses2 91 32600 Источник

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

Хотите узнать, какие именно уязвимости я нашёл? Но я не смогу вам об этом рассказать, даже если захочу. Без согласия вендора публично говорить о найденных уязвимостях мне не позволяет закон.

Примечание:

Эта статья является только моим личным мнением. Её цель — попытаться разобраться в теме и расставить все точки над «ё» публично.

Я не юрист, но консультировался с юристами во время написания статьи. Если среди вас есть профессионалы в этой области, буду рад услышать дополнения.

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

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

Нужно ли пользователям отказываться от «дырявого» сервиса? Этот выбор каждый делает для себя сам. Но как узнать об уязвимостях и понять, насколько они опасны? Рассказать об этом могут независимые исследователи — специалисты по информационной безопасности (они же пентестеры, whitehat и т.п.). Но они не всегда могут предать публичной огласке то, что знают, не попав при этом под юридические риски.

Давайте рассмотрим конкретную ситуацию:

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

Вы дополнительно извлекли и провели reverse-инжиниринг прошивки, нашли критичные уязвимости:

1. наличие включенного telnet-сервера и пароля по умолчанию для "root"-пользователя;

2. отсутствие авторизации на устройстве для сервиса получения видеопотока и управления;

3. отсутствие шифрования видеопотока и мультимедийных данных между устройством и мобильным клиентом;

4. отсутствие защиты от спуфинга DNS и NTP;

5. хранение пароля Wi-Fi в открытом виде;

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

Предположим, что модель вашего устройства — самая популярная на рынке, и у неё тысячи пользователей. Вы быстро пишете вендору письмо, чтобы тот всё поправил. А ему все равно. Устройство по-прежнему продаётся, а уязвимости не исправлены. Ничего не меняется даже спустя 6 месяцев. А кто знает, сколько еще людей в курсе данных уязвимостей? И кто знает, сколько из них злоупотребили своими знаниями?

Вам остается только сделать публичное оглашение, но, увы, в России этого делать не стоит.

Потенциальные юридические риски

Изначально законодательство вообще не на стороне независимых исследователей уязвимости сервисов. По-хорошему, ничего нельзя даже трогать. А если кто-то решит опубликовать своё исследование уязвимостей, правообладатель сервиса может предъявить ему гражданские иски, могут быть инициированы проверки наличия состава преступления, возбуждены дела об административном правонарушении и, возможно, даже придётся понести уголовное наказание. Звучит невесело?

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

1. Гражданское право

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

Подробнее:

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

Согласно п.п. 1, 2 ст. 1280 ГК РФ лицо, правомерно владеющее экземпляром программы для ЭВМ, вправе без согласия правообладателя и без выплаты дополнительного вознаграждения изучать, исследовать или испытывать функционирование такой программы в целях определения идей и принципов, лежащих в основе любого элемента программы для ЭВМ путем осуществления:

  • действий, необходимых для функционирования программы для ЭВМ или базы данных;

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

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

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

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

  • указанные действия осуществляются в отношении только тех частей декомпилируемой программы для ЭВМ, которые необходимы для достижения способности к взаимодействию (п. 3 ст. 1280 ГК РФ).

Важно понимать, что упомянутое исследование, преобразование, воспроизведение ПО не должно противоречить обычному использованию программы для ЭВМ или базы данных и не должно ущемлять необоснованным образом законные интересы автора или иного правообладателя (п. 4 ст. 1280 ГК РФ).

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

Подробнее:

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

2 Уголовная ответственность:

2.1: Потенциально: ст. 272 УК РФ за неправомерный доступ к компьютерной информации в случае, если среди полученных данных есть такие, правами доступа к которым исследователь не наделен.

Подробнее:

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

Более подробно о терминах, используемых в ст. 272 УК РФ (как чаще они понимаются в судебной практике и правовой доктрине):

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

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

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

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

2.2. Потенциально: ст. 273 УК РФ за использование скриптов\экплойтов для автоматизации атаки.

Подробнее:

Использование специальных скриптов для воздействия на компьютерные сети может расцениваться как использование компьютерных программ либо иной компьютерной информации, заведомо предназначенных для несанкционированного уничтожения, блокирования, модификации, копирования компьютерной информации или нейтрализации средств защиты компьютерной информации (состав преступления ст. 273 УК РФ).

Подробнее:

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

3. Административная ответственность

Существует риск признания рассматриваемых действий:

3.1 незаконной деятельностью в области защиты информации без получения соответствующей лицензии — ст. 13.13 КоАП РФ;

3.2 в случае совершения действий от имени компании — нарушением лицензионных требований, предъявляемых к лицензиату при осуществлении лицензируемого вида деятельности (ст. 13.12 КоАП).

Подробнее:

Примечание:

Например, согласно п. 6. Положения о лицензировании деятельности по технической защите конфиденциальной информации (утв. постановлением Правительства РФ от 3 февраля 2012 г. № 79), требованиями, предъявляемыми к лицензиату при осуществлении лицензируемого вида деятельности, являются выполнение работ и (или) оказание услуг лицензиатом. То есть для осуществления законной деятельности подразумевается наличие договорных отношений с заказчиком.

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

Законные возможности и их ограничения

Как же специалисты по информационной безопасности и сами пользователи могут законно искать уязвимости в публичном ПО и сервисах? Есть следующие возможности:

  • заключить договор на анализ ПО, организации, сервиса;

  • принять участие в одной из программ Bug Bounty (программы, по которым любой может получить признание и вознаграждение за нахождение ошибок и уязвимостей);

  • получить прямое разрешение в лицензионном соглашении на тестирование;

  • искать уязвимости в программах и сервисах Open Source;

Пройдемся по каждому из пунктов и рассмотрим его ограничения.

Заключение договора на анализ

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

Программы Bug Bounty

Некоторые веб-сайты и разработчики программного обеспечения предлагают программы Bug Bounty.

Минусы таких программ:

  • В Bug Bounty обычно чётко прописано то, что вы можете анализировать и с какими ограничениями. В списке программы может не оказаться того, что вы хотели бы исследовать и того, каким образом вы планировали это делать.

  • Если вы найдёте уязвимость, программа Bug Bounty может обязать вендора выплатить вам вознаграждение. А вот устранять эту уязвимость вендор не обязан. Известно множество случаев, когда даже в таких программах баги висят годами, а новые исследователи получают только статус «Дубликат» за них.

 На текущий момент в РФ меньше 20 компаний участвуют в Bug Bounty, а возможно, даже меньше десяти.

Прямое разрешение в лицензионном соглашении на возможность тестирования

На текущий момент на глаза ни разу что-то подобное не попадалось.

Анализ Open Source программ

С этим пунктом нет никаких проблем, кроме того, что:

  • далеко не весь софт попадает в эту категорию;

  • также не всегда очевидно, кто будет исправлять уязвимость, которую вы нашли, так как ответственного за ИБ как такового может не быть.

В сумме

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

По моим субъективным ощущениям:

Мечты об идеальном процессе

Оптимально выстроить механизмы отправки отчета об уязвимости безопасности можно следующим образом:

  1. В случае обнаружения недостатка в безопасности ПО\сервиса\устройства с аудиторией более X человек должен быть ясный механизм отправки отчета об уязвимости вендору, лучше — унифицированный для всех вендоров сразу.

  2. Вендор должен оценить риски и в течение Y недель сказать, собирается он это устранять или нет.

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

  4. По истечении Z дней исследователь имеет право опубликовать полные технические детали.

Данные формулировки и значения X, Y, Z должны быть закреплены юридически и распространяться на всех.

Опытный читатель может заявить, что часть этих шагов уже реализована:

Шаги 1-2 — решаются с помощью:

  • Bug Bounty — однако, как говорил ранее, далеко не у всех он есть, и далеко не всё попадает в разрешенные границы;

  • баз (CVE, БДУ, OSV и т.п.) — однако это далеко не самый очевидный и быстрый процесс, некоторые оформляют уязвимости по 2 года;

  • писем на электронную почту компании — однако в большинстве случаев письмо даже не дойдет до технического специалиста, потому что нет ясного процесса в компании для таких случаев. Есть проекты наподобие security.txt, но, к сожалению, о них мало кто знает.

Шаг 3 — решается с помощью:

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

  • новостей об уязвимостях в ПО — однако скорее это касается крупного ПО, а обычные пользователи могут и не прочитать такие новости;

  • баз (CVE, БДУ, OSV и т.п.) — однако маловероятно, что обычные пользователи их отслеживают.

Пример вывода об уязвимости в ПО (с человеческим пояснением проблемы, но без раскрытия технических деталей).

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

Итого, на текущий момент имеются две крупных проблемы:

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

  • Пользователь не в курсе, что пользуется небезопасным софтом.

Выводы

Сейчас специалисты ИТ и ИБ в основном действуют реактивно: заметают последствия инцидента после того, как он произошёл. Многие уязвимости давно известны, но не исправлены. И только после серьезной публичной огласки шестеренки механизма начинают крутиться. Но что пользователям с того, что сервис принес извинения или даже заплатил регулятору штраф после утечки клиентских данных, если их приватная информация стала известна всему интернету и останется в нем навсегда?

Часто никто не стремится проанализировать ситуацию глубже, понять, почему инцидент произошел. Дали студенту настроить prod-сервер? Сэкономили на разработчиках? Не стали строить процессы ИБ? А может, кто-то из whitehat уже находил эту уязвимость и ранее сообщал о ней, а сервис проигнорировал? Что делать пользователям, если разработчику «плевать» на ИБ настолько, что легче заплатить денег за закрытие симптома раз в год, чем делать финансовые вливания в устранение причин?

Мне бы хотелось, чтобы ситуация изменилась. Чтобы интересы общества и безопасность людей начали цениться больше, чем интересы владельца сервиса, чтобы я понимал, когда пользуюсь уязвимым сервисом и принимаю риски, что у меня был выбор. Хотелось бы, чтобы человек, нашедший недостаток ИБ, мог о нем смело рассказать и не бояться юридических рисков.

Статья написана в соавторстве с Александром Малофеевым, юристом компании «Инфосистемы Джет».