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

Вот, например, список токенов из дизайн-системы 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 и многие другие.

Undefined behavior (UB) — боль, знакомая каждому разработчику со стажем; эдакий «код Шредингера», когда не знаешь, правильно тот работает или нет. К счастью, стандарты языка С++20/23/26 привнесли относительно неопределенного поведения кое-что новое. И довольно важное, если вы — архитектор ПО, а «плюсы» — ключевой стек вашей компании (подробнее о том, как и почему мы в «Лаборатории Касперского» много используем С++, читайте здесь).

В этой статье я со своих позиций Senior Software Architect и Security Champion в микроядерной операционной системе KasperskyOS рассмотрю кейсы-ловушки, в которые можно попасть практически в любом из стандартов, и покажу, что меняется в С++20/23/26, — уменьшается ли количество кейсов с неопределенным поведением, и становится ли С++ безопаснее.

В свежем исследовании специалистов «Лаборатории Касперского» подробно анализируется стойкость типичных пользовательских паролей к перебору. Главный вывод работы — 59% паролей могут быть взломаны менее чем за час. Для этого была проанализирована огромная база из 193 миллионов паролей, обнаруженных в свободном доступе на различных ресурсах в даркнете. Авторы исследования рассматривали вполне реалистичный сценарий, при котором атакуется база паролей пользователей какого-либо сервиса. Исключается самый печальный сценарий, при котором пароли хранятся в открытом виде. Если пароли захешированы с солью, такие хеши по сути необратимы, но с помощью перебора можно установить соответствие реального пароля и его хеша.



Для измерения времени подбора требуется задать целевую производительность. В качестве референса была выбрана видеокарта RTX 4090 — решение недешевое, но тем не менее повсеместно доступное. Скорость подбора в такой конфигурации составляет 164 миллиарда хешей в секунду. Пожалуй, самый положительный вывод статьи заключается в том, что сложные пароли в базах утечек встречаются не так уж и редко. 28% паролей состоят из заглавных и строчных символов, содержат цифры и спецсимволы. Брутфорс 85% таких паролей займет больше года. Впрочем, речь идет о самом прямолинейном методе полного перебора. В исследовании оцениваются и более эффективные способы.

На прошлой неделе исследователи «Лаборатории Касперского» опубликовали подробный отчет о поиске уязвимостей в биометрическом терминале компании ZKTeco. Терминал обеспечивает распознавание пользователей по лицу, но также предоставляет резервные методы аутентификации: по пин-коду и с помощью QR-кода, который сканируется встроенной фотокамерой. В статье подробно описывается типичный процесс исследования устройства для поиска аппаратных и программных уязвимостей, включая анализ «железа», физических и сетевых интерфейсов, исследование прошивки. Не меньший интерес представляет и список найденных уязвимостей: всего их было обнаружено 24 штуки. Авторы работы приходят к выводу, что передовая технология была реализована в крайне небезопасном виде.


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

Стресс, связанный с переходом на менеджерскую роль, способен пошатнуть любые, даже самые крепкие нервы. А если ваше решение стать руководителем желанное и осознанное, то вы легко можете загнать себя в ловушку из двух стен: тревожности и перфекционизма.

Меня зовут Александр Шиндин, я — технический менеджер мобильных продуктов Kaspersky Password Manager и Kaspersky Who Calls. Я так сильно хотел проявить себя в роли руководителя, что внутренних обучающих курсов, которые дает в таких случаях компания, мне не хватало, — и лучшим дополнением к теории стали книги. Они ускорили мое погружение в мир менеджмента, помогли быть готовым к еще большему числу нестандартных ситуаций и придали уверенности в принимаемых решениях.

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

В пятницу 7 июня компания Microsoft сообщила о внесении изменений в работу фичи Microsoft Recall. Представленная ранее функция пока недоступна обычным пользователям и какое-то время будет работать только на ноутбуках Microsoft Surface и устройствах других производителей на базе новейших процессоров Qualcomm Snapdragon X. Microsoft Recall каждые несколько секунд делает скриншот экрана, распознает его содержимое, сохраняет информацию в базу данных и предоставляет пользователям возможность поиска по этой базе. По замыслу разработчиков, это должно значительно упростить жизнь владельца компьютера с вновь введенным обозначением «Copilot+ PC». Можно отыскать сайт, который вы когда-то посещали, по общему описанию типа «статья про домики красного цвета», вытащить из «истории» случайно удаленный текст и так далее. В некотором смысле Recall расширяет возможности, которые нам предоставляют сейчас разрозненные сервисы: поиск по архиву электронной почты и сообщений в мессенджере, история перемещений («где находится ресторан, в котором я был год назад»). Все это возможно благодаря сбору и хранению огромного массива данных обо всех аспектах деятельности пользователя. И именно это является проблемой.

«Взлом» криптокошелька, пароль к которому был утерян больше 10 лет назад, — это самая красивая история по теме кибербезопасности на прошлой неделе. Пожелавший остаться анонимным пользователь приобрел биткоины на сумму примерно 4000 евро в 2013 году. Криптовалюта хранилась в цифровом кошельке, доступ к которому был защищен паролем. Известный исследователь Джо Гранд на пару с коллегой помогли владельцу криптокошелька восстановить пароль, и не при помощи простого перебора, а, как правильно отметили в обсуждении на Хабре, «решив проблему мозгами». Джо Гранд любит подавать свои истории красиво, он снял видео и дал интервью журналу Wired, где использовал красивые и понятные более широкой аудитории метафоры типа «мы нашли способ повернуть время вспять».


Реально интересная техническая информация этой работы, впрочем, уместилась на одну страницу текстом. Для облегчения «взлома» криптокошелька хакерам требовалось уменьшить количество возможных вариаций пароля для перебора. Им удалось это сделать благодаря одной особенности программы RoboForm, которую владелец кошелька использовал для генерации пароля. И это, пожалуй, самое интересное: анализ старой версии RoboForm показывает нам пример, как не надо генерировать случайные последовательности символов.

Вы — разработчик и хотя бы раз говорили тестировщику «докажи руками»? Или вы — тестировщик и хотя бы раз слышали такое от коллег-разрабов? Либо вы — продакт или тимлид, в команде которого случались или могут случиться такие конфликты? Тогда эта статья для вас!

Кто-то после «а докажи, что это все действительно работает» или «а как ты проверял?» звереет и начинает открыто ругаться с коллегами — что ж, устраивать холивары, конечно, интересно, но бесполезно. Кто-то действительно начинает тратить ресурсы на воспроизведение бага. Однако можно выстроить такой процесс коммуникации, в котором разработчик доверяет результатам команды тестирования и даже иногда сам дополняет тесты, при этом не скатываясь в оверинжиниринг.



Меня зовут Илья Колесов, я — Senior SDET (Software Development Engineer in Test) в команде KasperskyOS Automotive & Embedded Quality Control «Лаборатории Касперского» и занимаюсь разработкой автоматизированных тестов на стыке embedded- и desktop-систем. В этой сфере я прошел весь путь с нуля до готовых решений. И в этой статье расскажу о взаимодействии с разработкой через автоматизацию тестирования — поделюсь своим опытом того, как удается преодолеть недоверие и сделать коммуникации более эффективными.

17 мая компания WatchTowr Labs опубликовала результаты исследования прошивки популярных сетевых устройств Qnap. Аудит программного обеспечения выявил 15 уязвимостей, из которых только 4 были закрыты на момент публикации. Авторы исследования анализировали «облачную» версию ПО QuTSCloud, а затем удостоверялись, что обнаруженные проблемы применимы к реальным устройствам. Отчет подробно разбирает один из пятнадцати багов, имеющий идентификатор CVE-2024-27130. Его эксплуатация может приводить к выполнению произвольного кода на устройстве QNAP и получению полного контроля над ним. Интерес представляет как сама уязвимость, так и подробное изложение методов ее обнаружения авторами отчета.



Работа началась с изучения содержимого виртуальной ОС QuTSCloud, где исследователи обнаружили большое количество кода, написанного на C, а в нем — немало типичных ошибок, способных приводить к повреждению памяти. Авторам отчета довольно быстро удалось вызвать ошибку в выполнении функции, обрабатывающей сценарии общего доступа к файлам. Это стандартная фича любого NAS, которая позволяет создать ссылку на файл, хранимый на устройстве, поделиться ей с коллегами или даже выложить в открытый доступ. Возможность вызвать сбой при работе с этим публичным интерфейсом — уже проблема сама по себе, но для потенциального атакующего есть важное ограничение: он должен знать уникальный идентификатор, который предоставляет доступ к какому-либо файлу на устройстве.

13 мая компания Apple обновила операционные системы iOS и iPadOS для мобильных устройств до версии 17.5. Всего в этом патче было исправлено более 15 уязвимостей, включая, например, возможность открывать заметки на заблокированном устройстве. Более серьезная проблема была исправлена в ядре iOS: уязвимость с идентификатором CVE-2024-27818 могла приводить к падению приложений, но также делала возможным выполнение произвольного кода.



Как сообщает сайт MacRumours, помимо решения проблем обновление добавило один новый и достаточно серьезный баг, приводящий к нарушению приватности. Сразу после выпуска iOS/iPadOS 17.5 появились сообщения о том, что на мобильных устройствах Apple начали появляться ранее удаленные фото. Во всех случаях отмечалось, что фотографии старые — добавленные не позднее 2017 года, а в некоторых случаях речь шла о совсем древних изображениях, созданных в 2010 году. Это можно было посчитать досадным, но безобидным багом, если бы не еще одно сообщение. В нем утверждалось, что старые фотографии появились на устройстве, отвязанном от учетной записи Apple ID, которое было продано новому владельцу.

7 мая исследователи «Лаборатории Касперского» опубликовали отчет со статистикой по обнаружению и эксплуатации уязвимостей в ПО. В публикации приводятся цифры за первый квартал 2024 года, по ряду параметров они сравниваются с данными с начала прошлого года.



Начнем с безусловно хороших новостей: количество обнаруженных и зарегистрированных в базе CVE уязвимостей неуклонно растет с 2019 года. В качестве причины авторы отчета указывают как распространение программ bug bounty, так и более широкое использование инструментов и методик для создания более безопасного кода. Для любого конкретного программного обеспечения рост обнаруженных уязвимостей не стоит расценивать как провал разработки. Наоборот, это косвенный признак более внимательного отношения к ПО с точки зрения безопасности.

1 мая исследователи из компании Microsoft рассказали об уязвимости в ряде приложений для платформы Android. Эта уязвимость в некоторых случаях позволяет выполнять произвольный код и полностью контролировать легитимное приложение. В публикации подробно описан интересный способ повышения привилегий, в котором задействована стандартная для Android фича обмена файлами между установленными программами. Проблема относится к типу path traversal: злоумышленник может модифицировать имя файла так, что он будет сохранен не в предназначенной для такого обмена локации, а в произвольном месте, где у приложения-жертвы имеется доступ на запись. Соответственно, имеет место и недостаточный контроль за входящими файлами.



Схема атаки показана выше на иллюстрации из отчета Microsoft. Реальная атака с использованием такой уязвимости может выглядеть следующим образом. Пользователь устанавливает вредоносное приложение, которое при этом само не запрашивает особых прав на доступ к информации в смартфоне или планшете. Приложение без ведома пользователя через стандартные возможности API Android инициирует обмен данными с уязвимой программой. В нормальных условиях этот обмен файлами используется, например, чтобы загрузить фотографию в соцсеть из Галереи или приложить файл к письму в почтовом клиенте. Модифицируя имя файла по стандартным для подобных багов паттернам, например добавляя команду на переход в предыдущую директорию, злоумышленник может сохранить файл в произвольную точку. В Microsoft выявили два очень популярных приложения, которые оказались уязвимыми для подобной атаки: штатный менеджер файлов для телефонов Xiaomi и офисный пакет WPS Office. Обе программы установлены на сотни миллионов устройств.

На прошлой неделе издание New York Times показало конкретные примеры того, как автопроизводители могут следить за пользователями, пользуясь большим количеством датчиков в автомобиле. Эта история началась еще в марте, когда то же издание впервые сообщило, что компания General Motors передает информацию о поведении водителей за рулем сторонним брокерам. Используя право на доступ к персональной информации, журналистка Кашмир Хилл запросила данные о семейном автомобиле Chevrolet Bolt, который был приобретен в 2023 году.


Информация у крупных брокеров данных LexisNexis и Verisk оказалась весьма подробной: общее количество поездок, километраж, а главное — число событий, когда имел место резкий разгон или торможение, либо превышение скорости. Эти данные впоследствии перепродаются страховым компаниям, которые на их основе могут принять решение о повышении страхового тарифа. Важной особенностью такого персонального расследования стало то, что Кашмир Хилл и ее муж, скорее всего, не давали согласия на сбор таких данных. Или как минимум сделали это, не понимая в полной мере, что эта информация будет доступна кому-то еще, кроме автопроизводителя. В такой же ситуации оказались примерно 8 миллионов владельцев автомобилей концерна GM. Так вышло, что все они обменяли свою приватность на геймификацию вождения, когда автомобиль выдает вам «бейджики» за разного рода достижения за рулем.