Хабрахабр

[Перевод] Что случилось, когда мы взломали выставку?

QRCODE через мобильное приложение для сканирования бейджей участников выставки проектов по информационной безопасности.
В прошлом году мы посетили большую выставку проектов по информационной безопасности в Лондоне. В ходе подготовки нам прислали наши пропуска в виде PDF-ников «распечатай сам».

Toms exhibitor badge

Что интересно, QR-код выглядел слишком плотным, учитывая, что в нём достаточно хранить только ID участника. Мы сразу обратили внимание на два вида штрихкода. Будучи любознательными по своей природе, мы запустили QR-сканер и получили содержимое кода:

Это оказался «почти-но-не-совсем-JSON». Одним из плюсов такого короткого имени, как у меня, является то, что оно бросается в глаза в подобных ситуациях. Поэтому я сразу заметил, что моё имя закодировано в ROT-25 («tom» превратилось в «upn»). Он также известен как Шифр Цезаря, где каждая буква заменена на другую с фиксированным смещением (в данном случае вместо каждой буквы использовалась соседняя в алфавите). Прогнав строку через декодер (с учётом разметки JSON), мы получили:

{"BId";"AGDDYRS","CN";"Bulletproof","F";"tom","JT";"Penetration tester","S";"wyatt"}

Это уже более читаемо.

Сломаем?

Любопытно, что QR-код хранит информацию, похоже, связанную с полем «BId» в базе данных. С чего бы? Что ж, это довольно просто. Организаторы сделали мобильное приложение для вендоров, которое помогает им собирать контакты участников в ходе выставки. Мы предположили, что данные забиты в QR-код на тот случай, когда Wi-Fi или сотовый сигнал неустойчивы.

Это было бы забавно, но врядли достойно емейла разработчику системы. Пока мы мало что можем сделать с этой информацией, кроме как поменять наши данные, чтобы избежать спама от вендоров с мероприятия. Итак, мы отправились в Play Market и установили соответствующее приложение, чтобы посмотреть, что оно делает.

Screenshot of the app

Мы подумали, что могли бы подделать ответ сервера с помощью MiTM proxy, и приложение пустит нас. И тут мы столкнулись с проблемой: у нас не было необходимых данных от организаторов мероприятия. Мы настроили Burpsuite и записали несколько неудачных попыток входа, надеясь перехватить трафик и поиграться с ним.

Приложение направляло все запросы с помощью SOAP, а ответы были неочевидны. Увы, у нас не получилось. Впрочем, сервер публикует WSDL документы для приложения.

Это не конец

Почему бы не написать поддельный веб-сервис, чтобы больше не обращаться к настоящему серверу приложения? Через несколько часов у нас был такой сервис, и весь трафик был завёрнут на него. Работает! Приложение аутентифицировалось с любыми данными и подключалось к фейковому мероприятию.

Fake show in app

Прогресс! Мы отсканировали пару бейджей, и, похоже, всё работало правильно. Немного поковырявшись в APK, мы нашли ряд упоминаний Sencha и Ext.js, что подтвердило наше предположение. После блуждания по приложению некоторое время стало очевидно, что оно использует какой-то фреймворк на основе WebView.

Если приложение состоит из обычной смеси HTML и JavaScript, может ли оно быть уязвимым для стандартных веб-атак? А теперь — самое интересное. Мы завернули несколько XSS'ок в «не-совсем-JSON», который ожидает приложение, отсканировали их, и…

Fake ID in app

Мы сломали его

Превосходно! HTML-инъекция в поле «JT» показала изображение. Мы можем добавить атрибут «onerror» в этот тэг, чтбы добиться выполнения скрипта, но упираемся в ограничение максимальной длины QR-кода. В итоге мы создали полезную нагрузку, которая скачивала JS-файл с сервера и запускала его на устройстве. Вот, например, стандартный тест на «alert()»:

coding an alert

Сканирование штрихкода вызывает срабатывание XSS и исполнение кода:

Showing an XSS flaw

После чтения документации на API Ext.js и сопоставления её с декомпилированным кодом APK нам удалось сделать штрихкод, который: Мы ужали это так, чтобы оно аккуратно умещалось в максимальный размер читаемого QR-кода, не слишком плотного для печати на пропуске.

  1. Скачивает JS-файл с удалённого сервера
  2. Считывает сессионные ключи со смартфона и отправляет их на наш сервер
  3. Считывает содержимое закэшированной базы данных контактов из приложения, включающей имена и адреса электронной почты всех, чьи пропуска были отсканированы данным устройством
  4. Удаляет свою запись со смартфона

Затем атака сводится к следующему: вендор сканирует мой QR-код в обмен на бесплатную ручку, а я получаю полный список всех контактов, отсканированных этим устройством.

Полезная нагрузка:

Showing the Payload

Запросы к веб-серверу:

Showing the server response

Всё хорошо, что хорошо кончается

Мы обратили на это внимание вендоров на выставке, и после некоторого обсуждения они решили не использовать приложение в этом году. Всего несколько человек на мероприятии воспользовались приложением, в то время как большинство предпочли ему простые небольшие сканеры штрихкодов. Приложение из Маркета скачали всего около 500 раз. Тем не менее, это интересный вектор для XSS, который показывает, что вам действительно нужно фильтровать данные перед использованием независимо от их источника.

Все эти данные достались бы злоумышленникам, которые бы распорядились ими на своё усмотрение: от фишинговых кампаний до брутфорс-атак. Хотя это конкретное приложение не использовалось широко, представьте, если бы уязвимость была в приложении, котором пользуются тысячи или скачивают миллионы?

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»