Я люблю программное обеспечение SCADA. Я люблю бесконечные возможности процесса обучения, с доступной и простой установкой. Ищете первое переполнение буфера в стеке? Попробуйте SCADA. SQL-инъекция? Попробуйте SCADA! Готовы перейти в NT AUTHORITY/SYSTEM с непривилегированного аккаунта в считанные секунды? Попробуйте SCADA!
Если серьезно. Я люблю программное обеспечение SCADA. В любое время, когда я хочу получить больше информации о конкретной классификации ошибок или когда я делаю модификации в своем фаззинг инструменте, я всегда возвращаюсь к SCADA. Главным образом потому, что это то, с чего я начал, когда стал присылать баги в ZDI, но это также никогда не подводило меня с точки зрения нахождения немедленных результатов. В плане поиска багов в SCADA.
Pwn2Own Miami прямо за углом, я хотел очень сильно вернуться туда с одним из моих любимых багов - позорном IOCTL Advantech 0x2711. Первоначально баг был обнаружен и отрепорчен в ZDI Стивеном Сили. Я писал об этом в 2018 году и по какой-то причине я все еще чувствую личную привязанность к этому багу. Не аутентифицированный RCE через RPC администратора. Это просто ужас.
Интересно, что этот баг проходил через программу ZDI несколько раз, и хотя некоторые изменения были сделаны, основная проблема все еще существует. Я думал, что если Advantech не собирается это исправлять, я буду злоупотреблять этим и просто буду бить их снова и снова в надежде, что им надоест слушать меня и наконец они закроют багу.
Примечание: я все еще жду этого дня.
Но я хочу потратить немного времени и рассказать о моем общем подходе к фаззингу, и в данном конкретном случае продемонстрировать, почему развертывание продукта без современных мер безопасности с устаревшим стандартом кодирования все еще актуальная проблема в 2020 году.
Давайте поговорим о процессе.
Рисунок 1: Процесс фаззинга
Независимо от целевого продукта, мой подход всегда придерживается одной и той же структуры. Я собираюсь сгенерировать что-то (то есть аргументы, ввод на основе файлов и т. Д.), Изменить его и передать в приложение с присоединенным отладчиком. По истечении заданного промежутка времени я прерву целевой процесс и запишу результаты. Креши будут изолированы, и процесс начнется заново.
После сбоя приложения я хотел бы использовать расширение !Exploitable для windbg, чтобы помочь с дедупликацией и установлением приоритетов и возникновением сбоев. Для тех, кто не знаком с этим расширением, !Exploitable вызывается после сбоя приложения и пытается классифицировать сбой на основе анализа, который он выполняет. Каждому сбою присваивается категория «Возможность эксплуатации» (т.е. «Возможный для эксплуатации», «Вероятно, пригодный для эксплуятации», «Не пригодный для эксплуатации» и т. д.) И хэш, связанный с крешем. Я использую эту информацию, чтобы распределить падения на основные категории. В итоге это выглядит так:
Рисунок 2: Результаты сбоя
Отсюда мы можем открыть журнал отладки, чтобы лучше понять причину сбоя приложения. Например, если мы посмотрим на файл журнала для bwmail.exe (ZDI-18-047, репорт предоставленный Стивеном Сили ), мы увидим, что он завершился сбоем из-за переполнения буфера в стеке.
Рисунок 3: Переполнение буфера в стеке
Если бы мы открыли bwmail.exe в IDA Pro, мы могли бы обнаружить, что основной причиной этой ошибки было использование вызова из запрещенного списка 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). В этом конкретном примере нам нужно начинать с перезаписи SEH.
Рисунок 9: Нахождение циклического паттерна с помощью функции Моны findmsp
Мона говорит нам, что запись регистрации следующих исключений (nSEH) перезаписывается после отправки 1192 байтов данных. Достаточно много байтов данных для перезаписи. Но что теперь?
Теперь используем sehchain, mona на самом деле напечатает шаблон-скелет эксплойта для использования. Давайте взглянем.
Рисунок 10: Предлагаемый формат полезной нагрузки, предоставленный Mona
Для этого нам понадобится 1192 байта данных, short jump, инструкция pop/pop/ret и некоторый шелл-код. У нас есть 1192 байта для перезаписи. У нас есть short jump. Далее нам нужно расположение набора инструкций pop/pop/ret. Мона seh -n будет искать в памяти процесса эти инструкции и исключать любые результаты, содержащие нулевой байт.
Рисунок 11: Использование mona для поиска инструкций pop/pop/ret
Mona возвращает длинный список допустимых инструкций pop/pop/ret, а также, если библиотека использует преимущества современных средств защиты от эксплойтов, таких как DEP или ASLR. К счастью для нас, ничего из этого не найдено здесь. ?
Рисунок 12: Результаты
Как только мы добавим наш шелл-код для Windows, у нас будет все, что нужно для эксплойта. Собрав все это вместе, мы получим нечто, похожее на это:
Рисунок 13: Соединяем все вместе
Вывод
Если вы всегда хотели начать с поиска ошибок и заработать дополнительные деньги, вы не ошибетесь с программным обеспечением SCADA. Отсутствие современных мер по снижению риска и распространению небезопасных методов кодирования делают его сочной целью для исследователей, так и для злоумышленников. Чего же ты ждешь? Загрузите некоторое программное обеспечение, запустите этот отладчик и отправьте ваши баги в ZDI!
Я надеюсь увидеть вас в Майами, где (надеюсь) будут продемонстрированы другие ошибки SCADA участниками Pwn2Own. А пока вы можете найти меня в твиттере @mrpowell и следить за командой ZDI , чтобы узнать о новейших техниках эксплуатации и исправлениях безопасности. Увидимся в Майами!
Источник: ZDI
Автор: Mat Powell
Если серьезно. Я люблю программное обеспечение SCADA. В любое время, когда я хочу получить больше информации о конкретной классификации ошибок или когда я делаю модификации в своем фаззинг инструменте, я всегда возвращаюсь к SCADA. Главным образом потому, что это то, с чего я начал, когда стал присылать баги в ZDI, но это также никогда не подводило меня с точки зрения нахождения немедленных результатов. В плане поиска багов в SCADA.
Pwn2Own Miami прямо за углом, я хотел очень сильно вернуться туда с одним из моих любимых багов - позорном IOCTL Advantech 0x2711. Первоначально баг был обнаружен и отрепорчен в ZDI Стивеном Сили. Я писал об этом в 2018 году и по какой-то причине я все еще чувствую личную привязанность к этому багу. Не аутентифицированный RCE через RPC администратора. Это просто ужас.
Интересно, что этот баг проходил через программу ZDI несколько раз, и хотя некоторые изменения были сделаны, основная проблема все еще существует. Я думал, что если Advantech не собирается это исправлять, я буду злоупотреблять этим и просто буду бить их снова и снова в надежде, что им надоест слушать меня и наконец они закроют багу.
Примечание: я все еще жду этого дня.
Но я хочу потратить немного времени и рассказать о моем общем подходе к фаззингу, и в данном конкретном случае продемонстрировать, почему развертывание продукта без современных мер безопасности с устаревшим стандартом кодирования все еще актуальная проблема в 2020 году.
Давайте поговорим о процессе.
Рисунок 1: Процесс фаззинга
Независимо от целевого продукта, мой подход всегда придерживается одной и той же структуры. Я собираюсь сгенерировать что-то (то есть аргументы, ввод на основе файлов и т. Д.), Изменить его и передать в приложение с присоединенным отладчиком. По истечении заданного промежутка времени я прерву целевой процесс и запишу результаты. Креши будут изолированы, и процесс начнется заново.
После сбоя приложения я хотел бы использовать расширение !Exploitable для windbg, чтобы помочь с дедупликацией и установлением приоритетов и возникновением сбоев. Для тех, кто не знаком с этим расширением, !Exploitable вызывается после сбоя приложения и пытается классифицировать сбой на основе анализа, который он выполняет. Каждому сбою присваивается категория «Возможность эксплуатации» (т.е. «Возможный для эксплуатации», «Вероятно, пригодный для эксплуятации», «Не пригодный для эксплуатации» и т. д.) И хэш, связанный с крешем. Я использую эту информацию, чтобы распределить падения на основные категории. В итоге это выглядит так:
Рисунок 2: Результаты сбоя
Отсюда мы можем открыть журнал отладки, чтобы лучше понять причину сбоя приложения. Например, если мы посмотрим на файл журнала для bwmail.exe (ZDI-18-047, репорт предоставленный Стивеном Сили ), мы увидим, что он завершился сбоем из-за переполнения буфера в стеке.
Рисунок 3: Переполнение буфера в стеке
Если бы мы открыли bwmail.exe в IDA Pro, мы могли бы обнаружить, что основной причиной этой ошибки было использование вызова из запрещенного списка 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). В этом конкретном примере нам нужно начинать с перезаписи SEH.
Рисунок 9: Нахождение циклического паттерна с помощью функции Моны findmsp
Мона говорит нам, что запись регистрации следующих исключений (nSEH) перезаписывается после отправки 1192 байтов данных. Достаточно много байтов данных для перезаписи. Но что теперь?
Теперь используем sehchain, mona на самом деле напечатает шаблон-скелет эксплойта для использования. Давайте взглянем.
Рисунок 10: Предлагаемый формат полезной нагрузки, предоставленный Mona
Для этого нам понадобится 1192 байта данных, short jump, инструкция pop/pop/ret и некоторый шелл-код. У нас есть 1192 байта для перезаписи. У нас есть short jump. Далее нам нужно расположение набора инструкций pop/pop/ret. Мона seh -n будет искать в памяти процесса эти инструкции и исключать любые результаты, содержащие нулевой байт.
Рисунок 11: Использование mona для поиска инструкций pop/pop/ret
Mona возвращает длинный список допустимых инструкций pop/pop/ret, а также, если библиотека использует преимущества современных средств защиты от эксплойтов, таких как DEP или ASLR. К счастью для нас, ничего из этого не найдено здесь. ?
Рисунок 12: Результаты
Как только мы добавим наш шелл-код для Windows, у нас будет все, что нужно для эксплойта. Собрав все это вместе, мы получим нечто, похожее на это:
Рисунок 13: Соединяем все вместе
Вывод
Если вы всегда хотели начать с поиска ошибок и заработать дополнительные деньги, вы не ошибетесь с программным обеспечением SCADA. Отсутствие современных мер по снижению риска и распространению небезопасных методов кодирования делают его сочной целью для исследователей, так и для злоумышленников. Чего же ты ждешь? Загрузите некоторое программное обеспечение, запустите этот отладчик и отправьте ваши баги в ZDI!
Я надеюсь увидеть вас в Майами, где (надеюсь) будут продемонстрированы другие ошибки SCADA участниками Pwn2Own. А пока вы можете найти меня в твиттере @mrpowell и следить за командой ZDI , чтобы узнать о новейших техниках эксплуатации и исправлениях безопасности. Увидимся в Майами!
Источник: ZDI
Автор: Mat Powell
Последнее редактирование:
