Кратко

  • FTP образца 1985 года разделял управляющий разговор и передачу данных: клиент мог связать два сервера напрямую, указав запасной адрес для данных командой PORT.
  • RFC 2577 в 1999 году показал, как та же команда позволяла отправить FTP-сервер к посторонней сетевой службе.

Если товар лежит на складе А и нужен складу Б, зачем везти его через дом заказчика? Особенно когда дорога к его дому медленная и узкая. FTP предусмотрел передачу прямо между серверами: заказчик отдавал распоряжения, машины перевозили файл. Удобная схема оставила одну неприятную мелочь. Адрес на путевом листе писал заказчик, а выезжала машина, принадлежащая серверу.

Стандарт FTP RFC 959, опубликованный в октябре 1985 года, различал управляющее соединение и соединение для данных. Клиент мог открыть управляющие сеансы с двумя FTP-серверами. Один ждал передачи, другой соединялся с ним и отправлял файл. Команда PORT позволяла указать альтернативный адрес и порт для данных. В документе упомянуты сторонний хост и удалённый принтер. Убрать медленный клиентский компьютер с пути самого файла было серьёзной практической выгодой.

Кому достался выбор следующей остановки? Клиенту. Кто устанавливал сетевое соединение? Серверу. В нормальной передаче между двумя FTP-серверами адрес указывал на второго участника. Без проверки сервер мог получить адрес и порт иной службы, которая вообще не ждала файл. Для неё соединение приходило от FTP-сервера. Человек, выбравший дверь, оставался на другой стороне управляющего канала.

Документ Стива Белловина RFC 1579 от февраля 1994 года разобрал родственную проблему с межсетевыми экранами. При активном FTP сервер сам соединялся с портом клиента. Фильтру пакетов трудно пропускать неожиданные входящие вызовы. Белловин рекомендовал клиентским программам PASV: сервер ждёт, клиент начинает исходящее соединение для данных. Он предложил также идею APSV, но сообщил, что не знает её реализации на тот момент. Направление звонка стало вопросом для оператора границы сети, а не просто стрелкой на схеме.

В сентябре 1998 года RFC 2428 добавил EPRT и EPSV для IPv6 и преобразователей адресов. EPRT передавал семейство адресов, сетевой адрес и порт TCP. Команда EPSV ALL закрепляла для текущего сеанса передачу между двумя сторонами; если позже требовалась трёхсторонняя, открывали новый сеанс. Бланк адреса стал вместительнее, а выбор числа участников — явнее. Проверка права отправить сервер по указанному адресу от этого не возникла сама собой.

В мае 1999 года RFC 2577 описал атаку с отскоком, FTP bounce. Клиент записывает в PORT адрес и порт службы на третьей машине, затем велит FTP-серверу послать туда данные. Если служба воспринимает эти данные как команды, сервер выполняет роль невольного посыльного. В примере документа клиент сначала кладёт на FTP-сервер файл с командами SMTP, а потом отправляет его почтовой службе третьей машины. К ней подключается FTP-сервер, а не создатель файла. Чужой сетевой адрес становится прикрытием для чужого распоряжения.

Ответ RFC 2577 был предметным. Авторы предложили не открывать соединения для данных к портам TCP ниже 1024 и отвечать 504 на соответствующий PORT. Службы на более высоких портах оставались доступны. Правильные права доступа к файлам могли пресечь загрузку командного файла и его последующую отправку. Полное отключение PORT убирало путь для атаки вместе с прямой передачей между серверами. Большинство обычных передач, по мнению авторов, обходилось PASV. Выбирать цену этой свободы должен был тот, кто содержал сервер.

В документах нет таинственной смены характера FTP. Сначала отделение данных от команд дало удобный кратчайший путь. Затем межсетевые экраны и новые адресные форматы сделали свойства этого пути более заметными. К 1999 году вопрос свёлся к одной графе накладной: клиент вправе предложить адрес, но право вести туда чужую машину принадлежит её владельцу.