Группа исследователей из Университета штата Северная Каролина
опубликовала (https://www.ndss-symposium.org/ndss-paper/how-bad-can-it-git.../) результаты (PDF (https://www.ndss-symposium.org/wp-content/uploads/2019/02/nd...)) анализа случайного попадания конфиденциальных данных в публично доступные репозитории на GitHub. Например, из-за недосмотра в репозитории временами попадают оставленные в рабочем каталоге или вшитые в код ключи доступа (https://www.opennet.me/opennews/art.shtml?num=41370) к облачным сервисам, пароли к СУБД, ключи к VPN и сертификаты (https://www.opennet.me/opennews/art.shtml?num=47584) для цифровых подписей.
В ходе проделанной работы был исследован как статических срез, включающий 13% репозиториев на GitHub (около 4 млн репозиториев), так и проанализирована динамика появления новых утечек, для чего на протяжении 6 месяцев отслеживались все новые коммиты на GitHub. Для анализа использовались срезы содержимого GitHub, предоставляемые (https://medium.com/google-cloud/github-on-bigquery-analyze-a...) через хранилище BigQuery (https://github.com/fhoffa/analyzing_github/), а также запросы через 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, разработчики данного сервиса запустили (https://help.github.com/en/articles/about-token-scanning) в тестовом режиме систему автоматизированного сканирования в репозиториях типовых параметров подключения к внешним API. При выявлении утечек сервис-провайдерам направляются уведомления для отзыва скомпрометированных токенов.
URL: https://www.zdnet.com/article/over-100000-github-repos-have-.../
Новость: https://www.opennet.me/opennews/art.shtml?num=50374
А каким именно образом закрытые ключи могут попасть в репозиторий?
git add . && git push
не понимаю, в чем у вас проблема - всегда так делаю!
Так точно никогда не утечет, коммита же небыло, хитрец
коммит сделается в параллельной сессии, или вообще другим чуваком параллельно зашедшим.
(кстати, регулярно на эти грабли наступаю, ну, правда, ключей от EC пока не коммитил, но ненужно-add'ы были)btw, я правильно понимаю, что git commit --amend не исправляет такую ситуацию, а усугубляет ее?
> ненужно-add'ы былиОт них легко избавиться, если следить за созданием красивой истории. Все рабочие коммиты должны идти в рабочую же ветку. Или в рабочие ветки. Которые создаются при помощи git checkout -B any-stupid-branch-name.
Когда же ты пришёл к выводу, что пора что-то втолкнуть в апстрим, то возвращаешься на тот коммит поверх которого хочешь пушить, создаёшь ветку, берёшь git rebase, превращаешь результаты своей дневной работы (или недельной -- это как удобнее) в последовательность осмысленных коммитов, вычищая из них все метания от процесса проб и ошибок, собирая воедино основные коммиты и второстепенные, которые фиксят идентацию, добавляют комментарии или исправляют в них грамматику. Каждый из этих осмысленных коммитов ты снабжаешь осмысленным сопровождающим комментарием.
Это _очень_ полезно делать, потому что таким образом ты прокручиваешь в голове всё сделанное, и перепроверяешь себя -- не было ли что-то забыто. Помимо этого, оно избавляет тебя от случайно закоммиченных излишков. Ну и да, ты получаешь в результате историю, с которой потом можно работать, а не беспорядочный поток слабосвязанных изменений.
И вот _после_ этого, ты пушишь эту (и только эту) ветку с красивой историей в апстрим. Я при этом проталкиваю в специально создаваемую для этого ветку в апстриме, чтобы мерг потом сделать на стороне github'а. Если ты один в апстрим пишешь это по идее не должно влиять, но я параноик (потому что я знаю, что мои шаловливые ручки могут сломать всё, что угодно), и я лучше лишних телодвижений сделаю, с тем чтобы потом ещё pull-request на github'е создать и смержить, чем буду рисковать удалением каких-нибудь коммитов.
> От них легко избавиться, если следить за созданием красивой истории.ну то есть никогда ничего не push'ить в апстрим просто так.
если его считать просто архивом на память - то можно и так, конечно.Можно ли работать с выдуманной историей вместо настоящей - я вот хз, потому что изменения делались тобой при одном состоянии репо, а подмененная история показывает другое. Но скорее всего эта история никому и никогда не потребуется, ни настоящая, ни поддельная. А для blame она не важна.
>> От них легко избавиться, если следить за созданием красивой истории.
> ну то есть никогда ничего не push'ить в апстрим просто так.
> если его считать просто архивом на память - то можно и так,
> конечно.
> Можно ли работать с выдуманной историей вместо настоящей - я вот хз,
> потому что изменения делались тобой при одном состоянии репо, а подмененная
> история показывает другое.Задача истории -- документировать изменения.
> Но скорее всего эта история никому и никогда
> не потребуется, ни настоящая, ни поддельная. А для blame она не
> важна.Зачем нужен blame, как ты думаешь?
Мне кажется, что некоторые считают, что blame нужен для того, чтобы найти виноватого и надрать ему задницу. Так вот, это ложное суждение. Это бюрократии он будет нужен для этого: она в случае любого косяка первым делом ищет стрелочников. Тебе же blame будет нужен для того, чтобы выяснить зачем нужна та или иная строчка кода. Зачем эта строчка кода была добавлена, были ли какая-то специальная причина, и если была, то остаётся ли она причиной и по сей день. Если нет причины для того, чтобы эта строчка кода была именно такой, какая она есть, то у тебя развязаны руки, чтобы переписать её так, как это будет удобно тебе. И ради этой цели ты будешь использовать blame для того, чтобы посмотреть контекст в котором строчка была добавлена в код или в котором она изменялась, ты почитаешь комментарии сопровождающие эти коммиты, с тем чтобы понять их. Если у тебя останутся сомнения, то ты свяжешься с автором коммита, чтобы понять лучше. Но если дело дошло до того, что тебе надо связаться с автором коммита, то скорее всего это говнокоммиты, которые недостаточно хорошо документированы, которые плохо описывают изменения, которые недостаточно хорошо структурированы и плохо разбиты на отдельные патчи.
И в этом случае, гораздо удобнее, если история изменений упорядочена и _вдумчиво_ документирована. В процессе многих изменений, с поиском не уродского способа решить проблему, тебе не до того, чтобы вдумчиво документировать каждое изменение, особенно если ты подозреваешь, что это изменение через полчаса отправится в мусор. Вот ты сейчас попробуешь, что из этого выйдет, через полчаса этот эксперимент закончится, и вся ветка пойдёт в расход. Некоторые из таких попыток выживают. Но документировать каждое такое изменение перед тем, как ты его сделаешь -- это убийственно, и скажется на производительности катастрофически. А если ты пишешь документацию задним числом, когда рефлексируешь над проделанным, то ты действительно можешь в комментарии к каждому коммиту писать о том, что ты делаешь и почему, не занимаясь ответами на вопрос как ты делаешь, потому что на вопрос "как" отвечают diff'ы.
А можно по командам разложить и со скрина, если в IDE делаете?
> А можно по командам разложить и со скрина, если в IDE делаете?Как пользоваться rebase? https://mtyurt.net/post/git-using-advanced-rebase-features-f...
А вот тут можно попрактиковаться: https://github.com/salemove/gojo
> А каким именно образом закрытые ключи могут попасть в репозиторий?Такая культурка разработки. Как на работке коммитят пароли в гит, так и дома - тяп ляп халтурка.
Привычка-с. ))
Есть даже боты, которые рыщут по гитхабу в поисках всяких клбчей.
Читал статью про то, как у кого-то 10000 инстансов на амазоне арендовали и майнили из-за оставленного ключа на гитхабе.
> Есть даже боты, которые рыщут по гитхабу в поисках всяких клбчей.где скачать бесплатно-без-смс?
На гитхабе
Большая часть людей занимающаяся этой проблемой работает в Apple, Google, Intel, Cyclane, ESET. А дальше чистый NDA. Ничего нельзя рассказывать, и даже опенсорсить. Сотрудники этих контор тайно делают комиты (не со своих учеток, понятно) в https://github.com/*****, например. Но пруфов не будет. Остальные кто занимаются этой темой, продают свои наработки в Black 0day market. Их называть тоже не буду, кто надо тот знает этих людей пофамильно. // Ну ты понел.
блин, просили ж бесплатно. У этих хорьков дорого, майнингом не окупится :-(
мы как то случайно закомитили приватный ключ от эфириум кошелька. украли все "деньги" выделенные на тестирование за 15 минуть.
т.е. вы вели разработку приложения для работы с криптовалютой не в приватном репозитории? ССЗБ
> т.е. вы вели разработку приложения для работы с криптовалютой не в приватном репозиторииа почему она должна вестись за закрытыми дверями и посреди минного поля?
Это случайно не связано с покупкой гитхаба мелкомягкими?
Наличие безалаберных и невнимательных людей? Нет, не связано
Проблема как всегда в плохом дизайне проектов.
сами себе противоречите, в мс только такие и работают
> Это случайно не связано с покупкой гитхаба мелкомягкими?Конечно связано, не сомневайтесь! У Майкарософт Рисёурч новая игрушка, а у опенета новые новости от "британских" учёных.
> Это случайно не связано с покупкой гитхаба мелкомягкими?Еще в древне-мохнатые, до-гитхабные годы те же шарващики "забывали" свои ключи RSA, с помощью которых проверялась лицензия (а у особо продвинутых даже расшифровывалась часть кода) в общественном доступе (т.е. в своей программе). Это помимо использования 512 битных ключей, которые ломались супербыстрым атлоном (почти 1 ГГц!) только влет.
Учитывая, что тогда (как любят писать некоторые анонимные комментаторы опеннета) "и солнце ярче светило и компутерщики скилнутее сегодняшних смузихлебов были" -- вряд ли оно связано с покупкой гитхаба мелкомягкими ;)
>> Это случайно не связано с покупкой гитхаба мелкомягкими?
> Еще в древне-мохнатые, до-гитхабные годы те же шарващики "забывали" свои ключи
> RSA, с помощью которых проверялась лицензия (а у особо продвинутых даже
> расшифровывалась часть кода) в общественном доступе (т.е. в своей программе).
> Это помимо использования 512 битных ключей, которые ломались супербыстрым атлоном (почти
> 1 ГГц!) только влет.Вообще-то факторизовали ключи и подлиннее (см. файлик "наследие DAMN") из-за того что автор популярного протектора реализовал PRNG на функции rand().
>Это случайно не связано с покупкой гитхаба мелкомягкими?Ты удивлён? Если что, то в сервисе поддержки Майкрософт сидят гастарбайтеры из Юго-Восточной Азии.
ну да, это ж мы вас заставляли пушить в паблик-репо что ни попадя.или, по вашему, мы должны круглые сутки следить, чтоб вы чего не накоммитили, и немедля...что, кстати, делать-то?
А они потом проверяли все найденные ключи на валидность? Или там половина плейсхолдеров типа abcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdef?
Часто ключи парсить приходится в гугле)
Но такие вот исследователя конечно портят всё)
чем портят-то, они ж ничего не удалили и даже не спугнули глупых рыбок?Или ты имеешь в виду - что ни ключ, то уже кто-то спер и сам майнит, а ты вечно не успеваешь?
>93.58% всех утечек выявлены в репозиториях, принадлежащих одному лицу, а не совместным проектам.Этим лицом был Альберт Эйнштейн?
Интересно, сколько из 19% ключей, который были убраны продолжают действовать? Ну, "я же убрал быстро, никто и не увидит"
интересней другое - сколько ключей "убраны" git rm'ом - и при этом продолжают действовать.и анализировали ли "исследователи" мертвые ветки без имен и тегов.
А что не выложили-то? :)
Они уверены что конф. данные не были специально там размещены особенно для перехвата через VPN?
Засилье джуниоров формошлепов на гитхабе после покупки мелкомягкими, которые по незнанию выкладывают корпоративные ключи... Вот что значит уменьшить порог вхождения и упрощать инструменты разработки.
Нормальные разработчики и кампании ставят свои инстансы гита, на крайний случай - гитлаб.