Побег через брандмаузер


Рисунок 1 map.gif распределение интенсивности атак на различные порты по регионам - часть 2


Существует несколько путей захвата ранее установленного TCP/IP-соединения (если кто раньше читал мои статьи, датированные годом эдак 1998, то там я называл это "передачей данных в потоке уже существующего TCP/IP соединения", но этот термин не прижился). Первое и самое глупое – обратиться к переменной дескриптора сокета по фиксированным адресам, специфичным для данного сервера, которые атакующий может получить путем его дизассемблирования. Но такой способ не выдерживает никакой критики, здесь он не рассматривается (тем не менее, знать о его существовании будет все-таки полезно).

Уж лучше прибегнуть к грубой силе, перебирая все возможные дескрипторы сокетов один за другим и тем или иным образом определяя какой из них заведует "нашим" TCP/IP-соединением. Поскольку, в операционных системах семейства UNIX и Windows 9x/NT, дескрипторы сокетов представляют собой вполне упорядоченные и небольшие по величине целочисленные значения (обычно заключенные в интервале от 0 до 255), их перебор займет совсем немного времени. Как вариант, можно воспользоваться возможностью повторного использования адресов, сделав re-bind на открытый уязвимым сервером порт. Тогда, все последующие подключения к атакованному узлу, будут обрабатываться отнюдь не прежним владельцем порта, а непосредственно самим shell-кодом (неплохое средство перехвата секретного трафика, а?). Наконец, shell-код может просто "прибить" уязвимый процесс, и открыть публичный порт заново.

Как вариант – червь может умертвить атакуемый процесс, автоматически освобождая все отрытые им порты и дескрипторы. Тогда повторное открытие уязвимого порта не вызовет никаких протестов со стороны операционных системы. Менее агрессивный червь не будет ничего захватывать, никого убивать и вообще что либо трогать. Он просто переведет систему в неразборчивый режим, прослушивая весь проходящий трафик с которым атакующий должен передать оставшийся хвост.

И на закуску: если ICMP-протокол хотя бы частично разрешен (чтобы пользователи внешней сети не доставали администратора глупыми вопросами почему умирает ping), то shell-код может запросто обернуть свой хвост ICMP-пакетами! В самом крайнем случае, червь может послать свое тело и в обычном электронном письме (конечно, при условии, что он сможет зарегистрировать на почтовом сервере новый ящик или похитить пароли одного или нескольких пользователей, что при наличии snffer'а не является проблемой).

Таким образом, никакой, даже самый совершенный и правильно сконфигурированный брандмаузер, не защитит вашу сеть (и уж тем более – домашний компьютер) ни от червей, ни от опытных хакеров. Это, разумеется, не обозначает, что брандмаузер совершенно бесполезен, но убедительно доказывает тот факт, что приобретение брандмауэра еще не отменяет необходимость регулярной установки свежих заплаток.




- Начало -  - Назад -  - Вперед -