В сентябре 2018 года стало известно о крупной утечке данных клиентов в авиакомпании British Airways. Злоумышленники скомпрометировали сервер web-приложения для бронирования авиабилетов и добавили в код JavaScript-библиотеки Modernizr код js-сниффера. js-сниффер перехватывал персональные данные и данные банковских карт пользователей, введенных в формы при бронировании авиабилетов, и отправлял на сервер злоумышленников. Несанкционированное изменение кода обнаружили через 10 дней, за это время были похищены данные 380 000 клиентов.
Злоумышленник не имел доступа к хранилищам данных с скомпрометированного сервера, поэтому перехватывал данные на уровне frontend-приложения. В большинстве случаев критичные данные отображаются либо вводятся пользователем на страницах frontend-приложения, а существующие средства защиты не обнаруживают утечки на стороне браузера и не могут отличить действия js-сниффера от легитимного поведения js-приложения.
Теоретически от отправки данных на сервер злоумышленника могла защитить Content Security Policy (CSP), но в случае скомпрометированного сервера, злоумышленник имел возможность изменить и конфигурацию CSP. Также важно отменить, что CSP позволяет ограничить не все предоставляемые браузерами каналы передачи информации.
Вектор: взлом через уязвимость.
Канал отправки данных в браузере: window.XMLHttpRequest.
Время присутствия: 10 дней.
Ущерб: 2 280 000 000 £ (компенсации пострадавшим) + 20 000 000 £ штраф по GDPR.
@FrontSecOps
Злоумышленник не имел доступа к хранилищам данных с скомпрометированного сервера, поэтому перехватывал данные на уровне frontend-приложения. В большинстве случаев критичные данные отображаются либо вводятся пользователем на страницах frontend-приложения, а существующие средства защиты не обнаруживают утечки на стороне браузера и не могут отличить действия js-сниффера от легитимного поведения js-приложения.
Теоретически от отправки данных на сервер злоумышленника могла защитить Content Security Policy (CSP), но в случае скомпрометированного сервера, злоумышленник имел возможность изменить и конфигурацию CSP. Также важно отменить, что CSP позволяет ограничить не все предоставляемые браузерами каналы передачи информации.
Вектор: взлом через уязвимость.
Канал отправки данных в браузере: window.XMLHttpRequest.
Время присутствия: 10 дней.
Ущерб: 2 280 000 000 £ (компенсации пострадавшим) + 20 000 000 £ штраф по GDPR.
@FrontSecOps
В конце февраля 2022 года был скомпрометирован один из сервисов маркетинговой аналитики для сайтов, сервис работал по принципу подключения внешнего js-скрипта. Злоумышленники добавили вредоносный код к этому скрипту, в результате был произведен "дефейс" сайтов всех компаний, использующих данный сервис, в частности многих российских интернет-СМИ. На сайтах были размещены политические лозунги.
С другой стороны, злоумышленники с иной мотивацией могли незаметно собирать данные пользователей, установить js-майнер криптовалюты, показывать пользователям мошеннические баннеры, производить заражение устройств пользователей через уязвимости браузеров с целью монетизации взлома и длительного незаметного присутствия.
После этой и других атак НКЦКИ выпустил "Рекомендации по повышению уровня защищенности российских web-приложений" от 11 марта 2022 г., содержащие следующие меры для безопасности frontend-приложений:
🔸Перед использованием на web-ресурсах JavaScript-кода, подгружаемого со сторонних ресурсов,
осуществлять его проверку на предмет вредоносного воздействия на отображаемую в браузерах пользователя
информацию и возможность кражи аутентификационных данных и файлов-cookie пользователей.
🔸Осуществлять периодическую проверку хэш-сумм используемых JavaScript. В случае изменения
хэш-сумм отключать использование JavaScript на сайте и выполнять повторную проверку функциональности.
🔸Отказаться от использования динамически формируемых кодов JavaScript на web-ресурсе.
🔸Отдавать предпочтение загрузке внешних зависимостей (JavaScript, CSS и др. из контролируемых источников).
@FrontSecOps
С другой стороны, злоумышленники с иной мотивацией могли незаметно собирать данные пользователей, установить js-майнер криптовалюты, показывать пользователям мошеннические баннеры, производить заражение устройств пользователей через уязвимости браузеров с целью монетизации взлома и длительного незаметного присутствия.
После этой и других атак НКЦКИ выпустил "Рекомендации по повышению уровня защищенности российских web-приложений" от 11 марта 2022 г., содержащие следующие меры для безопасности frontend-приложений:
🔸Перед использованием на web-ресурсах JavaScript-кода, подгружаемого со сторонних ресурсов,
осуществлять его проверку на предмет вредоносного воздействия на отображаемую в браузерах пользователя
информацию и возможность кражи аутентификационных данных и файлов-cookie пользователей.
🔸Осуществлять периодическую проверку хэш-сумм используемых JavaScript. В случае изменения
хэш-сумм отключать использование JavaScript на сайте и выполнять повторную проверку функциональности.
🔸Отказаться от использования динамически формируемых кодов JavaScript на web-ресурсе.
🔸Отдавать предпочтение загрузке внешних зависимостей (JavaScript, CSS и др. из контролируемых источников).
@FrontSecOps
Всем привет! Сегодня в 15:00 (МСК) на PHDays 2 буду рассказывать о концепции Frontend Application Security Testing (FAST). Обсудим задачи FAST-анализаторов и наиболее эффективные точки для встраивания в процесс безопасной разработки. Приходите в зал Фобос (трек Secure Development) или подключайтесь к трансляции на сайте https://phdays.com/forum/
Запись доклада про FAST-анализатор на PHD2 доступна по ссылке. @FrontSecOps
Опубликовано исследование от ProofPoint об атаке зафиксированной в марте 2024 года.
Злоумышленники размещали на взломанных сайтах JavaScript, показывающий всплывающие окна в стиле сообщений об ошибках Chrome, MS Office, One Drive. В данном случае пользователей убеждали для "устранения ошибки" выполнить в PowerShell вредоносный код, который скрипт злоумышленников записал в буфер обмена. JavaScript на веб-страницах имеет право читать/записывать данные в буфер.
Подобный фишинг в frontend-приложениях - один из способов монетизации взлома серверов. Злоумышленники могли предложить пользователю скачать документ с эксплойтом, запросить данные банковской карты, ввести учетные данные, пользуясь авторитетом взломанного сайта.
Контроль целостности и регулярная глубокая инвентаризация скриптов, iframe и других активных элементов позволят оперативно выявлять факт компрометации собственных или партнерских js-сервисов.
@FrontSecOps
Злоумышленники размещали на взломанных сайтах JavaScript, показывающий всплывающие окна в стиле сообщений об ошибках Chrome, MS Office, One Drive. В данном случае пользователей убеждали для "устранения ошибки" выполнить в PowerShell вредоносный код, который скрипт злоумышленников записал в буфер обмена. JavaScript на веб-страницах имеет право читать/записывать данные в буфер.
Подобный фишинг в frontend-приложениях - один из способов монетизации взлома серверов. Злоумышленники могли предложить пользователю скачать документ с эксплойтом, запросить данные банковской карты, ввести учетные данные, пользуясь авторитетом взломанного сайта.
Контроль целостности и регулярная глубокая инвентаризация скриптов, iframe и других активных элементов позволят оперативно выявлять факт компрометации собственных или партнерских js-сервисов.
@FrontSecOps
Несколько дней назад было обнаружено , что в js-библиотеку polyfill.js на cdn.polyfill.io внедрен вредоносный код. Библиотека из этого CDN подключена на более чем 100 000 сайтах. Говорят, что проект выкупила некая китайская компания, после чего был внедрен код, который динамически подгружал вредоносный скрипт с поддельного домена Google Analytics (www.googie-anaiytics.com), который осуществлял редирект пользователей через на сайты онлайн-букмекеров.
Примечательно, что вредоносное воздействие выполнялось по разному в зависимости от времени, устройства пользователя, наличия на страницах скриптов аналитики. Сейчас репозиторий помечен как вредоносный; регистратор доменных имен Namecheap заморозил домен, чтобы остановить раздачу вредоносной библиотеки. Атаки на цепочки поставок для frontend-приложений более чем актуальны. Регулярная инвентаризация скриптов и сетевых запросов frontend-приложения позволяет обнаружить такие атаки.
@FrontSecOps
Примечательно, что вредоносное воздействие выполнялось по разному в зависимости от времени, устройства пользователя, наличия на страницах скриптов аналитики. Сейчас репозиторий помечен как вредоносный; регистратор доменных имен Namecheap заморозил домен, чтобы остановить раздачу вредоносной библиотеки. Атаки на цепочки поставок для frontend-приложений более чем актуальны. Регулярная инвентаризация скриптов и сетевых запросов frontend-приложения позволяет обнаружить такие атаки.
@FrontSecOps
Компрометация polyfill.js затронула и российские компании. Прямо сейчас на сайте www.fontanka.ru, пострадавшем от компрометации стороннего js-сервиса в марте 2022 года, при условии открытия в старых версиях Internet Explorer, на страницы сайта динамически загружается скрипт с cdn.polyfill.io. Если у кого-то есть контакты, сообщите коллегам.
@FrontSecOps
@FrontSecOps
Уязвимость 0.0.0.0 Day
7 августа Oligo Security опубликовали исследование об уязвимости во всех современных браузерах, которую назвали 0.0.0.0 Day. Информация об уязвимости была передана разработчикам браузеров в начале апреля. Рекомендую оригинальную статью к прочтению, особенно про первые зафиксированные в 2006 году атаки скриптов на веб-страницах на домашние роутеры.
Злоумышленник может выполнять запросы со страниц публичных frontend-приложений (через js или html-элементы) к сетевым службам / приложениям на устройстве пользователя (используя адрес 0.0.0.0 вместо localhost/127.0.0.1). Ранее считалось, что это запрещено. Уязвимость затрагивает все основные браузеры Chromium, Chrome, Safari, Firefox при работе в ОС Linux и macOS.
Почему так произошло?
В Chrome за контроль сетевых запросов frontend-приложения отвечает механизм PNA (Private Network Access), который на основании IP-адреса определял его тип (local, private, public). Например адреса, соответствующие 127.0.0.0/8, ::1/128 считались local. Проблема заключалась в том, что в PNA не было правила для 0.0.0.0, следовательно, адрес считался public и запросы разрешались. В других браузерах - схожая проблема в реализации функций выполнения сетевых запросов.
Что может сделать злоумышленник?
Скрипт может, перебирая различные порты на localhost понять, какие службы/ПО выполняются на устройстве пользователя. В случае наличия уязвимых служб или доступного без авторизации API - выполнить атаку или запрос к такому API. Исследователи описывают реально зафиксированные атаки на ПО Ray и Selenium Grid, приводящие к удаленному выполнению кода.
Когда исправят?
🔹Google планирует вносить исправления поэтапно с версии 128 до применения у всех пользователей к версии 133 (сейчас актуальная версия 127).
🔹Apple внесла исправления в код WebKit / Safari, исправления будут доставлены в одном из следующих апдейтов.
🔹Firefox ограничился исправлением спецификации Fetch, срок реализации неизвестен.
Теперь запросы на локальные и частные IP-адреса запрещены окончательно?
Нет. После полного внедрения PNA+CORS в случае, если запрос предназначен для private-адреса Chrome будет выполнять предварительный запрос OPTIONS (аналогично механизму CORS). Если целевой сервис ответит, что разрешает запросы для private (заголовок Access-Control-Allow-Private-Network: true), то Chrome выполнит сам запрос.
Почему говорят, что уязвимости 18 лет?
18 лет назад Google Chrome еще не существовал. 18 лет назад был создан первый репорт в баг-трекере Mozilla, когда пользователь обнаружил, что вредоносные js-скрипты на страницах атакуют домашний роутер по адресу 192.168.0.1. После этого были предприняты первые меры по блокировке запросов на внутренние адреса.
Что происходит сейчас?
С 1 августа фиксируется значительный рост📈 запросов со страниц на адрес 0.0.0.0. По оценке Google запросы осуществлялись со 100 тысяч публичных сайтов. Т.к. исправления выйдут не скоро, злоумышленники могут это использовать и внедрять вредоносные скрипты на скомпрометированные сайты или в JavaScript-библиотеки для распространения вредоносного кода через зависимости.
@FrontSecOps
7 августа Oligo Security опубликовали исследование об уязвимости во всех современных браузерах, которую назвали 0.0.0.0 Day. Информация об уязвимости была передана разработчикам браузеров в начале апреля. Рекомендую оригинальную статью к прочтению, особенно про первые зафиксированные в 2006 году атаки скриптов на веб-страницах на домашние роутеры.
Злоумышленник может выполнять запросы со страниц публичных frontend-приложений (через js или html-элементы) к сетевым службам / приложениям на устройстве пользователя (используя адрес 0.0.0.0 вместо localhost/127.0.0.1). Ранее считалось, что это запрещено. Уязвимость затрагивает все основные браузеры Chromium, Chrome, Safari, Firefox при работе в ОС Linux и macOS.
Почему так произошло?
В Chrome за контроль сетевых запросов frontend-приложения отвечает механизм PNA (Private Network Access), который на основании IP-адреса определял его тип (local, private, public). Например адреса, соответствующие 127.0.0.0/8, ::1/128 считались local. Проблема заключалась в том, что в PNA не было правила для 0.0.0.0, следовательно, адрес считался public и запросы разрешались. В других браузерах - схожая проблема в реализации функций выполнения сетевых запросов.
Что может сделать злоумышленник?
Скрипт может, перебирая различные порты на localhost понять, какие службы/ПО выполняются на устройстве пользователя. В случае наличия уязвимых служб или доступного без авторизации API - выполнить атаку или запрос к такому API. Исследователи описывают реально зафиксированные атаки на ПО Ray и Selenium Grid, приводящие к удаленному выполнению кода.
Когда исправят?
🔹Google планирует вносить исправления поэтапно с версии 128 до применения у всех пользователей к версии 133 (сейчас актуальная версия 127).
🔹Apple внесла исправления в код WebKit / Safari, исправления будут доставлены в одном из следующих апдейтов.
🔹Firefox ограничился исправлением спецификации Fetch, срок реализации неизвестен.
Теперь запросы на локальные и частные IP-адреса запрещены окончательно?
Нет. После полного внедрения PNA+CORS в случае, если запрос предназначен для private-адреса Chrome будет выполнять предварительный запрос OPTIONS (аналогично механизму CORS). Если целевой сервис ответит, что разрешает запросы для private (заголовок Access-Control-Allow-Private-Network: true), то Chrome выполнит сам запрос.
Почему говорят, что уязвимости 18 лет?
18 лет назад Google Chrome еще не существовал. 18 лет назад был создан первый репорт в баг-трекере Mozilla, когда пользователь обнаружил, что вредоносные js-скрипты на страницах атакуют домашний роутер по адресу 192.168.0.1. После этого были предприняты первые меры по блокировке запросов на внутренние адреса.
Что происходит сейчас?
С 1 августа фиксируется значительный рост📈 запросов со страниц на адрес 0.0.0.0. По оценке Google запросы осуществлялись со 100 тысяч публичных сайтов. Т.к. исправления выйдут не скоро, злоумышленники могут это использовать и внедрять вредоносные скрипты на скомпрометированные сайты или в JavaScript-библиотеки для распространения вредоносного кода через зависимости.
@FrontSecOps