Особенность генерации логинов
Посмотрев на свой логин, я заметил особенность, что он состоял из фамилии, первой буквы имени и первой буквы отчества (всё это транслитерируется) и пароль был таким же. Например, у Иванова Ивана Ивановича будет логин и пароль ivanovii, у Сидорова Петра Сергеевича будет sidorovps. В случае «я» будет меняться на «ya», а не на «ia», и «ц» на «c».
Я решил проверить предположение и взял имя, фамилию и отчество одноклассника и успешно авторизовался под его аккаунтом. Потом я проделал те же действия, взяв имя, фамилию и отчество учителя, и успешно авторизовался под его аккаунтом. Получается, любой ученик мог авторизоваться под учителем и менять свои оценки? Я, конечно, понимаю, что у нас в стране не особо занимаются обеспечением безопасности и приватности персональных данных детей (ФИО и даже оценки — персональные данные), но учителя (может быть не все учителя), они не понимают, что можно побеспокоиться о безопасности своих аккаунтов. Самое классное было то, что после я получил доступ к аккаунту директора гимназии, однако позже выяснил, что он не имеет особых привилегий и прав.
Немного покапав модуль сообщений, я смог украсть фамилии, имена и отчества всей школы — учеников, их родителей и учителей. То есть, получив доступ к аккаунту Васи, я мог украсть персональные данные всей его школы и, взломав небольшое количество аккаунтов, я мог украсть перс. данные многих людей. Дальше я решил проверить, правда ли то, что персональные данные большого количества людей находятся под угрозой.
Брутфорс по логинам
Брутфорс проводился по логинам сгенерированными по выше описанным особенностям и при переборе пароль был эквивалентен логину. Авторизация у журнала шла через их API, которое выдавало auth_token (при правильном логине и пароле) или ошибку (при неправильном логине/пароле). Отправляемые данные состояли из
login — логин в стандартном виде password_hash — md5(pass + «4f8202ccd76210b47b40627c621daa56»)
Хеш генерировался на стороне клиента и отправлялся Ajax запросом вместе с логином на API. Не видел, чтобы где-нибудь в крупном продукте или проекте авторизация происходила так. Соль добавлялась для криптостойкости, чтобы хеш трудно было взломать, если его перехватят.
Я написал php скрипт, который принимал login, создавал хеш пароля, с помощью cUrl отправлял запрос на API журнала и возвращал ответ, который состоял из:
id — идентификатор пользователя email — E-mail пользователя (по умолчанию: логин@example.com) type — тип аккаунта («teacher», «student», «parent») school_id — идентификатор школы school_shortname — название школы first_name — имя last_name — фамилия middle_name — отчество authentication_token — токен, который кладётся в cookie, а при следующий запросов на API отправляется в виде HTTP-Header'a password_change_required — если «true», журнал предложит сменить пароль date_of_birth — дата рождения sex — пол
Сама прога для брутфорса была написана на Python, она отправляла запрос на сервер, где был php скрипт, и записывала ответ в файл, если авторизация проходила успешно. Статистика ущерба
Я перебрал популярные фамилии (по моему мнению): Иванов, Иванова, Петров, Петрова, Сидороа, Сидорова, Гончаров и Гончарова. Получается 8 * 26 * 26 (кол-во фамилий * кол-во букв в английском алфавите * кол-во букв в английском алфавите) = 5408 логинов и паролей. Из около 1500 были верные. Около половины из них были с «password_change_required»: true, но пароли никто не менял.