Хотелось бы немного рассказать о подходе повествования в данном посте. Всё описанное имеет реальные случаи произошедшие из моей личной практики, в большинстве своём это популярные проекты, поэтому в тексте буду их упоминать. Главное на что я хотел бы обратить внимание — эта статья может показаться не интересной специалистам ИБ, т.к. она не содержит никаких новых векторов атаки и супер крутых подходов. Вся информация ориентирована на разработчиков и проект-менеджеров.
Проводя заказы на аудит целью ставится аналитика максимального ущерба при минимальных действиях и знаниях злоумышленника. Как показывает практика в суровых условиях производства ПО такие нюансы продумывают единицы проектов.
Одной из популярных проблем является восстановление пароля и получение доступа к учётным записям пользователей. Сейчас наверное не существует ни одного сайта где бы не была функция восстановления пароля. Я их поделил на несколько типов, чтобы рассмотреть каждый из них:
Конечно это только часть большого айсберга. Существуют проблемы и в других подходах, например OAuth, но об этом уже много писали и там всё же технические нюансы, а меня больше интересует бизнес-логика.
И так, рассмотрим слабые места каждого из пунктов выше.
Одним из серьёзных упущений данного подхода чаще всего является отсутствие возможности задавать свой вопрос, а так же после ввода правильного ответа выдача формы с вводом нового пароля.
По оперативной информации было выяснено, что данная атака проводилась на компанию WesternUnion и дала повод серьёзно задуматься о безопасности данной функции, а так же временно ограничить её. Проведя аналитику сервиса было установлено, что на выбор для пользователя давалось 3 варианта вопросов: имя домашнего питомца, родной город и девичья фамилия матери. Ответы на эти вопросы получить для десятков пользователей по средством социальной инженерии не составило труда. На помощь пришли социальные сети facebook, twitter, lj и другие.
Помимо социальной инженерии была и более техническая возможность, варианты с ответом на родной город и имя питомца возможно было подобрать по небольшим словарям. Данную атаку можно было предотвратить дополнительным полем каптчи, что в последствии и было сделано. Таким образом из-за обычной недоработки функционала восстановления паролей злоумышленники смогли получить доступ к функции переводов WU с повышенными лимитами от профилей скомпрометированных пользователей. База по которой отрабатывали пользователей (логины и емайлы) была получена из другого источника, через более банальную уязвимость sql-injection, так же был размещён вредоносный код на главной странице взломанного сайта.
Выводы:
Интересная история произошла с одним из клиентов, который обратился за помощью. Начали активно поступать массовые жалобы на смены паролей у пользователей одной из популярных стартап-биржей NaPartner. Проведя анализ всех шагов восстановления пароля, единственным где могла быть проблема показалась уникальная ссылка имеющая всего 1 параметр с md5. Прогнав по базе этот md5-код был очень быстро получен результат и им оказался 4-х значный цифровой код вида md5(1234). Через несколько минут был получен готовый инструмент для тестирования, который принимал логин пользователя, посылал запрос на восстановление пароля и за считанные секунды в десяток потоков подбирал этот уникальный хеш, после чего через форму по уникальной ссылке ставил свой пароль 12345. Проблема была решена более сложным исходными данными для хеширования. Подобная проблема неоднократно наблюдалась и у других клиентов.
Стоит обратить внимание на несколько вещей:
Пожалуй, это самое распространённое и имеющее более сложный подход для получения доступа к учётной записи пользователей.
Здесь стоит отметить несколько рекомендаций:
К сожалению очень часто встречается 2 и 3 пункт вместе, что порождает для злоумышленников следующий алгоритм действий: запрос восстановления пароля, получение пользователем нового фиксированного пароля, который генерируется фиксированной длины из 5 символов или только цифр фиксированной длины. Дальнейший подбор этого пароля.
BONUS: В одной популярной онлайн игре Stronghold Kingdoms была одна единственная sql-injection в формах восстановления пароля/регистрации на поле логин(он же email) был ajax-запрос с проверкой существования данной записи в базе. Подобная проверка так же встречается очень часто на разных сайтах и хотелось бы описать возможности её эксплуатации даже если там нет sqli. Обычно это получение части базы пользователей: берут большие базы email адресов и прогоняют на существования их на сайте. А потом используют найденные для подбора логина/пароля. Это Вам может показаться очень странным и маловероятным, но если на кону стоят деньги или энтузиазм (а может оба), то нет ничего невероятного. Так же стоит отметить, что при восстановлении пароля бывает, когда просит ввести логин пользователя, а потом выдаёт сообщение на какой email был выслан пароль, что тоже может служить поводом для получения доступа к данной почте. Обязательно скрывайте звёздочками часть email.
Поскольку предыдущий пункт был очень скучный и разжеванный К.О., то предлагаю последним пунктом взять более интересную и не менее распространённую задачку с временными смс-кодами, тем более, что этот смс-код можно не только обойти, но и заставить владельца сайта раскошелиться.
Одним из заказов на аудит была Украинская компания, название её остаётся в секрет в связи с 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, когда при ошибке восстановления пароля можно было получить доступ к чужой учётной записи.
Когда работаешь в данном направлении и каждый раз изучаешь разные аферы, иногда просто удивляешься как до такого могли вообще додуматься. Многое скажите Вы очевидные вещи, но все эти очевидные вещи становятся только после того, как мы обращаем на них внимания, а обычно это бывает по факту совершения злоумышленниками преступления.
Очень часто мне задают вопрос, а кто из сотрудников должен отвечать за подобные недоработки? И мне действительно хочется сказать, что все понемногу виноваты. Но когда я смотрю на эти вещи не как специалист по ИБ, читающий кучу новостей и статей, проводящий мониторинг тематических форумов и вникающий во все мошеннические схемы, а как обычный человек без всей это информации, то одёргиваю себя и останавливаюсь на мысли, что только человек имеющий всю это корыстную гадость в голове сможет обдумывать все эти нюансы заранее и причём сложность действий зависеть будет только от его изощрённого воображения. :)
На этом первую часть объявляю оконченной. Если подход в данной статье Вам понравится, то продолжу писать. Имеется много примеров, которые я раскидал на разные темы.
Проводя заказы на аудит целью ставится аналитика максимального ущерба при минимальных действиях и знаниях злоумышленника. Как показывает практика в суровых условиях производства ПО такие нюансы продумывают единицы проектов.
Одной из популярных проблем является восстановление пароля и получение доступа к учётным записям пользователей. Сейчас наверное не существует ни одного сайта где бы не была функция восстановления пароля. Я их поделил на несколько типов, чтобы рассмотреть каждый из них:
- Контрольный вопрос — ответ
- Уникальная ссылка на email
- Отсылка нового/действующего пароля на email
- SMS OTP (One-time password)
Конечно это только часть большого айсберга. Существуют проблемы и в других подходах, например 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, когда при ошибке восстановления пароля можно было получить доступ к чужой учётной записи.
Когда работаешь в данном направлении и каждый раз изучаешь разные аферы, иногда просто удивляешься как до такого могли вообще додуматься. Многое скажите Вы очевидные вещи, но все эти очевидные вещи становятся только после того, как мы обращаем на них внимания, а обычно это бывает по факту совершения злоумышленниками преступления.
Очень часто мне задают вопрос, а кто из сотрудников должен отвечать за подобные недоработки? И мне действительно хочется сказать, что все понемногу виноваты. Но когда я смотрю на эти вещи не как специалист по ИБ, читающий кучу новостей и статей, проводящий мониторинг тематических форумов и вникающий во все мошеннические схемы, а как обычный человек без всей это информации, то одёргиваю себя и останавливаюсь на мысли, что только человек имеющий всю это корыстную гадость в голове сможет обдумывать все эти нюансы заранее и причём сложность действий зависеть будет только от его изощрённого воображения. :)
На этом первую часть объявляю оконченной. Если подход в данной статье Вам понравится, то продолжу писать. Имеется много примеров, которые я раскидал на разные темы.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.
Нужны ли статьи по ИБ в таком жанре?
92.19% Да956
7.81% Нет81
Проголосовали 1037 пользователей. Воздержались 142 пользователя.
