Вчера Hacker News взорвались новостями о взломе GitHub . Желая узнать, о чем идет речь, я начал со стороны GitHub :
Пользователь GitHub использовал уязвимость безопасности в форме обновления открытого ключа, чтобы добавить свой открытый ключ в организацию rails. Затем он смог отправить новый файл в проект в качестве демонстрации этой уязвимости.
Как только мы обнаружили атаку, мы удалили неавторизованный ключ и заблокировали пользователя.
Моя уверенность в ясности истории GitHub рассеялась, когда я прочитал один из комментариев :
Вы действительно ничего не «обнаружили». Вам сообщили. Это также не было нападением.
«Атакующий» не только не нанес никакого реального урона, но его постоянно игнорировали.
Автор этого комментария, Крис Экки, также сделал более полное сообщение в блоге об инциденте .
«Злоумышленник», о котором идет речь, — это Егор Хомаков (его учетная запись была восстановлена), и он действительно раскрыл уязвимость за несколько дней до того, как продемонстрировал ее . Есть несколько фактов, которые стоит отметить заранее:
- Это не была уязвимость безопасности открытого ключа, как предполагает заголовок поста GitHub.
- Егор не является носителем английского языка, что могло бы затруднить оценку потенциального воздействия его открытия.
- Его фактически не игнорировали, но он был довольно твердо уволен (ссылаясь на предыдущее обсуждение ).
Сказать кому-то, что он неправ, только подогревает их желание доказать, что они правы. Неудивительно, что следующим шагом Егора было продемонстрировать уязвимость.
Я хотел бы объяснить уязвимость, но вместо того, чтобы показывать вам какой-либо код, я хочу, чтобы вы поняли основные моменты, потому что он чрезвычайно прост. Если у вас есть учетная запись GitHub, вы можете управлять своими ключами SSH . Форма для добавления нового ключа выглядит примерно так (отредактировано для ясности):
<form method="post" action="/account/public_keys">
<input type="hidden" value="412e11d5317627e48a4b0615c84b9a8f" name="authenticity_token" />
<dl>
<dt>Title</dt>
<dd><input type="text" name="public_key[title]" /></dd>
<dt>Key</dt>
<dd><textarea name="public_key[key]" /></dd>
</dl>
<input type="submit">Add key</input>
</form>
Аутентификатор authenticity_token почти наверняка является анти-CSRF-токеном , поэтому он не усложняет этот эксплойт.
Все, что сделал Егор, это изменил свою форму, добавив следующее:
<input type="hidden" name="public_key[user_id]" value="4223" />
User_id проекта Rails — 4223, поэтому он выбрал его. (Он считает, что это проблема Rails, и с этим трудно поспорить.) Отправив этот user_id, его открытый ключ был добавлен в другую учетную запись. Хлоп!
Для тех из вас, кто более знаком с PHP, представьте такую функцию, как register_globals, но вместо того, чтобы вставлять данные произвольной формы в глобальное пространство имен, она вводит данные произвольной формы в базу данных. Это также можно назвать opt-in SQL инъекцией , но даже это слишком щедро, потому что это гораздо легче использовать, чем уязвимость SQL инъекций.
Егор отмечает, что эта уязвимость уникальна для Rails :
Только в Rails-приложении есть такая ошибка.
Желая лучше понять, почему Rails отказывается это исправить , я изучил массовое назначение , соответствующую функцию и нашел сообщение с прошлого года :
Если вы используете Rails и хотите быть в безопасности, вы должны защищаться от массовых назначений. По сути, не объявляя attr_accessible или attr_protected, злоумышленники могут установить любое значение столбца в вашей базе данных, включая внешние ключи и защищенные данные.
Хотя несправедливо ожидать, что Rails предотвратит ошибки, это выглядит как очевидный случай, когда он способствует небезопасности. Как прокомментировал один человек :
Rails это все о конвенциях. Сломанный по умолчанию не очень хорошее соглашение.
Иегуда Кац предложил решение, которое людям нравится. Мы надеемся, что это событие поможет поднять планку того, что ожидается от фреймворка. Когда Zend Framework был впервые анонсирован, я составил список пожеланий , потому что я думаю, что фреймворки идеально подходят для того, чтобы помочь разработчикам писать более безопасный код. Rails не является исключением.
Если вам интересно больше узнать об этом, вот несколько ссылок:
- Уязвимость массового назначения — как заставить dev. определить attr_accesible?
Проблема GitHub, где Егор впервые раскрывает уязвимость.
- вау, как я могу совершить в мастер? O_o
Егор привержен Rails, демонстрируя уязвимость.
- Политика ответственного раскрытия информации
Последующее сообщение GitHub, в котором упоминается их новая
политика ответственного объявления .
- «Егор, прекрати взламывать GH»
Оригинальный пост Егора, смутно описывающий то, что он смог сделать, и цитирующий тот факт, что он чувствует себя проигнорированным.
- я разочарован, github
Второй пост Егора, где он провозглашает свою любовь к GitHub и разочаровывает их ответом, приостанавливая его аккаунт.
- Как
Последний пост Егора, раскрывающий подробности подвига.
- Комментарий Макса Бернштейна
Ссылается на беседу по электронной почте с Егором, где Егор утверждает, что он написал GitHub по электронной почте об уязвимости и не получил ответа.
- Как Хомаков взломал GitHub и строку кода, которая могла предотвратить его
Суть из Питера Никси, который объясняет одну строку кода, которая может предотвратить эту уязвимость в ваших собственных приложениях Rails.