Матвей Чернов, Автор в Академия Selectel

Вы думаете, что данные защищены, потому что «все зашифровано»? Взломы из-за криптографии — это не про хакеров в черных худи с суперкомпьютерами. Чаще всего причина — простая халатность: кто-то включил TLS, но забыл отключить SSL 3.0, кто-то шифровал пароль, но на MD5 без строки salt. В этой статье — реальные кейсы, где «все было зашифровано», но ничего не спасло. Разберем, как устаревшие алгоритмы, слабые ключи и бездумное копипаст-использование библиотек привели к крупным провалам. А чтобы лучше понять, почему происходят утечки и кражи данных, сначала рассмотрим типичные ошибки в реализации криптомеханизмов. Почему проваливается криптография Вы когда-нибудь задумывались, сколько времени потребуется, чтобы вскрыть ваш пароль. Если это что-то простое как MD5, на современном GPU вроде NVIDIA RTXTM 4090 — меньше часа. А если думаете, что PBKDF2 с 1 000 итераций — это защита, то знайте: злоумышленник с той же RTX 4090 будет перебирать миллионы вариантов в секунду. Может показаться, что все проблемы упираются в пользователей, придумывающих простые пароли. На деле — большинство сбоев происходит из-за недостатка прозрачных процессов и слабой культуры код-ревью. MD5 и SHA-1 давно должны были уйти в архив, но до сих пор всплывают в коде, сертификатах и даже новых продуктах. Почему? Потому что «все работает, а обновлять дорого». Представьте, ваш аккаунт — это дом, пароль — массивная дубовая дверь. Но закрывается она не на надежный замок, а на ржавый гвоздь. Вот этот ржавый гвоздь — это MD5. Злоумышленник не станет выламывать дверь, он просто сломает этот ненадежный замок. Лучше использовать bcrypt с правильным cost-фактором. Чтобы его взломать с помощью RTX 4090, потребуется несколько десятков лет. Или посмотрим на другую неприятную ситуацию. В компании, которая считает, что «криптография — это когда добавляешь к паролю слово salt», произошла утечка данных. В результате в дампе оказалась база паролей. Что обычно происходит далее? Сотрудник ИБ проверяет масштаб утечки и параллельно обновляет резюме. Вдруг он вспоминает о переписке, где трижды писал: «надо переходить на bcrypt», но его игнорировали ради «оптимизации бюджета», и успокаивается. Приходят коллеги с запросом: «Ну ты же специалист, реши!». Сотрудник ИБ знает, что решение — в перехешировании всей базы. Но это займет недели, да и бюджета на это все равно нет. В компании просто запускают рассылку типа «Мы обновили политику безопасности! Смените пароль, иначе аккаунт заблокируем». При этом все понимают, что 80% пользователей придумают пароли уровня Aleksandr1991 или Solomca1503. Такие ошибки — не выдумки. Они уже привели к крупным инцидентам: компании, которые экономили на реализации, потеряли тысячи учетных записей. Согласно исследованию Apiiro, с мая 2023 года на просторах GitHub найдено 100 000 поддельных репозиториев, маскирующихся под популярные проекты. Злоумышленники сначала клонируют популярный репозиторий, затем добавляют в него вредоносный код. Репозиторий публикуется на платформе и становятся проектом с именем, идентичным исходному. Есть даже термин — обфускация — изменение кода программы, в результате которого он приобретает вид, трудный для понимания. Программа сохраняет функции и вредоносный код. Источник. GitHub пытается отслеживать и блокировать подозрительные репозитории, однако особенность в том, что он допускает наличие нескольких репозиториев с одинаковым именем. Открытые S3-бакеты, незащищенные MongoDB и MySQL без TLS — актуалочка. В 2024 году утечки произошли из-за того, что данные хранились в открытом виде. Компрометация одного сервера превращалась в распродажу конфиденциальной информации, потому что никто не потрудился включить шифрование на уровне диска или базы. Это не только ошибка настройки, но и отсутствие культуры безопасности. Шифрование at-rest — не опциональная функция. Если ваши данные лежат «как есть», вы не просто рискуете — а приглашаете атакующего. Куда ни посмотри, каждое устройство умное. Но массовость IoT-гаджетов приводит к проблемам. Часто существует всего один статический ключ на тысячи устройств, поэтому если хакер взломал один гаджет, он получил доступ ко всей партии. Проблема в том, что ключи внедряются на этапе сборки, а обновления не предусмотрены. Даже если вы обнаружите уязвимость, исправить ее можно только физически. Если у вас достаточно навыков, чтобы защитить устройства в своем умном доме, у вас чуть меньше поводов для беспокойство. Но массовые потребители, скорее, окажутся в одной из ситуаций, описанных в этой статье. Устаревшие протоколы вроде SSLv3 и RC4 считаются мусором, но до сих пор встречаются в корпоративных системах. Атаки типа downgrade и MitM актуальны, потому что настройка TLS требует понимания, а не копирования с GitHub. Источник. Организации по всему миру усиливают криптографическую защиту и готовятся к новым вызовам — от облачных рисков до постквантовой угрозы. Почти половина компаний (48 %) планировали рост бюджетов на шифрование в 2023–2024 году, а 70 % намерены использовать генеративный ИИ в стратегии кибербезопасности. При этом 53 % хранят свыше 60 % чувствительных данных в облаке под защитой шифрования, и почти столько же — 53 % — заявляют о поддержке перехода на постквантовые алгоритмы. Ключевыми факторами устойчивости остаются HSM: 69 % организаций задействуют отдельные команды для управления ключами. Однако основным тормозом для широкого внедрения шифрования остается data discovery — 62 % называют невозможность точно локализовать и классифицировать данные главным барьером. Реальные кейсы провалов LastPass 2022: слабая защита резервных копий Думаете, что если сервис хранит пароли в зашифрованном виде, а мастер-пароль не видел даже заметок — значит, вы в безопасности? А вот и нет. Кейс LastPass 2022 года показал, как даже при архитектуре Zero Knowledge недостаточно строгие криптографические параметры могут поставить под угрозу миллионы пользователей. И сделал он это не через эксплойт или бэкдор, а через банальную экономию на криптографии. Злоумышленники получили доступ к облачному бэкапу хранилищ, где лежали зашифрованные пароли, логины и заметки, а также незашифрованные метаданные — URL сайтов, названия компаний, адреса электронной почты и IP-адреса клиентов. По идее, даже если ты получишь такой файл — расшифровать его без мастер-пароля невозможно. Хотя по умолчанию LastPass использовал более 100 тысяч итераций, часть аккаунтов хранилась с параметрами PBKDF2-SHA256. Количество итераций там было сброшено до 5 000, 1 000 и даже 1. Да-да, я все правильно написал — 1. Время для взлома PBKDF2 с помощью случайно сгенерированных паролей SHA-256 с 5000 итераций с использованием RTX 4090 с 12 графическими процессорами. Источник. Это означало, что если пользователь выбрал слабый мастер-пароль, его хранилище можно было взломать за разумное время с помощью атак брутфорсом на современных GPU. Хотя сами пароли и логины были защищены AES-256 и не хранились на стороне LastPass, злоумышленники получили возможность перебирать мастер-пароли офлайн, не ограничиваясь попытками входа через интерфейс сервиса. В результате недостаточная настройка KDF и слабые мастер-пароли дали дорогу компрометации части хранилищ. Кроме того, открытые метаданные (например, URL сайтов) позволили проводить целевые фишинговые атаки и использовать полученную информацию для социальной инженерии («здравствуйте, я сотрудник банка»). Этот кейс стал уроком для всей отрасли: сегодня недостаточно полагаться лишь на PBKDF2 с «минимальными» 100 000 итераций. Большинство стандартов рекомендуют не менее 200-300 тысяч, а специалисты призывают переходить на более современные KDF, например Argon2.LinkedIn 2021: даркнет и сливы данных Вы получаете уведомление, что данные из вашего профиля LinkedIn выставлены на продажу. Не пароли, не хэши — просто личные данные. Имя, почта, номер телефона, геолокация, зарплата. На первый взгляд — ладно, все и так давно слито в сеть. Но через час после этого звонит человек, который называет ваше имя, место работы, даже упоминает, что вы «недавно интересовались вакансиями в IT». А потом просит подтвердить учетную запись в банке. Или передать логин от корпоративного аккаунта. Потому что «в LinkedIn так положено». Так случилось с 92% пользователей LinkedIn: 700 миллионов профилей были выставлены на продажу в даркнете. LinkedIn официально заявлял, что это было не утечка, а результат скрапинга через API. Но это не спасает, потому что злоумышленнику не нужно взламывать серверы — он просто использует то, что вы сами предоставили. Хакеры использовали автоматизированные скрипты и headless-браузеры для обращения к API Voyager и HTML-страницам. При помощи ротации сотен IP-адресов и подмены User-Agent они держали скорость запросов более 2 000 в минуту, не вызывая блокировок или необходимости проходить капчу от LinkedIn. Выложенный на RaidForums набор данных, сначала насчитывавший 500 млн записей, а затем выросший до 700 млн, содержал JSON-поля firstName, lastName, headline, location, emailAddress, phoneNumbers и публичный URL профиля. Число пользователей LinkedIn достигло 722 млн в 2021 году. Источник. LinkedIn — не первая и не последняя платформа, где персональные данные становятся целью атак. Проблема не в том, что их украли, а в том, что они существуют. Полные имена, номера телефонов, геолокация, даже предполагаемые зарплаты — все это уже давно не «информация для контакта», а инструмент. Злоумышленники не взламывают системы — они просто ищут вас в LinkedIn и других соцсетях. Собирают пазл из открытых данных, и когда у них есть достаточно кусочков, начинается атака. Фишинговые письма с точными деталями, звонки от «коллег», которые знают больше, чем должны, — это работает, потому что вы сами заполнили профиль до мелочей. Oracle Cloud: когда опровержение звучит как признание В этом году в даркнете появилось объявление от хакера с ником rose87168. Он выложил на продажу данные, якобы украденные из систем Oracle SSO и LDAP. В комплекте — файлы Java KeyStore (JKS), зашифрованные пароли, ключи JPS и прочие «деликатные» материалы. По его словам, в утечку попало около шести миллионов записей, затронувших более 140 тысяч арендаторов Oracle Cloud. Oracle официально опровергла взлом, заявив, что «все системы в порядке, а утекшие данные — не наши». Но кибербезопасники и часть клиентов Oracle подтвердили: образцы данных выглядят слишком реалистично, чтобы быть фейком. Что внутри «подарка» от хакера Злоумышленник не просто выложил данные — он просил помощи в расшифровке и предлагал «удалить ваши записи за деньги». В списке украденного: JKS-файлы с приватными ключами, которые открывают доступ к защищенным сервисам, зашифрованные пароли, которые при определенном подходе легко превратить в открытый текст, ключи JPS, позволяющие манипулировать процессами в инфраструктуре Oracle. Согласно исследованию, злоумышленник получил доступ к серверам Oracle Cloud, эксплуатируя уязвимость в Oracle Access Manager (CVE-2021-35587), которая позволяет неверифицированным пользователям с сетевым доступом через HTTP полностью скомпрометировать экземпляры Oracle Access Manager. Серверы, на которых произошла утечка, использовали устаревшую версию Oracle Fusion Middleware 11G. Ее компоненты не обновлялись с сентября 2014 года. Схема кибератаки на Оракл. Источник. Oracle официально заявила, что ее облачная инфраструктура не подвергалась взлому, а опубликованные учетные данные не связаны с Oracle Cloud, подчеркнув, что ни один из клиентов не пострадал от кибератаки. Однако независимые ИБ-специалисты и часть клиентов Oracle подтвердили подлинность образцов данных, что вызвало сомнения в достоверности опровержения компании. Учитывая противоречивые заявления, организациям, использующим сервисы Oracle Cloud, рекомендуется менять пароли и ключи, проводить аудит журналов на предмет подозрительной активности и усиливать контроль доступа с помощью многофакторной аутентификации. Эксперты также советуют следить за обновлениями через официальные каналы Oracle и рекомендации по безопасности, поскольку ситуация остаётся неоднозначной 23andMe: атака на ДНК В октябре 2023 года компания 23andMe, специализирующаяся на генетическом тестировании, столкнулась с масштабной утечкой данных, которая затронула 6,9 миллионов пользователей. Первоначально злоумышленники получили доступ к 14 000 аккаунтов, используя атаку типа credential stuffing. Это метод, при котором используются ранее скомпрометированные учетные данные с других сервисов. Однако из-за особенностей функций DNA Relatives и Family Tree, которые позволяют пользователям делиться генетической информацией с родственниками, масштабы утечки значительно увеличились. В результате были скомпрометированы данные 5,5 миллионов пользователей, информация о родственных связях и проценте совпадения ДНК, а также 1,4 миллиона профилей из функции Family Tree. Источник. Одной из ключевых проблем стало отсутствие обязательной многофакторной аутентификации (MFA) и недостаточные меры по ограничению количества попыток входа (rate limiting). Это позволило злоумышленникам эффективно использовать атаку credential stuffing. Кроме того, архитектура платформы позволяла пользователям, получившим доступ к одному аккаунту, извлекать данные о родственниках этого пользователя, что значительно увеличило объем скомпрометированных данных. После обнаружения утечки 23andMe предприняла ряд мер. Среди них были обязательная смена паролей для всех пользователей, внедрение двухфакторной аутентификации и временное отключение функций, таких как возможность загрузки данных и использование DNA Relatives. Однако компания подверглась критике за задержку в обнаружении и реагировании на инцидент, а также за попытки переложить ответственность на пользователей, обвиняя их в использовании слабых паролей. Впоследствии против 23andMe были поданы коллективные иски из-за халатности и нарушения конфиденциальности данных. В сентябре 2024 года компания согласилась на урегулирование в размере $30 миллионов, включая компенсации пострадавшим пользователям и предоставление услуг по мониторингу безопасности. Итоги и рекомендации В 2025 году устойчивая криптография — не просто хорошая практика, а строго необходимое требование. Реальные кейсы — от утечек в IoT-сегменте до атак на корпоративную инфраструктуру показывают: компромиссы в области криптографии оборачиваются катастрофами. Устаревшие алгоритмы, отсутствие ключевой ротации, незащищенная передача данных — все это недопустимо. Чтобы как-то спасти ситуацию, применяйте современные криптографические стандарты и best practices. На профильных симпозиумах регулярно обсуждаются и закрепляются новые национальные и отраслевые стандарты. Для защиты данных выбирайте актуальные алгоритмы: AES-GCM и ChaCha20-Poly1305 для симметричного шифрования, SHA-256 и более новые для хеширования, а также стойкие схемы аутентификации и целостности. При работе с паролями используйте только медленные KDF с солью — Argon2, bcrypt или scrypt. Это существенно усложняет перебор даже при утечке хеша. Не рекомендация, а требование большинства стандартов и регуляторов. Данные должны быть защищены как при передаче (in-transit), так и при хранении (at-rest). Используйте TLS 1.3+ для всех сетевых соединений и включайте серверное шифрование на всех облачных и локальных хранилищах. Для IoT-устройств и любых распределенных систем внедряйте уникальные ключи для каждого экземпляра, используя PKI или асимметричные схемы, а также поддерживайте защищенные механизмы OTA-обновлений для своевременного устранения уязвимостей. Проводить аудит конфигураций, включая TLS/SSL, анализировать версии протоколов и параметры шифрования, а также отслеживать появление новых угроз и стандартов — минимальные вещи для безопасности. Наконец, уже в ближайшие два-три года начнется масштабный переход к постквантовым алгоритмам, и организациям важно следить за рекомендациями NIST и ETSI, а также участвовать в пилотных внедрениях. Возможность seamless-перехода к PQC должна закладываться в архитектуру решений уже сейчас.

Матвей Чернов

Материалы автора

Как Kubernetes стал стандартом управления инфраструктурой

Изоляция процессов и минимизация привилегий: Linux namespaces и seccomp

Дерзкие фишинговые схемы, которые сработали