Истории с ошибками, которые 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 атаку:

  1. Клиент пытается соединиться с сервером,
    однако (путем DNS спуфинга или отравления
    arp кеша или любым другим методом)
    соединяется с нашим "человеком" ака
    сервером, который отсылает запрос
    настоящем серверу терминалов.
  2. Сервер отсылает свой публичный ключ
    клиенту и случайную соль открытым
    текстом, опять же через наш сервер. В
    процессе пересылки мы заменяем публичный
    ключ своим, от которого мы знаем
    приватный ключ.
  3. Клиент через MITM отсылает случайную соль
    зашифрованную открытым ключом сервера.
  4. Хакер на промежуточном сервере
    расшифровывает соль своим приватным
    ключом, шифруем его обратно ключом
    сервера и отсылаем ему.
  5. Теперь мы знаем соль и сервера и ключа,
    что достаточно нам для сооружения ключей
    сессии для дальнейшей пересылки пакетов
    между клиентом и сервером и вся
    информация открыта перед 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 протокола перехватывая и
расшифровывая всю информацию, которая
передается между клиентом и сервером.

Посмотри еще:

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

  • Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии