Full disclosure: я люблю программное обеспечение SCADA. Мне нравится бесконечная возможность учиться, доступная с простой установкой. Ищете первое переполнение буфера в стеке? Попробуйте SCADA. SQL-инъекция? Попробуйте SCADA! Готовы перейти в NT AUTHORITY/SYSTEM из непривилегированного аккаунта в считанные секунды? Попробуйте SCADA!
Я люблю программное обеспечение SCADA. В любое время, когда я хочу получить больше информации о конкретной классификации ошибок или когда я делаю модификации в моих fuzzing rig , я всегда возвращаюсь к SCADA. Главным образом потому, что это то, с чего я начал, когда я сел на ZDI, но также это никогда не подводило меня в плане получения немедленных результатов.
Недавно я вернулся к одной из моих любимых ошибок - позорному IOCTL Advantech 0x2711. Первоначальная
Интересно, что эта ошибка проходила через программу ZDI несколько раз, и хотя некоторые изменения были сделаны, основная проблема все еще существует. Я думал, что если Advantech не собирается ее исправлять, я буду злоупотреблять ею, донимая их снова и снова в надежде, что им надоест и они исправят ее.
Примечание: я все еще жду этого дня.
Но я хочу потратить немного времени и рассказать вам о моем общем подходе к фаззингу, и в данном конкретном случае продемонстрировать, почему развертывание продукта без современных мер безопасности и с устаревшими стандартами кодирования все еще актуально в 2020 году и остается плохой идеей.
Давайте поговорим о процессе.
Рисунок 1: Процесс фаззинга
Независимо от целевого продукта, мой подход всегда одинаков по своей структуре. Я генерирую что-то (то есть аргументы, ввод на основе файлов и т.д.), изменить его и передаю в приложение с подключенным отладчиком. По истечении заданного промежутка времени я прерываю целевой процесс и записываю результаты. Ошибки будут изолированы, и процесс начнется заново.
После сбоя приложения мне нравится использовать расширение
Рисунок 2: Результаты сбоя
Здесь мы можем открыть журналы отладки и лучше понять причину сбоя приложения. Например, если мы посмотрим на файл журнала для bwmail.exe (ZDI
Рисунок 3: Переполнение буфера в стеке
Если бы мы открыли bwmail.exe приложение в IDA, мы могли бы обнаружить, что основной причиной этой ошибки было использование вызова из
Рисунок 4: первопричина
Если мы пропустим этот вызов и исследуем стек, мы увидим, что он полностью перезаписан нашей полезной нагрузкой. Без ASLR или DEP, о которых стоит беспокоиться, это кажется лучшим кандидатом для написания нашего эксплойта. Но сначала нам нужно убедиться, что мы действительно можем отправить эту атаку по сети.
Рисунок 5: Остаток стека
Чтобы проверить это на RPC, я собираюсь использовать некоторый код, который был опубликован исследователем ZDI
Рисунок 6: Проверка возможности удаленной доставки полезной нагрузки
Чтобы ускорить разработку, я собираюсь использовать windbg реализацию mona, написанную
Рисунок 7: Создание циклического паттерна с моной
Затем мы отправляем этот шаблон обратно в приложение bwmail в качестве аргумента командной строки, и, как и ожидалось, происходит сбой приложения.
Рисунок 8: Сбой на основе циклического шаблона
Как только отладчик выходит из строя при сбое, мы используем findmsp функциональные возможности mona для поиска в памяти процессов приложений всех ссылок на циклический шаблон. Когда я смотрю на вывод таким образом, я сначала проверяю раздел регистров, чтобы найти одно из трех: перезаписать сохраненный указатель возврата (EIP), прямое управление регистром или переписать обработчик структурированных исключений (SEH). В этом конкретном примере мы идем с последним.
Рисунок 9: Нахождение циклического паттерна с помощью функции Моны findmsp
Мона говорит нам, что запись регистрации следующих исключений (nSEH) перезаписывается после отправки 1192 байтов данных. Здорово! Но что теперь?
Используя sehchain функциональность, mona на самом деле напечатает шаблон эксплойта для использования. Давайте взглянем.
Рисунок 10: Предлагаемый формат полезной нагрузки, предоставленный Mona
Для этого нам понадобится 1192 байта данных, шортджамп, инструкция pop/pop/ret и некоторый шелл-код. У нас есть 1192 байта. У нас есть шортджамп. Далее нам нужно расположение набора инструкций pop/pop/ret. Мона seh -n будет искать в памяти процесса эти инструкции и опускать любые результаты, содержащие нулевой байт.
Рисунок 11: Использование mona для поиска инструкций pop/pop/ret
Mona возвращает длинный список допустимых найденных инструкций pop/pop/ret, если библиотека использует преимущества современных средств защиты от эксплойтов, таких как DEP или ASLR. К счастью для нас, ничего из этого не найдено здесь.
Рисунок 12: Результаты
Как только мы добавим наш шелл-код Windows, у нас будет все, что нужно для этого. Собрав все вместе, мы получим нечто, похожее на это:
Рисунок 13: Соединяем все вместе
Вывод
Если вы всегда хотели начать с поиска ошибок и заработать дополнительные деньги, вы не ошибетесь с программным обеспечением SCADA. Отсутствие современных мер по снижению риска и распространению небезопасных методов кодирования делают его сочной целью как для исследователей, так и для злоумышленников. Чего же ты ждешь? Загрузите некоторое программное обеспечение, запустите этот отладчик и отправьте ваши ошибки в ZDI!
Перевод:
Я люблю программное обеспечение SCADA. В любое время, когда я хочу получить больше информации о конкретной классификации ошибок или когда я делаю модификации в моих fuzzing rig , я всегда возвращаюсь к SCADA. Главным образом потому, что это то, с чего я начал, когда я сел на ZDI, но также это никогда не подводило меня в плане получения немедленных результатов.
Недавно я вернулся к одной из моих любимых ошибок - позорному IOCTL Advantech 0x2711. Первоначальная
Ссылка скрыта от гостей
была обнаружена и сообщена в ZDI Стивеном Сили. Я писал об этом в
Ссылка скрыта от гостей
и по какой-то причине я все еще чувствую личную привязанность к этой ошибке. Unauthenticated RCE over RPC as Administrator. Просто ужас. Интересно, что эта ошибка проходила через программу ZDI несколько раз, и хотя некоторые изменения были сделаны, основная проблема все еще существует. Я думал, что если Advantech не собирается ее исправлять, я буду злоупотреблять ею, донимая их снова и снова в надежде, что им надоест и они исправят ее.
Примечание: я все еще жду этого дня.
Но я хочу потратить немного времени и рассказать вам о моем общем подходе к фаззингу, и в данном конкретном случае продемонстрировать, почему развертывание продукта без современных мер безопасности и с устаревшими стандартами кодирования все еще актуально в 2020 году и остается плохой идеей.
Давайте поговорим о процессе.
Рисунок 1: Процесс фаззинга
Независимо от целевого продукта, мой подход всегда одинаков по своей структуре. Я генерирую что-то (то есть аргументы, ввод на основе файлов и т.д.), изменить его и передаю в приложение с подключенным отладчиком. По истечении заданного промежутка времени я прерываю целевой процесс и записываю результаты. Ошибки будут изолированы, и процесс начнется заново.
После сбоя приложения мне нравится использовать расширение
Ссылка скрыта от гостей
для windbg, чтобы помочь с дедупликацией, установкой приоритетов и возникновением сбоев. Для тех, кто не знаком с этим расширением
Ссылка скрыта от гостей
вызывается после сбоя приложения и пытается классифицировать сбой на основе анализа, который оно выполняет. Каждому сбою присваивается категория «Возможности использования» (т.е. «Возможный для использования», «Вероятно, пригодный для использования», «Не пригодный для использования» и т.д.) и хэш, связанный с аварией. Я использую эту информацию для распределения аварий на основные категории. В итоге это выглядит так:
Рисунок 2: Результаты сбоя
Здесь мы можем открыть журналы отладки и лучше понять причину сбоя приложения. Например, если мы посмотрим на файл журнала для bwmail.exe (ZDI
Ссылка скрыта от гостей
), мы увидим, что он завершился сбоем из-за переполнения буфера в стеке.
Рисунок 3: Переполнение буфера в стеке
Если бы мы открыли bwmail.exe приложение в IDA, мы могли бы обнаружить, что основной причиной этой ошибки было использование вызова из
Ссылка скрыта от гостей
API strcpy. Если мы перезапустим приложение и установим точку остановки для этого вызова и сбросим содержимое регистра EAX, мы увидим, что он содержит нашу полезную нагрузку.
Рисунок 4: первопричина
Если мы пропустим этот вызов и исследуем стек, мы увидим, что он полностью перезаписан нашей полезной нагрузкой. Без ASLR или DEP, о которых стоит беспокоиться, это кажется лучшим кандидатом для написания нашего эксплойта. Но сначала нам нужно убедиться, что мы действительно можем отправить эту атаку по сети.
Рисунок 5: Остаток стека
Чтобы проверить это на RPC, я собираюсь использовать некоторый код, который был опубликован исследователем ZDI
Ссылка скрыта от гостей
вместе с его постом в
Ссылка скрыта от гостей
рассказывающем об Advantech и RPC. Для этого я собираюсь использовать две машины: машина с Windows 7 справа - злоумышленник, а машина с Windows 10 слева - жертва. Я присоединяюсь windbgк webvrpcs процессу, включаю отладку и запускаю работу. Как и ожидалось мы можем убедиться, что успешно завершили стек. Время выстаивать эксплойт.
Рисунок 6: Проверка возможности удаленной доставки полезной нагрузки
Чтобы ускорить разработку, я собираюсь использовать windbg реализацию mona, написанную
Ссылка скрыта от гостей
. Мона имеет несколько замечательных функций, которые действительно упростят и ускорят этот процесс. Прежде всего, нам нужно увидеть, в какой момент буфер был перезаписан. Для этого мы можем использовать mona для генерации циклического шаблона - уникальной неповторяющейся строки символов, которую мы можем искать во время отладки.
Рисунок 7: Создание циклического паттерна с моной
Затем мы отправляем этот шаблон обратно в приложение bwmail в качестве аргумента командной строки, и, как и ожидалось, происходит сбой приложения.
Рисунок 8: Сбой на основе циклического шаблона
Как только отладчик выходит из строя при сбое, мы используем findmsp функциональные возможности mona для поиска в памяти процессов приложений всех ссылок на циклический шаблон. Когда я смотрю на вывод таким образом, я сначала проверяю раздел регистров, чтобы найти одно из трех: перезаписать сохраненный указатель возврата (EIP), прямое управление регистром или переписать обработчик структурированных исключений (SEH). В этом конкретном примере мы идем с последним.
Рисунок 9: Нахождение циклического паттерна с помощью функции Моны findmsp
Мона говорит нам, что запись регистрации следующих исключений (nSEH) перезаписывается после отправки 1192 байтов данных. Здорово! Но что теперь?
Используя sehchain функциональность, mona на самом деле напечатает шаблон эксплойта для использования. Давайте взглянем.
Рисунок 10: Предлагаемый формат полезной нагрузки, предоставленный Mona
Для этого нам понадобится 1192 байта данных, шортджамп, инструкция pop/pop/ret и некоторый шелл-код. У нас есть 1192 байта. У нас есть шортджамп. Далее нам нужно расположение набора инструкций pop/pop/ret. Мона seh -n будет искать в памяти процесса эти инструкции и опускать любые результаты, содержащие нулевой байт.
Рисунок 11: Использование mona для поиска инструкций pop/pop/ret
Mona возвращает длинный список допустимых найденных инструкций pop/pop/ret, если библиотека использует преимущества современных средств защиты от эксплойтов, таких как DEP или ASLR. К счастью для нас, ничего из этого не найдено здесь.
Рисунок 12: Результаты
Как только мы добавим наш шелл-код Windows, у нас будет все, что нужно для этого. Собрав все вместе, мы получим нечто, похожее на это:
Рисунок 13: Соединяем все вместе
Вывод
Если вы всегда хотели начать с поиска ошибок и заработать дополнительные деньги, вы не ошибетесь с программным обеспечением SCADA. Отсутствие современных мер по снижению риска и распространению небезопасных методов кодирования делают его сочной целью как для исследователей, так и для злоумышленников. Чего же ты ждешь? Загрузите некоторое программное обеспечение, запустите этот отладчик и отправьте ваши ошибки в ZDI!
Перевод:
Ссылка скрыта от гостей
