Comments 22
Сложность брутфорса не оправдание, так как ничего не мешает запускать от нечего делать такой перебор и раз в неделю открывать и смотреть, что он поймал интересного.
Почему бы тогда пароли к биткоин кошелькам не начать подбирать?
По-моему сложность брутфорса тут имеет принципиальное значение - если за разумное время ничего найти нельзя, то от такого брутфорса угрозы нет.
Просто биткоин-кошельков хотя бы с 1 BTC меньше миллиона в мире. А в мессенджере MAX зарегистрировалось уже 1 трлн пользователей, и их число только растёт!
потому, что форсится не точный адрес конкретной картинки, а "всё, что попадётся при переборе". Медиафайлов на несколько порядков больше, чем юзеров. Соответственно, и вероятность выгрузки чего-нибудь далеко не нулевая даже при скромных затратах.
Другое дело, кому нужен весь этот мусор...
Если перебирать не 128 бит картинок конкретного пользователя (а это что-то типа одного шанса из триллиона найти хоть одну из его триллиона картинок за 10 лет поисков со скоростью в миллион запросов в секунду) а перебирать еще и 128 бит в поисках существующих пользователей, то шансы найти хоть что-то становятся только меньше.
Вы исходите из того, что адрес сам по себе практически зашифрован. Это точно так? Там точно длина имени такая? И т.п.
Сужу по посту по ссылке.
144 бита - заголовок непонятного назначения;
128 бит - идентификатор картинки (должно быть достаточно чтобы гарантировать невозможность перебор);
128 бит - идентификатор пользователя (ИД чата, он узнается отправкой одной картинку пользователю и потом постоянен).
ну, то есть, уиды. И вероятность что-то найти сильно зависит от того, насколько случаен генератор случайных чисел. И вот тут может быть сюрприз в виде стандартного, не слишком уж случайного, варианта.
Я немного поковырял эти ссылки и получил такой результат:
- Заголовок/префикс фиксированный и не меняется от картинки к картинке. Он чуть больше, чем 144 бита, но это не суть важно
- ID картинки тоже больше, на него отводится 21 символ с 64-символьным алфавитом
- 1 символ неизвестного предназначения, который меняется в зависимости от указанного ID пользователя
- ID пользователя, который можно заменить на любой другой известный ID, например, свой.
Если заранее известен ID картинки, то можно без проблем перебрать 1 символ со своим ID и получить доступ к картинке. Перебирать ID картинок бессмысленно, так как это займет просто бесконечное количество времени, о чем было сказано выше.
Кроме того, вероятно, ID картинки - это хеш от какой-то ее части, т.к. при отправке одинаковых изображений им присваивается один и тот же ID. Может, конечно, сделаны какие-то проверки на уровне сервера и если ее отпечаток совпадает, то новый объект не создается, но, думаю, так сильно никто не парился и в ссылке указывается хеш от картинки. Моих навыков реверса не хватит, чтобы докопаться до истины, но пища для размышления имеется
Как выяснилось раньше в почившем проекте oneme откуда был взят сервис хранения и распространения фоточек этот баг был, и уровень у него был Low (некритический). Но там как-бы изначально не было max-секретности и гос-защиты.
Как это можно починить не уничтожив все миллионы уже отправленных фоточек - это задача высокого уровня.
По вопросу того что вообще так быть не должно, то где-то в недрах max могут вот так открыто лежать чертежи атомной лодки или бомбардировщика из какой-нибудь игры... или не игры. Бессрочный адрес-токен (заменяющий пароль доступа или авторизацию) не есть хорошо, и разрабы это должны были понимать, но кто-то их гнал по срокам и они тупо забили на повышение уровня безопасности. Т.е. даже взламывать ничего не надо - интимные и личные фоточки все там и так лежат в общедоступном виде. Причем они не закрыты по гео для всего враждебного мира.
А как оцените угрозу "любой человек с логином и паролем может скачать содержимое чата"? Кажется аналогично п.1, нет? Единственная разница - надо сравнить длину пароля и случайной части ссылки.
Ещё раз уточню: речь идёт о самом факте возможности использовать прямую ссылку
Еще вопрос - является ли сложная ссылка эквивалентом пароля?
Допустим есть объект на сервере. Вариант 1 - Путь к объекту известен всем, но для доступа требуется ввести пароль. Вариант 2 - пароль не нужен, но путь известен только владельцу объекта (ссылка длинная и сложная). Вариант 3 - и путь и пароль знает только владелец объекта.
Эквивалентны ли эти варианты?
Сложная ссылка - это тоже токен (пароль) для доступа к ресурсу. Только лежит он не в куках, как сессия, а в адресной строке.
В принципе, раньше это не считалось проблемой. Запостил где-то приватную ссылку на всеобщее обозрение - сам виноват. Случайно это сделать едва ли можно.
Но с некоторых пор авторы браузеров обнаглели и стали отправлять все ссылки себе, под предлогом безопасности. И никто им не настучал по голове.
Ошибаетесь. URL никогда не был каким-то особым секретом: он оседает в куче логов (прокси, модули антивируса, плагины навигатора при доступе через веб, и т.д.). TLS частично спасает ситуацию, но лишь в контролируемых условиях (только из приложения на телефоне).
И в любом случае, если пользователь меняет пароль - URL тоже должен меняться иначе он ничего толком не защищает.
URL никогда не был каким-то особым секретом: он оседает в куче логов (прокси, модули антивируса, плагины навигатора при доступе через веб, и т.д.).
Это кстати аргумент. Пароль храниться только у пользователя. Причем он может хранить пароль вне компьютера. А URL может непредсказуемо "валяться во многих местах интернета", из-за технических особенностей интернета. То есть распространение информации явно уходит из под контроля. По факту безопасность снижается.
С одной стороны не секрет, с другой user:pass@server/res - вроде уже и секрет.
Этот формат, как и telnet, открытый на upload ftp, и т.д. - давно исчезли из реального использования из-за очевидных проблем с безопасностью. Но даже в эти бородатые времена "user" мог поменять свой "pass"...
Security through obscurity - это архитектурный тупик. IMHO конечно.
Другое дело, что можно получить данные каким-то другим путем, а объяснить их чисто случайным перебором. Плюс пароль явно указывает на защищенную информацию, и его перебор не законен. А с открытой ссылкой сложнее доказать умысел, ну случайно кот упал на клавиатуру и тут открылось...
Некорректно выбран алгоритм оценки уязвимости. Как минимум AC:L и PR:N не применим в данном случае. И, если подходить с Вашим алгоритмом чисто формально, то и парольная защита это уязвимость уровня 7.5...
Проблема "оправданий" в том, что ссылки на картинки и файлы, которые мы открываем в браузере, не особо защищаются, в отличие и сессий. Как верно указали выше, их могут (не всегда) видеть антивирусы, прокси и ещё много кто. Это подтверждает факт, что ещё недавно на https://web.archive.org/ были опубликованы тысячи (или миллионы, не помню точно) таких ссылок.
Т.е. эти ссылки не надо специально подбирать. Они оседают в логах разных систем.
В MAX есть доступ к фото по ссылке: Уязвимость или нет? По ФСТЭК и CVSS