SAP Afaria. Маленькая SMS для взлома большой компании
Меня зовут Дмитрий, и я уже долгое время занимаюсь информационной безопасностью различных софтверных решений для Enterprise. В основном, это, конечно, разнообразные продукты компании SAP (можно почитать предыдущие мои посты на эту тему тут, тут или тут).
Сегодня же мы с вами заглянем под «капот» SAP Afaria – MDM-решения от известного немецкого софтверного гиганта. Устраивайтесь поудобнее и откидывайтесь на спинку кресла (пожалуйста, будьте аккуратнее, если вы сидите на стуле).
Заниматься анализом защищенности SAP достаточно интересно в силу нескольких причин:
1) В случае удачной компрометации системы, атакующий получает доступ к очень критичной информации. Тут вам и персональные данные (бууэээ) и финансовые показатели, и банковские данные, а к тому же, и прочие корпоративные секретики (кто, куда и за сколько летает в командировки, например) с линками на другие системы («привет, SCADA!»)
2) Технологии. Да, SAP старается шагать в ногу со временем и использовать в своих продуктах все баззвордные технологии. Желаете познакомиться с BigData? Пожалуйста! In memory database интересует? Встречайте, HANA! Сервер сайд JS? Вот вам SAP XSJS. JS фреймворк? Да, забирайте.
Итак, SAP Afaria. Afaria — это Mobile Device Management (MDM) решение. Для тех, кто не знает, что такое MDM, кратко поясню: MDM — набор сервисов, который позволяет администраторам в крупных компаниях контролировать мобильные устройства (смартфоны, планшеты и прочие фаблеты) сотрудников этой самой компании, тем самым обеспечивая безопасность корпоративных данных, которые хранятся и обрабатываются на этих девайсах. На мобильное устройство устанавливается специальное приложение – MDM-клиент, позволяющее администраторам удаленно гибко осуществлять настройки.
MDM может: настроить разного рода политики на переносимых устройствах, найти телефон (если он был утерян сотрудником), контролировать установку приложений, разрешить использование девайса исключительно в рабочее время, заблокировать и даже удаленно стереть все данные. Очень полезный и интересный функционал, надо сказать.
Т.е. мы с вами будем рассматривать не просто очередное корпоративное решение, а решение, которое должно (в теории) повысить безопасность данных в компании.
Afaria имеет типичный для MDM-решений функционал, и работает со всеми современными (и не очень) мобильными платформами:
1) Собирает всю возможную информацию о хардварной части устройства;
2) Собирает информацию об активностях на устройстве: звонки, геопозиция, работа с приложениями и т.д.;
3) Позволяет применять к устройству различные конфигурации: парольную политику, политику использования беспроводных сетей, разрешение на доступ к камере, скриншотам и т.д.
На скриншоте информация о входящих SMS, доступная администратору SAP Afaria
Кинем беглый взгляд на архитектуру SAP Afaria:
Архитектура не хитрая: Устройство -> Relay server -> Afaria server.
На сервере работает ряд сервисов: web, DB и несколько служебных, которые обрабатывают входящие соединения от устройств.
Для передачи данных используется собственный протокол xnet, а также немного http(s), SMS и push-нотификация через Google Cloud Messaging / Apple Push Notification.
Но давайте уже посмотрим на уязвимости-то.
1. Переполнения
Это странно, но любой может достаточно легко провести DoS-атаку на Afaria-серверы, а любители собирать ROP-цепочки и обходить ASLR — даже выполнить произвольный код на сервере. А все потому, что один из основных сервисов Afaria — XcListener – «падает» от входящих пакетов с некорректными данными и размерами.
Небольшой пример, за который должно быть стыдно разработчикам:
import socket
HOST = ‘hostname'
PORT = 3005
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
poc = 'A'*4098
s.send(poc)
data = s.recv(10000)
s.close()
print 'Received', (data)
Мы нашли несколько мест с переполнением, все они на данный момент прикрыты вот этой sapnote.
Но, надо сказать, все это бинарное колдовство в корпоративных системах не очень интересно, ибо сложно в эксплуатации (необходимость писать рабочий эксплойт под различный парк серверных ОС) и редко применимо («ронять» энтерпрайз-системы в ходе теста на проникновение — не лучшая практика).
2. Различные захардкоженные значения
SAP любит хардкодить различные критичные значения (пруф), и Afaria не стала исключением. Например, учетная запись от администратора ОС в конфигурационном файле:
Конечно, она зашифрована. Алгоритм шифрования вполне себе стойкий, однако, угадайте, что с ключом? Бинго, он тоже захардкожен в одном из сервисов Afaria.
Таким образом, злоумышленнику не придется особо долго возиться с криптографией, ведь ключи вшиты и не меняются:
Единственное, что может смутить атакующего — это разнообразие захардкоженных ключей и алгоритмов шифрования.
Некоторые функции шифрования выглядели достаточно странно:
Такой подход к шифрованию нарушителю, конечно, на руку. Патчи вот тут.
3. Stored XSS
Немного веба. Основной функционал, доступный из браузера, приходится на административную часть SAP Afaria. Web-админка — то самое место, где администратор системы может получать список всех подключенных устройств, создавать новые конфигурации мобильных устройств, загружать приложения, управлять устройствами и т.д.
Таким образом, уязвимость в админке с очень большой вероятностью будет критична как для системы в целом, так и для администратора в частности. Простым пользователям Afaria, конечно, не предоставляется доступ к функционалу администратора. Однако, внедрить свои данные все же возможно. Для этого давайте взглянем на то, как отреагирует Afaria, если мы попробуем присоединить к серверу новое устройство, не имея на это прав (и аккаунта пользователя).
Получится следующее: сервер, конечно, не даст соединиться, однако, в админке в списке устройств (а надо сказать, что это основная рабочая область администратора) появится информация о нашем устройстве с пометкой «Not approved». Т.е. атакующий вполне себе может внедрить некие данные анонимно прямо в админку. Догадаетесь, в каком поле возможна JS-инъекция? Нет? Ну да ладно. Сервер не фильтрует перед выводом данные об IMEI устройства.
Казалось бы, типичная stored xss. Однако, ее эксплуатация показалась слегка интересной, ввиду того, что поле IMEI имеет длину, ограниченную 15 символами. Однако, ничто не мешает нам/атакующему послать насколько запросов на соединение, в качестве значения IMEI указав лишь часть JS-пейлоада и символы комментария. Таким образом, вполне можно собрать полноценный JS-скрипт, который позволил бы злоумышленнику делать в рамках сессии администратора Afaria.
На скриншоте исходный код страницы админки с внедренным JS через IMEI устройства:
Исправления от SAP доступны вот тут.
4. Control via SMS
Пожалуй, самая интересная часть. Как уже упоминалось, Afaria позволяет администратору системы контролировать устройство удаленно. И один из каналов для доставки команд от администратора — это SMS. Нужно это для того, например, чтобы заблокировать телефон с корпоративными секретами, который сотрудник оставил в баре после корпоратива.
Примеры административных SMS-команд:
WIPEALLDATA WIPENITRODESK WIPENITRODESKSDCARD LOCKDEVICE FETCHLOG UNLOCKDEVICE USERLOCK REMEDIATE NOTIFY etc...
Как можно заметить, это очень злой функционал. Чтобы телефоны сотрудников не блокировались массово от любой SMS с текстом «LOCKDEVICE», конечно же, предусмотрена аутентификация. Для того, чтобы понять, как она работает, рассмотрим подробнее SMS-сообщение, которое получает клиент.
Вот так выглядит SMS на блокировку пользователя:
@#!Afaria64aACAhntVzjTIjhHDMGql8ldvc/8U6IlIoPU7aAOT8=$\$CMD:USERLOCK
Состоит оно из нескольких частей:
1) @#!Afaria — сигнатура, которая сообщает клиентскому приложению, что это управляющая SMS от администратора, а не просто SMS от мамы;
2) 64aACAhntVzjTIjhHDMGql8ldvc/8U6IlIoPU7aAOT8= — base64 строка аутентификации;
3) $\$CMD: — сигнатура, поясняющая, что далее идет имя команды;
4) USERLOCK — непосредственно команда, которая будет выполнена на устройстве при успешной
аутентификации.
Самая интересная часть – это, конечно, аутентификация. Внутри base64 sha256 хэш от конкатенации следующих параметров:
<LastAdminSessionID>+<ClientID>+<TransmitterID>+$\$CMD:<CMD_NAME>
Что такое $\$CMD: и <CMD_NAME> мы уже знаем, разберемся с остальными:
1) — идентификатор последней сессии
2) — идентификатор клиента
3) — идентификатор сервера
Выглядит надежно. Для аутентификации нужно знать сессию, клиента и сервер. А SMS выглядит следующим образом:
@#!Afaria+base64(sha256(<LastAdminSessionID>+<ClientID>+<TransmitterID>+$\$CMD:+<CMD_NAME>))+$\$CMD:+<CMD_NAME>
Но не будем опускать руки раньше времени и заглянем в недра клиента:
Если внимательно посмотреть, то можно заметить, что клиент пытается сравнивать не один хэш из SMS, а два! Первый — в котором присутствуют все три параметра (ID сессии, клиента и сервера), и второй — который получается всего из двух параметров (ID клиента дважды и ID сервера). Выходит, что знать сессию вовсе не обязательно, что значительно упрощает обход аутентификации.
Остается разобраться с ClientID и TransmitterID. С TransmitterID все просто, его можно получить анонимно, так как сервер возвращает его значение в составе ответа на любой запрос к серверу Afaria. Остается только узнать ClientID.
Анализ бинарников Afaria позволил понять, что ClientID генерируется на основе IMEI телефона. Таким образом, все, что нужно знать атакующему для того, чтобы успешно стереть данные на телефоне CEO какой-нибудь крупной корпорации, это IMEI и номер его телефона.
Как получить IMEI? Это, конечно, отдельная задача. Варианты решения:
1) Брутфорс. Имеет смысл, если телефоны для сотрудников в компании закупались большой партией. В таком случае, возможно перебрать IMEI, зная один из партии;
2) Перехват трафика от сторонних приложений, передаваемого по незащищенным протоколам. Этим грешат различные картографические сервисы, которые посылают на сервер как инфу о телефоне, так и информацию о базовых станциях. Как пример;
3) Уязвимости в самой Afaria. Например, используя описанную ранее XSS;
4) Различные IMEI catcher и прочие фейк бтс.
В качестве резюме
Не стоит полностью доверяться секьюрити-решениям и думать, что это панацея от всего, или полагать, что их писали более квалифицированные программисты. Порой те или иные «продукты» только ухудшают и без того тяжелую ситуацию, добавляя очередную точку входа атакующему.
И да, не забывайте патчиться. Ну и аудиты там всякие, пентестики.
