В файрволах Palo Alto Networks нашли критическую уязвимость, позволяющую получить root-доступ удалённо — без аутентификации.
Детали пока скупые: SecurityLab сообщает о захвате устройства через сеть, но ни CVE-номера, ни затронутых версий PAN-OS в открытом доступе пока нет. Это само по себе тревожный сигнал — либо патч ещё не готов, либо информацию придерживают намеренно, чтобы не дать атакующим готовый вектор до выхода исправления.
Для тех, кто держит периметр на PA-серии: Palo Alto — один из самых распространённых enterprise-файрволов в российских корпоративных сетях, особенно в компаниях, которые ещё не завершили импортозамещение. Root на файрволе — это не просто «дыра в защите». Это полный контроль над трафиком, возможность отключить сегментацию сети, обойти политики и получить плацдарм для горизонтального движения внутри инфраструктуры.
Что стоит сделать прямо сейчас. Проверить, торчит ли management-интерфейс вашего Palo Alto в интернет (он не должен). Подписаться на security advisories от Palo Alto Networks напрямую — они публикуют бюллетени на security.paloaltonetworks.com раньше, чем новость доходит до агрегаторов. И следить за обновлением: как только выйдет патч с CVE — ставить без раздумий.
Файрвол с root-уязвимостью на периметре — это уже не файрвол, а открытая дверь с охранником, который работает на другую сторону.
Opensource-зависимости стали одним из главных векторов атак на цепочки поставок — и это уже не теория. Positive Technologies обновили PT Fusion до версии 1.7: теперь в нём появились фиды от PT Supply Chain Security с данными о вредоносных, протестных и удалённых релизах опенсорс-проектов. Формат — OSV, стандартный для ИБ-сообщества.
Что за угрозы они покрывают. Речь о трёх категориях: пакеты с намеренно внедрённым вредоносным кодом, «протестные» релизы (когда мейнтейнер что-то встраивает из политических или личных соображений — как было с colors.js или node-ipc) и заброшенные проекты, которые никто больше не патчит. Последнее — особенно коварно: уязвимость может существовать годами, и никто её не закроет.
Где это применимо. Фиды грузятся в SCA-инструменты, dependency firewall и реестры артефактов. Отдельный сценарий — ретроспективный forensics: при расследовании инцидента можно проверить, не было ли скомпрометированной зависимости на конечных устройствах. Это меняет SCA из «проверки перед деплоем» в непрерывный мониторинг.
Для компаний, где разработка использует опенсорс (а это почти все), вопрос уже не «нужен ли нам контроль зависимостей», а «насколько актуальна наша база данных угроз». Фиды в PT Fusion обновляются регулярно — это важнее самого факта их наличия.
4 мая Microsoft подтвердила: Defender с обновлением сигнатур от 30 апреля начал детектировать легитимные корневые сертификаты DigiCert как Trojan:Win32/Cerdigent.A!dha — и в ряде случаев не просто предупреждал, а удалял их из хранилища доверенных корневых сертификатов Windows.
Под удар попали два конкретных сертификата (`0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43` и DDFB16CD4931C973A2037D3FC83A4D7D775D05E4), которые вырезались прямо из ветки реестра HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\. Часть пользователей, не разобравшись, переустанавливала Windows — решив, что машина реально заражена.
Что произошло на самом деле. Defender оперативно добавил правила обнаружения после инцидента у DigiCert: злоумышленники атаковали сотрудника поддержки через вредоносный ZIP под видом скриншота, получили действительные сертификаты и использовали их для подписи малвари — в том числе компонентов кампании Zhong Stealer. DigiCert отозвала 60 сертификатов. Логика детекта сработала, но зацепила слишком широко — накрыв заодно и легитимные корневые.
Проблема исправлена в Security Intelligence 1.449.430.0 и новее. Свежее обновление также восстанавливает ранее удалённые сертификаты — дополнительных ручных действий Microsoft не требует.
Для меня как CIO этот инцидент — хорошая иллюстрация того, насколько хрупкой может оказаться цепочка доверия к сертификатам. Один взломанный сотрудник поддержки у CA, несколько выданных сертификатов — и антивирус крупнейшего вендора начинает «лечить» легитимную инфраструктуру. Если у вас есть системы, критически зависящие от конкретных корневых сертификатов (VPN, внутренние PKI, подписанные агенты мониторинга), стоит проверить, не прилетело ли обновление сигнатур незаметно в нерабочее время и не унесло ли что-нибудь с собой.
В cPanel обнаружена уязвимость, позволяющая получить доступ к серверу без пароля — авторизацию можно обойти полностью.
cPanel стоит на миллионах хостинг-серверов по всему миру. Это де-факто стандарт для shared-хостинга и небольших VPS. Если дыра позволяет зайти без учётных данных — под угрозой не только сайты, но и базы данных, почтовые ящики, конфигурации, SSH-ключи, всё что лежит на сервере.
Детали эксплойта SecurityLab не раскрывает, но сам факт обхода аутентификации — это уже критический уровень. Не «повышение привилегий», не «утечка данных при определённых условиях». Просто: пароль не нужен.
Что стоит проверить прямо сейчас
Если у вас или ваших подрядчиков есть серверы на cPanel:
убедитесь, что установлена последняя версия панели (апдейты в cPanel выходят через WHM → cPanel & WHM Updates)
закройте порты 2082, 2083, 2086, 2087 для внешнего доступа, если панель не должна быть публичной
проверьте логи авторизации на предмет подозрительных входов за последние несколько дней
если используете хостинг-провайдера — уточните у него статус патча
Последнее, что хочется обнаружить в понедельник утром: кто-то уже неделю ходит по вашему серверу, пока вы думали, что всё закрыто.
Недавно наткнулся на занятный опенсорс‑проект — GitHub Store (github.com/OpenHub-Store/GitHub-Store). Это такая «оболочка» поверх GitHub, которая делает с репозиториями то же самое, что App Store / Google Play делают с приложениями.
В чём суть
По факту GitHub Store пытается ответить на давно назревший вопрос:
«Почему, чтобы поставить простую утилиту с GitHub, мне нужно идти читать README, искать бинарники, разбираться с релизами, а потом ещё помнить, как это всё обновлять?»
Авторы решили: хватит так жить. Давайте сделаем нормальный стор поверх GitHub, но без своей отдельной экосистемы:
есть лента с трендами и популярными репозиториями — можно просто полистать и найти что‑нибудь полезное, как в обычном магазине приложений;
установка в один клик (ну, почти) — не надо руками лазить по релизам и думать, какой файл скачать;
автоматические обновления уже установленных программ — не нужно помнить, что там выходило, кто из них обновился, а кто нет;
работает на Android, Windows, macOS и Linux — то есть это не очередной «только под одну платформу, остальным держаться».
С точки зрения пользователя это выглядит как нормальный стор: плитки, поиск, категории, тренды. Но под капотом — обычные GitHub‑репозитории. Никакого своего «реестра пакетов», зависимостей и т.п. Всё, что уже лежит на GitHub, становится чуть более человечно упакованным.
Зачем это вообще нужно
Если вы давно сидите на GitHub, то знаете эту боль:
находишь классный проект на Hacker News / Хабре / Реддите;
переходишь в репу;
в README: «build it yourself», 15 шагов, три тулчейна и «tested only on Arch btw»;
если повезло — есть бинарник где‑то глубоко в релизах, но без автообновлений.
GitHub Store как раз пытается это сгладить: вместо «репозиторий с набором файлов» — понятное приложение, которое можно установить и потом обновлять как нормальный софт.
Причём это не замена package manager’ам (apt, brew, winget и прочие), а именно интерфейс к тем проектам, которые туда никогда не доедут: личные тулзы, мелкие утилиты, нишевые программы, эксперименты.
Автор проекта прямо пишет, что идея — собрать в одном месте тысячи программ, которых вы не увидите ни в одном официальном сторе, но которые живут на GitHub, звёзды собирают, а до пользователя так и не доезжают.
Чем это похоже на App Store, а чем — нет
Похоже:
есть витрина: тренды, популярное, поиск;
есть установка в одно действие;
есть обновления, о которых думать не нужно.
Не похоже:
нет централизованной модерации в духе Apple/Google — это всё равно GitHub, со всеми вытекающими;
нет единого UX по установке/запуску (проекты разные, и у каждого свои особенности);
безопасность пока, очевидно, на уровне «как в GitHub»: вы сами решаете, кому верить.
То есть это не «новый стор, который победит все остальные», а надстройка над тем, чем GitHub по факту давно является — огромным складом софта, где интерфейс для обычного пользователя исторически был «так себе».
Кому это вообще может зайти
Тем, кто любит ковыряться в GitHub и искать новые инструменты, но устал превращать каждый проект в квест.
Тем, кто живёт на Linux / Windows / macOS, использует кучу мелких утилит и хочет держать их в одном месте с автообновлениями.
Тем, кто сам пилит опенсорс: это ещё один канал донести свой проект до людей, которые не любят GitHub, но любят «поставить и пользоваться».
Что в итоге
Идея «сделать стор поверх GitHub» витала довольно давно, но тут её хоть кто‑то нормально попробовал свернуть в рабочий вид, да ещё и кроссплатформенно.
Пока это выглядит как удобная человеческая морда к GitHub, а не очередной велосипед ради велосипеда. Если у вас жизнь связана с опенсорсом (или вы просто любите новые игрушки), проект точно стоит хотя бы посмотреть.
Ну и по классике: это опенсорс, так что можете не только поставить, но и прийти с PR’ами, если чего‑то не хватает или кажется сделанным криво.
Нашёл почти идеальный лаунчер для старых игр — и теперь снова хочется прожить детство
Иногда ностальгия приходит не в виде воспоминаний, а в виде очень конкретного желания: запустить какую-нибудь старую игру, которую ты когда-то проходил до дыр, услышать знакомое меню, увидеть тот самый пиксельный интерфейс — и на пару часов выпасть из реальности.
Проблема обычно одна: старые игры почти никогда не начинаются с фразы «просто нажми и играй». Где-то нужен патч, где-то эмулятор, где-то ручная настройка, где-то игра вообще запускается только после плясок с совместимостью. И вот на этом моменте магия ностальгии обычно разбивается о суровый быт.
Но тут я наткнулся на RohanKar Launcher— и это, честно, одна из самых тёплых находок за последнее время.
По сути, это такой маленький Steam для олдов: лаунчер, в котором собраны сотни ретро-игр, и всё это запускается в максимально человеческом формате. Без лишней боли, без многочасового ковыряния в архивах, без ощущения, что ты не в игру хочешь поиграть, а проходишь квест «оживи софт из 90-х».
Что в нём особенно радует:
есть нормальный поиск и фильтрация;
игры можно поставить буквально одной кнопкой;
для совсем старых тайтлов уже предусмотрены нужные инструменты для запуска;
есть трекер проведённого времени;
обновления и новые релизы подтягиваются автоматически.
И вот это, мне кажется, самое приятное: проект не пытается быть просто складом старья. Он делает старые игры снова удобными. Не музейным экспонатом, не «смотри, как было раньше», а чем-то живым, во что реально хочется зайти вечером.
Потому что одно дело — помнить старые игры. И совсем другое — снова запускать их без страданий.
Вообще, в таких проектах всегда цепляет не только функциональность, но и сама идея. Кто-то ведь реально сел и подумал: а почему у классических игр до сих пор нет удобного, аккуратного, дружелюбного лаунчера? Почему, чтобы вернуться в любимые вещи из детства, нужно сначала немного побыть системным администратором, архивариусом и шаманом?
И вот когда появляется такой инструмент, ты вдруг ловишь очень простую мысль: старые игры не устарели — устарел способ, которым мы обычно пытаемся в них вернуться.
Да, возможно, сегодня эти проекты выглядят наивно. Где-то они простые, где-то угловатые, где-то слишком старомодные по темпу и механикам. Но в этом и есть их сила. В них меньше шума, меньше бесконечной монетизации, меньше «удержания». Они просто были сделаны, чтобы в них играть.
И, наверное, именно поэтому такие лаунчеры вызывают столько радости. Они возвращают не только игры — они возвращают способ чувствовать игры.
Ностальгия, похоже, теперь действительно запускается в один клик.
