С каждым днем все больше владельцев смартфонов отдают приоритет мобильным мессенджерам, популярный представитель которых — Viber, позволяющий удобно объединить переписку на разных устройствах. Неудивительно, что исследованию их безопасности в последнее время уделяется пристальное внимание. Думаешь, Viber полностью надежен и неспособен тебя подвести? Ну что ж, давай посмотрим, насколько это соответствует истине.
 

Маленький рисерч Viber

Не так давно стало известно об уязвимости в iMessage. Как обнаружил независимый исследователь Росс Маккиллоп (Ross McKillop), предварительный просмотр URL раскрывает данные об IP-адресе пользователя, версии ОС и другие данные об устройстве. Причина заключалась в том, что при построении превьюшки запросы отправлялись непосредственно с устройства. Таким образом, когда iMessage запрашивал данные о каком-либо сайте, то раскрывал адрес пользователя и сведения о его устройстве.

Более корректная архитектура мессенджера предполагает предварительное кеширование контента на своих серверах и дальнейшую загрузку уже оттуда, как это реализовано, например, в Facebook, Twitter и Skype. Давай разберемся, как строится preview по URL в Viber и какие последствия может иметь маленький недочет в проектировании ПО.

 

Кто принимал участие в исследовании

  • Игорь @almart_oO (автор статьи)
  • Комьюнити cybersec.kz (ЦАРКА)
  • Тимур Юнусов (Positive Technologies)
  • Сергей Белов (Digital Security)
  • Антон «Bo0oM» Лопаницын (Wallarm)

Для начала просто отправим сообщение, содержащее корректный URL картинки, размещенной на нашем сервере, например http://host/img.jpg, и посмотрим логи.

{sender_ip} "HEAD /img.jpg HTTP/1.1" 200 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.6.0 Chrome/45.0.2454.101 Safari/537.36"
{sender_ip} "GET /img.jpg HTTP/1.1" 200 45468 "-" "Dalvik/1.6.0 (Linux; U; Android 4.4.2; GT-N7100 Build/KOT49H)"
{reciever_ip} "GET /img.jpg HTTP/1.1" 200 45468 "-" "Viber/6.5.3.266 CFNetwork/808.1.4 Darwin/16.1.0"

Как видим, iMessage не был исключением, и Viber аналогично скомпрометировал IP-адрес получателя сообщения (reciever_ip). Но что будет, если под видом картинки мы попробуем выполнить redirect получателя в произвольном направлении? Вернем код ответа сервера 301 и в HTTP-заголовках укажем поле Location: http://somehost.ru.

{sender_ip}  "HEAD /img.jpg HTTP/1.1" 302 0 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.6.0 Chrome/45.0.2454.101 Safari/537.36"

Лог отличается от предыдущего отсутствием GET-запросов от отправителя и получателя сообщения. С чем это может быть связано? Попробуем в ответ на HEAD вернуть настоящий заголовок картинки, а для GET выполнить перенаправление:

{sender_ip} "HEAD /img.jpg HTTP/1.0" 200 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.6.0 Chrome/45.0.2454.101 Safari/537.36"
{sender_ip} "GET /img.jpg HTTP/1.0" 302 - "-" "Dalvik/1.6.0 (Linux; U; Android 4.4.2; GT-N7100 Build/KOT49H)"
{reciever_ip} "GET /img.jpg HTTP/1.0" 302 - "-" "Viber/6.5.3.266 CFNetwork/808.1.4 Darwin/16.1.0"

На этот раз Viber успешно перенаправил обоих участников переписки — это говорит о том, что Viber выполняет верификацию картинки с помощью начального HEAD-запроса.

А теперь давай проведем эксперимент с cookie. Разместим на сервере простой скрипт для генерации картинки со значением из cookie, увеличивая его на единицу при каждом запросе:

<?
$c=0;
if ( isset($_COOKIE['c']) ) $c = $_COOKIE['c'];
$im = imagecreate(200, 15);
$bg = imagecolorallocate($im, 255, 255, 255);
imagestring($im,10,90,0,$c,1);
if ($_SERVER['REQUEST_METHOD'] !== 'HEAD') { // Предотвращаем изменение cookie начальным запросом
        setcookie('c', $c+1, time()+60*60*24*30);
}
imagejpeg($im, 'temp.jpeg');
$size = filesize('temp.jpeg');
header("Content-Type: image/jpeg");
header("Content-Length: " . $size);
imagejpeg($im);
imagedestroy($im);
?>

В .htaccess добавим записи:

RewriteEngine on
RewriteRule c_(\d+)\.jpg$ cookie.php
# чтобы избежать кеширования

Отправим два сообщения со ссылками на наш хост, например:

http://somehost.ru/c_08.jpg

и

http://somehost.ru/c_09.jpg
Эксперимент с cookie
Эксперимент с cookie

Как видно из скриншота, от сообщения к сообщению Viber собирает и хранит выданные ему cookies.

 

Особенности Windows-клиента Viber

А теперь заглянем в директорию Viber, обычно это C:\Users\username\AppData\Local\Viber. Наличие файла Qt5WebEngine.dll, как и UserAgent Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_4) AppleWebKit/537.36 (KHTML, like Gecko) QtWebEngine/5.6.0 Chrome/45.0.2454.101 Safari/537.36, который мы наблюдали при создании миниатюр, подсказывает, что используется Qt-модуль QtWebEngine. Надо сказать, что в большинстве Windows-версий популярных браузеров реализован механизм аутентификации с помощью NTLM, имеющий по умолчанию ограниченный список ресурсов, вход на которые выполняется автоматически.

 

NTLM-аутентификация

В Firefox разрешенные ресурсы задаются полем network.automatic-ntlm-auth.trusted-uris в редакторе настроек about:config. По умолчанию данный список пуст.

В Chrome и IE политика безопасности в отношении NTLM-аутентификации строится на основе настроек IE (Tools > Internet Options > Security > Internet > User Authentication > Logon). По умолчанию там задан параметр Automatic logon only in Intranet zone, разрешающий автологин только внутри интрасети.

Интересно, а какие настройки безопасности по умолчанию имеет QtWebEngine? Один из способов узнать это — создать тестовое приложение с этим же модулем, например используя среду Qt Designer для Windows. Перенаправим GET-запросы с сервера по URI /a_1.jpg на предварительно развернутую утилиту Responder, которая реализует цепочку ответов, необходимых для входа по NTLM. Параллельно запустим WireShark для анализа пакетов. Затем, используя встраиваемый компонент на основе QtWebEngine в Qt Designer, откроем a_1.jpg и посмотрим историю запросов в WireShark.

Компонент QtWebEngine в Qt Designer
Компонент QtWebEngine в Qt Designer

Запросы NTLM-аутентификации в WireShark
Запросы NTLM-аутентификации в WireShark

Цепочка запросов говорит об успешной работе механизма NTLM-аутентификации на произвольном интернет-ресурсе. Последний HTTP-запрос от клиента включает данные о пользователе Windows, в том числе имя пользователя и NTLMv2-хеш пароля. Сможем ли мы получить хеш пароля от Windows, отправив всего одно Viber-сообщение? Узнаем при эксплуатации...

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя! Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.


Check Also

Неинновационные инновации. Откуда растут корни технологий Apple

Тройная камера, умный режим HDR, «ночной режим» Night Shift, True Tone, Liquid Retina Disp…

8 комментариев

  1. Аватар

    ruslan

    19.01.2017 at 16:45

    Огонь! Спасибо за разбор! 🙂

  2. Аватар

    m0rty

    19.01.2017 at 18:22

    Красавчик Игорь 🙂

  3. Аватар

    LuckyTiger

    19.01.2017 at 19:05

    Отлично! Давайте рассмотрим WhatsApp.

  4. Аватар

    Olzhas

    19.01.2017 at 20:37

    Defcon Kazakshtan на Хакере, еее )

  5. Аватар

    kamare

    20.01.2017 at 16:49

  6. Аватар

    roman.rrv

    24.01.2017 at 09:42

  7. Аватар

    Mr-r00t

    25.02.2017 at 20:10

    Давно удалил. Автору +

Оставить мнение