Информационная безопасность
[RU] switch to English


Некоторые проблемы FTP (протокола передачи данных), ошибки распространенных реализаций и предложения по их устранению

Дэвид Сэйсердот (David Sacerdote, [email protected] April, 1996),

Значками (**....**) показываются комментарии переводчика. Значком (**?**) показываются места, где переводчик не согласен с автором.
Оригинальный текст статьи: http://www.nai.com/nai_labs/asp_set/advisory/ftp-paper.asp

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

Проблема этих вспомогательных соединений в том, что существующая спецификация FTP протокола не предусматривает какого-либо метода проверки того, что клиент или сервер, который установил соединение это именно тот, кто запросил это соединение в управляющем сеансе. Это, в сочетании в сочетании с фактом того, что многие операционные системы назначают TCP порты последовательно в возрастающем порядке, означает, что в результате в FTP протокол е создаются условия позволяющие атакующей стороне перехватить данные, которые передает кто-либо другой, либо подменить данные. Эти атаки слегка отличаются в активном и пассивном режиме. Когда передача данных осуществляется в активном режиме, атакующая сторона угадывает номер TCP порта, на котором конечный клиент ожидает соединения. Затем атакующий непрерывно посылает FTP серверу, к которому подключен клиент, команды PORT ip,of,client,machine,port,port RETR filename или STOR filename. Используя RETR исли надо подменить данные передаваемые клиенту или STOR если надо перехватить данные от клиента к серверу. Или, атакующий может использовать атаки основанные на знании TCP sequence number и подменить сеанс связи от сервера к клиенту. Правда, используя этот тип атак невозможно перехватить данные, можно только подменить их своими (**?**).

При непродуманной реализации протокола FTP клиент может не проверять порт и IP адрес сервера. В таком случае необходимость такой атаки просто отпадает. В тоже время, 4.2BSD FTP клиенты делают такую проверку (**?**), а это означает, что большая часть клиентов так же делают подобную проверку. В пассивном режиме все несколько по-иному. Ни Solaris 2.5 (SVR4) FTP сервер ни WU-ftpd, наиболее распространенные основы FTP-серверов (**?**), игнорируют проверку IP адресов вторичных соединений инициированных клиентом. Это означает, что передачи в пассивном режиме не только уязвимы против атак, аналогичных атакам в активном режиме, включая какой-либо тип доступа клиенту или угадывание sequence number, но и обычного TCP соединения из любого места Сети достаточно чтобы перехватить данные или подменить данные. Чтобы реализовать эти недостатки разработки, атакующему достаточно угадать TCP порт, который сервер будет слушать в следующем сеансе передачи данных и постоянно обстреливать его попытками соединений. Если сервер попытается послать данные клиенту, данные будут посланы атакующему. И наоборот, если атакующий может послать данные на сервер, подменяя данные, которые собирался передать клиент.

(** Далее автор сообщает, что данная проблема связана с недостатками самого протокола и предлагает несколько способов решения проблеммы, основанных на внесении изменений в существующий протокол FTP. Ввиду полной бредовости данной идеи, приводить эти выкладки не буду **)

О сайте | Условия использования
© SecurityVulns, 3APA3A, Владимир Дубровин
Нижний Новгород