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



Группа исследователей из Университета Северной Каролины (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):

  1. Busla
    /#19929788 / +1

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

    • zetroot
      /#19929922 / +1

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

      • andToxa
        /#19930380 / +1

        Всегда было интересно, а кто где хранит боевые ключи и токены до их подкладывания вручную? Есть какие-то общие решения или каждый изобретает свой велосипед?

        • barkalov
          /#19930436 / +1

          Кажется, нам нужен токен-репозиторий. Нужно только решить, где хранить ключи от него.

        • dartraiden
          /#19930970 / +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»

        • zim32
          /#19931618

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

        • rework
          /#19933396

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

          • andToxa
            /#19933476

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

        • aml
          /#19933670

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

          Если нужно всё по-серьёзному, с аудитом доступа к ключам, то можно использовать Google Cloud Key Management Service. Тогда собственно секреты хранятся на серверах клиентов (Google их даже не знает), но зашифрованными ключами, хранящимися в Google. Такое вот комбо.

  2. Stas911
    /#19930822 / +2

    Для AWS есть pre-commit hook — нужно просто не лениться и поставить github.com/awslabs/git-secrets

  3. SerJook
    /#19932078

    Если open-source приложение устанавливается на компьютер или другое устройство клиента, то какой смысл держать API key в тайне?

    • nochkin
      /#19933142 / +3

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

  4. DaneSoul
    /#19933490 / +1

    а 81% так и не были удалены в течении срока наблюдения
    Что не обязательно свидетельствует о их уязвимости — отсутствие реакции может быть обусловлено тем что:
    1) Ключ изначально был не рабочим (отозван, просто случайный набор букв для примера)
    2) Рабочий ключ поменяли после сообщения, а старый просто оставили в репозитории.
    3) Это ключ для демо-доступа, который и должен быть всем доступен

  5. Gamliel_Fishkin
    /#19935508

    Меня удивляют люди, публикующие свой приватный ключ.

    Недавно я объяснил то, что должно быть понятно без пояснений:

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

    Как можно не понимать столь самоочевидные вещи?!

    • Protos
      /#19936274 / +1

      Уверен вы иногда вслух произносите конфиденциальную информацию, подразумевая что рядом стоящие ничего не понимают о чём идёт речь

    • nochkin
      /#19940034

      Меня удивляет то, что это удивляет других. Ведь теория всегда ясна и понятна. На то она и теория.
      Но есть ещё практика. И там есть такая штука, которая называется «человеческий фактор», «человеческая ошибка» и банальное «забыл».
      Уверен, что многие ключи вышли «в свет» именно по этой причине. Например, если бы этот автор в момент публикации увидел вопрос «are you sure you want to publish your private key?», то он с уверенностью ответил бы отказом.

  6. vortupin
    /#19936738 / +1

    Я как-то лично пытался донести до менеджмента одной, довольно крупной компании, что их code signing certificate с паролем (прямым текстом!) в подписывающим бинарники скрипте, не стоит не то, чтобы держать в public access repository, но даже и в private company repos (где любой сотрудник, даже контрактор на short term, имел к ним доступ). Не удалось…

    P.S. Самое неприятное то, что их бинарники, подписанные этим сертификатом, работают практически на каждом Windows PC :(

    • Gamliel_Fishkin
      /#19940708

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

      • vortupin
        /#19940766

        Потому, что a) NDA b) возможно, они уже исправили ситуацию, не хочу клеветать (контракт закончился три года назад).

        • Gamliel_Fishkin
          /#19940820

          Да, с NDA не поспоришь. Будем надеяться, что исправили (грустно, если нет).