09.03.2026 14:37
krutmaster 22 9400 Источник

Источников оказалось немного: пара постов на Хабре про саму уязвимость и ответки пресс-службы MAX. Вот сам пост с Хабра, где рассказана вся ситуация.

Мне больше другое интересно стало. Во‑первых, является ли уязвимость критичной, если доступ к ней возможен при очень большом переборе ссылок? Да, это в любом случае уязвимость, но настолько ли она критичная? Во‑вторых: а что если эти ссылки и доступ по ним возможен только после самой их компрометации? То есть как в облаке: ты сначала ссылку публичную получил, и уже после доступ к файлу возможен перебором по ссылке без авторизации, потому что ты это вообще позволил, а по умолчанию всё с твоими файлами нормально. Потому что из поста выше и всех перечисленных там ссылок не следует того, что эти ссылки изначально не были вскрыты или переданы.

Меня учили в вузе, что если мы сталкиваемся с комплексной задачей, то и её оценку тоже надо проводить комплексно. А ещё, что если это не семинар, то придумывать велосипед необязательно и можно достать табличку объёмов красных шариков, которую за тебя уже составили эксперты по красным шарикам. В нашем случае это ФСТЭК (разрабатывает стандарты и требования по защите персональных данных (ПДн) и критической информационной инфраструктуры (КИИ) в РФ) и CVSS (Открытый стандарт, используемый для расчёта количественных оценок уязвимости в безопасности компьютерной системы, обычно чтобы понять приоритет её исправления).

Так мы сможем описать и дать оценку конкретному сценарию эксплуатации уязвимости. Но помня мои вопросы выше, ради объективности и полного раскрытия темы мы рассмотрим два сценария:

  1. Любой человек с прямым URL может без авторизации открыть фото.

  2. Любой человек с утёкшим или полученным от самого пользователя URL может без авторизации открыть фото.

С вашего позволения, расписывать методику расчёта я не буду, про это есть много других статей, посмотрим сразу на получившийся вектор для первого сценария:

  • AV:N — атака по сети, удалённо.

  • AC:L — сложность низкая: просто открыть URL, специальных условий почти нет.

  • PR:N — привилегии не нужны: логин не нужен.

  • UI:N — взаимодействие жертвы не требуется в момент эксплуатации; атакующий сам открывает ссылку.

  • S:U — чтение файла в пределах того же сервиса.

  • C:H — влияние на конфиденциальность высокое, потому что раскрывается содержимое приватного пользовательского файла.

  • I:N, A:N — на целостность и доступность в описанном сценарии влияния нет.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. Числовая оценка этого вектора — 7.5, по ФСТЭК это высокий уровень угрозы.

Для второго сценария меняется только один пункт: UI:R — нужен внешний акт взаимодействия/утечки. Получится CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N, это уже 6.5 — средний уровень угрозы по ФСТЭК.

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

Лично я не верю, что в Максе этого не понимают, им просто нужно было дать какой‑то ответ, а сами они в темпе вальса сейчас всё чинят и исправляют, я так хочу думать. Возможно моя оценка грубая и нужно было бы учитывать ещё какие‑то вещи, но как мне кажется вот такого подхода должно быть достаточно для однозначного ответа по классификации угрозы, связанной с возможностью открытия фото по ссылке.

Всем спасибо за внимание, будем и дальше комментировать ситуацию (да и в целом много интересного в IT) в тг.

Комментарии (22)


  1. kipar
    09.03.2026 15:26
    #29640508

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

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


    1. Sixshaman
      09.03.2026 15:26
      #29640528

      Просто биткоин-кошельков хотя бы с 1 BTC меньше миллиона в мире. А в мессенджере MAX зарегистрировалось уже 1 трлн пользователей, и их число только растёт!


      1. KeisN13
        09.03.2026 15:26
        #29642272

         А в мессенджере MAX зарегистрировалось уже 1 трлн пользователей

        Спасибо, поржал. Вспомнил серию саус парка про наводнение xD


    1. Bedal
      09.03.2026 15:26
      #29640618

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

      Другое дело, кому нужен весь этот мусор...


      1. kipar
        09.03.2026 15:26
        #29640644

        Если перебирать не 128 бит картинок конкретного пользователя (а это что-то типа одного шанса из триллиона найти хоть одну из его триллиона картинок за 10 лет поисков со скоростью в миллион запросов в секунду) а перебирать еще и 128 бит в поисках существующих пользователей, то шансы найти хоть что-то становятся только меньше.


        1. Bedal
          09.03.2026 15:26
          #29640710

          Вы исходите из того, что адрес сам по себе практически зашифрован. Это точно так? Там точно длина имени такая? И т.п.


          1. kipar
            09.03.2026 15:26
            #29640734

            Сужу по посту по ссылке.

                144 бита - заголовок непонятного назначения;
    128 бит - идентификатор картинки (должно быть достаточно чтобы гарантировать невозможность перебор);
    128 бит - идентификатор пользователя (ИД чата, он узнается отправкой одной картинку пользователю и потом постоянен).


            1. Bedal
              09.03.2026 15:26
              #29641024

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


              1. kipar
                09.03.2026 15:26
                #29642284

                В наше время на всех ОС для генерации уидов есть стандартный, достаточно случайный, вариант (RtlGenRandom/arc4random/getrandom/urandom). Если вместо него кто-то догадается использовать rand() - это конечно будет грубая ошибка и серьезная уязвимость, но к этому никаких предпосылок я не вижу.


                1. Bedal
                  09.03.2026 15:26
                  #29642332

                  тоже верно. Ну, посмотрим, практика покажет


            1. pfub
              09.03.2026 15:26
              #29647974

              Я немного поковырял эти ссылки и получил такой результат:
              - Заголовок/префикс фиксированный и не меняется от картинки к картинке. Он чуть больше, чем 144 бита, но это не суть важно
              - ID картинки тоже больше, на него отводится 21 символ с 64-символьным алфавитом
              - 1 символ неизвестного предназначения, который меняется в зависимости от указанного ID пользователя
              - ID пользователя, который можно заменить на любой другой известный ID, например, свой.
              Если заранее известен ID картинки, то можно без проблем перебрать 1 символ со своим ID и получить доступ к картинке. Перебирать ID картинок бессмысленно, так как это займет просто бесконечное количество времени, о чем было сказано выше.
              Кроме того, вероятно, ID картинки - это хеш от какой-то ее части, т.к. при отправке одинаковых изображений им присваивается один и тот же ID. Может, конечно, сделаны какие-то проверки на уровне сервера и если ее отпечаток совпадает, то новый объект не создается, но, думаю, так сильно никто не парился и в ссылке указывается хеш от картинки. Моих навыков реверса не хватит, чтобы докопаться до истины, но пища для размышления имеется


  1. Tavrid
    09.03.2026 15:26
    #29640730

    Как выяснилось раньше в почившем проекте oneme откуда был взят сервис хранения и распространения фоточек этот баг был, и уровень у него был Low (некритический). Но там как-бы изначально не было max-секретности и гос-защиты.
    Как это можно починить не уничтожив все миллионы уже отправленных фоточек - это задача высокого уровня.
    По вопросу того что вообще так быть не должно, то где-то в недрах max могут вот так открыто лежать чертежи атомной лодки или бомбардировщика из какой-нибудь игры... или не игры. Бессрочный адрес-токен (заменяющий пароль доступа или авторизацию) не есть хорошо, и разрабы это должны были понимать, но кто-то их гнал по срокам и они тупо забили на повышение уровня безопасности. Т.е. даже взламывать ничего не надо - интимные и личные фоточки все там и так лежат в общедоступном виде. Причем они не закрыты по гео для всего враждебного мира.


  1. Ndochp
    09.03.2026 15:26
    #29640766

    А как оцените угрозу "любой человек с логином и паролем может скачать содержимое чата"? Кажется аналогично п.1, нет? Единственная разница - надо сравнить длину пароля и случайной части ссылки.


  1. LinkToOS
    09.03.2026 15:26
    #29640978

    Ещё раз уточню: речь идёт о самом факте возможности использовать прямую ссылку

    Еще вопрос - является ли сложная ссылка эквивалентом пароля?

    Допустим есть объект на сервере. Вариант 1 - Путь к объекту известен всем, но для доступа требуется ввести пароль. Вариант 2 - пароль не нужен, но путь известен только владельцу объекта (ссылка длинная и сложная). Вариант 3 - и путь и пароль знает только владелец объекта.

    Эквивалентны ли эти варианты?


    1. digrobot
      09.03.2026 15:26
      #29641080

      Сложная ссылка - это тоже токен (пароль) для доступа к ресурсу. Только лежит он не в куках, как сессия, а в адресной строке.
      В принципе, раньше это не считалось проблемой. Запостил где-то приватную ссылку на всеобщее обозрение - сам виноват. Случайно это сделать едва ли можно.
      Но с некоторых пор авторы браузеров обнаглели и стали отправлять все ссылки себе, под предлогом безопасности. И никто им не настучал по голове.


      1. tbp2k5
        09.03.2026 15:26
        #29641606

        Ошибаетесь. URL никогда не был каким-то особым секретом: он оседает в куче логов (прокси, модули антивируса, плагины навигатора при доступе через веб, и т.д.). TLS частично спасает ситуацию, но лишь в контролируемых условиях (только из приложения на телефоне).
        И в любом случае, если пользователь меняет пароль - URL тоже должен меняться иначе он ничего толком не защищает.


        1. LinkToOS
          09.03.2026 15:26
          #29643340

          URL никогда не был каким-то особым секретом: он оседает в куче логов (прокси, модули антивируса, плагины навигатора при доступе через веб, и т.д.).

          Это кстати аргумент. Пароль храниться только у пользователя. Причем он может хранить пароль вне компьютера. А URL может непредсказуемо "валяться во многих местах интернета", из-за технических особенностей интернета. То есть распространение информации явно уходит из под контроля. По факту безопасность снижается.


        1. Ndochp
          09.03.2026 15:26
          #29647340

          С одной стороны не секрет, с другой user:pass@server/res - вроде уже и секрет.


          1. tbp2k5
            09.03.2026 15:26
            #29647376

            Этот формат, как и telnet, открытый на upload ftp, и т.д. - давно исчезли из реального использования из-за очевидных проблем с безопасностью. Но даже в эти бородатые времена "user" мог поменять свой "pass"...

            Security through obscurity - это архитектурный тупик. IMHO конечно.


  1. ABRogov
    09.03.2026 15:26
    #29641108

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


  1. Cas_on
    09.03.2026 15:26
    #29643074

    Некорректно выбран алгоритм оценки уязвимости. Как минимум AC:L и PR:N  не применим в данном случае. И, если подходить с Вашим алгоритмом чисто формально, то и парольная защита это уязвимость уровня 7.5...


  1. yurikgl
    09.03.2026 15:26
    #29653780

    Проблема "оправданий" в том, что ссылки на картинки и файлы, которые мы открываем в браузере, не особо защищаются, в отличие и сессий. Как верно указали выше, их могут (не всегда) видеть антивирусы, прокси и ещё много кто. Это подтверждает факт, что ещё недавно на https://web.archive.org/ были опубликованы тысячи (или миллионы, не помню точно) таких ссылок.

    Т.е. эти ссылки не надо специально подбирать. Они оседают в логах разных систем.