Русский
Русский
English
Авторизация
Ip-адрес
Восстановление пароля
Регистрация
Статистика
Реклама

Безопасность данных

Системы противодействия банковскому мошенничеству что необходимо знать о решениях

20.08.2020 14:16:33 | Автор: admin
Благодаря стремительному прогрессу в банковском секторе в направлении диджитализации и
увеличения спектра банковских услуг, постоянно растет комфорт и расширяются возможности клиента. Но одновременно увеличиваются и риски, а соответственно и повышается уровень требований к обеспечению безопасности финансов клиента.



Ежегодный ущерб от финансового мошенничества в сфере онлайн платежей составляет 200 млрд. $. 38% из них результат хищения личных данных пользователей. Как избежать подобных рисков? Помогают в этом антифрод системы.

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

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

На сегодняшний день банковский сектор постепенно обновляет парк устаревших антифрод систем более новыми, которые созданы с использованием новых и усовершенствованных подходов, методик и технологий, таких как:

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

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

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

В совокупности с использованием продолжительной поведенческой биометрии выявлять атаки нулевого дня и минимизировать количество ложных срабатываний. Антифрод система должна обеспечивать многоуровневый подход к обеспечению безопасности транзакции (конечное устройство сессия канал мультиканальная защита использование данных от внешних SOC). Безопасность не должна заканчиваться аутентификацией пользователя и проверкой целостности транзакции.

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

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

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

На сегодняшний день на рынке антифрод систем есть ряд известных решений:

ThreatMark


Решение AntiFraudSuite от компании ThreatMark, несмотря на свою достаточною молодость на рынке антифрод систем, успело попасть в поле зрения компании Gartner. AntiFraudSuite включает возможность выявления киберугроз и финансового мошенничества. Использование машинного обучения, искусственного интеллекта и длительной поведенческой биометрии позволяет выявлять угрозы в режиме реального времени и имеет очень высокую точность срабатываний.



NICE


Решение Nice Actimize от компании NICE относится к классу аналитических платформ и позволяет осуществлять выявление финансового мошенничества в режиме реального времени. Система обеспечивает защиту любых типов платежей, в том числе SWIFT/Wire, Faster Payments, платежи BACS SEPA, банкоматные/дебетовые транзакции, массовые платежи, платежи по счетам, P2P/почтовые платежи и различные формы внутренних переводов.

RSA


RSA Transaction Monitoring and Adaptive Authentication от компании RSA относится к классу
аналитических платформ. Система позволяет выявлять попытки мошенничества в режиме реального времени и производит мониторинг транзакций после входа пользователя в систему, что позволяет защититься от атак типа MITM (Man in the Middle) и MITB (Man in the Browser).



SAS


SAS Fraud and Security Intelligence (SAS FSI) представляет собой единую платформу для решения задач предотвращения транзакционного, кредитного, внутреннего и иных типов финансового мошенничества. Решение совмещает тонкую настройку бизнес-правил с технологиями машинного обучения для предотвращения мошенничества при минимальном уровне ложных срабатываний. Система включает встроенные механизмы интеграции с онлайн- и офлайн-источниками данных.



F5


F5 WebSafe это решение по защите от киберугроз в финансовой сфере от компании F5. Оно позволяет выявлять кражу учетных записей, признаки заражения вредоносными программами, кейлоггинга, фишинга, троянов удаленного доступа, а также атак типа MITM (Man in the Middle), MITB (Man in the Browser) и MITP (Man in the Phone взлом мобильных устройств).



IBM


IBM Trusteer Rapport от компании IBM предназначена для защиты пользователей от перехвата учетных данных, захвата экрана, вредоносных программ и фишинговых атак, в том числе атак типа MITM (Man in the Middle) и MITB (Man in the Browser). Для этого в IBM Trusteer Rapport применяются технологии машинного обучения, что позволяет автоматически обнаружить и удалить вредоносные программы с конечного устройства, обеспечив безопасность сеанса работы в режиме онлайн.



Guardian Analytics


Система Digital Banking Fraud Detection от компании Guardian Analytics относится к аналитическим платформам. При этом Digital Banking Fraud Detection защищает от попыток захвата аккаунта клиента, мошеннических переводов, фишинга и атак типа MITB (Man in the Browser) в режиме реального времени. Для каждого пользователя создается свой профиль, на основе которого происходит распознавание аномального поведения.



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

Автор: Артемий Кабанцов, Softprom
Подробнее..
Категории: Информационная безопасность , Софт , Хранение данных , Платежные системы , Кибербезопасность , Антифрод , Защита данных , Фишинг , Защита информации , Защита персональных данных , Киберугрозы , Блог компании roi4cio , Кибератаки , Безопасность платежей , Безопасность данных

Перевод Zoom так и не понял GDPR

28.08.2020 14:05:29 | Автор: admin


Cookies куки


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


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


В течении прошлого месяца, удаляя Zoom (компания Threatspike EDR), мы обнаружили неоднократный доступ к Google Chrome cookie в процессе удаления:



Это было крайне подозрительно. Мы решили провести небольшое исследование и проверить является ли это поведение зловредным.


Мы проделали следующие шаги:


  • Почистили куки файл
  • Скачали Zoom
  • Поклацали сайт zoom.us
  • Походили по разным веб-сайтам, включая малоизвестные
  • Сохранили куки
  • Удалили Zoom
  • Сохранили куки еще раз для сравнения и что бы понять какие конкретно затрагивает Zoom.

Часть куков была добавлена при посещении сайта zoom.us, часть при авторизации на сайте.



Это поведение ожидаемо. Но когда мы попытались удалить Zoom клиент с компьютера под управлением Windows мы заметили интересное поведение. Файл install.exe обращается к Chrome Cookies и читает, в том числе куки не относящиеся к Zoom.



Изучив операции чтения, мы задались вопросом читает ли Zoom только определенные куки с определенных веб-сайтов?


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


Однако, мы все-таки нашли аномальное и интересное поведения в процессе удаления сравнив куки до и после. Процесс installer.exe записывает новые куки:



Куки без срока (так же известные как сессионные куки) будут удалены при закрытии браузера. Но куки NPS_0487a3ac_throttle, NPS_0487a3ac_last_seen, _zm_kms and _zm_everlogin_type имеют срок годности. Последняя запись имеет срок 10 лет:



Судя по имени "everlogin" это запись определяет использовать ли пользователь Zoom. И тот, факт, что эта запись будет храниться 10 лет после того как приложение было удалено, нарушает ePrivacy директиву:


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

Слежение за пользовательской активность в интернете не самая ужасная вещь сама по себе. Однако, как правило пользователи не будут вдаваться в подробности "Принять все куки" кнопки. Зачастую, только на совести компании уважать ePrivacy, GDPR или нет.


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

Подробнее..
Категории: Информационная безопасность , Облачные сервисы , Серверное администрирование , Куки , Cookie , Безопасность данных

Перевод Blacklight инспектор конфиденциальности веб-сайтов

28.09.2020 10:23:58 | Автор: admin


Blacklight это инспектор конфиденциальности веб-сайтов, выполняющий проверку в реальном времени.

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

Принцип работы Blacklight заключается в посещении каждого веб-сайта headless-браузером (браузером без графического интерфейса), в котором запущено специализированное ПО, созданное The Markup. Это ПО отслеживает, какие скрипты на сайте потенциально могут наблюдать за пользователем, выполняя семь тестов, каждый из которых исследует отдельный известный способ наблюдения.


Blacklight отслеживает следующие типы наблюдения:

  • Куки сторонних доменов
  • Рекламные трекеры
  • Кейлоггеры
  • Запись сессий
  • Фингерпринтинг по Canvas
  • Отслеживание Facebook
  • Remarketing Audiences Google Analytics

Подробнее о них и их ограничениях рассказывается ниже.

Blacklight создан на основе Javascript-окружения NodeJS, Node-библиотеки Puppeteer, обеспечивающей высокий уровень контроля поверх браузера Chromium (open-source Chrome). Когда пользователь вводит URL в Blacklight, инструмент запускает headless-браузер с новым профилем и посещает главную страницу сайта, а также случайно выбранную страницу, находящуюся глубже внутри того же веб-сайта.

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


Пока браузер посещает веб-сайт, он выполняет в фоновом режиме специализированное ПО, отслеживающее скрипты и сетевые запросы, чтобы понять, когда и как собираются пользовательские данные. Для мониторинга скриптов Blacklight модифицирует различные свойства Window API браузера, которые можно использовать для фингерпринтинга. Это позволяет Blacklight фиксировать, какой скрипт выполнил вызов определённой функции с помощью пакета Stacktrace-js. Сетевые запросы собираются при помощи инструмента мониторинга, содержащегося в API Puppeteer.

Blacklight использует данные скриптов и сетевые запросы для выполнения перечисленных выше семи тестов. После этого он закрывает браузер и генерирует отчёт для пользователя.

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

Мы определяем имена доменов с помощью способа Public Suffix + 1. Под понятием собственного домена (first-party domain) мы подразумеваем любой домен, соответствующий посещаемому веб-сайту, в том числе и поддомены. Под понятием стороннего (third-party) мы подразумеваем любой домен, не соответствующий посещаемому веб-сайту. Инструмент сравнивает список сторонних доменов из запросов веб-сайта с набором данных Tracker Radar сайта DuckDuckGo.

Это слияние данных позволяет Blacklight добавлять следующую информацию о сторонних доменах, найденных на исследуемом сайте:

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

Эта дополнительная информация о сторонних доменах предоставляется пользователям в качестве контекста результатов тестов Blacklight. Среди прочего, эта информация используется для подсчёта количества относящихся к рекламе трекеров, присутствующих на веб-сайте.

Blacklight выполняет тесты на основании корневого URL страницы, введённого в интерфейс инструмента. Например, если пользователь вводит example.com/sports, то Blacklight начинает исследование с example.com, отбрасывая путь /sports. Если пользователь вводит sports.example.com, то Blacklight начинает исследование с sports.example.com.

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

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

Кодовая база Blacklight выложена в open source и доступна на Github; также её можно скачать как NPM-модуль.

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

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

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

Предыдущие работы


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

Он выполняет средства Javascript, что позволяет ему отслеживать вызовы Javascript API браузеров. Этот аспект работы основан на OpenWPM инструменте с открытым исходным кодом для измерения веб-конфиденциальности, созданном Стивеном Энглехардом, Гунесом Акаром, Диллоном Рейсманом и Арвиндом Нараянаном из Принстонского университета. Сейчас этот инструмент поддерживается Mozilla.

OpenWPM использовался в принстонском Web Transparency and Accountability Project, который выполнял мониторинг веб-сайтов и сервисов для изучения того, как компании собирают и используют данные, а также вводят пользователей в заблуждение.

Благодаря множеству исследований, проведённых в период с 2015 по 2019 годы, исследователи Принстона выявили наличие множества технологий нарушения конфиденциальности. В их число вошли фингерпринтинг браузеров и синхронизация куки, а также скрипты воссоздания сессий, собирающие пароли и важные пользовательские данные. Одним из примечательных примеров является просачивание данных о выписанных рецептах и состоянии здоровья с walgreens.com.

Пять из семи выполняемых Blacklight тестов основаны на техниках, описанных в вышеупомянутом принстонском исследовании. Это фингерпринтинг по canvas, кейлоггинг, запись сессий и куки сторонних доменов.

OpenWPM содержит в себе код и техники из других инструментом изучения конфиденциальности, в том числе из FourthParty, Privacy Badger и FP Detective:

  • FourthParty была open-source-платформой для измерения динамичекого веб-контента, запущенной в августе 2011 года, которая поддерживалась до 2014 года. Её применяли в различных исследованиях, в частности, в исследовании, описывающем способ, которым веб-сайты наподобие Home Depot обеспечивали утечку имён своих пользователей третьей стороне. Blacklight использует методику FourthParty по мониторингу передачи пользовательской информации, передаваемой по сети третьей стороне.
  • Privacy Badger это расширение браузера, созданное Electronic Frontier Foundation и выпущенное в мае 2014 года. Оно не позволяет рекламным сетям и сторонним трекерам следить за людьми в Интернете.
  • FP Detective было первым подробным исследованием для измерения объёма фингерпринтинга устройств в Интернете. Этот инструмент был выпущен в 2013 году и использовался для проведения широкомасштабных исследований конфиденциальности в вебе.

Разработчики анализа данных Blacklight частично вдохновлялись Website Evidence Collector, разработанным Electronic Data Protection Supervisor (EDPS) из Евросоюза. Website Evidence Collector это пакет NodeJS, использующий библиотеку Puppeteer для изучения того, как веб-сайт собирает пользовательские персональные данные. Часть категорий собираемых данных была выбрана EDPS.

Среди других проектов, повлиявших на разработку Blacklight, были Web Privacy Census, проведённый Калифорнийским университетом в Беркли в 2012 году, и серия What They Know Wall Street Journal.

Как мы анализировали каждый тип трекинга


Куки сторонних доменов


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

Популярные браузеры Edge, Brave, Firefox и Safari по умолчанию блокируют куки слежения сторонних доменов, а разработчики Chrome объявили, что откажутся от них.

Что тестирует Blacklight

Blacklight выполняет мониторинг сетевых запросов заголовка Set-Cookie и следит за всеми доменами, устанавливающими куки при помощи javascript-свойства document.cookie. Blacklight определяет куки сторонних доменов как куки, чей домен не соответствует посещаемому веб-сайту. Мы ищем эти сторонние домены в данных DuckDuckGo Tracker Radar, чтобы узнать, кто ими владеет, насколько часто они используются, и какие виды услуг они предоставляют.

Кейлоггинг


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

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

Что тестирует Blacklight

Чтобы протестировать, происходит ли кейлоггинг на сайте, Blacklight вводит заранее заданный текст (см. Приложение) во все поля ввода, но никогда не нажимает на кнопку отправки. Он отслеживает сетевые запросы, чтобы проверить, передаются ли введённые данные каким-нибудь серверам.

Запись сессий


Запись сессий (Session recording) это технология, позволяющая третьим сторонам отслеживать и записывать всё поведение пользователя на веб-странице, в том числе движения мыши, нажатия, скроллинг страницы и весь ввод в формы даже без нажатия кнопки отправки.

В исследовании 2017 года исследователи Принстонского университета выяснили, что программы записи сессий собирают важную информацию, например, пароли и номера кредитных карт. Когда исследователи связались с соответствующими компаниями, большинство из них отреагировало быстро и устранило причину утечек данных. Однако в исследовании подчёркивается, что это не просто баги, а, скорее, небезопасные практики, которые, по словам исследователей, должны быть полностью прекращены. Большинство компаний, предоставляющих функцию записи сессий, сообщают, что используют данные для того, чтобы дать своим заказчикам (веб-сайтам, устанавливающим технологию) полезные сведения о том, как повысить удобство пользования веб-сайтом. Одна из компаний, Inspectlet, описывает свой сервис как отслеживание поведения отдельных пользователей на сайте так, как будто мы стоим у них за спиной. (Inspectlet не ответила на письмо с просьбой о комментариях.)


Скриншот сайта Inspectlet, известного поставщика услуг записи сессий.

Что тестирует Blacklight

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

Blacklight выполняет мониторинг сетевых запросов специфических подстрок URL, которые согласно списку, созданному исследователями Принстонского университета в 2017 году, встречаются только при записи сессий.

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

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

Фингерпринтинг по Canvas


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

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


Четыре примера фингерпринтинга по canvas, обнаруженных Blacklight.

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

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

Что тестирует Blacklight

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

  • Свойства height и width элемента canvas не должны быть меньше 16px.
  • Тест должен записываться на canvas не менее чем десятью символами.
  • Скрипт не должен вызывать методы save, restore или addEventListener контекста рендеринга.
  • Скрипт извлекает изображение при помощи toDataURL или единственным вызовом getImageData, указывающим область размером не менее 16px 16px.

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

Рекламные трекеры


Рекламные трекеры (Ad trackers) это технологии, идентифицирующие и собирающие информацию о пользователях. Такие технологии обычно (но не всегда) используются в какой-то мере с согласия владельцев веб-сайта. Они применяются для сбора аналитики о пользователях веб-сайта, для таргетинга рекламы, а также брокерами данных и другими сборщиками информации для создания своих профилей пользователей. Обычно они принимают форму скриптов на Javascript и web beacon.

Web beacon это небольшие изображения размером 1px x 1px, размещаемые на веб-сайтах сторонними лицами с целью слежения. С помощью этой техники сторонние лица могут определять поведения пользователей: когда конкретный пользователей вошёл на сайт, тип его браузера и используемый IP-адрес.

Что тестирует Blacklight

Blacklight проверяет все сетевые запросы по списку EasyPrivacy, содержащему URL и подстроки URL, известные выполнением трекинга. Blacklight отслеживает сетевую активность запросов, выполняемых к этим URL и подстрокам.

Blacklight записывает запросы, выполняемые только к сторонним доменам. Он игнорирует любые паттерны URL в списке EasyPrivacy, соответствующие собственному домену URL. Например, EFF хранит собственную аналитику, из-за чего выполняет запросы к своему поддомену аналитики https://anon-stats.eff.org. Если пользователь вводит eff.org, то Blacklight не считает вызовы anon-stats.eff.org запросами к сторонним доменам.

Мы находим эти сторонние домены в наборе данных DuckDuckGo Tracker Radar, чтобы узнать, кому они принадлежат, насколько они распространены и какие типы услуг предоставляют. Мы включаем в список только те сторонние домены, которые относятся к категориям Трекинг с целью рекламы (Ad Motivated Tracking) набора данных Tracker Radar.

Пиксель Facebook


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

Что тестирует Blacklight

Blacklight ищет сетевые запросы с сайта, ведущие на Facebook, и изучает параметры запроса данных URL, соответствующие схеме, описанной в документации пикселя Facebook. Мы ищем три разных типа данных: "standard events", custom events и "advanced matching".

Remarketing Audiences Google Analytics


Google Analytics это самая популярная сегодня платформа аналитики веб-сайтов. Согласно данным whotracks.me, 41,7% веб-трафика анализируется Google Analytics. Хотя бОльшая часть функциональности этого сервиса заключается в предоставлении разработчикам и владельцам веб-сайтов информации о том, как аудитория сайта взаимодействует с ним, этот инструмент также позволяет веб-сайту создавать собственные списки аудитории на основании поведения пользователей, а затем таргетировать рекламу для этих посетителей в Интернете при помощи Google Ads и Display & Video 360. Blacklight изучает исследуемые сайты на наличие этого инструмента, но не способа его использования.

Что тестирует Blacklight

Blacklight ищет сетевые запросы от исследуемого сайта, идущие к URL, начинающегося с stats.g.doubleclick, который также содержит префикс идентификатора аккаунта Google UA-. Подробнее это описано в документации разработчика Google Analytics.

Обследование


Для определения распространённости в Интернете технологий слежения мы протестировали с помощью Blacklight 100 000 наиболее популярных по данным Tranco List веб-сайтов. Данные и код анализа можно найти на Github. Blacklight успешно зафиксировал данные для 81 593 из этих URL. Для остальных или не удалось выполнить резолвинг, или произошёл таймаут после нескольких попыток, или не получилось загрузить веб-страницу. Показанные ниже процентные показатели рассчитаны на основании 81 617 успешных результатов.

Основные открытия, сделанные в нашем обзоре:

  • 6% веб-сайтов использовало фингерпринтинг по canvas.
  • 15% веб-сайтов загружало скрипты из известных сервисов записи сессий.
  • 4% веб-сайтов выполняло логгинг нажатий клавиш.
  • 13% сайтов не загружало никаких куки сторонних доменов или запросов сетей слежения.
  • Медианное количество куки сторонних доменов равно трём.
  • Медианное количество загруженных рекламных трекеров равно семи.
  • 74% сайтов загружало технологию слежения Google.
  • 33% веб-сайтов загружало технологию слежения Facebook.
  • 50% сайтов использовало функцию ремаркетинга Google Analytics.
  • 30% сайтов использовало пиксель Facebook.

Мы классифицировали как технологию слежения Google любые сетевые запросы, выполняемые к любому из следующих доменов:

  • google-analytics.com
  • Doubleclick.net
  • Googletagmanager.com
  • Googletagservices
  • Googlesyndication.com
  • Googleadservices
  • 2mdn.net

Мы классифицировали как технологию слежения Facebook любые сетевые запросы, выполняемые к любому из следующих доменов Facebook:

  • facebook.com
  • Facebook.net
  • atdmt.com

Ограничения


Анализ Blacklight ограничен четырьмя основными факторами:

  1. Это симуляция поведения пользователей, а не истинное их поведение, что может способствовать срабатыванию других реакций систем слежения.
  2. Исследуемый веб-сайт может отслеживать действия пользователя с благими целями.
  3. Ложноположительные срабатывания (возможны в отношении фингерпринтинга по canvas): очень изредка обоснованное использование HTML-элемента canvas совпадает с эвристиками, которые Blacklight использует для идентификации фингерпринтинга по canvas.
  4. Ложноотрицательные срабатывания: используемая Javascript-средствами Blacklight техника отслеживания стеков может некорректно связать вызов отслеживаемого метода window API с добавленной скриптом библиотекой. Например, если скрипт фингерпринтинга использует для выполнения вызовов jQuery, то в результате jQuery может оказаться на вершине стека, и Blacklight свяжет вызов с ним, а не со скриптом. На эту возможность нам указали исследователи, проводившие рецензирование нашей методологии; такого не происходило ни в наших тестах, ни при проверке 100 000 самых популярных сайтов.

Что касается ложноположительных срабатываний, когда Blacklight посещает сайт, то этот сайт может увидеть, что запрос поступает с компьютеров, расположенных в облачной инфраструктуре Amazon AWS. Так как в облачной инфраструктуре часто работают ботнеты, наш инструмент может привести к срабатыванию на сайте ПО распознавания ботов, в том числе и фингерпринтинга по canvas. Это может привести к ложноположительным результатам теста фингерпринтинга по canvas, несмотря на то, что тест используется не для слежения за пользователями, а для распознавания ботнетов.

Чтобы протестировать это, мы взяли случайную выборку в 1 000 сайтов из вершины списка Tranco List, которые мы уже пропускали через Blacklight на AWS. Мы пропустили эту выборку через ПО Blacklight на нашем локальном компьютере, имеющем IP-адрес в Нью-Йорке, и пришли к выводу, что результаты выполняемой локально проверки Blacklight очень похожи, но не точно совпадают с результатами запуска в облачной инфраструктуре.

Результаты для выборки: локальный компьютер и AWS


Локальный AWS
Фингерпринтинг по Canvas 8% 10%
Запись сессий 18% 19%
Кейлоггинг 4% 6%
Медианное количество куки сторонних доменов 4 5
Медианное количество сторонних трекеров 7 8

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

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

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

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

Приложение


Значения полей ввода

В показанной ниже таблице перечислены значения, которые мы прописали в Blacklight для ввода в поля ввода на веб-сайтах. В качестве справки мы использовали статью Mozilla об атрибуте autocomplete. Blacklight также выполняет проверку на наличие версий этих значений в base64, md5, sha256 и sha512.

Атрибут автозаполнения Значение Blacklight
Date 01/01/2026
Email blacklight-headless@themarkup.org
Password SUPERS3CR3T_PASSWORD
Search TheMarkup
Text IdaaaaTarbell
URL themarkup.org
Organization The Markup
Organization Title Non-profit newsroom
Current Password S3CR3T_CURRENT_PASSWORD
New Password S3CR3T_NEW_PASSWORD
Username idaaaa_tarbell
Family Name Tarbell
Given Name Idaaaa
Name IdaaaaTarbell
Street Address PO Box #1103
Address Line 1 PO Box #1103
Postal Code 10159
CC-Name IDAAAATARBELL
CC-Given-Name IDAAAA
CC-Family-Name TARBELL
CC-Number 4479846060020724
CC-Exp 01/2026
CC-Type Visa
Transaction Amount 13371337

Благодарности


Мы благодарим Гунеса Акара (Левенский университет), Стивена Энглехарда (Mozilla), Арвинда Нараянана и Джонатана Майера (Принстон Princeton, CITP) за комментарии и предложения к черновику статьи.


На правах рекламы


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

Подробнее..
Категории: Информационная безопасность , Разработка веб-сайтов , Браузеры , Тестирование веб-сервисов , Тестирование сайтов , Блог компании vdsina.ru — хостинг серверов , Безопасность данных , Blacklight

Безопасный удаленный доступ с помощью Citrix Virtual Apps and Desktops

30.10.2020 22:22:20 | Автор: admin


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

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

Проблем, связанных с ее реализацией, может быть несколько:

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

Суть обеспечения непрерывности бизнес-процесса заключается в минимизации ущерба от сбоя в работе, наносимого сотрудникам и ресурсам центра обработки данных (ЦОД), от которых они зависят.

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

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

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

Citrix Virtual Apps and Desktops как решение для быстрой организации удаленного доступа для сотрудника


Огромный плюс, выделяющий Citrix среди конкурентов это возможность быстро развернуть данное решение, используя сценарий Remote PC Access (краткое видео с инструкцией). Это дает возможность использования рабочих нагрузок локальной машины без дополнительных затрат на закупку дорогостоящего оборудования. Фактически, если вообще ничего нет, вам необходимо поставить несколько виртуальных машин, desktop delivery controller, Storefront, сервер лицензирования и, используя различные решения типа SCСM, установить агент на физические устройства сотрудников.

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

Единственным недостатком данного сценария при отсутствии функционала Microsoft Wake On LAN является то, что в случае отключения машины, вам придется произвести физическое включение.

Если вы готовы к использованию облачных сервисов, то самый быстрый вариант использовать продукт Citrix Manage Desktop. В этом решении все разворачивается в облаке Azure, и локально практически ничего разворачивать не нужно, разве что Active Directory. Можно разворачивать управляющую часть в Azure, при этом, если какие-то приложения не хочется выпускать наружу, то здесь можно строить гибридную схему с использованием Citrix Cloud, где часть сервиса ляжет локально, а часть может быть перенесена в любое облако.

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

Где купить или получить консультацию


C 2019 года Citrix поддерживает модель CSP (Citrix Service Provider), которая позволяет использовать практически все продукты Citrix с помесячной оплатой.

Компания Softprom Value Added IT Distributor Citrix готовы предоставить своим партнерам и их клиентам преимущества программы CSP

Альтернативы


О категории продуктов Виртуализация приложений и сессий на сайте ROI4CIO

Резюме


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

Ведь:

  • Продуктивность и безопасность работы обеспечить это реально.
  • Не нужно нести дополнительные расходы на содержание и обслуживание офиса.
  • Работники не тратят много времени на поездки в офис.

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

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

Включая эти возможности в свою стратегию обеспечения непрерывности бизнес-процесса, вы сможете гораздо эффективнее защитить свою организацию от рисков, связанных с запланированными изменениями или непредвиденными сбоями в работе.
Подробнее..
Категории: Информационная безопасность , Удаленная работа , Удаленный доступ , Софт , Кибербезопасность , Блог компании roi4cio , Безопасность данных , Удаленный рабочий стол

Telegram, Signal, Wickr Me выбираем самый безопасный мессенджер и разбираемся, существует ли он

12.11.2020 10:07:10 | Автор: admin


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

О каких мессенджерах пойдет речь?


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

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

  1. Signal некоммерческий проект Open Whisper Systems
  2. Telegram некоммерческий проект Telegram FZ-LLC
  3. Wickr Me коммерческий проект Wickr Inc с бесплатной версией

Для исследования мессенджеров использовали последние версии, доступные на момент исследования в App Store и Google Play.

Мессенджеры устанавливались на смартфоны с iOS версии 13.3.1 и Android версии 7.1.2, при этом на смартфонах заранее были получены права суперпользователя (jailbreak для iOS и root-доступ для Android).

Как сравнивали мессенджеры?


Теперь вкратце расскажем о методике проведенного анализа защищенности. На рисунке ниже отображена схема формирования оценки по каждому мессенджеру.

Для проведения анализа мы выбрали три основные категории:

  1. Открытость сообществу
  2. Архитектура
  3. Основная функциональность

В категории Открытость сообществу оценивались:

  • наличие отчетов внешних аудиторов (в том числе наличие bug bounty-программ)
  • доступность исходного кода мессенджера для исследователей (клиентская и серверная часть, протокол шифрования)
  • наличие доступной и подробной документации для пользователей мессенджера

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

В категориях Архитектура и Основная функциональность оценка складывалась на основе результатов технических (инструментальных) проверок, которые проводились по стандарту OWASP Mobile Security Testing Guide.

В категории Архитектура после проведения инструментальных проверок мы получили оценку:

  • защищенности данных мессенджера (например, конфигурационные файлы, необходимые для работы мессенджера)
  • защищенности каналов связи (например, реализация передачи данных на сервер мессенджера)
  • защищенности резервных копий (например, файлы приложения, создаваемые как мессенджером, так и операционной системой смартфона)
  • защищенности данных профиля пользователя (например, логин пользователя, местоположение)

При наличии недостатков в какой-либо из проверок максимальный балл категории снижался, а максимальная возможная оценка 200 баллов.

В категории Основная функциональность оценивалась корректность работы следующих функций мессенджеров:

  • обмен сообщениями (включая файлы различных форматов)
  • совершение видео- и аудиовызовов

Максимальная оценка в этой категории 120 баллов.

Таким образом, максимальная итоговая оценка мессенджера может составить 332 балла и складывается в следующем отношении:
Если вам интересно узнать больше полную информацию о методологии проведенного анализа защищенности можно найти здесь.

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

И что получилось?


Пришло время поделиться результатами исследования: как видно на диаграмме ниже, наибольшее количество баллов набрал Wickr Me 304 из 332 возможных:

В таблице отражено, как складывалась оценка каждого мессенджера:

Давайте рассмотрим лидеров в каждой категории и найденные недостатки, после чего немного детальнее рассмотрим каждый из них.

Открытость сообществу


Лидеры в этой категории Signal и Telegram набрали одинаковое значение, 10 баллов. Репозитории мессенджеров содержат исходный код приложения и протоколы, доступные для исследования всем желающим. Однако мессенджеры держат закрытой серверную часть приложения, поэтому не получили максимальную оценку.

Wickr Me набрал меньше баллов, так как мессенджер не раскрывает исходный код.

Архитектура


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

Лидером в категории Архитектура является Wickr Me, который содержит меньше выявленных недостатков, чем у конкурентов.

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

Из плюсов следует отметить, что все мессенджеры поддерживают E2EE-шифрование передаваемых данных, поэтому оценка Certificate pinning не проводилась.

Основная функциональность


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

  • обмен сообщениями
  • совершение аудио- и видеозвонков

Примечание: не рассматривалось использование в корпоративной среде.

Лидерами данной категории стали Wickr Me и Telegram, набрав максимальное количество баллов.

Версия мессенджера Signal под платформу Android содержит недостаток обработки исключений, который приводит к остановке приложения (то есть мессенджер сразу закрывается), поэтому Signal набрал меньше баллов в этой категории.

Информация о найденных недостатках


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

Напомним, что все выявленные недостатки были обнаружены на устройствах с root-доступом (или к устройству применен jailbreak).

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

Возможность обхода биометрической аутентификации


Современные смартфоны поддерживают несколько механизмов аутентификации, и один из возможных это биометрическая аутентификация при помощи Touch ID или Face ID. При включенной функции биометрической аутентификации устройство сканирует отпечаток пальца (или лицо) и сравнивает с эталонным, заранее занесенным в систему.

iOS


У всех приложений, в том числе мессенджеров из нашего списка, для платформы iOS биометрическая аутентификация пользователя осуществляется при помощи Local Authentication Framework с использованием функции evaluatePolicy класса LAContext. Рассмотрим работу биометрической аутентификации немного подробнее.

Как выглядит биометрическая аутентификация для пользователя?

При нажатии на логотип мессенджера отображается диалоговое окно аутентификации, которое запрашивает у пользователя подтверждение действия, например, изменение настроек, покупку и т.д. с помощью биометрической аутентификации (Touch ID/Face ID).

В зависимости от того, как закончился процесс биометрической аутентификации, функция evaluatePolicy возвращает значение (true или false), которое используется далее для управления приложением (например, открывается мессенджер или нет).

В чем заключается недостаток?

У всех исследуемых мессенджеров недостаток реализации биометрической аутентификации состоит в том, что пользователь аутентифицируется лишь на основе результата функции evaluatePolicy (true или false) и мессенджер не использует системные механизмы авторизации при доступе к значениям из защищенного хранилища Keychain. Более подробно о локальной аутентификации можно узнать в Mobile Security Testing Guide: здесь и здесь.

Как устранить недостаток?

Один из способов устранить описанный недостаток создать в защищенном хранилище Keychain запись, которая будет содержать некоторый секрет (например, упомянутый ранее аутентификационный токен). При сохранении записи в Keychain необходимо задать соответствующие атрибуты, например, kSecAccessControlTouchIDAny или kSecAccessControlTouchIDCurrentSet.

Далее, чтобы получить значение этой записи, нужно будет обязательно успешно пройти локальную аутентификацию (в зависимости от заданных настроек доступа в Keychain с помощью Touch ID/Face ID или ввода парольной фразы). Использование Keychain с необходимыми атрибутами сохраняемых в нем объектов позволит снизить возможность получения доступа к данным мессенджера.

Android


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

В приложении для платформы Android биометрическая аутентификация пользователя осуществляется с использованием классов FingerprintManager (не используется с Android 9), BiometricPrompt, BiometricManager.

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

В чем заключается недостаток?

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

Как устранить недостаток?

Для устранения данного недостатка в приложении рекомендуется использовать симметричные/асимметричные криптографические ключи (класс KeyGenerator), при инициализации которых вызывать функцию setUserAuthenticationRequired (true). Вызов данной функции позволяет получить доступ к значениям соответствующих криптографических ключей только после успешного прохождения процесса локальной аутентификации. Ключи при этом используются для шифрования некоторого секрета, например, аутентификационного токена в приложении.

Хранение чувствительной информации в локальном хранилище


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

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

  • передаваемые файлы, а также кэшированные изображения из чатов в открытом виде;
  • ключ шифрования базы данных мессенджера в Keychain. Поскольку не используется локальная аутентификация для доступа к значениям из Keychain (см. Возможность обхода биометрической аутентификации), хранение ключа шифрования базы данных мессенджера в Keychain снижает уровень защищенности данных;
  • файлы конфигурации мессенджера, в которых присутствуют параметры, использующиеся для шифрования;
  • IP-адрес устройства в лог-файлах мессенджера;
  • сообщения чатов в открытом виде в базе данных мессенджера.

Если говорить про мессенджеры на Android, небезопасное хранение чувствительных данных тоже встречается, например:

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

Как устранить недостаток?

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

Еще раз напомним, что вышеуказанные чувствительные данные мессенджера недоступны без использования root-доступа (или jailbreak) на устройстве.

Некорректная обработка исключений


Данная уязвимость относится только к платформе Android и мессенджеру Signal.

При исследовании основной функциональности мессенджеров осуществлялась отправка файлов разных форматов. В результате был найден один сценарий, при котором отправка файла вызывала остановку в работе мессенджера со следующей ошибкой: Signal has stopped.

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

Как устранить недостаток?

Чтобы избавиться от данного недостатка, нужно реализовать проверку формата файла, который пользователь выбирает для отправки.

Ответы разработчиков


Обо всех описанных выше недостатках наша команда сообщила разработчикам мессенджеров. На момент публикации мы получили ответ от двух из трех мессенджеров (Signal и Telegram), третий на наши вопросы так и не ответил.

Разработчики поблагодарили нашу команду за предоставленную информацию и сообщили, что не считают выявленные недостатки уязвимостью, поскольку исследуемые версии мессенджеров используют для защиты данных мессенджера штатные механизмы защиты информации операционной системы. Используемые механизмы не позволяют эксплуатировать выявленные недостатки, а использование на устройстве root-доступа (или jailbreak) остается на усмотрение пользователя.

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

Вывод


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

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

По итогам всех проверок лидером нашего исследования стал мессенджер Wickr Me, который набрал 304 балла и у которого выявлено меньше всего недостатков.

Вывод прост: абсолютно безопасных мессенджеров нет, но мы надеемся, что благодаря этому исследованию вы сможете сохранить конфиденциальность и повысить безопасность своего общения, зная обо всех подводных камнях выбранного вами сервиса.
Подробнее..
Категории: Информационная безопасность , It-компании , Signal , Исследования и прогнозы в it , Мессенджеры , Cybersecurity , Блог компании group-ib , Telegram , Исследование , Research , Безопасность данных , Компьютерная безопасность , Data security , Wickr , Messengers

Байки из склепа. Рассказываем, как не стоит обращаться с чувствительными данными

16.11.2020 10:18:38 | Автор: admin

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



Немного теории


Начнем конечно с определения того, какие данные считать конфиденциальными. OWASP причисляет к ним пароли, номера кредитных карт, медицинские записи, личную информацию и бизнес-секреты. Помимо этого, за списком чувствительных данных следует обращаться к законам и отраслевым постановлениям тех регионов, откуда к вам могут прийти пользователи. Если речь о России, нужно заглянуть в Федеральный закон РФ 152-ФЗ О персональных данных, а в случае европейских пользователей, например, в Общий регламент ЕС по защите данных (GDPR) или в закон Великобритании о защите данных (DPA), которые регулируют использование персональных данных.


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


В качестве конфиденциальных данных, хранящихся в приложениях, можно рассматривать следующее:


  • Большинство пользовательских данных. Здесь, впрочем, нужно сделать оговорку: ваши данные, доступные всему интернету, например имена пользователей, которые мы и так видим где-нибудь в чате, могут не быть конфиденциальными).
  • Данные приложения (такие как идентификаторы сеанса и ключи шифрования), которые помогают защитить данные пользователя от раскрытия.

Время удивительных историй


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


Ищем старые версии


Различных чек-листов по безопасности веб-приложений в сети вагон и маленькая тележка. Но, как показывает практика, за всем уследить нереально. Особенно когда речь заходит об использовании старых версий компонентов в большом проекте. Так, однажды на сервисе, использующем подменные номера телефонов, было найдено старое семейство API, где номер еще не скрывался. Подменные номера хорошая услуга, позволяющая скрыть реальный номер продавца с доски объявления. Однако, если внимательно изучить отправляемые запросы, найти документацию (или самим угадать нужные методы), то можно было сформировать запросы к старому API и получить через него подлинные номера пользователей.


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


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


Смотрим шире на процессы


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



Лишнего не болтаем


Аналогичная проблема несогласованности процессов была найдена в функциональности сброса забытого пароля. После ввода логина (в данном случае адреса электронной почты) сайт уточнял, куда отправить пароль: на почту или на привязанный номер телефона. Если был выбран второй вариант, то на странице появлялось оповещение с наполовину скрытым номером телефона. А вот в HTTP-ответе от сервера номер отображался целиком. Так можно было собрать целый список из пар почта-номер телефона. Раскрытие-с.


Кстати, к разговору о функционале сброса пароля. Если при реализации функционала регистрации только единицы забывают использовать общее предложение неправильный логин или пароль, то при восстановлении пароля информацию о наличии того или иного логина в системе раскрывают гораздо чаще. Конкретные ответы от сервера, подтверждающие наличие записи в системе, позволяют составить список пользователей и порой успешно использовать его в дальнейших атаках (фишинг, password spraying и т.д.). Но не только явные сообщения раскрывают информацию, вывод можно сделать по таймингу (например, таким страдали старые версии OWA веб-клиента для доступа к Microsoft Exchange) или телу ответа.


Не храним лишнее


Существует хорошая практика хранить только то, что действительно необходимо. Так, на неком сайте каждый раз, когда система отправляла email пользователю (например, при регистрации, анонсе мероприятий и т.п.), все сообщения записывались в лог. Этот лог на сайте был доступен, внутри хранились непосредственно текст сообщений, фамилия и имя пользователей, а также их почта. Интересно, что многие утилиты для поиска директорий данный файл не находили. Так как его размер был огромен (несколько ГБ), утилиты просто не могли дождаться, пока он скачается, и пропускали его. Но, перепробовав несколько вариантов утилит, аудиторы в конце концов добились своего.


В данной истории, помимо того, что в лог записывались избыточные данные, так еще и доступ к ним никак не был ограничен. Это, как ни парадоксально, далеко не редкий случай. Здесь стоит снова вспомнить ряд громких случаев (например, раз, два, три), когда утекали довольно серьезные объемы данных с Elasticsearch серверов.


Ну, не будем о грустном. Просто не забывайте правильно использовать авторизацию там, где она необходима.


Дружим с логикой


И все же самой распространенной болячкой, позволяющей утекать пользовательским данным, являются небезопасные прямые ссылки на объекты (Insecure Direct Object Reference, IDOR). В подтверждение расскажем две неклассические истории.


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



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


В другом случае IDOR был найден при просмотре транзакций. В HTTP-запросе передавались три параметра:


POST /api/get_transactions HTTP/1.1Host: example.comGT|2315486|2315488|40117812222030001111

, где 2315486 идентификатор пользователя,
2315488 идентификатор карты,
40117812222030001111 номер счета.


На первый взгляд, перебрать 3 значения (34 цифры) не представляется возможным за обозримое время. Но, как выяснилось впоследствии, номер счета (40117812222030001111) в запросе можно было опустить: запрос все равно оставался валидным, как и ответ. Соответственно, оставалось только два числа для подбора идентификатор пользователя и идентификатор карты.


Далее оказалось, что первое значение (идентификатор пользователя) может быть любым, например 1111111, но обязательно такого же размера, как идентификатор карты (7-значное число). Соответственно, параметр GT из 34-значного числа превратился в 7-значное, а перебрать его не составляет труда (в системе также отсутствовало ограничение на количество запросов от пользователей). В итоге, чтобы получить информацию о транзакциях, достаточно было знать только идентификатор карты (или перебрать его значение).


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


Еще раз всё проверим


Завершим наш рассказ случаем в онлайн-магазине, где использовались веб-сокеты. При оформлении заказа в системе для него генерировался ID, и пользователь подписывался по этому ID на все обновления касательно заказа. Но, как выяснилось позже, существовала возможность отправить подобный запрос на подписку не с конкретным ID, а с символом подстановки * на его месте. В результате можно было заполучить информацию обо всех заказах пользователей (с ФИО, адресами, телефонами и прочей сопутствующей информацией).


Заключение


Мы уверены, что подобных, а порой и куда более зубодробительных историй в практике специалистов ИБ предостаточно, но не всегда получается ими поделиться с сообществом. Обычно такое можно услышать в приватной беседе за кружечкой чая. И все же, делиться подобными случаями (обезличенно, конечно) крайне полезная практика как для сообщества, так и для разработчиков. Поиск уязвимостей это своего рода искусство мыслить иначе. Давайте вдохновлять друг друга.

Подробнее..
Категории: Информационная безопасность , Хранение данных , Web , Блог компании digital security , Безопасность данных , Idor

Сайты региональных органов власти все еще печальнее, чем у федералов

06.12.2020 22:08:26 | Автор: admin
image

Вот мы и выпустили сводный доклад по итогам мониторинга сайтов высших органов власти регионов Надежность сайтов органов государственной власти субъектов Российской Федерации 2020. Оценивали их с трех сторон: а) можно ли эти сайты считать официальными с точки зрения закона, б) обеспечивают ли они надежное HTTPS-соединение, и в) что и откуда они загружают, т.е. насколько потенциально уязвимы к XSS и как щедро сливают данные о своих посетителях третьим лицам?

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

Что касается официальности сайтов: у федералов 2 из 82 исследованных сайтов органов власти оказались неофициальным. Первоначально мы посчитали неофициальным еще и сайт Росгвардии, администрируемый подведомственным ей центром информационных технологий, но та отстояла свою точку зрения: центр это войсковая часть, т.е. часть самой Росгвардии, поэтому нарушения закона тут нет, а есть наша невнимательность (но вот TLS-сертификат у них на сайте уже вне всяких сомнений второй месяц как протух).

Поэтому региональные сайты мы проверяли по уже доработанной методике, предусматривающей запрос в ЕГРЮЛ и выяснили: из 184 сайтов, названных официальными, 27 (15%) таковыми не являются, т.к. соответствующие доменные имена администрируются подведомственными госучреждениями, коммерческими и некоммерческими организациями, и даже физическими лицами, хотя закон четко устанавливает, что это разрешено только государственным органам (читай органам власти). Особенно отличились Северо-Западный и Сибирский федеральные округа, где официальных сайтов не имеют более 30% высших органов власти.

С замиранием сердца делали запрос в ЕГРЮЛ по ИНН администратора сайта Парламента Чеченской Республики, который указан в реестре регистратора как ООО Парламент ЧР. Я, конечно, заранее извиняюсь, Рамзан Ахматович, но у парламентов в России иная организационно-правовая форма, и в ФНС считают так же (они пусть сами извиняются). В общем, сенсации не случилось администратор там Аппарат Парламента Чеченской Республики, а за ООО пусть извиняется тот, кто внес такую запись в реестр доменов.

Тут внимательный читатель может перебить меня вопросом: а почему исследовались 184 сайта, когда субъектов федерации 85? Отвечаю: исследовались сайты региональных правительств, парламентов и губернаторов при их наличии (сайта, а не губернатора). Но если вы думаете, что количество губернаторских сайтов легко вычисляется по формуле 184 85 85 (= 14), то вы заблуждаетесь, все намного сложнее. Например, у Правительства Москвы нет своего сайта, есть только сайт Мэра Москвы, где правительству отведен свой угол. Зато органы власти некоторых других субъектов располагают сразу двумя сайтами, причем оба называются официальными.

Для примера, у Правительства Республики Тыва сразу два сайта, оба названы официальными (gov.tuva.ru и rtyva.ru) и оба таковыми не являются с точки зрения закона, т.к. первое доменное имя администрируется АО Тывасвязьинформ, а второе вообще анонимным физическим лицом. У Правительства Костромской области тоже два сайта (adm44.ru и kostroma.gov.ru), оба официальные, но с разным наполнением.

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

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

Интересно тут другое: наверное, все хотя бы слышали про Электронную Москву, Электронную Бурятию, Электронный Татарстан и прочие электронные программы по освоению бюджетов на информатизацию госуправления. А знаете, у кого в результате оказалась лучшая поддержка HTTPS на официальном сайте? У правительств Ульяновской и Московской областей и парламентов Владимирской области и ЯНАО.

Я вот ничего даже не слышал про Электронное ЯНАО, может такой программы и не существует, а хотя бы одного пряморукого админа в ЯНАО найти смогли (пятое место по площади среди субъектов федерации, населения как в одном районе Москвы). А в электронной Бурятии то ли с населением еще хуже (Росстат возражает), то ли денег на нормального админа не хватило, но сервера обоих органов власти законодательной и исполнительной приветливо машут любознательным исследователям букетом из CVE-2014-0160, CVE-2014-0224, CVE-2016-2107, CVE-2019-1559 и далее со всеми остановками.

Из занимательного: при попытке проверить сайт Администрации Ненецкого автономного округа, мы наткнулись на блокировку по IP ряда исследовательских инструментов. На это у администратора хватило и усердия, и знаний, и желания, а вот на закрытие CVE-2012-4929 (кто не в курсе, первая цифра год описания уязвимости, 8 лет назад, Карл!) и прочих дыр уже ни сил, ни желания не осталось, а может и знаний тоже.

Лидером по поддержке защищенного соединения является Южный федеральный округ, где 53% исследованных сайтов обеспечивают достаточно надежное HTTPS-соединение. Следом за ним идут Центральный и Уральский (47% и 40% соответственно). Отстающие Приволжский и Северо-Кавказский, в которых лишь 13% сайтов высших органов власти не имеют значимых проблем с поддержкой защищенного соединения.

Что касается XSS, т.е. мусора, которые сайты сами загружают из сторонних источников, то тут, как и у федералов зоопарк: JS-библиотеки, шрифты, счетчики, баннеры и далее со всеми остановками, но есть и свои интересные нюансы.

Например, у федералов Google Analytics на 4 месте по популярности, а у регионалов на 7; это даже в абсолютных цифрах меньше, чем у федералов. Но если собственно счетчик GA стоит лишь на 9% региональных сайтов, то гуглокод вообще на 63%, так что данные о посетителях они все равно успешно собирают. А вот на третьем месте среди счетчиков у регионалов внезапно оказался Bitrix. Это который вроде бы CMS ну и еще немного сбора статистики.

Рекордсменом по любви к аналитике стало Правительство Алтайского края, чей сайт украшен сразу 6 счетчиками, но его успех несколько меркнет по сравнению с сайтами Администрации Костромской области, парламентов Калининградской области, Удмуртской Республики и Москвы, которые украшены кодом счетчика OpenStat, уже два года не подающим признаков жизни. Это, конечно, не электронные пропуска шаманить, это ж HTML, а у ДИТ лапки загребущие.

В качестве резюме: как и в случае мониторинга федеральных сайтов, мы рассылали отдельные доклады по субъектам их героям. Федералов после этого специально не мониторили, но подвижки видны невооруженным глазом: кто-то дыры на сервере залатал, кто-то HTTPS включил, кто-то TLS-сертификат обновил, кто-то так и не почесался, но реакция заметна.

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

В общем, пока на главной странице его сайта не появится срамная картинка или хула на государя-императора, губернатор партбилетом не перекрестится. Через год проверим, так ли это планируем проводить мониторинг ежегодно.
Подробнее..
Категории: Информационная безопасность , Tls , Сайт , Анализ трафика , Законодательство , Ssl сертификаты , Утечка данных , Https , Администрирование доменных имен , Poodle , Cve-2016-2107 , Robot , Государственные органы , Доступ к информации , Гос. порталы , Доменные имена , Безопасность данных , Xss , Региональные сайты

Перевод 7 основных ошибок безопасности при переходе на облачные приложения

18.01.2021 16:06:50 | Автор: admin
image

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

Вступление


В связи с пандемией многие предприятия перешли на использование большего количества облачных приложений по необходимости потому, что всё больше из нас работают удаленно. В опросе 200 ИТ-менеджеров, проведенном Menlo Security, 40% респондентов заявили, что они сталкиваются с растущими угрозами со стороны облачных приложений и атак Интернета вещей (IoT) из-за этой тенденции.

Есть хорошие и плохие способы осуществить эту миграцию в облако. Многие подводные камни не новы. Например, на одной встрече Gartner 2019 два ИТ-менеджера заявили, что их развертывание Office 365 было приостановлено из-за необходимости обновления устаревшего оборудования. Теперь то, как мы используем и совместно используем наши домашние компьютеры, изменилось. Наши компьютеры больше не личные. Этот же компьютер может поддерживать виртуальную школу вашего ребенка и приложения вашего супруга.

Летний опрос CyberArk показал, что более половины респондентов сохраняют свои пароли в браузерах корпоративных ПК. Конечно, это не обещает ничего хорошего ни для какой политики безопасности.

Вот семь основных ошибок, которые негативно влияют на безопасность, и несколько советов, как их избежать.

1. Использование VPN для удаленного доступа


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

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

2. Создание неправильного облачного портфеля


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

Доступны ли версии для запуска определенных приложений, зависящих от определенных конфигураций Windows и Linux? Есть ли у вас подходящие соединители и средства защиты аутентификации для работы с локальными приложениями и оборудованием, которое вы не переносите? Если у вас есть устаревшее приложение для мэйнфреймов?

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

3. Ваша политика безопасности не подходит для облака


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

Johnson & Johnson сделали это несколько лет назад, когда перенесли большую часть своих рабочих нагрузок в облако и централизовали свою модель безопасности. Есть помощь: Netflix только что выпустил инструмент с открытым исходным кодом, который они называют ConsoleMe. Он может управлять несколькими учетными записями Amazon Web Services (AWS) в одном сеансе браузера.

4. Не тестировать планы аварийного восстановления


Когда вы в последний раз тестировали свой план аварийного восстановления (DR)? Возможно, это было слишком давно, особенно если вы были заняты повседневными проблемами, связанными с поддержкой домашних работников.

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

Еще одна важная часть любого плана аварийного восстановления это непрерывное тестирование на предмет частичных сбоев облака. Скорее всего, у вас будут перебои в работе. Даже Amazon, Google и облака Microsoft испытывают это время от времени. Netflix был одним из первых мест, где несколько лет назад стала популярной общая инженерия хаоса с помощью инструмента под названием Chaos Monkey. Он был разработан для тестирования инфраструктуры AWS компании путем постоянного и случайного отключения различных рабочих серверов.

Используйте эти уроки и инструменты, чтобы разработать собственное тестирование отказов, особенно тесты, связанные с безопасностью, которые выявляют слабые места в вашей облачной конфигурации. Ключевой элемент делать это автоматически и постоянно, чтобы выявлять узкие места и недостатки инфраструктуры. Помимо использования инструментов с открытым исходным кодом от Netflix, есть коммерческие продукты, такие как Verodin / Mandiant's Security Validation, SafeBreachs Breach and Attack Simulation, инструменты моделирования Cymulate и AttackIQ's Security Optimization Platform.

5. Не оптимизирована аутентификация для портфеля с преобладающим облачным сервисом


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

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

6. Устаревший Active Directory


Идентичность это теперь новый периметр, и данные распространяются повсюду, заявили Дэвид Махди и Стив Райли из Gartner в своей презентации.

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

Разумеется, здесь стоит многое исправить. Это означает, что ваша Active Directory (AD) может не отражать реальность как из списка текущих и авторизованных пользователей, так и из текущих и авторизованных приложений и серверов.

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

7. Отказ обратиться за помощью


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

Возможно, вы слишком заняты, чтобы уделять миграции всё свое внимание, и непреднамеренно отбросили некоторые важные аспекты. В спешке, перенесли всё в облако и оставили открытыми несколько бэкдоров или внесли уязвимости.
Подробнее..
Категории: Информационная безопасность , Сетевые технологии , Vpn , Облачные сервисы , Исследования и прогнозы в it , Восстановление данных , Безопасность данных

Brave new world

23.02.2021 14:15:47 | Автор: admin

О дивный новый мир! Как ты прекрасен. Как же ошибался Джордж Оруэлл и как был прав Олдос Хаксли. Никто никого не принуждает ни к чему. Народ сам ломится табунами для того, чтобы получить новую пилюлю и слить всю информацию о себе кому попало. И конечно, тебя-то, хабрачеловек, это не будет касаться. Мы то не то, что остальное человьё. Мы умные. Сидим за фаерволлами, торами и всем остальным. Но вот, зачастую упускаем такие моменты, как бабушки, дедушки, мамы, папы и остальные обыкновенные люди, нас окружающие.

Говорить мы будем про Brave и фильм под названием The Social Dilemma.

На Хабре этот фильм как то не упоминался вообще. Разве что, я пропустил где-то переведённую на русский версию. Ну а зря.

The Social Dillema

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

Тристан Харрис (автор проекта, защитник данных и большой любитель потроллить большие корпорации) рассказывает и показывает что да как сейчас происходит в индустрии обработки данных, социальных сетей, бесконечного скроллинга и тому подобных вещей. Если вы посмотрите на список участников фильма, то вы найдёте бывших сотрудников:

  • Google

  • Facebook

  • Firefox & Mozilla Labs

  • Instagram

  • Uber

  • NVIDIA

  • Youtube

Все эти ребята собрались вместе и как полагается рассказали обо всём, что происходит в индустрии.

В оригинале: If youre not paying for the product, then you are the product.В оригинале: If youre not paying for the product, then you are the product.

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

Фильм очень хорошо рассказывает о проблемах современного программного обеспечения, которое уж слишком сильно косплеит Большого Брата. В том числе понятно и ясно рассказываются что и почему. Как так выходит, что некоторые люди готовы платить за твоё внимание.

There are only two industries that call their costumers `users`: illegal drugs and software. (К сожалению, смысл ломается при переводе на русский. Если есть предложения по лучше, пишите)There are only two industries that call their costumers `users`: illegal drugs and software. (К сожалению, смысл ломается при переводе на русский. Если есть предложения по лучше, пишите)

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

Фильм заслуживает премии за свою вменяемость. Несмотря на то, что один из участников проекта, Джарон Ланье (http://personeltest.ru/aways/en.wikipedia.org/wiki/Jaron_Lanier) выглядит как упоротый хиппи, его советы не такие уж и упоротые. На самом деле, этот человек работал в Atari в 1985 году, после чего покинул компанию, и работал над множеством проектов, такие как первые VR гарнитуры, Internet2 и так далее. Сейчас он работает в Microsoft Research, и в 2018 году он написал книгу под названием 10 причин почему вам надо удалить свои аккаунты в социальных сетях прямо сейчас. Советы же в фильме не настолько бесполезные.

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

Кстати, фильм имеет приличный рейтинг на этих ваших гнилых помидорах. А на гугл так вообще оценил его в 95%, что весело, ввиду того, что гугл прилично огрёб от этого кина.

(Отступление, и ложка дёгтя в бочке мёда. Фильм на английском. Он был выпущен в сентябре 2020 и я не видел его русских переводов. Так вышло, что большинство моих родственников по той или иной причине понимают язык в той степени, чтобы посмотреть фильм. Но не у всех всё так же радужно. Для решения этой проблемы, я хотел бы посмотреть, если у нас получится захаброэффектить всё это дело. На сайте фильма можно послать отзыв. https://www.thesocialdilemma.com/contact/. Если вы не англоговорящий, спросите, есть ли планы. А если вы себя чувствуете достаточно сильным почему бы не предложить ребятам свою помощь в переводе. Хотя бы субтитры. Поправьте меня, если я не прав и вы знаете о русской версии.

Ну а на пока что придётся обойтись всё той же книгой 10 причин почему вам надо удалить свои аккаунты в социальных сетях прямо сейчас, благо её найти можно.)

На самом деле, мы то с вам уже об этом давно знаем. Нам, хабрачеловекам, не надо рассказывать о том, почему Фейсбук сделал бесконечный скроллинг. Мы с вами безостановочно выпиливаем скрипты телеметрии из всего что только можно. Наши браузеры обвешаны блокировщиками по самое не хочу до того состояния, что только половина сайтов работает более-менее нормально (и мы этому рады). Есть часть таких как мы, которые вообще не водятся вконтактиках и фейсбуках, а если и водятся, то только для того, чтобы использовать мессенджеры для общения с бабушками и дедушками.

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

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

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

Ну хорошо, мы можем попробовать просветить неведущих, показывая им фильмы и давая им книги. Но что делать со всей этой рекламой, которая льётся со всех сторон? Просто ставить адблок на Microsoft Edge и Яндекс Браузер? Ага. Эти с удовольствием сливают идентификатор машины, и независимо от того, сколько раз ты их переустановишь, продолжают следить за твоим компьютером.

Ладно, зачем эти спиноффы? Мы то знаем, что есть Хром и Огнелис! (Которые льют идентификатор инсталяции, и их можно немного урезонить, путём полной переустановки. Хотя, гуглу и на это полный пофиг, потому что всё подключено к вашим этим аккаунтам).

The Brave - защитник наших данных

Ну и тут на сцену выходит Король Brave. О! Посмотрите только на отзывы в Google Play для мобильной версии этого браузера. Таких рейтингов просто так не наберёшь. Все отзывы исключительно положительные. (Может быть процентов пять жалобы на то, что у кого-то поломался бинарник после апгрейда).

Да что там, весь интернет только и говорит о том, какой замечательно безопасный это браузер, который не льёт эти ваши данные направо и налево! Да ещё и позволяет вам зарабатывать бабло на просмотре рекламы! (Хаха, вот это интересная идея, почему бы не развернуть этот движок рубли бабла в обмен на моё внимание другой стороной. Пусть мне будут платить за внимание). Ну так, а как вам поддержка IPFS и Tor? Да просто замечательно! Беру! Пачку! Весь прайд. Устанавливаю на все устройства.

Но только и Лев сам себе иногда попукивает и неприлично пахнет, особенно, когда он зело обожрался зеброй (тобишь, маркетинговых кампаний). Почему бы не вкрутить автоподставку своих реферальных кодов без разрешения? Ну так вкрутим! http://personeltest.ru/aways/habr.com/ru/company/itsumma/news/t/505782/. А, может быть, вам всё-таки показать кое-какую рекламу, которую Король Brave счёл нужной? Покажем!

Ох, ну что же всё так плохо? Почему же так сложно сделать всё по-человечески?

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

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

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

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

И что же? А вот что:

Я знаю, что на хабре есть люди причастные к проекту и они следят за тем, что здесь происходит.

Я хотел бы предложить (и надеюсь, вы меня можете поддержать) сделать следующую функцию в Brave режим суперпаранойи. Режим этот может вызываться очень странными способами. Пусть даже если мне придётся вбивать код Конами десять раз подряд в главном системном меню браузера, чтобы это всё активировать.

В режиме суперпаранойи должно быть сделано следующее:

  • Никакой синхронизации закладок.

  • Никаких профилей.

  • Никаких менеджеров паролей и кредитных карточек. Мне это не нужно. У меня всё в офлайне.

  • Разрешить очищать историю при выходе из браузера.

  • Никаких разрешённых реклам. Просто всё нафиг закрыть.

  • Убрать-таки все эти разрешённые фейсбучные сайты из списков разрешённых. Мне пофигу что половина сайтов в интернете будет нерабочей. Если сайт не работает в таком состоянии, я скорее всего не захочу им пользоваться.

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

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

Единственное что вам нужно будет сделать это закопать разодранную зебру подальше и перестать заниматься неприличествами. Дайте мне, в конце концов, браузер который 100% ничего никуда не льёт, и я в обмен, найду вам аудиторию, которой вы можете показывать рекламу, кормить свои BAT или вставлять реферальные коды. (С условием, конечно, что вы будете держаться честно и не будете лить персональные данные, за чем вас ещё не уличили, насколько я могу видеть).

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

Подробнее..
Категории: Информационная безопасность , Социальные сети и сообщества , Браузеры , Big data , Facebook , Вконтакте , Персональные данные , Безопасность данных , The social dilemma , Brave браузер , Brave new world , Лев и зебра

Вебинар защита конфиденциальной информации и управление рисками, связанными с данными

14.05.2021 10:12:48 | Автор: admin
27-28 мая, на английском с субтитрам на русском27-28 мая, на английском с субтитрам на русском

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

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

На этом мероприятии:

  • Поймите, идентифицируйте и защитите свои самые конфиденциальные данные.

  • Выявляйте инсайдерские риски и нарушения кодекса поведения и принимайте соответствующие меры.

  • Используйте защиту информации и управление.

Подробности и регистрация.

Подробнее..
Категории: Информационная безопасность , Безопасность , Microsoft , Учебный процесс в it , Хранение данных , Блог компании microsoft , Разработка для office 365 , Microsoft 365 , Безопасность данных

Recovery mode ZOOM история создания сервиса, проблемы с безопасностью и секрет популярности

16.02.2021 20:15:11 | Автор: admin

Казалось бы, до марта 2020 года мало кто вообще в России слышал о сервисе видеоконференций с названием ZOOM. Зато теперь о нем говорит каждый второй, даже несмотря на слухи о проблемах с безопасностью личных данных. Ни у кого нет внятного объяснения того, почему этот сервис стал столь популярным в мгновение ока. С другой стороны, ответ очевиден: эпидемия коронавируса заставила бесчисленное количество людей работать из дома, а удаленным сотрудникам нужен инструмент для проведения видеооконференций. Однако еще задолго до того, как удаленная работа стала мейнстримом, люди тоже пользовались ZOOMом и предпочитали его большинству приложениям для видеосвязи. Так что вопрос почему люди выбирают ZOOM? по-прежнему актуален. Давайте разбираться, почему так?

Первое появление ZOOM и проблемы с безопасностью

К настоящему времени история ZOOM больше мифологична и вызывает много вопросов, а потому начнем с самого начала. В 2011 году Эрик Юань, ведущий инженер подразделения WebEx в компании Cisco, уволился с работы и решил создать собственный бизнес. Он набрал команду, собрал первые инвестиции, а два года спустя появился проект ZOOM. Проект собирает еще больше денег от инвесторов и Эрик начинает сразу же использовать сервис для проведения деловых встреч с новыми инвесторами, осуществляя демонстрацию возможностей программы на практике. Что ж это сыграло ему на руку: к 2015 году проект привлек 30 миллионов долларов, а к 2017 году его стоимость оценивалась в 1 миллиард.

Все ли было так гладко? Нет. Давайте перенесемся на несколько лет вперед. Первая проблема сервиса вскрылась в 2018 году, когдабыла обнаружена уязвимость, позволявшая неавторизованным пользователям внедряться в конференции и подделывать сообщения участников собрания, а также удалять пользователей из беседы. Весной 2019 года специалисты по безопасности обнаружили в приложении ZOOM для MacOS еще одну дыру, которая позволяла вредоносным сайтам насильно добавлять пользователей в конференцию и активировать их веб-камеру. Эта проблема затронула даже тех пользователей, который удалили ZOOM со своего Макинтоша, что вынудило Apple выпустить патч безопасности. ZOOM в свою очередь изменил способ предоставления разрешений для подключения к конференциям.

Впрочем, эта ситуация не повлияла на позиции ZOOM, сделав его к концу 2019 года одним из самых популярных бизнес-инструментов, а также самым быстрорастущим. В начале марта 2020 года прирост новых клиентов составил 61%, а выручка компании выросла на 88% по сравнению с 2019 годом. К концу марта 2020 года ZOOM даже обогнал TikTok по количеству скачиваний в AppStore. А затем случился громкий скандал с утечкой пользовательских данных. Тот неловкий момент, когда популярность совсем не играет на руку: 4 апреля 2020 года СМИ сообщили, что тысячи личных видео из ZOOM были выложены в Сеть для открытого просмотра и обвинили компанию в безалаберном отношении к конфеденциальности своих пользователей. Спору нет, ведь в эпоху самоизоляции многие люди перенесли в формат видеозвонков даже личные взаимодействия.

Крупнейшая утечка данных: причины и последствия

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

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

Однако позже Эрик Юань принес извинения за то, что ZOOM не соответствует ожиданиям пользователей в отношении конфиденциальности и безопасности, и заявил, что компания перенаправит своих инженеров на устранение недостатков безопасности. Также Эрик опубликовал в своем блоге запись о том, что сервис ZOOM используется гораздо шире, чем он предполагал, когда основал компанию в 2011 году. Мы не разрабатывали продукт с предвидением, что в течение нескольких недель каждый человек в мире вдруг начнет работать, учиться и общаться дома, написал Эрик в качестве оправдания. По его словам, новые пользователи видеосервиса начали использовать ZOOM неожиданными способами, которые поставили перед компанией проблемы, с которыми никто не ожидал столкнуться при создании платформы. Честно говоря, очень странно, что разработчики приложения действительно не подумали заранее о том, что люди начнут сливать видеозаписи и просто записи разговоров в Интернет.

Специалисты по безопасности бьют тревогу

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

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

Особенно встревоженными оказались представители сексуальных меньшинств. Рут Шварц, директор компании Conscious Girlfriend (группа поддержки отношений для однополых отношений между женщинами) ужаснулась, когда узнала, что видеозаписи ее групповых сессий можно просматривать через Интернет. По ее мнению, женщины с нетрадиционной ориентацией и без того постоянно подвергаются нападкам, но из-за небезопасного ZOOM это может усугубить их положение в обществе. Это действительно важный звонок для всех, ведь социальная связь является одним из главных факторов, определяющих психическое и физическое здоровье. Для всех нас, кто выполняет такую деликатную работу, необходимы максимальные меры предосторожности для защиты наших сообществ. Очень жаль, что ZOOM позволяет себе пренебрегать этим.

Почему люди выбирают ZOOM, а не Skype?

Несмотря на явные проблемы с безопасностью, люди все равно продолжают делать выбор в пользу ZOOM, а не сторонних сервисов конкурентов. Почему так происходит? Пользователи сервиса рассказывают, что основная причина, по которой они любят ZOOM, кроется в том, что максимальная задержка во время разговора не превышает 150 мс. Руководство самого ZOOM отмечает, что людям нравится их приложение просто потому, что это работает: никому не приходится лишний раз убеждаться, что все пользователи, подключившиеся к собранию, могут хорошо слышать каждого оратора. Кроме того, приложение эффективно функционирует на мобильном телефоне и позволяет удобно производить демонстрацию экрана для всех участников беседы.

Вы скажете, что даже майкрософтовский Skype умеет делать тоже самое безо всяких танцев с бубном, и будете совершенно правы. А значит, одной лишь функциональности недостаточно для того, чтобы быть лидером рынка. Именно поэтому мы начали разговор с низкой задержки, которая не позволяет допускать рассинхрона между видео и звуком. ZOOM постоянно сравнивается скептиками с такими сервисами, как Skype и Hangouts (последний не популярен в России), которые предлагают аналогичные наборы инструментов для совершения видеосессий и общения, но в подавляющем большинстве люди все равно выбирают ZOOM.

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

Поскольку ZOOM продолжает дистанцироваться от толпы видеочатов, преображение мира в формате перехода на удаленную работу, приносит только пользу создателям видеосервиса. Бесспорно коронавирус увеличил число людей, которые перешли на работу из дома: примерно 4,7 миллионов жителей США и почти 6 миллионов жителей России перевели на удаленку с февраля 2020 года. Для этих людей ZOOM это больше, чем просто возможность проводить видеоконференции. ZOOM это теперь и есть офис. Более 10 миллионов человек присоединяются к встрече Zoom каждый день. А еще в феврале 2020 года компания достигла более 200 миллионов ежедневных пользователей по сравнению с 10 миллионами в декабре 2019 года.

ZOOM, коронавирус и планы на будущее

С распространением коронавируса, амбиции руководителей ZOOM раскачались еще больше. У них родилась мысль, что можно сделать нечто большее, чем просто сервис видеоконференций, ведь ZOOM может изменить способ развития бизнеса в будущем. И эпидемия стала отличным полем для тест-драйва.

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

Мы хотим быть коммуникационной компанией номер один, рассказывают они. Под этим подразумевается превращение сервиса видеоконференций в мощную платформу для текстовых чатов, интеграцию с календарными приложениями, телефонными контактами, трекерами продаж, образовательными платформами и многое другое. Кажется, на выходе мы получим продвинутую версию китайского WeChat для европейцев. Глобальный план ZOOM начинается с видео, а заканчивается всеобъемлющим инструментом коммуникации для всей рабочей силы. Но, конечно же, нет никакой гарантии, что успех ZOOM в видеосреде переместится в другое место, отмечает Рич Костелло из IDC.

С точки зрения продукта задача ZOOM будет заключаться в том, чтобы предлагать гораздо больше опций и возможностей, не теряя при этом простоты работы, которую любят пользователи. Успешные приложения, как правило, всегда пытаются добавить больше функций, что делает их менее полезными и разочаровывает людей, заставляя искать более удобное и простое решение. Эрик Юань знает это не понаслышке после своей истории с WebEx, поэтому ZOOM будет предлагать лишь возможность активации новых опций, не заставляя пользователей пробовать новые возможности принудительно. Если вы подключите какую-то опцию осознанно, то будете понимать, как ее использовать, рассказывает Юань, Однако самый важный способ сделать пользователей счастливыми убедиться, что видео продолжает работать.

Подробнее..
Категории: Сетевые технологии , Zoom , Мессенджеры , Видеочат , Безопасность данных , Zoom interface , Общение в интернете , Видеосервисы

Пентест сети провайдера или почему не стоит доверять свои данные провайдерам в Узбекистане

26.05.2021 18:20:11 | Автор: admin

Предыстория

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

PT0.1ENUM

Решил начать сканирование с подсети 10.3X.X.0/24 т.к она светилась в трасерте несколько раз

насканив несколько свитчей с доступом по 80 порту решил проверить несколько других портов 161(SNMP) и 179(BGP) по итогу получил несколько свитчей с открытым SNMP и тут из всей пачки мне достался один с мисконфигом public и private не были удалены, что и сыграло мне на руку позже

PT1.1Gath

Получив доступ по SNMP к одному из свитчей определился что свитч этот DGS-3620-28SC гигабитный Управляемый L3 стекируемый коммутаторс 20портами SFP,4комбо-портами100/1000Base-T/SFPи4портами 10GBase-X SFP+, используя private community решил слить себе бэкап конфига что мне и удалось используя snmpset

snmpset -v2c -c $COMMUNITY $IP 1.3.6.1.4.1.171.12.1.2.18.1.1.3.3 a $TFTP_SERVER_IPPsnmpset -v2c -c $COMMUNITY $IP 1.3.6.1.4.1.171.12.1.2.18.1.1.5.3 s $FILE_NAME.cfgsnmpset -v2c -c $COMMUNITY $IP 1.3.6.1.4.1.171.12.1.2.18.1.1.7.3 s config.cfgsnmpset -v2c -c $COMMUNITY $IP 1.3.6.1.4.1.171.12.1.2.18.1.1.8.3 i 2snmpset -v2c -c $COMMUNITY $IP 1.3.6.1.4.1.171.12.1.2.18.1.1.12.3 i 3

покопав немного конфиг получаем пароль vfrtgb45switch(заменен в целях безопасности провайдера), а так же другое community string vfrtgb45switch и vfrtgb45switchrw теперь, пробежимся по остальным свитчам и добавим для удобства в последнюю виндовую версию The Dude, после этого мы увидим то что нам действительно нужно это MNGT vlan это 4002 с подсетью 172.2X.X.0/15

Потратил очень много времени на поиски места где же всё таки конфиг разрешает из сети юзера попасть в mngt vlan оказалось это еще несколько мисконфигов в некоторых свитчах, позже просканив еще несколько сетей я нашел свитч ARISTA-100G-CityPlace1 и его брата ARISTA-100GCityPlace2, в общем на данный момент у меня есть доступ к 50 L3 свитчам(до остальных в принципе он и не нужен), на которых спокойненько можно запустить TCPDUMP и собирать трафик всех наших прекрасных пользователей.

PT2.1 Разговор с провайдером

Спустя два месяца после получения первых доступов я добрался до ядра сети, но не стал делать всё плохо(хотя мог просто отключить консоль на всех свитчах, сменить community string и пароль), решил оформить все как надо, пообщаться с директором компании и объяснить ему что мисконфиги это плохо и надо проводить аудиты время от времени, но столкнулся с проблемой, связи с директором увы нет, админа которого мы нашли при помощи знакомых, откровенно сказал что это всё нае***ово и никто его сеть не сможет взломать. позже пошел в центральный офис, в пятницу, сказали что принимает только по вторникам, то есть ему пофиг как и админу, ок не стал торопить события, написал эту статью подготовился и пошел к нему во вторник, он меня не принял со словами завтра позвоню, в итоге на следующий день мне в лс постучался админ который так же котегорично сообщил что ему насрать на то что происходит, то есть компании Turon Telecom абсолютно пофигу безопасность данных которые передают их пользователи.

PT3.1 Для тех кто не смыслит в IT и будет читать это

Для обычного пользователя интернета данного провайдера это кажется не особо важным, но если вчитаться в это можно понять что в любой момент могут быть украдены Ваши логины и пароли от не зашифрованных служб например доступ к сайтам через HTTP, почту которую вы отправляете по SMTP, имея ваш IP адрес злоумышленник сможет видеть сайты которые вы посещали DNS, в общем полные доступы к вашим данным которые не имеют шифрования, это может стать очень пагубным для вас, я не один такой который сможет получить доступ к этой сети. так что люди думайте о своей безопасности!

PT4.1 Ожидание реакции

Сейчас дописал статью и в ожидании реакции или людей которые ее прочтут или реакции провайдера

Подробнее..
Категории: Сетевые технологии , Сетевое оборудование , Isp , Безопасность данных , Узбекистан

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru