Некоторые проблемы 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 порт, который сервер будет слушать в следующем сеансе передачи данных и постоянно обстреливать его попытками соединений. Если сервер попытается послать данные клиенту, данные будут посланы атакующему. И наоборот, если атакующий может послать данные на сервер, подменяя данные, которые собирался передать клиент.

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

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

Так же уязвим практически любой FTPD-based FTP сервер (wu-ftpd, например, практически любой версии или стандартный FTPD). При этом ftp клиент в Midnight Commander, например, такой проблемы не имеет.

Рецепт для борьбы следующий:

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

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

Как использовать?

ftpspy ip_адрес_сервера

Какие требования?

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

Дата добавления: 2014-01-07