В Сеть выложили якобы вторую часть слитой базы Почты России

В Сеть выложили якобы вторую часть слитой базы Почты России

В Сеть выложили якобы вторую часть слитой базы Почты России

В открытый доступ попал второй фрагмент базы данных с клиентами, предположительно, “Почты России”. Сама госкомпания отрицает факт утечки. Первый дамп выложили в декабре в связке с Госуслугами. Файлы содержат ФИО, паспортные данные, СНИЛС и ИНН.

О продолжении истории со слитой базой “Почты России” сообщает Telegram-канал “Утечки информации”. В первой “серии” дамп фигурировал в декабрьском сливе с портала Госуслуг. Тогда слив опровергли в Минцифре, заявив, что данные взяты из старой утечки “Почты России”, которая произошла еще летом.

Новую утечку отрицает и сам оператор российской почтовой связи.

“После июльского инцидента мы провели полный аудит безопасности информационных систем и никаких утечек из них не было, — заявили Anti-Malware.ru в пресс-службе “Почты России”. — Наши специалисты по информационной безопасности исследовали упомянутую в запросе базу данных. Злоумышленники продолжают выкладывать неактуальные данные с подменой даты создания записей. Это компиляция из других утечек информации”.

Однако эксперты по кибербезопасности еще тогда заметили нестыковки.

“Информация от 19.12.2022 не совпадает с другими утечками из “Почты России”, ранее опубликованными в открытом доступе, поскольку относится к другой информационной системе почтового оператора, не появлявшейся ранее в публичном поле”, — говорили специалисты “Утечек информации”.

Свежий фрагмент базы по объему схож с первой частью и содержит примерно 140 тыс. строк:

  • ФИО
  • адрес (регистрации и фактический)
  • телефон
  • адрес эл. почты (не для всех)
  • СНИЛС/ИНН (не для всех)
  • пол
  • дата рождения
  • серия / номер паспорта, кем и когда выдан

Дамп был сделан не раньше 30 ноября 2022, говорят в “Утечках”.

На связь с “Почтой России” указывают такие специфичные поля, как:

  • pepactivate - ПЭП (простая электронная подпись)
  • flag_abox - abox.pochta.ru (абонентский почтовый ящик)
  • flag_digitalf22 - почтовое извещение, форма 22
  • post_office - коды почтовых отделений

Добавим, Минцифры всё еще работает над законопроектом об оборотных штрафах за утечки. В конце года в проекте закона прописали верхний предел штрафа. “Потолок” может составить 500 млн руб. Он предусмотрен в случае, если компания допустила утечку данных повторно с момента вступления закона в силу и нарушила требования регулятора, например скрывала инцидент.

При этом пока непонятно, как в таком случае будут поступать с государственными организациями. Будут ли они нести аналогичные штрафные санкции и каким образом они будут рассчитываться.

В GNU telnetd нашли критическую дыру с удалённым root-доступом

В GNU InetUtils telnetd обнаружили новую критическую уязвимость, которая позволяет удалённо выполнить произвольный код с правами root. Проблема получила идентификатор CVE-2026-32746 и, согласно опубликованному описанию, затрагивает версии до 2.7 включительно.

Исследователи из DREAM Security Labs говорят о классическом Переполнении буфера, который срабатывает ещё до появления запроса логина.

Суть бага в том, как telnetd обрабатывает переговоры по опции LINEMODE SLC. Если на старте соединения по TCP-порту 23 отправить специально подготовленное сообщение с аномально большим числом параметров, можно спровоцировать переполнение буфера.

Поскольку этот код отрабатывает сразу после подключения, атакующему не нужно проходить аутентификацию. А так как telnetd часто запускается с повышенными правами через inetd или xinetd, успешная эксплуатация фактически даёт полный контроль над хостом.

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

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

Если это невозможно, то минимум — закрыть порт 23 снаружи, оставить доступ только с доверенных адресов и не держать daemon с лишними привилегиями.

Здесь важно не перепутать эту уязвимость с другой недавней проблемой в GNU InetUtils telnetd. Ранее мы писали про CVE-1999-0073 — уязвимость из конца 90-х, которая неожиданно вернулась и снова позволяет получить полный root-доступ к серверу без аутентификации.

RSS: Новости на портале Anti-Malware.ru