Статья носит сугубо информационно-образовательный характер.
Пробегая по старым папкам, наткнулся на сохраненные скриншоты, которые делал для представителей пары небезызвестных компаний на нашем финансово-IT рынке.
Все началось с того, что я решил сменить профиль работы и попробовать себя в QA или смежной профессии, только уже не самоучкой-одиночкой, а заняться этим в штате какой-нибудь крупной организации, чтобы было у кого перенять опыт, поработать в команде…
После размещения резюме, со мной пересекались Сбербанк-Технологии, Банк Открытие о которых и пойдет небольшое повествование.
После приглашения пообщаться, я решил посмотреть, что же живет на доменах компаний, на предмет интересных уязвимостей. Всегда приятно иметь козырь в рукаве на переговорах.
Сбербанк
Сбербанк в первую очередь ассоциируется с Россией, но у него есть филиалы и в других странах. Поэтому, я решил пойти по «простому» пути. Практически через пару попыток было найдено две пассивные XSS уязвимости в веб-интерфейсе Белорусского Сбербанка.
Первая детская ошибка – не проверять входящие данные со стороны пользователя. Как результат – межсайтовый скриптинг в поле поиска и формы входа в Сбербанк Онлайн.
Отдельный момент по форме входа Сбербанк Онлайн – хоть форма и передавала значения через POST, но скрипты на веб-сервере успешно обрабатывали и мой GET запрос.
Так же решил глянуть домен, с которого мне написала HR Сбербанка. Им оказался портал «Сбербанк Таланты».
Помучив разные формы и скрытые поля, ничего путного не получил, кроме того, что портал крутится на ASP.NET.
Просмотрев в очередной раз исходник главной HTML страницы, обратил внимание на то, что все JS и CSS файлы отдаются через скрипт, который объединяет и сжимает файлы, указанные в GET запросе.
Вторая детская ошибка – не ограничивать белым списком перечень файлов/каталогов, которые можно выгружать с сервера.
В итоге я получил доступ к файлу конфигурации веб-сервера. А также, более интересному файлу с логами, где были указаны как пароли от SQL и других сервисов, так и актуальные токены API для публикации в социальных сетях.
Открытие
Здесь я так же решил не тратить время на основной портал, а сразу просмотреть на какие свои веб ресурсы ссылается банк. Подопытным, по случайной аналогии со Сбербанком, стал «Карьерный портал банка «Открытие»».
Оказалось, что портал работает на CMS Bitrix. Как правило, крупные коммерческие движки или движки с открытым исходным кодом не содержат детских ошибок, но…
Окей гугл, как получить доступ в админку Битрикса?
Третья детская ошибка – не закрывать листинг директорий на сервере.
В принципе все и так понятно – Apache был настроен так, что директории без index файлов показывали свое содержимое. Это не сильно критичная проблема, если бы не роковое стечение обстоятельств. На карьерном портале можно загрузить свои контактные данные и файл своего резюме. Пару минут и я уже смотрю на листинг директории с данными соискателей.
Это все интересно, но не админка. Поэтому листаем все папки в надежде что-то найти.
Не детская ошибка – человеческий фактор. Я не знаю «как» и главное «зачем», но в одном из каталогов с PDF/RTF/DOC файлами лежал файл без расширения, который представлял собой PHP скрипт.
Благодаря этому файлу был получен новый вектор поиска – папка /estaff/, где лежали логи добавления/удаления вакансий с логин/пароль парой, скрипты модуля, а так же в одном из файлов засветились реквизиты, которые подходили к админ-панели Битрикса.
Теперь, Шарик, ты еще полдня за ним будешь бегать — фотографии отдавать...
К сожалению, для меня эта история закончилась без счастливого финала. Во-первых, пришлось долго искать реального представителя банка, связанного с IT. Первая линия поддержки банков (как и сами HR) в принципе не понимали проблемы, что ожидаемо, но и передать эти данные выше коллегам из нужных отделов не могли.
Решением стал LinkedIn и рассылка личных сообщений по руководителям различных отделов, хоть как-то связанных с IT инфраструктурой.
Во-вторых, у обоих банков отсутствует программа Bug Bounty, как следствие, все ограничилось лаконичным «Спасибо».
А в-третьих, HR обоих банков не стали рассматривать мое резюме, сославшись на отсутствие опыта.
Комментарии (18)
Drag13
31.05.2019 09:52+2А в-третьих, HR обоих банков не стали рассматривать мое резюме сославшись на отсутствие опыта.
Вот это пять! Но не переживайте, ценители таких людей "без опыта" вас найдут быстро, без хорошей работы не останетесь.
pansa
31.05.2019 13:37Учитвая отношение сбербанка к подобного рода информации, найдут-то может и быстро и даже, как следствие, работать потом придется долго. Только вот насчет места работы и её оплаты я сильно не уверен. :\
Drag13
31.05.2019 14:41Я бы мог ответить в стиле — нет вмешательства -> нет ущерба -> нет проблем. Но это не правда. Именно поэтому я и не эксперементирую на подобных сайтах. Ну их.
Valya-roller
31.05.2019 09:53+2Мда… надеюсь с выходом этой публикации квалификацию/зарплату конкретных HR-ов пересмотрят.
Zenitchik
31.05.2019 12:48Почему «даже»? Я давно подметил корреляцию, что чем крупнее и известнее компания — тем паршивее у неё сайт. Исключение — IT-компании.
andreymal
31.05.2019 13:46Вторая детская ошибка – не ограничивать белым списком перечень файлов/каталогов, которые можно выгружать с сервера.
Настоящая ошибка — держать в public_html конфиги, которые не должны быть доступны через сайт вообще никогда и никому. Тебе не придётся прятать секретные файлы в папке с сайтом, если там нет секретных файлов
qw1
31.05.2019 15:44На первом скриншоте web.config был замазан PublicKeyToken из configSections.
В этом нет ничего секретного, так .NET framework решает проблему выбора DLL (заодно защита от вредоносных DLL с тем же именем). Директива указывает: загрузи не любую версию Microsoft.Practices.EnterpriseLibrary.Logging.dll, а конкретную, зареганную в GAC с указанным хешем. Все эти хеши публично известны, раскрывают они разве что конкретную версию подключенной библиотеки.
HellWalk
31.05.2019 19:46+6Ага, а когда оказываешься в подобной компании, и начинаешь мягко и не мягко поднимать вопросы на тему «Как вы могли такого наворотить?», «Какие нафиг бизнес задачи, тут над качеством надо работать» — тебя называют «токсичным», «мешающим работать» и увольняют.
P.S. Опережая фразу «Надо не сообщать об ошибке, а предлагать решение» — решение требует времени, а чтобы это время выбить (у нас же есть бизнес задачи горят!) надо объяснить, что в проекте куча проблем.pyrk2142
01.06.2019 18:50тебя называют «токсичным», «мешающим работать» и увольняют.
Круговая порука в действии: если не изгнать такого «токсика» и «неадеквата», который бросает тень на процессы разработки, из компании, то может всплыть, что вместо программистов наняли кодеров (а некоторые даже не умеют умножить 10*10*10*10, чтобы получить 10000, а не «дофига, этого хватит для всего, четырехзначные коды надежные, я сказал!!!»), безопасников нет, а есть автотестеры, которые купили дополнительное ПО и читают OWASP, а деньги на зарплаты профессионалам уходят непонятным людям, которые почему-то получают х10 окладов от их навыков. Лучше изгнать «токсика», продолжить есть вкусности на корпоративных обедах и полдниках, а пользователи все сожрут, они же не умеют возмущаться из-за взломов.
Loggus66
01.06.2019 20:06Bitrix на Ubuntu — оригинально. На семействе Debian действительно нужно всё самостоятельно настраивать, в отличие от установки через bitrix-env.sh. Вот и идея для вектора атаки: выбрать через shodan веб-серверы, из них — bitrix, из них — те, что не на CentOS (nmap скан или баннер версии OpenSSH подскажут). То, что останется, может быть более дырявым, чем то, что разворачивалось оф. скриптом.
whiteline
01.06.2019 20:06xsash, HR Вас не оценили и не стали рассматривать резюме. Возможно, Вам и не нужно работать в столь замечательных компаниях, где придеться продираться со своим «видением» проблем и натыкаться на сопротивление старших по команде и непониманием проблем с их стороны. Надеюсь, что у Вас в итоге с работой все сложилось хорошо.
legolegs
01.06.2019 23:11Даже web ресурсы известных организаций не защищены от детских ошибок
Кхм. А что, этот факт для кого-то новость?
Напомню, что гугл недавно попался на том, что его разработчики считали «секретный» кодик в GET-запросе достаточной защитой для данных пользователей в гуглодоках. А, например, я уже в середине нулевых, когда делал себе сайтик на народе, слышал от старших товарищей, что «секретные URL» ни от чего не защищают.
Shtucer
Даже веб ресурсы?