безопасность

Исследователи из CWI и Гугла представили практическую атаку на SHA1.

SHA1 — это хэш-функция, то есть алгоритм, создающий цифровой отпечаток файла. Редактируешь хоть одну букву в гигантском файле и отпечаток меняется радикально, никак не перепутаешь. Файлы большие, а отпечатки — маленькие. Теория информации и теория множеств доказывает, что в такой ситуации всё-таки существуют два разных файла, имеющих один и тот же отпечаток. Вся суть хэш-функций в том, чтобы подобрать второй файл было как можно сложнее, читай практически невозможно.

SHA1 придумали в 1995 году в NSA (том самом агенстве национальной безопасности США) и с тех пор он активно использовался для большинства HTTPS-сертификатов в интернете. В 2005-м году исследователи обнаружили слабость в алгоритме, позволявшую теоретически произвести атаку на коллизии — подобрать второй файл с таким же отпечатком SHA1, что и у заданного первого файла. Начиная с 2010 сертификаты начали по-умолчанию использовать SHA2 или SHA3 — более свежие версии алгоритмов.

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

Тут же можно самому скачать две разные PDF-ки, у которых совпадают SHA1. Довольно мощное впечатление.

Теперь модно давать крупным атакам имя и делать персональные сайты-объяснения. Встречайте https://shattered.io/

В суперкомпьютерной платформе IBM стоимостью 300 миллионов долларов нашли уязвимость, позволяющую украсть петабайты пользовательских данных. (Тот самый адов бигдата.)

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

Это к вопросу о безопасности.

Статья достойна прочтения целиком - сколько они патчили ошибку и сколько заплатили нашедшему - не буду спойлить.

https://wycd.net/posts/2017-02-21-ibm-whole-cluster-privilege-escalation-disclosure.html

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

Разбавим томный рабочий день https://github.com/search?utf8=%E2%9C%93&q=remove+password&type=Commits&ref=searchresults

Короткая (14 страниц A4) и познавательная статья про безопасность в гугле: https://cloud.google.com/security/security-design/
Проходится «по верхам» обеспечения безопасности такого монстра, как Google.

Мне было особенно интересно про аутентификацию/авторизацию на уровне общения сервисов друг с другом (внутри есть больше подробностей про это):

Each service that runs on the infrastructure has an associated service account identity. A service is provided cryptographic credentials that it can use to prove its identity when making or receiving remote procedure calls (RPCs) to other services. These identities are used by clients to ensure that they are talking to the correct intended server, and by servers to limit access to methods and data to particular clients.

Доброе утро.

PHPMailer (этой библиотекой для отправки писем пользуются буквально миллионы сайтов) содержит критическую уязвимость Remote Code Execution из-за забытого эскейпинга поля from.

Вкратце: если сайт даёт вписать адрес отправителя письма и использует уязвимую библиотеку для их отправки — то атакующий сможет выполнить любую команду на сервере с правами сайта (например, удалить сайт или отправлять с него спам).

Мне особенно интересны 2 момента:

1. Dawid Golunski сообщил об ошибке публично 25.12.2016, но пока не пишет, в чем конкретно заключается уязвимость и не показывает PoC код [proof of concept, пример кода, эксплуатирующего уязвимость]. Это, очевидно, сделано для того, чтобы скрипткиддисы [малокомпетентные хакеры (kiddie — ребенок)] не использовали его пример как инструкцию к действию. При этом понять, в чем заключалась уязвимость, можно просто посмотрев на коммит, исправляющий эту ошибку.

2. Прикольно, как относятся к своим пользователям разные проекты. Drupal (популярная CMS, движок для сайта) не включает в себя PHPMailer напрямую. Тем не менее, они выпустил PSA (public security advisory, условно письмо АААА всем обновляться срочно) через 12 часов после публичного описания ошибки, Joomla сделала это через сутки, а Wordpress не написал ничего до сих пор. Я попытался найти публичный security advisory list для Wordpress и угадайте что?

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

Как много хакнутых сайтов мы увидим в ближайшие месяцы?

Мне кажется очевидным, что криптографию нужно использовать готовую, но как мы видим на примере телеграма — с этим согласны не все 👀 https://eprint.iacr.org/2015/1177.pdf

Хорошая вводная статья о том, сколько всего нужно держать в голове при программировании криптографии http://loup-vaillant.fr/articles/rolling-your-own-crypto

Кстати, приложенная классическая картинка отвечает на популярный вопрос «как разобраться в *** за 21 день»

Свежее обновление MacOS и Google Chrome перестали доверять сертификатам от WoSign и StartCom. Думаю, любой стартап в какой-то момент своей истории использовал бесплатные сертификаты от StartSSL, так что событие ого-го.

История не новая — у чуваков было очень много багов, позволявших обходить валидацию доменов целиком и выпускать сертификаты для совершенно левых доменов (как насчет левого сертификата для github.com?). Последней каплей стало то, что WoSign купил StartCom и никому об этом не сказал, а когда это всплыло — пытался скрыть. Решение гугла было объявлено 31 октября, решение Apple — 30 ноября и вот оно постепенно доезжает до конечных пользователей. Если ещё используете эти сертификаты где-либо — пришло время их менять прямо сейчас.

Хорошо, что теперь уже нормально работает Let's Encrypt. Для массового продакшена его использовать рано, но для side-проектов и временных доменов — идеальное решение.

Пишу, потому что сегодня сам обжегся — у некоторых редакторов отвалились сокеты во внутренней админке. Конечно, основной EV (extended validation) сертификат Медузы куплен у Comodo. Но сервер сокетов, для скорости, расположен на отдельном секретном домене, в обход основного CDN Медузы. Сертификат для этого домена мы, по привычке, выпустили у StartSSL, и вот результат.

У нас в Медузе весь CI самописный, из Go и sh. Мне это казалось не очень классным.

Мантра: можешь взять готовый код - отлично; готовый продукт - ещё лучше, SaaS - совсем идеально.

После прочтения этого доклада как-то отпустило. Одной фразой: из коробки все популярные CI дико дырявые.

https://www.blackhat.com/docs/eu-15/materials/eu-15-Mittal-Continuous-Intrusion-Why-CI-Tools-Are-An-Attackers-Best-Friend.pdf

Разработчики обычно имеют запущенными у себя на компьютере локальные базы: elasticsearch, redis и многие другие. Частенько это может быть слепок с продакшен базы, с настоящими важными данными внутри. Так вот, придумали хитрый способ вытащить эти данные просто заманив разработчика на вредоносную web-страницу. Браузеры пытаются защитить пользователей с помощью множества механизмов, так что внутри атаки хитрый трюк с DNS. Понятно, что практически это очень маловероятный вектор атаки, но уж очень элегантно.

http://bouk.co/blog/hacking-developers