ZeroDay | Кибербезопасность

Гэри «Соло» МакКиннон: взломать Пентагон в поисках НЛО История МакКиннона - это одновременно и байка про уфологию начала 2000-х, и очень показательный кейс о том, насколько плохо иногда была устроена безопасность даже в сетях американских ведомств. Вместо сложных эксплойтов тут дефолтные пароли, открытый NetBIOS и удалённый доступ с базовыми настройками. ⏺В статье разбирают, как британский админ под ником Solo больше года лазил по системам NASA и Пентагона в поисках доказательств существования НЛО, почему США называли это крупнейшим военным взломом своего времени и как вся история в итоге превратилась в международный скандал с судами, угрозой экстрадиции и публичной кампанией в его защиту. ZeroDay | Белый Хакер | #Статья

ZeroDay | #мем

Приглашаем на бесплатный вебинар «Резервное копирование: как проверить готовность к реальному инциденту» Резервные копии есть у всех. Но когда случается реальная атака шифровальщика, выясняется, что восстановить инфраструктуру в нужные сроки невозможно. Критические ошибки в backup-защите обнаруживаются именно тогда, когда исправлять уже поздно. На мероприятии директор техдепартамента RTM Group и гендиректор MEDOED Фёдор Музалевский разберет: 🔵 почему работающая система резервного копирования может не спасти бизнес; 🔵 как проверить backup-защиту (порядок действий и чек-лист); 🔵 какие ошибки встречаются чаще всего — на примере реального кейса аудита. Вебинар будет особенно полезен руководителям и специалистам по ИБ и ИТ, системным администраторам, отвечающим за резервное копирование, а также всем, кто хочет проверить, как их система защиты работает на практике, а не только на бумаге. 📆 Когда? 21 мая в 12:00 (online). 🔥Участие — бесплатное! Подробная программа и регистрация — по ссылке.

Pentest award 2026 открыл прием заявок! Каждый год у этичных хакеров появляется возможность заявить о себе, продемонстрировать свои навыки и творческий подход к решению задач в области тестирования на проникновение. Главный приз за победу — статуэтка и макбук! За вторые и третьи места призеры получат айфоны и смарт-часы. Церемония награждения состоится 14 августа на Красном Октябре Заявка на премию — это рассказ о лучшем проекте в свободной форме. Не нужно раскрывать эксплоиты, любые шаги в цепочке эксплуатации могут быть полностью анонимны, а детали могут быть скрыты, важно отразить сам подход и идею. Отправляйте заявки на сайте, участвуйте и побеждайте! Реклама. ООО «Авилликс». erid: 2VtzqxZ1Ckw

Права доступа в Linux: где чаще всего ошибаются​​​​​​​​​​​​​​​​? 👋 Приветствую в мире цифровой безопасности! Расскажу об основных правах доступа в Linux. ⏺Каждый файл в Linux имеет ровно одного владельца, одну группу и всех остальных. Девять битов прав делятся поровну между ними, по три на каждый класс. Выглядит это так:

    
        -rw-r----- 1 root shadow /etc/shadow{}
    

root читает и пишет, группа shadow только читает, все остальные не получают вообще ничего. ⏺Самое важное, как ядро принимает решение о доступе. Проверка идёт строго по порядку и останавливается на первом совпадении. Сначала смотрит EUID процесса, если совпал с владельцем файла, берёт биты владельца и останавливается. Группа даже не проверяется. Поэтому файл с такими правами:

    
        ----rwx--- 1 ivan developers secret.txt{}
    

недоступен для Ивана несмотря на то что его группа имеет полный доступ. Ядро увидело что ivan владелец, применило биты владельца (—) и остановилось. Права не суммируются, и это частая ловушка. ⏺SUID - бит который часто используют при эскалации привилегий: он заставляет процесс работать с правами владельца файла, а не того кто его запустил. Именно так обычный пользователь через passwd может писать в /etc/shadow, потому что passwd принадлежит root и имеет SUID. Если на системе внезапно появился SUID на bash, vim или find, это уже инцидент. Проверяется так:

    
        find / -perm -4000 -type f 2>/dev/null{}
    

⏺ACL нужен, когда стандартная модель не справляется: один владелец и одна группа - довольно жёсткое ограничение. Если нужно дать Марии права на запись, а условному Сергею только на чтение, UGO это не позволит. ACL решает задачу, но есть частая ошибка, настроить его без флага -d, тогда новые файлы создаваемые в директории его не наследуют:

    
        setfacl -R -m g:developers:rwx /project   # для существующих файлов
setfacl -d -m g:developers:rwx /project   # для новых файлов{}
    

ZeroDay | Белый Хакер | #Linux

Claude Mythos и уязвимость, которая уже существовала (или нет?) 👋 Приветствую в мире цифровой безопасности! Anthropic заявила что их новая модель Mythos автономно нашла уязвимость в ядре FreeBSD и сразу написала рабочий эксплойт. Только история оказалась интереснее чем кажется… ⏺Уязвимость нашли в функции svc_rpc_gss_validate() сетевой файловой системы FreeBSD. Она выделяет на стеке 128-байтный буфер, записывает в него 32 байта заголовка и копирует туда же тело credentials, не проверяя размер. Если credentials больше 96 байт, данные выходят за пределы буфера и перезаписывают адрес возврата:

    
        int32_t rpchdr[128 / sizeof(int32_t)];
// записали 32 байта заголовка, осталось 96
if (oa->oa_length) {
    memcpy((caddr_t)buf, oa->oa_base, oa->oa_length); // нет проверки размера
}{}
    

Патч добавляет одну проверку до копирования:

    
        if (oa->oa_length > sizeof(rpchdr) - 8 * BYTES_PER_XDR_UNIT) {
    return (FALSE);
}{}
    

⏺Но тут исследователи полезли в историю кода и нашли кое-что интересное: В 2007 году уже выходила CVE-2007-3999, практически идентичная уязвимость в той же функции, только в реализации MIT Kerberos. Код FreeBSD был скопирован из того же источника в начале 2000-х, патч так и не применили. Mythos по сути переоткрыла баг который уже был в её обучающих данных. ⏺Это не значит что достижение нейронки - ненастоящее: Автономно пройти путь от чтения незнакомого кода до рабочего эксплойта ядра, это серьёзно. Но разница между «ИИ нашёл новую уязвимость» и «ИИ переоткрыл старый паттерн из обучающих данных» принципиальная. ⏺Но тут главная проблема в другом: LLM генерируют код на основе данных, в которых полно небезопасных паттернов. Те же паттерны оседают в новых кодовых базах, и следующий агент найдёт их быстро, дёшево и без лишнего шума. ZeroDay | Белый Хакер | #AI

Как НЕ провалить аудит смарт-контрактов? Провальный аудит - так то не всегда история про слабых спецов или пропущенные баги. Чаще всё ломается раньше: плохая подготовка, размытые задачи, хаос в коммуникации и попытка «успеть всё» за нереальные сроки. ⏺В статье по шагам разбирают, как вообще устроен нормальный аудит смарт-контрактов: от доступа к инфраструктуре и общения с разработчиками до финального отчёта с PoC и рекомендациями. ZeroDay | Белый Хакер | #Статья

ZiChatBot: малварь в PyPI с C2 через Zulip 👋 Приветствую в мире цифровой безопасности! Kaspersky нашли три пакета на PyPI, которые честно делали то, что обещали в описании. И параллельно тихо ставили малварь 🧐Так то в этом и была вся хитрость. Просто конда пакет реально работает, никто не лезет смотреть что там внутри, а зря… ⏺uuid32-utils, colorinal, termncolor - у всех трёх нормальный функционал, termncolor вообще чистый сам по себе, просто тянет colorinal как зависимость. Нагрузка спрятана именно там, в транзитивной зависимости, которую в большинстве проектов никто не проверяет. Поставил пакет, он заработал, и всё, дальше никто не смотрит. ⏺На Windows в момент импорта библиотеки загружается terminate.dll, которая дропает ZiChatBot, прописывает его в реестр и удаляет себя. На Linux то же самое через terminate.so, малварь ложится в /tmp/obsHub/obs-check-update и закрепляется через crontab. ⏺Вместо собственного C2-сервера используется Zulip - обычный корпоративный мессенджер с REST API. Малварь получает шеллкод через API, выполняет его локально и отправляет сердечко как подтверждение что всё прошло. С точки зрения любого мониторинга это просто HTTPS-трафик к легитимному сервису, и именно поэтому такие каналы так сложно поймать - сигнатур нет, домены чистые, да и поведение как у обычного приложения. ⏺По атрибуции пока вопрос открытый. Дроппер на 64% похож на инструментарий OceanLotus (APT32), но уверенности нет. Если это всё-таки они, то группа заметно меняет подход, потому что раньше работали через фишинг, теперь идут через публичные репозитории, что так то сильно расширяет охват потенциальных жертв. ZeroDay | Серверная Админа | #атака