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

В MacOS High Sierra можно активировать root-пользователя без пароля. Достаточно в любом диалоге «элевации прав» (появляющемся при установке софта или открытии некоторых системных настроек) ввести логин root, оставить поле ввода пароля пустым и нажать несколько раз Unlock.

Это активирует root-пользователь без пароля и можно шуровать в компьютере без ограничений.

Защититься можно установив рутовый пароль (sudo passwd root) или вот официальная GUI инструкция https://support.apple.com/ru-ru/HT204012.

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

https://twitter.com/lemiorhan/status/935578694541770752

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

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

Для включения нужно купить и привязать ключи безопасности U2F. Для компьютера — знаменитая флешка за 18$. Для телефона — необычная bluetooth/nfc версия за 25$, хотя, кажется, можно обойтись приложением Google Smart Lock.

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

Хотя это и не говорится явно, кажется, всё это — ответ гугла на русских государственных хакеров, которые планомерно проводят качественные таргетированные атаки на журналистов и политиков.

Реальное отличие таких аппаратных ключей от одноразовых кодов — в защите от фишинга. Одноразовые коды можно перехватить на этапе их ввода руками на фишинговую страницу (а люди плохо определяют фишинг, это медицинский факт). Криптографический обмен ключами между сайтом и USB-устройством перехватить можно, но бессмысленно. Шах и мат, Russian hackers.

Про ошибку в Wifi-протоколе пишет крутой безопасник.

Оказывается, в 2005 (!) году была опубликована научная статья о формальном анализе WPA2. Это когда ученые доказывают, что программа работает корректно. Дико дорогой процесс, использующийся в науке, оборонке, авиации и прочей космической промышленности (ниже будет скриншот из статьи, вы только посмотрите на эту нотацию).

Почему же анализ не обнаружил ошибки? Они смотрели отдельно на хэндшейк (процесс договора сторон о ключах шифрования) и отдельно на шифрование. Ошибка возникает только смотреть на систему в целом (что очень сложно).

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

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

https://blog.cryptographyengineering.com/2017/10/16/falling-through-the-kracks/

Хорошая статья про сложность обновлений, в противовес моему утверждению «кто не обновился тот дурак»

Особенно тяжело обновлять медицинское оборудование — это то, что сейчас модно называть «интернет вещей». Они гарантированно работают в течении 5-10 лет в том виде, что их поставили. Причин две: 1. Часть из них не могут обновиться — у маленьких железок не хватит ресурсов; 2. Важные железки очень жестко тестируют, при этом любое обновление влечет необходимость дорогого и долгого повторного тестирования. Вы ведь не хотите, чтобы вдруг завис рентгеновский аппарат, в момент снятия снимка?

Я в бытность студентом работал сисадмином в биологической-генетической лаборатории. Единственная железка, которую я помню смог обновить — атомный микроскоп от JPK. Производитель выпустил «свежую» версию дистрибутива на Linux годовой давности. И это было очень круто, предыдущей версии было 4 года. Чтобы вы понимали — критичные обновления безопасности обычно выходят каждые 2-3 месяца.

Apple обновил свой whitepaper (техническую статью) про безопасность в iOS, добавил информации по iOS 10.

Для неторопливого чтения, качественные 70 страниц A4: https://www.apple.com/business/docs/iOS_Security_Guide.pdf

У каждой большой корпорации и Open-Source сообществ есть свои языки документации. Мне ближе всего язык FreeBSD и PostgreSQL — краткий и в то же время очень четкий. Microsoft любит чуть по-длинеее, но легко читаемый.

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

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

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

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

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

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

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

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