Популярный сервис заказа такси Uber (https://ru.wikipedia.org/wiki/Uber) инициировал (http://arstechnica.com/security/2015/03/in-major-goof-uber-s... судебное разбирательство, связанное с утечкой (http://blog.uber.com/2-27-15) базы данных, содержащей сведения о персональных данных и номерах водительских удостоверений около 50 тысяч водителей. Примечательно, что в рамках судебного разбирательства, в котором фигурирует неизвестный злоумышленник, Uber потребовал у GitHub предоставить сведения об IP-адресах, с которых был зафиксирован доступ к определённым репозиториям.Судя по фигурирующей в рамках дела информации, утечка базы данных вызвана не компрометацией инфраструктуры Uber, а использованием штатных ключей аутентификации, которые по недосмотру были опубликованы каким-то сотрудником или подрядчиком в публичном репозитории GitHub. Неавторизированный доступ к серверам Uber был произведён ещё 13 мая 2014 года и привёл к выгрузке данных о приблизительно 50 тысячах водителях.
Инциденты, связанные со случайной публикацией на GitHub параметров аутентификации, происходят достаточно часто и активно отслеживаются потенциальными злоумышленниками. Наличие сервисов, подобных GHTorrent (http://ghtorrent.org/), которые почти в реальном режиме времени отслеживают и зеркалируют все изменения на GitHub, делают безвозвратным попадание закрытой информации в публичные репозитории. Даже в случае оперативного удаления данных (https://help.github.com/articles/remove-sensitive-data/), опубликованных по ошибке, эти данные остаются доступными через независимые сторонние архивы.
Например, несколько месяцев назад один из разработчиков случайно сохранил (http://www.devfactor.net/2014/12/30/2375-amazon-mistake/) на никому неизвестном тестовом репозитории приложение, забыв удалить параметры входа в Amazon AWS, после чего в течение 5 минут воспользовался инструментом GitHub для полного вычищения изменений из репозиторя. Не почувствовав подвоха разработчик не посчитал нужным сменить параметры входа. Через считанные часы злоумышленники задействовали его аккаунт в Amazon AWS для майнинга bitcoin.URL: http://arstechnica.com/security/2015/03/in-major-goof-uber-s.../
Новость: http://www.opennet.me/opennews/art.shtml?num=41771
То есть рубанок виноват в тупости и злобности буратины? Это прекрасно.
Цена ошибки такова, что выгоднее не пользоваться GitHub, чем пользоваться с риском огрести.
Зачем отказываться от Гитхаба если можно оперативно поменять ключ?
А если нельзя или сложно,то ИМХО значит с организацией безопасности проблемы.
Затем, что прочитав статью ты узнаешь, как сотрудник по ошибке опубликовал данные, которые были использованы для взлома. И узнали об этой ошибке только по факту разбирательства причин взлома.Повторяю: цена ошибок слишком высока. С такими рисками ресурс могут использовать только камикадзе.
Не вижу никаких дополнительных рисков? относительно тех что они уже несут, имея фирменный сайт.
Поищите в гугле файлы дампов баз данных, случайно лежащих в общем доступе на сайте.
Десятки тысяч результатов.
Или вот:
>Были получены исходники 3300 глобальных интернет-проектов
>http://habrahabr.ru/post/70330/- забыли закрыть доступ к svn репозиториям на сайтах yandex opera mail.ru rambler.
Избавься от рисков - выдерни ethernet кабель.
> - забыли закрыть доступ к svn репозиториям на сайтах yandex opera mail.ru
> rambler.забыли нанять людей, у которых в голове мозг, а не кю. каждому идиоту известно, что служебным каталогам системы контроля версий не место на продакшн‐сервере. но проприерасты умудряются находить таких идиотов, которым неизвестно. это называется «профессионализм».
> Затем, что прочитав статью ты узнаешь,Нет, ты.
> как сотрудник по ошибке опубликовал данные, которые были использованы для взлома.
1/ "По ошибке" сотрудник не сменил явки после публикации.
2/ Не было _влома, была утечка данных аут-ции.> Повторяю: цена ошибок слишком высока. С такими рисками ресурс могут использовать только
> камикадзе.Ваше мнение очень важно для нас. Лучшие б.-практики, теория циклов, бесценные ошибки. Всегда в нетерпении ждём продолжения!
> 2/ Не было _влома, была утечка данных аут-ции.Даже, компрометация ключей.
Кражи не было, просто ключи попали кому-то не тому. А что вещей недосчитались, так это уже совсем другая история.Два не связанных между собой события.
+++
Если свои ключи оставить на столике в кафе, то глупо иск вчинять ему.
Гитхаб опасный, гыгыг.
Минус вам поставил походу тот же школьник, который мне минусует даже если я пишу, что Земля круглая. Поймаю - уши надеру ))
> Повторяю: цена ошибок слишком высока. С такими рисками ресурс могут использовать только
> камикадзе.500 рублей в месяц за 5 приватных репозиториев.
https://github.com/account/plans
Я конечно понимаю, что цена неподъемная даже для Uber с капитализацией $41,0 млрд...А вообще, если к их серверам подключились 13 мая 2014 года, а узнали они об этом 17 сентября, им нужно что-то менять в консерватории.
"Каждый мнит себя стратегом видя бой со стороны." (древне-римская пословица)Если крупной ИТ компании нужен закрытый репозиторий - его проще и быстрее создать внутри компании. Если компании нужен открытый репозиторий или компания вляпалась в GPL и теперь не может от него отмыться - она использует чужой открытый репозиторий, т.к. нет смысла создавать его внутри.
Не открывайте код - не будет утечек.
> "Каждый мнит себя стратегом видя бой со стороны." (древне-римская пословица)
> Если крупной ИТ компании нужен закрытый репозиторий - его проще и быстрее
> создать внутри компании. Если компании нужен открытый репозиторий или компания вляпалась
> в GPL и теперь не может от него отмыться - она
> использует чужой открытый репозиторий, т.к. нет смысла создавать его внутри.
> Не открывайте код - не будет утечек.Ща тебя стаканчиком накроют. :)
Но так-то ты прав.
> Не открывайте код - не будет утечек.Есть более фундаментальный вариант: можно не писать код и пойти работать дворником. Тогда ущерб от утечек будет минимизирован на самом базовом уровне.
Онанизма бояться - *** не др**ить. Первый раз - случайность, второй - совпадение, третий - закономерность. В статье приведены три примера с одной причиной - невнимательность. Вариантов немного:
- отказаться от публичного репозитория
- создать дублирующий внутренний репозиторий, нанять (отвлечь) людей для верификации файлов и кода, копируемого из рабочего репозитория в публичный
- оставить как есть и будь что будетУчитывая, что публичный репозиторий ничего не приносит, от него лучше отказаться.
Выше уже приводили примеры с незакрытыми SVN репами, которые должны были быть "внутренними". Суть проблемы - не в открытых репах, а в тех клоунах, которые в них вываливают всё подряд не подумав, включая ключи. С тем же успехом можно было запостить ключи на пастебин или забыть закрыть доступ извне к своей VCS.
> Онанизма бояться - *** не др**ить.Вот я и говорю: слой гипса, бинт, еще слой гипса, еще бинт, еще слой гипса, .... .... и самое главное - никакого секса!
> Учитывая, что публичный репозиторий ничего не приносит,
Нормальная такая подтасовка фактов. И конечно мы ее совсем не заметим :).
> Онанизма бояться - *** не др**ить. Первый раз - случайность, второй -
> совпадение, третий - закономерность. В статье приведены три примера с одной
> причиной - невнимательность. Вариантов немного:
> - отказаться от публичного репозитория
> - создать дублирующий внутренний репозиторий, нанять (отвлечь) людей для верификации файлов
> и кода, копируемого из рабочего репозитория в публичный
> - оставить как есть и будь что будет
> Учитывая, что публичный репозиторий ничего не приносит, от него лучше отказаться.Еще один вариант, первейший - НЕ БРАТЬ НА РАБОТУ ДЕБИЛОВ, путающих конфиденциальные данные с общедоступными. А то Вы тут выше говорите, что нельзя выпускать ножи - а то идиот может и сам порезаться, и других порезать - в инструкции к ножу не сказано же, что им запрещено резать свои или чужие горло или живот...
Невнимательный администратор - это оксюморон.
> Невнимательный администратор - это оксюморон.Это писатель на bash.im ))
И судя по-всему их не мало. В отличие от сапёра, который ошибается дважды, и радиотехника, который в случае ошибки будет наблюдать красивую вспышку, Одминистрирование ошибки прощает. Быстро поднял = не падало. Таким слоупокам, которые через 3 месяца заметили - так и надо.
Может быть поздно, как в данном случае.
Доступ к внутренней базе Uber возможен с любого устройства подключенного к интернет, ключи аутентификации доступны широкому кругу лиц, в том числе низкоквалифицированным сотрудникам подрядчиков. И причём тут github?
> Цена ошибки такова, что выгоднее не пользоваться GitHub, чем пользоваться с риском огрести.Понимаешь, у сетей универсальное свойство такое: если там что-то опубликовали, назад это уже не заберешь. А агрессивные попытки это сделать часто ведут к противоположному эффекту, из-за эффекта Стрейзанд. Если это не нравится - не пользуйся сетями и не публикуй информацию. Сиди в бетонном бункере на мешке с своей "информацией".
Давно пора понять: опасен не нож в руках маньяка, а маньяк, взявший в руки нож. Нож - инструмент, ему всё равно будут им резать хлеб или соседей.Открытый код несёт риски. Если бы компания не открыла код - данные не утекли бы в сеть - взлома бы не произошло. Я предлагаю не открывать больше ни строчки кода. Это предотвратит утечки и позволит недопустить взломов в будущем. Open source имеет преимущества, а это один из его неустранимых недостатков.
> Давно пора понять: опасен не нож в руках маньяка, а маньяк, взявший в руки нож.
> Я предлагаю не открывать больше ни строчки кода.Кто-кто, говоришь, "маньяк"-то?? Ты, что ли?
>> Давно пора понять: опасен не нож в руках маньяка, а маньяк, взявший в руки нож.
>> Я предлагаю не открывать больше ни строчки кода.
> Кто-кто, говоришь, "маньяк"-то?? Ты, что ли?нет, он Всемирно Известный Эксперт. к его ценным предложениям прислушиваются ведущие IT-корпорации мира.
> Открытый код несёт риски. Если бы компания не открыла код - данные не утекли бы в сеть - взлома бы не произошло. Я предлагаю не открывать больше ни строчки кода. Это предотвратит утечки и позволит недопустить взломов в будущем.Это типа такое упражнение на логику, нужно найти контр-аргумент на этот бред?
Поэтому надо бить по рукам тем кто не умеет пользоваться инструментами или пользуется не по назначению, а не "ломать хлеб руками, вместо того чтобы пользоваться ножом".
> Открытый код несёт риски. Если бы компания не открыла код - данные
> не утекли бы в сеть - взлома бы не произошло.Да что там, если бы компания не писала код и не генерила ключи, и занималась исключительно уборкой дворов от мусора - утечки можно было бы избежать!
> Я предлагаю не открывать больше ни строчки кода. Это предотвратит утечки и
> позволит недопустить взломов в будущем.А я предлагаю тебе не писать код - уж так то его точно не "украдут". Сложно взять то, чего нет. Иначе всегда будет риск. Иди работать дворнико.
> Open source имеет преимущества, а это один из его неустранимых недостатков.
Ну вот ты и сиди на своем супермегакоде и секретах. Закончится СССРовским "такие приборы, никому не покажем". А потом с удивлением обнаружится что оказывается эти приборы - всем пофигу и будущее просто определили другие.
Цена ошибки такова, что выгоднее нихрена не делать.
стереотипы, стереотипы...
> стереотипы, стереотипы...Кто о чем, а буратино про рубанок...
не смущает, что про рубанок не он написал?
> не смущает, что про рубанок не он написал?Он намекнул, поскольку сам дрова.
Какие дрова?
> не смущает, что про рубанок не он написал?Зато про стереотипы он очень шаблонно пишет, в каждом втором случае наверное. Так что рубанок, рубанок...
> Зато про стереотипы он очень шаблонно пишет, в каждом втором случае наверное.
> Так что рубанок, рубанок...Нечего на Буратину пенять, коли сам Аноним (никто). ;-)
> То есть рубанок виноват в тупости и злобности буратины? Это прекрасно.Uber FAIL.
Ответ лежит на поверхности - жлобы не хотели влпатить копейки за приватные репозитарии.
Ответ лежит на поверхности - никто не делает review коммитов. Кто помешает, в таком случае, увольняющемуся сотруднику закомиттить видео с записью сексуального акта своего начальника с бобром?
>никто не делает review коммитов.
>Кто помешает, в таком случае, увольняющемуся сотруднику закомиттить видео с записью сексуального акта своего начальника с бобром?Какой отдел у Вас в Компании занят _review_ youtub-ика?
А то, "кто ж помешает-то"tm ?!
>>никто не делает review коммитов.
>>Кто помешает, в таком случае, увольняющемуся сотруднику закомиттить видео с записью сексуального акта своего начальника с бобром?
> Какой отдел у Вас в Компании занят _review_ youtub-ика?вообще‐то, в нормальной компании есть отдел внутренней безопасности. и существует он именно затем, чтобы не надо было делать «review youtub-ика».
pre-commit review?
Нафиг-нафиг.
> pre-commit review?
> Нафиг-нафиг.Пре-комит, пост-комит, и во время написания чтобы обе руки на столе были, а то опять винда получиться )))
Или РеактОС, если левая под столом будет ))
вот, тоже так подумал
На опеннете эта фраза звучит как-то странно. Как бы хорошо, что код открыто публикуется, вопрос - как риски безопасности снизить
> На опеннете эта фраза звучит как-то странно. Как бы хорошо, что код
> открыто публикуется, вопрос - как риски безопасности снизитьнапример, не давать девелоперам credentials для доступа к боевым базам и серверам. потому что зачем? для этого должен быть deploy manager. у которого, в свою очередь, нет права на коммит в девелоперский репозиторий.
понятно, это не защита от злоумышленников, это защита от случайной утечки логинов‐паролей.
> Ответ лежит на поверхности - жлобы не хотели влпатить копейки за приватные репозитарии.Клинический неуч всегда делает неверные выводы из своих и чужих ошибок. Ответ, конечно, лежит на поверхности, но он несколько другой - нельзя авторизационные данные хранить вместе с кодом, мухи должны быть отдельно от всего остального.
Разработчик конечно тот еще орел, но мне кажется первопричина такого явления немного в другом.
Какого ... использовать для таких Public репозитарии.
Они же автоматом синкаются (привет Uber с их требованиями по IP), их ковыряют.Хорошо, допустим они хотели показать всем, вот наш код, нашего сервиса, мол смотрите.
Но для такого можно использовать варианты максимальной изоляции всяких крит. данных от основной репы.
Но по мне - лучше иметь свой, изолированный GitLab для таких вещей.
> Но по мне - лучше иметь свой, изолированный GitLab для таких вещей.Карабас-Барабас хотел быстро, качественно, и чтобы ему доплатили ))
В итоге плётку отжали, и в гримёрке нагадили )
- За выходные запросто можно зарефакторить тута. Дурацкая сикурность, почему я не могу получить доступ к репе из дома?
- А ладно, сделаю
$ git remote add pesonal-repo https://github.org/supermax/corp-app.git
$ git push personal-repo ticker-10500- Запилю и в понедельник меня похвалят %)
> - За выходные запросто можно зарефакторить тута. Дурацкая сикурность, почему я не
> могу получить доступ к репе из дома?Там видать мужики про ssh и vpn не слышали )) А одмин rdp не даёт всем подряд к сервакам снаружи без привязки к ип. Это же так неудобно, с телефона друга на рыбалке коммит не отправить ))
На моей прошлой работе так и было, VPN нет, SSH тоже, все рабочие станции с Windows, почта только через Outlook, никаких IMAP и POP3. И никакого RDP как и внешних IP, работа на удаленных рабочих станциях через Citrix Receiver, с отвратительный проприетарным клиентом под Linux.
> Uber потребовал у GitHub предоставить сведения об IP-адресах, с которых был зафиксирован доступ к определённым репозиториям.Какой-то очень обходной путь.
А у себя они не могут посмотреть с каких IP к ним подключались и сливали данные?