последние пару лет российские компании активно используют блокировку по геолокации (сетевой доступ только из РФ). Сканирование shodan'ом ничего не выдаст для таких случаев, только старые записи из БД можно достать.
Если смотреть только на правила, то, скорее всего, так и есть. Панацеи (полноценного «забора»), как и во многих вопросах безопасности, для этой области пока не существует и вряд ли будет, поскольку ситуация у каждого своя. В таких случаях обычно прибегают к централизованному подходу: о чем я и попытался изложить в статье. Если же Вас интересуют конкретные правила, то можете посмотреть их здесь
Еще можно использовать owasp zap — в нем есть несколько модулей для краулинга сайтов, гибкая настройка и приятный бонус в виде удобной АПИшки, которая позволит работать в терминале
mov esi, [ebx + 4*ecx] ; get RVA of next function name
add esi, [ebp + 0x0C] ; base of function name
Т.к. мы не знаем какое значение хранится в этом регистре, его необходимо обнулить, иначе это может нарушить логику программы: «должен» не значит «всегда».
2. «Аверы могут встроить свою длл», AV может проанализировать код и не дать его выполнить еще до начала работы программы, фаервол может не дать соединиться к 4444 порту, EDR может заблокировать некоторые системные вызовы и т.д. и т.п. — это всё, конечно, верно, но выходит за рамки общего шеллкода.
Вы правы, отчасти. Основная причина по который шеллкод должен быть маленьким — отсутствие достаточного места в коде программы в которую внедряется шеллкод. Именно поэтому и существуют техники, например, Socket reuse, egghunter, которые иногда позволяют использовать бОльшие шеллкоды.
Думаю, размер шеллкода играет лишь незначительную роль в скрытности всего эксплоита, поскольку даже эксплоиты для «ванильных» переполнений буферов чаще всего имеют строку, вызывающее переполнение, гораздо большей длины, чем тело самого шеллкода (в качестве примера, можете рассмотреть vulnserver или посмотреть примеры эксплоитов на exploit-db). И если говорить о скрытности, то можно упомянуть об обфускации тела шеллкода, чтобы сигнатурный анализ не выявил угроз, полиморфизма, использовании нестандартных системных вызовов для установления соединения (такой пример можете рассмотреть вот здесь) и т.д.
Целью статьи было рассмотрение наиболее общего примера создания шеллкода — программы, которая позволяет получить удаленный доступ в командную оболочку в самом общем её понимании и это написано в начале статьи. Различные доработки, например такие как: избавление от нулевых байтов (а ведь с ними шеллкод не будет работать при передаче его по сети), уменьшения размера за счёт избавления от «ненужных» команд, возможность многократного подключения, обработка всех исключений и т.д. во-первых, изучаются после основ, а во-вторых, применяются далеко не всегда.
Это шеллкод и для него размер имеет важное значение. Создание дополнительных обработчиков ошибок и проверок увеличат его длину. Поэтому при написании шеллкодов такими вещами обычно пренебрегают.
В то же время я решил оставить, например, создание стекового фрейма для функций, чтобы пример был понятнее. В большинстве руководств по созданию шеллкодов Вы также не найдете этих проверок по вышеупомянутой причине.
Думаю, всё зависит от конкретных целей использования. Для прохождения курса и получения базовых навыков отладки GDB вполне достаточно и мне удобно «не вылезать» из консоли во время работы. Расширение Peda помогает в работе с «голым» GDB. Из графических могу порекомендовать edb debugger.
Согласен, однако наш мир не идеален и человеческий фактор почти всегда присутствует. Пентест отчасти и нужен для того, чтобы таких ошибок было как можно меньше, ведь даже крупные компании могут допускать такие промахи: Github authorization bypass vulnerability
В рамках интроспекции Вы сначала узнаете какие запросы существуют в принципе, затем какие есть поля у каждого запроса можно узнать по примеру 3, что в статье. Чтобы точнее понять, какие поля есть и что из них что означает рекомендую потестировать приложения, указанные в начале статьи. После этого многие вопросы сами решатся.
GraphQL дырявый ровно настолько, насколько это реализует разработчик. Нельзя сказать дырявый REST или нет? Дырявый GraphQL или нет? Это стандарты, которые описывают то, как должно быть устроено API-приложение. А дырявым Вы его сделаете или нет — решать Вам.
последние пару лет российские компании активно используют блокировку по геолокации (сетевой доступ только из РФ). Сканирование shodan'ом ничего не выдаст для таких случаев, только старые записи из БД можно достать.
так для этого придуманы заголовки
За перекрытие шифра мой преподаватель по криптографии расстреливал на месте
Еще можно использовать owasp zap — в нем есть несколько модулей для краулинга сайтов, гибкая настройка и приятный бонус в виде удобной АПИшки, которая позволит работать в терминале
Т.к. мы не знаем какое значение хранится в этом регистре, его необходимо обнулить, иначе это может нарушить логику программы: «должен» не значит «всегда».
2. «Аверы могут встроить свою длл», AV может проанализировать код и не дать его выполнить еще до начала работы программы, фаервол может не дать соединиться к 4444 порту, EDR может заблокировать некоторые системные вызовы и т.д. и т.п. — это всё, конечно, верно, но выходит за рамки общего шеллкода.
Думаю, размер шеллкода играет лишь незначительную роль в скрытности всего эксплоита, поскольку даже эксплоиты для «ванильных» переполнений буферов чаще всего имеют строку, вызывающее переполнение, гораздо большей длины, чем тело самого шеллкода (в качестве примера, можете рассмотреть vulnserver или посмотреть примеры эксплоитов на exploit-db). И если говорить о скрытности, то можно упомянуть об обфускации тела шеллкода, чтобы сигнатурный анализ не выявил угроз, полиморфизма, использовании нестандартных системных вызовов для установления соединения (такой пример можете рассмотреть вот здесь) и т.д.
Целью статьи было рассмотрение наиболее общего примера создания шеллкода — программы, которая позволяет получить удаленный доступ в командную оболочку в самом общем её понимании и это написано в начале статьи. Различные доработки, например такие как: избавление от нулевых байтов (а ведь с ними шеллкод не будет работать при передаче его по сети), уменьшения размера за счёт избавления от «ненужных» команд, возможность многократного подключения, обработка всех исключений и т.д. во-первых, изучаются после основ, а во-вторых, применяются далеко не всегда.
Про fasm спасибо, посмотрю.
В то же время я решил оставить, например, создание стекового фрейма для функций, чтобы пример был понятнее. В большинстве руководств по созданию шеллкодов Вы также не найдете этих проверок по вышеупомянутой причине.
Github authorization bypass vulnerability