Архивы автора: Александр Леонов

Об авторе Александр Леонов

Привет! Меня зовут Александр. Я специалист по Управлению Уязвимостями. Подробнее обо мне можно и моих проектах можете прочитать здесь. Приглашаю подписаться на мой канал @avleonovrus "Управление Уязвимостями и прочее" в MAX или в Telegram. Вы можете обсудить мои посты или задать вопросы в группе ВКонтакте. And I invite all English-speaking people to another Telegram channel @avleonovcom.

Классная была задумка в NVD добавлять лейблы к ссылкам

Классная была задумка в NVD добавлять лейблы к ссылкам

Классная была задумка в NVD добавлять лейблы к ссылкам. Чтобы сразу было видно на какой объект ссылаются: почтовая рассылка, бюллетень вендора, бюллетень третьих лиц, патч, а самое ценное - эксплоит. То есть можно было бы только на основе NVD делать достаточно неплохую приоритизацию уязвимостей. Но реальность, к сожалению, грустнее:

1. На простановку лейблов всем так-то пофигу. На скриншоте log4shell. Для части ссылок на packetstorm проставлено, что это эксплоиты. Для части нет. Может это на самом деле не эксплоиты? Да нет, все верно, я обкликал и проверил. Просто ошибка операциониста, который ссылку добавлял.
2. Заинтересован ли кто-то быстро добавить в NVD ссылку на эксплоит, когда он появляется в паблике? Да видимо не особо. Разве что для очень громких уязвимостей.
3. Это общая беда, но в описании CVE могут писать про один тип уязвимости, допустим RCE, а эксплоит будет демонстрировать другую уязвимость, допустим DoS.

Выводы? Спасибо, что хотя бы так и бесплатно. 🙂 Но исключительно на данные из NVD лучше не полагаться.

Ростелеком как головная контора для ОМП, тоже заинтересован в выпуске устройств на Аврора ОС для физиков

Если верить статье в Ъ… А верить статье, которая называется "Навстречу серверной «Авроре»" сложновато 🤦🏻‍♂️. Так вот, если ей верить, то Ростелеком как головная контора для ОМП, тоже заинтересован в выпуске устройств на Аврора ОС для физиков. Правда пока без особой конкретики, т.к. речь идет о промежутке 2022–2030 г. Всего же устройств за это время планируется выпустить от 1,5 млн до 65,9 млн (!). Правда обеспечить максимальные показатели можно будет только через меры жесткой господдержки, включающие, например, ограничение импорта зарубежных смартфонов. Видимо как с сыром.

И если так подумать, то я бы такое даже поприветствовал. Paris vaut bien une messe, а развитие отечественной мобильной экосистемы (на практически полноценном Linux-е причем!) стоит некоторых неудобств.

PS: там ещё пишут, что ограничение импорта не поможет, только серый рынок подстегнет. Но на это и обязательной регистрацией по IMEI можно ответить, а может и чем-то поинтереснее. 😈

upd. Вышел комментарий от Ростелека: "«Ростелеком» никогда не занимался и не собирается заниматься производством мобильных устройств." Ну это видимо про то, что в статье Ъ было: "Ростелеком" планирует разработку трех линеек смартфонов и планшетов на "Авроре" для обычных потребителей, бизнеса и госсектора. Очевидно, что если эти устройства и появятся, то производить их скорее всего будет не сам Ростелек или ОМП, а партнеры. Как и в случае с текущими устройствами на Авроре. Поэтому все верно.

Сходили сегодня семьей на "Хозяйку Медной горы"

Сходили сегодня семьей на "Хозяйку Медной горы". Хороший спектакль, поучительный.

1. CEO Барин дает задание сделать вазу за месяц. Project Manager Приказчик спускает сроки as is. Junior мастер Данила порывается сдать проект за день. Senior мастер Прокопьич предупреждает джуна, что это приведет к проблемам. За день не за день, но Junior сдает проект значительно раньше срока, получает у проджекта задание ещё на 2 аналогичные вазы. В итоге за месяц выдают 3 вазы. Project Manager Приказчик молодец получает поощрение. Junior мастер Данила и Senior мастер Прокопьич получают втык за затягивание сроков по предыдущим проектам, трамбовать задач в них теперь будут больше и контролировать строже.
2. На второй усложненный проект вазы выделяется "хоть 5 лет", требования подтверждены ТЗ (чертежом). В итоге проект сдают за год. Планирование конечно атас, но хоть уже без дурных попыток нафигачить и сдать всё за день. Казалось бы джун Данила становится адекватнее. Но фиг там.
3. Помимо основной работы джун Данила придумывает себе pet-project. В текущих рабочих проектах он не видит красоты, архитектура не та, "сила камня не раскрывается". Фигачит в свободное от основной работы время вазу по дурман-цветку. Senior мастер Прокопьич предостерегает от нарушения work-life balance, т.к. нечем хорошим это не кончится - либо выгоришь, либо двинешься. Тщетно. Данила окончательно слетает с катушек, буянит и отъезжает, образно выражаясь, "к хозяйке Медной горы смотреть каменный цветок".
4. К счастью, история заканчивается хэппи-эндом. Прошедший процедурки Данила возвращается к производительному труду, женится на Екатерине, выращившей его из заведения "хозяйки Медной горы". И вроде даже обходилось без значительных рецидивов. "Только нет-нет - и задумается Данило. Катя понимала, конечно, - о чем, да помалкивала".

Посмотрел интервью с Алексеем Коганом из ОМП про ОС Аврора

Посмотрел интервью с Алексеем Коганом из ОМП про ОС Аврора. Очень адекватная и взвешенная позиция у Алексея. Понравилось как он сформулировал преимущества независимой национальной мобильной экосистемы (5:32). Подчеркнул что сейчас смартфон с Авророй это дополнительное устройство прежде всего для решения рабочих задач. Например для сотрудников, которые по работе постоянно перемещаются (курьер, представитель, почтальон, обходчик РЖД и т.д.), или сотрудников, которым важен защищённый обмен сообщениями на сертифицированном устройстве. На текущем этапе это не замена личному Android/iOS устройству.

Алексей даже мельком коснулся трудностей с портированием (34:00) и необходимостью использования драйверов или даже некоторых компонентов от Android для запуска Авроры. Что в принципе вполне ожидаемо и очевидно в связи с отсутствием полного цикла производства устройств. Но хорошо, что это не замалчивается. Помнится во времена Jolla Sailfish об этом старались не упоминать.

Амбиция делать с партнёрами смартфоны/планшеты для физиков у ОМП есть и они идут в этом направлении. Этому можно поспособствовать через программу бета-тестирования. Правда количество желающих в десятки раз превышает количество доступных для тестирования устройств. В ОМП понимают, что в текущих условиях зарабатывать в этом сегменте им будет сложновато. Поэтому в самом ближайшем будущем ждать телефоны на Авроре в продаже в условном МВидео пока не стоит. Будем следить за новостями.

Сделал видяшку с обзором Joint cybersecurity advisory (CSA) AA22-279A

Сделал видяшку с обзором Joint cybersecurity advisory (CSA) AA22-279A. Интересно будет ли фидбек от авторов документа. 😁

Новая потенциально горячая уязвимость CVE-2022-42889 (9.8 CVSS) в версиях Apache Commons Text с 1.5 до 1.9

Новая потенциально горячая уязвимость CVE-2022-42889 (9.8 CVSS) в версиях Apache Commons Text с 1.5 до 1.9. Proof-of-concept эксплоит в паблике, но про атаки вживую пока не пишут. Проблема может развиться в "Log4Shell а миниатюре".

Joint advisory AA22-279A (4/4)

Joint advisory AA22-279A (4/4)

3. Продетектированные типы уязвимостей.

Remote Code Execution
Command Injection
Arbitrary File Reading
Authentication Bypass
Path Traversal

Как видим все уязвимости очевидно критичные за исключением одного "Path Traversal":

Path Traversal - Citrix Application Delivery Controller (CVE-2019-19781)

Описание уязвимости не оставляет никаких возможностей для детектирования другого типа:

"An issue was discovered in Citrix Application Delivery Controller (ADC) and Gateway 10.5, 11.1, 12.0, 12.1, and 13.0. They allow Directory Traversal".

Этот же тип указывается в отчете AA22-279A: Citrix ADC CVE-2019-19781 Path Traversal

И только в описании эксплоита мы можем видеть, что это по факту RCE: "This tool exploits a directory traversal bug within Citrix ADC (NetScalers) which calls a perl script that is used to append files in an XML format to the victim machine. This in turn allows for remote code execution."

Что ж, это очередное напоминание о том, что жестко фильтроваться по типу уязвимости нельзя и доверять описанию из nvd тоже нельзя. Тип уязвимости может уточняться со временем, а изменения в NVD никто не вносит.

В части случаев Vulristics может помочь более точно определить тип уязвимости:

AA22-279A: Apache HTTP Server CVE-2021-41773 Path Traversal
Vulristics: Remote Code Execution - Apache HTTP Server (CVE-2021-41773)

Почему? Потому что в описании "If CGI scripts are also enabled for these aliased pathes, this could allow for remote code execution."

Но конечно Vulristics это не серебряная пуля и кроме ручного разбора публикаций об уязвимостях и эксплоитах тут ничего не придумаешь.

Также не могу не указать, что ещё для части уязвимостей Vulrisitcs определил типы уязвимостей более корректно в соответствии с описанием:

AA22-279A: GitLab CE/EE CVE-2021-22205 Remote Code Execution
Vulristics: Command Injection - GitLab (CVE-2021-22205) - Urgent [947]
"… which resulted in a remote command execution."

AA22-279A: Sitecore XP CVE-2021-42237 Remote Code Execution
Vulristics: Sitecore Experience Platform (XP) (CVE-2021-42237)
"… it is possible to achieve remote command execution on the machine."

AA22-279A: VMware vCenter Server CVE-2021-22005 Arbitrary File Upload
Vulristics: Remote Code Execution - VMware vCenter (CVE-2021-22005)
"…may exploit this issue to execute code on vCenter Server by uploading a specially crafted file."

AA22-279A: F5 Big-IP CVE-2022-1388 Remote Code Execution
Vulristics: Authentication Bypass - BIG-IP (CVE-2022-1388)
… undisclosed requests may bypass iControl REST authentication"

AA22-279A: Apache HTTP Server CVE-2021-41773 Path Traversal
Vulristics: Remote Code Execution - Apache HTTP Server (CVE-2021-41773)
"… this could allow for remote code execution."

AA22-279A: Apache CVE-2022-24112 Authentication Bypass by Spoofing
Vulristics: Remote Code Execution - Apache APISIX (CVE-2022-24112)
"… is vulnerable to remote code execution."

AA22-279A: Buffalo WSR CVE-2021-20090 Relative Path Traversal
Vulristics: Authentication Bypass - Buffalo WSR (CVE-2021-20090)
"… allow unauthenticated remote attackers to bypass authentication."

Поэтому не спешите доверять типу уязвимости из CISA Known Exploited Vulnerabilities Catalog и учитывать его при приоритизации.