Использование open source в KasperskyOS

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

https://habr.com/ru/companies/kaspersky/articles/921684/

#иб #kasperskyos #операционные_системы #системное_программирование #драйверы #linux #микроядро #песочница #модель_угроз #атака_на_цепочку_поставок

[Перевод] Как мы взломали цепочку поставок и получили 50 тысяч долларов

В 2021 году я только начинал свой путь в наступательной безопасности. Я уже взломал довольно много компаний и получал стабильный доход охотой за баг-баунти — практикой этичного хакинга, при которой исследователи безопасности находят уязвимости и сообщают о них, получая за это вознаграждение. Однако я ещё не достиг уровня, позволившего бы мне быстро обнаруживать критические уязвимости цели. Этот уровень умений казался мне недостижимым. Но всё поменялось, когда я познакомился с человеком, ставшим ключевой фигурой в моей карьере баг-баунти: Snorlhax . Поначалу я видел в нём конкурента. Он был намного выше меня во французской таблице лидеров HackerOne , что стимулировало меня расти над собой. Мы начали общаться в Discord, и спустя несколько недель я рассказал ему о многообещающей программе баг-баунти. Вскоре после этого он обнаружил у этой цели критическую уязвимость, оценённую в 10000 долларов — сумму вдвое больше, чем максимальная полученная мной от этой же цели. Мотивировавшись этим, я вернулся к этой же цели и за ту же неделю нашёл собственную критическую уязвимость за 10000 долларов в другом классе багов. Вместо того, чтобы продолжать состязаться, мы решили сотрудничать. Теперь нашей задачей стало выявление у этой цели всех возможных классов багов: IDOR, SQL-инъекций, XSS, багов OAuth, Dependency Confusion, SSRF, RCE и так далее. Все их мы нашли, сообщили компании и написали отчёты. Это сотрудничество длилось несколько лет, и даже сегодня мы время от времени снова возвращаемся к этой цели. Однако недостижимой оставалась одна задача: обнаружение «чудовищной уязвимости». Это должен быть настолько критичный баг, что нам выплатят нестандартное вознаграждение, намного превышающее обычные выплаты. Это стало для нас главной целью. В посте я расскажу, как мы со Snorlhax наконец-то этого добились.

https://habr.com/ru/companies/ruvds/articles/885950/

#docker #npm #атака_на_цепочку_поставок #уязвимости #bug_bounty #багбаунти #ruvds_перевод

[Перевод] Как уберечься от кражи репозитория (реподжекинга)

Реподжекинг или захват репозитория / перехват контроля над репозиторием — это особый вид атак на цепочки поставок. В этой статье поговорим о том, что это такое, каков риск и как можно себя обезопасить. Этот тип атаки привлёк мое внимание из-за своего потенциального влияния на программное обеспечение с открытым исходным кодом. В этой статье я объясню, что такое захват репозитория и что можно сделать, чтобы оставаться в безопасности. Говоря вкратце: если вы получаете все свои программные зависимости из менеджера пакетов — например, npm или PyPI , то эта атака не может на вас повлиять. Если вы берёте зависимости напрямую с GitHub, нужно быть более осторожными, но есть простое решение — заблокировать определённый ID коммита. Я поясню, как это сделать, в нескольких наиболее распространённых сценариях.

https://habr.com/ru/companies/otus/articles/824374/

#репозиторий #Реподжекинг #атака_на_цепочку_поставок