Расскажем, почему изоляция от коллег и руководителя – это база, и в чем польза cтагнации.

Нет в жизни разработчика более надоедливого архетипа коллеги, чем “неравнодушный советчик”, который спешит причинить добро вне зависимости от твоего желания и последствий этого причинения. Причем, каждый второй обязательно собрал целое комбо из этих квазиполезных рекомендаций и готов делиться ими при каждом удобном случае. Мы нашли целых четверых таких советчиков и решили предоставить им трибуну для причинения добра в особо крупных размерах!



26 сентября мы проведем онлайн-митап “10+ вредных советов мобильному разработчику: как точно завалить проект и карьеру”. На нем опытные лиды и разрабы расскажут, какие действия обязательно затормозят твой промоушн и подожгут любой релиз.

Седьмого сентября исследователь Мордехай Гури опубликовал новую работу, предложив атаку PIXHELL — очередной метод эксфильтрации данных из компьютера, изолированного от Интернета и локальной сети. Гури — известный специалист по решению задач такого рода. За последние 10 лет он опубликовал минимум два десятка работ. Все они так или иначе решают следующую проблему: есть компьютер с особо секретными данными, отключенный от сети. Мы предполагаем, что на этом ПК каким-то образом удалось запустить вредоносное программное обеспечение, способное собрать секретную информацию. Осталось выяснить, как ее оттуда извлечь. Очевидные способы (подкупить сотрудника, заслать в охраняемое помещение шпиона) Мордехай Гури отметает как слишком скучные и вместо этого изобретает все новые нетривиальные подходы, которые наверняка учитываются в наиболее параноидальных сценариях защиты информации.



Во всех своих работах Мордехай Гури описывает несколько общих способов организации скрытного канала передачи информации: это звук, свет, тепло, магнитное и электромагнитное излучение. Свежая работа описывает создание акустического канала эксфильтрации. Самый простой метод такого рода был описан в 2018 году: через динамики ноутбука или даже PC Speaker на материнской плате десктопа воспроизводятся аудиосигналы высокой частоты, которые люди в помещении, скорее всего, не услышат. Свежее исследование организует акустический канал чуть более сложным образом, используя паразитный шум электронных цепей компьютерного монитора.

О software-архитекторах сейчас не говорит только ленивый. По мере усложнения структуры современных приложений команды разработки все больше нуждаются в «дирижере» для своего «оркестра», в специалисте, который предсказывает, какими нефункциональными требованиями будет обладать система и как довести ее до нужных характеристик.



Однако у рядового разработчика вопросов о сути работы «софтварных» архитекторов нередко остается больше, чем ответов:

Чем именно архитектор занимается? Какими навыками должен обладать? Да и как им вообще можно стать?

На наш взгляд, развитие IT-специалиста можно сравнить с классическим мифическим путем героя: победил дракона — стал лидом.

Чтобы узнать, как этот «путь» выглядит в архитектуре ПО, мы пообщались с Анной Мелеховой (AnnaTref), Software Architect & Software Development Group Manager в KasperskyOS — собственной микроядерной операционной системе «Лаборатории Касперского». Мы пройдем путь героя вместе: посмотрим на основные карьерные треки, выявим их особенности и выясним, каких драконов надо победить. Поехали!

Важной новостью прошлой недели стало обнаружение достаточно серьезной уязвимости в аппаратных ключах YubiKey 5, используемых для многофакторной аутентификации, в том числе по стандарту FIDO. Исследователи из компании NinjaLab показали (сайт проекта, исследовательская работа, пересказ для простых смертных в издании Ars Technica), как можно, по сути, такой ключ клонировать и в дальнейшем получать доступ к сервисам ничего не подозревающей жертвы. Атаку назвали EUCLEAK.



Исследование представляет интерес скорее своей сложностью, а не потенциальными последствиями. Для успешной атаки требуется физический доступ к устройству. Более того, нужно будет разобрать устройство и поработать паяльником, а сама атака занимает (в худшем случае) около 10 часов. В случае если речь идет об особо ценной информации, впрочем, и такие усилия могут быть оправданы. Но настоящая заслуга NinjaLab заключается в том, что они нашли уязвимость в особо защищенном и очень хорошо протестированном микроконтроллере компании Infineon, который используется и в контроллерах YubiKey, и во многих других устройствах.

На прошлой неделе исследователи Сэм Карри и Иэн Кэрролл сообщили о серьезной уязвимости в одном из сервисов, используемых для обеспечения безопасности в аэропортах США. В этой стране контроль безопасности во всех аэропортах передан общей администрации, известной как Transportation Security Administration. TSA обеспечивает в том числе специальные программы TSA PreCheck, ускоряющие проход для обычных пассажиров. Для пилотов и членов экипажей, как правило, предусмотрена отдельная очередь. Как выяснили Карри и Кэрролл, для записи в «члены экипажа» существует отдельная система, открытая для ряда сторонних организаций. И в одном из таких сторонних сервисов обнаружилась довольно банальная уязвимость.



В исследовании речь идет не только о быстром прохождении через контроль безопасности в аэропортах. Помимо этой системы, известной как Known Crewmember, существует также база данных Cockpit Access Security System. Она позволяет получить доступ в кокпит самолета. Например, если пилот авиакомпании летит пассажиром, то он может воспользоваться свободным местом в кабине летного экипажа. Администрированием этих двух систем занимается коммерческая компания Collins Aerospace, но она по сути предоставляет API, в то время как реальными «пропусками» управляют отдельные авиакомпании. И вот здесь авторы исследования наткнулись на сервис FlyCASS. В то время как крупные авиакомпании имеют собственные проприетарные системы контроля доступа, FlyCASS предоставляет услуги более мелким операторам. На сайте FlyCASS.com для каждого из них предусмотрен отдельный личный кабинет.

На прошлой неделе специалисты «Лаборатории Касперского» опубликовали отчет об эволюции уязвимостей в ПО за второй квартал 2024 года. Отчет основан на статистике из внешних источников и собственных данных компании. Особый интерес представляет статистика уязвимостей, эксплуатировать которые пытается реальное вредоносное ПО. Судя по этим данным, киберпреступники достаточно активно эксплуатируют несвежие проблемы в популярном программном обеспечении. В частности, пользователи компьютеров под управлением Windows чаще всего сталкиваются с эксплойтами, нацеленными на уязвимости, обнаруженные и закрытые от трех до семи лет назад. Эксплойты под Linux чаще нацелены на более свежие уязвимости в ядре ОС.


Совершенно противоположную картину демонстрирует статистика по часто эксплуатируемым уязвимостям в таргетированных атаках, нацеленных на бизнес. В этом случае в TOP 10 уязвимостей представлено куда больше недавно обнаруженных проблем, включая, например, уязвимость в VPN-сервере Ivanti Connect Secure. Помимо общей статистики, авторы отчета также выбрали три наиболее «интересные» уязвимости среди обнаруженных во втором квартале 2024 года.

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



Важным звеном в процессе повышения разраба зачастую оказывается тимлид — он как наставник должен навести «молодого джедая на путь истинный», помочь своему мидлу наконец-то стать сеньором-помидором (да простят меня хабровчане за космический пафос).

В «Лаборатории Касперского» существует устоявшийся и прозрачный пайплайн повышения мидлов — промоушен-комитет. В этой статье я подробно расскажу об этом процессе с точки зрения руководителя: от подготовки и сбора кейсов до получения кандидатом заветного грейда.

На прошлой неделе компания iVerify обнародовала (оригинальное исследование, пост на Хабре) информацию об уязвимом приложении, которое устанавливалось на большинство смартфонов Google Pixel с сентября 2017 года. Приложение, известное как Showcase.apk, изначально было разработано по заказу сотового оператора Verizon и использовалось им для перевода телефона в специальный деморежим. Широкие привилегии приложения, невозможность удалить его стандартными методами теоретически позволяют перехватить контроль над устройством.



Главная претензия iVerify к приложению Showcase — небезопасный метод загрузки обновлений со стороннего сервера. При первом запуске программа обращается к серверу по незащищенному протоколу HTTP и скачивает обновления. Система верификации скачанного присутствует, но по факту не работает. Теоретически можно представить сценарий атаки типа man-in-the-middle, при котором Showcase.apk перенаправляется на сервер злоумышленника, скачивает оттуда вредоносное обновление и выполняет этот код с максимальными привилегиями.

Нет повести печальнее на свете, чем повесть о слухах про работу в мониторинге ИБ-инцидентов. Публичные спикеры и авторы книг часто поддерживают разные заблуждения о SOC: что он скучный, лишен по-настоящему интересных задач и не предполагает карьерного роста. Однако я уверен, что это не так!



Меня зовут Сергей Солдатов. Я — Head of Security Operations Center в «Лаборатории Касперского». За свою карьеру мне посчастливилось работать в разных ипостасях мира ИТ и ИБ, поэтому, наверное, в своих размышлениях я могу быть вполне объективен. Ну а если нет, надеюсь, коллеги-ветераны кибербеза поделятся своим мнением в комментариях :)

Мы подробно разберем основные заблуждения, связанные со сферой мониторинга инцидентов, а также рассмотрим, из каких конкретных задач состоит работа аналитика SOC и какой карьерный трек у него может быть.

На прошлой неделе в Лас-Вегасе в США прошла очередная парная конференция DEF CON / Black Hat. Именно к этим двум ежегодным мероприятиям многие компании и частные исследователи в сфере информационной безопасности готовят свои наиболее интересные доклады. Сегодня мы коротко расскажем о семи презентациях, затрагивающих большой спектр тем: от серьезной уязвимости в процессорах AMD до методов шпионажа с использованием небезопасного робота-пылесоса.



Начнем с исследования компании SafeBreach Labs, в котором был показан способ деинсталляции обновлений Windows. В результате такой атаки потенциальный злоумышленник может заново сделать систему уязвимой для известных атак, заменяя часть системных файлов на устаревшие. При этом встроенное средство обновления будет показывать, что все доступные апдейты установлены. Компания Microsoft знает о данных проблемах с февраля этого года и официально идентифицировала две уязвимости (1,2). Патчи для них пока не выпущены.

Интернет вещей плотно вошел в нашу жизнь и используется повсеместно. Для меня же это возможность не только пользоваться, но еще и создавать разные умные устройства.



Меня зовут Евгений Глейзерман, я — Head of KasperskyOS IoT Protection Development в «Лаборатории Касперского». Отвечаю за различные IoT-продукты на собственной микроядерной операционной системе KasperskyOS: шлюзы, контроллеры, блоки телематики и т. д. А еще я иногда ковыряю устройства поменьше, на которые KasperskyOS пока установить нельзя. В данной статье хочу рассказать о своем хобби-проекте и поделиться возможностями esp-32 на примере DIY-девайса для автозвука: как я собрал пульт, регулирующий громкость по Bluetooth, взяв за основу популярный микроконтроллер.

На прошлой неделе компания Google объявила об усилении защиты файлов cookie в браузере Google Chrome. Кража сессионных cookie активно практикуется вредоносным программным обеспечением. Зачастую это позволяет злоумышленникам сравнительно легко получить доступ к веб-сервисам (корпоративным или персональным), в которых залогинен пользователь, без кражи паролей к ним. В результате данные браузера становятся одной из главных мишеней инфостилеров. Улучшение касается Chrome под Windows. Начиная с версии браузера Chrome 127, будет внедрена система шифрования данных, ограничивающая доступ к ним со стороны других приложений.

Проблема, которую пытаются решить в Google, заключается в том, что информация, защищенная стандартным механизмом Data Protection API (DPAPI) в Windows, доступна любой другой программе, выполняемой с правами пользователя. В дополнение к этому в Chrome 127 реализована концепция шифрования, привязанного к конкретному приложению или Application-Bound Encryption. Отдельный сервис будет проверять обращения к файлам cookie и расшифровывать их, только если к ним обращается браузер.

Все мы знаем, что токен — это всего лишь ключ и значение. И нет ничего проще, чем их создавать. Придумываешь ключ, который полностью описывает кейс, назначаешь значение из базовой палитры — готово. Такой способ декларативен, но когда используешь токены каждый день, появляется ряд неудобств: сложно запомнить, сложно найти в списке, больно вбивать в редактор…

Вот, например, список токенов из дизайн-системы Atlassian. Смогли бы вы запомнить и скомбинировать «всего-то» сотню-другую названий?



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

На прошлой неделе компания BINARLY сообщила об утечке приватного ключа компании American Megatrends, который используется во множестве ноутбуков, компьютеров и серверов компаний Acer, Dell, GIGABYTE и Supermicro. Исследование BINARLY широко цитировалось в прессе (статья в издании Ars Technica, новость на сайте BleepingComputer, новость на Хабре), а сами первооткрыватели опубликовали подробный отчет. Разобраться в отчете, впрочем, нелегко, так как речь идет не о единичном случае утечки ключей для Secure Boot, а скорее о фундаментальном недосмотре ряда производителей, начало которому было положено еще в 2012 году.



Самое свежее событие в этом таймлайне относится к 2023 году: в январе компания BINARLY обнаружила публичный репозиторий на GitHub, в котором содержался один приватный ключ, в терминах экосистемы Secure Boot известный как Platform Key. Ключ был опубликован на GitHub в декабре 2022 года. Он был зашифрован, но при этом использовался четырехзначный пароль, который легко взломать. Этот ключ играет важную роль в обеспечении безопасности механизма Secure Boot. Потенциальный злоумышленник может с помощью Platform Key сгенерировать так называемый Key Exchange Key, а уже с его помощью подписать вредоносный компонент, который будет выполнен при загрузке компьютера. В итоге возникает риск серьезной компрометации системы, причем вредоносное ПО будет способно пережить полную переустановку ОС. Для реализации атаки потребуется физический доступ к ПК или серверу либо права администратора в системе. Второе вполне достижимо, а физический доступ открывает возможность реализации атаки класса supply chain: когда целая партия компьютеров «модифицируется» в пути от производителя к заказчику. Но самое важное, что это, скорее всего, не единственный приватный ключ, который можно считать скомпрометированным.

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



Меня зовут Александр Пугач, я — Senior .NET Developer в проекте Data Warehouse «Лаборатории Касперского» (да-да, вы могли не знать, но у нас в компании широко используются .NET и «шарпы»).

В этой статье я расскажу, как работать с метриками в .NET на примере OpenTelemetry и Prometheus — систем, которые помогают отслеживать проблемы в работе приложений и быстро на них реагировать, обеспечивая стабильную и отказоустойчивую работу сервисов.

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

Главное событие прошлой недели — масштабный сбой ПК по всему миру, вызванный ошибкой в обновлении защитного ПО компании CrowdStrike. По мере распространения обновления для клиентской программы Falcon часть компьютеров, физических и виртуальных серверов у клиентов CrowdStrike падала в «синий экран», причем вывести подверженные системы из этого состояния зачастую можно было только путем принудительной загрузки в безопасный режим и удаления вызывающего сбой файла вручную. Для крупных организаций с большим количеством устройств это максимально неблагоприятный сценарий, на устранение последствий которого требуется много времени.



Наибольший резонанс вызвала не уникальность данного события (подобное происходит далеко не первый раз), а скорее масштаб сбоя, с которым столкнулись множество людей по всему миру. Среди пострадавших были и представители малого бизнеса, например небольшой мотель в США, в котором перестала работать система электронных ключей, а постояльцам рекомендовали временно блокировать двери каким-нибудь тяжелым предметом, покидая номер. Но больше всего сбой был заметен в крупных организациях: как минимум в трех авиакомпаниях в США, в аэропортах по всему миру, в больницах и в службах быстрого реагирования, в банках, онлайн-сервисах и телекомпаниях (подробнее о последствиях — в этой статье на Хабре) По данным компании Microsoft, сбой затронул 8,5 миллионов систем на Windows по всему миру. Это меньше 1% всех компьютеров и серверов под управлением ОС Microsoft. Проблема в том, что в ряде компаний была временно выведена из строя почти вся инфраструктура. На момент подготовки этого материала технические детали сбоя, его подлинная причина еще неизвестны. Тем не менее масштабный сбой породил массу дискуссий, часть из которых мы разберем.

На прошлой неделе американский сотовый оператор AT&T объявил о масштабной утечке клиентских данных (официальное заявление компании, новость и обсуждение на Хабре). Пострадали практически все клиенты оператора, включая абонентов MVNO, использующих сеть AT&T,— а это как минимум 110 миллионов абонентов сотовой связи, не считая пользователей традиционной телефонии. Утекло то, что можно назвать логами или метаданными: в базе содержатся записи о входящих и исходящих звонках, их дате и длительности, номера телефонов, данные о полученных и отправленных SMS. Об утечке компания узнала еще в апреле и по законам США должна была раскрыть информацию публично, но получила отсрочку от регулятора ввиду чувствительности информации.



Инцидент тесно связан с другими утечками корпоративных данных, произошедшими в апреле–мае этого года и связанными с атаками на плохо защищенные учетные записи в сервисе Snowflake, предоставляющем услуги облачного хостинга. В июне сообщалось о том, что злоумышленники получили доступ к данным 165 клиентов Snowflake, включая, например, испанский банк Santander, сеть магазинов Advance Auto Parts и сервис по продаже билетов на концерты Ticketmaster. По данным компании Mandiant, причиной масштабной атаки не была какая-либо уязвимость в облачном сервисе. Все пострадавшие учетки не были должным образом защищены: доступ к ним был возможен с помощью простой пары логин-пароль, а доступные на сервисе средства многофакторной аутентификации не были активированы. Данные к учетным записям попадали в руки злоумышленников в результате работы вредоносного программного обеспечения.

Важная новость прошлой недели: в библиотеке OpenSSH обнаружена и закрыта уязвимость, получившая название RegreSSHion. Проблему нашли специалисты компании Qualys (общее описание, подробная техническая информация, новость на Хабре). Уязвимость получила идентификатор CVE-2024-6387 и является вариантом совсем древней проблемы в OpenSSH, CVE-2006-5051, закрытой в OpenSSH 4.4 в сентябре 2006 года. Исправление, внесенное 16 сентября 2020 года и попавшее в релиз OpenSSH 8.5 в марте 2021 года, по сути сделало старую уязвимость снова актуальной, отсюда и название: RegreSSHion.



Особенности уязвимости представляют собой набор хороших и плохих новостей. Плохая новость: по оценке Qualys на 1 июня, примерно 14 миллионов доступных из сети SSH-серверов были уязвимы. Впрочем, практическую атаку можно провести примерно в отношении 700 тысяч из них. Хорошая новость: уязвимость не так-то просто эксплуатировать. Уязвимость актуальна для дистрибутивов, использующих стандартную библиотеку glibc. Для успешной атаки потребуется выполнить примерно 10 тысяч подключений к уязвимому серверу, что при стандартных ограничениях на количество одновременных подключений и их длительность потребует 6–8 часов. Плохая новость номер два: если атака все же успешна, то она может дать атакующему права суперпользователя. Реальная атака была продемонстрирована только на 32-разрядном дистрибутиве, в то время как для 64-разрядных систем практического метода эксплуатации пока не существует. Осложняют потенциальную атаку и стандартные средства защиты, такие как ASLR.

На прошлой неделе сразу несколько источников сообщили о компрометации ресурса polyfill.io, раздающего одноименную JavaScript-библиотеку для обеспечения совместимости с устаревшими браузерами (новость, статья на сайте Sansec и ее перевод на Хабре). Библиотека Polyfill распространяется свободно, и ее подгрузка с данного конкретного сайта — не единственный вариант использования. Тем не менее более ста тысяч сайтов подгружали ее именно с polyfill.io, несмотря на предупреждения от бывших разработчиков еще в феврале этого года.



Оригинальный репозиторий Polyfill на GitHub и домен polyfill.io были проданы в конце февраля малоизвестной компании Funnull. Уже тогда высказывались сомнения о безопасности дальнейшего использования библиотеки при ее загрузке с данного URL и предлагались альтернативные источники (помимо варианта self-hosted). Опасения стали реальностью на прошлой неделе: в библиотеку был добавлен код, вызывающий перенаправление на другие веб-сайты через URL, указанные в списке на скриншоте выше. Среди пострадавших веб-сайтов — библиотека JSTOR, сайт компании Intuit, британская газета Metro и многие другие.