Пользователь
0,0
рейтинг
24 октября 2011 в 13:33

Разработка → Перехват PPPoE сессии tutorial



На видео показан практический способ угона сессии PPPoE с помощью врезки в кабель. При этом не происходит перехвата логина или пароля и не имеет значения используемый тип авторизации (CHAP/PAP).

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



Теория



PPPoE (Point-to-Point Protocol over Ethernet) — протокол канального уровня, на уровень ниже ip, поэтому для установки соединения не требуется ip-адреса, адресация происходит по MAC-ам.

Условно процесс подключение выглядит так:

Клиент в поисках pppoe-сервера посылает широковещательный запрос,
MAC-адрес назначения FF:FF:FF:FF:FF:FF.
Сервер отвечает клиенту и происходит авторизация (например CHAP Challenge)



В установленном соединении сервер идентифицирует клиента по MAC-адресу и Session ID. Пакеты IP инкапсулируются внутрь кадров PPPoE. В незашифрованном подключении всё содержимое пакетов может быть просмотрено:



Соответственно, узнав реквизиты подключения, можно перехватить сессию:



Для защиты от подобных атак существует опция CHAP Rechallenge, когда сервер повторно идентифицирует клиента с заданным интервалом времени. Ни один из протестированных провайдеров не использовал эту опцию.

В видео используется виртуальная машина, запущенная в режиме моста с ethernet картой хост-системы.
Во время переключения кабеля важно попасть между пакетами LCP-echo.
PPPoE-сервер www.roaringpenguin.com/products/pppoe перекомпилированный с опцией
#define DEFAULT_MAX_SESSIONS 64000

Спасибо kekekeks за помощь в ковырянии исходников сервера rp-pppoe.
Павел Жовнер @zhovner
карма
172,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (63)

  • +1
    Как вы узнали IP-адрес шлюза провайдера?
    • 0
      По tcpdump-у?
      • 0
        Всё верно, второй адрес в ppp подключение который и является роутом не передается в каждом пакете, там только мак pppoe сервера. Можно либо стимулировать клиента повторно авторизоваться с сервером, (например временно разорвав подключение) тогда этот адрес будет передан в IPCP-пакете, либо спросить у провайдера.
    • 0
      Он обычно не меняется. Можно просто узнать из легитимной сессии.
  • +10
    +100 к паранойи?
  • +2
    PPPoE не предназначен для использования в средах, где возможна такая врезка (читай: для FTTx). Отсюда и фигня.
    В домовых сетях рулит и педалит DHCP + Option 82 и, соответственно, авторизация по порту коммутатора.
    • +2
      Билайн как использовал PPTP, так и использовал.
      • +33
        Билайн — мудаки.
        • 0
          это корбиновское наследие, жаль, что избавляться от него не спешат.
        • 0
          *YES*
      • 0
        а как с таким перехватом дела на adsl линиях?
        • 0
          Будет посложнее, чем подклюение к своему ethernet'у, но принцип тот же.
          • 0
            У жертвы отключится не только интернет, но и телефон, т.е. он быстрее почувствует неладное :)
            • 0
              Не почувствует, всего лишь один глюк в линии в момент врезки.
              • +1
                Если исходного клиента не отрезать, то интернет во врезке скорее всего вообще работать не будет.
              • 0
                Если исходного клиента не отрезать, то интернет во врезке скорее всего вообще работать не будет.
            • 0
              Когда вы последний раз домашним телефоном пользовались;)?
              • +2
                Полчаса назад, а что?
                • 0
                  Комментарий из прошлого века?
                  • 0
                    В телефонном общении обычно две стороны разговора, среднее арифметическое их привычек попадает в прошлый век, да. Хотя телефон — это вообще позапрошлый :)
        • +1
          Говорят, можно в разрез воткнуть DSLAM с зеркалированием порта.
      • +2
        А в нашем городе в домовых сетях Билайн использует L2TP, а не PPTP. Хотя тоже без шифрования. PPTP и PPPoE — разные вещи, хотя отличия только в «конвертах».

        Вроде бы L2TP и PPTP тоже можно перехватить (точнее, не перехватить, а «увести» к себе) тем же способом, т.к. авторизация (внутри PPP поверх L2TP) используется только в самом начале сессии, а в последующих пакетах идет только номер сессии.
    • +1
      Что-то не связывается:
      dhcp — чтобы выдать адрес
      option 82 — чтобы узнать с какого порта, какого коммутатора пришел dhcp запрос
      авторизация по порту — разрешать инет или нет в зависимости от того, откуда пришел запрос

      Каким образом это всё поможет от врезки в кабель до порта коммутатора? Через крокодильчики узнать MAC и всё остальное. Потом настроить сетевуху, обрезать, обжать подключиться вместо него и всё.

      По-моему, даже легче чем с PPPoE. Что-то упустил?
  • 0
    Я-то думал, вы действительно PPPoE сломали, а тут незашифрованная сессия…
    • +5
      Он сломал то, что используется на практике у крупнейших провайдеров.
      • 0
        Я же не сказал, что автор что-то сделал не так. Все это, конечно, круто с точки зрения практического использования, но совсем не так интересно как могло бы быть.
  • 0
    Простите за ламерский вопрос.
    А что если кто-нибудь из пользователей провайдера поставит свой PPPoE-сервер, не получится ли ему подключить клиентов к себе? Такое возможно, кто знает? Или все/не все провайдеры блокируют такие вещи на коммутаторах?
    • +1
      CHAP авторизация работает таким образом, что если обе стороны не знают комбинации логина-пароля подключится не удастся.
      • 0
        На своём PPoE сервере злоумышленник может просить именно PAP и если в клиенте не стоит «подключатьс только по CHAP» то вполне удастся узнать пароль. Другое дело, то можно наверное на свиах фильтровать это каким-т ообразом?
        • +2
          Да, CHAP-пароль вынюхать не получится, но Nastradamus спрашивал не об этом, а о «подключении клиентов к себе» — для этого пароль клиента знать не нужно, можно изменить код своего PPP-сервера так, что он будет принимать любой ответ на challenge, без проверки, т.е. клиент успешно пройдет авторизацию, и не будет знать, что он работает через «другого провайдера». И дальше хакер может вынюхивать пароли пользователя на почту, веб-службы и т.д., если пользователь работает с ними без SSL/TLS. Поэтому если провайдер не блокирует бродкасты, то конечно подвергает своих клиентов риску.
          • 0
            Вы правы, я заблуждался. Мне всегда казалось что CHAP авторизация двухсторонняя.
          • 0
            можно ещё явно AC name указать в подключении. Если провайдер предоставляет данную информацию.
            • 0
              AC name можно и из записи сессии выяснить, если провайдер его не сообщает. Но к сожалению ничто не помешает злоумышленнику указать то же самое имя концентратора, там ведь никакими ЦП идентификация не защищается.
          • +3
            можно изменить код своего PPP-сервера так, что он будет принимать любой ответ на challenge, без проверки, т.е. клиент успешно пройдет авторизацию, и не будет знать, что он работает через «другого провайдера».


            Через этого «другого провайдера» клиент будет работать до первого обращения в техподдержку. При обращении же выяснится что клиент работает, а на BRAS-е сессии нет. Потом путём несложных манипуляций выясняется, «откуда кака прилетает» — т.е. откуда клиент получает PADO, и принимаются соответствующие меры.

            Хотя практика показала, что «самозванными провайдерами» зачастую становятся не по злому умыслу, а по неумению — настраивают, к примеру, VPN на кошке, и выставляют наружу PPPoE вместо L2TP. И потом еще удивляются, за что им порт уложили.
            • 0
              Это понятно, что вскрыть размножение провайдеров легко. Хотя бы по самому факту бродкастов.

              menraen: практика показала, что «самозванными провайдерами» зачастую становятся

              Даже как-то не по себе стало от прочтения такой «частой практики». Это что выходит, что провайдеры (или где у вас практика?) все-таки не блокируют такие бродкасты, и не мониторит, и что факты таких приключений выясняются только при обращении клиента в техподдержку? Значит описанное в моем комменте ниже может случиться не только «теоретически»? Ой.
              • 0
                Это что выходит, что провайдеры (или где у вас практика?) все-таки не блокируют такие бродкасты


                Какие броадкасты? PADO — вполне себе юникаст.
                • 0
                  PADI бродкаст — его и надо блокировать (не пускать на порты других клиентов), тогда «альтернативные провайдеры» не смогут выслать в ответ PADO, и подмена сервера не состоится.

                  В общем, та же процедура, что и с блокировкой посторонних DHCP-серверов.
                  • 0
                    В общем, та же процедура, что и с блокировкой посторонних DHCP-серверов.

                    Не совсем та-же. Блокировка DHCP-сервера представляет собой drop-анье offer-ов с untrusted портов, и относится производителями оборудования к L3-функционалу. Там же, где «последняя миля» терминируется на L2-устройстве, _обычно_ есть возможность лишь запретить _любое_ общение (мультикаст, броадкаст, юникаст) кроме как с аплинком (т.н. port isolation), что и делается на практике, и лишь изредка можно ставить фильтры по Ethertype, и то — настройка таких фильтров обычно выглядит как переключатель «allow all <-> PPPoE only».
                    • 0
                      Да, уровень другой, но принцип тот же…

                      Если «последняя миля на L2-устройстве», то выходит пользователи вообще практически беззащитны (не в смысле уязвимостей ОС, а в смысле уязвимостей сетевой инфраструктуры). Эдакая «ЛС без сисадмина»…

                      Значит наличие в сети соседских бродкастов означает, что port isolation отключен, и вообще ничего не фильтруется?
                      • 0
                        Да, уровень другой, но принцип тот же…

                        Ваши бы слова, да производителям DSLAM-ов в уши…
                        Если «последняя миля на L2-устройстве», то выходит пользователи вообще практически беззащитны

                        Уж точно не беззащитнее пользователей «настоящих» домосетей, которые зачастую именно «ЛС без сисадмина на неуправляемых свичах». Кроме того нужно понимать, что собственный провайдер — худшая из возможных целей для взлома по целому ряду причин (хотя это отнюдь не означает что провайдер не принимает мер для предотвращения взломов и других деструктивных действий).
                        Значит наличие в сети соседских бродкастов означает, что port isolation отключен

                        А где я сказал про _соседские_ броадкасты? ;)
                        • 0
                          > Уж точно не беззащитнее пользователей «настоящих» домосетей, которые зачастую именно «ЛС без сисадмина на неуправляемых свичах».

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

                          > А где я сказал про _соседские_ броадкасты? ;)

                          Это я говорил ранее — в комментариях ниже про шумящие бродкастами TV-приставки Билайна.

                          > собственный провайдер — худшая из возможных целей для взлома по целому ряду причин

                          Это понятно, я о том же и говорил, что легко детектируется. Но хотелось, бы, чтобы была техническая невозможность реализации указанных атак. Т.е. фильтрация «системных» бродкастов хотя бы. А если всё так, как вы пишете, то это довольно печально. Себя-то провайдер защитит, а вот соседей друг от друга — нет.
                          • +1
                            Разумный провайдер всегда будет принимать разумные меры для защиты как себя, так и своих абонентов. Однако любой провайдер — в первую очередь коммерческая организация, и он при всём желании не может ставить 100% безопасность каждого конкретного клиента за основную цель. Осноная цель любого бизнеса — извлечение прибыли, и глупо ждать что при абонплате в среднем 5-10$ в месяц вы получите от провайдера state-of-the-art защиту от любых угроз, будете включены в «супер-умное» оборудование, умеющее «заглядывать» в заголовки до L7 включительно, и т.д. Кроме того, как опять-же показывает практика, безопасность — не та штука, которой «много не бывает», и собственные «благодарные» клиенты первыми побегут от «безопасного» провайдера к «опасному», но на котором «осёл» (к примеру) не ловит постоянно LowID.

                            Если же возвращаться к сабжу — да, такая атака принципиально возможна при совпадении ряда факторов, проверить совпадение которых не удастся до фактического совершения атаки — т.е. «или пан, или бан». Однако вероятность успешно, и главное — незаметно её провести ничтожно мала.

                            Ждать принятия провайдерами каких-либо дополнительных мер для предотвращения этого типа атак также, думаю, не стоит по уже упомянутым здесь причинам. Только если производители оборудования «почешутся». А они не почешутся, потому что от них в последнее время только и слышно что «PPPoE is dead, baby».
                            • 0
                              А что они (производители) рекомендуют на замену PPPoE?
                              • 0
                                DHCP
                                • +1
                                  Ну IP-то DHCP выдаст, а дальше? Смысл всех этих VPNов и прочих виртуальных каналов в том, чтобы клиент вводил «пароль для интернета», а локальный трафик чтобы шел отдельно. Если от такой схемы отказываться, то провайдерам придётся менять все учетные схемы и тарифные планы, так?
                                  • 0
                                    чтобы клиент вводил «пароль для интернета» актуально для провайдеров, выросших из домосетей. PPPoE — это обычно xDSL, т.е. не домосети, а крупные телекомы, которые никогда «домосетями» не были, и под «локальным» трафиком подразумевают ни разу не трафик «внутри свича», а, к примеру, собственные сервера с контентом. Но мы уже очень сильно отклонились от сабжа топика.
                                    • 0
                                      Провайдеров с PPPoE в нашем регионе нет вообще, самопальные домовые сети раздают IP по DHCP, статистику считают по IP на шлюзах, старейшие «автохтонные» провайдеры региона (не домовые сети, а «наследники» телефонных пулов, сейчас у них у всех оптоволокно до большинства многоэтажек в городе, т.е. в каждом доме 4-5 провайдеров на выбор) раздают интернет по PPTP, единственный «телеком» на домашнем рынке — Билайн, у него L2TP. При этом у Билайна локальным считается весь внутригородской трафик по билайновской сети (включая трафик между клиентами — торренты и DC в основном) и до пары московских («личный кабинет»), а остальные билайновские сайты маршрутизируются по не-локальным IP, и в статистике считаются как внешние. Пиринга с местными провайдерами у билайна нет, к ним все идет через Питер+Москву. Ну то есть, у нас получается все наоборот, в сравнении с вашей картиной.
                • 0
                  А, понял, это ответ на моё " Хотя бы по самому факту бродкастов."? Да, там неправильно, атакующий «альтернативный провайдер» может обойтись без бродкастов, если бродкасты от клиентов не блокируются.
      • +3
        CHAP-авторизация работает таким образом, что клиенту сообщается challenge (случайная последовательность байт), и он из этой строки и своего пароля вычисляет хэш-ответ, который потом проверяется сервером. Т.е. авторизация односторонняя. Клиент никак не может проверить, что сервер — именно тот (это функция IPSEC, который провайдерами не используется).

        Поэтому да, обман клиентов и переключение их на себя теоретически возможен, причем не только в PPPoE, а вообще в любых автонастраиваемых протоколах, где используются бродкасты (DHCP, WPAD, IPv6 RAD и т.д.), и борьба с таким обманом очевидна — в провайдерском концентраторе должны быть заблокированы бродкасты соответствующих протоколов. На практике у провайдеров в домовых сетях часто разрешены многие широковещательные протоколы, которые тоже хорошо бы запретить (например, NetBIOS). Билайн сейчас активно внедряет в домовых сетях IP-телевидение, так вот эти TV-приставки тоже активно шумят в сети — в бродкастах сообщают, что именно смотрит юзер, сколько у него места на диске осталось, и т.д. :)
        • 0
          ayc, спасибо. Я именно бродкасты на адрес FF:FF:FF:FF:FF:FF и имел в виду.

          Вот интересно попробовать на своем провайдере чисто из академического интереса, но боюсь людей в черном. :)
          • +1
            Menraen выше написал, что действительно бывают такие случаи. И там же он написал правдоподобную отмазку для людей в черном — «случайно включил PPPoE вместо L2TP» :)
            • 0
              Случаи укладывания портов автоматом с последующей необходимостью объяснять в письменном виде провайдеру логику своих действий для возобновления доступа к Интернету — да, бывают. Так что дерзайте. Только учтите — «отмазка» проходит только 1 (один) раз.
  • 0
    Напоминает старую добрую прослушку телефонов
  • +5
    Вольнов, ты?
    • +1
      Есть такое мнение.
  • 0
    Каких провайдеров проверяли?
  • +1
    я так думаю, PPPOE — провайдеров шифрующих ВЕСЬ траффик попросту нет, т.к. скорости сейчас большие+траффик внутри локальной сети не ограничен — и никакая циска не сможет шифровать несколько десятков мегабит (несколько клиентов в доме).
    • 0
      Ну, раз есть провайдеры, которые шифруют весь трафик в PPTP (у меня такой), шифруют весь трафик в точках доступа wi-fi (все такие), то почему бы не быть и шифрации в других канальных протоколах…

      Проблема там, кстати, не только в отсутствии шифрации, но и в отсутствии аутентификации сервера (сертификатов сервера), т.к. сессию можно перехватывать не только в середине, но и в самом начале — подменив сервер, можно шифровать трафик своим подставным сервером, т.е. просто галочка «требовать шифрование» клиента в этом случае не спасёт.
  • +3
    Пошел к соседу…
  • +1
    Голос приятный, как раз на утро.
    Спасибо.
  • +2
    Отлично, нам будет над чем подумать с коллегами теперь))
  • НЛО прилетело и опубликовало эту надпись здесь

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