Истории с ошибками, которые Microsoft правит,
правит да все никак не исправит далеко не
единичны. Взять ту же LAND атаку, которую не
могут исправить уже долгие годы. Сегодня же
мы расскажем об уязвимости в RDP службе,
пусть не столь опасной, но тоже довольно
интересной.
Microsoft Windows Terminal Services (встроен в сервера 2К и
2К3) и Windows XP Remote Desktop предоставляют
пользователям довольно удобный сервис для
управления удаленным рабочим столом. RDP
протокол уязвим к MITM атаке. Впервые эту
уязвимость обнаружили в 2003 году, однако до
сих пор уязвимость живет и здравствует. По
умолчанию данные между сервером терминалов
и его клиентом шифруются. Протокол RDP
использует симметричный алгоритм
шифрования RC4, который может использоваться
в трех вариантах:
- Высокий уровень безопасности:
используется 128 битный ключ. - Средний: 56-битный ключ в клиентах Windows 2000
и выше или 40-битный в предыдущих версиях
ОС. - Малый уровень: в отличии от предыдущих
вариантов шифруются только данные,
передающиеся от клиента к серверу,
используется 56- или 40-битные ключи.
В Апреле 2003 года Эрик Фосберг выпустил бюллетень,
в котором описывал возможность реализации
MITM атаки в RDP протоколе. Выглядит это так:
"... В процессе исследования протокола
мы обнаружили, что несмотря на то, что
данные по сети передаются в зашифрованном
виде, отсутствует идентификация сервера
при обмене ключами в процессе установления
соединения. Это и значит, что в RDP
теоретически можно Man In The Middle атаку:
- Клиент пытается соединиться с сервером,
однако (путем DNS спуфинга или отравления
arp кеша или любым другим методом)
соединяется с нашим "человеком" ака
сервером, который отсылает запрос
настоящем серверу терминалов. - Сервер отсылает свой публичный ключ
клиенту и случайную соль открытым
текстом, опять же через наш сервер. В
процессе пересылки мы заменяем публичный
ключ своим, от которого мы знаем
приватный ключ. - Клиент через MITM отсылает случайную соль
зашифрованную открытым ключом сервера. - Хакер на промежуточном сервере
расшифровывает соль своим приватным
ключом, шифруем его обратно ключом
сервера и отсылаем ему. - Теперь мы знаем соль и сервера и ключа,
что достаточно нам для сооружения ключей
сессии для дальнейшей пересылки пакетов
между клиентом и сервером и вся
информация открыта перед MITM.
Такая ситуация возникла из-за того, что
клиент не верифицировал публичный ключ
сервера, посланный в шаге 2. В других
протоколах, таких как например Secure Shell,
реализована защита от такого рода ситуаций,
например подтверждением контрольной суммы
ключа..."
Microsoft доложилась о наличии проблемы и
пофиксила ошибку в новых версиях клиентов.
Последние версии клиентов, например в XP SP2,
теперь проверяют публичный ключ сервера.
Казалось бы проблема решена? Как и во многих
других случаях с Microsoft ответ не столь
очевиден :)... Как вы уже догадались проблема
MITM атаки по прежнему существует и угрожает
пользователям.
В процессе начального обмена ключами
сервер терминалов посылает клиенту
сертификат, созданный при создании сервиса.
Этот сертификат хранится в реестре сервера
в таком ключе:
HKEY_LOCAL_MACHINE\SYSTEM\ CurrentControlSet\Services\
TermService\Parameters\Certificate\
Модуль публичного ключа (обозначим его n)
совпадает с представленным с RSA2 ключом,
сохраненным в LSA Secret "L$HYDRAENCKEY" на
сервере: именно эта информация
используется клиентом для
подтверждения достоверности сервера. С
точки зрения атакующего, подпись
публичного ключа должна быть изменена на
лету для того, что бы обмануть клиента и тот
подтвердил достоверность ключа. Но что
используется для составления подписи?
Цифровая подпись это не что иное как хеш
публичного ключа зашифрованный приватным
ключом при помощи асимметричного алгоритма.
Именно это и делается терминальным
сервером и отсылается клиенту. На стороне
клиента подпись расшифровывается с помощью
публичного ключа и результат сравнивается
с новым хешем ключа, подсчитанным на
стороне клиента. Если значения совпадают -
сервер считается благонадежным.
Microsoft использует другой RSA ключ для
подписи ключей терминального сервера и
этот приватный ключ открыт всем! Звучит
странно, но на самом деле для работы с ним
используется стандартная mstlsapi.dll, в
частности процедуры TLSInit. Каждый
пользователь Windows имеет этот файл и
возможность им пользоваться... получаем
новую разновидность public-private key (PPK)???
The Microsoft Windows Terminal Server PPK follows:
public exponent: e
0x5B,0x7B,0x88,0xC0
public modulus: n
0x3D,0x3A,0x5E,0xBD,0x72,0x43,0x3E,0xC9,0x4D,
0xBB,0xC1,0x1E,0x4A,0xBA,0x5F,0xCB,0x3E,0x88,
0x20,0x87,0xEF,0xF5,0xC1,0xE2,0xD7,0xB7,0x6B,
0x9A,0xF2,0x52,0x45,0x95,0xCE,0x63,0x65,0x6B,0x58,
0x3A,0xFE,0xEF,0x7C,0xE7,0xBF,0xFE,0x3D,0xF6,0x5C,
0x7D,0x6C,0x5E,0x06,0x09,0x1A,0xF5,0x61,0xBB,0x20,
0x93,0x09,0x5F,0x05,0x6D,0xEA,0x87,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00
private exponent: d
0x87,0xA7,0x19,0x32,0xDA,0x11,0x87,0x55,0x58,0x00,
0x16,0x16,0x25,0x65,0x68,0xF8,0x24,0x3E,0xE6,0xFA,
0xE9,0x67,0x49,0x94,0xCF,0x92,0xCC,0x33,0x99,0xE8,
0x08,0x60,0x17,0x9A,0x12,0x9F,0x24,0xDD,0xB1,0x24,
0x99,0xC7,0x3A,0xB8,0x0A,0x7B,0x0D,0xDD,0x35,0x07,
0x79,0x17,0x0B,0x51,0x9B,0xB3,0xC7,0x10,0x01,0x13,
0xE7,0x3F,0xF3,0x5F,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
0x00,0x00,0x00,0x00
secret prime factor: p
0x3F,0xBD,0x29,0x20,0x57,0xD2,0x3B,0xF1,0x07,0xFA,0xDF,
0xC1,0x16,0x31,0xE4,0x95,0xEA,0xC1,0x2A,0x46,0x2B,0xAD,
0x88,0x57,0x55,0xF0,0x57,0x58,0xC6,0x6F,0x95,0xEB,0x00,
0x00,0x00,0x00
secret prime factor: q
0x83,0xDD,0x9D,0xD0,0x03,0xB1,0x5A,0x9B,0x9E,0xB4,0x63,
0x02,0x43,0x3E,0xDF,0xB0,0x52,0x83,0x5F,0x6A,0x03,0xE7,
0xD6,0x78,0x45,0x83,0x6A,0x5B,0xC4,0xCB,0xB1,0x93,0x00,
0x00,0x00,0x00
d mod (p-1): dmp1
0x65,0x9D,0x43,0xE8,0x48,0x17,0xCD,0x29,0x7E,0xB9,0x26,
0x5C,0x79,0x66,0x58,0x61,0x72,0x86,0x6A,0xA3,0x63,0xAD,
0x63,0xB8,0xE1,0x80,0x4C,0x0F,0x36,0x7D,0xD9,0xA6,0x00,
0x00,0x00,0x00
d mod (q-1): dmq1
0x75,0x3F,0xEF,0x5A,0x01,0x5F,0xF6,0x0E,0xD7,0xCD,0x59,
0x1C,0xC6,0xEC,0xDE,0xF3,0x5A,0x03,0x09,0xFF,0xF5,0x23,
0xCC,0x90,0x27,0x1D,0xAA,0x29,0x60,0xDE,0x05,0x6E,0x00,
0x00,0x00,0x00
q^-1 mod p: iqmp
0xC0,0x17,0x0E,0x57,0xF8,0x9E,0xD9,0x5C,0xF5,0xB9,0x3A,
0xFC,0x0E,0xE2,0x33,0x27,0x59,0x1D,0xD0,0x97,0x4A,0xB1,
0xB1,0x1F,0xC3,0x37,0xD1,0xD6,0xE6,0x9B,0x35,0xAB,0x00,
0x00,0x00,0x00
Знание РРК ключа позволяет атакующему
посчитать правильную подпись для MITM ключа,
сгенерированно в ходе атаки, клиент
подтвердит MITM подпись и примет сессию без
оповещения пользователя о том, что ключ
сервера изменился.
По умолчанию, в административном режиме
работы сервера терминалов, только
пользователи с административными правами
могут работать с удаленным рабочим столом.
Атакующий таким образом может получить
полные права и полностью скомпрометировать
сервер. Учтите, что атака полностью
невидима для пользователя и в результате мы
получаем одно из лучших нападений.
Описанная атака реализована в известной
программе Cain & Abel (http://www.oxid.it).
С версии 2.7 программа может проводить MITM
атаки против RDP протокола перехватывая и
расшифровывая всю информацию, которая
передается между клиентом и сервером.
Посмотри еще:
- rdesktop - A Remote Desktop Protocol Client: http://www.rdesktop.org
- rdpproxy - RDP mitm прокси: http://cvs.sourceforge.net/viewcvs.py/rdesktop/rdpproxy/
- Cain & Abel v2.7: http://www.oxid.it
