LDAP-«аутентификация» — это антипаттерн

Автор оригинала: Ryan Newington
  • Перевод

Сегодня в любой организации есть LDAP-каталог, наполненный пользователями этой организации. Если присмотреться, вы найдете одно или несколько приложений, которые используют этот же каталог для «аутентификации». И кавычки здесь неспроста, ведь LDAP — это протокол доступа к каталогам, спроектированный для чтения, записи и поиска в службе каталогов. Это не протокол аутентификации. Термин «LDAP-аутентификация», скорее, относится к той части протокола (операции bind), где определяется, кто вы такой, и какие права доступа имеете к информации каталога.

Со временем LDAP стал службой аутентификации де-факто. Широко распространенные и доступные службы LDAP, такие, как Active Directory, стали лакомым кусочком для разработчиков программного обеспечения, которые хотят встроить аутентификацию в свои продукты. Клиентские библиотеки LDAP доступны практически для любого фреймворка, а реализовать интеграцию относительно легко.

Но несмотря на то, что применение LDAP может помочь решить задачу внедрения аутентификации пользователей в различных приложениях компании, оно создает множество проблем. В отличие от специально предназначенных протоколов аутентификации, при использовании LDAP возникают различные уязвимости информационной безопасности.

Чтобы разобраться в том, что это за уязвимости, сперва нужно понять, как работает LDAP-аутентификация.

Как работает LDAP-аутентификация


Представьте себе следующую ситуацию (она далека от реальности, но отлично передает суть).

Предположим, я делаю заказ в интернет-магазине так, чтобы его доставили мне домой в мое отсутствие. Курьер приезжает и оставляет под дверью записку с текстом «извините, мы вас не застали» и просит меня забрать заказ в ближайшем пункте выдачи в удобное время. В пункте выдачи сотрудник спрашивает мое имя, адрес и просит ключи от дома, чтобы подтвердить мою личность. Затем сотрудник службы доставки приезжает ко мне домой и открывает дверь моим ключом. Он заходит внутрь, чтобы убедиться, что я там живу, например, по фотографиям на стене или по имени адресата на корреспонденции. После этого сотрудник возвращается в пункт выдачи и сообщает мне, что успешно подтвердил мою личность, и я могу получить свою посылку! Ура!

Помимо проблем с логистикой, данная ситуация полна других вопросов. Что, если недобросовестный проверяющий сделал копию моего ключа? Или он оставил ключ надолго без присмотра, и это сделал кто-либо еще? Что, если на проверяющего напали и забрали мой ключ? Когда я отдаю ключ от своей квартиры незнакомцу, я не могу быть уверен в его порядочности и своей безопасности.

К счастью, в реальном мире у нас есть документы для подтверждения личности, например, водительские права или паспорт, которые выданы государственными органами, и их подлинность не вызывает сомнений. Я могу предоставить эти документы курьеру для собственной идентификации без передачи ключей.

В мире LDAP мы все еще должны передавать наши ключи, чтобы открыть дверь от нашего имени. Мы передаем наш пароль стороннему лицу, и он пытается с его помощью проникнуть на сервер LDAP. Если ему удается получить доступ, мы не можем быть уверены, что наши учетные данные не скомпрометированы. При этом злоумышленник получит не только возможность разблокировать дверь LDAP, но и доступ к любому приложению, использующему те же учетные данные.

К счастью, в более полном мире аутентификации у нас также есть паспорта и водительские права! Протоколы аутентификации, такие как Kerberos, SAML и OpenID Connect, выпускают токены третьим лицам. Токены подтверждают, что вы являетесь тем, за кого себя выдаете, и нет необходимости передавать кому-либо свои ключи. Поскольку LDAP никогда не разрабатывался как протокол аутентификации, соответствующие механизмы у него отсутствуют.

Недостатки LDAP как системы аутентификации


В 2007 году Шумон Хак выпустил фантастическую статью (LDAP Weaknesses as a Central Authentication System), в которой он описывает три конкретные проблемы при использовании LDAP в качестве системы аутентификации.

1. Приложение, вероятно, недостаточно защищено, чтобы оперировать учетными данными


Автор подчеркивает, что защитить от атаки небольшой набор серверов аутентификации гораздо проще, чем защитить большое количество серверов приложений.

В своем большинстве серверы аутентификации, как правило, находятся под тщательным присмотром специалистов, обладающих значительным опытом в области информационной безопасности.

С другой стороны, серверы приложений имеют совершенно иной уровень безопасности и более подвержены риску компрометации. Они менее защищены, работают с более сложными программными стеками и с большей вероятностью имеют уязвимости. И чаще они находятся под управлением людей, которые не имеют глубоких знаний о безопасности. Построение правильной системы безопасности — сложнейший процесс, в котором очень легко допустить ошибку.

Проблема заключается в том, что если один сервер приложений скомпрометирован, то все учетные данные, которыми пользовались их владельцы во время атаки, также скомпрометированы. Под угрозой находится и любая другая система, которая использует тот же каталог LDAP для аутентификации.

2. Сервер LDAP не может обеспечить безопасность механизма аутентификации, используемого для получения учетных данных


LDAP-сервер не может гарантировать безопасность транзакции. Несмотря на то, что LDAP-сервер, например, может обеспечить принудительное выполнение операции bind по TLS, чтобы гарантировать, что учетные данные не передаются в открытом виде, сам сервер никогда не принимал никакой роли в получении учетных данных от пользователя. Существует риск, что приложение будет получать пароль по небезопасному каналу.

3. Пользователь вынужден делиться своим секретом аутентификации с третьей стороной


Пароль пользователя или секрет аутентификации должен оставаться секретом. Он должен быть известен только самому пользователю и системе аутентификации. При использовании LDAP-аутентификации пользователь вынужден поделиться своим секретом с третьей стороной, чтобы она затем смогла использовать данный секрет для взаимодействия с LDAP-каталогом от имени пользователя.

Важно упомянуть, что при использовании специально предназначенных протоколов аутентификации, таких как Kerberos, и даже с более раннего — NTLM, секрет пользователя никогда не передается по сети. Клиентское устройство и сервер используют криптографические операции, чтобы доказать друг другу, что у них один и тот же секрет и при этом даже не обмениваются самим секретом.

К пунктам Шумона Хука добавлю описание нескольких нюансов LDAP-аутентификации, основываясь на собственном опыте. Прежде всего, тема касается использования Active Directory.

4. Многие разработчики знают о механизмах работы LDAP недостаточно, чтобы правильно его использовать


В одном из моих прошлых постов блога описывается, как анонимные и неаутентифицированные bind’ы позволяли обхитрить разработчиков приложений и заставляли пропускать неавторизованных пользователей. Возможность выполнения операции bind без проверки подлинности — одна из тонкостей протокола, о которой не знают даже самые опытные специалисты по LDAP.

Каталоги устроены непросто и способны хранить огромное количество организационной информации и предоставляют множество настраиваемых способов ее хранения. Я видел очень много случаев, когда разработчик приложения предполагал, что существует определенный класс объекта или атрибут, а когда их не обнаруживалось, приложение падало. Для аутентификации пользователя не должны требоваться и применяться знания о структуре данных, хранящихся в каталоге. Протокол аутентификации должен абстрагироваться от деталей хранилища объектов, расположенного уровнем ниже.

5. Администраторы приложений зачастую не настраивают LDAP-клиенты корректным образом


При управлении Active Directory в большой распределенной среде есть один неприятный нюанс: трудно определить, какие конкретно приложения используют Active Directory в качестве LDAP-каталога, и как именно администраторы приложений настроили LDAP-клиент.

Ниже представлены примеры ужасов некорректной настройки.

  • Хардкодинг DN в приложениях или использование DN при выполнении операции bind. Постоянно случаются неприятности при переименовании или перемещении объектов внутри директории, а все потому, что кто-то где-то захардкодил DN. (Примечание для тех, кто выполняет простые операции bind с Active Directory: нет необходимости использовать DN. Active Directory также предоставляет альтернативные форматы DN, которые являются более надежными, чем использование традиционного формата).
  • Для операции bind используется не сервисный аккаунт, а персональный аккаунт разработчика или администратора (представьте, что будет, когда владелец аккаунта покинет компанию).
  • Отправка паролей в открытом виде на 389-й порт.
  • Существуют приложения, где чекбокс «Валидировать сертификат» не является обязательным при подключении к AD с использованием TLS (порт 636). Почему такое вообще допустимо? Как можно передать пароль стороннему сервису, не убедившись в его достоверности?

Заставить LDAP-клиент работать легко. Но только тот факт, что он работает, не означает, что конфигурация правильная.

6. LDAP-аутентификация и современные сервисы аутентификации взаимоисключают друг друга


Приложение, использующее LDAP для аутентификации, всегда будет вынуждено опираться на имена пользователей и пароли. Попытка реализовать современные технологии, такие как многофакторная аутентификация и единый вход, практически невозможна (если только вы не собираетесь внедрять свои собственные технологии, что само по себе является плохой идеей). Альянс FIDO стремится сделать пароли пережитком прошлого, а каждое приложение, использующее аутентификацию LDAP, будет помехой на пути к беспарольной политике.

Какие есть варианты?


Сегодня веб-приложения действительно могут обойтись без LDAP-аутентификации. Существует множество прекрасных веб-протоколов аутентификации, таких как SAML, WS-Federation и OpenID Connect, которые не требуют учетных данных пользователя для работы со сторонними приложениями. Бесчисленное количество продуктов предоставляют эти услуги, включая Active Directory Federation Service (встроенные в Windows Server) или сторонние сервисы, такие как Microsoft Azure AD, Okta, Ping и другие. Если в организации нет федеративного IdP, первое, что нужно сделать — внедрить его.

Главное, на что стоит обратить внимание при выборе нового ПО — поддержка современных протоколов аутентификации. Даже если приложение требуется бизнесу здесь и сейчас, не стоит спешить с выбором решения, особенно, если этот выбор ограничен только продуктами с LDAP-аутентификацией. Стоит попробовать донести до выбранного вендора необходимость доработки продукта с использованием более современных протоколов аутентификации. Возможно он прислушается и пересмотрит свой план разработки.

Число десктоп-приложений с «толстым клиентом», поддерживающих современные протоколы аутентификации, растет, и это действительно радостная тенденция. Эти приложения обычно были оплотом LDAP-аутентификации. Растет число SDK, таких, как Microsoft Authentication Library (MSAL), которые позволяют разработчикам легко добавлять поддержку современных сервисов аутентификации в свои мобильные и десктоп-приложения.

В конечном счете, стоит признать, что в сегодняшней реальности не все приложения поддерживают современные протоколы аутентификации, и, возможно, никогда и не будут. Внедрение полного запрета LDAP-аутентификации, вероятно, невозможно ни в одной организации. Однако ни в коей мере не стоит поощрять применение LDAP-аутентификации внутри организации. Использование LDAP следует рассматривать только при отсутствии других вариантов.
Avanpost
Безопасность начинается с управления доступом

Комментарии 36

    0

    Все хорошо, только разваливается при требовании некоей странички учёта времени на корпоративном портале ввести юзера и пароль. Да менять пароль раз в три месяца.


    Я к тому что некоторым внутренним приложениям вообще нужна неаутентификация, а только идентификация. Тут все средства хороши лишь бы не вводить ничего.

      +1

      Аутентификация это и есть идентификация. Возможно вы имели ввиду авторизацию? Т.е. далеко не всем нужна авторизация (факт наличия прав на некое действие), а достаточно только аутентификации (т.е. подтверждения что вы это вы).

        +3

        Э нет. Аутентификация гораздо больше идентификации. Это если хотите гарантированая идентификация. А просто идентификация это "я Вася". Без доказательств. И этого достаточно многим некритичнам внутренним приложениям.

          0

          Ок. Вы убедили меня что идентификация и аутентификация это разные понятия. Но тогда я в упор не понимаю где применяется именно идентификация. Оффтопик конечно, но не расскажете ли?

            0
            Идентификация, как вариант, может использоваться в интернет-магазине с быстрым заказом. Указываешь Имя, Адрес и Телефон. Это и будет идентификация. Потом звонит администратор и авторизует идентифицированного заказчика, подтверждая по телефону, что это он выполнил операцию. Впоследствие курьер аутентифицирует клиента, при выдаче заказа, спросив, он ли этот заказ делал.
        +2
        Прямой и правильный путь для корпоративного портала, если он доступен только из локальной сети — использовать Kerberos. И пользователи будут счастливы, и владельцы.
        Если доступен извне и прозрачная доменная аутентификация невозможна, есть альтернативные варианты. Наиболее популярные сейчас — SAML и OpenID Connect
        +2
        6. LDAP-аутентификация и современные сервисы аутентификации взаимоисключают друг друга

        Приложение, использующее LDAP для аутентификации, всегда будет вынуждено опираться на имена пользователей и пароли. Попытка реализовать современные технологии, такие как многофакторная аутентификация и единый вход, практически невозможна

        Простите, что? Если взять AD как реализацию LDAP, то он отлично интегрируется с AAD и AD FS — вот вам и MFA, и SSO.
          +1

          Это же код писать надо в своей приложеньки. Местами сложный.
          А по логину с паролем достаточно с so скопипастить.

            +1

            Интересный вопрос, в AD DS вокруг каталога Kerberos и NTLM, ещё и сам каталог не совсем соответствует ntds.dit.
            Автор, насколько я понимаю, обсуждает проблему простой аутентификации через открытие ldap каталога. Какой-нибудь HP BladeCenter или Zabbix, которые просто открывают LDAP каталог с вашим логином и плейн-текстовым паролем, и если всё получилось — ура, пароль был верным. Заодно одно ваши группы прочитать для авторизации, а можно и не только ваши, и не только почитать.

              +1
              Статья вашему утверждению и не противоречит. Если вы дочитаете ее до конца, то увидите рекомендацию использовать ADFS и ADD.
                0
                Я говорю про конкретный пункт — тут сказано, что LDAP исключает MFA и SSO. В то время как их можно использовать вместе. Чистый LDAP этого не предоставляет, но вовсе не исключает.
                  +1
                  Сказано что LDAP-аутентификация исключает MFA и SSO. Поскольку LDAP-аутентификация это операция bind(), как минимум формально автор прав.
              –1

              Может быть вы тогда можете посоветовать небольшой сервер для авторизации\аутентификации для self-hosting?
              Все сервера для OpenID и OAUTH, что я находил являются огромными монстрами на Java, которые запустить и настроить является заметной проблемой.

                0
                Если основная инфраструктура у вас на продуктах MS, то самый простой путь — ADFS. Большинство опенсорсных IDP, как вы заметили, действительно представляют собой Java- приложения, но, настройка, например Keycloak, не настолько сложна как кажется на первый взгляд.
                  +1
                  Посмотрите на связку FreeIPA (Identity Management система) + Keycloak (SSO провайдер). Запускается и настраивается «из коробки», ресурсов требует мало, документация хорошая:)
                  +1
                  Какая тогда альтернатива? Возьмем простой случай — есть некая организация и некий набор сервисов внутреннего пользования — корпоративная вики, тот же zabbix, gitea, радиус-сервер для хождения по сетевым устройствам и т.д. Что, в каждом сервисе заводить свои локальные учетки?
                    +1
                    Нет, пытаться использовать сервисы, которые умеют, к примеру, OpenID, когда сам сервис не получает учётных данных, а получает от сервера аутентификации токен.
                      +1
                      Человек должен вводить свой пароль один раз. При логине на свой компьютер.
                        0
                        Тут есть небольшая проблема — если он вдруг отойдёт от компа не залочив его, злоумышленник может получить доступ ко всему сразу.
                          0

                          Доступ злоумышленника к незаблокированному компьютеру в любом случае даст ему доступ ко всему к чему есть доступ у пользователя.


                          Запустить один бинарник на незаблокированном компе не выглядит сложной задачей.

                            –1
                            Если это комп без портов и без возможности запуска произвольных бинарников, к тому же не имеющий выхода в интернет — задача очень даже сложная.
                              +1

                              Только вот на таком работать нельзя. У обычного разработчика ноут с полными правами и всеми портами.


                              Девочка с браузером это предел для такой конфигурации. А у нее и не должно быть доступов никуда. Надо по умолчанию считать что все что у нее есть она сольет.

                                0
                                Обычным разработчикам, которые не пишут под конкретное железо и обеспечены всем что нужно в сети вовсе нет небходимости пользоваться полными правами — вы, видимо, никогда в реально закрытых конторах не работали, где не то что свой ноутбук, свою одежду приходится в камере хранения оставлять, а потом 10 минут ехать до рабочего места в закрытом автобусе.

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

                                SSO это конечно удобно, но вовсе не панацея и имеет свои недостатки.
                                  +1
                                  У Гугла, да и у Яндекса тоже, все смотрит прямо в интернет. Я уверен что разработчики у них с полными правами на ноутах. Секретов у них больше чем у всех остальных вместе взятых. Полное досье на всех (с мизерной погрешностью) жителей Земли.
                                  И ничего. Все безопасно и ничего по вине Гугла не утекает. Значит дело не в правах на ноутах, а в бумерах которые думают что дело в ноуте или вообще в одежде.

                                  Ну так делим по такому же принципу. Доступ только к тому к чему он нужен. Операции разумно ограничены. По простому «Полная выгрузка базы не нужна среднему пользователю. Да и рейт лимитер полезно прикрутить.» Ну и так далее в зависимости от предметной области.

                                  Да какие мышки с джойстиками. Мы тут вроде как разработчики. На Питоне наговнокодить все можно. С любой машины. Питона нет, так я и на Баше напишу. Апи хоть какое-то есть и дальше дело техники. Соответвенно исходим из того что любой злоумышленник устроившийся на работу может сделать тоже самое.

                                  SSO это как раз панацея. Один пароль можно заставлять делать сложным и учить наизусть. С привязкой к компу вообще хорошо. Логин с другого компа это сразу алярм.
                                  А вот если пароль надо вводить по 10 раз для начала работы, то уже так не выйдет. Если пароли разные, то вообще можно сразу тушить свет. Люди извернутся, но придумают как сделать так чтобы попроще печатать было. Люди они такие.
                                    0
                                    Задачи (и конторы) бывают разные, не у всех и не всегда есть (и нужен) полный доступ ко всему, думаю и у Гугля и у Яндекса есть закрытые зоны куда со своими устройствами не пускают, а «обычный» разработчик вряд-ли имеет возможность со своего ноута подключиться к прод базе клиентов и уж тем более что-то там менять.

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

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

                                    SSO в чистом виде применим только в очень доверенной среде, и его слепое использование «потому что удобно» открывает много рисков (погуглите «sso risks»).

                                    Это не значит что от него нужно отказываться — но риски нужно учитывать и принимать меры, вплоть до того чтобы применять SSO селективно, в зависимости от конкретной среды или даже конкретной транзакции.

                                      +1
                                      Какие зоны? Вы о чем вообще? К вайфаю подключился и все. Физически можно быть в любом месте офиса. К серверам подходить не надо вообще.

                                      Простите, если не у разработчиков то у кого доступ к проду должен быть? Кто будет править ошибки когда все сломалось? Кто новые версии разворачивать и мониторить будет? Кто ошибки которые появляются только на проде ловить будет? Эльфы?

                                      Если у вас в системе клерк может кредитный лимит просто выставить или долг списать так что об этом через минуту не узнают все, то у вас проблемы с процессами. Большие проблемы. Не надо валить проблемы с больной головы на здоровую.

                                      Устроится на работу в банк клерком сложно? Вы это серьезно? Естесвенно со своего, а с какого еще? К другим аккаунтам доступа быть не должно вообще.

                                      Нет. SSO закрывает самую главную дыру. Пароли пользователей с возможность авторизации по сети с любого оборудования. Основная дыра это человек. Как раз ее SSO и прикрывает.

                                      Нет, его надо просто использовать. Можно добавить 2fa для логина в места где ну совсем секретно. Или там для перевода миллиона долларов. И раздать токены кому надо. Главное чтобы эти операции были не по 100 раз на дню. Иначе пользователи автоматизируют и упростят.
                                        –1
                                        Простите, если не у разработчиков то у кого доступ к проду должен быть? Кто будет править ошибки когда все сломалось? Кто новые версии разворачивать и мониторить будет? Кто ошибки которые появляются только на проде ловить будет? Эльфы?

                                        К проду доступа быть не должно ни у кого, кроме как у CD (continuous delivery) системы. Ошибки править будут разработчики, но никак не на продакшне. Новые версии разворачивает CD тулсет. Мониторит система мониторинга. Ошибки, которые появляются только на проде, отлично видно в логах и в мониторинге прода.
                                          0

                                          Так а кто настраивает CD? Кто ее входными данными кормит? А если данные на проде разошлись? Или просто прилетело что-то странное и роняющее все. А перешардировать прод кто будет?


                                          Править не на проде хорошо конечно. Но как сказал один умный человек "Когда у вас петабайты данных, то теста нет. Тест становится слишком дорогим. И что делают разработчики? Правильно! Тестируют на проде" Отсюда весь этот девопс и доступы для разработчиков.


                                          Логи, кодревью, аппрув от 2 человек. Это все нормальные практики для защиты прода.

                        +1
                        настраивайте AD и используйте SAML/OpenID/Kerberos. Для этого каждое приложение надо зарегистрировать в AD и настроить single sign-on.
                        если ваша вики/вебприложение крутится на стеке линукс+апач+PHP, то надо перетащить на виндовый апач и установить mod_auth_sspi и удостовериться что сайт вики находится в доверенной зоне браузера
                      +1
                      > 3. Пользователь вынужден делиться своим секретом аутентификации с третьей стороной

                      Читаем RFC 4513:

                      6.3.2. Name/Password Mechanism Security Considerations

                      The name/password authentication mechanism of the simple Bind method
                      discloses the password to the server, which is an inherent security
                      risk. There are other mechanisms, such as SASL DIGEST-MD5
                      [DIGEST-MD5], that do not disclose the password to the server.

                      > Существует риск, что приложение будет получать пароль по небезопасному каналу.

                      Если кто-то передает пароли в открытом виде в своем приложении, то чем здесь LDAP провинился?
                        0

                        Защищает ли этот механизм от переиспользования учётных данных? От выполнения сервером или mitm любых действий в каталоге от вашего имени?

                          0

                          Для DIGEST аутентификации сервер должен уже знать пароль пользователя, притом открытым текстом. Точнее, достаточно особого хеша от него, но это не играет особой роли: зная этот хеш, можно выдать себя за пользователя, то есть этот хеш на самом деле и есть "digest-пароль" в открытом виде.


                          Единственное что тут можно сделать — это каждому серверу свой realm назначать, но это же надо писать свой плагин для LSA контроллера домена, что так себе затея.


                          К тому же, все мечты о безопасности разбиваются о MD5.


                          В общем, в домене DIGEST-MD5 безопасным методом не является ни разу.

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

                        Самое читаемое