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

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

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

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

20 000р х 365 = 7 300 000р

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

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

По следам The Standoff (2022). Год фишинга

Многие впервые обо мне узнали как раз из публикаций о ходе самых первых Противостояний 2016-2019 годов, и помнят меня, как лидера команды You Shall Not Pass (не путать с новой командой Your shell not pass - об этом фишинге или совпадении я уже писал). За 2016-2019 годы мы прошли интересный путь как команда защитников, команда SOC телеком-оператора и Интернет-провайдера, и как почти партнеры в организации The Standoff с командой Миши Левина (распорядитель игр тех годов). Много у нас было споров и при подготовке, и в ходе Противостояний, но сейчас это все вспоминается с улыбкой. 

В этом году я смотрел на Противостояние, как зритель. Поделюсь наблюдениями и сравнением с тем, как было "при мне".

Указ №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 от жертвы.

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

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

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

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

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

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

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