Новый вид DDoS-атаки: найден баг протокола ТСР в Windows

    Уважаемые хабро-читатели, прежде чем перейти к сути хочу сразу сказать, что автор не является каким бы то ни было хакером или зловредным программером, исследующим со свечкой каждый темный угол драйвера или чего-либо другого программного, поэтому если об этой уязвимости уже известно, то не судите строго, а лучше посоветуйте патч.

    Итак, в процессе отладки стека протоколов для сетей MANET, где тестировалось модифицированное ТСР-соединение радиосети с компьютером через Ethernet-шлюз, было случайно выявлено, что путем некорректного закрытия соединения клиентом на стороне сервера возможно удерживание ресурсов сокета бесконечно долго!

    Началось всё с этого:


    На скрин-шоте представлено ТСР-соединение между клиентом 192.168.0.108 (Ethernet шлюз) и сервером 192.168.0.187 (OS Windows Vista).

    Как видно, при неправильном указании номера последовательности в пакете FIN ACK клиента, Windows сервер не закрыл сокет и не освободил ресурсы. Попытка соединиться еще раз с того же порта клиента (source port 40400) на порт сервера (destination port 31000) оказалась неуспешной. Сервер упорно требовал ACK в ответ на новый SYN от клиента.

    Сначала, я решил что это просто какой-то баг на стороне стека MANET (помимо, конечно же, неправильного seqno в FIN ACK), но проанализировав поток по номерам sequence / acknowledgement и повторив этот же эксперимент для других портов оказалось, что таки да, Windows…

    Пример другого порта сервера (30000):



    Потом, перегрузив комп и повторили все еще раз. На этот раз соединение закрывал клиент, а сервер слушал порт 32000.



    Результат тот же.

    Потом посмотрели командой netstat состояние сокетов и ужаснулись…


    Сервер держит открытым сокеты, которых нет в природе уже много часов!!!
    И скорее всего, только принудительное убийство процессов или перезагрузка, спасет положение, т.к. очевидно в состоянии FIN_WAIT_2 у Windows нет таймера для сокета и он не переходит в состояние TIME_WAIT для очистки ресурсов.

    Резюме

    1. Убедительная просьба сообщить об известности этой уязвимости.
    Если это вновь открытый баг, то это ставит под угрозу многие сетевые продукты на OS Windows.

    2. Было бы интересно исследовать данную проблему на других серверах и ОС, в первую очередь Linux.

    3. Изучайте сетевые протоколы!

    P.S.
    прошли сутки со дня открытия проблемы — ресурсы выделены до сих пор…
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама
    Комментарии 36
    • +5
      Возможно это www.auburn.edu/docs/apache/misc/fin_wait_2.html?
      The FIN_WAIT_2 state is somewhat unusual in that there is no timeout defined in the standard for it. This means that on many operating systems, a connection in the FIN_WAIT_2 state will stay around until the system is rebooted. If the system does not have a timeout and too many FIN_WAIT_2 connections build up, it can fill up the space allocated for storing information about the connections and crash the kernel. The connections in FIN_WAIT_2 do not tie up an httpd process.


      И посмотрите тут social.msdn.microsoft.com/forums/en-US/d20e5e67-d23c-42a5-95c5-ba80f4263546/keepalive-packets-continue-being-sent-after-client-closes-server-socket-is-closewait-client, не то?
      • 0
        Да, похоже оно.
        Хорошо, что добавлен, как пишут выше, тайм-аут на это состояние в Linux, хотя конечно надо проверить своими руками это.
        Насчет Windows, надо проверять точно…
      • +12
        habracut?
        • +16
          Только это не DDoS, а DoS.
          • 0
            Ну разница не велика, на самом деле. Хотя в случае в одним клиентом, конечно DoS.
            • +4
              хотя, конечно, немного похоже и на DOS.
            • +1
              Серверные версии ОС подвержены атаке?
              • +27
                Vista в качестве серверной ОС — месье знает толк.
                • +14
                  Это нормальное решение, если речь не о запуске серверов для обслуживания сети Windows. Я имею ввиду, например, что если вы хотите запустить Apache на винде (причина не важна, просто есть такое требование — Apache на винде), то нахрена тратить ОЗУ и деньги на покупку Windows Server, когда «десктопная» винда с задачей справится абсолютно так же?
                  • –2
                    Не надо ничего покупать — возьмите Linux на отдельную машину.
                    Если все хочется без допжелеза — то поставьте Vagrant — он вам сам поставит Linux в виртуалке, расшарит туда папку.
                    Вы правите файлы на локальном компе, а их тут же подхватывает LAMP. У вас и винда и нормальная серверная среда одновременно.
                    Профитъ и бесплатно!
                    • +1
                      Некропостер?

                      Требование: «apache на windows». Какой линукс на отдельную машину? Требование прямое и недвусмысленное — «windows».
                      • –1
                        > Требование: «apache на windows». Какой линукс на отдельную машину? Требование прямое и недвусмысленное — «windows».
                        Ну так вы работаете в винде, а апач — в виртуалке. Каждый в своей родной среде.
                        Завтра появится требование «прикрутить маленький модулек» к апачу и начнутся танцы с бубном и пересборки моделей апача в винде.
                        • +2
                          Апач нужен для запуска виндовского CGI-приложения. В вайне не запустишь, исходников нет. Эта винда и есть в виртуалке. Но это неважно.

                          Важно то, что есть конкретное решение, из которого вытекает такое требование. Задача — внедрить, а не выпендриваться и искать другое решение.

                          P.S. я сам линуксоид уже почти 15 лет, джентушник,. Но красноглазики, которые пытаются пихать его везде и всюду, не задаваясь вопросами «а почему так», заколебали. Просто перестаньте.
                  • +2
                    Кто Вам сказал что это серверная ОС ???!!! Там просто поднят простейший ТСР сервер для подключения…
                    Читаем внимательней…
                    • –3
                      — а ваша ОС серверная?
                      — да, конечно, смотрите, тут у нас подняты разные TCP-серверы…
                  • 0
                    Серверная не серверная, какая практическая разница? У меня около 5 лет работал домашний шлюз на Windows XP Pro, где в качестве маршрутизирующего ПО был установлен Kerio Control, там же стояли торренты, FTP, SVN, Apache и ещё много чего, и всё это чудесно работало. Единственное, что я делал с системой это патч для TCP/IP на количество полуоткрытых соединений, но я делал его даже не потому что это шлюз, а потому что там торренты стоят :) И как верно пишет merlin-vrn — если эта машина не работает в качестве контроллера доменов — то это адекватное, и рабочее решение.

                    P.s: и сейчас эта машинка работает, правда я её редко включаю ибо она старая — ест много и греется :), а не используется просто потому что в качестве шлюза и домашнего сервера сейчас работает новая железка и уже с 2008R2 на борту.
                  • +22
                    А пробовали такую операцию сделать 65535 раз, чтобы забились все локальные порты?
                    Что будет с системой?
                    • +8
                      вопрос настоящего тестировщика)
                      • +1
                        Скорее всего, потеряется возможность соединяться именно с тем клиентом, с кем были эти 65535 соединений, а соединения с другими клиентами не должны сломаться или упасть.
                        • 0
                          Все 65535 забить не получится вроде: процесс System открывает сокет на 445/TCP, а svchost на 135/TCP
                          • 0
                            И еще момент:

                            Windows умеет вешать несколько процессов на один сокет.
                            Я столкнулся с этим, когда писал веб-сервер на Java. Например можно так:
                            1) первый процесс java.exe маппится на 127.0.0.1:80
                            2) при запуске ещё одного процесса этого сервера проверка на занятость сокета выдаст результат «сокет свободен»
                            3) Windows запустит ещё один процесс java.exe, который по данным netstat.exe тоже слушает 127.0.0.1:80

                            Все коннекты обрабатывает первый процесс java.exe


                            • 0
                              Это не эксклюзивная фича именно для 127.0.0.1? Потому, что иначе бред какой-то
                              • 0
                                Да, было такое дело. Как-то давно получалось перебивать открытый на 127.0.0.1 порт, изменив 127.0.0.1 на 0.0.0.0.
                                • +1
                                  Сейчас на Windows Server 2008 R2 не получилось воспроизвести.

                                  Но нашел скриншот, где у меня получалось 127.0.0.1 занимать двумя процессами



                                  Возможно это из-за того что 9600 > 1024. Но Windows вроде не разделяет root-порты и клиентские.
                            • 0
                              Реквестирую DoS эксперимент на этой проблеме.
                              • +1
                                Проверили… Итого, это проблема ВСЕХ Windows что были в наличии: Vista, 7, 8, Win server…
                                Сервер НЕ ПРИНИМАЕТ соединение от клиента со старого порта, но принимает с нового, т.е. old src port != new src port => OK!!!
                                • 0
                                  А не пытались переполнить память отведенную на поддержку TCP соединений?
                                  • 0
                                    Нет. Задача ставилась совсем другая — проверить возможность восстановления соединения после обрыва.
                                    Надеюсь кто-нибудь из хабра продолжит исследование темы…
                              • +4
                                Атака очень похожа на выстрел самому себе в ногу. :)
                                Windows Server давно сам себя научился так атаковать, чему крайне способствует SQL Server.

                                Попробуйте с этим хотфиксом: support.microsoft.com/kb/2553549/en-us
                                • 0
                                  Спасибо, попробуем.
                                  • 0
                                    Отпишитесь пожалуйста о результатах. Ибо у меня такое ощущение, что иногда я сталкиваюсь с этой проблемой. просто не понимаю откуда она берётся.
                                    • 0
                                      * ранее не понимал откуда ноги растут.
                                • 0
                                  Хм, я правильно понимаю — если подключаться с разных портов, то в конце-концов можно сделать сервис недоступным?
                                  • 0
                                    Насколько я понял, только для себя (своего IP-адреса). Ну или вариант — возможно, получится исчерпать там память ядра, отведённую для поддержки TCP-соединений, тогда да, ляжет TCP или вся ОС.
                                  • +2
                                    Лучше поздно чем никогда:

                                    Сейчас увидел реальную ситуацию когда из-за этого бага перестает работать TeamCity. Оно перодически дергает Систему контроля версий и оставляет порт в FIN_WAIT2. В итоге, забивает все клиентские порты.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.