Рисунок 9: Исключение, возникающее при отсылке запроса Эксплуатация уязвимости не представляет особых сложностей из-за отсутствия механизмов противодействия эксплоитам, заточенным под бинарный файл msloader: Рисунок 10: Результаты тестирования на безопасность файла msloader Более того, стек и куча доступны на выполнение, и мы можем просто перейти к шелл-коду после перехвата управления программным счетчиком. При эксплуатации уязвимости обнаружилось, что управление регистром PC перехватывается после 176 байт, хотя у полезной нагрузки было ограничение в 180 байт. Сей факт означает, что размер шелл-кода ограничивается. Для решения этой проблемы мы написали шелл-код в режиме Thumb (режим, в котором используется сокращенная система команд) в целях более рационального использования места. Также выяснилось, что переполнение негативно влияет и на другие регистры до такой степени, что мы не можем найти регистр, указывающий шелл-коду, куда переходить. Данное влияние затрагивает указатель стека, требующий подстройки, чтобы наш шелл-код передал параметры в стек во время конфигурирования системного вызова. Из-за этой проблемы мы решили указать конкретный адрес местонахождения шелл-кода в стеке. Возможно, данное решение не идеально, но в реализации значительно легче. Несмотря на то, что по теории эксплуатация бреши – относительно тривиальна, следует помнить о некоторых моментах. Во-первых, на устройстве используется защита ASLR, хотя и в консервативном режиме, что означает слабую рандомизацию стека и уязвимость к прямому перебору. Мы выяснили, что на практике требуется не более 20 попыток, а в большинстве случаев – не более 5. Самое главное заключается в том, что программная защита отслеживает неудачные попытки, поскольку происходит падение процесса msloader. При каждой неудаче устройство перезагружается. Во-вторых, полезная нагрузка не должна портить URL, поскольку происходит передача при помощи GET-запроса. Поэтому полезная нагрузка должна содержать такие символы, чтобы HTTP-запрос был корректным. Данное ограничение мы обошли при помощи кодирования URL. Кроме того, полезная нагрузка не должна содержать пустых байтов, иначе строка завершится раньше положенного. Чтобы обойти данное ограничение, мы сделали так, чтобы шелл-код был самомодифицирующимся и патчил пустые байты в нужных местах буфера при первом запуске. В-третьих, полезная нагрузка была повреждена в некоторых местах. Вместо решения этой проблемы, когда требовались бы дополнительные инструкции, мы изменили полезную нагрузку так, чтобы испорченные инструкции не влияли на шелл-код. Эксплуатация проблемы в наглядной форме показана ниже. Код эксплоита находится на странице: https://github.com/mdsecresearch/Pu...r/exploits/motorolascout_setupWifi_exploit.py В заключение мы продемонстрировали, насколько безопасность IoT-устройств несовершенна, по сравнению с мобильными и настольными системами. Во многих случаях в IoT-устройствах используются стандартные учетные записи, не используются методы противодействия эксплоитам, все службы запускаются от имени суперпользователя и зачастую содержатся бреши, связанные с инъекциями. Анализ ботнета Mirai показал, насколько распространены и легкодоступны подобные устройства для эксплуатации злоумышленниками. Мы предполагаем, что в будущем данная тенденция будет только развиваться. Полная видео демонстрация показана ниже: