LINUX.ORG.RU

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

 


1

3

В среду, 25 октября, мы (FSF — прим. переводчика) получили электронное письмо, сообщающее нам, что старый файл резервной копии базы данных Drupal стал общедоступным на сайте defectivebydesign.org, основанном Free Software Foundation. Этот файл резервной копии содержит контактную информацию и другие данные, накопленные за 2007—2012 года, которые не должны быть общедоступными.

В течение нескольких минут после получения отчета мы удалили файл и начали проверку 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.

>>> Подробности

Мы объяснили, что произошло, взяли на себя ответственность и извинились

Вот это круто по-моему. Не стали скрывать и замалчивать.

meequz ★★ ()
Ответ на: комментарий от meequz

Вот это круто по-моему. Не стали скрывать и замалчивать.

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

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

fornlr ★★★★★ ()
Последнее исправление: fornlr (всего исправлений: 2)
Ответ на: комментарий от fornlr

Всё нормально. FSF это не про безопасность и качество софта, а про свободу. Поэтому софт может быть каким угодно дырявым кривым и глючным, но зато свободным. Их репутация на мой взгляд не пострадала.

Reset ★★★★★ ()
Ответ на: комментарий от fornlr

defectivebydesign.org

борцуны все такие, а сами...

Что «сами»? Если вы Ъ и не пошли смотреть, что́ такое DbD, то сообщаю, что никакого отношения к пропаганде защиты персональных данных оно не имеет.

Это про борьбу с DRM’ом.

Zmicier ★★★★ ()
Ответ на: комментарий от fornlr

Даже смешнее

Apple operates a network of services for managing contacts, calendars and correspondence across all its devices. This amounts to a huge vacuum sucking up users' personal information and storing it in a centralized server farms that are vulnerable to attacks.

Лицемеры же.

fornlr ★★★★★ ()
Ответ на: комментарий от fornlr

Как не имеет?

Натурально. Это особо выделенная кампания по искоренению DRM’а. Так что «а сами» они бы были, например, если бы по ошибке разместили у себя на страничке ролик с Ютьюба.

А если хотите позлорадствовать утечке э-адресов подписчиков, подождите пока что-нибудь утечет у Роскомнадзора.

Там у бородатых
бородатых

?

написано «Apple devices threaten your privacy»

А там еще не написано, часом, что розетка током бьется?

Zmicier ★★★★ ()
Ответ на: комментарий от Reset

Как всегда.

Утечка данных из крупной компании: «обычная ситуация», «случается довольно часто», «несерьёзная проблема».

Утечка данных из FSF: «дырявый швабодный софт!!1111», «ниасиляторы», «борцуны за свободу и приватность сливают данные, КАКАЯ ИРОНИЯ!!».

Типичное лицемерие проприетарщиков.

pelmeshechka ()
Ответ на: комментарий от pelmeshechka

Утечка данных из крупной компании: «обычная ситуация», «случается довольно часто», «несерьёзная проблема».

Сам выдумал, сам посмеялся.

Если уж обосрались, то не важно кто :)

fornlr ★★★★★ ()
Последнее исправление: fornlr (всего исправлений: 1)
Ответ на: комментарий от pelmeshechka

Утечка данных из крупной компании: «обычная ситуация», «случается довольно часто», «несерьёзная проблема».
Типичное лицемерие проприетарщиков.

Назови хоть один такой пример.

AP ★★★★★ ()

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

Napilnik ★★★★★ ()
Ответ на: комментарий от BruteForce

От пожатия архиватором я бы сам прихренел, если чесна.

Такие у нас в линуксах архиваторы, раз чуть более сложную задачу ими выполнить проблема. А в том же винраре есть несколько степеней сжатия и для их применения не нужно полгода читать маны а потом после обновления ругаться: почикали нужный функционал. Для больших объёмов данных рулит архивация с минимальным сжатием, без сжатия, разделение архива на куски ну и пароли. И что хорошо в «проклятой проприетарщине», пароль можно написать в комментарии архива - человек его прочитает, а программы этим не заморачиваются.

Napilnik ★★★★★ ()
Ответ на: комментарий от Zmicier

Нет, Апач не defective by design, он defective by mistake.

Ага, обосрались админы FSF, а виноват апач, ФС, права в стиле POSIX и разработчик ведра Линус Торвальдс лично. Плохие танцоры такие танцоры.

h578b1bde ★☆ ()
Ответ на: комментарий от pelmeshechka

Утечка данных из крупной компании: «обычная ситуация», «случается довольно часто», «несерьёзная проблема».
Утечка данных из FSF: «дырявый швабодный софт!!1111», «ниасиляторы», «борцуны за свободу и приватность сливают данные, КАКАЯ ИРОНИЯ!!».

Эскобар.жпг

h578b1bde ★☆ ()
Ответ на: комментарий от d_a

Вот. А на лоре за 20 лет ни одного слива ПД! ... Ну, правда же? Anyone?

www.linux.org.ru/forum/web-development/9374214?cid=9378107
www.linux.org.ru/forum/web-development/9374214?cid=9378227
Ой.

h578b1bde ★☆ ()
Последнее исправление: h578b1bde (всего исправлений: 1)
Ответ на: комментарий от h578b1bde

как символично получилось-то
defectivebydesign

Нет, Апач не defective by design, он defective by mistake.

Ага, обосрались админы FSF, а виноват апач...

Судя по всему...

h578b1bde ★☆ (05.11.2017 1:20:08) (Пишет быстрее, чем думает)

... это вы пытаетесь наехать на меня, а вовсе не горячо мне поддакиваете?

Zmicier ★★★★ ()
Ответ на: комментарий от Zmicier

Впрочем, возможно, мне следовало и согласиться с товарищем thunar — таки да, не человеческим фактором единым, но и «defective by design». Только не Апач, разумеется, а Друпал.

Zmicier ★★★★ ()
Последнее исправление: Zmicier (всего исправлений: 1)
Ответ на: комментарий от Zmicier

h578b1bde ★☆ (05.11.2017 1:20:08) (Пишет быстрее, чем думает)

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

Апач не defective by design, он defective by mistake.

Хм…

h578b1bde ★☆ ()
Ответ на: комментарий от Zmicier

За 5 лет не смогли удалить совершенно ненужный файл с устаревшими данными в публичном каталоге

«defective by design». Только не Апач, разумеется, а Друпал.

Опять поиски непричастных.

h578b1bde ★☆ ()
Ответ на: комментарий от h578b1bde

Очевидно, вопрос в том, как он вообще там оказался.

Однако я не особо знаком с Друпалом, а потому судить не могу. Безусловно, я погорячился: верить на слово Салливану здесь безоговорочно не стоит — поскольку дело пустяковое, куда удобнее стопроцентно взять вину на себя, чем указывать на какие-то более глубинные причины.

Но вам-то определенно стоило бы писать помедленнее. :-) Хотя бы что бы не выдавать взаимоисключающие тезисы подряд — сначала «решето» и «defective by design» и немедленно: «админы облажались».

Zmicier ★★★★ ()
Ответ на: комментарий от Zmicier

Хотя бы что бы не выдавать взаимоисключающие тезисы подряд — сначала «решето» и «defective by design» и немедленно: «админы облажались»

В данном случае „defective by design” — это такое рекурсивное подшучивание над „defective by design”.

h578b1bde ★☆ ()
Ответ на: комментарий от h578b1bde

Я не спорю, в наблюдении, что в Defective by Design пользуются программами, которые таки defective by design (пусть и в другом смысле), есть свое изящество.

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

А удивило меня то, как вы немедля после этого наблюдения стали яро отстаивать диаметрально противоположное.

Zmicier ★★★★ ()
Ответ на: комментарий от Zmicier

Я не спорю, в наблюдении, что в Defective by Design пользуются программами, которые таки defective by design (пусть и в другом смысле), есть свое изящество.

Нет, под „defective by design” имелась в виду организация работы с одноимённым сайтом, а не программы как инструменты этой работы, ведь решето же не в них.

Более того, вы меня уже почти убедили, что в нем есть и доля истины

Разве? Я вроде и не пытался.

А удивило меня то, как вы немедля после этого наблюдения стали яро отстаивать диаметрально противоположное.

Конечно можно винить архитекторов и строителей в том что туалет они разместили в самом конце коридора, но если добежать туда не успел — штаны придётся стирать самому.

h578b1bde ★☆ ()