Архив рубрики: Темы

Сходили с семейством на "Сказку о царе Салтане"

Добавить комментарий

Сходили с семейством на "Сказку о царе Салтане". Ничего так. Про проблемы с ИБ в Saltan Inc. и крайне удачливый, но и крайне мутный IT-стартап GWI Done. 🙂

1. Проблемы с ИБ в Saltan Inc. видны с самого начала. Ключевой сервис GONE.c компании подвержен критической уязвимости, позволившей злоумышленникам провести атаку "человек посередине" (MitM) и выполнить действия от имени CEO Салтанова. Процедуры подтверждения решений не было, платёжка прошла, активы ушли в "бездну вод". Инцидент замяли. Крайним выставили CTO Гвидонова, которому пришлось покинуть компанию.

2. Гвидонов запускает стартап GWI Done. Разработка PoC ведётся в режиме жёсткой экономии и по Agile:

"Ломит он у дуба сук
И в тугой сгибает лук,
Со креста снурок шелковый
Натянул на лук дубовый,
Тонку тросточку сломил,
Стрелкой легкой завострил"

Гвидонову необыкновенно везёт, он знакомится с ключевым инвестором и будущим партнёром по бизнесу, влиятельной г-жой Лебедевой. Это предрешает успех всего предприятия. После первого успешного проекта получены инвестиции, гарантирующие развитие компании на годы вперед. За счёт этих средств успешно запустили блокчейн-платформу Belka.

"Из скорлупок льют монету,
Да пускают в ход по свету;"
"Князю прибыль, белке честь"

Силовую поддержку бизнеса обеспечивают, "братья" Лебедевой под руководством Черноморова.

3. Кульминационный момент это сделка о недружественном поглощения Saltan Inc. со стороны GWI Done. Ключевую роль здесь снова сыграли проблемы с ИБ в Saltan. Успешная APT атака позволила Гвидонову и Лебедевой получить доступ ко всем переговорам внутри Saltan Inc. в реальном времени (почта, месенджеры, сервис телеконференций) и купировать все попытки противодействия ТОПов Saltan. Не брезговали даже причинением лёгкого вреда здоровью ТОПов. В итоге Гвидонов и Лебедева успешно отжимают бизнес, расходятся относительно мирно с предыдущей командой, даже номинально оставляют в компании Салтанова, и продолжают жить-поживать, да добра наживать.

Мораль: связи решают, а проблемы с ИБ могут иметь самые плачевные последствия для бизнеса. 🙂

В прошлый раз про Данилу-мастера разбирал.

По наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от Nucleus

Добавить комментарий

По наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от NucleusПо наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от NucleusПо наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от Nucleus

По наводке Александра Редчица посмотрел на CISA Known Exploited Vulnerabilities Enrichment Dashboard от Nucleus. Товарищи взяли CISA KEV и добавили туда данные EPSS (Score и Percentile), CVSS из NVD, а также Treat Intelligence фид от GreyNoise. Вроде ничего хитрого, но получилось занимательно.

1. Самое очевидное это то, что можно дополнительно приоритизировать уязвимости из CISA KEV для исправления.
2. С другой стороны здесь наглядно видны проблемы источников.
2.1. Если уязвимость эксплуатируется вживую, то почему эту эксплуатацию GreyNoise не видит? С одной стороны это может быть связано с ограничением фида GreyNoise - не по всем уязвимостям могут эксплуатацию отслеживать. С другой стороны это может быть связано с тем, что CISA берет признак эксплуатации от вендора, по факту это может быть "вероятная эксплутация в единичной таргетированной атаке в полнолуние и пятницу 13-е", а подробностей нет и не будет.
2.2. Вот Exploit Prediction Scoring System (EPSS) показывает "probability [0-1] of exploitation in the wild in the next 30 days (following score publication)". Весьма весело взять уязвимости "CVE-2022" с детектами от GreyNoise и увидеть, что EPSS для них вероятность появления эксплоита оценивала довольно низко. Выделил на скриншоте 20%. Иногда оценка даже в 1-2%, как например в случае с одной из уязвимостей Exchange ProxyNotShell. В общем, EPSS это далеко не серебряная пуля.
2.3. Также интересно посортировать по CVSS. Сразу вылезают проблемы с уязвимостями, которых нет в NVD. Проблемы сортировки в таблице (но это ладно). А самое интересное уязвимости с CVSS 7, т.е. меньше High. В данном случае укладываются в Medium. То есть горячий привет тем, кто жестко фильтрует по CVSS от High и выше.

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

1 комментарий

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

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

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 дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями?

4 комментария

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

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

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

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

2 комментария

Кстати узнал, что для 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 и в отношении чужого кода тоже. Лучше лишний спросить себя действительно ли эта новая зависимость нужна и не хватит ли того, на что мы уже завязались (и чьим авторам доверились).

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