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

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. Ввиду полной бредовости данной идеи, приводить эти выкладки не буду **) "Как использовать погрешности в реализации FTP протокола".

Дэвид Сэйсердот в своей статье посвященной уязвимости FTP протокола и датированной аж апрелем 1996 года теоретически уязвимость FTP протокола при его некорректной реализации. В статье интересны два момента, причем не связанные напрямую с ее содержанием а именно:

1. С апреля 1996 года проблема нисколько не утратила своей актуальности. Проблема очень серьезная, поскольку позволяет, например, атаковать клиента находящегося за прокси-сервером (подсунув измененные данные прокси серверу вы тем самым подсунете их клиенту).

2. Дэвид ошибался как в оценке уязвимости FTP-клиентов, так и в сложности реализации данной уязвимости, т.к. указанные им методы чересчур сложны для реального использования.

Лечиться эта проблема так же должна другими методами: сервер не должен принимать более одного соединения на порт данных (так делает IIS, поэтому против него такая атака работает лишь как DoS, не позволяя подсоединиться клиентам). Клиент в активном режиме должен проверять IP адрес соединения и так же не позволять двух соединений на один порт. Кроме того, при получении сообщения об ошибке или при неожиданном закрытии контрольного сеанса, сторона, принимающая данные, должна эти данные игнорировать (т.е. удалять принятый файл). Кроме того, желательно наличие в протоколе команды вычисляющей контрольную сумму файла (хотя этим можно воспользоваться как DoS атакой - требуются большие ресурсы сервера).

К счастью, я не читал статью Дэвида (кстати, спасибо aleph1@securityfocus.com за посылку на эту статью) иначе никогда не взялся бы за эту проблему. А потому обнаружил, что стандартный ftp из FreeBSD 2.2.5 (и наверняка любой другой BSD4.2 клиент) уязвим, несмотря на заверения Дэвида в обратном. Так же уязвим практически любой FTPD-based FTP сервер (wu-ftpd, например, практически любой версии или стандартный FTPD) . При этом ftp клиент в Midnight Commander, например, такой проблемы не имеет.

А потому, столкнувшись с этой проблеммой на собственной шкуре, я написал эксплоит, который использует точь-в-точь алгоритм предложенный Дэвидом больше трех лет назад. Может быть я и изобрел велосипед, но, похоже, на этом велосипеде за три года кататься разучились. По крайней мере, посещаемость FTP серверов не упала а защищенность не увеличилась. Итак, рецепт:

Мы угадываем, какой порт будет открыт пассивным Ftp-сервером или активным клиентом и атакуем этот порт постоянными запросами на TCP соединение. Если соединение удалось установить, мы либо посылаем туба свои собственные данные либо читаем данные оттуда. Либо - и то и другое. Вопрос лишь в том, как угадать порт, а сделать это не сложно, если вы можете использовать атакуемую машину или как FTP сервер, или как прокси или как сервер для отправки почты. В случае атаки на FTP сервер - мы не имеем никаких проблем. Как работает эксплоит?

Открывает соединение на 21й (ftp) порт сервера и через равные интервалы времени дает команду PASV, на которую сервер любезно отвечает номером открытого порта. Вот именно его мы и используем за основу для вычисления атакуемого порта. Соединение устанавливается, программа переходит в режим ожидания данных. Если в течении 5 секунд данные не поступили, то программа сама посылает данные. Работает как против сервера, так и против клиента (при условии, что на машине клиента так же живет FTP-Сервер). Можно атаковать клиента и используя данные о порте полученные другим образом, например, если на компьютере клиента стоит sendmail можно отправлять через него письма на свою машину и определять номер порта, с которого пришло соединения на 25й порт. Если на компьютере клиента есть прокси сервер, то можно запросить любую URL со своего компьютера и так же определить порт входящего соединения. Как использовать?

ftpspy ip_адрес_сервера Какие требования?

Канал связи между вами и сервером не должен быть сильно хуже, чем канал между сервером и клиентом. Кроме того, не всегда проходит против локальной машины с удаленным клиентом (ну да это и не интересно). Программа создает обширный трафик, причем мелкими пакетами, и получает обратно на каждый пакет Port Unreachable. При этом программа находится в вечном цикле. Два этих факта вместе могут привести в недоумение локальную систему. При работе программы у меня несколько раз закрывалась telnet-сессия..... надо бы исследовать этот вопрос....