Пароли Git-репозитория языка PHP хранились ненадежно

Разработчик и сопровождающий языка программирования PHP Никита Попов рассказал новые детали об инциденте, связанном с безопасностью git.php.net.

По словам Никиты Попова, когда первый вредоносный коммит был внедрен от имени создателя PHP Расмуса Лердорфа, его первоначальной реакцией было отменить изменение и отозвать доступ на коммит для учетной записи Расмуса. Он исходил из предположения, что учетная запись была скомпрометирована. Но, как Попов понял позже, это действие не имело смысла, потому что не было оснований полагать, что атака произошла через аккаунт Расмуса: любая учетная запись с доступом к репозиторию php-src могла выполнить атаку под вымышленным именем.

Когда второй вредоносный коммит был внедрен уже от имени Никиты Попова, он просмотрел журналы установки gitolite, чтобы определить, какая учетная запись на самом деле использовалась для атаки. Хотя все смежные коммиты были учтены, записи git-receive-pack для двух вредоносных коммитов отсутствовали, что означало, что эти два коммита полностью обошли инфраструктуру gitolite. Это специалисты интерпретировали как вероятное свидетельство взлома сервера.

Вскоре после этого в PHP решили прекратить работу с git.php.net и вместо этого сделать GitHub основным хостом репозитория. По словам Никиты Попова, сохранение собственной инфраструктуры Git потребовало бы настройки нового сервера git.php.net после определения основной причины компрометации. Это заняло бы много времени и нарушило бы разработку PHP. Выбор пал на базовую миграцию на GitHub, поскольку большинство репозиториев уже были зеркальными. 

Согласно заявлению Попова, в то время он не знал, что git.php.net поддерживает отправку изменений не только через SSH (с использованием инфраструктуры gitolite и криптографии с открытым ключом), но и через HTTPS. Последний не использовал gitolite, а вместо этого использовал git-http-backend аутентификации Apache2 Digest в базе данных пользователей master.php.net. 

Основываясь на журналах доступа, в PHP определили, что коммиты были отправлены с использованием HTTPS и аутентификации на основе пароля. Отрывок из соответствующих записей журнала представлен ниже:

[redacted] - rasmus@[redacted] [27/Mar/2021:19:19:23 -0700] "GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1" 401 941
[redacted] - rasmus@[redacted] [27/Mar/2021:19:19:28 -0700] "GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1" 401 941
[redacted] - rasmus [27/Mar/2021:20:56:51 -0700] "GET
/push/php-src.git/info/refs?service=git-receive-pack HTTP/1.1" 200 125315
[redacted] - rasmus [27/Mar/2021:20:58:13 -0700] "POST
/push/php-src.git/git-receive-pack HTTP/1.1" 200 1080
[redacted] - nikita.ppv [28/Mar/2021:09:09:15 -0700] "GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1" 401 941
[redacted] - nikita.ppv [28/Mar/2021:09:09:18 -0700] "GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1" 401 941
[redacted] - nikitappv [28/Mar/2021:09:09:35 -0700] "GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1" 401 941
[redacted] - nikitappv [28/Mar/2021:09:09:36 -0700] "GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1" 401 941
[redacted] - nikita [28/Mar/2021:09:09:50 -0700] "GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1" 401 941
[redacted] - nikita [28/Mar/2021:09:09:53 -0700] "GET
/push/php-src.git/info/refs?service=git-upload-pack HTTP/1.1" 401 941
[redacted] - nikic [28/Mar/2021:09:11:31 -0700] "GET
/push/php-src.git/info/refs?service=git-receive-pack HTTP/1.1" 401 941
[redacted] - nikic [28/Mar/2021:09:11:31 -0700] "GET
/push/php-src.git/info/refs?service=git-receive-pack HTTP/1.1" 401 941
[redacted] - nikic [28/Mar/2021:09:13:28 -0700] "GET
/push/php-src.git/info/refs?service=git-receive-pack HTTP/1.1" 200 123263
[redacted] - nikic [28/Mar/2021:09:13:39 -0700] "POST
/push/php-src.git/git-receive-pack HTTP/1.1" 200 1079

Никита Попов отмечает, что злоумышленнику удавалось успешно проходить аутентификацию с нескольких заходов. И хотя у команды PHP нет никаких конкретных доказательств, возможное объяснение — утечка пользовательской базы данных master.php.net. Вот что уже сделано для повышения безопасности системы: 

• master.php.net переведен на новую систему, работающую под управлением PHP 8, и одновременно переименован в main.php.net.
  Новая система будет поддерживать TLS 1.2;
• реализация перемещена в сторону использования параметризованных запросов, чтобы исключить возможность внедрения SQL-кода;
• пароли теперь хранятся с использованием адаптированной; криптографической хеш-функции формирования ключей bcrypt;
Курс Quality Assurance (QA) від Mate academy.
Курс QA — ідеальний для новачка. Від основ тестування до складних стратегій — опануйте всі технології, щоб жодна помилка не змогла вас оминути. Ми впевнені в якості нашого курсу, тому гарантуємо вам працевлаштування після його завершення.
Зареєструватись на курс
• ранее пароли хранились в формате, совместимом с аутентификацией HTTP Digest (по сути, это простой хеш md5). Все пароли php.net были сброшены. Установить новый пароль можно здесь;
• серверы git.php.net и svn.php.net теперь доступны только для чтения.

Один из пользователей Reddit отметил, что, если это была хеш-атака, и учитывая закономерности HTTP-аутентификации, фактический ключ доступа для пользователей хранился в базе данных в виде обычного текста, что и могло привести к утечке.