-
Похожий контент
-
Автор KL FC Bot
Атаки на open source чаще всего сводятся к публикации новых вредоносных пакетов в репозиториях. Атака, произошедшая 14 марта, из другой лиги — злоумышленники скомпрометировали популярный процесс (GitHub Action) tj-actions/changed-files, который применяется более чем в 23000 репозиториев. Инцидент получил номер CVE-2025-30066, этой уязвимости подвержены все репозитории, в которых использовался заражённый процесс changed-files. Хотя администрация заблокировала changed-files, а затем откатила его к безопасной версии, все, кто пользовался им должны провести реагирование на инцидент, а сообщество разработчиков — извлечь из него более общие уроки.
Что такое GitHub Actions
Рабочие процессы (GitHub Actions) упрощают разработку ПО при помощи автоматизации типовых задач DevOps. Они могут стартовать при наступлении каких-то событий в GitHub, например коммитов. У GitHub есть условный «магазин приложений», в котором можно взять готовый процесс и применить его в своём репозитории, например популярны процессы для автоматической инсталляции вспомогательных инструментов. Чтобы интегрировать в свой сборочный конвейер CI/CD такой готовый процесс GitHub, достаточно всего одной строчки кода.
View the full article
-
Автор KL FC Bot
Легенды гласят, что наши смартфоны нас подслушивают. Оказывается, делать им это совсем не обязательно — информации, которую передают брокерам данных практически все установленные на вашем смартфоне приложения, от игр до прогноза погоды, с лихвой достаточно, чтобы составить на вас полное досье. И если долгое время под «слежкой в Интернете» подразумевалось, что поисковые и рекламные системы — а с ними и рекламодатели — знают, на какие сайты вы ходите, то с появлением смартфонов ситуация изменилась к худшему — теперь рекламодатели знают, куда вы ходите физически и как часто. Как у них это получается?
Каждый раз, когда любое мобильное приложение собирается показать рекламу, за ваше внимание проходит молниеносный аукцион, определяющий на основании переданных с вашего смартфона данных, какую именно рекламу вам покажут. И, хотя вы видите только рекламу победителя, данные о потенциальном зрителе, то есть о вас, получают все участники торгов. Недавно поставленный эксперимент наглядно показал, как много компаний получают эту информацию, насколько она детализирована и как мало помогают защититься встроенные в смартфоны опции «Не отслеживать меня», «Не показывать персонализированную рекламу» и аналогичные. Но мы все же посоветуем способы защиты!
Какие данные пользователя получают рекламодатели
Все мобильные приложения устроены по-разному, но большинство из них начинают «сливать» данные в рекламные сети еще до того, как показать какую-либо рекламу. В вышеописанном эксперименте мобильная игра сразу же после запуска отослала в рекламную сеть Unity Ads обширный набор данных:
информацию о смартфоне, включая версию ОС, уровень заряда батареи, уровень яркости и громкости, количество свободной памяти; данные о сотовом операторе; тип подключения к Интернету; полный IP-адрес устройства; код «вендора», то есть производителя игры; уникальный код пользователя (IFV) — идентификатор для рекламной системы, привязанный к производителю игры; еще один уникальный код пользователя (IDFA/AAID) — идентификатор для рекламной системы, единый для всех приложений на смартфоне; текущую геолокацию; согласие на рекламную слежку (да/нет). Интересно то, что геолокация передается, даже если она целиком отключена на смартфоне. Правда, приблизительная, вычисленная на базе IP-адреса. Но с учетом имеющихся в общем доступе баз соответствия физических и интернет-адресов, это может быть достаточно точно — с точностью до района города или даже дома. Если же геолокация включена и разрешена приложению, передаются точные данные.
Согласие на рекламную слежку в описанном случае было передано как «Пользователь согласен», хотя автор эксперимента такого согласия не давал.
View the full article
-
Автор KL FC Bot
Чуть больше года назад в посте Google OAuth и фантомные аккаунты мы уже обсуждали, что использование опции «Вход с аккаунтом Google» в корпоративные сервисы дает возможность сотрудникам создавать фантомные Google-аккаунты, которые не контролируются администратором корпоративного Google Workspace и продолжают работать после оффбординга. Недавно выяснилось, что это не единственная проблема, связанная с OAuth. Из-за недостатков этого механизма аутентификации любой желающий может получить доступ к данным многих прекративших деятельность организаций, перерегистрировав на себя брошенные компаниями домены. Рассказываем подробнее об этой атаке.
Как работает аутентификация при использовании «Вход с аккаунтом Google»
Некоторые могут подумать, что, доверяя опции «Вход с аккаунтом Google», компания получает надежный механизм аутентификации, использующий продвинутые технологии Google и широкие возможности интернет-гиганта по мониторингу пользователей. Однако на деле это не так: при входе с Google OAuth применяется достаточно примитивная проверка. Сводится она, как правило, к тому, что у пользователя есть доступ к почтовому адресу, который привязан к Google Workspace организации.
Причем, как мы уже говорили в предыдущем материале о Google OAuth, это вовсе не обязательно Gmail — ведь привязать Google-аккаунт можно совершенно к любой почте. Получается, что при использовании «Входа с аккаунтом Google» доступ к тому или иному корпоративному сервису защищен ровно настолько надежно, насколько защищен почтовый адрес, к которому привязан Google-аккаунт.
Если говорить несколько более подробно, то при аутентификации пользователя в корпоративном сервисе Google OAuth отправляет этому сервису следующую информацию:
В теории в ID-токене Google OAuth есть уникальный для каждого Google-аккаунта параметр sub, но на практике из-за проблем с его использованием сервисы проверяют лишь домен и адрес электронной почты. Источник
View the full article
-
Автор KL FC Bot
Примерно год назад произошел масштабнейший ransomware-инцидент — атака на гиганта американского медицинского страхования, компанию UnitedHealth Group. Взлом имел настолько многочисленные и серьезные последствия, что все прошедшее с момента атаки время появлялись новые подробности о ходе атаки и ее итогах. К годовщине инцидента мы решили собрать все теперь уже доступные данные в одном материале.
Ransomware-атака на UnitedHealth Group
Сперва дадим контекст, который будет в особенности полезен для тех, кто не очень хорошо знаком с данной организацией. UnitedHealth Group — это крупнейшая компания на рынке медицинского страхования и медицинских услуг США. Ее капитализация составляет примерно $500 миллиардов. При этом UnitedHealth Group занимает девятое место по выручке среди всех корпораций мира, следуя в этом списке сразу после Apple.
В состав UnitedHealth Group входят две компании. Первая из них, UnitedHealthcare, занимается медицинским страхованием. Вторая, Optum, специализируется на предоставлении разнообразных медицинских услуг — от фармацевтики и собственно медицинского обслуживания до ИТ-систем, используемых в здравоохранении.
Последним занимается OptumInsight — одно из трех подразделений Optum, причем самое высокомаржинальное из них. Осенью 2022 года в OptumInsight вошла приобретенная UnitedHealth Group платформа Change Healthcare. Эта цифровая площадка обрабатывает заявления на получение страховых выплат, выступая в роли финансового посредника между пациентами, поставщиками медицинских услуг и страховщиками.
Собственно, Change Healthcare и стала непосредственной целью атаки вымогателей: 21 февраля в ее системах начал работать шифровальщик, из-за чего платформа стала недоступна. Это вызвало настоящий хаос в американской системе здравоохранения: из-за невозможности быстрой обработки заявлений на страховые выплаты многие пациенты вынуждены были оплачивать лекарства и медицинские услуги из своего кармана. А медицинским учреждениям пришлось перейти в ручной режим обработки счетов.
Восстановление пострадавших систем заняло многие месяцы: к примеру, клиринговый сервис Change Healthcare возобновил работу лишь в ноябре. В UnitedHealth Group даже создали специальный сайт, на котором можно следить за восстановительными работами. Даже сейчас, спустя год после атаки, на этом сайте публикуются регулярные обновления, а некоторые системы до сих пор имеют статус «доступна частично».
View the full article
-
Автор KL FC Bot
Наши технологии для противодействия эксплойтам выявили волну атак с применением ранее неизвестного вредоносного ПО. При тщательном анализе эксперты нашего Глобального центра исследования и анализа угроз (Kaspersky GReAT) пришли к выводу, что мы имеем дело с весьма технически сложной целевой атакой, что позволяет предположить авторство APT-группировки, спонсируемой государством. В атаке использовалась уязвимость нулевого дня в браузере Chrome, о которой мы незамедлительно сообщили в Google, и компания оперативно выпустила закрывающий ее патч.
В чем суть APT-атаки Operation ForumTroll?
Атака начинается с фишингового приглашения на научный форум «Примаковские Чтения». В теле письма содержатся ссылки якобы на программу мероприятия и анкету для участников. На самом деле обе ссылки ведут на сайт злоумышленников и если получатель пользуется браузером Google Chrome (или каким-либо другим браузером на движке Chromium), то простой переход по ним приводит к заражению компьютера под управлением Windows. Никаких дополнительных действий от жертвы не требуется.
Дальше в дело вступает эксплойт для уязвимости CVE-2025-2783, который позволяет обмануть механизмы защиты браузера Google Chrome. О технических деталях говорить пока рано, однако суть уязвимости сводится к логической ошибке на стыке браузера и операционной системы, которая позволяет обойти песочницу браузера.
Более подробное описание атаки вместе с индикаторами компрометации можно найти на нашем блоге Securelist. После того, как большая часть пользователей браузера установит свежевыпущенный патч, наши исследователи обещают опубликовать там же детальный технический разбор уязвимости.
View the full article
-
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти