Хабрахабр

Как я Telegram ломал

Как-то раз я взломал один из серверов telegram. Не то чтобы это было нечто интересное, да и сами уязвимости стандартные. Удивление скорее вызывает факт того, как телеграм относится к безопасности и почему на протяжении многих лет уязвимостями так никто и не воспользовался. Но, не ошибается тот, кто ничего не делает!
Ещё в мае 2017 года kyprizel обратил внимание на то, что telegram desktop может загружать ZIP-архивы к себе на сервер tdesktop.com. Как позже выяснилось, не только ZIP, а внутри там лежит информация о падении приложения, чтобы разработчик изучил при каких обстоятельствах произошло падение. К тому же разработчик получает к ним доступ через веб-интерфейс, судя по форме аутентификации. Я добавил хост в заметки и благополучно забыл.

На тот момент, в корне лежал файл error_log, в котором, как можно было догадаться, писались ошибки. Вспомнил я о нём примерно через год, когда обсуждали в чате предстоящие исследования. Но все мы ленивые, а в bug bounty я вообще стараюсь не учавствовать, поэтому все осталось как есть. Как минимум, там были полные пути к файлам, но помимо этого любимая ошибка «You have an error in your SQL syntax».

А когда у тебя нет материала для выступления — ты смотришь в заметки. Прошёл ещё год, меня пригласили выступить на конференции #PartyHack в Казани. Подозрительный хост в Telegram.
Так как на сервере использовался PHP, о чем свидетельствовал crash.php, я решил немного перебрать файлы с этим расширением, тогда я и наткнулся на info.php, где было содержимое функции phpinfo(). Что там у нас? Как же так? Первое, что я заметил — это использование веб-сервера Apache. Да и кто использует apache в 2019? У всего телеграма nginx, а тут Apache!

Я сразу вспоминаю про mod_status, который собирается с ним по-умолчанию. Что в первую очередь приходит в голову, когда слышишь Apache? Чаще всего путь к нему /server-status, редко просто /status. Этот модуль генерирует страницу с текущим состоянием сервера, про системные ресурсы, запросы на сервер, скорость их обработки. Чтобы понять, насколько это популярная ошибка администрирования, достаточно вспомнить, что она много лет висела на сайте apache.org

Я много лет собираю пути к потенциально опасным файлам и директориям в проекте fuzz.txt, поэтому server-status естественно был там.

Но в данном случае все запросы были с 127. Вообще в server-status примечательно то, что он показывает и IP адреса клиентов, которые отправляют запросы на сервер. 0. 0. Nginx на фронтовой части просто проксировал все запросы на локальный apache, поэтому раскрытия пользовательской информации не было. 1 на виртуальный домен preston-desktop.com. За небольшой промежуток времени было собрано множество уникальных ссылок, но в основном это запросы на обновления (с указанием версии), а загрузок крашей почти не было. Однако, стоило поставить server-status на мониторинг, вот небольшой скрипт сделанный на коленке, который кладет уникальные строки в базу данных sqlite. Через некоторое время я увидел админа.

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

Он возвращает, нужны ли еще логи о падении приложения, или версия уже свежая и об ошибках известно. Первый это query_report, который имеет дополнительные параметры apiid, version, dmp и platform. Механизм создан, чтобы не получать лишнее, а исправлять только актуальное.

Уже без дополнительных параметров. Второй — сам report. Если на предыдущий запрос вернулось слово, которое говорит о необходимости отправить дамп — файл отправляется.

Там же можно посмотреть, что данные отправляются с помощью multipart, где имя файла report.telegramcrash, а его Content-type application/octet-stream.

Таким образом, можно было попробовать позаливать собственные файлы и протестировать уязвимости связанные с распаковкой ZIP и прочими upload-штуками.

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

Использовав силу мегазорда (одинарная кавычка) в параметре platform можно было наблюдать аномальное поведение ресурса.

Для проверки достоверности можно написать какое-нибудь логическое выражение, например platform=mac’ AND ‘a’=’a. Есть кавычка — ошибка, нет кавычки — все хорошо. В ответе Done, как при удачной заливке файла.

Предвидя вопросы — все остальное было хорошо настроено, пользователь в СУБД не привилегированный. Ну-с, не зря же придумали автоматизацию, поэтому я раскукоживаю sqlmap, который уже запылился от бездействия.

И волки целы и овцы сыты, или наоборот. Отправил на security@telegram.org, чуть позже получил заветное письмо о награде в $30,000.
Шучу, $2000 за sqli, и $500 за phpinfo и server-status, что тоже неплохо.

По идее, можно было бы качать краши и самому изучать и эксплуатировать их. Пользователей я не взломал (твоя переписка в безопасности), развить атаку дальше не мог, сервер с дампами рандомных пользователей — сомнительная ценность. Узнав как роняется телеграм, можно было ронять его у жертвы, а дальше изучать его дамп, его ось, последние сообщения, чаты и все что можно выжать из логов падения. Например, для деанонимизации. И то, если эта информация вообще там присутствует.

Неповторимый оригинал.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть