S3 Ep95: утечка Slack, натиск Github и постквантовая криптография [аудио + текст]

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

ДУГ.  Утечки из Slack, непослушный код GitHub и постквантовая криптография.

Обо всем этом и многом другом в подкасте Naked Security.

[МУЗЫКАЛЬНЫЙ МОДЕМ]

Добро пожаловать в подкаст, все.

Я Дуг Аамот.

Со мной, как всегда, Пол Даклин.

Павел, как дела сегодня?

---

УТКА.  Супер-пупер, как обычно, Дуг!

---

ДУГ.  Я супер-пупер взволнован, чтобы попасть на эту неделю Техническая история сегмент, потому что…

…ты был там, чувак!

На этой неделе, 11 августа…

---

УТКА.  О нет!

Я думаю, что копейка просто упала ...

---

ДУГ.  Мне даже не нужно говорить год!

11 августа 2003 г. – мир обратил внимание на червя Blaster, поражающего системы Windows 2000 и Windows XP.

Blaster, также известный как Lovesan и MsBlast, использовал переполнение буфера и, возможно, наиболее известен сообщением: «Билли Гейтс, почему вы делаете это возможным? Прекратите зарабатывать деньги и исправьте свое программное обеспечение».

Что случилось, Пол?

---

УТКА.  Что ж, это была эпоха, когда, возможно, мы так серьезно относились к безопасности.

И, к счастью, в наши дни такую ​​ошибку было бы намного сложнее использовать: это было переполнение буфера на основе стека.

И если я правильно помню, серверные версии Windows уже собирались с тем, что называется защита стека.

Другими словами, если вы переполняете стек внутри функции, то, прежде чем функция вернется и нанесет ущерб поврежденному стеку, она обнаружит, что произошло что-то плохое.

Таким образом, программа-нарушитель должна быть закрыта, но вредоносное ПО не запускается.

Но такой защиты не было в клиентских версиях Windows на тот момент.

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

Вы на 2000? Ты на НТ? Вы на XP?

И если это будет сделано неправильно, то произойдет сбой важной части системы, и вы получите предупреждение «Ваша система вот-вот отключится».

---

ДУГ.  Ха, я помню их!

---

УТКА.  Итак, был тот побочный ущерб, который для многих людей был признаком того, что вы забиты инфекциями…

…что может быть извне, например, если вы просто домашний пользователь и у вас дома нет маршрутизатора или брандмауэра.

Но если вы находились внутри компании, наиболее вероятная атака исходила бы от кого-то еще внутри компании, рассылающего пакеты по вашей сети.

Так что, как и в случае с атакой CodeRed, о которой мы говорили за пару лет до этого, в недавнем подкасте, проблема заключалась в масштабе, объеме и скорости этой штуки.

---

ДУГ.  Ладно, это было лет 20 назад.

И если мы повернем часы на пять лет назад, тогда Slack начал протекать хешированные пароли. [СМЕХ]

---

УТКА.  Да, Slack, популярный инструмент для совместной работы…

… у него есть функция, с помощью которой вы можете отправить другим людям ссылку-приглашение присоединиться к вашему рабочему пространству.

И представьте себе: вы нажимаете кнопку с надписью «Создать ссылку», и она создает какой-то сетевой пакет, внутри которого наверняка есть какой-то JSON.

Если у вас когда-либо было приглашение на собрание Zoom, вы будете знать, что в нем есть дата и время, и человек, который вас приглашает, и URL-адрес, который вы можете использовать для собрания, и код доступа, и все такое. вещи - там довольно много данных.

Обычно вы не копаетесь в необработанных данных, чтобы посмотреть, что там есть — клиент просто говорит: «Эй, вот встреча, вот подробности. Вы хотите принять/возможно/отказаться?»

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

Итак, ни URL, ни имя, ни дата, ни время…

…но *хэш пароля приглашающего пользователя* [СМЕХ]

---

ДУГ.  Хммммм.

---

УТКА.  Я тебя не устраиваю!

---

ДУГ.  Звучит плохо…

---

УТКА.  Да, это действительно так, не так ли?

Плохая новость в том, как, черт возьми, это туда попало?

И, как только он оказался там, как, черт возьми, он оставался незамеченным в течение пяти лет и трех месяцев?

На самом деле, если вы посетите статью о Naked Security и посмотрите на полный URL статьи, вы заметите, что в конце написано, blahblahblah-for-three-months.

Потому что, когда я впервые прочитал отчет, мой разум не хотел видеть его в 2017 году! [СМЕХ]

Это было с 17 апреля по 17 июля, поэтому там было много «17».

И мой разум выкинул 2017 год как год начала — я неправильно истолковал его как «с апреля по июль *этого года*» [2022].

Я подумал: «Вау, *три месяца*, а они и не заметили».

А потом первый комментарий к статье был, «Кхм [КАШЕЛЬ]. На самом деле это было 17 апреля *2017*».

Вот это да!

Но кто-то разобрался с этим 17 июля [2022 года], и Slack, к их чести, починил в тот же день.

Типа: «О, черт возьми, о чем мы думали?!»

Так что это плохие новости.

Хорошая новость в том, что, по крайней мере, это были *хешированные* пароли.

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

Идея этого двояка.

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

Во-вторых, вы не можете предварительно вычислить словарь известных хэшей для известных входных данных, потому что вам нужно создать отдельный словарь для каждого пароля *для каждой соли*.

Так что взлом хешированных паролей — нетривиальное упражнение.

Сказав это, вся идея состоит в том, что они не должны быть достоянием общественности.

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

Итак, яйцо на лице Slack!

Slack говорит, что пострадал примерно один из 200 пользователей, или 0.5%.

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

Итак, идите и смените свой пароль в любом случае… вы тоже можете это сделать.

---

ДУГ.  Хорошо, мы также говорим: если вы не используете менеджер паролей, рассмотрите возможность его приобретения; и включите 2FA, если можете.

---

УТКА.  Я думал, тебе это понравится, Даг.

---

ДУГ.  Да!

А затем, если вы Slack или подобная компания, выберите авторитетный алгоритм «соли-хеш-и-растяжения» при работе с паролями самостоятельно.

---

УТКА.  Да.

Самое важное в ответе Slack, и то, чего мне не хватало, это то, что они просто сказали: «Не волнуйтесь, мы не только хэшировали пароли, но и посолили их».

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

И если вы укажете, какой алгоритм вы используете и с какими параметрами.. например, PBKDF2, bcrypt, scrypt, Argon2 — это самые известные алгоритмы «соль-хэш-растягивание» паролей.

Если вы на самом деле указываете, какой алгоритм вы используете, то: [A] вы более открыты, и [B] вы даете потенциальным жертвам проблемы шанс самим оценить, насколько опасным, по их мнению, это могло быть .

И такая открытость действительно может очень помочь.

Слэк этого не делал.

Они просто сказали: «О, они были соленые и перетертые».

Но чего мы не знаем, так это того, добавили ли они два байта соли, а затем хэшировали их один раз с помощью SHA-1…

…или у них было что-то более устойчивое к взлому?

---

ДУГ.  Продолжая тему плохих вещей, мы замечаем развивающуюся тенденцию, когда люди внедрение плохих вещей в GitHub, просто чтобы посмотреть, что произойдет, подвергая риску…

…у нас есть еще одна такая история.

---

УТКА.  Да, кто-то, кто сейчас якобы вышел в Твиттере и сказал: «Не волнуйтесь, ребята, никакого вреда. Это было только для исследования. Я собираюсь написать отчет, выделиться из Blue Alert».

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

Итак, вещи, которые действительно могут навредить, если вы установите один из этих пакетов.

Давая им законно выглядящие имена…

…заимствуя, по-видимому, историю коммитов настоящего проекта, чтобы вещь выглядела гораздо более законной, чем вы могли бы ожидать, если бы она просто появилась с «Эй, скачай этот файл. Ты знаешь чего хочешь!"

Действительно?! Исследовательская работа?? Мы этого еще не знали?!!?

Теперь вы можете возразить: «Ну, Microsoft, которой принадлежит GitHub, что они делают, чтобы людям было так легко загружать такие вещи?»

И в этом есть доля правды.

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

Но это будет немного преувеличением, чтобы сказать: «О, это все вина Microsoft».

На мой взгляд, еще хуже сказать: «Да, это настоящее исследование; это действительно важно; мы должны напомнить людям, что это может произойти».

Что ж, [A] мы это уже знаем, большое вам спасибо, потому что многие люди делали это раньше; мы получили сообщение громко и ясно.

И [B] это *не* исследование.

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

Для меня это больше похоже на «большое жирное оправдание», чем на законную мотивацию для исследований.

Итак, моя рекомендация: если вы думаете, что это *является* исследованием, и если вы полны решимости делать что-то подобное снова и снова, *не ждите большого сочувствия*, если вас поймают.

---

ДУГ.  Хорошо – мы вернемся к этому, и читатель прокомментирует в конце шоу, так что оставайтесь.

Но сначала поговорим о светофорыи какое отношение они имеют к кибербезопасности.

---

УТКА.  Ааа, да! [СМЕХ]

Ну, есть такая штука, как TLP. Протокол светофора.

И TLP — это то, что вы могли бы назвать «протоколом исследования кибербезопасности человека», который помогает вам маркировать документы, которые вы отправляете другим людям, чтобы дать им намек на то, что вы надеетесь, что они будут (и, что более важно, на что вы надеетесь, что они * не*) делать с данными.

В частности, насколько широко они должны его распространять?

Это что-то настолько важное, что вы можете заявить об этом миру?

Или это потенциально опасно, или это потенциально включает в себя некоторые вещи, которые мы пока не хотим публиковать… так что держите это при себе?

И началось это с: TLP:RED, что означало «Держи это при себе»; TLP:AMBER, что означало «Вы можете распространять его внутри своей компании или среди своих клиентов, которым, по вашему мнению, может быть срочно необходимо это узнать»; TLP:GREEN, что означало: «Хорошо, вы можете позволить этому широко распространиться в сообществе кибербезопасности».

И, TLP:WHITE, что означало: «Ты можешь рассказать кому угодно».

Очень полезно, очень просто: КРАСНЫЙ, ЯНТАРНЫЙ, ЗЕЛЕНЫЙ… метафора, которая работает глобально, не беспокоясь о том, в чем разница между «секретно» и «конфиденциально», в чем разница между «конфиденциально» и «секретно», обо всех этих сложных вещах, которые нужно много законов вокруг него.

Что ж, TLP только что получил некоторые модификации.

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

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

Итак, TLP:WHITE только что стал TLP:CLEAR, что, на мой взгляд, является гораздо более подходящим словом, потому что оно говорит: «Вы можете использовать эти данные», и это намерение заявлено, гм, очень ясно. (Извините, не удержался от каламбура.)

И есть дополнительный слой (поэтому он немного испортил метафору — теперь это *пятицветный* светофор!).

Есть специальный уровень, который называется TLP:AMBER+STRICT, и это означает: «Вы можете поделиться этим внутри своей компании».

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

Но TLP:AMBER+STRICT означает, что, хотя вы можете распространять ее внутри своей организации, *пожалуйста, не говорите своим клиентам или клиентам*, или даже людям вне компании, что, по вашему мнению, может быть необходимо знать.

Для начала держите его в более тесном сообществе.

TLP:AMBER, как и раньше, означает: «Хорошо, если вы чувствуете, что вам нужно сообщить своим клиентам, вы можете это сделать».

И это может быть важно, потому что иногда вы можете захотеть сообщить своим клиентам: «Эй, у нас есть исправление. Вам нужно будет принять некоторые меры предосторожности, прежде чем появится исправление. Но поскольку это довольно деликатно, можем ли мы попросить вас пока не рассказывать об этом миру?»

Иногда слишком раннее сообщение миру на самом деле играет на руку мошенникам больше, чем на руку защитникам.

Итак, если вы отвечаете за кибербезопасность, я предлагаю вам пойти: https://www.first.org/tlp

---

ДУГ.  И вы можете узнать больше об этом на нашем сайте, nakedsecurity.sophos.com.

И если вы ищете какое-то другое легкое чтение, забудьте о квантовой криптографии… мы переходим к постквантовая криптография, Павел!

---

УТКА.  Да, мы уже говорили об этом несколько раз в подкасте, не так ли?

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

Другими словами, вместо того, чтобы брать 2²⁵⁶ пытается найти файл с определенным хэшем, возможно, вы сможете сделать это всего за («просто»!) 2¹²⁸ пытается, что является квадратным корнем.

Явно намного быстрее.

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

Итак, вместо того, чтобы брать, скажем, 2¹²⁸ дней на взлом [НАМНОГО БОЛЬШЕ, ЧЕМ НАСТОЯЩИЙ ВОЗРАСТ ВСЕЛЕННОЙ], на взлом может уйти всего 128 дней.

Или вы можете заменить «дни» на «минуты» или что-то еще.

И, к сожалению, этот алгоритм логарифмического времени (называемый Алгоритм квантовой факторизации Шора)…теоретически это может быть применено к некоторым современным криптографическим методам, особенно к тем, которые используются для криптографии с открытым ключом.

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

Особенно логарифмический, потому что он настолько ускоряет потенциальные атаки, что криптографические ключи, о которых мы сейчас думаем: «Ну, никто никогда этого не поймет», могут стать раскрытыми на каком-то более позднем этапе.

Во всяком случае, NIST, Национальный Институт Стандартов и Технологий в США уже несколько лет проводит конкурс, чтобы попытаться стандартизировать некоторые общедоступные, незапатентованные, хорошо изученные алгоритмы, которые будут устойчивы к этим волшебным квантовым компьютерам, если они когда-либо появятся.

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

У них крутые имена, Дуг, так что я должен их зачитать: CRYSTALS-KYBER, CRYSTALS-DILITHIUM, FALCONи SPHINCS+. [СМЕХ]

Так что у них классные имена, как минимум.

Но в то же время в NIST решили: «Ну, это всего четыре алгоритма. Что мы сделаем, так это выберем еще четырех потенциальных второстепенных кандидатов и посмотрим, пройдет ли кто-нибудь из них».

Таким образом, сейчас существует четыре стандартизированных алгоритма и четыре алгоритма, которые могут быть стандартизированы в будущем.

Или их *было* четыре на 5 июля 2022 года, и один из них был SIKE, Короче для суперсингулярная инкапсуляция ключа изогении.

(Нам понадобится несколько подкастов, чтобы объяснить суперсингулярные изогении, так что мы не будем беспокоиться. [СМЕХ])

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

Так что, к счастью, незадолго до того, как он был или мог быть стандартизирован, два бельгийских криптографа выяснили: «Знаете что? Мы думаем, что у нас есть способ обойти это, используя вычисления, которые занимают около часа, на довольно среднем процессоре, используя только одно ядро».

---

ДУГ.  Думаю, лучше выяснить это сейчас, чем после стандартизации и распространения в дикой природе?

---

УТКА.  В самом деле!

Я полагаю, если бы это был один из уже стандартизированных алгоритмов, им пришлось бы отменить стандарт и придумать новый?

Кажется странным, что это не заметили в течение пяти лет.

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

Хорошее напоминание о том, что если вы *когда-нибудь* задумывались о создании собственной криптографии...

---

ДУГ.  [СМЕЕТСЯ] Нет!

---

УТКА.  ..несмотря на то, что мы N раз говорили вам в подкасте Naked Security: «Не делайте этого!»

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

Так что, это определенно не выглядит хорошо для этого SIKE алгоритм.

И кто знает, может быть, она будет отозвана?

---

ДУГ.  Мы будем следить за этим.

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

Роб пишет:

«В комментариях есть немного мела и сыра, и я ненавижу это говорить, но я искренне вижу обе стороны спора. Это опасно, хлопотно, трата времени и ресурсов? Да, конечно. Это то, что сделали бы преступники? Да да это. Напоминает ли это всем, кто использует GitHub или любую другую систему репозитория кода, если на то пошло, что безопасное путешествие по Интернету требует здоровой степени цинизма и паранойи? Да. Часть меня, системного администратора, хочет приветствовать обнаружение риска. Как системный администратор группы разработчиков, я теперь должен убедиться, что все недавно просмотрели все пулы на предмет сомнительных записей».

---

УТКА.  Да, спасибо, RobB, за этот комментарий, потому что я думаю, важно видеть обе стороны спора.

Были комментаторы, которые просто говорили: «Что, черт возьми, в этом проблема? Это круто!"

Один человек сказал, «Нет, на самом деле, это тестирование пера хорошее и полезное. Радуйтесь, что их разоблачают сейчас, а не поднимают свою уродливую голову от настоящего злоумышленника».

И мой ответ на это таков: «Ну, на самом деле это *нападение*».

Просто потом кто-то вышел и сказал: «О, нет, нет. Никто не пострадал! Честно говоря, я не был непослушным».

Я не думаю, что вы обязаны покупать это оправдание!

Но в любом случае это не тестирование на проникновение.

Мой ответ должен был сказать очень просто: «Ответственные тестировщики на проникновение всегда действуют [A] только после получения явного разрешения и [B] в пределах поведенческих ограничений, оговоренных заранее».

Вы не просто придумываете свои собственные правила, и мы обсуждали это раньше.

Итак, как сказал другой комментатор, который, я думаю, является моим любимым комментарием… Экурб сказал, «Я думаю, что кто-то должен ходить от дома к дому и бить окна, чтобы показать, насколько на самом деле неэффективны дверные замки. Это просрочено. Кто-нибудь, прыгайте на это, пожалуйста».

А потом, на случай, если вы не поняли, что это сатира, ребята, говорит он, "Не!"

---

УТКА.  Я понимаю, что это хорошее напоминание, и я понимаю, что если вы являетесь пользователем GitHub, и как производитель, и как потребитель, вы можете кое-что сделать.

Перечислим их в комментариях и в статье.

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

И не просто слепо потребляйте материал, потому что вы сделали поиск, и он «выглядел так», что это может быть правильный проект.

Да, мы все можем чему-то научиться на этом, но действительно ли это считается обучением или это просто то, чему мы все равно должны научиться?

Я думаю, что это *не* обучение.

Это просто *недостаточно высокий стандарт*, чтобы считаться исследованием.

---

ДУГ.  Отличная дискуссия вокруг этой статьи, и спасибо, что прислали ее, Роб.

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

Вы можете по электронной почте tips@sophos.com; вы можете прокомментировать любую из наших статей; или вы можете связаться с нами в соц. @NakedSecurity.

Это наше шоу на сегодня – большое спасибо за внимание.

Для Пола Даклина я Дуг Аамот, напоминающий вам, до следующего раза, чтобы…

---

ОБА.  Оставайтесь в безопасности!

[МУЗЫКАЛЬНЫЙ МОДЕМ]