Группа исследователей из Университета Северной Каролины (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)
Stas911
23.03.2019 16:44+2Для AWS есть pre-commit hook — нужно просто не лениться и поставить github.com/awslabs/git-secrets
SerJook
23.03.2019 21:06Если open-source приложение устанавливается на компьютер или другое устройство клиента, то какой смысл держать API key в тайне?
nochkin
24.03.2019 06:27+3Если там ключ, который должен знать только клиент и больше никто, то странно было бы выкладывать этот ключ для всего остального мира.
DaneSoul
24.03.2019 10:56+1а 81% так и не были удалены в течении срока наблюдения
Что не обязательно свидетельствует о их уязвимости — отсутствие реакции может быть обусловлено тем что:
1) Ключ изначально был не рабочим (отозван, просто случайный набор букв для примера)
2) Рабочий ключ поменяли после сообщения, а старый просто оставили в репозитории.
3) Это ключ для демо-доступа, который и должен быть всем доступен
Gamliel_Fishkin
24.03.2019 21:50Меня удивляют люди, публикующие свой приватный ключ.
Недавно я объяснил то, что должно быть понятно без пояснений:Полагаю, вам понятен смысл слов «приватный разговор» и «публичное заявление»: содержание приватного разговора не должно стать известно посторонним, содержание же публичного заявления должно стать известно широкому кругу людей. Разница между приватным ключом и публичным ключом такая же: приватный ключ следует спрятать и не показывать никому, а публичный ключ можно опубликовать (эти слова не случайно однокоренные).
Как можно не понимать столь самоочевидные вещи?!
Protos
25.03.2019 03:34+1Уверен вы иногда вслух произносите конфиденциальную информацию, подразумевая что рядом стоящие ничего не понимают о чём идёт речь
nochkin
25.03.2019 18:23Меня удивляет то, что это удивляет других. Ведь теория всегда ясна и понятна. На то она и теория.
Но есть ещё практика. И там есть такая штука, которая называется «человеческий фактор», «человеческая ошибка» и банальное «забыл».
Уверен, что многие ключи вышли «в свет» именно по этой причине. Например, если бы этот автор в момент публикации увидел вопрос «are you sure you want to publish your private key?», то он с уверенностью ответил бы отказом.
vortupin
25.03.2019 09:05+1Я как-то лично пытался донести до менеджмента одной, довольно крупной компании, что их code signing certificate с паролем (прямым текстом!) в подписывающим бинарники скрипте, не стоит не то, чтобы держать в public access repository, но даже и в private company repos (где любой сотрудник, даже контрактор на short term, имел к ним доступ). Не удалось…
P.S. Самое неприятное то, что их бинарники, подписанные этим сертификатом, работают практически на каждом Windows PC :(Gamliel_Fishkin
25.03.2019 20:43Почему не называете компанию? Ни один человек не может знать всё, и даже знающий может ненамеренно ошибиться, но в описанной Вами ситуации имеет место воинствующее невежество.
vortupin
25.03.2019 20:55Потому, что a) NDA b) возможно, они уже исправили ситуацию, не хочу клеветать (контракт закончился три года назад).
Gamliel_Fishkin
25.03.2019 21:06Да, с NDA не поспоришь. Будем надеяться, что исправили (грустно, если нет).
Busla
Давайте зайдём с другой стороны: а что должно быть вместо реального токена, ключа и т.п.? — всё равно в тестах, описании, комментах будет тестовый, отозванный токен, либо его имитация вида ABCD-1234-EF56.
zetroot
Выносить ключи и токены из кода в конфиги, которые подкладывать вручную в bin.
В репозитории конфиг держать без чувствительной информации, заменив токены пустыми строками, например.
andToxa
Всегда было интересно, а кто где хранит боевые ключи и токены до их подкладывания вручную? Есть какие-то общие решения или каждый изобретает свой велосипед?
barkalov
Кажется, нам нужен токен-репозиторий. Нужно только решить, где хранить ключи от него.
dartraiden
В нашем проекте они хранятся в приватном репозитории. В коде можно встретить такое:
Соответственно, если кто-то посторонний хочет собирать сам, он должен создать у себя локально нужную структуру каталогов и положить токен в secret_key.h:
zim32
Можно маунтить директорию с шифрованием. Ключи один раз положил потом просто маунт
rework
Мы обычно их Environment variable выносим.
andToxa
Вопрос был про хранение до выноса в те же environment variables. Про обмен между членами команды.
aml
Если приложение работает в Kubernetes, то можно использовать средства хранения ключей, предоставляемые платформой — Kubernetes Secrets. При этом в репозиториях ключи не хранятся от слова совсем, и один и тот же код, запускаясь в разных средах (dev, staging, prod — кто во что горазд), будет видеть разные ключи в специальном каталоге, видимом из их контейнера.
Если нужно всё по-серьёзному, с аудитом доступа к ключам, то можно использовать Google Cloud Key Management Service. Тогда собственно секреты хранятся на серверах клиентов (Google их даже не знает), но зашифрованными ключами, хранящимися в Google. Такое вот комбо.
missingdays
Мы vault используем
missingdays
Мы vault используем