Второй польский поставщик медицинского программного обеспечения пострадал в течение нескольких недель. Злоумышленники использовали уязвимость SQL-инъекции, чтобы украсть данные пациентов из Medyc — платформы, которую QBUSoft продаёт медицинским кабинетам и клиникам. Утечка данных Medyc в Польше с раскрытием номеров PESEL следует за гораздо более крупным инцидентом в августе, и вместе они показывают, насколько велик риск, связанный с поставщиками, стоящими за программным обеспечением для клиник, а не с пациентами, чьи записи они хранят.

Приведённые ниже подробности взяты из репортажа Help Net Security. Некоторые части оригинального резюме были усечены, поэтому данный пост придерживается только подтверждённой информации.

Что было украдено из Medyc

Medyc — это платформа, которую медицинские кабинеты и клиники используют для управления регистрацией пациентов, записями и рецептами. Согласно отчёту, хакеры украли данные пациентов у поставщика, эксплуатируя уязвимость SQL-инъекции.

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

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

Как утечка MyDr подготовила почву

Инцидент с Medyc не произошёл в изоляции. В августе злоумышленники украли данные почти 19 миллионов человек из MyDr — варшавской компании, программное обеспечение которой используется примерно 12 000 медицинских учреждений. Утёкшая база данных там также содержала номера PESEL.

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

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

Почему SQL-инъекции продолжают поражать поставщиков медицинских услуг

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

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

Тот же класс уязвимостей встречается и далеко за пределами медицины. Наш материал о злоумышленниках, эксплуатирующих неисправленную zero-day SQL-инъекцию в GeoServer показывает, как один тип уязвимости может использоваться против совершенно разных платформ. Урок неизменен: когда интернет-приложение взаимодействует с базой данных, небезопасные запросы представляют серьёзный риск.

Что это значит для вас

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

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

Что вы можете сделать, так это уменьшить ущерб, если ваши данные будут использованы неправомерно:

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

Ключевые выводы

Утечка данных Medyc в Польше с раскрытием номеров PESEL, последовавшая за утечкой MyDr, затронувшей почти 19 миллионов человек, показывает, что концентрированные поставщики медицинского программного обеспечения являются едиными точками отказа. Личные инструменты, такие как VPN, стоит использовать для приватного просмотра, но они не могут исправить уязвимость внутри базы данных поставщика. Ответственность за это лежит на поставщиках, которым необходимо устранить базовые проблемы, такие как SQL-инъекции, и на регулирующих органах, которые их контролируют.

Для читателей практический шаг — бдительность в отношении выдачи себя за других лиц и фишинга, использующего утёкшие идентификаторы. Чтобы увидеть, как тот же тип уязвимости эксплуатируется в других местах, прочитайте наш отчёт о zero-day SQL-инъекции в GeoServer.