Как потерять доступ в лайв систему, просто пошарив исходный код

    Безопасность на реальных примерах всегда более интересна.

    Один раз пришел клиент с запросом на тестирование на проникновение. У него было достаточно много причин для беспокойства, среди прочих прозвучала и такая: “Несколько месяцев назад к нам пришел новый разработчик, получил доступы к исходному коду, документации, тестовому серверу, через два дня пропал и до сих пор не отвечает. Чем мне это может грозить? Доступы в лайв систему ему не давали.”

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

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

    Система 1.
    Клонированный код из гита это не только последняя версия, но и история всех изменений. Source code на предмет чувствительной информации мы обычно прогоняем, используя gittyleaks.

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

    image
    Картинка 1. Output: gittyleaks --find-anything


    Система 2.
    Можно воспользоваться git утилитой и попросить ее показать все когда-либо удаленные файлы. В данной системе мы нашли deployer.pem файл, который лежал когда-то в руте проекта и использовался для автоматического разворачивания проекта на серверах через SSH канал. SSH порт в лайв системе был открыт. Почему открыт? Разработчики ответили, что билд машина у них сидела за динамическим IP адресом, и они решили не закрывать порт — “все равно SSH ключ никто не подберет”. Гы-гы…

    image
    Картинка 2. Output: git log --diff-filter=D --summary

    Система 3.
    С этой системой все было ещё проще. Возможно, стоит залезть в скрипты базы и посмотреть, как создаются пользователи по умолчанию. Обычно первым пользователем создается админ с самыми высокими полномочиями. В скриптах мы нашли код, который из реальных паролей генерировал хэш и записывал его в базу. Что удивительно — создавалось 5 пользователей, но пароль для самого главного админа к нашему изумлению прошел в лайв системе. А этому коду не первый год, между прочим, и не один человек работал с ним.

    image
    Картинка 3. Как в скриптах базы можно найти реальные пароли

    Посыл.

    1. Если ваш проект на гите, откройте его и запустите пару команд из рут папки:

    pip install gittyleaks
    gittyleaks --find-anything

    git log --diff-filter=D --summary


    2. Одно золотое правило. Лайв система всегда должна иметь уникальные ключи, уникальные пароли пользователей, и в ней все по максимуму должно быть закрыто.

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

    Денис Колошко
    Поделиться публикацией

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

      –5

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


      Я обсудил проблему с коллегами и они мне подсказали, что не надо делать всё, что пишут в Интернетах. После того, как я убрал "закрыть всё по максимуму" работоспособность сервисов восстановилась.

        +1
        Вы, похоже, восприняли все буквально. В статье основной посыл — нельзя оставлять в коде в целом и в VCS в частности такие вещи, как сертификаты, пароли, ключи в любом виде и при любой (даже стремящейся к нулю) вероятности эксплуатации этих ключей.
          +11

          Я хотел показать, что чрезмерно обобщающие советы "делайте безопасно!" неконструктивны, потому что система должна быть не только безопасной, но и работать. Что выводит проблему безопасности из области тривиальной, в область почти недостижимого.

            +2
            Вы, похоже, восприняли все буквально.

            Э… IMHO к вам это тоже относится =)
            +8
            У вас теперь дыра в безопасности.
              +13
              «Ну хоть что-то у нас в безопасности!» (с)
              +1
              Есть 2 подхода к безопасности:
              1) Запретить всё, разрешить только нужное
              2) Разрешить всё, запретить только потенциально опасное.
              Безопаснее всего использовать первый подход. Да, этот подход сложнее в реализации, но профита от него намного больше.

              amarao рекомендую всё же помучиться и открыть только нужные порты.

              PS на клиентских проектах именно так и делаю.
                +2

                Но в рекомендации эксперта ничего не было про открытие чего-либо! Если я открою хоть один порт, система окажется в опасности, потому что у нас а админку basic auth с паролем "123"!


                /сарказм, если по первому комменту было непонятно.

                –2
                Не думал, что на Хабре нужно кому-то что-то разжевывать.

                Ваш сарказм неуместен.
                  +6

                  Мой сарказм направлен на то, что для очень сложной задачи вы даёте очень простое решение. А когда я показываю на неприменимость простого решения вы говорите "ну разумеется, надо делать сложное решение. Не думал, что нужно всем разжёвывать".


                  Классическое "за всё хорошее против всего плохого".

                    0
                    Прошу обратить внимание — я не автор статьи.

                    Кстати, полистал ваши публикации — многое показалось полезным, спасибо.
                0

                А как в реальном мире решается проблема доступа к лайв системе для диагностики проблем и обновления? Когда с одной стороны стоит CI/CD и прочая кроссфункиональность команды, а с другой — вполне резонная безопасность и закрытость от лишних людей.

                  +3

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


                  У каждого сотрудника должна быть индивидуальная учетка, которая блокируется в момент увольнения. Уровень доступа зависит от роли учетки. Администратор может всё, саппорт только читать логи, а технические учётки (backup, cd) только тот минимум, который необходим для создания бэкапа и выкладки нового кода.


                  Доступы к учетке для деплоя хранятся в настройках ci системы. Сам доступ к таким настройкам так же ограничен ролью "деплой менеджер".


                  Доступы к продуктовым внешним сервисам, используемым в коде (база, api), хранятся на продуктовых же серверах (файлики, переменные окружения, vault, whatever...).


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


                  Никаких сложностей в общем нет, главное включать мозги и почаще задавать вопросы "а что если?".


                  Что если админ уволится? Заблокируем учётку и доступ пропадет.


                  Что если нечистый на руку программист сольёт код налево? Ничего, так как пароли от прода есть только на проде.

                    0
                    А потом эта идиллия при определенных объемах компании начинает давать сбои.
                    Например на этапе создания архитектуры не учли возможность появления роли «посередине», например «вторая линия саппорта», которым прав админа много, а прав саппорта — мало. Но архитектура по каким-либо причинам не позволяет в определенных местах сделать что-то «по середине» (требуется серьезное перепиливание определенного слоя).
                    Сюда добавляется бюрократическо-организиацонная махина большой компании, по которой у саппорта не может быть второй учетки для повышения привилегий, или еще чего этакое.
                    И вот уже в отделе появляются «обходные пути».
                  –1

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

                    +2
                    Лучше доступы выдавать систематизировано, через специализированное ПО. Как только уволили сотрудника система автоматом все доступы прикрыла.
                    Идея в том, чтобы свести «человеческий фактор» к минимуму
                    +3
                    Так а что с "новым разработчиком" случилось-то? Жив хоть? Может его машина сбила…
                      0

                      Статья бы выиграла с примером как очистить репу от ключа или пароля полностью. Сорри, с телефона не смогу набросать пример.

                      0
                      Все что написано, здраво, но как всегда есть нюансы:
                      — в git-репозитариях лежат конфиги ansible, puppet, etc, т.е. от хранения ключей, паролей совсем избавиться как-бы не получается (да, есть vault, etc, но это снижение рисков, а не устранение проблемы)
                      — сотрудник работающий 2 дня, и сотрудник работающий 2 года, в общем случае у сотрудника всегда есть доступ к некоторой информации. и проблема отзыва всех прав ушедшего сотрудника — это проблема процесса увольнения. Технические тулы упрощают жизнь конечно, но без процесса это не живет.
                        0
                        — в git-репозитариях лежат конфиги ansible, puppet, etc, т.е. от хранения ключей, паролей совсем избавиться как-бы не получается (да, есть vault, etc, но это снижение рисков, а не устранение проблемы)

                        А кто мешает разделить код приложений от кода системы управления конфигурациями?
                        У меня (админа) нет доступа к коду приложений, а у разрабов нет доступа к коду salt.

                          0
                          Это понятно.
                          Но в сабже рекомендуют вообще не ложить ключи, пароли в git. Что в текущих условиях, уже не работает
                            0

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

                        0
                        всё секретное должно быть на энвайроменте и уж никак не в коде, ну а если чтото было в коде, а потом убралось то надо было сменить ключи везде, статью можно переименовать, в «Как потерять доступ если не соблюдаешь(не знаешь\игноришь) правила безопастности»

                        ну и в открытый доступ можно выкладывать только то в чём на 100% уверен, если же раньше были дыры, то наверно не надо эту историю выкладывать, а только текущее состояние, полагаю если поискать то можно ещё дырок найти которые недофикшеные или не правильно дофикшеные
                          0
                          Напомнило, как в 2016 году выкладывали исходники ICQ на гихаб. habr.com/ru/news/t/391669

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

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