Они просканировали 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 данных.


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

    Ads
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More

    Comments 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?», то он с уверенностью ответил бы отказом.
                            • UFO just landed and posted this here
                                0
                                Почему не называете компанию? Ни один человек не может знать всё, и даже знающий может ненамеренно ошибиться, но в описанной Вами ситуации имеет место воинствующее невежество.
                                • UFO just landed and posted this here
                                    0
                                    Да, с NDA не поспоришь. Будем надеяться, что исправили (грустно, если нет).

                              Only users with full accounts can post comments. Log in, please.