forum.opennet.ru - "Анализ утечек конфиденциальных данных через репозитории на G..." (36)

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

Форум Разговоры, обсуждение новостей
Вариант для распечатки		Пред. тема \| След. тема
Изначальное сообщение		[ Отслеживать ]

"Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
Сообщение от opennews (ok), 22-Мрт-19, 14:12
Группа исследователей из Университета штата Северная Каролина опубликовала (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.dev/opennews/art.shtml?num=41370) к облачным сервисам, пароли к СУБД, ключи к VPN и сертификаты (https://www.opennet.dev/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.dev/opennews/art.shtml?num=50374
Ответить \| Правка \| Cообщить модератору

Оглавление

Анализ утечек конфиденциальных данных через репозитории на G..., Тибетский лис (ok), 14:12 , 22-Мрт-19, (1)

Анализ утечек конфиденциальных данных через репозитории на G..., нах (?), 14:44 , 22-Мрт-19, (4) +23

Анализ утечек конфиденциальных данных через репозитории на G..., Аноним (17), 16:57 , 22-Мрт-19, (17) +12

Анализ утечек конфиденциальных данных через репозитории на G..., нах (?), 21:46 , 22-Мрт-19, (25) –3

Анализ утечек конфиденциальных данных через репозитории на G..., Ordu (ok), 13:58 , 23-Мрт-19, (32) +2

Анализ утечек конфиденциальных данных через репозитории на G..., нах (?), 16:00 , 23-Мрт-19, (35)

Анализ утечек конфиденциальных данных через репозитории на G..., Ordu (ok), 16:38 , 23-Мрт-19, (37)

Анализ утечек конфиденциальных данных через репозитории на G..., universite (ok), 21:12 , 23-Мрт-19, (38)

Анализ утечек конфиденциальных данных через репозитории на G..., Ordu (ok), 01:06 , 24-Мрт-19, (40)

Анализ утечек конфиденциальных данных через репозитории на G..., Аноним (33), 14:43 , 23-Мрт-19, (33) +1

Анализ утечек конфиденциальных данных через репозитории на G..., Аноним (2), 14:20 , 22-Мрт-19, (2)

Анализ утечек конфиденциальных данных через репозитории на G..., нах (?), 14:45 , 22-Мрт-19, (5) –2

Анализ утечек конфиденциальных данных через репозитории на G..., istepan (ok), 15:02 , 22-Мрт-19, (6) +6
Анализ утечек конфиденциальных данных через репозитории на G..., Аноним (7), 15:09 , 22-Мрт-19, (7)

Анализ утечек конфиденциальных данных через репозитории на G..., нах (?), 15:13 , 22-Мрт-19, (9) –1

Анализ утечек конфиденциальных данных через репозитории на G..., Dmitry77 (ok), 09:49 , 23-Мрт-19, (28)

Анализ утечек конфиденциальных данных через репозитории на G..., имя (?), 15:07 , 23-Мрт-19, (34)

Анализ утечек конфиденциальных данных через репозитории на G..., нах (?), 16:02 , 23-Мрт-19, (36)

Анализ утечек конфиденциальных данных через репозитории на G..., Аноним (10), 15:18 , 22-Мрт-19, (10) –2

Анализ утечек конфиденциальных данных через репозитории на G..., жека воробьев (?), 15:29 , 22-Мрт-19, (11) +12

Анализ утечек конфиденциальных данных через репозитории на G..., Аноним (13), 16:05 , 22-Мрт-19, (13) +1
Анализ утечек конфиденциальных данных через репозитории на G..., анон (?), 00:14 , 25-Мрт-19, (43)

Анализ утечек конфиденциальных данных через репозитории на G..., Andrey Mitrofanov (?), 15:33 , 22-Мрт-19, (12)
Анализ утечек конфиденциальных данных через репозитории на G..., Аноним84701 (ok), 16:25 , 22-Мрт-19, (14) +3

Анализ утечек конфиденциальных данных через репозитории на G..., Аноним (7), 06:44 , 23-Мрт-19, (27)

Анализ утечек конфиденциальных данных через репозитории на G..., Аноним (20), 18:39 , 22-Мрт-19, (20)

Анализ утечек конфиденциальных данных через репозитории на G..., проклятый гастарбайтер из ЮВА (?), 12:52 , 23-Мрт-19, (29)

Анализ утечек конфиденциальных данных через репозитории на G..., Аноним (16), 16:33 , 22-Мрт-19, (16) –2
Анализ утечек конфиденциальных данных через репозитории на G..., robot228 (?), 17:22 , 22-Мрт-19, (18)

Анализ утечек конфиденциальных данных через репозитории на G..., пох (?), 12:58 , 23-Мрт-19, (31)

Анализ утечек конфиденциальных данных через репозитории на G..., Аноним (22), 19:47 , 22-Мрт-19, (22) –1
Анализ утечек конфиденциальных данных через репозитории на G..., abi (?), 22:14 , 22-Мрт-19, (26) +3

Анализ утечек конфиденциальных данных через репозитории на G..., пох (?), 12:54 , 23-Мрт-19, (30)

Анализ утечек конфиденциальных данных через репозитории на G..., InuYasha (?), 22:37 , 23-Мрт-19, (39)
Анализ утечек конфиденциальных данных через репозитории на G..., Honeypot (?), 07:11 , 24-Мрт-19, (41)
Анализ утечек конфиденциальных данных через репозитории на G..., Anon_Erohin (?), 15:09 , 24-Мрт-19, (42)

Сообщения [Сортировка по времени | RSS]

1. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от Тибетский лис (ok), 22-Мрт-19, 14:12

А каким именно образом закрытые ключи могут попасть в репозиторий?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

4. "Анализ утечек конфиденциальных данных через репозитории на G..." +23 +/–

Сообщение от нах (?), 22-Мрт-19, 14:44

git add . && git push
не понимаю, в чем у вас проблема - всегда так делаю!

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

17. "Анализ утечек конфиденциальных данных через репозитории на G..." +12 +/–

Сообщение от Аноним (17), 22-Мрт-19, 16:57

Так точно никогда не утечет, коммита же небыло, хитрец

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

25. "Анализ утечек конфиденциальных данных через репозитории на G..." –3 +/–

Сообщение от нах (?), 22-Мрт-19, 21:46

коммит сделается в параллельной сессии, или вообще другим чуваком параллельно зашедшим.
(кстати, регулярно на эти грабли наступаю, ну, правда, ключей от EC пока не коммитил, но ненужно-add'ы были)
btw, я правильно понимаю, что git commit --amend не исправляет такую ситуацию, а усугубляет ее?

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

32. "Анализ утечек конфиденциальных данных через репозитории на G..." +2 +/–

Сообщение от Ordu (ok), 23-Мрт-19, 13:58

> ненужно-add'ы были
От них легко избавиться, если следить за созданием красивой истории. Все рабочие коммиты должны идти в рабочую же ветку. Или в рабочие ветки. Которые создаются при помощи git checkout -B any-stupid-branch-name.
Когда же ты пришёл к выводу, что пора что-то втолкнуть в апстрим, то возвращаешься на тот коммит поверх которого хочешь пушить, создаёшь ветку, берёшь git rebase, превращаешь результаты своей дневной работы (или недельной -- это как удобнее) в последовательность осмысленных коммитов, вычищая из них все метания от процесса проб и ошибок, собирая воедино основные коммиты и второстепенные, которые фиксят идентацию, добавляют комментарии или исправляют в них грамматику. Каждый из этих осмысленных коммитов ты снабжаешь осмысленным сопровождающим комментарием.
Это _очень_ полезно делать, потому что таким образом ты прокручиваешь в голове всё сделанное, и перепроверяешь себя -- не было ли что-то забыто. Помимо этого, оно избавляет тебя от случайно закоммиченных излишков. Ну и да, ты получаешь в результате историю, с которой потом можно работать, а не беспорядочный поток слабосвязанных изменений.
И вот _после_ этого, ты пушишь эту (и только эту) ветку с красивой историей в апстрим. Я при этом проталкиваю в специально создаваемую для этого ветку в апстриме, чтобы мерг потом сделать на стороне github'а. Если ты один в апстрим пишешь это по идее не должно влиять, но я параноик (потому что я знаю, что мои шаловливые ручки могут сломать всё, что угодно), и я лучше лишних телодвижений сделаю, с тем чтобы потом ещё pull-request на github'е создать и смержить, чем буду рисковать удалением каких-нибудь коммитов.

Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

35. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от нах (?), 23-Мрт-19, 16:00

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

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

37. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от Ordu (ok), 23-Мрт-19, 16:38

>> От них легко избавиться, если следить за созданием красивой истории.
> ну то есть никогда ничего не push'ить в апстрим просто так.
> если его считать просто архивом на память - то можно и так,
> конечно.
> Можно ли работать с выдуманной историей вместо настоящей - я вот хз,
> потому что изменения делались тобой при одном состоянии репо, а подмененная
> история показывает другое.
Задача истории -- документировать изменения.
> Но скорее всего эта история никому и никогда
> не потребуется, ни настоящая, ни поддельная. А для blame она не
> важна.
Зачем нужен blame, как ты думаешь?
Мне кажется, что некоторые считают, что blame нужен для того, чтобы найти виноватого и надрать ему задницу. Так вот, это ложное суждение. Это бюрократии он будет нужен для этого: она в случае любого косяка первым делом ищет стрелочников. Тебе же blame будет нужен для того, чтобы выяснить зачем нужна та или иная строчка кода. Зачем эта строчка кода была добавлена, были ли какая-то специальная причина, и если была, то остаётся ли она причиной и по сей день. Если нет причины для того, чтобы эта строчка кода была именно такой, какая она есть, то у тебя развязаны руки, чтобы переписать её так, как это будет удобно тебе. И ради этой цели ты будешь использовать blame для того, чтобы посмотреть контекст в котором строчка была добавлена в код или в котором она изменялась, ты почитаешь комментарии сопровождающие эти коммиты, с тем чтобы понять их. Если у тебя останутся сомнения, то ты свяжешься с автором коммита, чтобы понять лучше. Но если дело дошло до того, что тебе надо связаться с автором коммита, то скорее всего это говнокоммиты, которые недостаточно хорошо документированы, которые плохо описывают изменения, которые недостаточно хорошо структурированы и плохо разбиты на отдельные патчи.
И в этом случае, гораздо удобнее, если история изменений упорядочена и _вдумчиво_ документирована. В процессе многих изменений, с поиском не уродского способа решить проблему, тебе не до того, чтобы вдумчиво документировать каждое изменение, особенно если ты подозреваешь, что это изменение через полчаса отправится в мусор. Вот ты сейчас попробуешь, что из этого выйдет, через полчаса этот эксперимент закончится, и вся ветка пойдёт в расход. Некоторые из таких попыток выживают. Но документировать каждое такое изменение перед тем, как ты его сделаешь -- это убийственно, и скажется на производительности катастрофически. А если ты пишешь документацию задним числом, когда рефлексируешь над проделанным, то ты действительно можешь в комментарии к каждому коммиту писать о том, что ты делаешь и почему, не занимаясь ответами на вопрос как ты делаешь, потому что на вопрос "как" отвечают diff'ы.

Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

38. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от universite (ok), 23-Мрт-19, 21:12

А можно по командам разложить и со скрина, если в IDE делаете?

Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

40. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от Ordu (ok), 24-Мрт-19, 01:06

> А можно по командам разложить и со скрина, если в IDE делаете?
Как пользоваться rebase? https://mtyurt.net/post/git-using-advanced-rebase-features-f...
А вот тут можно попрактиковаться: https://github.com/salemove/gojo

Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

33. "Анализ утечек конфиденциальных данных через репозитории на G..." +1 +/–

Сообщение от Аноним (33), 23-Мрт-19, 14:43

> А каким именно образом закрытые ключи могут попасть в репозиторий?
Такая культурка разработки. Как на работке коммитят пароли в гит, так и дома - тяп ляп халтурка.
Привычка-с. ))

Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

2. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от Аноним (2), 22-Мрт-19, 14:20

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

5. "Анализ утечек конфиденциальных данных через репозитории на G..." –2 +/–

Сообщение от нах (?), 22-Мрт-19, 14:45

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

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

6. "Анализ утечек конфиденциальных данных через репозитории на G..." +6 +/–

Сообщение от istepan (ok), 22-Мрт-19, 15:02

На гитхабе

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

7. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от Аноним (7), 22-Мрт-19, 15:09

Большая часть людей занимающаяся этой проблемой работает в Apple, Google, Intel, Cyclane, ESET. А дальше чистый NDA. Ничего нельзя рассказывать, и даже опенсорсить. Сотрудники этих контор тайно делают комиты (не со своих учеток, понятно) в https://github.com/*****, например. Но пруфов не будет. Остальные кто занимаются этой темой, продают свои наработки в Black 0day market. Их называть тоже не буду, кто надо тот знает этих людей пофамильно.  // Ну ты понел.

Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

9. "Анализ утечек конфиденциальных данных через репозитории на G..." –1 +/–

Сообщение от нах (?), 22-Мрт-19, 15:13

блин, просили ж бесплатно. У этих хорьков дорого, майнингом не окупится :-(

Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

28. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от Dmitry77 (ok), 23-Мрт-19, 09:49

мы как то случайно закомитили приватный ключ от эфириум кошелька. украли все "деньги" выделенные на тестирование за 15 минуть.

Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

34. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от имя (?), 23-Мрт-19, 15:07

т.е. вы вели разработку приложения для работы с криптовалютой не в приватном репозитории? ССЗБ

Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

36. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от нах (?), 23-Мрт-19, 16:02

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

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

10. "Анализ утечек конфиденциальных данных через репозитории на G..." –2 +/–

Сообщение от Аноним (10), 22-Мрт-19, 15:18

Это случайно не связано с покупкой гитхаба мелкомягкими?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

11. "Анализ утечек конфиденциальных данных через репозитории на G..." +12 +/–

Сообщение от жека воробьев (?), 22-Мрт-19, 15:29

Наличие безалаберных и невнимательных людей? Нет, не связано

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

13. "Анализ утечек конфиденциальных данных через репозитории на G..." +1 +/–

Сообщение от Аноним (13), 22-Мрт-19, 16:05

Проблема как всегда в плохом дизайне проектов.

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

43. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от анон (?), 25-Мрт-19, 00:14

сами себе противоречите, в мс только такие и работают

Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

12. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от Andrey Mitrofanov (?), 22-Мрт-19, 15:33

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

14. "Анализ утечек конфиденциальных данных через репозитории на G..." +3 +/–

Сообщение от Аноним84701 (ok), 22-Мрт-19, 16:25

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

27. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от Аноним (7), 23-Мрт-19, 06:44

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

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

20. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от Аноним (20), 22-Мрт-19, 18:39

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

Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

29. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от проклятый гастарбайтер из ЮВА (?), 23-Мрт-19, 12:52

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

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

16. "Анализ утечек конфиденциальных данных через репозитории на G..." –2 +/–

Сообщение от Аноним (16), 22-Мрт-19, 16:33

А они потом проверяли все найденные ключи на валидность? Или там половина плейсхолдеров типа abcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdef?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

18. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от robot228 (?), 22-Мрт-19, 17:22

Часто ключи парсить приходится в гугле)
Но такие вот исследователя конечно портят всё)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

31. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от пох (?), 23-Мрт-19, 12:58

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

Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

22. "Анализ утечек конфиденциальных данных через репозитории на G..." –1 +/–

Сообщение от Аноним (22), 22-Мрт-19, 19:47

>93.58% всех утечек выявлены в репозиториях, принадлежащих одному лицу, а не совместным проектам.
Этим лицом был Альберт Эйнштейн?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

26. "Анализ утечек конфиденциальных данных через репозитории на G..." +3 +/–

Сообщение от abi (?), 22-Мрт-19, 22:14

Интересно, сколько из 19% ключей, который были убраны продолжают действовать? Ну, "я же убрал быстро, никто и не увидит"

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

30. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от пох (?), 23-Мрт-19, 12:54

интересней другое - сколько ключей "убраны" git rm'ом - и при этом продолжают действовать.
и анализировали ли "исследователи" мертвые ветки без имен и тегов.

Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

39. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от InuYasha (?), 23-Мрт-19, 22:37

А что не выложили-то? :)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

41. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от Honeypot (?), 24-Мрт-19, 07:11

Они уверены что конф. данные не были специально там размещены особенно для перехвата через VPN?

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

42. "Анализ утечек конфиденциальных данных через репозитории на G..." +/–

Сообщение от Anon_Erohin (?), 24-Мрт-19, 15:09

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

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

1. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
Сообщение от Тибетский лис (ok), 22-Мрт-19, 14:12
А каким именно образом закрытые ключи могут попасть в репозиторий?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	4. "Анализ утечек конфиденциальных данных через репозитории на G..."	+23 +/–
	Сообщение от нах (?), 22-Мрт-19, 14:44
	git add . && git push не понимаю, в чем у вас проблема - всегда так делаю!
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору


	17. "Анализ утечек конфиденциальных данных через репозитории на G..."	+12 +/–
	Сообщение от Аноним (17), 22-Мрт-19, 16:57
	Так точно никогда не утечет, коммита же небыло, хитрец
	Ответить \| Правка \| ^ к родителю #4 \| Наверх \| Cообщить модератору


	25. "Анализ утечек конфиденциальных данных через репозитории на G..."	–3 +/–
	Сообщение от нах (?), 22-Мрт-19, 21:46
	коммит сделается в параллельной сессии, или вообще другим чуваком параллельно зашедшим. (кстати, регулярно на эти грабли наступаю, ну, правда, ключей от EC пока не коммитил, но ненужно-add'ы были) btw, я правильно понимаю, что git commit --amend не исправляет такую ситуацию, а усугубляет ее?
	Ответить \| Правка \| ^ к родителю #17 \| Наверх \| Cообщить модератору


	32. "Анализ утечек конфиденциальных данных через репозитории на G..."	+2 +/–
	Сообщение от Ordu (ok), 23-Мрт-19, 13:58
	> ненужно-add'ы были От них легко избавиться, если следить за созданием красивой истории. Все рабочие коммиты должны идти в рабочую же ветку. Или в рабочие ветки. Которые создаются при помощи git checkout -B any-stupid-branch-name. Когда же ты пришёл к выводу, что пора что-то втолкнуть в апстрим, то возвращаешься на тот коммит поверх которого хочешь пушить, создаёшь ветку, берёшь git rebase, превращаешь результаты своей дневной работы (или недельной -- это как удобнее) в последовательность осмысленных коммитов, вычищая из них все метания от процесса проб и ошибок, собирая воедино основные коммиты и второстепенные, которые фиксят идентацию, добавляют комментарии или исправляют в них грамматику. Каждый из этих осмысленных коммитов ты снабжаешь осмысленным сопровождающим комментарием. Это _очень_ полезно делать, потому что таким образом ты прокручиваешь в голове всё сделанное, и перепроверяешь себя -- не было ли что-то забыто. Помимо этого, оно избавляет тебя от случайно закоммиченных излишков. Ну и да, ты получаешь в результате историю, с которой потом можно работать, а не беспорядочный поток слабосвязанных изменений. И вот _после_ этого, ты пушишь эту (и только эту) ветку с красивой историей в апстрим. Я при этом проталкиваю в специально создаваемую для этого ветку в апстриме, чтобы мерг потом сделать на стороне github'а. Если ты один в апстрим пишешь это по идее не должно влиять, но я параноик (потому что я знаю, что мои шаловливые ручки могут сломать всё, что угодно), и я лучше лишних телодвижений сделаю, с тем чтобы потом ещё pull-request на github'е создать и смержить, чем буду рисковать удалением каких-нибудь коммитов.
	Ответить \| Правка \| ^ к родителю #25 \| Наверх \| Cообщить модератору


	35. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от нах (?), 23-Мрт-19, 16:00
	> От них легко избавиться, если следить за созданием красивой истории. ну то есть никогда ничего не push'ить в апстрим просто так. если его считать просто архивом на память - то можно и так, конечно. Можно ли работать с выдуманной историей вместо настоящей - я вот хз, потому что изменения делались тобой при одном состоянии репо, а подмененная история показывает другое. Но скорее всего эта история никому и никогда не потребуется, ни настоящая, ни поддельная. А для blame она не важна.
	Ответить \| Правка \| ^ к родителю #32 \| Наверх \| Cообщить модератору


	37. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от Ordu (ok), 23-Мрт-19, 16:38
	>> От них легко избавиться, если следить за созданием красивой истории. > ну то есть никогда ничего не push'ить в апстрим просто так. > если его считать просто архивом на память - то можно и так, > конечно. > Можно ли работать с выдуманной историей вместо настоящей - я вот хз, > потому что изменения делались тобой при одном состоянии репо, а подмененная > история показывает другое. Задача истории -- документировать изменения. > Но скорее всего эта история никому и никогда > не потребуется, ни настоящая, ни поддельная. А для blame она не > важна. Зачем нужен blame, как ты думаешь? Мне кажется, что некоторые считают, что blame нужен для того, чтобы найти виноватого и надрать ему задницу. Так вот, это ложное суждение. Это бюрократии он будет нужен для этого: она в случае любого косяка первым делом ищет стрелочников. Тебе же blame будет нужен для того, чтобы выяснить зачем нужна та или иная строчка кода. Зачем эта строчка кода была добавлена, были ли какая-то специальная причина, и если была, то остаётся ли она причиной и по сей день. Если нет причины для того, чтобы эта строчка кода была именно такой, какая она есть, то у тебя развязаны руки, чтобы переписать её так, как это будет удобно тебе. И ради этой цели ты будешь использовать blame для того, чтобы посмотреть контекст в котором строчка была добавлена в код или в котором она изменялась, ты почитаешь комментарии сопровождающие эти коммиты, с тем чтобы понять их. Если у тебя останутся сомнения, то ты свяжешься с автором коммита, чтобы понять лучше. Но если дело дошло до того, что тебе надо связаться с автором коммита, то скорее всего это говнокоммиты, которые недостаточно хорошо документированы, которые плохо описывают изменения, которые недостаточно хорошо структурированы и плохо разбиты на отдельные патчи. И в этом случае, гораздо удобнее, если история изменений упорядочена и _вдумчиво_ документирована. В процессе многих изменений, с поиском не уродского способа решить проблему, тебе не до того, чтобы вдумчиво документировать каждое изменение, особенно если ты подозреваешь, что это изменение через полчаса отправится в мусор. Вот ты сейчас попробуешь, что из этого выйдет, через полчаса этот эксперимент закончится, и вся ветка пойдёт в расход. Некоторые из таких попыток выживают. Но документировать каждое такое изменение перед тем, как ты его сделаешь -- это убийственно, и скажется на производительности катастрофически. А если ты пишешь документацию задним числом, когда рефлексируешь над проделанным, то ты действительно можешь в комментарии к каждому коммиту писать о том, что ты делаешь и почему, не занимаясь ответами на вопрос как ты делаешь, потому что на вопрос "как" отвечают diff'ы.
	Ответить \| Правка \| ^ к родителю #35 \| Наверх \| Cообщить модератору


	38. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от universite (ok), 23-Мрт-19, 21:12
	А можно по командам разложить и со скрина, если в IDE делаете?
	Ответить \| Правка \| ^ к родителю #32 \| Наверх \| Cообщить модератору


	40. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от Ordu (ok), 24-Мрт-19, 01:06
	> А можно по командам разложить и со скрина, если в IDE делаете? Как пользоваться rebase? https://mtyurt.net/post/git-using-advanced-rebase-features-f... А вот тут можно попрактиковаться: https://github.com/salemove/gojo
	Ответить \| Правка \| ^ к родителю #38 \| Наверх \| Cообщить модератору


	33. "Анализ утечек конфиденциальных данных через репозитории на G..."	+1 +/–
	Сообщение от Аноним (33), 23-Мрт-19, 14:43
	> А каким именно образом закрытые ключи могут попасть в репозиторий? Такая культурка разработки. Как на работке коммитят пароли в гит, так и дома - тяп ляп халтурка. Привычка-с. ))
	Ответить \| Правка \| ^ к родителю #1 \| Наверх \| Cообщить модератору

2. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
Сообщение от Аноним (2), 22-Мрт-19, 14:20
Есть даже боты, которые рыщут по гитхабу в поисках всяких клбчей. Читал статью про то, как у кого-то 10000 инстансов на амазоне арендовали и майнили из-за оставленного ключа на гитхабе.
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	5. "Анализ утечек конфиденциальных данных через репозитории на G..."	–2 +/–
	Сообщение от нах (?), 22-Мрт-19, 14:45
	> Есть даже боты, которые рыщут по гитхабу в поисках всяких клбчей. где скачать бесплатно-без-смс?
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	6. "Анализ утечек конфиденциальных данных через репозитории на G..."	+6 +/–
	Сообщение от istepan (ok), 22-Мрт-19, 15:02
	На гитхабе
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	7. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от Аноним (7), 22-Мрт-19, 15:09
	Большая часть людей занимающаяся этой проблемой работает в Apple, Google, Intel, Cyclane, ESET. А дальше чистый NDA. Ничего нельзя рассказывать, и даже опенсорсить. Сотрудники этих контор тайно делают комиты (не со своих учеток, понятно) в https://github.com/*****, например. Но пруфов не будет. Остальные кто занимаются этой темой, продают свои наработки в Black 0day market. Их называть тоже не буду, кто надо тот знает этих людей пофамильно. // Ну ты понел.
	Ответить \| Правка \| ^ к родителю #5 \| Наверх \| Cообщить модератору


	9. "Анализ утечек конфиденциальных данных через репозитории на G..."	–1 +/–
	Сообщение от нах (?), 22-Мрт-19, 15:13
	блин, просили ж бесплатно. У этих хорьков дорого, майнингом не окупится :-(
	Ответить \| Правка \| ^ к родителю #7 \| Наверх \| Cообщить модератору


	28. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от Dmitry77 (ok), 23-Мрт-19, 09:49
	мы как то случайно закомитили приватный ключ от эфириум кошелька. украли все "деньги" выделенные на тестирование за 15 минуть.
	Ответить \| Правка \| ^ к родителю #2 \| Наверх \| Cообщить модератору


	34. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от имя (?), 23-Мрт-19, 15:07
	т.е. вы вели разработку приложения для работы с криптовалютой не в приватном репозитории? ССЗБ
	Ответить \| Правка \| ^ к родителю #28 \| Наверх \| Cообщить модератору


	36. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от нах (?), 23-Мрт-19, 16:02
	> т.е. вы вели разработку приложения для работы с криптовалютой не в приватном репозитории а почему она должна вестись за закрытыми дверями и посреди минного поля?
	Ответить \| Правка \| ^ к родителю #34 \| Наверх \| Cообщить модератору

10. "Анализ утечек конфиденциальных данных через репозитории на G..."	–2 +/–
Сообщение от Аноним (10), 22-Мрт-19, 15:18
Это случайно не связано с покупкой гитхаба мелкомягкими?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	11. "Анализ утечек конфиденциальных данных через репозитории на G..."	+12 +/–
	Сообщение от жека воробьев (?), 22-Мрт-19, 15:29
	Наличие безалаберных и невнимательных людей? Нет, не связано
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	13. "Анализ утечек конфиденциальных данных через репозитории на G..."	+1 +/–
	Сообщение от Аноним (13), 22-Мрт-19, 16:05
	Проблема как всегда в плохом дизайне проектов.
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	43. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от анон (?), 25-Мрт-19, 00:14
	сами себе противоречите, в мс только такие и работают
	Ответить \| Правка \| ^ к родителю #11 \| Наверх \| Cообщить модератору


	12. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от Andrey Mitrofanov (?), 22-Мрт-19, 15:33
	> Это случайно не связано с покупкой гитхаба мелкомягкими? Конечно связано, не сомневайтесь! У Майкарософт Рисёурч новая игрушка, а у опенета новые новости от "британских" учёных.
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	14. "Анализ утечек конфиденциальных данных через репозитории на G..."	+3 +/–
	Сообщение от Аноним84701 (ok), 22-Мрт-19, 16:25
	> Это случайно не связано с покупкой гитхаба мелкомягкими? Еще в древне-мохнатые, до-гитхабные годы те же шарващики "забывали" свои ключи RSA, с помощью которых проверялась лицензия (а у особо продвинутых даже расшифровывалась часть кода) в общественном доступе (т.е. в своей программе). Это помимо использования 512 битных ключей, которые ломались супербыстрым атлоном (почти 1 ГГц!) только влет. Учитывая, что тогда (как любят писать некоторые анонимные комментаторы опеннета) "и солнце ярче светило и компутерщики скилнутее сегодняшних смузихлебов были" -- вряд ли оно связано с покупкой гитхаба мелкомягкими ;)
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	27. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от Аноним (7), 23-Мрт-19, 06:44
	>> Это случайно не связано с покупкой гитхаба мелкомягкими? > Еще в древне-мохнатые, до-гитхабные годы те же шарващики "забывали" свои ключи > RSA, с помощью которых проверялась лицензия (а у особо продвинутых даже > расшифровывалась часть кода) в общественном доступе (т.е. в своей программе). > Это помимо использования 512 битных ключей, которые ломались супербыстрым атлоном (почти > 1 ГГц!) только влет. Вообще-то факторизовали ключи и подлиннее (см. файлик "наследие DAMN") из-за того что автор популярного протектора реализовал PRNG на функции rand().
	Ответить \| Правка \| ^ к родителю #14 \| Наверх \| Cообщить модератору


	20. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от Аноним (20), 22-Мрт-19, 18:39
	>Это случайно не связано с покупкой гитхаба мелкомягкими? Ты удивлён? Если что, то в сервисе поддержки Майкрософт сидят гастарбайтеры из Юго-Восточной Азии.
	Ответить \| Правка \| ^ к родителю #10 \| Наверх \| Cообщить модератору


	29. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от проклятый гастарбайтер из ЮВА (?), 23-Мрт-19, 12:52
	ну да, это ж мы вас заставляли пушить в паблик-репо что ни попадя. или, по вашему, мы должны круглые сутки следить, чтоб вы чего не накоммитили, и немедля...что, кстати, делать-то?
	Ответить \| Правка \| ^ к родителю #20 \| Наверх \| Cообщить модератору

16. "Анализ утечек конфиденциальных данных через репозитории на G..."	–2 +/–
Сообщение от Аноним (16), 22-Мрт-19, 16:33
А они потом проверяли все найденные ключи на валидность? Или там половина плейсхолдеров типа abcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdef?
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору

18. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
Сообщение от robot228 (?), 22-Мрт-19, 17:22
Часто ключи парсить приходится в гугле) Но такие вот исследователя конечно портят всё)
Ответить \| Правка \| ^ к родителю #0 \| Наверх \| Cообщить модератору


	31. "Анализ утечек конфиденциальных данных через репозитории на G..."	+/–
	Сообщение от пох (?), 23-Мрт-19, 12:58
	чем портят-то, они ж ничего не удалили и даже не спугнули глупых рыбок? Или ты имеешь в виду - что ни ключ, то уже кто-то спер и сам майнит, а ты вечно не успеваешь?
	Ответить \| Правка \| ^ к родителю #18 \| Наверх \| Cообщить модератору