Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: решения по уязвимостям

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

Про SSVC и конкретно про недавно вышедший SSVC Guide от CISA: решения по уязвимостям.

Идея там в следующем: а давайте на основе некоторого опросника (да, очередного) будем определять что нам делать с конкретной уязвимостью. Какие это могут быть решения:

1. Отслеживать (Track). В настоящее время каких-то особых действий по уязвимости не требуется. Организация продолжает отслеживать новую информацию по уязвимости и проводить её переоценку. CISA рекомендуют устранять такие уязвимости в рамках стандартных сроков обновления.

2. Внимательно отслеживать (Track*). Уязвимость содержит определенные характеристики, которые могут потребовать более тщательного мониторинга изменений. CISA рекомендуют устранять такие уязвимости в рамках стандартных сроков обновления.

3. Уделять внимание (Attend). Уязвимость требует внимания со стороны нижнего уровня менеджмента (organization's internal, supervisory-level individuals). Необходимые действия могут включать запрос помощи или информации об уязвимости, приводить к публикации внутренних и/или внешних нотификаций об уязвимости. CISA рекомендуют устранять такие уязвимости быстрее стандартных сроков обновления.

4. Действовать (Act). Уязвимость требует внимания со стороны нижнего уровня менеджмента и ТОПов (organization's internal, supervisory-level and leadership-level individuals). Необходимые действия включают запрос помощи или информации об уязвимости, а также публикацию внутренних и/или внешних нотификаций об уязвимости. Как правило, внутренние группы встречаются и договариваются как будут реагировать на эту уязвимость, а затем выполняют согласованные действия. CISA рекомендуют устранять такие уязвимости как можно скорее.

Относительно американских уровней менеджмента я не особо в курсе, а гуглится там противоречивое, но в целом оно как-то так.

Как я понимаю о чем это вообще

Кажется во многих организациях, если не во всех, есть чатики безопасников, куда кидаются уязвимости для обсуждения. И там уже сообща решается вопрос стоит ли подрываться и оперативно фиксить уязвимость, или оно в регулярном процессе само зафиксится. Очевидно какие-то уязвимости не особо критичные и вряд ли будут эксплуатироваться в реальных атаках (множество вариаций Meltdown и Spectre например). По каким-то с ходу непонятно, но выглядит подозрительно и надо бы за ними приглядывать (недавняя SQLite RCE CVE-2022-35737). Какие-то очевидно нужно оперативно брать в работу, т.к. явно опасно и в целом понятно как устранять (какая-нибудь очередная RCE в Exchange или AD). А для некоторых уязвимостей нужно на ТОПов выходить, запускать их отдельными треками и патчить пожарном режиме (Log4Shell, MS17-010).

В принципе процесс это знакомый и естественный. Но так сразу и не скажешь по какому принципу в таком чатике принимаются решения по конкретной уязвимости, "экспертная оценка" во всей красе. И цель SSVC, насколько я могу судить, этот процесс несколько формализовать.

В следующей части начнем разбираться на основании чего решение принимается. И т.к. недавняя ФСТЭКовская "Методика оценки уровня критичности уязвимостей программных, программно-аппаратных средств" тоже +- про это, хотя и реализация совсем другая, напрашивается некоторое сравнение / размышление как мы до жизни такой дошли. Stay tuned.

Про восстановление внезапно отъехавшего Xiaomi Redmi Note 11 (2/2)

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

Про восстановление внезапно отъехавшего Xiaomi Redmi Note 11 (2/2).

Какие выводы сделал:

1. В сторону Xiaomi и Qualcom - безусловное фи. Таких массовых сбоев быть не должно, вендор должен это фиксить сам, а не отмалчиваться. Это случилось потому, что китайцы такие китайцы, а с другими вендорами такое произойти не может? Не уверен, но решайте сами.

2. "Developer options" и "USB debugging" с аппрувом на рабочей машине должны быть активированы заранее на всякий случай.

3. Важные файлы должны храниться на sd-карте, тогда их просто будет достать, если телефон окирпичится.

4. Бэкапы? Безусловно это нужно делать каким-то образом.

5. Целиком полагаться на телефон дело такое себе. А если бы на телефоне был электронный билет который нужно было срочно предъявить? А если бы сегодня был не выходной, а надо было активно передвигаться на такси? Есть повод поразмышлять о зависимости от гаджетов и необходимости резервирования.

Про восстановление внезапно отъехавшего Xiaomi Redmi Note 11 (1/2)

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

Про восстановление внезапно отъехавшего Xiaomi Redmi Note 11 (1/2).

И на старуху бывает проруха, как сказала польская красавица Инга Зайонц через месяц после свадьбы с другом моего детства Колей Остен-Бекеном. (с)

Сегодня я проснулся и обнаружил, что мой телефон Xiaomi Redmi Note 11 ровно через 11 секунд после разблокировки экрана сваливается в черный экран с крутящимся белым значком загрузки. Через пару минут в таком режиме телефон открывает меню MIUI 5.0 Recovery Mode. И так постоянно. Я перепробовал различные варианты загрузки системы (опцией из Recovery Mode, по тайм-ауту из Recovery Mode, загрузка после полного выключения, после перезагрузки, загрузка в Safe Mode), но ситуация та же - стабильная работа до разблокировки экрана, потом 11 секунд и снова сваливается в черный экран.

Учитывая, что на xda-developers есть свежий топик от 5 ноября с описанием ровно такой же проблемы и 7 страницами обсуждения, это массовый сбой, связанный с сервисом com.qualcomm.location.

"We now know the cause of the issue thanks to Reddit user pxbrz, and a fix (easier if your phone has USB Debugging enabled, if not you'll have to try to enable it as fast as you can before the reboot): One of Qualcomm's processes for the phone's location (called com.qualcomm.location) crashed and then rebooted itself when it did, but didn't clean up the ram, which made the phone crash by a lack of accessible memory. To fix it, you can use the following commands with adb:
adb shell
pm uninstall -k --user 0 com.qualcomm.location
Then it should be fixed (you'll lose location services until you update the phone obviously)."

USB debugging у меня был выключен. Можно ли включить USB debugging за 11 секунд? Я старался и у меня не получилось. Вот что я делал:

Этап 1. Включаем "Developer options"
1. Разблокируем экран
2. Находим шестеренку с настройками и жмем на неё
3. Жмем на "About Phone"
4. Проворачиваем вниз к "All specs" и заходим
5. Барабаним по MIUI version пока не получим "You are now a develper"

На это уходит секунд 10, потом отваливаемся в reboot, снова попытка

Этап 2. Включаем "USB debugging"
1. Разблокируем экран
2. Находим шестеренку с настройками и жмем на неё
3. Проворачиваем на "Additional settings" (провернуть до конца, вторая опция сверху) и заходим
4. Проворачиваем на "Developer options" (провернуть до конца, посередине экрана) и заходим
5. Находим "USB debugging" (пролистнуть примерно на второй экран), переводим в ок
6. Проставляем галку в warning-e "I am aware" и жмем ок …
Ну как жмем, не успеваем нажать, потому что кнопка блокируется warning-ом как раз на 10 секунд. 🤬

Конечно те, кто поставили туда этот ворнинг вряд ли предполагали, что людям может потребоваться включить USB debugging очень быстро. Но цензурных слов у меня для них нет.

Здесь я загрустил и пришел к выводу, что придется делать factory reset как минимум чтобы включить USB debugging. 😔

К счастью, выяснилось, что если за 10 секунд разблокировать экран и аппрувнуть подключение для передачи данных к компьютеру, то все то время пока на черном экране крутится белый значок загрузки есть время (минуты 2 точно) , чтобы забрать файлы с телефона. Так что нужные файлы я забрал, но настройки приложений потерял.

После ресета подключил USB debugging и без особых проблем удалил com.qualcomm.location

$ adb shell
spesn:/ $ pm uninstall -k --user 0 com.qualcomm.location
Success
spesn:/ $

Пока работает. Посмотрим что будет дальше.

Про Microsoft Digital Defense Report 2022 (2/2)

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

Про Microsoft Digital Defense Report 2022 (2/2)

Про Microsoft Digital Defense Report 2022 (2/2).

Теперь на что можно обратить внимание.

1. Неплохая схема "Understanding the ransomware economy" на 11 странице и вообще раздел про рансомварь норм. "Существуют отдельные организации, которые создают вредоносные программы, получают доступ к жертвам, развертывают программы-вымогатели и ведут переговоры о вымогательстве". Занимательно.
По нашей теме: "В 68% затронутых организаций не было эффективного процесса управления уязвимостями и исправлениями, а высокая зависимость от ручных процессов по сравнению с автоматическим исправлением привела к критическим уязвимостям. Производственная и критическая инфраструктура по-прежнему испытывает трудности с обслуживанием и исправлением устаревших систем операционных технологий (OT)."
Лол, а в 32% затронутых организаций был эффективный VM процесс и все равно пошифровали? Я бы на такие посмотрел. 🙂 Рекомендации по борьбе с рансомварью не сказать, что какие-то новые, но в целом толковые.

2. На 26 странице раздел про атаки на роутеры неплохой со схемами атак.

3. Раздел "Nation State Threats" это один сплошной фейспалм. Но, закрыв глаза на недоказуемые геополитические набросы, можно выделить интересное по нашей теме. "Ключевой тактикой [атак] стало выявление и быстрое использование незакрытых уязвимостей. Быстрое развертывание обновлений безопасности является ключом к защите." "В среднем требуется всего 14 дней, чтобы эксплойт стал доступен в дикой природе после того, как информация об уязвимости была публично раскрыта". Это выглядит как манипуляция, т.к. для подавляющего большинства уязвимостей ни эксплуатации вживую, ни эксплоитов не появляются. Но допустим.

4. Вынесу как отдельный пункт признание МS на странице 39, что относительно новая политика Китая, регулирующая порядок раскрытия информации об уязвимостях, самым положительным образом сказалась на информированности китайских государственных структур. Там конечно приводятся всякие голословные обвинения в offensive активностях, которые внимания не заслуживают. А вот то самое китайское "Положение об администрировании уязвимостей безопасности сетевых продуктов" внимание очень даже заслуживает, надо будет его отдельно разобрать. Если американцы так возмущаются, значит хорошие сапоги, надо брать (с).

5. Рекомендации относительно 0day уязвимостей неплохие. "Уделите особое внимание исправлению уязвимостей нулевого дня сразу же после их выпуска; не ждите, пока цикл управления исправлениями будет развернут. Документируйте и инвентаризируйте все аппаратные и программные активы предприятия, чтобы определить риски и быстро определить где нужно патчить."

6. Страница 53. "Нам срочно нужна последовательная глобальная система, в которой приоритет отдается правам человека и которая защищает людей от безрассудного поведения государства в Интернете." Лол, лучше б напомнили кто MS17-010 не зарепортил, а использовал втихую, и у кого потом EternalBlue утек. 🙃

7. На 64-ой странице рекомендации по IOT снова про патчинг. "Обеспечьте надежность устройств, установив исправления, изменив пароли по умолчанию и порты SSH по умолчанию." "Как и в других системах, в прошивке устройств IoT/OT широко использовались библиотеки с открытым исходным кодом. Однако устройства часто поставляются с устаревшими версиями этих компонентов. В нашем анализе 32 процента образов содержали не менее 10 известных уязвимостей (CVE), оцененных как критические (9,0 или выше). Четыре процента содержали не менее 10 критических уязвимостей старше шести лет."

8. На странице 97 пишут, что браузеры тоже не патчат "Изучив критическую уязвимость, затронувшую 134 версии набора браузеров (set of browsers), мы обнаружили, что 78 процентов, или миллионы устройств, по-прежнему используют одну из уязвимых версий через девять месяцев после выпуска исправления."

Про Microsoft Digital Defense Report 2022 (1/2)

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

Про Microsoft Digital Defense Report 2022 (1/2)

Про Microsoft Digital Defense Report 2022 (1/2).

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

Дорогие IT-шные френды из РФ, если вы прямо сейчас не занимаетесь активным выпиливанием продуктов MS из инфраструктур ваших компаний, вы зря это не делаете. MS давно уже в открытую пишут, что РФ это угроза с которой корпорация помогает бороться. Как и с Китаем, Ираном и Северной Кореей. Это давно уже не нейтральный вендор, а часть американской государственной машины. В моменте нужно конечно продолжать продукты MS обслуживать, патчить и т.д. Но тренд должен быть однозначный на минимизацию использования.

Tom Burt, MS Corporate Vice President, заканчивает свое вступление в отчете так: "Мы надеемся вызвать чувство безотлагательности (urgency), чтобы читатели приняли немедленные меры (immediate action) на основе данных и идей, которые мы представляем как здесь, так и в наших многочисленных публикациях по кибербезопасности в течение года." У меня такие отчеты, в которых Россия упоминается 160 раз на 114 страницах отнюдь не в позитивном ключе (Китай, для сравнения, 73) вызывают желание безотлагательно и немедленно выполнять меры, чтобы инсталляций продуктов настолько политизированного американского вендора стало вокруг как можно меньше.

Новое чтиво на выходные по нашей теме от американцев из CISA "Stakeholder-Specific Vulnerability Categorization Guide", то есть руководство по классификации уязвимостей для конкретных заинтересованных сторон

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

Новое чтиво на выходные по нашей теме от американцев из CISA "Stakeholder-Specific Vulnerability Categorization Guide", то есть руководство по классификации уязвимостей для конкретных заинтересованных сторон.

"Целью SSVC является помощь в определении приоритетности устранения уязвимости на основе воздействия, которое ее эксплуатация может оказать на конкретную организацию (организации)."

Ознакомимся 🙂

Про кейс Cisco Meraki и 12345-Sanctions

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

Про кейс Cisco Meraki и 12345-Sanctions.

Для тех, мимо кого инфоповод прошел: Cisco Meraki это сетевые устройства, в основном роутеры, с управлением из Public Cloud. Позиционируются в основном для компаний, но используется и домашними пользователями. Так-то идея интересная. Заходишь в облачный сервис и видишь какое хозяйство у тебя развернуто, насколько оно обновлено, настроено и т.д. А то, что ты своим устройствами рулишь через вендорское облако, так и какая разница. Это ведь вендор-то какой уважаемый, международный! Так ведь? 😏

Для пользовалей Cisco Meraki в России это закончилось тем, что устройства поблочились. Это было предсказуемо и это не особо новость. Новость в другом: Cisco Meraki обвиняют в том, что они умышленно удаленно добавили в роутеры пользователей в России открытую сеть с SSID вида «12345-Sanctions». Таким образом любой человек мог подключиться к устройству по Wi-Fi и получить доступ в сеть, где это устройство было установлено. Это тоже самое как если бы производитель умных электронных замков для дверей вдруг решил удаленно открыть двери своих пользователей в определенной стране. Нате, получите санкцию! Аналогия полная. В случае с дверью злоумышленник может что-то украсть из квартиры или наоборот подкинуть. В случае с сеткой критичные данные пользователя могут утечь, а с его IP-шника может быть сделано что-то нехорошее и он потом долго-долго будет доказывать, что ни при чём.

Итак, обвинения серьезные. Выдвинул их бывший сотрудник Cisco Виктор Платов (инженер-консультант по беспроводным решениям Cisco, системный инженер-консультант по направлению Mobility, CCIE, более 15 лет работы в компании). Я почитал несколько источников. Самый полный набор ссылок на текущий момент в посте на Хабре. Можете зайти, тоже почитать и сделать какие-то выводы для себя.

Комменты я тоже почитал:

1) На реддите и других западных площадках в основном злорадствуют в духе "так этим русским и надо за…" чего-нибудь. На пару десятков таких комментов попадаются редкие технические вопросы по делу и размышления, что создание публичного подключения Wi-Fi вендором это жесть и такое может произойти не только с русскими.
2) На Хабре в комментах в основном просят пруфов. И в этом весь цимес! Потому что в случае, когда вы отдали контроль над устройством третьим лицам сложновато становится доказать, что вы не врёте и не наговариваете на бывшего работодателя например. Могли же ещё и просто конкретного человека поломать и сделать ему такие настройки. Чего сразу на уважаемого вендора-то думать?! В аналогии с замком в двери это когда вы пришли домой, дверь открыта, квартиру обнесли, замок исправен. Вы можете сказать, что когда уходили точно заперли дверь, но как вы это докажете? Дубликаты ключей есть у консьержа и он к вам в квартиру периодически заходит по каким-то делам (вы ему зачем-то разрешили), у него на вас зуб, он мог умышленно оставить дверь открытой. Но как вы докажете, что он тут замешан? В самом деле, где пруфы, Билли? Есть и другие комменты с подтверждением аналогичных проблем с "12345-Sanctions", но их оставили недавно зарегистрированные пользователи - не убедительно.
3) Также был коммент, что Cisco Meraki в России официально не продавались. Поэтому пострадали пользователи серых устройств или бетатестеры из бывших сотрудников Cisco. Типа тю, это же ненастоящие клиенты, несчитово. Тоже штришочек и привет любителям серых устройств от западных вендоров.

В общем, собираясь управлять своими устройствами через Public Cloud, имейте ввиду возможные риски, взвесьте все за и против. И про Cisco тоже имейте ввиду и не забывайте им пожалуйста. 😉