Обратное проектирование компонентов WinAPRS с помощью WinDbg и IDA Pro для поиска уязвимостей, связанных с повреждением памяти, вдоль нашего сконфигурированного пути кода.
Ключевые моменты:
1. Охватываем реверс-инжиниринг компонентов WinAPRS с помощью WinDbg и IDA Pro для поиска уязвимостей повреждения памяти вдоль сконфигурированного пути кода.
2. Модификация программного обеспечения пакетной радиосвязи с открытым исходным кодом для помощи в фаззинге входа KISS TNC WinAPRS и настройка WinAPRS для работы с конкретным аппаратным обеспечением.
3. Обнаружено, что сгенерированный пакет с 1000 A's, получил нарушение доступа, но после попытки продолжить выполнение, управление EIP было успешным.
В первой части этой серии, посвященной исследованию уязвимостей в программном обеспечении любительской радиосвязи, мы обсудили любительскую радиосвязь и цифровую связь через пакетную радиосвязь. Мы рассмотрели некоторые соответствующие протоколы пакетной радиосвязи, такие как AX.25, APRS и KISS. Затем мы выбрали WinAPRS в качестве нашего целевого приложения. В этом выпуске мы рассмотрим обратное проектирование компонентов WinAPRS с помощью WinDbg и IDA Pro для поиска уязвимостей, связанных с повреждением памяти, в нашем сконфигурированном пути кода. Мы также модифицируем программное обеспечение для пакетной радиосвязи с открытым исходным кодом, чтобы облегчить фаззинг входных данных WinAPRS KISS TNC, чтобы получить прибыль. Хотя сначала мы должны настроить WinAPRS для работы с нашей конкретной настройкой оборудования.
Сначала был мой позывной.
Затем последовательный COM-порт. В моей тестовой виртуальной машине (ВМ) с моим TNC KISS это был COM3 со скоростью 9600 бод.
Затем мне пришлось включить режим KISS.
После того, как он был настроен и заработал, я стал получать пакеты APRS и отображать местоположение станций на базовой прилагаемой карте.
Далее я дизассемблировал исполняемый файл в IDA Pro и подключил WinDbg к работающему процессу. Первое, что я сделал, это загрузил расширение narly WinDbg и проверил, есть ли в WinAPRS какие-либо средства защиты. У него вообще не было защиты. Я также обнаружил, что он не загружал внешние библиотеки DLL.
Следующее, что мне нужно было сделать, это выяснить, откуда данные поступали в WinAPRS из TNC. Обычно я находил несколько вызовов Win32 API к RECV (TCP) или RECVFROM (UDP) и проверял их там, но в этом случае данные поступали через последовательный порт. Целевая система теоретически не может быть даже подключена к Ethernet. Я провел некоторое исследование API-интерфейсов Win32, связанных с последовательной связью, и обнаружил, что COM-порты в Windows в основном обрабатываются как файлы ( https://www.xanthium.in/Serial-Port-Programming-using-Win32-API ). Сначала вы открываете дескриптор порта, а затем вызываете ReadFile. Я использовал IDA для поиска вызовов ReadFile и нашел вот это:
Я установил точку останова на этом вызове и стал ждать, пока по радио не придет пакет APRS. Сработала точка останова, что стало первым признаком того, что я на правильном пути. Я проверил параметры в стеке, чтобы найти адрес lpBuffer.
Я взял следующий вызов ReadFile и проверил содержимое буфера и обнаружил, что он загружен пакетными данными.
Это указывало на то, что я нашел правильный вызов ReadFile и теперь могу проследить код, чтобы, надеюсь, найти его уязвимость Моя первая мысль состояла в том, чтобы проверить, подвержен ли lpBuffer переполнению. Чтобы ответить на этот вопрос, мне нужно было знать, насколько велик lpBuffer и откуда взялся параметр nNumberOfBytesToRead. Если бы я мог создать пакет, в котором для nNumberOfBytesToRead было бы установлено значение, превышающее размер lpBuffer, то я мог бы переполнить буфер и получить контроль над EIP. Я начал с размера lpBuffer.
Я проверил буфер перед вызовом ReadFile и обнаружил, что он заполнен символами 0xCC.
Я продолжал двигаться вниз по стеку, пока не нашел конец символов 0xCC.
Небольшие математические вычисления показали, что размер буфера составляет 2052 байта.
Значение параметра nNumberOfBytesToRead, похоже, получено из переменной с именем Stat.cbInQue.
Согласно документации Microsoft ( https://docs.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-comstat ), cbInQue представляет количество байтов, полученных провайдером, но еще не прочитанных. Это казалось хорошей новостью, поскольку это означало, что значение параметра nNumberOfBytesToRead будет установлено в зависимости от того, сколько данных было отправлено TNC. В ассемблерном коде, похоже, не было никаких проверок, чтобы гарантировать, что данные не превышают 2052 байта в длину, что означало, что он, вероятно, был уязвим для базового переполнения. Мне просто нужно было бы отправить пакет размером более 2052 байт. Но как это сделать?
Один TNC, который у меня был, использовался для приемной станции. Мне нужен был способ передать пакет со второй станции, отвечающий определенным условиям, чтобы вызвать переполнение. У меня была портативная трансивер Kenwood TH-G71 с аудиоразъемами для внешнего динамика и микрофона. Я изучил распиновку радиоприемника в руководстве и обнаружил, что если я подключу внешний порт микрофона и динамика радиостанции к компьютеру, он автоматически включит радио и начнет передавать любой звук, который выдает компьютер. Это было не идеальное решение, но оно сработало бы, если бы я нашел способ создавать собственные пакеты AX.25 и преобразовывать их в аудиофайл, который я мог бы воспроизводить по команде.
Я исследовал программное обеспечение с открытым исходным кодом Direwolf, которое обычно используется в качестве интерфейса радиомодема на основе звуковой карты. Я обнаружил, что он поставляется с утилитой под названием «gen_packets», которая позволяет вам генерировать аудиофайл, представляющий настроенный пакет AX.25. Это было именно то, что мне было нужно, но у него было встроенное ограничение на размер пакета. Я изучил исходный код и нашел способ изменить его, чтобы позволить мне создавать гораздо большие пакеты. Сначала я изменил файл ax25_pad.c:
Затем я внес изменения в gen_packets.c.
После компиляции Direwolf я смог генерировать собственные пакеты размером до 3000 байт.
Я начал с создания пакета размером более 2052 байт, но, что интересно, после его передачи по воздуху ничего не произошло. Я не мог заставить точку останова ReadFile даже сработать. Я попробовал кучу пакетов разного размера и обнаружил, что меньшие пакеты, казалось, нормально запускали точку останова, но пакеты длиной более 1024 байт не срабатывали. Я подключился к своему TNC с помощью putty и обнаружил, что любые пакеты размером более 1024 байт просто не отправляются на ПК через последовательный порт. KPC 9612+ ограничивал размер пакета до 1024 байт. Из моих исследований не следует, что протоколы AX.25 или KISS имеют такое ограничение по размеру. Я подозреваю, что сам TNC имеет какое-то ограничение памяти или просто жестко запрограммированное ограничение размера по какой-либо причине. Это означало, что я не смогу переполнить буфер, используя это оборудование.
Однако не все было потеряно. Я обнаружил, что когда я сгенерировал пакет с 1000 A, я получил нарушение прав доступа. И после попытки продолжить выполнение я каким-то образом получил контроль над EIP.
Небольшой фаззинг удался!
Регистр EIP ЦП указывает на адрес памяти инструкции ЦП, которая должна быть выполнена. В данном случае он теперь указывал на адрес 0x41414141.
0x41 — это шестнадцатеричный эквивалент символа ASCII «A». Моя полезная нагрузка содержала 1000 A, поэтому вполне вероятно, что EIP теперь указывал на местоположение, контролируемое моей полезной нагрузкой. Если бы это было правдой, я теоретически мог бы изменить свою полезную нагрузку, чтобы она содержала некоторые другие символы, которые могли бы указать EIP практически в любом месте. Если бы я мог найти способ указать EIP на место в памяти, содержащее мой собственный шелл-код, ЦП затем выполнил бы мои собственные инструкции, и я мог бы получить удаленное выполнение кода на машине-жертве. Но как это произошло? Моя полезная нагрузка содержала только 1000 A, что было меньше, чем размер переменной lpBuffer. Я не ожидал такого результата. Дальше в коде должна быть какая-то другая уязвимость.
Перевод Этой статьи.
Ключевые моменты:
1. Охватываем реверс-инжиниринг компонентов WinAPRS с помощью WinDbg и IDA Pro для поиска уязвимостей повреждения памяти вдоль сконфигурированного пути кода.
2. Модификация программного обеспечения пакетной радиосвязи с открытым исходным кодом для помощи в фаззинге входа KISS TNC WinAPRS и настройка WinAPRS для работы с конкретным аппаратным обеспечением.
3. Обнаружено, что сгенерированный пакет с 1000 A's, получил нарушение доступа, но после попытки продолжить выполнение, управление EIP было успешным.
В первой части этой серии, посвященной исследованию уязвимостей в программном обеспечении любительской радиосвязи, мы обсудили любительскую радиосвязь и цифровую связь через пакетную радиосвязь. Мы рассмотрели некоторые соответствующие протоколы пакетной радиосвязи, такие как AX.25, APRS и KISS. Затем мы выбрали WinAPRS в качестве нашего целевого приложения. В этом выпуске мы рассмотрим обратное проектирование компонентов WinAPRS с помощью WinDbg и IDA Pro для поиска уязвимостей, связанных с повреждением памяти, в нашем сконфигурированном пути кода. Мы также модифицируем программное обеспечение для пакетной радиосвязи с открытым исходным кодом, чтобы облегчить фаззинг входных данных WinAPRS KISS TNC, чтобы получить прибыль. Хотя сначала мы должны настроить WinAPRS для работы с нашей конкретной настройкой оборудования.
Конфигурация оборудования
Приемная станция- Радио: Icom IC-207
- TNC: Kantronics KPC 9612+ в режиме KISS
- Операционная система: Windows XP SP3 и Windows 10
- Программное обеспечение: WinAPRS v2.9.0
Настройка WinAPRS
Я обнаружил, что мне пришлось внести несколько изменений в конфигурацию, чтобы WinAPRS правильно работал с моим оборудованием.Сначала был мой позывной.
Затем последовательный COM-порт. В моей тестовой виртуальной машине (ВМ) с моим TNC KISS это был COM3 со скоростью 9600 бод.
Затем мне пришлось включить режим KISS.
После того, как он был настроен и заработал, я стал получать пакеты APRS и отображать местоположение станций на базовой прилагаемой карте.
Обратный двоичный файл
Далее я дизассемблировал исполняемый файл в IDA Pro и подключил WinDbg к работающему процессу. Первое, что я сделал, это загрузил расширение narly WinDbg и проверил, есть ли в WinAPRS какие-либо средства защиты. У него вообще не было защиты. Я также обнаружил, что он не загружал внешние библиотеки DLL.
Следующее, что мне нужно было сделать, это выяснить, откуда данные поступали в WinAPRS из TNC. Обычно я находил несколько вызовов Win32 API к RECV (TCP) или RECVFROM (UDP) и проверял их там, но в этом случае данные поступали через последовательный порт. Целевая система теоретически не может быть даже подключена к Ethernet. Я провел некоторое исследование API-интерфейсов Win32, связанных с последовательной связью, и обнаружил, что COM-порты в Windows в основном обрабатываются как файлы ( https://www.xanthium.in/Serial-Port-Programming-using-Win32-API ). Сначала вы открываете дескриптор порта, а затем вызываете ReadFile. Я использовал IDA для поиска вызовов ReadFile и нашел вот это:
Я установил точку останова на этом вызове и стал ждать, пока по радио не придет пакет APRS. Сработала точка останова, что стало первым признаком того, что я на правильном пути. Я проверил параметры в стеке, чтобы найти адрес lpBuffer.
Я взял следующий вызов ReadFile и проверил содержимое буфера и обнаружил, что он загружен пакетными данными.
Это указывало на то, что я нашел правильный вызов ReadFile и теперь могу проследить код, чтобы, надеюсь, найти его уязвимость Моя первая мысль состояла в том, чтобы проверить, подвержен ли lpBuffer переполнению. Чтобы ответить на этот вопрос, мне нужно было знать, насколько велик lpBuffer и откуда взялся параметр nNumberOfBytesToRead. Если бы я мог создать пакет, в котором для nNumberOfBytesToRead было бы установлено значение, превышающее размер lpBuffer, то я мог бы переполнить буфер и получить контроль над EIP. Я начал с размера lpBuffer.
Я проверил буфер перед вызовом ReadFile и обнаружил, что он заполнен символами 0xCC.
Я продолжал двигаться вниз по стеку, пока не нашел конец символов 0xCC.
Небольшие математические вычисления показали, что размер буфера составляет 2052 байта.
Значение параметра nNumberOfBytesToRead, похоже, получено из переменной с именем Stat.cbInQue.
Согласно документации Microsoft ( https://docs.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-comstat ), cbInQue представляет количество байтов, полученных провайдером, но еще не прочитанных. Это казалось хорошей новостью, поскольку это означало, что значение параметра nNumberOfBytesToRead будет установлено в зависимости от того, сколько данных было отправлено TNC. В ассемблерном коде, похоже, не было никаких проверок, чтобы гарантировать, что данные не превышают 2052 байта в длину, что означало, что он, вероятно, был уязвим для базового переполнения. Мне просто нужно было бы отправить пакет размером более 2052 байт. Но как это сделать?
Один TNC, который у меня был, использовался для приемной станции. Мне нужен был способ передать пакет со второй станции, отвечающий определенным условиям, чтобы вызвать переполнение. У меня была портативная трансивер Kenwood TH-G71 с аудиоразъемами для внешнего динамика и микрофона. Я изучил распиновку радиоприемника в руководстве и обнаружил, что если я подключу внешний порт микрофона и динамика радиостанции к компьютеру, он автоматически включит радио и начнет передавать любой звук, который выдает компьютер. Это было не идеальное решение, но оно сработало бы, если бы я нашел способ создавать собственные пакеты AX.25 и преобразовывать их в аудиофайл, который я мог бы воспроизводить по команде.
Я исследовал программное обеспечение с открытым исходным кодом Direwolf, которое обычно используется в качестве интерфейса радиомодема на основе звуковой карты. Я обнаружил, что он поставляется с утилитой под названием «gen_packets», которая позволяет вам генерировать аудиофайл, представляющий настроенный пакет AX.25. Это было именно то, что мне было нужно, но у него было встроенное ограничение на размер пакета. Я изучил исходный код и нашел способ изменить его, чтобы позволить мне создавать гораздо большие пакеты. Сначала я изменил файл ax25_pad.c:
Затем я внес изменения в gen_packets.c.
После компиляции Direwolf я смог генерировать собственные пакеты размером до 3000 байт.
Я начал с создания пакета размером более 2052 байт, но, что интересно, после его передачи по воздуху ничего не произошло. Я не мог заставить точку останова ReadFile даже сработать. Я попробовал кучу пакетов разного размера и обнаружил, что меньшие пакеты, казалось, нормально запускали точку останова, но пакеты длиной более 1024 байт не срабатывали. Я подключился к своему TNC с помощью putty и обнаружил, что любые пакеты размером более 1024 байт просто не отправляются на ПК через последовательный порт. KPC 9612+ ограничивал размер пакета до 1024 байт. Из моих исследований не следует, что протоколы AX.25 или KISS имеют такое ограничение по размеру. Я подозреваю, что сам TNC имеет какое-то ограничение памяти или просто жестко запрограммированное ограничение размера по какой-либо причине. Это означало, что я не смогу переполнить буфер, используя это оборудование.
Однако не все было потеряно. Я обнаружил, что когда я сгенерировал пакет с 1000 A, я получил нарушение прав доступа. И после попытки продолжить выполнение я каким-то образом получил контроль над EIP.
Небольшой фаззинг удался!
Регистр EIP ЦП указывает на адрес памяти инструкции ЦП, которая должна быть выполнена. В данном случае он теперь указывал на адрес 0x41414141.
0x41 — это шестнадцатеричный эквивалент символа ASCII «A». Моя полезная нагрузка содержала 1000 A, поэтому вполне вероятно, что EIP теперь указывал на местоположение, контролируемое моей полезной нагрузкой. Если бы это было правдой, я теоретически мог бы изменить свою полезную нагрузку, чтобы она содержала некоторые другие символы, которые могли бы указать EIP практически в любом месте. Если бы я мог найти способ указать EIP на место в памяти, содержащее мой собственный шелл-код, ЦП затем выполнил бы мои собственные инструкции, и я мог бы получить удаленное выполнение кода на машине-жертве. Но как это произошло? Моя полезная нагрузка содержала только 1000 A, что было меньше, чем размер переменной lpBuffer. Я не ожидал такого результата. Дальше в коде должна быть какая-то другая уязвимость.
Следующие шаги
В следующей части Hacking Ham Radio мы отследим источник этой ошибки и выясним, как она привела к контролю над реестром EIP. Мы также обнаружим некоторые ограничения допустимых значений адресов, которые мы можем поместить в EIP. Нам придется пойти на некоторые компромиссы, чтобы обойти эту проблему и двигаться вперед к нашей цели — получить реверсивную оболочку с использованием радиолюбителей.Перевод Этой статьи.
Like