Они просканировали GitHub

    Группа исследователей из Университета Северной Каролины (North Carolina State University, NCSU) провели исследование сервиса для хостинга IT-проектов и их совместной разработки GitHub. Специалисты установили, что свыше 100 тыс. GitHub-репозиториев содержат API-ключи, токены и криптографические ключи.



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


    «Благодаря» таким утечкам уже произошло несколько крупных инцидентов с персональными данными (Uber, DJI, DXC Technologies и др.).


    В период с 31 октября 2017 года по 20 апреля 2018 года, исследователи из NCSU просканировали 4,394,476 файлов в 681,784 репозиториях через поисковый API самого GitHub и 2,312,763,353 файла в 3,374,973 репозиториях, предварительно собранных в базе данных Google BigQuery.


    В процессе сканирования эксперты искали строки, которые бы попадали под шаблоны API-ключей (Stripe, MailChimp, YouTube и т.п.), токенов (Amazon MWS, PayPal Braintree, Amazon AWS и т.п.) или криптографических ключей (RSA, PGP и т.п).



    Всего эксперты обнаружили порядка 575,476 токенов, API- и криптографических ключей, причем 201,642 из них были уникальными. 93,58% находок были связаны с аккаунтами, у которых один владелец.



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


    В ходе исследования был выявлен интересный тренд — если владельцы данных обнаруживали утечку, то 19% отслеживаемых экспертами данных удалялись (как «удалялись», см. ниже) в течение 16 дней (из них 12% — в течении первого дня), а 81% так и не были удалены в течении срока наблюдения.


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


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


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

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

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

      +4
      Давайте зайдём с другой стороны: а что должно быть вместо реального токена, ключа и т.п.? — всё равно в тестах, описании, комментах будет тестовый, отозванный токен, либо его имитация вида ABCD-1234-EF56.
        +3

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

          +2
          Всегда было интересно, а кто где хранит боевые ключи и токены до их подкладывания вручную? Есть какие-то общие решения или каждый изобретает свой велосипед?
            +4
            Кажется, нам нужен токен-репозиторий. Нужно только решить, где хранить ключи от него.
              +3
              В нашем проекте они хранятся в приватном репозитории. В коде можно встретить такое:
              #include "../../../miranda-private-keys/Dropbox/secret_key.h"

              data.AppendFormat("&client_id=%s&client_secret=%s", DROPBOX_APP_KEY, DROPBOX_API_SECRET);

              Соответственно, если кто-то посторонний хочет собирать сам, он должен создать у себя локально нужную структуру каталогов и положить токен в secret_key.h:
              #define DROPBOX_API_SECRET «abcdefghijklm»
                +1

                Можно маунтить директорию с шифрованием. Ключи один раз положил потом просто маунт

                  0
                  Мы обычно их Environment variable выносим.
                    0

                    Вопрос был про хранение до выноса в те же environment variables. Про обмен между членами команды.

                    0
                    Если приложение работает в Kubernetes, то можно использовать средства хранения ключей, предоставляемые платформой — Kubernetes Secrets. При этом в репозиториях ключи не хранятся от слова совсем, и один и тот же код, запускаясь в разных средах (dev, staging, prod — кто во что горазд), будет видеть разные ключи в специальном каталоге, видимом из их контейнера.

                    Если нужно всё по-серьёзному, с аудитом доступа к ключам, то можно использовать Google Cloud Key Management Service. Тогда собственно секреты хранятся на серверах клиентов (Google их даже не знает), но зашифрованными ключами, хранящимися в Google. Такое вот комбо.
                      0
                      Мы vault используем
                      0
                      Мы vault используем
                    +2
                    Для AWS есть pre-commit hook — нужно просто не лениться и поставить github.com/awslabs/git-secrets
                      0
                      Если open-source приложение устанавливается на компьютер или другое устройство клиента, то какой смысл держать API key в тайне?
                        +3
                        Если там ключ, который должен знать только клиент и больше никто, то странно было бы выкладывать этот ключ для всего остального мира.
                        +3
                        а 81% так и не были удалены в течении срока наблюдения
                        Что не обязательно свидетельствует о их уязвимости — отсутствие реакции может быть обусловлено тем что:
                        1) Ключ изначально был не рабочим (отозван, просто случайный набор букв для примера)
                        2) Рабочий ключ поменяли после сообщения, а старый просто оставили в репозитории.
                        3) Это ключ для демо-доступа, который и должен быть всем доступен
                          0
                          Меня удивляют люди, публикующие свой приватный ключ.

                          Недавно я объяснил то, что должно быть понятно без пояснений:
                          Полагаю, вам понятен смысл слов «приватный разговор» и «публичное заявление»: содержание приватного разговора не должно стать известно посторонним, содержание же публичного заявления должно стать известно широкому кругу людей. Разница между приватным ключом и публичным ключом такая же: приватный ключ следует спрятать и не показывать никому, а публичный ключ можно опубликовать (эти слова не случайно однокоренные).

                          Как можно не понимать столь самоочевидные вещи?!
                            +1
                            Уверен вы иногда вслух произносите конфиденциальную информацию, подразумевая что рядом стоящие ничего не понимают о чём идёт речь
                              0
                              Меня удивляет то, что это удивляет других. Ведь теория всегда ясна и понятна. На то она и теория.
                              Но есть ещё практика. И там есть такая штука, которая называется «человеческий фактор», «человеческая ошибка» и банальное «забыл».
                              Уверен, что многие ключи вышли «в свет» именно по этой причине. Например, если бы этот автор в момент публикации увидел вопрос «are you sure you want to publish your private key?», то он с уверенностью ответил бы отказом.
                              +1
                              Я как-то лично пытался донести до менеджмента одной, довольно крупной компании, что их code signing certificate с паролем (прямым текстом!) в подписывающим бинарники скрипте, не стоит не то, чтобы держать в public access repository, но даже и в private company repos (где любой сотрудник, даже контрактор на short term, имел к ним доступ). Не удалось…

                              P.S. Самое неприятное то, что их бинарники, подписанные этим сертификатом, работают практически на каждом Windows PC :(
                                0
                                Почему не называете компанию? Ни один человек не может знать всё, и даже знающий может ненамеренно ошибиться, но в описанной Вами ситуации имеет место воинствующее невежество.
                                  0
                                  Потому, что a) NDA b) возможно, они уже исправили ситуацию, не хочу клеветать (контракт закончился три года назад).
                                    0
                                    Да, с NDA не поспоришь. Будем надеяться, что исправили (грустно, если нет).

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

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