Выбрать язык


Выбрать язык | Show only


Русский | English


воскресенье, 19 декабря 2021 г.

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

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


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

суббота, 20 ноября 2021 г.

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

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

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

среда, 8 сентября 2021 г.

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 от жертвы.


вторник, 18 мая 2021 г.

Фишинг на "Противостоянии" (Standoff)

Говорят, настоящую гордость художник испытывает, когда его картину не покупают, а воруют.

Было у вас когда-нибудь, что вы создаете команду на Standoff, участвуете несколько лет подряд, а через некоторое время ваши последователи создают фишинговую команду схожего звучания? 

А у меня было. Наша команда You Shall Not Pass участвовала в роли защитника с самого начала в Противостоянии, расширившись затем собственной командой SOC, а теперь наши последователи / фанаты / подражатели создали похожую. Но это не мы. 

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

О нашем участии в предыдущие годы можно прочитать в этом блоге по тегу PHDays.

По ссылке - наша команда и наш логотип, на картинке - фишинговая. Не перепутайте. 



суббота, 24 апреля 2021 г.

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

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

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

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


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

пятница, 2 апреля 2021 г.

Двухфакторная аутентификация глазами agile-хипстера

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

Почему я должен использовать двухфакторную аутентификацию?

Скоро аудит делается, да неспешно рекомендации пишутся. Неспешно, но емко и беспощадно.

пятница, 19 февраля 2021 г.

Он вам не SolarWinds! Epic Fail в виде TeamViewer для промышленных систем

Увидев новость на SecurityLab о том, что неизвестный хакер подкрутил показатели уровня щелочи в воде на водоочистной станции во Флориде, я решил поискать чуть больше информации.

В итоге, нашел новость на CSO Online, из которой можно понять следующее:

  • Терминал управления ICS имеет доступ в Интернет.
  • TeamViewer в компании разрешен.
  • Для управления терминалом ICS используется TeamViewer.
  • Процесс удаленного доступа к терминалу управления ICS не только возможен через Интернет посредством TeamViewer, но и толком не регламентирован.
  • Отсутствует автоматизированный контроль изменения критичных параметров концентрации веществ в воде.

Только ленивый не обсуждал SolarWinds, но беда пришла, откуда не ждали. 

Судя по документации, у TeamViewer есть различные локализуемые варианты внедрения, но для них все равно необходим доступ в Интернет. А значит, и возможность вмешательства в процесс управления системами с помощью TeamViewer извне.

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