Рубрика «security» - 8

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

Карта средств защиты ядра Linux - 1Читать полностью »

Привет!

Сегодня расскажу о том, чем мы с коллегами заняты уже несколько месяцев: о пуш-уведомлениях для мобильных мессенджеров. Как я уже говорил, в нашем приложении главный упор сделан на безопасность. Поэтому мы выясняли, есть ли у пуш-уведомлений “слабые места” и если да, то как мы можем их нивелировать, чтобы добавить эту полезную опцию в наш сервис.

Публикую перевод нашей статьи с Medium с небольшими добавлениями от себя. В ней итоги “расследования” и рассказ о том, как решили проблему.

Исследуем матчасть

В классической модели пуш-уведомления делают мессенджеры уязвимыми для атак MITM (Man-in-the-middle, «Человек посередине»). Например, у Google, Microsoft и в старой версии iMessage приложение отправляет ключи шифрования на серверы Apple — на сервере происходит аутентификация пользователей и дешифровка заголовка сообщения (либо его содержания).

Безопасные push-уведомления: от теории к практике - 1

В итоге есть шанс прочесть переписку, получив доступ к серверу пуш-уведомлений. А это значит, что любые шифрования переписки бесполезны: пуш-уведомления все равно оставят возможность для чтения третьими лицами. Подробнее эту возможность обсуждали авторы статьи “Шифруйся грамотно” на Xaker.ru, посвященной способам шифрования сообщений.

Если вам кажется, что серверы Apple и Google 100% не допустят утечки ключей шифрования пользователей, подумайте о том, что к ним имеют доступ их сотрудники. А сотрудники — люди.
При всех уязвимостях пушей, многие «безопасные» мессенджеры, включая Signal и Telegram, используют их. Ведь иначе пользователям придется «вручную» мониторить новые сообщения, постоянно заходя в приложение. Что весьма неудобно, и мессенджеры-конкуренты получат преимущество.

Паранойя и здравый смысл

Читать полностью »

image

In the modern world popularity of a mobile applications continues to grow. So does OAuth 2.0 protocol on mobile apps. To make OAuth 2.0 protocol secure on mobile apps it's not enough to implement standard as is. One needs to consider the specifics of mobile applications and apply some additional security mechanisms.

In this article, I want to share the attacks on mobile OAuth 2.0 implementations and security mechanisms used to prevent such attacks. Concepts described in this article are not new but there is lack of the structured information on this topic. The main aim of the article is to fill this gap.
Читать полностью »

На днях в блоге Elastic появилась запись, в которой сообщается о том, что основные security-функции Elasticsearch, выведенные в open source-пространство более года назад, теперь являются бесплатными для пользователей.

В официальной блогозаписи содержатся «правильные» слова о том, что open source должен быть бесплатным и что владельцы проекта строят свой бизнес на прочих дополнительных функциях, которые предлагаются ими для enterprise-решений. Теперь в базовые сборки версий 6.8.0 и 7.1.0 включены следующие security-функции, ранее доступные только по gold-подписке:

  • TLS для шифрованной связи.
  • Файл и native-реалм для создания и управления пользовательскими записями.
  • Управление доступом пользователей к API и кластеру на базе ролей; допускается многопользовательский доступ к Kibana с использованием Kibana Spaces.

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

А они у него есть и серьезные.
Читать полностью »

Отгремел Google I/O 2019 и пришла пора переписывать проекты на новую архитектуру изучать новинки. Так как я интересуюсь безопасностью мобильных приложений, то в первую очередь обратил внимание на новую библиотеку в семействе JetPack — security-crypto. Библиотека помогает правильно организовывать шифрование данных и при этом ограждает разработчиков от всех нюансов, которые сопровождают этот процесс.

Читать полностью »

Исторически сложилось, что sudo права регулировались содержимым файлов из /etc/sudoers.d и visudo, а авторизация по ключам велась с использованием ~/.ssh/authorized_keys. Однако с ростом инфраструктуры возникает желание управлять этими правами централизованно. На сегодняшний день вариантов решения может быть несколько:

  • Система управления конфигурацией — Chef, Puppet, Ansible, Salt
  • Active Directory + sssd
  • Разнообразные извращения в виде скриптов и ручного редактирования файлов

На мой субъективный взгляд, оптимальным вариантом централизованного управления является все-таки связка Active Directory + sssd. Преимущества данного подхода вот в чем:

  • Действительно Единый централизованный каталог пользователей.
  • Раздача прав sudo сводится к добавлению пользователя в определенную группу безопасности.
  • В случае различных Linux-систем возникает необходимость вводить дополнительные проверки на определение ОС при использовании систем конфигурации.

Сегодняшняя сюита будет посвящена именно связке Active Directory + sssd для управления правами sudo и хранением ssh ключей в едином репозитории.
Итак, зал застыл в напряженном молчании, дирижер поднял палочку, оркестр приготовился.
Поехали.
Читать полностью »

Начиная с 25 апреля 2019 у партнеров появилась возможность получить ранний доступ (Early Access) к платформе Acronis Cyber Platform. Это первый этап реализации программы по формированию новой экосистемы решений, в рамках которой компании по всему миру смогут воспользоваться платформой Acronis для интеграции сервисов киберзащиты в свои продукты и решения, а также получают возможность предложить собственные услуги мировому сообществу через наш будущей маркетплейс. Как это работает? Читайте в нашем посте.

Acronis впервые открывает доступ к API для разработчиков - 1
Читать полностью »

Некоторое время назад мне предоставилась возможность поэксперементировать с настройками одного заурядного роутера. Дело в том, что первое апреля обязывало меня разыграть своих товарищей с университета. В университеть была Wi-Fi сеть. Мною было решено поднять на своем роутере поддельную есть (задать имя, пароль и установить MAC-адрес одной из легитимных точек доступа), на ноутбуке запустить вой DNS, web сервер. Каждый случайно подключившийся к моей сети и попытавшийся на зайти на какой либо сайт должен был перенапрявляться на мою страничку с первоапрельской картинкой. Но история не об этом. Когда я ковырялся в настройках роутера я нашел интересный баг, о нем я сегодня и расскажу.

image

Читать полностью »

image

Начиная с сегодняшнего дня (24/04/2019) для пользователей последней версии браузера Brave доступна функция Brave Rewards. При активации Brave Rewards пользователи, просматривающие рекламу, предоставленную Brave Ads, в качестве вознаграждения будут получать 70% от оплаты за рекламу.
Читать полностью »

OAuth 2 overview

This article assumes that readers are familiar with OAuth 2. However, below a brief description of it is presented below.

The most common OAuth 2.0 Hacks - 1

  1. The application requests authorization to access service resources from the user. The application needs to provide the client ID, client secret, redirect URI and the required scopes.
  2. If the user authorizes the request, the application receives an authorization grant
  3. The application requests an access token from the authorization server by presenting authentication of its own identity, and the authorization grant
  4. If the application identity is authenticated and the authorization grant is valid, the authorization server issues the access and refresh (if required) token to the application. Authorization is complete.
  5. The application requests the resource from the resource server and presents the access token for authentication
  6. If the access token is valid, the resource server serves the resource to the application

The are some main Pros and Cons in OAuth 2.0

+OAuth 2.0 is easier to use and implement (compared to OAuth 1.0)
+Wide spread and continuing growing
+Short lived Tokens
+Encapsulated Tokens

-No signature (relies solely on SSL/TLS ), Bearer Tokens
-No built-in security
-Can be dangerous if used from not experienced people
-Too many compromises. Working group did not make clear decisions
-Mobile integration (web views)
-Oauth 2.0 spec is not a protocol, it is rather a framework — RFC 6749

Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js