Разработчик и инструктор по дайвингу, который предпочёл скрыть своё имя, пожаловался, что он обнаружил уязвимость в личном кабинете крупной страховой компании, но вместо признания получил угрозы от её юристов. Приводим перевод этой истории.
Я инструктор по дайвингу. Также я инженер, много времени уделяющий разработке и внедрению решений в области безопасности инфраструктуры. Иногда эти два мира пересекаются неожиданным образом. Во время 14-дневной дайвинг-поездки вокруг острова Кокос в Коста-Рике я обнаружил уязвимость в личном кабинете крупной страховой компании, занимающейся страхованием дайвинга, — компании, через которую я лично застрахован. Обнаруженная уязвимость была настолько тривиальной и настолько базовой, что я искренне не мог поверить, что она ещё не использовалась злоумышленниками.
Я сообщил об этой уязвимости 28 апреля 2025 года со стандартным 30-дневным периодом эмбарго. Этот период истёк 28 мая 2025 года — более восьми месяцев назад. Я ждал так долго, чтобы опубликовать информацию, потому что хотел дать организации все разумные возможности для полного устранения проблемы и уведомления пострадавших пользователей. Уязвимость с тех пор была устранена, но я не получил подтверждения о том, что о ней уведомили затронутых юзеров. Я обратился в организацию за разъяснениями по этому вопросу.
Это история о том, что произошло, когда я попытался поступить правильно.
Уязвимость
Чтобы понять, почему всё так плохо, нужно знать, как работает процесс регистрации. Как инструктор по дайвингу, я регистрирую учеников (для страхования) через свой аккаунт на портале. Я ввожу личные данные с их согласия — имя, дату рождения, адрес, номер телефона, электронную почту — и система создаёт для них учётную запись. Затем ученики получают электронные письма с новыми учётными данными: числовым идентификатором и паролем по умолчанию. Они могут войти в систему, чтобы заполнить дополнительную информацию, либо же больше никогда не заходить на портал.
Когда я зарегистрировал трёх учеников, они сидели рядом со мной и проверяли свои приветственные письма. Идентификаторы пользователей были почти идентичны — последовательные числа, одно за другим. Именно тогда я понял, что происходит что-то действительно плохое.
А вот в чём проблема: портал использовал возрастающие числовые идентификаторы пользователей для входа в систему: пользователь XXXXXX0, XXXXXX1, XXXXXX2 и так далее. Уже одно это вызывает подозрения, но ситуация усугубляется: каждая учётная запись была создана с использованием статического пароля по умолчанию, который никогда не менялся при первом входе. И многие пользователи — особенно студенты, чьи учётные записи были созданы преподавателями — никогда его не меняли.
Таким образом, «аутентификация» для доступа к полному профилю пользователя — имени, адресу, номеру телефона, электронной почте, дате рождения — выглядела так:
угадайте число:
введите тот же пароль по умолчанию, который используется для всех учётных записей при их создании;
есть большая вероятность, что вы войдёте в аккаунт.
Вот и всё. Никаких ограничений скорости. Никакой блокировки учётной записи. Никакой многофакторной аутентификации. Просто увеличивающееся целое число и пароль, который вполне мог бы выглядеть как password123.
Я проверил проблему с минимальным доступом, необходимым для подтверждения масштаба проблемы — и сразу же остановился. Значительная часть идентификаторов в выборке по-прежнему использовала пароль по умолчанию. Раскрытые данные включали не только адреса электронной почты, но и полные личные профили, в том числе и профили несовершеннолетних студентов.
Проверка концепции
Дисклеймер: эту главу автор удалил из оригинального поста, но она есть в Internet Archive.
Чтобы подтвердить, что проблема не ограничивается несколькими учётными записями, я написал короткий скрипт, автоматизирующий действия, которые можно выполнить вручную в любом браузере. Сначала я попробовал использовать Python requests, но механизм входа в портал был настолько сложным, что создание чистой сессии было невозможно. Поэтому я использовал Selenium — инструмент автоматизации, который просто запускает в реальном браузере те же шаги, которые любой пользователь выполнил бы вручную.
Ниже приведен упрощённый и нефункциональный фрагмент скрипта. Идентификаторы, конечные точки и детали реализации были удалены или изменены — в текущем виде он не будет работать и включён только для иллюстрации тривиальности проблемы:
Никаких эксплойтов, переполнения буфера, уязвимостей нулевого дня. Просто форма входа, номер и пароль по умолчанию, который был установлен для каждого студента при создании. Это та проблема, которую любой может обнаружить и воспроизвести за один день.
Вот как выглядел результат одного успешного входа в систему — отредактированный, но структурно идентичный реальному:
Перечитайте дату рождения. 2011 год. На тот момент этому человеку было 14 лет. Его полное имя, адрес электронной почты, номер телефона, гражданство и физический домашний адрес — всё это доступно только по порядковому номеру и стандартному паролю. И это не был единичный случай. Несколько профилей принадлежали несовершеннолетним.
Хочу внести полную ясность: все данные, полученные в ходе этой проверки, были безвозвратно удалены. Я не сохранял никакой личной информации, не пытался получить доступ к чему-либо, кроме того, что требовалось для подтверждения отчёта, и остановился, как только стал понятен масштаб бедствия.
Раскрытие информации
Я сделал всё по правилам. Сначала связался с CSIRT Malta (MaltaCIP) — поскольку эта организация зарегистрирована на Мальте, это компетентный национальный орган. Национальная политика Мальты по скоординированному раскрытию уязвимостей (NCVDP) прямо требует, чтобы о подтверждённых уязвимостях сообщалось как ответственным лицам, так и CSIRTMalta.
Затем я отправил электронное письмо непосредственно в организацию, скопировав его в CSIRT:
Уважаемые дамы и господа,
Как коллега-инструктор по дайвингу, застрахованный через [организацию], и штатный инженер по платформе Linux, я обращаюсь к вам, чтобы ответственно сообщить о критической уязвимости, которую я обнаружил в системе учётных записей пользователей [организации].
В ходе недавнего тестирования я обнаружил, что учётные записи пользователей, в том числе несовершеннолетних студентов, доступны посредством комбинации предсказуемого перечисления идентификаторов (увеличение идентификаторов пользователей) и использования статического пароля по умолчанию, который не требует изменения при первом входе в систему. Эта неправильная конфигурация в настоящее время раскрывает конфиденциальные персональные данные (например, имена, адреса, контактную информацию, включая номера телефонов и электронные адреса, даты рождения) и представляет собой многочисленные нарушения GDPR.
Основные сведения:
повторное использование паролей в разных учётных записях без принудительной перезагрузки паролей;
предсказуемое, поэтапное перечисление идентификаторов пользователей;
раскрытие конфиденциальных данных пользователей, в том числе несовершеннолетних, без надлежащих мер защиты.
Для первоначального подтверждения прилагаю скриншот с идентификатором пользователя XXXXXXX, демонстрирующий раскрытые данные, частично отредактированный по соображениям конфиденциальности.
Кроме того, для обеспечения прозрачности и проверки я безопасно поделился своим экспериментальным кодом через зашифрованный сервис для размещения текста: [ссылка удалена].
В духе ответственного раскрытия информации я уже уведомил CSIRT Malta (в копии) о необходимости официального начала процесса сообщения о нарушениях, учитывая оперативное присутствие [организации] на Мальте.
Прошу [организацию] подтвердить получение данного уведомления в течение 7 дней.
Я предоставляю [организации] 30 дней, начиная с 28 апреля 2025 года, для устранения или решения проблемы уязвимости, прежде чем я рассмотрю вопрос о публичном раскрытии информации.
Пожалуйста, обратите внимание, что я готов оказать вашей IT-команде всестороннюю помощь в решении технических вопросов, проведении проверок и предоставлении рекомендаций с точки зрения безопасности.
[контактные данные]
Настоятельно рекомендую назначить контактное лицо по вопросам IT-безопасности для непосредственного сотрудничества по этому вопросу.
Большое спасибо за ваше внимание к этому важному вопросу. Я с нетерпением жду возможности сотрудничать с вами для безопасного решения проблемы.
Оба указанных срока являются стандартными — если не сказать, даже завышенными — в рамках ответственного раскрытия информации.
Ответ
Через два дня я получил ответ. Не от их IT-команды, а от юридической фирмы их сотрудников по защите данных (DPO).
Письмо начиналось достаточно вежливо — они признали проблему и сообщили, что начали расследование. Они даже упомянули, что сбрасывают пароли по умолчанию и планируют внедрить двухфакторную аутентификацию. Хорошо.
Но затем тон изменился:
Хотя мы искренне ценим ваши, казалось бы, благие намерения и прозрачность в освещении этого вопроса, мы должны с уважением отметить, что уведомление властей до обращения в Группу создает дополнительные сложности в восприятии и решении этого вопроса, а также подвергает нас несправедливой ответственности.
Позвольте мне перевести: «Мы бы хотели, чтобы вы не сообщали правительству о нашей проблеме безопасности».
Далее лучше не стало:
Мы также не одобряем вашу угрозу предать этот вопрос огласке [...] и напоминаем, что вы можете быть привлечены к ответственности за любой ущерб, который мы или субъекты данных можем понести в результате ваших действий, которые, вероятно, представляют собой уголовное преступление согласно мальтийскому законодательству.
Итак, чтобы было ясно: на их портале был установлен пароль по умолчанию для каждой учётной записи, что раскрывало личные данные, включая данные детей, и именно я, «вероятно», совершил уголовное преступление, обнаружив это и сообщив им.
Они также прислали декларацию с требованием моей подписи — заодно запросив мой паспорт, — подтверждающую, что я удалил все данные, ничего не буду разглашать и буду хранить всю информацию в «строго конфиденциальном порядке». Крайний срок? Конец рабочего дня в того же дня, когда они её прислали.
Эта декларация содержала следующую «жемчужину»: «Я также обещаю, что буду хранить содержание этой декларации в строгой конфиденциальности».
Это соглашение о неразглашении с дополнительными шагами: меня просили отказаться от права обсуждать сам процесс раскрытия информации — включая тот факт, что я обнаружил уязвимость в их системе — под угрозой судебного иска.
Затем последовали напоминания. Одно «дружеское» напоминание. Затем «срочное». Подпишите декларацию. Снизьте накал страстей. Идите дальше. Молчите.
Сопротивление
Я обычно отказываюсь подписывать соглашения о конфиденциальности в случаях, связанных с раскрытием конфиденциальной информации, и поступил так же и здесь. Скоординированное раскрытие информации зависит от прозрачности и доверия между исследователями и организациями: уверенности в том, что пострадавшие пользователи будут проинформированы, и веры в то, что сообщение приведёт к реальному устранению проблемы.
Учитывая, что организация, о которой идёт речь, уже нарушила это соглашение, раскрыв персональные данные из-за слабых механизмов контроля, я не был готов предоставить ей полную конфиденциальность, которая могла бы быть использована для сокрытия инцидента от общественности. Пытаясь заставить меня замолчать с помощью юридических угроз, они уже ясно дали понять, что их приоритетом является репутация. Управление безопасностью данных важнее защиты пользовательских данных. Поэтому я стоял на своём.
Вместо этого я предложил подписать изменённое заявление, подтвержда��щее удаление данных. Я не был заинтересован в сохранении чьих-либо личных данных, но и не собирался хранить молчание о самом процессе раскрытия информации.
Я также указал, что в соответствии с Национальным протоколом по защите персональных данных Мальты (NCVDP) привлечение CSIRT Malta является частью ожидаемого процесса отчётности, а не враждебным актом, и что публикация анализов после устранения нарушений является стандартной практикой в сообществе специалистов по безопасности.
Их ответ был ещё более категоричным. Они сослались на статью 337E Уголовного кодекса Мальты — неправомерное использование компьютеров — и любезно напомнили мне, что:
Статья 337E Уголовного кодекса также предусматривает, что «если какое-либо действие совершено за пределами Мальты, которое, если бы оно было совершено на Мальте, представляло бы собой преступление [...] оно [...] считается совершённым на Мальте». Это означает, что ваши действия будут считаться уголовным преступлением на Мальте, даже если они совершены в другой стране.
Они также предельно ясно выразили свою позицию по поводу раскрытия информации после того, как я повторил свой отказ подписать их соглашение о неразглашении:
Мы категорически возражаем против использования [название организации] в любых подобных блогах или конференциях, которые вы можете писать/посещать, поскольку это нанесёт несоразмерный ущерб репутации [организации] [...]. Мы оставляем за собой право по закону привлечь вас к ответственности за любой ущерб, который [организация] может понести в результате любых подобных публичных разглашений, которые вы можете сделать.
Меня это устраивает. Потому что вот в чём дело: уязвимость исправлена. Пароли по умолчанию сброшены. Внедряется двухфакторная аутентификация. Мне жаль разработчика(ов), которому(ым) пришлось исправлять эту проблему, но, по крайней мере, она больше не является уязвимой к эксплуатации. Конечно, было бы лучше, если бы организация поблагодарила меня и взяла на себя ответственность за уведомление пострадавших пользователей. Если инцидент квалифицируется как нарушение защиты персональных данных (что так и есть) и может привести к (высокому) риску для физических лиц, особенно учитывая участие несовершеннолетних, то статьи 33 и 34 GDPR, как правило, требуют уведомления надзорного органа и информирования затронутых субъектов данных.
Статья 34(1) GDPR: Если нарушение защиты персональных данных может привести к высокому риску для прав и свобод физических лиц, контролёр должен незамедлительно уведомить субъекта данных о нарушении защиты персональных данных.
Статья 34(2) GDPR: Уведомление субъекта данных, указанное в пункте 1 настоящей статьи, должно чётко и ясно описывать характер нарушения защиты персональных данных и содержать как минимум информацию и меры, указанные в пунктах (b), (c) и (d) статьи 33(3).
Я не получил подтверждения того, что эти уведомления были когда-либо осуществлены.
Игра в обвинения
Больше всего мне понравилась позиция организации относительно того, чья это на самом деле вина:
Мы утверждаем, что ответственность за смену пароля лежит на пользователях (после того, как мы установим пароль по умолчанию).
Прочитайте это ещё раз. Компания, которая установила один и тот же пароль по умолчанию для всех учётных записей, никогда не принуждала к смене пароля и использовала возрастающие числовые идентификаторы в качестве имён пользователей, обвиняет их в том, что они не обеспечили безопасность своих собственных учётных записей. Аккаунтов, включая учётные записи несовершеннолетних.
Краткое напоминание:
Статья 5(1)(f) GDPR (целостность и конфиденциальность): Персональные данные должны обрабатываться таким образом, чтобы обеспечить надлежащую безопасность персональных данных, включая защиту от несанкционированной или незаконной обработки и от случайной потери, уничтожения или повреждения, с использованием соответствующих технических или организационных мер.
В соответствии с GDPR, контролёр данных (а именно: организация) несёт ответственность за внедрение соответствующих технических и организационных мер для обеспечения безопасности данных. Статический пароль по умолчанию на портале, уязвимом для IDOR, ни по какому определению не является «надлежащей мерой».
Статья 24(1) GDPR (ответственность контролёра): Принимая во внимание характер, объём, контекст и цели обработки, а также риски различной вероятности и степени тяжести для прав и свобод физических лиц, контролёр должен внедрить соответствующие технические и организационные меры для обеспечения и возможности продемонстрировать, что обработка осуществляется в соответствии с настоящим Регламентом. Эти меры должны пересматриваться и обновляться по мере необходимости.
Это устоявшаяся схема
Это не единичный случай. Сообщество исследователей в области безопасности сталкивается с такой схемой десятилетиями: обнаружение уязвимости, ответственное сообщение о ней, угрозы судебного преследования. Это настолько распространённое явление, что у него есть название — эффект запугивания.
Организации, которые реагируют на раскрытие информации юристами, а не инженерами, говорят миру нечто важное: они больше заботятся о своей репутации, чем о данных, которые они должны защищать.
Ирония заключается в том, что именно угрозы судебного преследования наносят ущерб репутации. Не сама уязвимость — уязвимости случаются со всеми. Именно реакция говорит обо всем, что происходит в культуре безопасности организации.
Что должно было произойти
Признание ошибки.
Получите отчет — честно говоря, они это сделали.
Исправьте уязвимость — они тоже начали над этим работать.
Поблагодарите исследователя, вместо того чтобы угрожать ему уголовным преследованием.
Разработайте политику скоординированного раскрытия уязвимостей (CVD), чтобы исследователи знали, как сообщать о проблемах и чего ожидать.
Уведомите пострадавших пользователей, особенно родителей несовершеннолетних, чьи данные были раскрыты.
Не пытайтесь заставить замолчать исследователя с помощью соглашений о неразглашении, замаскированных под «заявления».
Что вы можете сделать
Если вы организация:
Опубликуйте политику скоординированного раскрытия уязвимостей. Она не обязательно должна быть сложной — можно начать с файла security.txt и чёткого процесса, способствующего прозрачности.
Поблагодарите исследователей за помощь в улучшении вашей системы безопасности.
Не стреляйте в гонца. Человек, сообщивший об ошибке, не ваш враг. Враг — это ошибка.
Не обвиняйте своих пользователей в сбоях безопасности, за которые вы несёте ответственность как оператор данных.
Если вы исследователь в области безопасности:
Всегда привлекайте свою национальную группу реагирования на инциденты безопасности (CSIRT). Это защитит вас и создаст официальную запись.
Документируйте всё. Каждое электронное письмо, каждую отметку времени, каждый ответ.
Не подписывайте соглашения о неразглашении, которые запрещают вам обсуждать процесс раскрытия информации. Но вы можете согласиться удалить данные (и ОБЯЗАНЫ это сделать!), не соглашаясь на молчание.
Знайте свои права. Во многих юрисдикциях существуют правовые гарантии добросовестного проведения исследований в области безопасности. Директива ЕС NIS2 поощряет скоординированное раскрытие уязвимостей.
Потому что прямо сейчас, в 2026 году, сообщение о тривиальной уязвимости, раскрывающей персональные данные, включая данные детей, по-прежнему встречает юридические угрозы вместо благодарности. И это проблема для всех нас.
Этот пост вызвал неоднозначную реакцию в сообществе. Его активно обсуждают на Reddit и других профильных форумах.
