Заметки о безопасности. Восстановление пароля

    Хотелось бы немного рассказать о подходе повествования в данном посте. Всё описанное имеет реальные случаи произошедшие из моей личной практики, в большинстве своём это популярные проекты, поэтому в тексте буду их упоминать. Главное на что я хотел бы обратить внимание — эта статья может показаться не интересной специалистам ИБ, т.к. она не содержит никаких новых векторов атаки и супер крутых подходов. Вся информация ориентирована на разработчиков и проект-менеджеров.
    Проводя заказы на аудит целью ставится аналитика максимального ущерба при минимальных действиях и знаниях злоумышленника. Как показывает практика в суровых условиях производства ПО такие нюансы продумывают единицы проектов.



    Одной из популярных проблем является восстановление пароля и получение доступа к учётным записям пользователей. Сейчас наверное не существует ни одного сайта где бы не была функция восстановления пароля. Я их поделил на несколько типов, чтобы рассмотреть каждый из них:

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

    И так, рассмотрим слабые места каждого из пунктов выше.

    Контрольный вопрос — ответ


    Одним из серьёзных упущений данного подхода чаще всего является отсутствие возможности задавать свой вопрос, а так же после ввода правильного ответа выдача формы с вводом нового пароля.
    По оперативной информации было выяснено, что данная атака проводилась на компанию WesternUnion и дала повод серьёзно задуматься о безопасности данной функции, а так же временно ограничить её. Проведя аналитику сервиса было установлено, что на выбор для пользователя давалось 3 варианта вопросов: имя домашнего питомца, родной город и девичья фамилия матери. Ответы на эти вопросы получить для десятков пользователей по средством социальной инженерии не составило труда. На помощь пришли социальные сети facebook, twitter, lj и другие.
    Помимо социальной инженерии была и более техническая возможность, варианты с ответом на родной город и имя питомца возможно было подобрать по небольшим словарям. Данную атаку можно было предотвратить дополнительным полем каптчи, что в последствии и было сделано. Таким образом из-за обычной недоработки функционала восстановления паролей злоумышленники смогли получить доступ к функции переводов WU с повышенными лимитами от профилей скомпрометированных пользователей. База по которой отрабатывали пользователей (логины и емайлы) была получена из другого источника, через более банальную уязвимость sql-injection, так же был размещён вредоносный код на главной странице взломанного сайта.

    Выводы:
    • Возможность задавать свой контрольный вопрос — ответ, без ограничений
    • Для ввода правильного ответа ограничение на кол-во попыток на единицу времени, например 10 попыток в час


    Уникальная ссылка на email


    Интересная история произошла с одним из клиентов, который обратился за помощью. Начали активно поступать массовые жалобы на смены паролей у пользователей одной из популярных стартап-биржей NaPartner. Проведя анализ всех шагов восстановления пароля, единственным где могла быть проблема показалась уникальная ссылка имеющая всего 1 параметр с md5. Прогнав по базе этот md5-код был очень быстро получен результат и им оказался 4-х значный цифровой код вида md5(1234). Через несколько минут был получен готовый инструмент для тестирования, который принимал логин пользователя, посылал запрос на восстановление пароля и за считанные секунды в десяток потоков подбирал этот уникальный хеш, после чего через форму по уникальной ссылке ставил свой пароль 12345. Проблема была решена более сложным исходными данными для хеширования. Подобная проблема неоднократно наблюдалась и у других клиентов.
    Стоит обратить внимание на несколько вещей:
    • Уникальная ссылка должна быть одноразовой и становиться неактивной после смены пароля или авторизации пользователя
    • Должно быть ограничение на кол-во попыток ввода кода, достаточно 5


    Отсылка нового/действующего пароля на email


    Пожалуй, это самое распространённое и имеющее более сложный подход для получения доступа к учётной записи пользователей.
    Здесь стоит отметить несколько рекомендаций:
    • Никогда не храните в открытом виде пароль пользователя и особенно не надо его отсылать на email
    • Никогда не отсылайте новый/временный пароль без предварительного подтверждения пользователя о его смене уникальной ссылкой
    • Никогда не генерируйте новые/временные простые и короткие пароли

    К сожалению очень часто встречается 2 и 3 пункт вместе, что порождает для злоумышленников следующий алгоритм действий: запрос восстановления пароля, получение пользователем нового фиксированного пароля, который генерируется фиксированной длины из 5 символов или только цифр фиксированной длины. Дальнейший подбор этого пароля.

    BONUS: В одной популярной онлайн игре Stronghold Kingdoms была одна единственная sql-injection в формах восстановления пароля/регистрации на поле логин(он же email) был ajax-запрос с проверкой существования данной записи в базе. Подобная проверка так же встречается очень часто на разных сайтах и хотелось бы описать возможности её эксплуатации даже если там нет sqli. Обычно это получение части базы пользователей: берут большие базы email адресов и прогоняют на существования их на сайте. А потом используют найденные для подбора логина/пароля. Это Вам может показаться очень странным и маловероятным, но если на кону стоят деньги или энтузиазм (а может оба), то нет ничего невероятного. Так же стоит отметить, что при восстановлении пароля бывает, когда просит ввести логин пользователя, а потом выдаёт сообщение на какой email был выслан пароль, что тоже может служить поводом для получения доступа к данной почте. Обязательно скрывайте звёздочками часть email.

    SMS OTP (One-time password)


    Поскольку предыдущий пункт был очень скучный и разжеванный К.О., то предлагаю последним пунктом взять более интересную и не менее распространённую задачку с временными смс-кодами, тем более, что этот смс-код можно не только обойти, но и заставить владельца сайта раскошелиться.
    Одним из заказов на аудит была Украинская компания, название её остаётся в секрет в связи с NDA. Это финансовый сервис, который был фанатично привязан к SMS OTP, чуть ли не на каждое действие. Меня это изрядно раздражало при тестировании, т.к. приходилось сидеть в обнимку с мобильным и вводить эти коды каждый раз. Но как оказалось потом, после авторизации можно было в профиле сменить смс-пароль, на обычный пароль. И тут мне это показалось отличным шансом взять за основу SMS OTP для получения доступа к учётным записям пользователей. Код приходящий по sms представлял из себя всегда 6 цифр и тут нельзя не упомянуть про md5(1234) который мы рассматривали выше. Да, логика у меня была той же. Первым делом я проверил кол-во попыток на ввод код и они оказались неограниченными, после было дело времени, написание рабочего прототипа для подбора SMS OTP и отправки запроса на установку в профиле своего пароля 12345.
    Таким образом удалось получить доступ к тестовому пользователю и осуществить от него вывод денежных средств с баланса.
    На этом я не остановился, во время тестирования я отослал себе уйму смсок на телефон и решил посчитать затраты:
    1 смс = 0.30 коп * реальная стоимость смсок для этого клиента
    Скрипт выполняющийся в 10 потоков шлёт минимум 1 запрос в секунду, то есть 10 запросов в секунду.
    Итого за 24 часа работы скрипта мы можем отослать 10 * 60 * 60 * 24 = 864 000 смс, что обойдётся клиенту в 259 200 Российских рублей (>$8000).
    Вывод: используйте ограничения как на отправку смс для одного логина, так и кол-во попыток проверки OTP.

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

    На этом про восстановление паролей хотел бы закончить. Единственное что хотелось бы добавить, что подобная уязвимость, как недостаточная сложность паролей и хешей в огромных кол-вах нас окружает. Последний такой пример компания СИТИЛИНК у которой дисконтные карты выдаются только для покупателей заплативших за раз от 5000р. Сама по себе карта очень полезная и позволяет экономить. Но вот технически карта является обычным 6 значным номером + 4 значным кодом активации с неограниченными попытками подбора этого кода.
    Так же стоит отметить недавний инцидент со skype, когда при ошибке восстановления пароля можно было получить доступ к чужой учётной записи.

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

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

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

    Only registered users can participate in poll. Log in, please.

    Нужны ли статьи по ИБ в таком жанре?

    Share post

    Comments 21

      +9
      Получается, что большинство описанных уязвимостей используют неограниченное количество попыток действий, связанных с безопасностью.
      Т.е. общий орг.вывод: не давать делать много раз то, что нужно делать мало раз + ограничивать скорость действий (капча или задержка по времени).
        +3
        Скорее нужна капча И задержка по времени. Т.к. большинство капч разгадываются автоматически с весьма большой точностью.
        +4
        С смс были аналогичные грабли с подписками и рассылками.
        Под утро был чуть удивлен счетом за смс в ХХк рублей.
          0
          Я считаю, что большая часть сайтов должны использовать авторизацию по OAuth или OpenID. Тогда и не надо задумываться о куче вопросов безопасности и юзабилити.
            +3
            Это лишь перекладывание вопросов безопасности на плечи другого сайта.
              0
              Полностью согласен — легче один раз подумать вопросы безопасности на паре крупных ресурсов, которые могут себе позволить нормальных специалистов по безопасности, чем каждый раз делать новую систему авторизации, а потом поддерживать кучу старых проектов.
                0
                С точки зрения пользователя это «о, здесь можно авторизоваться через вконташечку», через пару дней пароль от вконташечки уводят вместе с аккаунтом на вашем сайте. Удобно — да, безопасно — вряд ли.
                  +5
                  У ВК есть хорошая система восстановления пароля по СМС.

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

                  Из-за отсутствия удобства реальная безопасность паролей очень низка.
                    0
                    Тут вопрос не в том, как увести аккаунт на другом сайте, а в том, что это приведёт к автоматическому получению доступа к сайту с подобным механизмом авторизации. Да, когда пароли везде одинаковые, то разницы никакой. Но если пароли разные, то подобная авторизация уступает традиционным методам в плане безопасности.
                      +1
                      Если пароли одинаковы, то разница как раз есть большая — ваш общий пароль будет открыто передаваться без HTTPS, храниться открыто в базе мелких сайтов и т. п. — и безопасность будет гораздо ниже.
                    –3
                    Я вот только не понял, как могут увести ВК, но не аккаунт на сайте. Сомневаюсь, что в Рунете много сайтов, которые заботятся о безопасности больше, чем Гугль, ВК, Яндекс или Фейсбук.
                +2
                вот наглядный пример того, чем открытая авторизация может обренуться для пользователя.

                к тому же, ОА ограничивает функционал: нет возможности изменить отображаемое имя для конкретного ресурса, аватар и т.д… не говоря уже о случаях, когда нет желания выставлять на показ свои личные данные ради комментария на каком-нибудь мелком сайте.
                  +2
                  У OpenID было хорошее решение этой проблемы — свой домен, который привязан к сменяемым провайдерам.
                +3
                А разве обязательно отвечать на вопрос «Кличка вашего домашнего питомца», кличкой вашего домашнего питомца? По-моему это элементарная проблема безопасности при соц. инженерии, поэтому я не отвечаю на вопрос, а пишу не связанное с ним слово, иначе любой мой сосед сможет сбросить мой пароль.
                  +1
                  Конечно, желательно так и делать, но есть простое человеческое незнание всего этого, а ещё чаще мнение кому я нужен.
                    +1
                    Честно говоря, эти контрольные вопросы — на фоне существования социальной инженерии — открытая дыра в безопасности. Какой идиот их вообще придумал, и зачем многие сервисы на них повелись? Поубивал бы!.. :(
                    +4
                    Ага, и через четыре года начинаешь вспоминать, какую несвязанную фигню ты вколотил при регистрации.
                    Ответ на вопрос должен быть твоей ассоциацией, причем достаточно устойчивой.
                    — Гадость?
                    — Ваша рыба!
                      0
                      И пароли везде разные и все трудно запомнить. Слово несвязное, но это не набор символов, за много лет практики проблем не было.
                    0
                    Ребята из qip.ru с легкостью восстанавливают пароли от моих ящиков для неизвестных мне людей.
                    Пожалуй это было единственной причиной перестать ими пользоваться.
                      0
                      Через несколько минут был получен готовый инструмент для тестирования, который принимал логин пользователя, посылал запрос на восстановление пароля и за считанные секунды в десяток потоков подбирал этот уникальный хеш, после чего через форму по уникальной ссылке ставил свой пароль 12345

                      Зачем такие сложности для такого простого случая? Уже есть просчитанные таблицы хэшей до 7-9 символов (иногда достаточно просто вбить в гугл хэш от этой строки). И не нужно никаких многопоточных подборщиков.
                        0
                        Я согласен, можно взять готовые хеши, но ведь это задачка реально на пару минут. Какая разница тратить их на поиск базы или на пару строк кода. Тем более всё равно в итоге нужно кодить, чтобы он эти хеши проверял.
                        К тому же генерация хеша перед отсылкой запросов на скорость никак не повлияет.

                      Only users with full accounts can post comments. Log in, please.