запуск завтра
о каналепоиск

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

Короткая (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