FSF рассказал об ошибке, которая привела к утечке данных04.11.2017 17:45

В течение нескольких минут после получения отчета мы удалили файл и начали проверку defectivebydesign.org и остальных наших сайтов. Файл не содержал никаких паролей или их хэшей, финансовой информации, почтовых адресов или информации о пользователях, которые взаимодействовали с сайтом без регистрации.

В пятницу, 27 октября, как только мы были достаточно уверенны, мы поняли масштаб проблемы и устранили самые насущные проблемы; мы отправили уведомление по электронной почте на каждый адрес, который был в файле резервной копии базы данных. Мы объяснили, что произошло, взяли на себя ответственность и извинились.

Если вы не получили такое электронное письмо, ваш адрес не находился в открытом файле.

В файле были (как из профилей пользователей, так и из спам‐ботов):

• ≈28 000 адресов электронной почты;
  
• имена контактов;
  
• некоторые IP‐адреса, связанные с комментариями к сообщениям;
  
• ≈120 номеров телефонов.

Хотя часть этой информации была для пользователей изначально публичной, некоторая часть оставалась приватной.

Я (John Sullivan — прим. переводчика) и остальные сотрудники FSF очень сожалеем об этой ошибке. Мы знаем, насколько важна конфиденциальность наших сторонников; мы каждый день сражаемся от вашего имени против ограничительных технологий, которые угрожают вам. Мы также не верим в то, что скрывали наши ошибки, поэтому мы хотели как можно скорее сообщить всем пострадавшим, а затем поделиться своей ошибкой и тем, чему мы научились.

Несмотря на то, что мы небольшая команда, такая ошибка абсолютно неприемлема. С 2012 года мы значительно улучшили наши методы обеспечения безопасности, и в свете этой неудачи мы будем глубже смотреть на то, что еще нам нужно делать.

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

Резервная копия базы данных Drupal defectivebydesign.org была сделана с помощью модуля backup-migrate в 2012 году, что, вероятно, должно было помочь перенести сайт на новый хост. Мы не смогли удалить или перенести этот файл.

В 2014 году, или некоторое время до этого, имя каталога нашей установки Drupal было вручную изменено как часть обновления. Однако мы не обновили часть нашей конфигурации Apache, которая активировала файлы .htaccess для определенных каталогов. Файл .htaccess Drupal обычно скрывает файлы путём запрета доступа к содержимому директорий. Сайт работал нормально, несмотря на отключенный файл .htaccess, потому что наша основная конфигурация Apache содержала функциональность, обычно выполняемую этим файлом. Мы также ошибочно не получили другого файла .htaccess, чтобы полностью отключить доступ к резервной копии. В результате бекап остался открытым.

В документации для backup-migrate есть «ОЧЕНЬ ВАЖНОЕ ЗАМЕЧАНИЕ БЕЗОПАСНОСТИ», указывающее, что «резервное копирование» и «миграция» пытается защитить бекапы с помощью файла .htaccess», о чём мы успешно забыли.

В настоящее время мы не используем этот модуль и вместо этого создаем резервную копию сайта как часть наших глобальных процедур резервного копирования. Мы рассматриваем и улучшаем несколько других политик и процедур, чтобы избежать повторения подобных ошибок и обнаружить их, если они будут сделаны. Это включает, например, удаление персональных данных с сайтов, на которых мы больше не используем или нуждаемся в них.

Спасибо всем за вашу поддержку и доверие. Если у вас есть опыт в администрировании систем и вы заинтересованы в добровольчестве, чтобы помочь, пожалуйста, сообщите нам на sysadmin@gnu.org.