Комментарии 2
Хорошее учение и статья, но несколько вопросов:
1. какой процент занимали атаки от общего объёма трафика в стенде?
2. участники знали что защищать надо будет сайт или они должны были быть готовы к чему угодно?
3. атакующие могли изменить атаку (например изменить пейлоад для десериализации или подправить нагрузку для команд инжекшен)?
4. защита могла внедрять waf и подобные средства (например резать ответы в которых содержится слово полигон)?
5. какие итоги учения (если я правильно понял из видео, то все 5 уязвимостей никто не смог закрыть?)
1. какой процент занимали атаки от общего объёма трафика в стенде?
2. участники знали что защищать надо будет сайт или они должны были быть готовы к чему угодно?
3. атакующие могли изменить атаку (например изменить пейлоад для десериализации или подправить нагрузку для команд инжекшен)?
4. защита могла внедрять waf и подобные средства (например резать ответы в которых содержится слово полигон)?
5. какие итоги учения (если я правильно понял из видео, то все 5 уязвимостей никто не смог закрыть?)
Спасибо!
Извините, что задержались: ушли с головой в написание райтапов и итогового отчета по тренингу.
Спешим ответить на ваши вопросы:
1. Примерно половину: к сервисам участников производились обращения чекера как для проверки работоспособности стенда, так и для эксплуатации уязвимостей. Участники были осведомлены об атаке, поэтому сокрытие трафика намеренно не осуществлялось.
2. Участники должны были защищать свое веб-приложение полностью. Т.е. не только сайт, но и связанные с ним компоненты, например базу данных.
3. Атакующие подготовили несколько вариантов полезной нагрузки. Они все сводились к одному и отличались по большей части синтаксически. Целеноправленно полезная нагрузка не менялась: на наш взгляд, это затруднило бы подсчет баллов и снизило общую объективность оценки.
4. Да, участники могли применять средства фильтрации трафика и иные средства защиты. Блокировать все запросы, содержащие фразу «polygon», было бы не очень хорошей идеей, ведь данное слово встречается и в легитимных ответах от серверов. Во время проверки функциональности сервис участников был бы помечен как неработоспособный, что привело бы к падению SLA.
5. Со всеми итогами можно ознакомиться в нашем отчете по ссылке cyberpolygon.com/ru/results-2020
Извините, что задержались: ушли с головой в написание райтапов и итогового отчета по тренингу.
Спешим ответить на ваши вопросы:
1. Примерно половину: к сервисам участников производились обращения чекера как для проверки работоспособности стенда, так и для эксплуатации уязвимостей. Участники были осведомлены об атаке, поэтому сокрытие трафика намеренно не осуществлялось.
2. Участники должны были защищать свое веб-приложение полностью. Т.е. не только сайт, но и связанные с ним компоненты, например базу данных.
3. Атакующие подготовили несколько вариантов полезной нагрузки. Они все сводились к одному и отличались по большей части синтаксически. Целеноправленно полезная нагрузка не менялась: на наш взгляд, это затруднило бы подсчет баллов и снизило общую объективность оценки.
4. Да, участники могли применять средства фильтрации трафика и иные средства защиты. Блокировать все запросы, содержащие фразу «polygon», было бы не очень хорошей идеей, ведь данное слово встречается и в легитимных ответах от серверов. Во время проверки функциональности сервис участников был бы помечен как неработоспособный, что привело бы к падению SLA.
5. Со всеми итогами можно ознакомиться в нашем отчете по ссылке cyberpolygon.com/ru/results-2020
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Attack-defence для бизнеса: разбираем задания корпоративного тренинга Cyber Polygon