The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Анализ утечек конфиденциальных данных через репозитории на GitHub

22.03.2019 13:39

Группа исследователей из Университета штата Северная Каролина опубликовала результаты (PDF) анализа случайного попадания конфиденциальных данных в публично доступные репозитории на GitHub. Например, из-за недосмотра в репозитории временами попадают оставленные в рабочем каталоге или вшитые в код ключи доступа к облачным сервисам, пароли к СУБД, ключи к VPN и сертификаты для цифровых подписей.

В ходе проделанной работы был исследован как статических срез, включающий 13% репозиториев на GitHub (около 4 млн репозиториев), так и проанализирована динамика появления новых утечек, для чего на протяжении 6 месяцев отслеживались все новые коммиты на GitHub. Для анализа использовались срезы содержимого GitHub, предоставляемые через хранилище BigQuery, а также запросы через Google Search API. Проверка охватывала только типовые форматы закрытых ключей и токены доступа к наиболее популярным платформам, таким как Amazon Web Services (AWS), Azure, Twitter, Google Cloud, Slack, Stripe, Facebook, Mailchimp, MailGun, Twilio, Square, Braintree и Picatic.

В результате было выявлено более 100 тысяч репозиториев, содержащих токены доступа к API или криптографические ключи. Всего было получено 575456 ключей и токенов, из которых 201642 уникальны. Большая часть утечек связана с размещением токенов доступа к Google API и AWS, а также случайно попавшими в репозиторий закрытыми ключами. 93.58% всех утечек выявлены в репозиториях, принадлежащих одному разработчику, а не совместным проектам.

Непрерывный мониторинг показал, что ежедневно на GitHub попадает несколько тысяч новых утечек конфиденциальных данных. 6% из выявленных в ходе динамического мониторинга утечек были сразу замечены разработчиками и удалены в течение часа. 12% забытых ключей оставались в открытом доступе не больше 24 часов, а 19% до 16 дней. 81% всех утечек остались незамеченными и продолжали оставаться в репозиториях спустя 16 дней.

Из наиболее заметных утечек отмечается попадание в репозиторий учётных данных к окружениям AWS, используемым одним из крупных сайтов, которым пользуются миллионы учащихся колледжей в США, а также к AWS-окружению сайта государственного учреждения одной из стран Восточной Европы. Кроме того, выявлено 564 ключа к Google API, которые использовались для копирования роликов YouTube на один из сайтов обмена видео в обход ограничений YouTube. В размещённых в репозиториях файлах конфигурации OpenVPN было выявлено 7280 оставленных RSA-ключей, позволяющих получить доступ к тысячам различных приватных сетей.

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

  1. Главная ссылка к новости (https://www.zdnet.com/article/...)
  2. OpenNews: Представлен Gitleaks 1.0, инструмент для аудита git-репозиториев
  3. OpenNews: Невозможность удаления данных, по ошибке опубликованных на GitHub
  4. OpenNews: Интернет-регистратор APNIC по ошибке опубликовал хэши паролей Whois-сервиса
  5. OpenNews: GitHub и Twitter по ошибке сохраняли открытые пароли в логе
  6. OpenNews: Производитель дронов DJI по ошибке опубликовал закрытые ключи и пароли
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/50374-github
Ключевые слова: github
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (36) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Тибетский лис (ok), 14:12, 22/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А каким именно образом закрытые ключи могут попасть в репозиторий?
     
     
  • 2.4, нах (?), 14:44, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +23 +/
    git add . && git push
    не понимаю, в чем у вас проблема - всегда так делаю!
     
     
  • 3.17, Аноним (17), 16:57, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Так точно никогда не утечет, коммита же небыло, хитрец
     
     
  • 4.25, нах (?), 21:46, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • –3 +/
    коммит сделается в параллельной сессии, или вообще другим чуваком параллельно зашедшим.
    (кстати, регулярно на эти грабли наступаю, ну, правда, ключей от EC пока не коммитил, но ненужно-add'ы были)

    btw, я правильно понимаю, что git commit --amend не исправляет такую ситуацию, а усугубляет ее?

     
     
  • 5.32, Ordu (ok), 13:58, 23/03/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > ненужно-add'ы были

    От них легко избавиться, если следить за созданием красивой истории. Все рабочие коммиты должны идти в рабочую же ветку. Или в рабочие ветки. Которые создаются при помощи git checkout -B any-stupid-branch-name.

    Когда же ты пришёл к выводу, что пора что-то втолкнуть в апстрим, то возвращаешься на тот коммит поверх которого хочешь пушить, создаёшь ветку, берёшь git rebase, превращаешь результаты своей дневной работы (или недельной -- это как удобнее) в последовательность осмысленных коммитов, вычищая из них все метания от процесса проб и ошибок, собирая воедино основные коммиты и второстепенные, которые фиксят идентацию, добавляют комментарии или исправляют в них грамматику. Каждый из этих осмысленных коммитов ты снабжаешь осмысленным сопровождающим комментарием.

    Это _очень_ полезно делать, потому что таким образом ты прокручиваешь в голове всё сделанное, и перепроверяешь себя -- не было ли что-то забыто. Помимо этого, оно избавляет тебя от случайно закоммиченных излишков. Ну и да, ты получаешь в результате историю, с которой потом можно работать, а не беспорядочный поток слабосвязанных изменений.

    И вот _после_ этого, ты пушишь эту (и только эту) ветку с красивой историей в апстрим. Я при этом проталкиваю в специально создаваемую для этого ветку в апстриме, чтобы мерг потом сделать на стороне github'а. Если ты один в апстрим пишешь это по идее не должно влиять, но я параноик (потому что я знаю, что мои шаловливые ручки могут сломать всё, что угодно), и я лучше лишних телодвижений сделаю, с тем чтобы потом ещё pull-request на github'е создать и смержить, чем буду рисковать удалением каких-нибудь коммитов.

     
     
  • 6.35, нах (?), 16:00, 23/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > От них легко избавиться, если следить за созданием красивой истории.

    ну то есть никогда ничего не push'ить в апстрим просто так.
    если его считать просто архивом на память - то можно и так, конечно.

    Можно ли работать с выдуманной историей вместо настоящей - я вот хз, потому что изменения делались тобой при одном состоянии репо, а подмененная история показывает другое. Но скорее всего эта история никому и никогда не потребуется, ни настоящая, ни поддельная. А для blame она не важна.

     
     
  • 7.37, Ordu (ok), 16:38, 23/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Задача истории -- документировать изменения Зачем нужен blame, как ты думаешь ... большой текст свёрнут, показать
     
  • 6.38, universite (ok), 21:12, 23/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    А можно по командам разложить и со скрина, если в IDE делаете?
     
     
  • 7.40, Ordu (ok), 01:06, 24/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > А можно по командам разложить и со скрина, если в IDE делаете?

    Как пользоваться rebase? https://mtyurt.net/post/git-using-advanced-rebase-features-for-a-clean-reposit

    А вот тут можно попрактиковаться: https://github.com/salemove/gojo

     
  • 2.33, Аноним (33), 14:43, 23/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > А каким именно образом закрытые ключи могут попасть в репозиторий?

    Такая культурка разработки. Как на работке коммитят пароли в гит, так и дома - тяп ляп халтурка.

    Привычка-с. ))

     

  • 1.2, Аноним (2), 14:20, 22/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Есть даже боты, которые рыщут по гитхабу в поисках всяких клбчей.
    Читал статью про то, как у кого-то 10000 инстансов на амазоне арендовали и майнили из-за оставленного ключа на гитхабе.
     
     
  • 2.5, нах (?), 14:45, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > Есть даже боты, которые рыщут по гитхабу в поисках всяких клбчей.

    где скачать бесплатно-без-смс?

     
     
  • 3.6, istepan (ok), 15:02, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +6 +/
    На гитхабе
     
  • 3.7, Аноним (7), 15:09, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Большая часть людей занимающаяся этой проблемой работает в Apple, Google, Intel, Cyclane, ESET. А дальше чистый NDA. Ничего нельзя рассказывать, и даже опенсорсить. Сотрудники этих контор тайно делают комиты (не со своих учеток, понятно) в https://github.com/*****, например. Но пруфов не будет. Остальные кто занимаются этой темой, продают свои наработки в Black 0day market. Их называть тоже не буду, кто надо тот знает этих людей пофамильно.  // Ну ты понел.
     
     
  • 4.9, нах (?), 15:13, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    блин, просили ж бесплатно. У этих хорьков дорого, майнингом не окупится :-(
     
  • 2.28, Dmitry77 (ok), 09:49, 23/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    мы как то случайно закомитили приватный ключ от эфириум кошелька. украли все "деньги" выделенные на тестирование за 15 минуть.
     
     
  • 3.34, имя (?), 15:07, 23/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    т.е. вы вели разработку приложения для работы с криптовалютой не в приватном репозитории? ССЗБ
     
     
  • 4.36, нах (?), 16:02, 23/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > т.е. вы вели разработку приложения для работы с криптовалютой не в приватном репозитории

    а почему она должна вестись за закрытыми дверями и посреди минного поля?

     

  • 1.10, Аноним (10), 15:18, 22/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Это случайно не связано с покупкой гитхаба мелкомягкими?
     
     
  • 2.11, жека воробьев (?), 15:29, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +12 +/
    Наличие безалаберных и невнимательных людей? Нет, не связано
     
     
  • 3.13, Аноним (13), 16:05, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Проблема как всегда в плохом дизайне проектов.
     
  • 3.43, анон (?), 00:14, 25/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    сами себе противоречите, в мс только такие и работают
     
  • 2.12, Andrey Mitrofanov (?), 15:33, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > Это случайно не связано с покупкой гитхаба мелкомягкими?

    Конечно связано, не сомневайтесь!  У Майкарософт Рисёурч новая игрушка, а у опенета новые новости от "британских" учёных.

     
  • 2.14, Аноним84701 (ok), 16:25, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Это случайно не связано с покупкой гитхаба мелкомягкими?

    Еще в древне-мохнатые, до-гитхабные годы  те же шарващики "забывали" свои ключи RSA, с помощью которых проверялась лицензия (а у особо продвинутых даже расшифровывалась часть кода) в общественном доступе (т.е. в своей программе).  Это помимо использования 512 битных ключей, которые ломались супербыстрым атлоном (почти 1 ГГц!) только влет.

    Учитывая, что тогда (как любят писать некоторые анонимные комментаторы опеннета) "и солнце ярче светило и компутерщики скилнутее сегодняшних смузихлебов были" -- вряд ли оно связано с покупкой гитхаба мелкомягкими ;)

     
     
  • 3.27, Аноним (7), 06:44, 23/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >> Это случайно не связано с покупкой гитхаба мелкомягкими?
    > Еще в древне-мохнатые, до-гитхабные годы  те же шарващики "забывали" свои ключи
    > RSA, с помощью которых проверялась лицензия (а у особо продвинутых даже
    > расшифровывалась часть кода) в общественном доступе (т.е. в своей программе).  
    > Это помимо использования 512 битных ключей, которые ломались супербыстрым атлоном (почти
    > 1 ГГц!) только влет.

    Вообще-то факторизовали ключи и подлиннее (см. файлик "наследие DAMN") из-за того что автор популярного протектора реализовал PRNG на функции rand().

     
  • 2.20, Аноним (20), 18:39, 22/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    >Это случайно не связано с покупкой гитхаба мелкомягкими?

    Ты удивлён? Если что, то в сервисе поддержки Майкрософт сидят гастарбайтеры из Юго-Восточной Азии.

     
     
  • 3.29, проклятый гастарбайтер из ЮВА (?), 12:52, 23/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    ну да, это ж мы вас заставляли пушить в паблик-репо что ни попадя.

    или, по вашему, мы должны круглые сутки следить, чтоб вы чего не накоммитили, и немедля...что, кстати, делать-то?

     

  • 1.16, Аноним (16), 16:33, 22/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    А они потом проверяли все найденные ключи на валидность? Или там половина плейсхолдеров типа abcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdef?
     
  • 1.18, robot228 (?), 17:22, 22/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Часто ключи парсить приходится в гугле)
    Но такие вот исследователя конечно портят всё)
     
     
  • 2.31, пох (?), 12:58, 23/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    чем портят-то, они ж ничего не удалили и даже не спугнули глупых рыбок?

    Или ты имеешь в виду - что ни ключ, то уже кто-то спер и сам майнит, а ты вечно не успеваешь?

     

  • 1.22, Аноним (22), 19:47, 22/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    >93.58% всех утечек выявлены в репозиториях, принадлежащих одному лицу, а не совместным проектам.

    Этим лицом был Альберт Эйнштейн?

     
  • 1.26, abi (?), 22:14, 22/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Интересно, сколько из 19% ключей, который были убраны продолжают действовать? Ну, "я же убрал быстро, никто и не увидит"
     
     
  • 2.30, пох (?), 12:54, 23/03/2019 [^] [^^] [^^^] [ответить]  
  • +/
    интересней другое - сколько ключей "убраны" git rm'ом - и при этом продолжают действовать.

    и анализировали ли "исследователи" мертвые ветки без имен и тегов.


     

  • 1.39, InuYasha (?), 22:37, 23/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А что не выложили-то? :)
     
  • 1.41, Honeypot (?), 07:11, 24/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Они уверены что конф. данные не были специально там размещены особенно для перехвата через VPN?
     
  • 1.42, Anon_Erohin (?), 15:09, 24/03/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Засилье джуниоров формошлепов на гитхабе после покупки мелкомягкими, которые по незнанию выкладывают корпоративные ключи... Вот что значит уменьшить порог вхождения и упрощать инструменты разработки.
    Нормальные разработчики и кампании ставят свои инстансы гита, на крайний случай - гитлаб.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру