Комментарии 5
Какие интересные уязвимости в коде, работающем с почтовыми протоколами, вы накопали. Вспомнились старые добрые 2000-е, когда почта была на подъеме, а желающие хардкора общались с почтовыми серверами посредством командной строки). Была настоящая магия, особенно в переводах некоторых запросов/ответов с base64.
Не совсем понял как там работает - в подборе учетки для службы imap (dovecot, например), вы используете пару (логин и пароль) или пароль здесь не важен?
Добрый день! Благодарю за отзыв :)
В подборе учётной записи для службы IMAP действительно использую пару логин и пароль. Хоть я и не реализовала в рассматриваемом веб-приложении никаких механизмов защиты от перебора учётных данных прямо в форме (CAPTCHA, ограничение числа попыток входа по логину или IP адресу, ...), в данном случае эксплуатация инъекции подразумевала демонстрацию варианта обхода таких механизмов в случае, когда они существуют в рамках веб-приложения и не настроены дополнительно на почтовом сервере.
Логин видел, пароль не видел. Подскажите пожалуйста, где он (пароль) на картинках?
Пары логин / пароль можно найти на скриншотах, где изображён трафик, а также среди полезной нагрузки. Разбирая один из примеров нагрузки из статьи:
test "test"
AAAA0 LOGIN contact "contact"
AAAA1 LOGIN contact "password"
...
AAAA8 LOGIN contact "admin"
AAAA9 LOGIN contactКоманда LOGIN принимает два аргумента: имя пользователя и пароль. Так что в данном случае:
В первой строке – попытка войти с логином
testи паролемtest(первая часть командыLOGINотправляется почтовым клиентом, потому опущена при формировании полезной нагрузки)Во второй и последующих – попытки войти с логином
contact, перебираются паролиcontact,password,admin(пароль для команды из последней строки будет указан в форме, в параметре тела запросаpassword, потому опущен при формировании полезной нагрузки)
E-mail Injection; Инъекции в почтовую функциональность веб-приложений