1807
Чат для обсуждения DevSecOps и постов канала @sec_devops Вакансии: @appsec_job Услуги: https://radcop.online/
Это про базы данных же? PL/SQL функции в биде?
Читать полностью…
Это просто общими словами описано, ибо по другому в широком смысле не описать. Вон, Алексей выше приеме привёл
Читать полностью…
Любые фунции. Блокировка после 5 неправильных попыток ваода пароля, запрос авторизации при критичных действиях, возможность посмотреть журнал событий и т.д.
Читать полностью…
Есть у приложения набор функций и вот проверять получается безопасность этой самой функциональности
Читать полностью…
Использование "в принципе плохих практик" - классика для аппсек/девопс 🤡😅👍
Читать полностью…
Автоматическое слияние в принципе плохая практика
Читать полностью…
Да, такое тоже было, я знал некоторые проекты глобального плана, на которые не было денег. Хуже, когда оказывалось, что они появились и теперь нужны ресурсы, которым денег дать можно и нужно переделать. Тут начиналась ржака: условно было большое ядро и регион или бизнес теперь с деньгами после пары лет без денег был пользователем ядра на 30%... а переписывать и подернизировать за их счет считай все ядро. И соседи начинали потирать ручки: ну вы сделайте , а мы потом на вас переедем)))
Читать полностью…
Обычно всё заканчивалось тем что "ресурсы у нас ограничены, денег нет, кодеры загружены, ты сам понимаешь" ну и это вот всё такое
Читать полностью…
Так а чем закончилось?
Завершили или отменили и вернулись к легаси?
Зависит от объема, аккаунтов 10 внутренних команд за месяц можно перевести, если оно 24х7 используется и нужно тестирование отдельное и разработка плюс есть волевое решение сверху.
Если же у тебя полупубличный сервис по оферте и 1000акков... нуууу... такоэээ
Бороду рубить (отказаться от легаси) никак? Придумывать костыли для легаси как-то плохо звучит
Читать полностью…
Я работал в других реалиях, там была единая система, в которой были заведены все учетные записи и IT Sec Audit регулярно требовал наличие "живого" владельца служебной учётки, а так же у служебных учеток был тип атентификации. Самый ад было переводить подконтрольные на сайберарк
Читать полностью…
Ревью и аудит при любом раскладе нужны, непонятно, как сущность «сервисный токен» ломает их
Читать полностью…
Я видел в регламентах необходимость СУЗ и СпУЗ, но выглядит как пережиток эпохи.
Читать полностью…
Это тип учетной записи или контейнер для нее с разными политиками
Читать полностью…
Авторизация аутентификация, хэширование
Смысл подтвердить что оно впринципе работает как надо по дефолту
Не надо путать оффенсив и дефенсиф (разный скоуп и другие нюансы)
Читать полностью…
просто это как-будто про пентест больше
Читать полностью…
Ребят, подскажите, пожалуйста, я вот в DAF нашёл пункты про Функциональное ИБ-тестирование. У вас есть опыт добавления таких тестов в QA? что вообще можно проверять таким образом ? брутфорс?
Читать полностью…
на gitverse что-то похожее на github actions, может и актуально в РФ
Читать полностью…
GitHub Actions Exploitation
Мы редко пишем про векторы атак и уязвимости, связанные с GitHub Actions, так как в России платформа по понятным причинам не используется. С другой стороны у нас есть читатели и не из России, а за каждой конкретной атакой скрываются полезные концептуальные идеи и универсальные принципы. Поэтому когда мы нашли блог SynAcktiv, где они делятся увлекательными атаками на GitHub Actions, мы были просто обязаны этим поделиться.
Итак, рассмотрим одну из интересных атак. Атака на цепочку поставок CI через инструменты безопасности, а именно через Dependabot, сканер уязвимых зависимостей!
1) Атакующий создаёт форк репозитория, куда собирается заинжектить вредонос.
2) Затем он тригерит работу Dependabot, который делает pull request (PR) в созданный форк, предлагая обновить библиотеку до безопасной версии. При этом создаётся новый форк от Dependabot для слияния. На этом этапе авторы нашли способ изменить то, что именно добавляется в PR от Dependabot, и внедрить вредоносный код (посредством излечение секрета бота через self-hosted runners и коммуникации с Dependabot API). Хотя это уже звучит угрожающе, при внимательном ревью PR вредоносные файлы все равно могут быть обнаружены, поэтому давайте продолжим цепочку эксплуатации.
3) Далее атакующий берёт новый PR, созданный Dependabot, и вместо слияния со своим форком отправляет его в основной бранч репозитория жертвы (main). GitHub позволяет изменить цель PR, перенаправив его из одного бранча в другой. В этом случае, хотя PR и был создан ботом, авторство будет приписано атакующему, так как он инициировал действия, а не сам Dependabot.
В обычной ситуации на этом всё должно было бы закончиться, но не в случае с авторами репозитория spring-security. Они намудрили с actions на GitHub, разрешив автоматическое слияние PR, если github.actor == 'dependabot[bot]'. Проблема в том, что в контексте GitHub github.actor — это не автор бранча, а последний пользователь, совершивший действие с PR!
4) Атакующий вызывает Dependabot повторно в своём PR в main, после чего уязвимый workflow автоматически сливает PR, включая вредоносный код.
Фикс в данном случае - использовать github.event.pull_request.user.login, а не github.actor, который выдает именно автора PR как и ожидается.
SynAcktiv также поддерживает собственный инструмент octoscan для анализа безопасности GitHub Actions, куда они уже добавили файндинги со своих ресерчей.
Среди других статей от них мы также рекомендуем ознакомиться с Introduction, где авторы разбирают базовые аспекты атакующего на GitHub Actions, а также со статьей про Untrusted Input.
Здесь важно понимать, что данная проблема не является уникальной для GitHub; аналогичные проблемы и векторы атак могут возникнуть в любом элементе цепочки поставок. Обратите внимание на причины, которые привели к появлению уязвимости:
- Наличие вызовов в платформе GitHub, название которых говорит совсем не о том, как их воспринимает конечный пользователь с позиции "здравого смысла".
- Использование вызовов авторами, не до конца разобравшимися в их логике работы.
- Автоматический обход ревью, основанный на неочевидных скриптах, которые могут быть использованы широким кругом лиц...
А если вы еще пока далеки от темы CI/CD Security, но хотите с легкостью понимать, о чем здесь идет речь, вот вам awesome ci-cd attacks, где есть и Threat Matrix, use cases, инструменты и многие другие ресерчи.
#cicd
Мы были регулируемая организация, международный банк, это условно аудит КПМГ и отчет инвесторам и регуляторам, что мы не подпадаем под бестпрактис.
Выбирали самый дешевый вариант: считали проекты на полностью переписать или поменять только логику коннектора.
Но сделать было надо.
Иногда наблюдал исключения из модели рисков, когда не меняли саму логику, но обезопашивали все вокруг. Типа фаерволлом закрывали только на одну айпишку и прикрепляли доки, что это летает только по внутренней сети без сильных рисков быть тисипидампнутым - условный пример
Просто тоже интересно. Сколько с этим легаси работаю, ни разу ещё не было такого чтобы руководство согласно было бы на его отмену/переработку
Читать полностью…
Ну вот я делал внутри компании. Некоторые проекты шли месяцами, потому как какая-нибудь система имела только L1 саппорт и надо было найти внутренний бюджет и "программиста"
Читать полностью…
Есть способы, но достаточно дорогие. Интересно послушать, может кто-то делал что-то подобное и отказывался / продолжал это использовать?
Читать полностью…
Ну, они правильно делали, но «живой» пользователь нужен только для того, чтобы можно было ему письмо написать, а не то, что он сам пользуется этой учеткой
Читать полностью…
Еще момент, что сервисные токены можно валидировать на апи гейтвей напрямую, не делая дорогие походы в тот же LDAP/ActiveDirectory
Читать полностью…
А потом политики протухли и выяснялись, что бот полноценный человек
Читать полностью…
Учетная запись нужна в любой системе, поддерживающей выгрузку: ревью логинов с ответственными лицами, круто, если еще последнее время логина видно (используется или нет)
Читать полностью…