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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Баг macOS ломает TCP через 49 дней без перезагрузки

В macOS нашли редкий, но очень неприятный баг: если компьютер работает без перезагрузки примерно 49,7 дня, у него может постепенно умирать TCP. По версии исследователей, проблема связана с переполнением 32-битного счётчика времени в ядре XNU, который используется TCP-подсистемой.

После этого внутренние TCP-таймеры якобы перестают нормально обновляться, соединения в состоянии TIME_WAIT не очищаются, временные порты постепенно заканчиваются, и система в какой-то момент просто перестаёт устанавливать новые TCP-соединения.

При этом ping может продолжать работать, что делает сбой особенно странным. В Photon пишут, что заметили аномалию на своих macOS-машинах, которые круглосуточно используются для мониторинга iMessage-сервисов.

По их описанию, часть узлов после примерно 49 дней 17 часов 2 минут 47 секунд аптайма перестала открывать новые TCP-сессии. После перезагрузки всё возвращалось в норму, но таймер, по сути, запускался заново.

Авторы утверждают, что смогли воспроизвести поведение на двух машинах и связали его с переменной tcp_now в XNU. В открытом репозитории Apple действительно есть TCP-код ядра Darwin/XNU, где используются 32-битные значения времени и логика сравнения временных меток TCP, на которую ссылаются исследователи.

Поведения бага выглядит так: сначала ничего не ломается в лоб, но закрытые TCP-соединения перестают вовремя исчезать из TIME_WAIT. Затем их становится всё больше, временные порты забиваются, новые подключения начинают зависать в SYN_SENT, а сервисы, которым нужны новые TCP-сокеты, начинают сыпаться.

Если эта находка подтвердится, то для обычного пользователя баг вряд ли станет массовой проблемой: большинство устройств на macOS перезагружаются чаще (хотя бы из-за обновлений). А вот для долго работающих Mac mini, билд-серверов, CI/CD-ферм, удалённых рабочих станций и серверных компьютеров, которые могут жить без ребута неделями, история выглядит уже куда серьёзнее.

Если у вас есть компьютер на macOS, который работает неделями без перезагрузки и критичен для сервисов, мы бы посоветовали следить за его аптаймом.

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