Архив за месяц: Декабрь 2022

Посмотрел запись вебинара ОМП и Аквариуса "Как ОС Аврора появляется на мобильных устройствах российского производства"

Посмотрел запись вебинара ОМП и Аквариуса Как ОС Аврора появляется на мобильных устройствах российского производстваПосмотрел запись вебинара ОМП и Аквариуса Как ОС Аврора появляется на мобильных устройствах российского производстваПосмотрел запись вебинара ОМП и Аквариуса Как ОС Аврора появляется на мобильных устройствах российского производстваПосмотрел запись вебинара ОМП и Аквариуса Как ОС Аврора появляется на мобильных устройствах российского производстваПосмотрел запись вебинара ОМП и Аквариуса Как ОС Аврора появляется на мобильных устройствах российского производстваПосмотрел запись вебинара ОМП и Аквариуса Как ОС Аврора появляется на мобильных устройствах российского производства

Посмотрел запись вебинара ОМП и Аквариуса "Как ОС Аврора появляется на мобильных устройствах российского производства". Весьма интересно.

1) В первой части про Аврору понравилось, что в ОМП всерьез занимаются проблемами информационной безопасности и исправлением известных уязвимостей.
2) Вторая часть про производство устройств в Аквариусе удивила. Я грешным делом думал, что "устройства российского производства" это просто OEM, который в готовом виде из Китая приходит. Ну или максимум конвейерная сборка из готовых модулей. Оказывается в случае Аквариуса это не так. Рассказали про полный цикл производство, включающий проектирование и изготовление печатных плат для кпк, планшетов и серверных продуктов. Понятное дело, что используемые электронные компоненты импортные, но даже текущая степень локализации впечатляет. Особенно с учетом вполне современных характеристик устройств. Круто!

На днях пролетала новость по поводу уязвимости FreeBSD CVE-2022-23093 про RCE и ping

На днях пролетала новость по поводу уязвимости FreeBSD CVE-2022-23093 про RCE и ping

На днях пролетала новость по поводу уязвимости FreeBSD CVE-2022-23093 про RCE и ping. Можно было предположить, что достаточно послать какой-то хитрый ICMP Echo (ping) пакет на уязвимый хост и получить RCE.

К счастью, судя по бюллетеню FreeBSD-SA-22:15.ping.asc, проблема заключается в обработке ответа на ping от внешнего хоста.

"ping reads raw IP packets from the network to process responses in the pr_pack() function."

Т.е. уязвимый FreeBSD-шный хост должен начать пинговать хост злоумшышленника. Хост злоумышленника должен ждать этот ping и в ответ выдать нестандартную бяку, которая покрашит процесс на FreeBSD-шном хосте, и это возможно (!) приведет к RCE от рута, т.к. ping устанавливается с setuid bit. Но из-за того, что процесс ping запускается в песочнице ("capability mode sandbox"), атакующему будет сложновато нанести какой-то реальный вред системе.

Обновлять FreeBSD-ные хосты нужно (а EOL-ные выкорчевывать), но всерьез рассматривать эту уязвимость сложновато.

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями?

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями?

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями? Если б я был регулятор. 🙂

1) Обновления безопасности должны быть. Критичная общелинуксовая уязвимость, должна быть пофикшена и в отечественном дистрибе. Или должно быть опубликовано обоснование, почему она неэксплуатируема.
2) Бюллетени безопасности должны быть. Клиенты должны как-то узнавать какую версию пакета нужно поставить, чтобы избавиться от критичной уязвимости.
3) Бюллетени безопасности должны быть публично доступны. Cпорный момент. Зависит от отношения к "security through obscurity". По мне закрытие доступ к бюллетеням усложняет жизнь исследователям, а злоумышленники все равно их получат через любого клиента.
4) Бюллетени безопасности должны быть доступны в машиночитаемом виде. Желательно в формате OVAL, раз уж он так распространен (RHEL, Suse, Ubuntu, Debian и даже отечественный RedOS)

Кстати узнал, что для RedOS есть официальный OVAL-контент (XML, 1.1 мб)

Кстати узнал, что для RedOS есть официальный OVAL-контент (XML, 1.1 мб)

Кстати узнал, что для RedOS есть официальный OVAL-контент (XML, 1.1 мб). И даже есть статья на русском как его использовать для детектирования уязвимостей на хостах при помощи OpenSCAP. VM-щикам сканеристам теперь можно удобно обновлять свои базы знаний, забирая данные из этой публично доступной XML-ки в стандартном формате. А не возиться с черти как оформленными бюллетеньками, которые ещё и не факт, что вообще есть. Нужно ли говорить, что в моём личном рейтинге отечественных операционных систем RedOS теперь взлетела в самый-самый топ. 😍 Молодцы 👍

Чем ответит купечество, т.е. остальные вендоры российских Linux-ов? 🙂

Про программный код, отношения и эпикуреизм

Про программный код, отношения и эпикуреизм

Я, конечно, не настоящий программист. Даже не претендую. Но код пишу, мнение имею и иногда позволяю себе его высказывать. Мнение такое. Кажется, что некоторые максимы, к которым мы привыкли как к чему-то разумеющемуся в современных реалиях требуют переосмысления. Например то, что использовать чужой код в виде модулей и библиотек это правильно и хорошо. Да, конечно, это позволяет получить нужную функциональность несколько быстрее и проще. И возможно этот чужой код будет лучше протестирован, в том числе и с точки зрения безопасности.

Но надо понимать, что использование чужого кода порождает зависимость от него. В известной степени это означает вступление в определенные отношения с автором кода. Возможно весьма токсичные. Придется приспосабливаться к возможным тараканам в голове этого человека. Автор сделал изменения, умышленно или случайно, которые поломали ваше приложение и/или испортили ваши данные? Ну что ж, вы сами виноваты. Лучше надо было тестироваться. На сайт проекта заглядывать, интересоваться что там автор делает и какую позицию по разным вопросам имеет. Уязвимости и баги в коде автора это теперь ваши общие уязвимости и баги. Автор в своем праве исправлять их в сколь угодно большие сроки или вовсе не обращать на них внимание.

Конечно без использования чужого кода не получится. Но следует проявлять при этом разумность и умеренность. Если неограниченно плодить зависимости (а значит отношения с авторами этого кода), это перестанет быть сколько-нибудь контролируемым и неизбежно приведет к проблемам. Тем более, когда использование чужого кода оправдывается не объективными насущными причинами, а тем, что так "проще писать", "на N строчек короче", "работает на 10% быстрее", "да все так делают", "уважаемый эксперт N сказал, что так делать правильно".

"Никакое наслаждение само по себе не есть зло; но средства достижения иных наслаждений доставляют куда больше хлопот, чем наслаждений" © Эпикур.

Прежде чем вкорячивать в проект очередную монструозную вундервафлю, подумай не создаёшь ли ты сам себе проблемы на ровном месте.

К примеру, если мне потребуется интеграция через http-based API я скорее разберусь сам как оно устроено и буду сам делать запросы, чем понадеюсь на непонятно кем и как поддерживаемый модуль. Если для моей частной задачи будет достаточно небольшого самописного "велосипеда", то я буду использовать его, а не мега-комбайн (привет log4j, ага).

Итого, Keep It Simple Stupid и в отношении чужого кода тоже. Лучше лишний спросить себя действительно ли эта новая зависимость нужна и не хватит ли того, на что мы уже завязались (и чьим авторам доверились).

"Величайший плод ограничения желаний — свобода." © Эпикур.

Весной-летом я толкал речи на тему как Vulnerability Management поменялся в 2022 году

Весной-летом я толкал речи на тему как Vulnerability Management поменялся в 2022 году. Пришла зима, скоро уже новый год, есть повод порефлексировать и скорректировать видение.

Что сканировать?

1) Оценка "стабильности" IT-вендоров похоже оказалась не особо востребованной и в итоге свелась к переходу на отечественное. Тут и позиция регуляторов направляет, и нежелание зарубежных вендоров подставляться лишний раз под вторичные санкции. Пока выглядит так, что новые IT и ИБ решения будут в основном российские (пусть даже они будут функционально хуже).
2) С другой стороны массового выпиливания продуктов Microsoft пока не наблюдается. MS пока не нагнетают. Позиция регуляторов достаточно умеренная и сводится к требованию контроля обновлений. Видима зависимость настолько велика, что требовать чего-то другого не реалистично.
3) Массового отказа от мейнстримных Linux дистрибутивов тоже не наблюдается. Пока не было громких кейсов с активным участием западных вендоров Linux дистрибутивов. Миграция c Ubuntu/Debian/CentOS Stream/Alma/Rocky на российские дистрибы связана с техническими сложностями и значительными финансовыми затратами. В целом, в ширнармассах пока не ощущается понимание зачем это нужно (за исключением случаев когда это прямое указание регулятора).

Чем сканировать?

Какого-то значимого изменения ландшафта на рынке VM-решений пока не видится.
1) Кто-то продолжает использовать западные решения с помощью разного рода ухищрений.
2) Кто-то активнее переходит на продукты традиционных отечественных VM вендоров (Positive Technologies, Алтэкс-Софт, Эшелон, Газинформсервис).
3) Есть некоторая активность от нового игрока Vulns.io.
4) Есть развитие у периметровых сервисов Metascan и ScanFactory.
5) Интересно развитие VM как доп. функциональности у Kaspersky: если все равно антивирус заменять, удобно получить в результате и агент детектирующий уязвимости. Win-win в духе Microsoft Defender for Endpoint. Выглядит как перспективная тема для агентного сканирования.
6) Достаточно много больших российских компаний приняли решение пилить свои VM решения, т.к. доступные коммерческие дороги и/или чем-то не устраивают. Есть вероятность появления таких решений на рынке.