Каждый безопасник должен держать руку на пульсе и быть в курсе значимых публикаций и презентаций по нашему с тобой профилю. Не всем удается постоянно путешествовать по миру и посещать хакерские конференции, но с некоторых пор для наших подписчиков это перестало быть проблемой.
Зомби-расширения Chrome захватывают интернет
16 апреля 2016 года армия ботов штурмовала серверы Wix, создавая новые аккаунты и публикуя в массовом порядке теневые веб-сайты. Атака велась вредоносным расширением браузера Chrome, которое в результате самораспространения было установлено на десятках тысяч девайсов. Этот базирующийся на расширениях бот использовал Wix’овую платформу веб-сайтов и Facebook’овский мессенджер — для самораспространения среди пользователей этих интернет-сервисов. Два месяца спустя та же самая атака повторилась. На этот раз злоумышленники инфицировали всплывающие уведомления Facebook’а — так, чтобы при клике по этому уведомлению управление передавалось на вредоносный JSE-файл, который устанавливал контрабандное расширение в Chrome-браузере жертвы. Затем это контрабандное расширение эксплуатировало Facebook’овский мессенджер еще раз — теперь уже чтобы распространить себя еще большему числу жертв.
Анализируя эти две бот-атаки, поражаешься их неуловимости, а особенно тому, как они обходят веб-ориентированные системы обнаружения ботов. Однако это не должно удивлять, поскольку легальным расширениям браузера позволено многое: отправлять сообщения в Facebook, создавать веб-сайты в Wix, да и вообще выполнять любое действие от имени пользователя. С другой стороны, контрабандные вредоносные расширения в Google Web Store и их эффективное распространение среди большого количества жертв, подобно двум описанным выше атакам, превращают Google Web Store в зону боевых действий.
Кроме того, совсем недавно было обнаружено, что несколько популярных расширений Chrome уязвимы для XSS. Тому самому XSS, которому подвержено большинство веб-приложений. Причем в случае с браузерными расширениями последствия от XSS могут быть куда более разрушительными, чем в случае с традиционным злоупотреблением XSS на веб-сайтах. Яркий тому пример — расширение Adobe Acrobat для Chrome, которое 10 января 2016 года было по-тихому установлено компанией Adobe на 30 миллионов компьютеров. DOM’овская XSS-уязвимость, найденная в этом расширении, позволяла злоумышленнику создавать контент, запускающий JavaScript-код от имени этого Adobe’овского расширения.
В докладе рассказывается, как подобные изъяны приводят к полному и постоянному контролю над браузером жертвы, превращая легальное расширение в зомби. Кроме того, докладчик проливает новый свет на две атаки, упомянутые в начале описания доклада. Демонстрирует, как злоумышленник может использовать аналогичные техники для эффективной доставки вредоносной полезной нагрузки к новым жертвам, через популярные социальные платформы и таким образом создавать в интернете мощнейшие бот-сети.
Атака на браузерные расширения по обходным каналам
Все наиболее востребованные браузеры поддерживают механизм расширений. Поскольку браузерные расширения тесно связаны с браузерным окружением, они в последнее время стали привлекательным для злоумышленников объектом. С помощью механизма расширений злоумышленники уже давно собирают конфиденциальную информацию, просматривают историю поиска, воруют пароли. Все эти свои находки злоумышленники затем используют для очень серьезных целенаправленных атак.
В современных браузерах теоретически есть контрмеры, которые защищают расширения и их ресурсы от доступа к ним со стороны третьих лиц. Однако все эти контрмеры грешат одним из двух изъянов: либо их недостаточно, либо они реализованы некорректно.
В этом докладе представлена атака на браузерные расширения по обходным каналам, как раз направленная против настроек контроля доступа. Данная атака обходит даже самые современные защитные механизмы, во всех популярных браузерах, в том числе Chromium, Firefox, Microsoft Edge, Safari.
Также в докладе демонстрируются разрушительные последствия от применения плохой практики программирования, из-за которой большинство ныне существующих браузерных расширений очень уязвимы.
Как оценить уровень докладов на хакерских конференциях?
Эксплуатация одной и той же SQLite-уязвимости на разном софте
SQLite широко используется в качестве встроенной БД для локального/клиентского хранилища в прикладном софте, таком как веб-браузеры и мобильный софт. Как реляционная БД, SQLite уязвима для SQL-инъекций. Эксплоитами SQL-инъекций сегодня уже мало кого удивишь. Поэтому в докладе сделан акцент на ошибки повреждения памяти в SQLite. Обычно эти ошибки не считаются серьезными проблемами кибербезопасности, и предполагается, что они вряд ли будут эксплуатироваться. Однако в этом докладе описаны несколько вариантов повреждения памяти через удаленный доступ, чтобы показать, что такой тип атак представляет для SQLite серьезную опасность.
Экскурс в SQLite-эксплоиты начинается с WebSQL. БД WebSQL — это веб-интерфейс для хранения данных, доступ к которым может быть получен посредством SQL-запросов. Хотя рабочая группа W3C прекратила развивать эту спецификацию в 2010 году, многие современные браузеры (в том числе Google Chrome, Apple Safari и Opera) все еще имеют в своей реализации обширную функциональность на основе SQLite.
В докладе рассмотрено несколько последних этапов в эволюции SQLite, рассказано, какое влияние эти этапы оказали на браузеры и каким исправлениям SQLite подвергалась на протяжении своей эволюции. Кроме того, в докладе представлены новейшие SQLite-уязвимости, которые докладчик использовал для компрометации Apple Safari. Этим новейшим уязвимостям подвержены абсолютно все браузеры, которые поддерживают БД WebSQL, в том числе браузерные компоненты WebView (Android) и UIWebView (iOS), которые широко используются в мобильном софте.
Чтобы показать, какими серьезными неприятностями может обернуться даже одна-единственная SQLite-уязвимость, в докладе приведено несколько примеров применения описываемого эксплоита против разных браузеров и платформ.
У многих языков программирования, в том числе PHP, Lua и Java, есть API для привязки к SQLite. Поэтому ошибки повреждения памяти в SQLite, помимо всего прочего, оказывают разрушительное влияние на функции безопасности этих языков программирования. В качестве примера в докладе продемонстрировано, как скомпрометировать PHP-движок через его SQLite-расширение, чтобы обойти ограничения безопасности, предусмотренные в PHP.
Новейшие примитивы и стратегии для проведения CSRF-атак
CSRF (Cross Site Request Forgery, межсайтовая подделка запроса) не теряет своей актуальности и остается неуловимой — из-за устаревшего кода, устаревших фреймворков, а также из-за того, что разработчики попросту не понимают сути этой проблемы, а если и понимают, то не знают, как от нее защититься. Докладчик в своем выступлении вводит примитивы и стратегии для проведения CSRF-атак, которые могут быть развернуты против любого веб-софта, использующего HTTP (в котором существует техническая возможность перехватывать и модифицировать HTTP-запросы и HTTP-ответы).
Современные фреймворки наконец-то стали предлагать эффективные решения для противодействия CSRF. Эти решения автоматически интегрируются в веб-софт и хорошо показывают себя в большинстве случаев. Однако множество старых приложений, а также новые приложения, которые либо не используют эти фреймворки вообще, либо используют их некорректно, по-прежнему подвержены CSRF.
Докладчик подробно разбирает, почему CSRF все еще жива, анализируя при этом примеры «полезной нагрузки», которая эксплуатирует конкретные проблемы в их различных вариациях. Докладчик проводит живую демонстрацию этих атак и показывает, как современные умные фреймворки пытаются защититься от них.
Далее докладчик показывает, как синтезировать рассмотренные примитивы в единое универсальное решение, способное проводить CSRF в подавляющем большинстве ситуаций. Объясняются ограничения умных фреймворков и эксплуатация этих ограничений. Под конец своего выступления докладчик рассматривает Same Site Cookies — новейшую технологию против CSRF — и объясняет, как и почему описанные методики распространяются и на эту технологию.
Злоупотребление веб-хуками — для C2 (Command and Control)
Хакер проник за периметр. Разумеется, он хочет провести эксфильтрацию, скачать утилиту или выполнить команду на своем C2-сервере. Но вот проблема: в каждом из этих случаев ему необходимо установить с C2-сервером связь, а такая возможность заблокирована. Генерируемый хакером DNS-трафик и ICMP-трафик мониторятся. Доступа к облачным хранилищам нет. Конечно, злоумышленнику удалось доставить внутрь периметра фронтенд-компонент своей хакерской утилиты, но в результате он видит, что она не может преодолеть заслон контентного прокси-сервера, который контролирует доступ к внешним сайтам. Многим взломщикам доводилось бывать в такой переделке, и выпутаться из нее помогают альтернативные способы наладить исходящее подключение к сети. В докладе представлена техника налаживания такой связи посредством HTTP-колбэков: эксплуатация списка «доверенных сайтов» для содействия в работе с внешним C2-сервером через веб-хуки.
Докладчик кратко рассказывает, что такое веб-хуки и как их использовать. Затем он объясняет, как можно приспособить «одобренные сайты» в качестве посредника для C2-коммуникации, передавать данные, отдавать асинхронные команды в режиме реального времени. И все это в обход контентных прокси, без лишних цифровых следов! Под конец докладчик демонстрирует авторский инструмент, который автоматизирует описанные в докладе техники.
Новое поколение SSRF-атак: эксплоиты для URL-парсеров самых востребованных языков программирования
Докладчик демонстрирует принципиально новую технику применения SSRF-эксплоитов (Server Side Request Forgery, подделка запроса на стороне сервера). Эта техника значительно расширяет поверхность SSRF-атак и позволяет обходить даже самые современные SSRF-контрмеры. Описываемая техника представляет собой комбинированный подход, основой которого служит автоматический поиск специфических 0day-уязвимостей во встроенных библиотеках языков программирования. Автоматический поиск 0day-уязвимостей ведется при помощи авторской утилиты для фаззинга, которая фокусируется на поиске только тех уязвимостей, которые обусловлены несогласованностью действий URL-парсеров и URL-запросов. Проблема этой несогласованности фундаментальна, и она свойственна встроенным библиотекам всех языков программирования, в том числе Python, PHP, Perl, Ruby, Java, JavaScript, Wget и cURL.
Таким образом, весь веб-софт, разработанный с применением этих языков и встроенных библиотек, потенциально уязвим для нового поколения SSRF-атак. В том числе WordPress (на долю которого приходится 27% интернета), vBulletin, MyBB и GitHub. Во всех этих веб-приложениях докладчик обнаружил 0day-уязвимости, связанные с несогласованностью действий URL-парсеров и URL-запросов. В докладе показано на живых примерах, как применять эксплоиты для URL-парсеров, чтобы обходить SSRF-защиту и устраивать RCE (Remote Code Execution, удаленное выполнение кода). Разобравшись в основополагающих моментах предлагаемой докладчиком техники, уже не удивляешься, что докладчик нашел больше двадцати фундаментальных уязвимостей в распространенных языках программирования и наиболее востребованном веб-софте.
Ты уже бывал на конференциях по безопасности?
DOM недостоин вашего доверия: обход XSS-блокираторов посредством скрипт-гаджетов
XSS (Cross-Site Scripting, межсайтовый скриптинг) — хроническая болезнь любого веб-софта. На протяжении долгих лет предпринимаются все новые и новые попытки победить XSS. Большинство этих попыток сосредоточены на контроле тегов, в которых можно запускать скрипты, и на контроле обработчиков событий. Политика HTML-дезинфекции, к примеру, нацелена на удаление потенциально опасных тегов и атрибутов. Другая политика, CSP(Content Security Policy, политика защиты контента), запрещает использовать встроенные обработчики событий и ограничивает допустимые к использованию скрипты белым списком.
В этом докладе представлена новая техника взлома веб-софта, которая позволяет злоумышленнику обходить большинство XSS-блокираторов. Суть этой техники — в использовании так называемых скрипт-гаджетов. Скрипт-гаджет — это законный фрагмент JS-кода на веб-странице, который при помощи CSS-селекторов считывает содержимое DOM-элементов и затем обрабатывает их таким образом, чтобы запустился вредоносный скрипт.
Для злоупотребления скрипт-гаджетом злоумышленник делает на странице-жертве JS-инъекцию, которая выглядит как вполне законный JS-код, но может «ошибочно» увеличивать привилегии доступа к обрабатываемому DOM-элементу. Впоследствии скрипт-гаджет запускает находящиеся под контролем злоумышленника скрипты. Поскольку первоначально имплантированный элемент выглядит доброкачественным, он легко проходит мимо XSS-блокираторов.
В предлагаемом докладе продемонстрировано, что скрипт-гаджеты присутствуют практически во всех современных JS-библиотеках, API и веб-софте. В докладе представлено несколько тематических исследований и реальные примеры из дикой природы, демонстрирующие, что подавляющее большинство ныне существующих методов противодействия XSS несостоятельны.
Electronegativity: исследование безопасности Electron
Вопреки многочисленным пророчествам, старые добрые «настольные приложения» с недавнего времени вновь обрели популярность. После нескольких лет переноса автономных приложений в интернет мы сегодня наблюдаем обратную тенденцию. Многие компании начали предоставлять настольные версии своих приложений, используя при этом те же технологии, что и при разработке веб-софта. Один из самых популярных фреймворков, обеспечивающих такую возможность, — GitHub’овский Electron, который позволяет создавать кросс-платформенные настольные приложения на основе таких технологий, как JavaScript, HTML и CSS. Хотя подобный шаг на первый взгляд кажется весьма лаконичным, встраивание веб-технологий в автономную веб-среду (Chromium, Node.js) порождает новые проблемы с кибербезопасностью.
В этом докладе проиллюстрирована Electron’овская модель безопасности и описан механизм изоляции, ограждающий примитивы Node.js от сомнительного контента. Подробно описаны внутренние компоненты Electron’а, в том числе обмен IPC-сообщениями и предзагрузка. Также представлены результаты анализа опций безопасности для BrowserWindow и WebView, архитектурные изъяны и ошибки реализации в приложениях, построенных на базе Electron’a.
Кроме того, в рамках своего исследования по безопасности Electron’а докладчик представил карту общей поверхности атак и привел исчерпывающий контрольный список антишаблонов. Также докладчик анонсировал свой новый инструмент (Electronegativity), предназначенный для автоматического поиска уязвимостей в приложениях, разработанных на основе Electron’а.
Как новомодные веб-стандарты и нагромождение спецификаций приводят к возникновению критических ошибок в скриптовых движках
Веб-стандарты постоянно эволюционируют и постоянно диктуют новые требования к тому, что придерживающиеся этих стандартов браузеры могут делать. Однако новые возможности, описываемые этими стандартами, также приводят и к новым проблемам с безопасностью, новым уязвимостям. Потому что для реализации этих возможностей уже существующая функциональность используется новым, незапланированным способом.
Докладчик обсуждает некоторые из наиболее интересных и необычных особенностей JavaScript, с появлением которых в JS-движке также появились и новые критические уязвимости, которым подвержены самые разнообразные скриптовые движки, в том числе Adobe Flash, Chrome, Microsoft Edge и Safari.
В докладе доходчиво объясняется, как новомодные веб-стандарты и нагромождение спецификаций друг на друга (как это происходит в современных скриптовых движках) приводят к возникновению неустранимых критических ошибок. При этом в докладе акцент сделан не на перечислении конкретных ошибок, а на объяснении того, почему эти ошибки неизбежно возникают.
Докладчик объясняет, что нагромождение спецификаций (для реализации обновленной функциональности), как правило, негативно сказывается на безопасности кода скриптового движка. Но соблазн воспользоваться более новой и более удобной функцией — даже несмотря на то, что новая версия скриптового движка, в которой эта функция реализована, более уязвима, — берет верх над здравым смыслом.
Последствия нагромождения спецификаций проиллюстрированы реализацией массива (который на сегодняшний день представляет собой смесь фильтров, умной индексации, смешанных типов, подклассов, многопоточного доступа и других концепций). Докладчик объясняет, что негативные последствия для безопасности возникают в том числе из-за того, что реализация массивов в одном браузере, как правило, несовместима с его реализацией в другом браузере. Почему так происходит? Иногда из-за того, что разработчики скриптовых движков не до конца поняли отраслевой стандарт, регулирующий работу скриптового движка; иногда из-за того, что какие-то пункты этого стандарта сформулированы неоднозначно… И так не только с массивами, но и со всеми остальными компонентами скриптовых движков.
WCD-атака: фальсификация веб-кеша
WCD-атака (Web Cache Deception; фальсификация веб-кеша) — это новый вектор веб-атак, который ставит под угрозу широкое разнообразие самых современных веб-технологий и фреймворков. Манипулируя поведением веб-серверов и механизмами кеширования веб-контента, анонимные злоумышленники могут скомпрометировать конфиденциальную информацию авторизованных пользователей веб-софта, а в некоторых случаях даже могут захватить полный контроль над их учетными записями.
WCD-атака на удивление проста в исполнении. В докладе представлено ее подробное описание, необходимые для ее проведения предпосылки и то, каким образом безопасники пытаются от нее защищаться. Презентация WCD-атаки сопровождается демонстрацией поведения различных веб-серверов и механизмов веб-кеширования. Доклад завершается примерами уязвимых для WCD-атаки сайтов и демонстрационной атакой.
Почему иногда не удается воспроизвести техники взлома из авторитетных докладов?
Зомби-расширения Chrome захватывают интернет
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
16 апреля 2016 года армия ботов штурмовала серверы Wix, создавая новые аккаунты и публикуя в массовом порядке теневые веб-сайты. Атака велась вредоносным расширением браузера Chrome, которое в результате самораспространения было установлено на десятках тысяч девайсов. Этот базирующийся на расширениях бот использовал Wix’овую платформу веб-сайтов и Facebook’овский мессенджер — для самораспространения среди пользователей этих интернет-сервисов. Два месяца спустя та же самая атака повторилась. На этот раз злоумышленники инфицировали всплывающие уведомления Facebook’а — так, чтобы при клике по этому уведомлению управление передавалось на вредоносный JSE-файл, который устанавливал контрабандное расширение в Chrome-браузере жертвы. Затем это контрабандное расширение эксплуатировало Facebook’овский мессенджер еще раз — теперь уже чтобы распространить себя еще большему числу жертв.
Анализируя эти две бот-атаки, поражаешься их неуловимости, а особенно тому, как они обходят веб-ориентированные системы обнаружения ботов. Однако это не должно удивлять, поскольку легальным расширениям браузера позволено многое: отправлять сообщения в Facebook, создавать веб-сайты в Wix, да и вообще выполнять любое действие от имени пользователя. С другой стороны, контрабандные вредоносные расширения в Google Web Store и их эффективное распространение среди большого количества жертв, подобно двум описанным выше атакам, превращают Google Web Store в зону боевых действий.
Кроме того, совсем недавно было обнаружено, что несколько популярных расширений Chrome уязвимы для XSS. Тому самому XSS, которому подвержено большинство веб-приложений. Причем в случае с браузерными расширениями последствия от XSS могут быть куда более разрушительными, чем в случае с традиционным злоупотреблением XSS на веб-сайтах. Яркий тому пример — расширение Adobe Acrobat для Chrome, которое 10 января 2016 года было по-тихому установлено компанией Adobe на 30 миллионов компьютеров. DOM’овская XSS-уязвимость, найденная в этом расширении, позволяла злоумышленнику создавать контент, запускающий JavaScript-код от имени этого Adobe’овского расширения.
В докладе рассказывается, как подобные изъяны приводят к полному и постоянному контролю над браузером жертвы, превращая легальное расширение в зомби. Кроме того, докладчик проливает новый свет на две атаки, упомянутые в начале описания доклада. Демонстрирует, как злоумышленник может использовать аналогичные техники для эффективной доставки вредоносной полезной нагрузки к новым жертвам, через популярные социальные платформы и таким образом создавать в интернете мощнейшие бот-сети.
Атака на браузерные расширения по обходным каналам
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
Все наиболее востребованные браузеры поддерживают механизм расширений. Поскольку браузерные расширения тесно связаны с браузерным окружением, они в последнее время стали привлекательным для злоумышленников объектом. С помощью механизма расширений злоумышленники уже давно собирают конфиденциальную информацию, просматривают историю поиска, воруют пароли. Все эти свои находки злоумышленники затем используют для очень серьезных целенаправленных атак.
В современных браузерах теоретически есть контрмеры, которые защищают расширения и их ресурсы от доступа к ним со стороны третьих лиц. Однако все эти контрмеры грешат одним из двух изъянов: либо их недостаточно, либо они реализованы некорректно.
В этом докладе представлена атака на браузерные расширения по обходным каналам, как раз направленная против настроек контроля доступа. Данная атака обходит даже самые современные защитные механизмы, во всех популярных браузерах, в том числе Chromium, Firefox, Microsoft Edge, Safari.
Также в докладе демонстрируются разрушительные последствия от применения плохой практики программирования, из-за которой большинство ныне существующих браузерных расширений очень уязвимы.
Как оценить уровень докладов на хакерских конференциях?
- По оформлению презентаций и количеству слайдов
- По демонстрации PoC и детальности технического описания
- По авторитетности докладчика и цене за билет
Эксплуатация одной и той же SQLite-уязвимости на разном софте
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
SQLite широко используется в качестве встроенной БД для локального/клиентского хранилища в прикладном софте, таком как веб-браузеры и мобильный софт. Как реляционная БД, SQLite уязвима для SQL-инъекций. Эксплоитами SQL-инъекций сегодня уже мало кого удивишь. Поэтому в докладе сделан акцент на ошибки повреждения памяти в SQLite. Обычно эти ошибки не считаются серьезными проблемами кибербезопасности, и предполагается, что они вряд ли будут эксплуатироваться. Однако в этом докладе описаны несколько вариантов повреждения памяти через удаленный доступ, чтобы показать, что такой тип атак представляет для SQLite серьезную опасность.
Экскурс в SQLite-эксплоиты начинается с WebSQL. БД WebSQL — это веб-интерфейс для хранения данных, доступ к которым может быть получен посредством SQL-запросов. Хотя рабочая группа W3C прекратила развивать эту спецификацию в 2010 году, многие современные браузеры (в том числе Google Chrome, Apple Safari и Opera) все еще имеют в своей реализации обширную функциональность на основе SQLite.
В докладе рассмотрено несколько последних этапов в эволюции SQLite, рассказано, какое влияние эти этапы оказали на браузеры и каким исправлениям SQLite подвергалась на протяжении своей эволюции. Кроме того, в докладе представлены новейшие SQLite-уязвимости, которые докладчик использовал для компрометации Apple Safari. Этим новейшим уязвимостям подвержены абсолютно все браузеры, которые поддерживают БД WebSQL, в том числе браузерные компоненты WebView (Android) и UIWebView (iOS), которые широко используются в мобильном софте.
Чтобы показать, какими серьезными неприятностями может обернуться даже одна-единственная SQLite-уязвимость, в докладе приведено несколько примеров применения описываемого эксплоита против разных браузеров и платформ.
У многих языков программирования, в том числе PHP, Lua и Java, есть API для привязки к SQLite. Поэтому ошибки повреждения памяти в SQLite, помимо всего прочего, оказывают разрушительное влияние на функции безопасности этих языков программирования. В качестве примера в докладе продемонстрировано, как скомпрометировать PHP-движок через его SQLite-расширение, чтобы обойти ограничения безопасности, предусмотренные в PHP.
Новейшие примитивы и стратегии для проведения CSRF-атак
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
CSRF (Cross Site Request Forgery, межсайтовая подделка запроса) не теряет своей актуальности и остается неуловимой — из-за устаревшего кода, устаревших фреймворков, а также из-за того, что разработчики попросту не понимают сути этой проблемы, а если и понимают, то не знают, как от нее защититься. Докладчик в своем выступлении вводит примитивы и стратегии для проведения CSRF-атак, которые могут быть развернуты против любого веб-софта, использующего HTTP (в котором существует техническая возможность перехватывать и модифицировать HTTP-запросы и HTTP-ответы).
Современные фреймворки наконец-то стали предлагать эффективные решения для противодействия CSRF. Эти решения автоматически интегрируются в веб-софт и хорошо показывают себя в большинстве случаев. Однако множество старых приложений, а также новые приложения, которые либо не используют эти фреймворки вообще, либо используют их некорректно, по-прежнему подвержены CSRF.
Докладчик подробно разбирает, почему CSRF все еще жива, анализируя при этом примеры «полезной нагрузки», которая эксплуатирует конкретные проблемы в их различных вариациях. Докладчик проводит живую демонстрацию этих атак и показывает, как современные умные фреймворки пытаются защититься от них.
Далее докладчик показывает, как синтезировать рассмотренные примитивы в единое универсальное решение, способное проводить CSRF в подавляющем большинстве ситуаций. Объясняются ограничения умных фреймворков и эксплуатация этих ограничений. Под конец своего выступления докладчик рассматривает Same Site Cookies — новейшую технологию против CSRF — и объясняет, как и почему описанные методики распространяются и на эту технологию.
Злоупотребление веб-хуками — для C2 (Command and Control)
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
Хакер проник за периметр. Разумеется, он хочет провести эксфильтрацию, скачать утилиту или выполнить команду на своем C2-сервере. Но вот проблема: в каждом из этих случаев ему необходимо установить с C2-сервером связь, а такая возможность заблокирована. Генерируемый хакером DNS-трафик и ICMP-трафик мониторятся. Доступа к облачным хранилищам нет. Конечно, злоумышленнику удалось доставить внутрь периметра фронтенд-компонент своей хакерской утилиты, но в результате он видит, что она не может преодолеть заслон контентного прокси-сервера, который контролирует доступ к внешним сайтам. Многим взломщикам доводилось бывать в такой переделке, и выпутаться из нее помогают альтернативные способы наладить исходящее подключение к сети. В докладе представлена техника налаживания такой связи посредством HTTP-колбэков: эксплуатация списка «доверенных сайтов» для содействия в работе с внешним C2-сервером через веб-хуки.
Докладчик кратко рассказывает, что такое веб-хуки и как их использовать. Затем он объясняет, как можно приспособить «одобренные сайты» в качестве посредника для C2-коммуникации, передавать данные, отдавать асинхронные команды в режиме реального времени. И все это в обход контентных прокси, без лишних цифровых следов! Под конец докладчик демонстрирует авторский инструмент, который автоматизирует описанные в докладе техники.
Новое поколение SSRF-атак: эксплоиты для URL-парсеров самых востребованных языков программирования
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
Докладчик демонстрирует принципиально новую технику применения SSRF-эксплоитов (Server Side Request Forgery, подделка запроса на стороне сервера). Эта техника значительно расширяет поверхность SSRF-атак и позволяет обходить даже самые современные SSRF-контрмеры. Описываемая техника представляет собой комбинированный подход, основой которого служит автоматический поиск специфических 0day-уязвимостей во встроенных библиотеках языков программирования. Автоматический поиск 0day-уязвимостей ведется при помощи авторской утилиты для фаззинга, которая фокусируется на поиске только тех уязвимостей, которые обусловлены несогласованностью действий URL-парсеров и URL-запросов. Проблема этой несогласованности фундаментальна, и она свойственна встроенным библиотекам всех языков программирования, в том числе Python, PHP, Perl, Ruby, Java, JavaScript, Wget и cURL.
Таким образом, весь веб-софт, разработанный с применением этих языков и встроенных библиотек, потенциально уязвим для нового поколения SSRF-атак. В том числе WordPress (на долю которого приходится 27% интернета), vBulletin, MyBB и GitHub. Во всех этих веб-приложениях докладчик обнаружил 0day-уязвимости, связанные с несогласованностью действий URL-парсеров и URL-запросов. В докладе показано на живых примерах, как применять эксплоиты для URL-парсеров, чтобы обходить SSRF-защиту и устраивать RCE (Remote Code Execution, удаленное выполнение кода). Разобравшись в основополагающих моментах предлагаемой докладчиком техники, уже не удивляешься, что докладчик нашел больше двадцати фундаментальных уязвимостей в распространенных языках программирования и наиболее востребованном веб-софте.
Ты уже бывал на конференциях по безопасности?
- Да, но только на российских
- Бывал на зарубежных
- Еще нет, но посетил бы с удовольствием
- Нет, и не планирую
DOM недостоин вашего доверия: обход XSS-блокираторов посредством скрипт-гаджетов
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
XSS (Cross-Site Scripting, межсайтовый скриптинг) — хроническая болезнь любого веб-софта. На протяжении долгих лет предпринимаются все новые и новые попытки победить XSS. Большинство этих попыток сосредоточены на контроле тегов, в которых можно запускать скрипты, и на контроле обработчиков событий. Политика HTML-дезинфекции, к примеру, нацелена на удаление потенциально опасных тегов и атрибутов. Другая политика, CSP(Content Security Policy, политика защиты контента), запрещает использовать встроенные обработчики событий и ограничивает допустимые к использованию скрипты белым списком.
В этом докладе представлена новая техника взлома веб-софта, которая позволяет злоумышленнику обходить большинство XSS-блокираторов. Суть этой техники — в использовании так называемых скрипт-гаджетов. Скрипт-гаджет — это законный фрагмент JS-кода на веб-странице, который при помощи CSS-селекторов считывает содержимое DOM-элементов и затем обрабатывает их таким образом, чтобы запустился вредоносный скрипт.
Для злоупотребления скрипт-гаджетом злоумышленник делает на странице-жертве JS-инъекцию, которая выглядит как вполне законный JS-код, но может «ошибочно» увеличивать привилегии доступа к обрабатываемому DOM-элементу. Впоследствии скрипт-гаджет запускает находящиеся под контролем злоумышленника скрипты. Поскольку первоначально имплантированный элемент выглядит доброкачественным, он легко проходит мимо XSS-блокираторов.
В предлагаемом докладе продемонстрировано, что скрипт-гаджеты присутствуют практически во всех современных JS-библиотеках, API и веб-софте. В докладе представлено несколько тематических исследований и реальные примеры из дикой природы, демонстрирующие, что подавляющее большинство ныне существующих методов противодействия XSS несостоятельны.
Electronegativity: исследование безопасности Electron
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
Вопреки многочисленным пророчествам, старые добрые «настольные приложения» с недавнего времени вновь обрели популярность. После нескольких лет переноса автономных приложений в интернет мы сегодня наблюдаем обратную тенденцию. Многие компании начали предоставлять настольные версии своих приложений, используя при этом те же технологии, что и при разработке веб-софта. Один из самых популярных фреймворков, обеспечивающих такую возможность, — GitHub’овский Electron, который позволяет создавать кросс-платформенные настольные приложения на основе таких технологий, как JavaScript, HTML и CSS. Хотя подобный шаг на первый взгляд кажется весьма лаконичным, встраивание веб-технологий в автономную веб-среду (Chromium, Node.js) порождает новые проблемы с кибербезопасностью.
В этом докладе проиллюстрирована Electron’овская модель безопасности и описан механизм изоляции, ограждающий примитивы Node.js от сомнительного контента. Подробно описаны внутренние компоненты Electron’а, в том числе обмен IPC-сообщениями и предзагрузка. Также представлены результаты анализа опций безопасности для BrowserWindow и WebView, архитектурные изъяны и ошибки реализации в приложениях, построенных на базе Electron’a.
Кроме того, в рамках своего исследования по безопасности Electron’а докладчик представил карту общей поверхности атак и привел исчерпывающий контрольный список антишаблонов. Также докладчик анонсировал свой новый инструмент (Electronegativity), предназначенный для автоматического поиска уязвимостей в приложениях, разработанных на основе Electron’а.
Как новомодные веб-стандарты и нагромождение спецификаций приводят к возникновению критических ошибок в скриптовых движках
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
Веб-стандарты постоянно эволюционируют и постоянно диктуют новые требования к тому, что придерживающиеся этих стандартов браузеры могут делать. Однако новые возможности, описываемые этими стандартами, также приводят и к новым проблемам с безопасностью, новым уязвимостям. Потому что для реализации этих возможностей уже существующая функциональность используется новым, незапланированным способом.
Докладчик обсуждает некоторые из наиболее интересных и необычных особенностей JavaScript, с появлением которых в JS-движке также появились и новые критические уязвимости, которым подвержены самые разнообразные скриптовые движки, в том числе Adobe Flash, Chrome, Microsoft Edge и Safari.
В докладе доходчиво объясняется, как новомодные веб-стандарты и нагромождение спецификаций друг на друга (как это происходит в современных скриптовых движках) приводят к возникновению неустранимых критических ошибок. При этом в докладе акцент сделан не на перечислении конкретных ошибок, а на объяснении того, почему эти ошибки неизбежно возникают.
Докладчик объясняет, что нагромождение спецификаций (для реализации обновленной функциональности), как правило, негативно сказывается на безопасности кода скриптового движка. Но соблазн воспользоваться более новой и более удобной функцией — даже несмотря на то, что новая версия скриптового движка, в которой эта функция реализована, более уязвима, — берет верх над здравым смыслом.
Последствия нагромождения спецификаций проиллюстрированы реализацией массива (который на сегодняшний день представляет собой смесь фильтров, умной индексации, смешанных типов, подклассов, многопоточного доступа и других концепций). Докладчик объясняет, что негативные последствия для безопасности возникают в том числе из-за того, что реализация массивов в одном браузере, как правило, несовместима с его реализацией в другом браузере. Почему так происходит? Иногда из-за того, что разработчики скриптовых движков не до конца поняли отраслевой стандарт, регулирующий работу скриптового движка; иногда из-за того, что какие-то пункты этого стандарта сформулированы неоднозначно… И так не только с массивами, но и со всеми остальными компонентами скриптовых движков.
WCD-атака: фальсификация веб-кеша
Пожалуйста,
Вход
или
Регистрация
для просмотра содержимого URL-адресов!
WCD-атака (Web Cache Deception; фальсификация веб-кеша) — это новый вектор веб-атак, который ставит под угрозу широкое разнообразие самых современных веб-технологий и фреймворков. Манипулируя поведением веб-серверов и механизмами кеширования веб-контента, анонимные злоумышленники могут скомпрометировать конфиденциальную информацию авторизованных пользователей веб-софта, а в некоторых случаях даже могут захватить полный контроль над их учетными записями.
WCD-атака на удивление проста в исполнении. В докладе представлено ее подробное описание, необходимые для ее проведения предпосылки и то, каким образом безопасники пытаются от нее защищаться. Презентация WCD-атаки сопровождается демонстрацией поведения различных веб-серверов и механизмов веб-кеширования. Доклад завершается примерами уязвимых для WCD-атаки сайтов и демонстрационной атакой.
Почему иногда не удается воспроизвести техники взлома из авторитетных докладов?
- Использованные уязвимости уже закрыли
- Докладчик утаил важные детали
- Для демонстрации PoC использовалась система с кастомными настройками
- Проверяющий сам чего-то недопонял
- Возможны все перечисленные варианты и масса других
На этом мой обзор закончен.