Cisco IOS XE CVE-2023-20198

Раз уж в последние несколько дней ходит шум вокруг уязвимости Cisco IOS XE CVE-2023-20198, то позволю и себе высказаться на эту тему. Не буду пересказывать первоисточники, переводя на русский, хотя краткую выжимку рекомендаций дам.

Когда возникает подобная новость об уязвимости, в первую очередь у ИБшника и владельца зоопарка систем возникает вопрос: а что же у меня под угрозой?

Список платформ, работающих на Cisco IOS XE, можно найти по ссылке.

Как понять, что ваша платформа уязвима?

Когда ПДн собирают все, кому не лень

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

- Подскажите, где ближайший банкомат к станции метро такой-то?

- Как я могу к вам обращаться?

---

- Видел на сайте, что у вас в наличии автомобиль такой-то, по такой-то цене. Информация актуальна?

- Как я могу к вам обращаться?

---

Список можно продолжать очень долго. Когда-то я практиковал метод, при котором каждому новому ресурсу представлялся новым именем. Но имена быстро закончились, а вести таблицу было лень. Можно пробовать одно имя на целое направление (банки, автосалоны, магазины) - так таблица меньше. А можно вообще отвечать что-то типа:

- Как я могу к вам обращаться?

- Пока никак не нужно обращаться. Мне сейчас нужен только ответ на вопрос.

С той стороны может возникнуть замешательство, недоумение и прочие эмоции, кроме положительных, поэтому, кому не нравится такой поворот - метод не подойдет. Но какая-никакая эффективность у этого метода есть. Потом звонков меньше. Видать, пустое поле не особо заполняют, чтобы не возникало вопросов. Хотя, стоит учесть, что узнать имя человека по номеру телефона вполне легальным методом в большинстве случаев проблемы не составляет.

Но, кому не претит метод замалчивания имени - пользуйтесь.

Опровержейшн на утверждение о худшей профессии

Интересный высер от Business Insider, запроксированный сесуритулабом, прочитал я сегодня. Ну и, конечно, создал мем на эту тему, чтобы вы не унывали, дорогие представители одной из худших (оказывается) профессий по версии ИБшного портала.

Что на эту тему пишет первоисточник по-нерусски: "You spend a lot of time reviewing a lot of logs and then, just when you think you've solved a critical data breach, a new hacker erases all the good you've done, the world is not a better place and you are back at square one."

Конечно, если компания вместо создания собственного SOC либо покупки сервиса SOC нанимает аналитика, превращая в живой SIEM, то так себе его судьба, если не запилит автоматизированную корреляцию хотя бы на open source. Кстати, лет много назад я собеседовал человека, который как раз и был таким живым ArcSight'ом компании на тот момент. Дяденьке было 45+, и ничего.

Но если вернемся к инфе из Business Insider, то можно заметить, что цитата по-нерусски сгенерирована не кем-нибудь, а целой CEO of a tech career coaching service for women!

В отличие от остальных профессий из списка, Cybersecurity Analyst имеет уровни, и если в логе копается форензист либо threat hunter, то это уже всем логам лог. А они тоже аналитики кибербеза, но уже выбравшие специализацию. Правда, чтобы и на начальный уровень попасть, тоже нужно много чего знать. Тут да, легкий старт не выйдет.

Так что, пацаны, это работа для нас с вами. В обработке логов есть высший смысл и инструменты автоматизации. Если проникся - ты в игре.

Кибербез надо любить. Это мужская работа.

Мелкий бизнес и оборотные штрафы за утечку ПДн

Появилась новость о том, что теперь за утечку ПДн организации могут получать оборотные штрафы: от 5 до 500 млн рублей, или до 3% от годового оборота. И самый интересный вопрос: при принятии решения регулятор будет руководствоваться принципом "что больше", или "что меньше"?

Например, построил человек небольшой домик на 4 отдельных входа, и решил сдавать его, как гостевой, чтобы не простаивал зря. Зарегистрировался, как ИП (кстати, к ним это применимо?). Место живописное, но не особо раскрученное, поэтому установлена цена 5 000р за ночь за комнату, 20 000р за весь дом. Предпринимателю настолько сопутствовала удача, что каким-то чудом все секции были заняты каждую ночь в году.

Сколько заработает за 1 год такой бизнес в идеальном случае:

20 000р х 365 = 7 300 000р

Чтобы из этого получилась прибыль - нужно отнять разнообразные расходы.

Совсем не обрабатывать персональные данные такая организация не может, ибо обязана регистрировать посетителей и предоставлять информацию соответствующим регуляторам. Если работает в белую, конечно. И вдруг происходит утечка, о которой становится известно, и бизнесмену выставляется ай-яй-яй.

Указ №250 как драйвер ИБ в SMB

1 мая 2022 был подписан Указ Президента Российской Федерации № 250 "О дополнительных мерах по обеспечению информационной безопасности Российской Федерации". 

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

Если пристально взглянуть на перечисленные в п. 1 типы организаций, становится очевидно:

• Их количество исчисляется тысячами.
• Большая часть организаций имеют малые размеры и нецифровой профиль деятельности. 

В каком-нибудь региональном "Центре дезинфекции", задача которого - травить грызунов, с высокой вероятностью не ИБшник станет заместителем генерального директора, а на кого-то из существующих замов возложат эту честь. Более того, подшефное такому заму подразделение пойдет по последней строчке пункта б) из скриншота, разделив с боссом почетную функцию. И, вероятнее всего, это будет ИТ-подразделение. Возможно, состоящее из одного человека (того самого зама).

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

Самим же ИТ-специалистам придется взглянуть на поддерживаемые ими технологии под другим углом, если ранее не приходилось этого делать.

Посмотрим, что из этого получится.

Апдейтофилия. Уязвимости Heartbleed и Log4j

Все хорошо помнят 2014 год с открывшейся на теле набирающего обороты HTTPS уязвимости с идентификатором CVE-2014-0160, более известной, как Heartbleed. Аналогично запомнится декабрь 2021 года с набором уязвимостей в Apache log4j. Подробно на их описании и методах лечения останавливаться не буду, по ссылкам выше доступна вся необходимая информация. Больше хотелось бы обратить внимание на то, что в обоих случаях подвержены уязвимости оказались не все версии, а лишь часть их. 

Я отлично помню рекомендацию, которую в 2014 году сам же выкатил ИТ-специалистам: на уязвимых к Heartbleed системах после применения лекарства сменить ключи и пароли. То же самое стоило сделать на используемых мной средствах защиты.

По следам Робина Гуда

Кто не в курсе, недавно у одного из брокеров по имени Robinhood произошла утечка информации. Некто получил доступ к списку email-адресов порядка 5 млн пользователей, полные ФИО еще 2 млн пользователей. Несколько тысяч записей содержали номера телефонов. При этом номера банковских карт и социальной страховки не утекали, реализации идеологии сказочного персонажа не произошло. К чести службы ИБ брокера, они заметили этот инцидент. Судя по информации от Robinhood, утечка произошла в результате социальной инженерии, которую применили к сотруднику саппорта. 

Я, как и преобладающее большинство, не в курсе всей ситуации, но считаю, что некоторые организационно-технические меры могли бы помочь:

DDoS-атака TCP Reflected Amplification - причины и методы предотвращения

Недавно на конференции USENIX Security Symposium была опубликована статья под названием Weaponizing Middleboxes for TCP Reflected Amplification. До этого традиционно считалось, что атаки типа Reflected Amplification - побочный эффект использования протокола UDP. TCP казался абсолютно неуязвимым в связи с необходимостью верификации инициатора сессии методом "тройного рукопожатия". Оказалось, что Reflected Amplification с TCP не только возможен, но в некоторых случаях коэффициент усиления может быть практически бесконечным. 

Конечно, вольное переложение статьи на русский было уже предпринято такими порталами, как Securitylab.ru и xakep.ru, но позволю себе не только покритиковать их, но и представить свой вариант изложения сути исследования по TCP amp DDoS на русском языке. Для иллюстрации буду использовать слайды оригинальной презентации - уж слишком они хороши, чтобы придумывать что-то свое.

Атака типа amplification с использованием протокола на базе UDP при условии подмены адреса жертвы выглядит так:

За счет чего TCP считался неуязвимым к атакам reflected amp, хорошо показано на рисунке:

То есть, сценарий отправки SYN/ACK жертве возможен, но по способностям заполнения канала малоэффективен. Исследование показало, что подобную защиту можно обойти. И это не уязвимость протокола TCP, а недостатки сетевой реализации внедрения определенного класса сетевых решений.

В своем исследовании авторы используют такой термин, как middlebox - устройство с возможностями фильтрации, интеллектуальной обработки и перенаправления трафика. 

Middlebox'ами можно назвать:

• FW/NGFW
• IPS
• Proxy
• Reverse proxy
• WAF
• DPI
• Censor

Перечень не исчерпывающий. 

Условия, которым должен соответствовать middlebox, чтобы его можно было использовать в атаке TCP Reflected Amplification:

• Имплементация с поддержкой асимметричной маршрутизации, подразумевающая обработку пакетов только в одном направлении.
• Сконфигурирована отправка/перенаправление на страницу при определенных условиях.
• Присутствует петля маршрутизации.
• Повторная отправка контента в случае получения RST-пакета в ответ на страницу блокировки.

То есть, архитектура, подразумевающая обработку TCP-сессий полностью на одном устройстве, либо с онлайн-обменом информацией о сессиях между участниками обработки трафика, не может быть использована в TCP amp-атаке. 

В норме, middlebox с поддержкой асимметричной маршрутизации должен увидеть в одном направлении в рамках одной сессии SYN, ACK и дальнейшие PSH+ACK. Опытным путем ученые определили, что завершающий тройное рукопожатие ACK не отслеживается. Вероятно, с целью экономии ресурсов. Проверено 5 возможных комбинаций пакетов с целью вызвать атаку TCP reflected amp на 184 middlebox'ах. 

Результаты описаны в таблице:

Флаги пакетов	Успешно	% успешности	Коэффициент усиления
[SYN; PSH+ACK]	128	69,6	7455
[SYN; PSH]	121	65,7	24
[PSH]	82	44,6	14
[PSH; ACK]	61	33,2	21
[SYN+payload]	21	11,4	527

При этом, главным корнем зла, как и в атаках "усиления" с использованием UDP, является возможность подмены IP-адреса отправителя в пакете. 

Бесконечное усиление может быть вызвано повторной отправкой middlebox'ом страницы с контентом на RST-пакет жертвы, отправляемый в ответ на нежданный пакет с данными вне существующей TCP-сессии. 

Также, если при внедрении была допущена ошибка, приводящая к петле маршрутизации - сам факт закольцовывания без некорректной обработки RST-ответа жертвы будет вызывать умножение количества пакетов, пока не иссякнет TTL. Если же TTL в петле по какой-то причине регенерируется - коэффициент усиления может быть бесконечным.

Для того, чтобы минимизировать риск участия оборудования государственной цензуры в атаках TCP reflected amplification, стоит обратить внимание на такие меры:

• Архитектура, подразумевающая контроль трафика в обе стороны. Зачастую невозможно на больших транзитных сетях провайдеров.
• Уменьшение размера ответа. Например, вместо выдачи всей страницы, отправлять только redirect с адресом страницы блокировки.
• ACL. Обрабатывать запросы, приходящие только из сетей своих клиентов на соответствующий интерфейс. Инициировать атаку можно будет только из сети клиента на адреса других клиентов, что минимизирует вероятность атаки и упростит поиск злоумышленника своей юрисдикцией.
• Удостовериться в отсутствии петель маршрутизации.
• Настроить middlebox на отсутствие отправки страницы блокировки в ответ на каждый RST-пакет от жертвы, либо устранить дефект ПО.
• Настроить конечные устройства не отправлять RST в ответ на непонятные пакеты, во избежание штормовой реакции middlebox'а на RST от жертвы.

Внедрение WAF. Взгляд архитектора

Еще 8 лет назад я изучил различные варианты внедрения WAF в инфраструктуру компании для защиты ее веб-ресурсов. Ни вендор, ни интегратор тогда не смогли мне толком ответить, каким образом правильнее интегрировать WAF под мои требования, только твердили "vendor-recommended design". В итоге пришлось делать все самому, причем на тот момент выбранный вариант шел вразрез с рекомендованным дизайном вендора (только через пару лет вендор изменил свой дизайн на тот, что выбрал я). Иногда я рассказываю на внешних или внутренних конференциях, как правильно выбрать архитектуру, отвечаю на возникающие вопросы, чтобы мой опыт пригодился и другим. Несколько дней назад я понял, что тема актуальна и до сих пор, поэтому решил написать эту статью. 

Составлю эту статью в основном из скриншотов слайдов презентаций, с которой выступал на разных конференциях.

Вряд ли для кого-то это будет новостью, но дам вводное определение WAF своими словами:

Иногда можно услышать споры о том, что лучше использовать: WAF, IDS или IPS.

Звукоизоляция квартиры как вектор утечки при удаленной работе

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

• предотвращение
• усложнение
• удорожание

кибератак либо утечек. И это не считая неотключаемого логирования. Риск перехвата и модификации интернет-трафика решается посредством VPN, возможные варианты утечки информации из случайно услышанных разговоров через членов семьи минимизируются выделением отдельного кабинета (если есть возможность) либо переселением совещающихся по удаленке на время совещания в отдельную комнату.

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

Питч-сессия SOC v2.0: уровень организации онлайн-меропиятия

Участвовал сегодня в питч-сессии v2.0 «Опыт ошибок SOC: срывая покровы» (не договорили на SOC-форуме, впрочем, как и сейчас).

Казалось бы, чего можно интересного рассказать об онлайн-конференции по ИБ, после того, как сбился со счета выступлений в оффлайне? Наверное, удивить может только соотношение "ожидание" - "реальность".

Противостояние. Интервью защитника

Посвящается перенесенному мероприятию-2020.

- А вы безопасник?
- Да.
- Настоящий?
- Информационный.
- Ух ты. А как это?
- Как настоящий, только информационный.
- И в боевых действиях принимали участие?
- Не то, чтобы в совсем боевых, но было.
- Война, сражение?
- Противостояние.
- И страшно было?
- Бывало.
- А когда страшнее всего было?
- Когда понимаешь, что атакующие где-то пробились, но не понимаешь, где, и к тебе ли пробились.
- И что в этой ситуации вам придает сил?
- То, что атакующий может сам понимать еще меньше.
- Прям такая неразбериха на поле боя?
- Не то слово. Как Большой адронный коллайдер - если туда падает гаечный ключ, то разгоняется до такой скорости, что врезается сам в себя сзади.
- А на поле боя в одиночку выходили?
- Только со своей группой спецназа.
- Так опасно? Страшно было?
- Аккуратно перемещались по полю боя, и ничего, кроме мужества, не испытывали.
- А скажите, ведь в войнах всегда есть сторона, которой эта война выгодна. В вашем случае вы задумывались, ради чего все это?
- Не просто задумывался, а выяснил и все отлично знал.
- Да ладно! А можете рассказать?
- Есть, как минимум, один человек, который, умело манипулируя происходящим в киберпространстве, столкнул противоборствующие стороны.
- И ему это выгодно?
- Чрезвычайно.
- И ему до вас, как до людей, никакого дела нет?
- Да видал он нас на пуфиках в черных тапочках.
- А почему же вы идете у него на поводу?
- Умеет манипулировать.
- А что будет, если вы не будете участвовать?
- Скучно будет.
- Кажется, я понимаю: вы из тех, кто, вкусив крови, уже не может остановиться.
- В последний раз было не до крови, воды еле раздобыли.
- И последний вопрос: как долго вам приходилось сидеть в засаде, терпеть лишения и воевать, чтобы в итоге победить?
- Если на противостоянии, то почти двое суток.
- А что, и дольше бывало?
- Да.
- И сколько?
- 512 часов.

Измерение эффективности SOC. Время обнаружения и отражения атаки

В продолжение предыдущих двух статей об использовании SOC для контроля безопасности бизнес-процессов и зоне покрытия SOC как метрике эффективности, стоит обратить внимание на такой немаловажный фактор, как время реакции SOC на произошедший инцидент. И важно не только время реагирования, но и время отражения атаки. 

Измерить можно тем же методом, что и зону покрытия: провести пентест своими либо наемными силами. Делим команды на Red Team и SOC. Первые - не скрываются. Вторые - бдят и отражают атаки. Обе команды до старта не знают о местонахождении противника.

Обе команды предоставляют отчеты о проведенной работе. При этом фиксируют время (синхронизация команд с одним NTP-сервером и один часовой пояс в отчете).

Измерение эффективности SOC. Зона покрытия

Как уже писал в предыдущей статье, во вторник 17.12.2019 я выступал на конференции "Ведомостей" с докладом на тему "Технологии настоящего и будущего в центрах мониторинга ИБ (SOC)". 

Выступление условно можно было поделить на 3 части: 

1. Вводная.
2. Реализация контроля безопасности бизнес-процессов с помощью SOC.
3. Измерение эффективности SOC.

Пункты 1 и 2 я описал в предыдущей статье, на которую ведет ссылка в списке. Здесь подробнее остановлюсь на том, как можно измерить зону покрытия SOC. 

Логично, что SOC должен покрывать все 100% защищаемой инфраструктуры, будь то IT-, OT- или иные технологии. Но как это проверить, особенно если нет уверенности в том, что IT/OT-подразделения сами владеют всей информацией?

SOC для безопасности инфраструктуры и бизнес-процессов

Во вторник 17.12.2019 я выступал на конференции "Ведомостей" с докладом на тему "Технологии настоящего и будущего в центрах мониторинга ИБ (SOC)". В отличие от многих других моих выступлений, здесь необходимо было сфокусироваться не на технической стороне вопроса, а на взаимосвязи информационной безопасности с бизнесом. При этом, конечно, донести возможность технической реализации того или иного действия. 

Выступление условно можно было поделить на 3 части: 

1. Вводная.
2. Реализация контролей безопасности бизнес-процессов с помощью SOC.
3. Измерение эффективности SOC.

Поскольку регламент давал на все не более 10 минут, пришлось постараться вложить информацию в минимум слайдов и слов. Поэтому осталось и для блога. Опишу 1 и 2 части.

У многих сложилось мнение, что область применения SOC - исключительно инфраструктура, и что-то, полезнее антивируса либо событий операционной системы, мониторить не получится. Отчасти это правда, поскольку SIEM - технологическое ядро SOC - имеет готовые интеграционные модули (коннекторы, коллекторы и т. п. вендорспецифичные термины) в основном для сбора информации с операционных систем, сетевых сервисов и средств защиты информации. И это объяснимо. Приведу в качестве примера слайд из своей презентации.

Если обратить внимание на рисунок и попытаться подсчитать разнообразие возможных источников на каждом слое, то можно заметить, что на уровне приложений их количество резко возрастет.

Основы сетевых технологий. Broadcast-unicast-multicast-anycast

В классе 30 человек. 
Учитель ведет перекличку:
- Абрамов Валера!
- Я!
Протокол переклички основан на широковещательных (broadcast) запросах. Класс очерчивает пределы широковещательного домена. Ответ тоже носит широковещательный характер, поэтому диалог слышат все.

- Забирай тетрадку.
Валера идет за тетрадкой к столу учителя, забирает ее, уносит за свое место и читает. 
Это unicast.

Учитель замечает, что один из учеников занимается ерундой, и окликает его:
- Саша!
Поскольку в классе три Саши, все они поворачиваются к учителю. 
Это multicast запрос к тем, кто отзывается на имя Саша.

В классе включается громкоговоритель, и из учительской транслируется:
- Сергей Смирнов, подойди в кабинет директора.
В школе 30 аудиторий по 30 человек, в каждой пятой аудитории есть Сергей Смирнов. 
В итоге, 6 школьников устремляются в кабинет директора в ответ на anycast запрос.

Все персонажи вымышлены, любое совпадение с реальными людьми - случайность.

Основы сетевых технологий. Incapsulation

Все в курсе, как перевозят через границу что-то очень небольшое, дорогое и запрещённое.

Это инкапсуляция.

Основы сетевой безопасности. Network Segmentation

Если вы едете в новом поезде метро, который можно пройти от начала до конца, и в него заходит бомж - потенциально он может провонять весь состав. В старых - только один вагон.
Так же и с сегментацией сети.

Основы сетевых технологий. Unicast vs broadcast

Открываешь бутылку, пьешь минералку - это unicast.
Открываешь бутылку, поливаешь голову - это broadcast. При этом ловишь ртом воду, чтобы отхлебнуть - снифаешь broadcast.

Противостояние-2019 глазами защитника и SOC

Наша команда "You Shall Not Pass" в этом году уже четвёртый раз принимает участие в "Противостоянии", которое проводится в рамках конференции Positive Hack Days. Фактически, единственные, кто в роли защитников играет в эту игру с самого начала её существования. В этом году мы выступили в составе двух команд: телеком-защита и SOC. Обе команды назывались "You Shall Not Pass".

Наш SOC на PHDays мониторил инфраструктуру двух команд: собственной и клиента. В реальной жизни все происходит аналогично: у нашей компании есть корпоративный SOC, который обеспечивает защиту своей инфраструктуры, и коммерческий, предоставляющий услуги SOC внешним клиентам. По сути, для нас Противостояние каждый год является своего рода киберучениями, где мы тестируем свои методы защиты от атак, которые на тестовой среде не воспроизведешь, а на продуктиве - слишком рискованно. Поэтому псевдопродуктив площадки очень в этом помогает.