Чем опасен Firebase
Инструменты Firebase очень часто используются для ускоренной разработки веб и мобильных приложений. Но иногда разработчики хотят получить больше свободы и начинают применять небезопасные конфигурации которые могут привести к утечке чувствительной информации, файлов или даже к захвату контроля над хранилищем Firebase.
Конфигурация Firebase
Как правило, в конфигурации добавляются API ключ, URL хранилища и базы данных, идентификатор приложения и название проекта. Пример конфигурации:
В зависимости от потребностей разработчика, их можно встретить в разных местах:
- Внутри страницы как отдельный массив с параметрами для дальнейшего доступа из других JavaScript сценариев.
- Отдельный JavaScript файл, например, firebase-messaging-sw.js, firebase-config.js и многие другие, зависит от фантазии разработчика.
- Внутри мобильного приложения.
Само по себе наличие конфигурации не считается уязвимостью, но при некорректной конфигурации ключ может быть использован для регистрации или анонимной аутентификации с получением дальнейшего доступа к данным проекта:
curl -k -v 'https://identitytoolkit.googleapis.com/v1/accounts:signUp?key=AIza...' \
-H 'Content-Type: application/json' \
--data '{"email":"EMAIL","password":"ПАРОЛЬ","returnSecureToken":true}'Можно отправить в качестве данных любой Email и пароль, либо пустое тело {} что будет считаться как анонимной регистрацией. Если разработчик разрешил свободную регистрацию, в ответе от сервера мы получим idToken и refreshToken с помощью которых мы можем обращаться к API Firebase.
Мисконфигурации
Если разработчик изменил конфигурацию по умолчанию, это может привести к непредсказуемым уязвимостям и раскрытию информации, среди которых:
- Анонимный или аутентифицированный доступ к Storage Bucket (от чтения до изменения / удаления произвольных файлов в хранилище)
- Анонимный или аутентифицированный доступ к Real-time Database
- Извлечение чувствительной информации или модификация шаблона Remote Config
- Анонимный или аутентифицированный доступ к коллекциям Firestore (от чтения коллекциий до модификации и удаления объектов в коллекции)
В объектных хранилищах разработчики могут хранить как статичные файлы используемые другими приложениями, так и пользовательские данные, нередко используя коллекции Firestore для хранения данных о зарегистрированных пользователях. Пример обращения к API Firebase для получения листинга объектов в хранилище с полученной в результате регистрации сессии:
curl -k -v https://firebasestorage.googleapis.com/v0/b/%storageBucket%/o \ -H 'Authorization: Bearer eyJ...'
Реальные случаи взлома
В рамках аудита конфигураций выявленных с помощью Метаскан у наших клиентов мы обнаружили API ключ который позволял осуществить регистрацию. Сценарий атаки следующий:
- Обнаружен файл firebase-messaging-sw.js содержащий стандартную конфигурацию Firebase.
- С использованием API ключа была осуществлена регистрация через API Firebase.
- После получения сессии был получен полный доступ к хранилищу объектов с возможностью чтения, изменения и удаления объектов.
Среди объектов были статические файлы которые использовались в мобильном приложении, в результате эксплуатации мы могли подменить статический контент для осуществления массовой атаки на пользователей.
С этой сессией была возможность загрузки и перезаписи файлов через PUT метод и удаление через DELETE метод.
Заключение
Для автоматизации всех проверок сделали утилиту firebase-tester которая позволяет проверить все известные (кроме отправки пуш сообщений) недостатки в конфигурации Firebase.
Метаскан позволяет упростить процесс поиска данных конфигураций при помощи модулей Dirsearch и ZAP (кастомный скрипт для поиска ключей по регулярным выражениям).