В этой статье я расскажу, как из одного сообщения об ошибке на сайте я случайно получил доступ к внутренней информации компании (и даже немного больше). Отмечу, что это можно проделать, используя один лишь браузер.
Пролог
Сайты иногда падают. Такое случается. Но вот то, что описано в статье, случаться не должно.
#1
Недавно зашёл на сайт одной компании и увидел (в очередной раз, замечу) вместо него сообщение об ошибке:
Почему сайт упал — это отдельный разговор. Скажу лишь, что это на совести его разработчиков.
Первая ошибка (слишком очевидная, но…): показ сообщений об ошибках. Да, все знают, что нужно отключать дебаг в продакшене. Но, чёрт возьми, почему я регулярно вижу сообщения об ошибках в своём браузере?!
#2
Итак, что мы можем почерпнуть из этого сообщения? Да ни много ни мало публичный адрес SOAP-сервиса. Ну ладно, вряд ли он всё-таки доступен открыто, но на всякий случай копируем в адресную строку и получаем… список доступных методов. Много методов, бо́льшая часть явно для внутреннего пользования. К каждому прилагается описание запроса и пример ответа. Многие требуют авторизацию (передачу в запросе логина и пароля), но далеко не все. Выбираем один открытый метод с говорящим названием и конструируем запрос прямо в браузере. Да, многие ругают встроенный в Firefox Web Developer (и есть за что), но для простых задач он вполне пригоден:
Вторая ошибка: доступные публично сервисы. Вот зачем этот сервер смотрит в мир? Им пользуются какие-то удалённые приложения? Хорошо, тогда закройте его авторизацией. Или хотя бы не сопровождайте подробной инструкцией к действию.
#3
Посмотрим, что ответил нам сервер. Для удобства просмотра откроем полученный XML всё в том же браузере:
Это список сотрудников компании, чуть менее двухсот элементов. Отлично, поищем руководство. Находим, мягко говоря, не последнего человека в компании (на скриншоте). Теперь мы знаем его email и что-то подозрительно похожее на Base64 в элементе SotrudnikPassword. Декодируем пароль в любом из множества онлайн-декодеров.
Третья ошибка: пароли в открытом виде. Даже если вынести за скобки вопрос, зачем вообще отдавать пароли (хеши) наружу, всё равно непонятно, почему хотя бы не хеши. Или девелоперы считают, что Base64 подходит для этих целей?
Примечание: ошибки #4 и #5 относятся уже не к безопасности сервисов, а к личной безопасности. Тут вина не разработчиков, а пользователя, но я решил оставить их, поскольку они а) часть этой истории б) такие же банальные и всем очевидные, но так же часто совершаемые.
#4
Посмотрим, что можно сделать с полученной информацией. Попробуем получить доступ к указанной почте. Проверяем домен в первом попавшемся сервисе просмотра DNS-записей. Судя по MX, это GMail. Что ж, попробуем авторизоваться, используя декодированный пароль:
Вы ведь не удивитесь, если я скажу, что пароль подошёл?
Четвёртая ошибка: один пароль для разных учётных записей. Будет не важно, какой он длины и сколько в нём букв разного регистра и цифр, если он утечёт по вашей или чьей-либо (как в этом случае) глупости.
#5
Пароль подошёл, но Google на страже безопасности пользователя — видит, что зашли с другого IP, и требует дополнительного подтверждения:
Вот только последний предлагаемый им вариант выглядит слишком просто. Google, ты серьёзно?
В данном случае была достаточно редкая фамилия, поэтому не понадобилось даже название компании указывать. Попробуем ввести найденный телефон:
Подходит. Открывается корпоративный GMail (и, соответственно, Google Tasks, Google Drive и прочие сервисы).
Пятая ошибка: использование в качестве дополнительного фактора авторизации/контрольного вопроса легко узнаваемой информации (в данном случае известного другим и интернету номера телефона). Сложно ли узнать девичью фамилию матери или дату её рождения? Так почему многие сервисы и банки по-прежнему используют их по умолчанию?
Эпилог
Написал этому человеку письмо о необходимости сменить пароль. Ещё принято сообщать об уязвимостях разработчикам и давать время на исправление. Но. Перечитайте ошибки #1—#3. Нужно сообщить им, что у них сообщения о падениях всем показываются, серверы, простите, голой ж. в интернет смотрят и пароли отдаются первому встречному разве что не плейн-текстом? Об этом действительно нужно напоминать коммерческим разработчикам, претендующим на корпоративный уровень? О вещах столь простых и очевидных, что без знания их и на работу-то брать не должны? Надеюсь, что они это прочитают и узнают себя. Хочу сказать им только одно: «Ребята, вон из профессии!»
О себе: не разработчик, не специалист по безопасности и вообще никаким боком не IT. Продвинутый пользователь интернета, скажем так.
Автор: fed-rev
