Что случилось, когда мы взломали выставку?

https://www.bulletproof.co.uk/blog/expo-hack
  • Перевод
QRCODE через мобильное приложение для сканирования бейджей участников выставки проектов по информационной безопасности.

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

Toms exhibitor badge

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

{"CJe";"BHEEZST","DO";"Cvmmfuqsppg","G";"upn","KU";"Qfofusbujpo uftufs","T";"xzbuu"}

Это оказался «почти-но-не-совсем-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

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

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

Fake ID in app

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


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

coding an alert

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

Showing an XSS flaw

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

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

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

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

Showing the Payload

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

Showing the server response

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


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

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

      –1
      Поляк?
        0
        Я про фотку говорю. Ее сделал поляк вроде.
      –1
      Пора бы уже начать награждать за мобильные приложения, написанные на JS.
      Несколько сотен тысяч евро штрафа были бы отличной наградой, на мой взгляд.
        0
        — И, боже вас сохрани, не устанавливайте до обеда мобильные приложения, написанные на JS
        — Гм… Да ведь других нет.
        — Вот никаких и не устанавливайте.
        0
        Проблема QR-кодов в их нечитаемости, что давно известно. Вектор просто очевиден. Ребята молодцы, что проэксплуатировали. :)
          0
          Спасибо! Очень интересно!
              0
              Вспомнился анекдот На эту тему
              Спойлер
              День первый
              Хакер приходит в общественную столовую и с возмущением обнаруживает, что солонку на столе может открутить кто попало и насыпать туда что угодно. Хакер приходит домой и пишет гневное письмо директору столовой: «Я, meG@Duc, обнаружил уязвимость солонки в Вашей столовой. Злоумышленник может вскрыть солонку и насыпать туда яду! Примите меры срочно!»

              День второй
              Директор среди прочих деловых писем, запросов о поставках еды и курьерских уведомлений получает письмо, и пожимает плечами: «Кому этот бред только в голову пришёл?»

              День пятый
              Хакер приходит в столовую, насыпает во все солонки яду. Погибает триста человек, директора три месяца таскают по судам и, в конце концов, оправдывают за отсутствием состава преступления. Хакер пишет письмо в стиле «ну что, видали?».

              День 96-ой
              Директор покупает специально спроектированные солонки с кодовым замком. Посетители столовой чувствуют, что они в этой жизни чего-то не понимают.

              День 97-ой
              Хакер обнаруживает, что дырки в солонках пропускают соль в обе стороны. И не только соль, а вообще всё, что угодно. Он пишет возмущенное письмо директору и ссыт во все солонки столовой. Триста человек перестают посещать эту столовую вообще, тридцать попадают в больницы с отравлением. Хакер вдогонку посылает директору смс-ку «Ну как вам?». Директора тем временем три месяца таскают по судам и дают год условно.

              День 188-ой
              Директор столовой клянется в жизни больше не работать ни в одной столовой, а тихо-мирно грузить лес в Сибири. Инженеры работают над новой солонкой с односторонним клапаном. Официантки тем временем изымают все старые солонки и раздают соль вручную.

              День 190-ый
              Хакер тырит солонку из столовой и изучает дома её устройство. Пишет гневное письмо директору: «Я, meG@Duc, стырил солонку и нахожу этот факт возмутительным! Любой может стырить солонку из Вашей столовой!» До этого непьющий директор читает письмо, идет домой и выпивает водки.

              День 193-ый
              Хакер обнаруживает, что все солонки в столовой прибиты цепями к столам. Он приезжает на очередной хакерский СПРЫГ и докладывает о своих успехах, получая там заслуженную награду за защиту интересов общества и потребителя. К счастью, директор ничего про это не знает и не сопьется раньше времени.

              День 194-ый
              В рамках дьявольски гениально продуманной операции хакеры всем СПРЫГом вламываются в столовую и высыпают соль из всех солонок себе в карманы. Хакер meG@Duc пишет возмущенное письмо директору, намекая на то, что никакой заботы о посетителях в столовой нет и любой гад может лишить честных людей соли в одно мгновение. Дозатор соли с авторизацией необходим просто позарез.

              Инженеры в поте лица работают над новой солонкой, пока официантки опять раздают соль вручную. Директор уезжает в отпуск на Сейшельские острова и обедает только в номере, избегая столовых, ресторанов и баров.

              День 200-ый
              Посетители столовой с ужасом находят, что, чтобы насыпать соли, они должны подойти к официанту, предъявить паспорт, получить специальный 8-значный одноразовый код к солонке. Для получения перца процедуру следует повторить.

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

              Самое читаемое