Security: теория

Пару примеров о том, что детально описано ниже, до огромной статьи.

Key Takeaways
Patching: Ensure that all systems are fully patched and updated
Protection Databases: Make sure your security tools have the latest databases
Backup: Create or update offline backups for all critical systems
Phishing: Conduct phishing awareness training and drills
Hunt: Proactively hunt for attackers in your network using the known TTPs
Emulate: Test your defenses to ensure they can detect the known TTPs
Response: Test your incident response against fictitious, real-world scenarios
Stay up to Date: Subscribe to threat intelligence feeds like Fortinet Threat Signals
  • Стек технологий/направлений трафика сетевой безопасности от Cisco

  • Sharkbot – пример более-менее продвинутого трояна для Androi – phishing banking app page, keylogging, SMS intercept.
Latest Android Banking Malware Sharkbot Distributed on Google Play Store

It can detect when a targeted banking app is open and display a phishing page to steal the victim's credentials. Keylogging and SMS intercept features are implemented to intercept all the accessibility events produced by the victim when "Accessibility Permissions & Services" is enabled.
 

Взлом matrix.org – пример очень показательного взлома с точки зрения множество важнейших принципов, описанных ниже. Сам хакер очень подробно все описал.

https://archive.md/MfrjB
в матриксе крутили на х.ю самые обычные бестпрактисы. Молодцы, че

I noticed in your blog post that you were talking about doing a postmortem and steps you need to take. As someone who is intimately familiar with your entire infrastructure, I thought I could help you out.
[SECURITY] 2FA is gud
2FA is often touted as one of the best steps you can take for securing your servers, and for good reason! If you'd deployed google's free authenticator module (sudo apt install libpam-google-authenticator), I would have never been able to ssh into any of those servers.
Alternatively, for extra security, you could require yubikeys to access production infrastructure. Yubikeys are cool. Just make sure you don't leave it plugged in all the time, your hardware token doesn't do as much for you when it's always plugged in and ready for me to use.
Alternate-Alternatively, if you had used a 2FA solution like Duo, you could have gotten a push notification the first time I tried to ssh to any of your hosts, and you would have caught me on day one. I'm sure you can setup push notifications for watching google-authenticator attempts as well, which could have at least given you a heads up that something fishy was going on.
Anyways, that's all for now. I hope this series of issues has given you some good ideas for how to prevent this level of compromise in the future. Security doesn't work retroactively, but I believe in you and I think you'll come back from this even stronger than before.
Or at least, I hope so -- My own information is in this user table... jk, I use EFNet.
  • Лишние привилегии (даешь рут для всех :/)
[SECURITY] Principle of Least Privilege
Escalation could have been avoided if developers only had the access they absolutely required and did not have root access to all of the servers. I would like to take a moment to thank whichever developer forwarded their agent to Flywheel. Without you, none of this would have been possible.
  • Отсутствие аудита логов безопасности
[SECURITY] Monitor log files to avoid relying on external whitehats
Let's face it, I'm not a very sophisticated attacker. There was no crazy malware or rootkits. It was ssh agent forwarding and authorized_keys2, through and through. Well okay, and that jenkins 0ld-day. This could have been detected by better monitoring of log files and alerting on anomalous behavior. Compromise began well over a month ago, consider deploying an elastic stack and collecting logs centrally for your production environment.
  • Отсутствие постоянных обновлений критичных для безопасности систем (CI Jenkins)
После первого взлома командой Matrix был опубликован отчёт, в котором указано, что взлом был совершён через уязвимость в необновлённой системе непрерывной интеграции Jenkins. 
  • Прямой доступ из интернета НА ВСЕ СЕРВЕРА без каких то глупых VPN/reverse-proxy/bastion-host
    • на SSH сервера
    • на сервер CI Jenkins
[SECURITY] Controlled Production Access
I was able to login to all servers via an internet address. There should be no good reason to have your management ports exposed to the entire internet. Consider restricting access to production to either a vpn or a bastion host.

[SECURITY] Jenkins Slave listening to SSH on the internet
Once I was in the network, a copy of your wiki really helped me out and I found that someone was forwarding 22226 to Flywheel. With jenkins access, this allowed me to add my own key to the host and make myself at home. There appeared to be no legitimate reason for this port forward, especially since jenkins tunnel was being used to establish the communication between Themis and Flywheel.

Ну и чуть более сложные:

  • Хранение ключей для создания подписей СВОИХ МЕГА БЕЗОПАСНЫХ ПРИЛОЖЕНИЙ на рабочих серверах, а не на изолированном хосте
[SECURITY] Signing keys in production?!?
There I was, just going about my business, looking for ways I could get higher levels of access and explore your network more, when I stumbled across GPG keys that were used for signing your debian packages. It gave me many nefarious ideas. I would recommend that you don't keep any signing keys on production hosts, and instead do all of your signing in a secure environment.
  • Включенный “проброс ключа ForwardAgent” в ssh – позволяет с одного сервера подключаться на другой без пароля, форвардом ключа от первого сервера второму
[SECURITY] SSH Agent Forwarding
Complete compromise could have been avoided if developers were prohibited from using ForwardAgent yes or not using -A in their SSH commands. The flaws with agent forwarding are well documented.
  • Хранение в Git репозитории всех важных данных и полностью репа заливалась на хосты, хотя по факту в этом нужды не было
[SECURITY] Git is not a secret store
The internal-config repository contained sensitive data, and the whole repository was often cloned onto hosts and left there for long periods of time, even if most of the configs were not used on that host. Hosts should only have the configs necessary for them to function, and nothing else.

 

 

Источники

 

А теперь перейдем от практики к непосредственно теории.

 

Стандартизация
  • NIST Cybersecurity Framework (National Institute of Standards and Technology) – совокупность индустриальных стандартов и наилучших практик для защиты организаций в контексте кибербезопасности от гос. органа США (всего более 500 штук). Одной из основных целей стандартизации является управление рисками кибербезопасности критической инфраструктуры эффективно и не дорого. Framework может использоваться как основа для любой организации. В целом публикации NIST охватывают широкий круг вопросов безопасности (от контроля доступа до беспроводной безопасности) и являются очень ценным источником информации.
  • ISO/EIC 27000 (ISO27k) – набор стандартов (порядка 50) о информационной безопасности от ISO (International Organization for Standardization) и IEC (International Electrotechnical Commission). Первые же 6 документов рассматривают большой пул вопросов касающихся развертывания/поддержки/мониторинга/аудита систем управления ИБ (ISMS). Организации могут/проходят процедуру соответствия этим сертификациям.
  • Регулирующие процедуры особенно развиты в США. Яркий пример – процедура в США, обязательная Federal Civilian Executive Branch (FCEB), но рекомендованная всем: в течении двух недель после анонса Cybersecurity & Infrastructure Security Agency (CISA) закрыть уязвимость существующим патчем.
    The Cybersecurity & Infrastructure Security Agency (CISA) added CVE-2022-21882 to the list of known publicly exploited vulnerabilities on February 4, 2022.

    This means that all Federal Civilian Executive Branch (FCEB) agencies are now required to patch all systems against this vulnerability within two weeks, until February 18.

    While Binding Operational Directive 22-01 (BOD 22-01) only applies to FCEB agencies, CISA strongly urges all private and public sector organizations to reduce their exposure to ongoing cyberattacks by adopting this Directive and prioritizing mitigation of vulnerabilities included in its catalog of actively exploited security flaws.
  • NSA/US government активно вкладывались и вкладываются в направление ИБ, участвовали в разработке The Ghidra, спонсировали такие проекты как snort/suricata (и использовали snort) и методологии тестирования IDS. author Victor Julien <victor@inliniac.net>
What the Suricata development by the OISF has shown in my opinion is that we’ve managed to create a very promising new Open Source project out here. In little over a year, funded for about $600k by the US government and with heavy (and growing) industry support, we’ve produced a new IDS/IPS engine mostly compatible with Snort but build on a all new code base an incorporating some very interesting fresh ideas. We’re already seeing a community form around our project with a lot of support from that new community.

This work has been funded by the National Security Agency INFOSEC University Research Program under Contract Number DOD-MDA904-93-C-4084.
Терминология (словарь/dictionary)
  • CIA triad (confidentiality, integrity, availability) – ключевые аспекты безопасности. Каждый из аспектов можно раскрыть подробнее, например
    • конфиденциальность подразумевает что данные видимы только тем, кто авторизован их видеть. Требует совокупность мер для реализации – шифрование, ограничения физического и логического доступа и даже контроль маршрутизации трафика. Чаще всего технически задача конфиденциальности решается шифрованием. В общем случае задача конфиденциальности решается тремя общими концепциями:
      • определение того, какая информация нуждается в контроле
      • определение лиц, которые авторизованы и не авторизованы в получения доступа к этой информации
      • контроль доступа к информации только авторизованным пользователям 
    • целостность подразумевает что данные защищены от порчи, подмены (имитозащита). Чаще всего технически задача целостности решается хешированием. Так же шифрованием, цифровыми подписями, контролем процессов, тестированиями кода, анализ логов, мониторинг (напр. контроль целостности файлов), тренинги персонала.
      • Воровство пароля админа в последующим изменением конфигурации сервисов/серверов/устройств – тоже атака на целостность.
      • Malware которое модифицирует/уничтожает системные файлы, необходимые для загрузки – пример неавторизованной манипуляции, атаки на целостность.
      • Подмена/удаление медицинских или банковских данных.
    • доступность подразумевает что сервис доступен (напр. сайт online retailing, ISP provider, cloud provider) для легитимных пользователей. Самой частой атакой против доступности является DoS (denial-of-service). Показателем доступности является uptime (сколько времени в процентах сервис доступен), например ISP/датацентры часто публикуют данные/подписывают договоры (SLA) с 99.999% доступностью (99.999% uptime). В среднем мы более уязвимы к проблемам доступности в сравнении с проблемами конфиденциальности и целостности. Методы митигации угроз доступности включают контроль доступа, мониторинг, отказоустойчивость, виртуализация, административные меры (процедуры, планирование).

Какой из этих аспектов CIA triad более важен? Во первых они связаны – например, потеря пароля может привести к проблемам по любому из аспектов. Во вторых компания должна решать сама на основе ее целей, сервисов, регламентов и соглашений.

  • Атаковать сложнее чем защищать – атакующему зачастую достаточно провести успешно только одну атаку из 100, чтобы взломать систему. При этом защищающийся может успешно отразить 99 атак и система все равно будет взломана.
  • Risk (риск, управление рисками) и идеальная безопасность – возможность понести потери в случае атаки на систему (реализации угрозы). Безопасность вся основывается на рисках – определение рисков, определение вероятности атак, разработка/проектирование систем для минимизации рисков этих атак (простейший пример из жизни – переход дороги). В контексте безопасности есть аксиома, что невозможно полностью исключить риск – невозможно сделать идеально защищенную систему (impossible to make absolutely secure) т.к. полностью безопасная система – отключенная от сети, питания, к ней нет доступа ни у кого. Но это не повод не делать ничего (даже в контексте безопасности дома – все закрывают двери). Правильный подход – это идентифицировать риск, принять меры по уменьшению и мониторить, приняв его как остаточный риск (residual risk). С риском ассоциируются понятия assets (активы), threats (угрозы) и vulnerabilities (уязвимости). Для “работы” с рисками правительство США разработало risk management framework (RMF) на базе публикации NIST 800-37.
    • Assets (активы) – любой предмет, который представляет какую либо ценность. Может быть реальным – роутеры, сервера, ноутбуки и проч; может быть и виртуальным – формулы, базы, таблицы, торговые секреты. Независимо от типа актива его потеря может привести к финансовым потерям компании.
    • Risk assessment (оценка рисков) – начинается с threat modeling (моделирования угроз). Подразумевается идентификация возможных источников угроз (векторов атак, таких, как уязвимости) для систем (критичных систем/критичных данных) с точки зрения потенциального атакующего, приоритизация этих угроз в зависимости от вероятности и серьезности (например, для уязвимости – можно ли использовать ее удаленно, вероятность ее использования, тип доступа, который получит атакующий в результате эксплойта). 
  • Безопасность во многом – это меры предотвращения инцидентов и реагирования на них. «Хороший пожар — это тот, который не произошел, (((или хуже))) мы его потушили до того момента, как он разгорелся», — цитата, которая отражает роль безопасности в обеспечении непрерывности бизнеса. 
Reducing the attack surface should be your first goal.
  • Trade-off (компромис) – во многих темах безопасности встречаются темы компромиссов между безопасностью и удобством:
    • безопасный  пароль ! = пароль который легко запомнить,
    • максимальная длина ключа != максимальная скорость работы,
    • цена/безопасность аппаратной реализации != цена/безопасность программной
    • безопасность 3FA != удобству 1FA
    • удаленный доступ со своего девайса (вместо rdp/VM) != безопасный доступ
    • и так далее
  • Vulnerability (уязвимость) – недостаток в системе (программной или аппаратной), который может быть использован для компроментации системы. Уязвимость не всегда имеет эксплойт (особенно публичный) и не всегда даже может быть эксплуатирована (подробнее ниже). Уязвимость может быть обнаружена в любой системе (application, OS, hardware) – не существует полностью неуязвимых систем. Вендоры/исследователи обычно после обнаружения уязвимости назначают ей номер CVE (Common Vulnerabilities and Exposure) и исправляют, но это не всегда так – вендор/пользователь может не исправлять уязвимость из-за простого отсутствия финансов. Так же уязвимость может не исправляться т.к. библиотека уже всеми забыта. Поддержкой CVE базы занимается организация MITRE. Пример конкретной уязимости CVE-2017-3881. Пример аппаратных уязвимостей – Spectre, Meltdown. Пример базы с уязвимостями ФСТЭК

Не все уязвимости имеют Exploit, такие уязвимости часто называют “theoretical vulnerabilities”, но нужно всегда иметь ввиду, что если вы не нашли или не придумали эксплойт, это не значит его нельзя найти (напр. глубоко в darkweb) или придумать и скрытно использовать (напр. спецслужбами). Поэтому в природе не бывает полностью “theoretical vulnerabilities”.

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

    • Android ОС работает на базе ядра Linux и все прекрасно знают, что Android – не эталон в плане безопасности
    • Интересная статистика Fortinet. В топе по защищаемым IPS атакам D-Link, Linux! (Linux.Kernel.TCP.SACK.Panic.DoS), PHP.
    • Fortiguard первым ставит атаки на Linux как перспективы роста в ближайшее время
    • Top 5 IPS: 2-3 атаки из TOP 5 на CPE устройства несмотря на период выборки.
1 D-Link.Devices.HNAP.SOAPAction-Header.Command.Execution 23
2 Linux.Kernel.TCP.SACK.Panic.DoS 21
3 ThinkPHP.Controller.Parameter.Remote.Code.Execution 21
4 PHPUnit.Eval-stdin.PHP.Remote.Code.Execution 18
5 Dasan.GPON.Remote.Code.Execution 17

# другая неделя (через несколько мес после первой)
1 D-Link.Devices.HNAP.SOAPAction-Header.Command.Execution 21
2 Apache.Log4j.Error.Log.Remote.Code.Execution 20
3 Dasan.GPON.Remote.Code.Execution 20
4 Telerik.Web.UI.RadAsyncUpload.Handling.Arbitrary.File.Upload 20
5 HTTP.XXE 19

Although no one can predict the future, here are five up-and-coming threats we're keeping an eye on at FortiGuard Labs.
1. Linux Attacks
2. Satellite Network Attacks
3. Attacks Targeting Crypto Wallets
4. Attacks on OT Systems
5. Attacks on the Edge
  • 0-day vulnerability, zero-day exploit – уязвимость нулевого дня – уязвимость, которая неизвестна производителю продукта, но известна хакеру. 0 дней подразумевает за сколько нужно ее починить (или сколько дней известно о уязвимости) 😀 По факту зачастую даже после патча чинится куда дольше – нужно время для его “разливки”.
  • Exploit – софт или набор шагов, который использует (эксплуатирует) уязвимость в системе. 

Пример базы с exploit-ами – популярный http://exploit-db.com/ от Offensive Security или github. Есть так же очень удобный command-line tool “searchsploit“, который позволяет выгрузить копию exploit database и в консоли искать эксплойты. Exploit’ы чаще всего продают в dark web. Exploit’ы не всегда выкладываются для злого умысла или зарабатывания денег – они являются proof-of-concept (POC).

  • Threat – в общем случае это любая потенциальная угроза. Это может быть угроза использования уязвимости (возможная атака), угроза отказа в обслуживании, угроза воровства данных, отказа объекта КИИ (stuxnet), угроза пожара или другого катаклизма и проч. В общем случае угроза может приводить к любым проблемам CIA (Confidentiality, Integrity, Availability). Сущность, получающая профит от использования уязвимости известна как malicious actor (threat actor – подробнее отдельно), а путь используемый этим actor для осуществления атаки известен как threat agent/threat vector.
  • Threat actor, malicious actor – личность или группа личностей, осуществляющих атаку или ответственные за security инцидент. Типы:
    • script kiddies (используют написанные другими инструменты),
    • organized crime groups (в основном занимаются воровством информации и зарабатыванием денег),
    • state governments (серьезные ребята),
    • hacktivists (занимаются этим по идеологическим причинам),
    • terrorist groups (групп мотивированные политическими или религиозными целями). 
  • Attack vector (вектор атаки) – метод или механизм, которые атакующий может использовать для атаки сети/системы. Примеры векторов атак – вложения в почте, сетевые протоколы/сервисы. В зависимости от используемого приложения могут быть наиболее “актуальные” те или иные веторы атак, к примеру есть очень известный список OWASP TOP-10 (линк на непосредственно сайт OWASP – Open Web Application Security Project), в который включены самые опасные атаки на WEB приложения (SQL injection, auth implementation problems,  sensitive data exposure, XXE, XSS, url, deserialization, security misconfiguration, unsecure components, using components with known vulnerabilities, insufficient logging & monitoring, etc).

Для тренировки с уязвимостью XSS и другими WEB-уязвимостями, которые рассмотрены в проекте OWASP можно использовать тулзу OWASP Juice Shop, можно на практике посмотреть уязвимости OWASP top 10 и другие (подробнее в XSS).

  • Attack scope (совокупность векторов атаки) – совокупность векторов атак
  • Attack – непосредственно атака на систему. Одна атака может иметь тысячи вариаций.
  • Defense in depth (эшелонированная защита) – концепция наличия нескольких наложенных систем защиты. Может быть реализована даже в рамках одного продукта (например, Firewall). 1) Нельзя полагаться на одну систему (SPOF) 2) Каждый из элементов защиты может быть не идеален, но он является потенциальным барьером, который может помочь отразить или как минимум замедлить атаку. Пример практического обоснования Defense in depth.
A defense-in-depth strategy uses a series of mechanisms to slow the advance of an attack that aims at acquiring unauthorized access to data.

Как в замке.

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

    • Яркий пример – это куча эксплойтов у ведущих вендоров, позволяющих обойти аутентификацию. Почему ОБЯЗАТЕЛЬНО нужно закрывать доступ к устройствам на уровне протоколов (ACL), использовать серую адрессацию, а не только полагаться на аутентификацию в соотвествующих протоколах (SSH, SNMP, telnet, etc).

      https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170629-snmp
      https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20190501-nexus9k-sshkey
    • best practice настраивать и sshd_config и iptables для защиты подключения по ssh на сервер
    • как бы плохи антивирусы не были, они хорошо защищают от популярных известных атак (модель blacklist). Конечно, с точки зрения безопасности лучше иметь binary whitelisting software (bit9) – который будет запрещать все, кроме того что явно не разрешено (концепция implicit deny ниже), но это очень неудобно, особенно если он не полагается на signing PKI (концепция trade-off выше ;)), но недостаток есть и у них – если доверять всему подписанному, не смотря внутрь, то, в тот момент, когда подделают подпись – тебе хана (примеры подобных атак были).
    • как бы не были плохо функции защиты port security и MAC authentication, если они не накладывают серьезных недостатков в поддержании актуальными баз адресов – они могут быть полезны
    • То же самое и про firewall – помимо классических сетевых устройств, должны быть и host-based firewall, у которых будут примерно такие же правила, как у классического устройства или даже больше (защита внутри сети от зараженных устройств внутри сети за файрволом) или защита mobile юзера.
      • Fail-closed – близкая к Implicit deny концепция,  только описывает что делать с трафиком после сбоя (default action в таком случае)
      • Физическая изоляция (англ. air gap «воздушный зазор»[1]) — одна из мер обеспечения информационной безопасности, которая заключается в том, что безопасная компьютерная сеть физически изолирована от небезопасных сетей: интернета и локальных сетей с низким уровнем безопасности[2]. Физическая изоляция применяется в компьютерных сетях при необходимости обеспечить высокий уровень безопасности. 
      • Machine Learning Security – частично в Machine Learning, частично в DNS security
      • Internal Attack Team – есть во многих организациях, включая Google. Хакеры в белых шляпах.
      • BYOD – Bring Your Own Device, remote work. К концу 2021 30% рабочей силы перейдет на постоянную удаленную работу (Global Workspace Analytics). Актуальная статистика Cisco – большая часть сотрудников счастливы от Hybrid work (совмещение работы в офисе с удаленной) и более мотивированы.

      • OSINT (Open sourceintelligence) — Разведка на основе анализа открытых источников информации, разведывательная дисциплина, включающая в себя поиск, выбор и сбор разведывательной информации из общедоступных источников, а также её анализ. Примером можно считать avinfobot telegram бот, который из открытых источников агрегирует информацию по номерам авто/телефонам или ФИО.
      • Survival Time системы без защиты, патчей (что не менее важно) и с неактуальной версией системы (Windows XP, god forbid), смотрящие “голо” в интернет – час. Потом ее хакнут. Поэтому безопасность – это важно.
      • Security Misconfiguration – неправильная конфигурация продукта с точки зрения безопасности (напр. использование устаревших типов шифрования, устаревших методов аутентификации). Частая проблема, особенно в свете того, что дефолтные конфиги зачастую уже имеют заложенные недостатки с точки зрения безопасности.
      • Security Education – обучение по безопасности, обязательно в компаниях, которые заботятся о своей безопасности. Обучать нужно всех сотрудников, не только сотрудников SoC/IRP. Должно включать самые распространенные способы атаки (почтовые вложения, зеркала, пароли) и способы защиты от них. 
      • Third party security – безопасность сторонней организации с которой взаимодействует твоя организация. Нужно проверять сторонние организации на соответствие политикам безопасности (внутренним внутри организации и зачастую даже твоим политикам) через VSAQ (Vendor security assessment questionnaries, быстрый и эффективный способ) или даже тестировать (audit, vulnerability test, pentest) их решения на безопасность. Пример VSAQ от Google.
      • Zero Trust не доверяем никому и ничему по умолчанию (пользователям, приложениям, трафику, данным или узлам) до тех пока не проведем их проверку. ZTNA (Zero Trust Network Access) – повторяющаяся проверка доверия, а не однократная – идентификация/аутентификация и оценка соответствия устройства при каждом соединении/доступе/новом запросе (посессионная). Доступ только к выбранным приложениям.
      Концепция Zero Trust появилась, когда современные подходы, основанные, в первую очередь, на защите периметра, стали давать сбой. Когда к внутренним ресурсам стали подключаться различные клиенты, партнеры, контрагенты, когда компании начали активно уходить в облака и использовать мобильные устройства, прежняя концепция – защита периметра – перестала справляться. Возникла новая необходимость защитить и данные, и пользователей, и устройства, которые постоянно меняют свое местоположение. Именно тогда была предложена концепция Zero Trust. Она как раз и означает, что мы изначально не доверяем никому: пользователям, приложениям, трафику, данным, узлам. Не доверяем до того момента, пока не проведем проверку. Эта проверка производится либо постоянно, либо через небольшие интервалы времени, чтобы убедиться, что злоумышленники не смогли подменить пользователя, устройство, трафик, данные, узел и т.д.
      • Bastion host – хост, на входе в какую то (какие-то) IT системы. Позволяет получить доступ к каким то системам с себя/через себя, но на него наложены политики безопасности (аутентификации/авторизации, логгирования, мониторинга).
      • Data leak prevention (DLP) – системы предотвращения данных. Могут анализировать любую активность, включая даже данные, копируемые по RDP.
      • Data Sanitization, Secure Erase, File Shredder, Data Destruction – множество аббревиатур о безопасном удалении данных. Пример реализации в софте – удаление данных Disk Utility MacOS (подробнее). Пример стандартов/подходов/алгоритмов по уничтожению данных:
        • DoD 5220.22-M
        • GOST R 50739-95
        • NAVSO P-5239-26
        • RCMP TSSIT OPS-II
        • CSEC ITSG-06
        • HMG IS5
        • NCSC-TG-025
        • AFSSI-5020
        • AR 380-19
        • VSITR
        • Gutmann
        • Schneier
        • Pfitzner
        • Secure Erase
        • Random Data
        • Writes a Zero
      • Персональные данные (ПД: personally identifiable information, PII) – данные которые позволяют идентифицировать персону. Защищаются законами в большинстве стран и требуют ‘особую’ защиту (напр. ГОСТ шифрование). Потеря таких данных может стать причиной судебного преследования компании, помимо потери доверия клиентов. Примеры персональных данных/информации:
        • PII – personally identifiable information (ФИО, адрес, телефон; биометрические: отпечатки пальцев, сетчатка глаза, ДНК),
        • NPPI – nonpublic personal information (национальность, политические взгляды),
        • PHI – personal health information (сосостояние здоровья),
        • PCI – payment card information.

       

      Разведка угроз (Threat Intelligence)

      Разведка угроз (Threat Intelligence) – это знания о существующих и появляющихся угрозах к активу (asset). Основное применение – информирование бизнеса относительно рисков и последствий угроз для актива. Threat Intelligence включает информацию о активе, внутренних и внешних угрозах, контекст (context), механизмы (mechanisms), индикаторы компрометации (Indicators of Compromise, IoCs), последствия (implications), действия (actionable advice). Вся эта информация является критической для Security Operations Centers (SOC).

      В целом использование опыта других – это полезно (немного капитаним).

      Процесс threat intelligence можно разбить на этапы: планирование (planning), сбор (collection), обработка (processing), подготовка/аналитика/внедрение (analysis and production) и распространение (dissemination).

      Существует ряд стандартов разработанных в контексте Threat Intelligence. Первые три основаны MITRE, поддерживаются сейчас OASIS.

      • STIX – Structured Threat Information eXpression – язык для обмена информацией о атаках, может включать IP адреса/домены контрольных серверов (Command-and-control, C2, CNC), хеши malware и прочее. 
      • TAXII – Trusted Automated eXchange of Indicator Information – отрытый транспортный механизм, который стандартизировал автоматический обмен информацией о гибер-угрозах. Использует формат STIX для передачи cyber threat intelligence (CTI).
      • CybOX – Cyber Observable eXpression
      • OpenIOC – Open Indicators of Compromise – информация о гибер-угрозах в машинном виде (machine-digestible format).
      • OpenC2 – Open Command and Control

      Cybersecurity & Information Security (InfoSec)

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

       

      ОЦЕНКА уровня угроз (CVSS)

      Common Vulnerability Scoring System (CVSS) – оценка уровня угрозы (совокупность рисков) конкретной уязвимости. Можно встретить двух версий – CVSSv2, CVSSv3 (чаще). CVSS является стандартом, используемым security специалистами во всем мире и поддерживается организацией FIRST (Forum of Incident Response and Security Teams). Примеры расчета оценок CVSS на основе анализа реальных уязвимостей есть у самого FIRST.

      CVSS оценка имеет градацию на низкий/средний/высокий/критический уровень. Во ФСТЭК градация почти аналогичная CVSSv3. Примером критичной уязвимости можно считать уязвимость, которая позволяет атакующему удаленно компроментировать систему и получить полный контроль над ней. 

      CVSS
      Textual severity ratings of None (0), Low (0.1-3.9), Medium (4.0-6.9), High (7.0-8.9), and Critical (9.0-10.0)[10] were defined, similar to the categories NVD defined for CVSS v2 that were not part of that standard .[11]

      ФСТЭК
      - низкий уровень, если 0,0 ≤ V ≤ 3,9;
      - средний уровень, если 4,0 ≤ V ≤ 6,9;
      - высокий уровень, если 7,0 ≤ V ≤ 9,9;
      - критический уровень, если V = 10,0.

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

      CVSS оценка состоит из трех компонентов, каждый из которых имеет свою оценку от 0 до 10 и описывает различные характеристики уязвимости и то, как атакующий может эти характеристики использовать:

      • Базового (base)
      • Временного (temporal)
      • Среды (environmental)

      Подробнее о каждом:

        • Базовый (base) – самый важный компонент и единственный обязательный (mandatory) компонент, представляет собой характеристики, присущие уязвимости, которые неизменны со временем и не зависят от пользовательской среды. Сам компонент состоит из трех метрик:
          • Эксплуатируемость (exploitability) – условия, при которых возможна эксплуатация уязвимости.
            • Вектор атаки (Attack Vector, AV) – уровень доступа к уязвимой системе, при которых возможна эксплуатация уязвимости. Бывает четырех типов:
              • Сетевой (Network, N)
              • Смежный (Adjacent, A)
              • Локальны (Local, L)
              • Физический (Physical, P)
            • Сложность атаки (Attack Complexity, AC) – описывает условия, которые не контролируются атакующим, которые должны существовать для эксплуатации уязвимости.
              • Низкая сложность (Low, L)
              • Высокая сложность (High, H)
            • Требуемые привелегии (Privileges Required, PR) – представляет из себя уровень привилегий, которыми атакующий должен обладать на уязвимой системе.
              • Не требуются (None, N)
              • Низкие (Low, L)
              • Высокие (High, H)
            • Взаимодействие с пользователем (User Interaction, UI) – требуется ли взаимодействие с пользователем для осуществления атаки.
              • Не требуется (None, N)
              • Требуется (Requred, R)
          • Влияние на CIA (impact) – влияние на ключевые аспекты безопасности (CIA)
            • Влияние на Конфиденциальность (Confidentiality, C)
              • Низкое (Low, L)
              • Среднее (Medium, M)
              • Высокое (High, H)
            • Влияние на Целостность (Integrity, I)
              • Низкое (Low, L)
              • Среднее (Medium, M)
              • Высокое (High, H)
            • Влияние на Доступность (Availability, A)
              • Низкое (Low, L)
              • Среднее (Medium, M)
              • Высокое (High, H)
          • Зависимые системы (scope change, S) – влияние на другие системы, которые не имеют уязвимости, но зависимы от уязвимой (напр. из-за “падения” роутера с уязвимостью страдают все подключенные к нему устройства, если не имеют backup)
            • Нет влияния (Unchanged, U)
            • Есть влияние (Changed, C)
        • Временный (temporal) – изменяемые характеристики уязвимости, зафиксированные на момент оценки
          • Наличие эксплойтов (Exploit Code Maturity, E)
          • Наличие средств защиты от уязвимости (Remediation Level, RL) 
          • Полнота знаний об уязвимости (Report Confidence, RC)
        • Среды (environmental) – характеристики уязвимости с учетом среды организации
          • Требования к безопасности (Security Requirements CR, IR, AR) для уязвимой и зависимых систем
          • Модифицируемые метрики (Modified Base Metrics,  MAV, MAC, MAPR, MUI, MS, MC, MI, MA) на основе конкретной среды организации

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

      • Attack vector (AV) – Network т.к. атакующий потенциально может находится где угодно и отправить созданный пакет (вообще, зачастую спорно, если 1) хост в изолированном сегменте 2) пакет нужно послать L2)
      • Attack complexity (AC) – Low т.к. создать пакет не сложно (напр. используя Scapy)
      • Privilege Required (PR) – None т.к. не требуется привилегий на уязвимой системе
      • User Interaction (UI) – None т.к. не требуется взаимодействия между атакующим и пользователем уязвимой системы
      • Scope (S) – Unchanged т.к. от хоста не зависят другие системы
      • Confidentiality Impact (C) – None т.к. атака нацелена на Availability
      • Integrity Impact (I) – None т.к. атака нацелена на Availability
      • Availability Impact (A) – High т.к. устройство полностью недоступно после эксплуатации уязвимости
Виды хакеров (hacker, Cracker, white-list)

Изначально термин hacker означал – компьютерный энтузиаст. Далее журналисты начали так же называть личностей, которые занимаются взломом с злыми намерениями. Индустрия предложила в таком случае использовать термин cracker (black hat hackers), а тех, которые “добрые” white hat hacker (ethical hacker). “Добрые” хакеры считают, что вы должны подходить к безопасности инфраструктуры используя хакерские утилиты и идеи. Различают так же и серых хакеров (grey hat hackers), которые в основном выступают в роли “белых” хакеров, но иногда становятся и “черными”. Таких сотрудников лучше не нанимать.

У кого-то на фоне текущих событий на Украине появляется извращенное понимание white hat hackers. Не ведитесь на это дерьмо от бывших учителей спецслужб (NSA, FBA, CIA) США, которые при этом смеясь открыто говорят “NSA on your side”.
 
https://www.youtube.com/watch?v=GudY7XYouRk
 
Из интересного из этого видео (помимо русофобии):
  like: your_host <-->socks5 <--> http <--> socks4 <--> target_host
 
Виды атак

Malware (вредоносный софт)

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

Трояны могут быть похожими на легитимные PDF, email, Word/Excel/PowerPoint документы, но по факту содержать malware код, который сделает все что угодно с вашей системой.

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

Существуют разные виды троянов:

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

Существуют разные способы передачи вирусов (первые три самые популярные):

Соединения поверх сети интернет являются наиболее чаще используемым каналом передачи данных для распространения malware – это могут быть email attachments (самый часто используемый тип, обычно идущий вместе с социальной инженерией), peer-to-peer сети, instant messaging (IM), internet relay chat (IRC), browser/browser extension vulnerabilities, SMS, infected mobile apps (или видимая копия популярного mobile app с трояном по меньшей цене чем оригинал), watering hole (заражение сайта который посещает выбранная жертва), freeware (ничто не бесплатно в этом мире) и проч и проч. Но никуда не делся и классический способ – физический доступ (слив данных флешкой, установка жучков/кейлогеров и проч).

Почему лучше не загружать изображения и тем более вложения из писем – при загрузке могут быть обращения к серверам или даже эксплуатация уязвимостей в стеках/службах/приложениях локальной системы.
Other observed tactics include the use of image files in the emails that are very tiny in scale and report back to the hosting server so that the attacker can determine if the email was viewed or not. Of course, this depends on whether the recipient chooses to download images or not.

Сам код вируса может располагаться как в начале инфицированного файла (prepender), так и в конце (appender).

 
Анализ malware

Вообще анализ malware это “целая наука” и это зачастую крайне сложный процесс.

В своем базовом сценарии malware анализ бывает двух типов:

В malware так же существует понятие search routine – malware делает поиск новых файлов/пространства ОП для заражения. Далее посредством infection routine происходит заражение уязвимых хостов. Payload routine подразумевает непосредственные действия, для которых был написан софт – шифрование диска, отображение текста, отправка зловреда всем твоим друзьям и проч. Trigger routine – счетчик, когда стартует payload routine.

Так же существует понятия profiling – сбор информации о системе и изменения поведения malware для минимизации обнаружения. Это может включать anti-forensics/antidetection routine техники (обфускация, защита от реверс-инженеринга), включенные в malware.

 
Network attacks (сетевые атаки) & Network security

Network attacks:

Сетевая безопасность (network seucirity; наличие firewall, ids/ips, шифрование важных данных, мониторинг/алертинг, использование Wi-Fi, использование VPN, аутсорсинг управления сетью, какое оборудование используется, наличие бекапов конфигов, наличие политик по управлению инфраструктурой – обновление конфигов/софта/проч) крайне важна – сетевые устройства это первая линия обороны в IT инфраструктуре против внешних атакующих.

 

Скорость распространения

Вирусы отличаются скоростью распространения:

fast infection – вирус инфицирует любой файл “до которого может дотянуться”

sparse infection – вирус не инфицирует все подряд во избежание раннего обнаружения

 

 

СОБЫТИЯ и ИНЦИДЕНТЫ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ (security incidents & ALARMS)

Security incident – выявленная или неминуемая проблема в безопасности (NIST 800-61), например – слив, модификация или уничтожение персональных данных (PII, NPPI, PCI, PHI), неавторизованный доступ к интеллектуальной собственности, нарушение сервисов (DoS). По сути любой негатив для CIA triad.

A computer security incident is a violation or imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.

Само понятие инцидента должно быть определено в компании – что является индидентом, а что нет. Сам же факт произошедшего инцидента должен триггерить процедуру ответных действий на него. Причем не все инциденты одинаковы по приоритету – дыра, которая привела к сливу персональных данных (PII, NPPI, PCI, PHI), обычно требует более строгое и быстрое расследование т.к. потенциально придется отчитываться перед контролирующими органами по нему. Приоритет инциденту обычно выставляется инцидент-менеджером или сотрудником ИБ, занимающимся расследованием. Приоритет обычно определяет сроки устранения и список эскалации о инциденте.

Incident handling, incident response, incidents priority

Incident handling, incident response – управление инцидентами – подразумевает, по сути, предсказуемый ответ на разные ситуации (инциденты). Incident response program обычно состоит из ряда документов, которые согласовываются на уровне руководства компании –

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

Ключевой персонал управления инцидентами – координаторы, дежурные, члены IRT, внешние советники.

Для помощи организациям в понимании как нужно обрабатывать security инциденты несколько письменных рекомендаций было создано, например, NIST Special Publication 800-61 – в документе подробно рассказано о работе с инцидентами – определение инцидента и связанных терминов, приоритизация, уведомления, документы и процедуры (policies, plans, procedures), координирование инцидентов, взаимодействие с третьими сторонами, ответственность и ее зона у ролей сотрудников/менеджмента, цели и объекты процедур, зона охвата процедур и проч, проч.

Incident handling, incident response в соответствии с NIST 800-601 включает 4 основные фазы:

  1. подготовку – на основе оценки рисков проводится
  2. обнаружение проблемы, анализ/обнаружение влияния и последствий (в том числе root cause), приоритизация – зачастую это самая сложная фаза, ряд инцидентов обнаружить легко (напр. DoS), но многие инциденты остаются необнаруженными из-за “blind spots” в сети (network visibility), существующим в вашей инфраструктуре, недели и месяцы! Эти blind spots надо устранять, используя разные инструменты (сканеры, аналитика). Источниками информации при инцидентах могут быть те, которые описаны выше, простой googl’инг, снифинг пакетов, ids/ips, netflow/ipfix (подробнее о network visibility и netflow в отдельной статье).
  3. сдерживание разрастания проблемы (containment strategy, напр. через ограничение сетевого доступа или даже отключения уязвимых хостов), устранение и восстановление последствий. Так же в эту фазу включается сбор доказательств, определение ущерба (повреждения/воровства/недоступности сервисов и проч), необходимые ресурсы (временные/материальные) для сдерживания/устранения/восстановления, тип выбранного решения по покрытию инцидента (полное, частичное покрытие), тип выбранного решения по времени (аварийное, временное, постоянное). 
  4. активность после инцидента “lessons learned/post-mortem” – изменение процедур/инфраструктуры для минимизации повторного возникновения. Кроме того в эту фазу включается сохранение доказательств. Все это применимо и к инцидентам, касающимся безопасности.

Управление security инцидентами (так же как и compliance) должно раcпространяться на третьи стороны – эти организации нужно на контрактной основе обязывать уведомлять о фактах произошедших у них индидентов. Кроме того, о инцидентах в вашей компании зачастую придется так же взаимодействовать с третьими сторонами – правоохранительными органами, партнерами, медиа, провайдерам, интеграторами, программными и аппаратными вендорами, а так же в поисках внешней экспертизы (координационные центры, другие команды SoC/incident response). Так же могут быть центры обмена подобной информацией в целом или для конкретной индустрии – например, FS-ISAC (Financial Services Information Sharing and Analysis Center). Взаимодействие со всеми этими внешними организациями, так же как и со внутренними, должно быть описано в incident response plan. Обмен информацией о событиях ИБ с неавторизованными участниками (и зачастую даже с неавторизованными представителями! авторизованных участников) должен быть запрещен во избежание слива информации. 

Incident reporting:

Нужно держать как можно меньшее количество активных инцидентов, закрывать уязвимости еще до того, как они будут эксплуатированы. После же инцидентов нужно обязательно искать “root-cause” (если не нашли во время устранения) оценивать эффективность его обработки и составлять “lessons learned/post-mortem” – выученные уроки с инцидента.

Разумно предовращать эти индиденты (incident preparedness), осуществляя:

Forensic analysis – криминалистический анализ логов/данных с хостов, серверов или сетевых устройств (digital forensic evidence). Чаще всего криминалистический анализ делается на битовой копии данных утилитами, во избежание изменения оригинальных данных (софт начал выпиливаться после того, как увидел, подозрительную для себя активность – напр. недоступность интернета). Оригинальная зараженная система при этом должна быть переведена в режим read only – например, используя джамперы на HDD (сейчас уже редко встретишь, да и данные зачастую в облаке) или, например, аппаратными или программными write blocker. Так же крайне желательно хранить носитель с доказательствами в антистатической сумке или forensic room (и такое бывает, хотя у нас это скорее защищенная “переговорка”) в которой реализована клетка Фарадея (Faraday cage), клетки из проводящих материалов, препятствующtq радио волнам попадать внутрь клетки и выбраться из клетки (mobile, wi-fi, наводкаи, etc). 

В контексте криминалистической экспертизы так же крайне важно сохранение каждого чиха (chain of custody), который делался по расследованию инцидента и работе с доказательствами вплоть до судебного процесса – как вы узнали об инциденте, когда/как/кем собраны доказательства, как хранили/перевозили (lockable container?)/кто имел доступ к доказательству (желательно, чтобы ответственный всегда был с доказательством).

Security Operations Centers (SOC), Incident Response Teams (CSIRT, PSIRT, CERT, MSSP), InfoSec

Существуют различные типы incident response команд и других security команд. Все они призваны минимизировать риски, возникающие от инцидентов ИБ. Стоимость потенциальных угроз зачастую значительно выше содержания в штате специалистов ИБ, которые позволят этим угрозам или не стать инцидентами или устранить эти инциденты с минимальными потерями для бизнеса. Так же есть опция аутсорса подобных услуг (MSSP, подробнее ниже).

Из Российских там три:

Национальные CERT, помимо обеспечения безопасности/расследования инцидентов в ключевых для страны сегментах (финансовом, медицинском, индустриальном, IT и т.д) и информации о разных уязвимостях, обычно предоставляют какое-то обучение, best-practices.

Типы alert/alarm/incidents в security устройствах IDS/IPS:

False positive (ложное срабатывание) – по сути false alarm. Срабатывание системы безопасности на легитимный трафик. Могут быть совсем не безобидным явлением, когда таких эвентов будет много – они будут требовать время на отработку и отвлекать от настоящих security events/incidents.

False negative (ложное несрабатывание) – несрабатывание системы безопасности на malicious трафик.

True positive (правильное срабатывание) – успешное обнаружение security events и срабатывание механихмов защиты на него.

True negative (правильное несрабатывание) – успешное обнаружение легитимной активности и несрабатывание механизмов защиты.

 

 

 

MALWARE EVASIONS

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

Методы, которые усложняют static анализ вирусов с использованием декомпиляторов/дизасемблеров – шифрование, обуфскация, кодирование, Anti-VM, Anti-debugger.

Кроме того вирусы сегодня не распространяются так широко как ранее – они пишутся под конкретную цель, что в итоге делает сложным обнаружения семпла вируса и написания сигнатуры на него. Что своего рода тоже “evasion technique”.

Распространятся malware софт может в wrappers – пакетах программ, включающих два или более исполняемых файла. Так же софт может распространятся в packers в архивах подобных WinZip, Rar, Tar. Еще одним типом является droppers – по сути тоже самое что wrappers. Crypters шифруют код malware используя алгоритмы шифрования или преобразования данных. Делаются все эти манипуляции (wrappers, packers, droppers, crypters) для обфускации обнаружения/активности malware антивирусным/ips ПО при установке malware в систему жертвы.

Malware может использовать многоуровневые подходы к обвускации и шифрования своего кода и единичное или совокупное использование всех этих манипуляций (wrappers, packers, droppers, crypters) приводит к тому, что обнаружение malware cтановится все более сложной задачей.

Примеры сокрытия в ОС:

 
 
Pixilized image obfuscation

По идее depix (depixilizer) можно восстановить – нужный функционал есть в gimp/photoshop или github Depix и других инструментах (напр. бесплатный online сайт lunapic), но на практике Depix не работал даже с правильным “словарем” (несмотря на матчи генерировался бред). Причем над одной строкой pixilized данных скрипт работал 3-5 часов, загружая в полку CPU.

Depix is a tool for recovering passwords from pixelized screenshots.
This implementation works on pixelized images that were created with a linear box filter.
In this article I cover background information on pixelization and similar research.

# python3 depix.py -p pic2.png -s images/searchimages/black-shell-dict-putty.PNG -o output2.png
INFO:root:Loading pixelated image from pic2.png
INFO:root:Loading search image from images/searchimages/black-shell-dict-putty.PNG
INFO:root:Finding color rectangles from pixelated space
INFO:root:Found 494 same color rectangles
INFO:root:480 rectangles left after moot filter
INFO:root:Found 77 different rectangle sizes
INFO:root:Finding matches in search image
INFO:root:Removing blocks with no matches
INFO:root:Splitting single matches and multiple matches
INFO:root:[3 straight matches | 23 multiple matches]
INFO:root:Trying geometrical matches on single-match squares
INFO:root:[3 straight matches | 23 multiple matches]
INFO:root:Trying another pass on geometrical matches
INFO:root:[3 straight matches | 23 multiple matches]
INFO:root:Writing single match results to output
INFO:root:Writing average results for multiple matches to output
INFO:root:Saving output image to: output2.png

 

Network evasions

Примеры:

Скрытые коммуникации могут быть реализованы на базе практически любого протокола, который используется в сети для обмена данными между конечными хостами, особенно часто этим протоколом является один из следующих: IPv4/IPv6, TCP, UDP, ICMP, DNS.

IPv6 используется для этой задачи часто т.к. edge устройства зачастую не сконфигурированы или даже не поддерживают распознавание IPv6 трафика и он на них не запрещен. Кроме того (по мнению US-CERT) недостатком считается функционал IPv6 autoconfiguration. В итоге возможно туннелирование сетевого трафика приватной сети поверх сети Интернет используя тулзы вроде 6tunnel, socat, nt6tunnel, relay6. Нужно понимать, что даже если продукты информационной безопасности поддерживают распознавание IPv6, эти же продукты могут не справится с задачей корректного анализа IPv6, когда он инкапсулирован в IPv4.

Точно так же как IPv6, ICMP протокол может так же использоваться для туннелирования трафика.

В контексте TCP есть разные бекдоры. Например ACKCMD – обходим файрволы, которые настроены для инспекции только 3WHS – считаем, что если мы на уровне файрвола контролируем установку 3WHS (напр. на базе SYN permit/deny rule), то мы контролируем полностью TCP обмен между хостами. Backdoor требует установки софта на зараженный хост, который будет реализовывать обмен только на базе TCP ACK пакетов.

В контексте UDP он может вообще не логгироваться как соединение в файрволе или по умолчанию иметь разрешающее правило для DNS трафика. Примером backdoor на основе DNS являются: UDP tunnel (туннелируем TCP в UDP пакетах), DNSCAT (туннелируем данные в DNS протокол). Безусловно резкий скачек DNS трафика может быть подозрителен для администраторов/ИБ, но особо умные делают его отправку по расписанию.

В контексте туннелирования на уровне приложения возможны сценарии использования HTTP(S), SSH, DNS и туннелирования в них данных других протоколов. Используя netcat можно передать данные поверх HTTP, а используя cryptcat поверх HTTPS.

 

 
Social engineering (социальная инженерия)

Phishing (fake email, spear phishing, email spoofing), Baiting (usb-drive), Tailgating (access to restricted area) – чаще всего решаются через обучение персонала

Интересный кейс внедрения фишинг кода в 500 Android APP с аудиторией в 100 МЛН человек. Проверки Google Play на код видимо проходятся – судя по схеме нет опасного в самом коде. Андройд или ОПСОСы по описанию частично виноваты (не только пользовательская невнимательность/фишинг) – пользователь бы

Dark Herring distributes malicious android applications through Google Play and third-party application stores.
Once installed, the infected device communicates with the first-stage URL that is hosted on CloudFront. The response contains the links to JavaScript files for instructing the application to communicate with C&C servers, exposing the geolocation of the victim's IP. Subsequently, the malware redirects victims to their geo-specific webpage to request phone numbers for verification.
But in fact, the threat actors are submitting the victims' phone number to a Direct Carrier Billing service that begins the subscription by charging them 15 USD from their mobile bill every month. It is said that the threat actor published around 470 applications on the Google Play Store, with more than 105 million users having installed this scamware.

Direct carrier billing (DCB) is an online mobile payment method which allows users to make purchases by charging payments to their mobile phone carrier bill. The global direct carrier billing market was valued at US$ 29.8 billion in 2019.

 

Software Development (атаки на софт)
Команды, построенные по типу DеvSecOps, рассматривают безопасность как важнейший элемент создания приложения, наравне с его разработкой.
- Безопасность может смещаться и «влево», и «вправо». Возможность «смещения влево» для решения проблем безопасности на этапе разработки помогает отследить уязвимости на ранних этапах. Но важно, чтобы практика обеспечения безопасности «смещалась вправо», поддерживая работоспособность приложений в производственной среде.
- Безопасность проектируется, а не приделывается постфактум
- Безопасность — общая ответственность - В недавнем исследовании ESG 27% респондентов признались, что их команды по разработке приложений и DevOps не работают с командами кибербезопасности из-за опасений, что это замедлит их работу.
Внедрение DevSecOps требует изменения культуры. Основная идея DevSecOps в том, что каждый член команды принимает решения, держа в голове важность кибербезопасности. Недостаточно просто объединить три отдела под одним руководителем, придется изменить майндсет.
- И DevOps, и DevSecOps ставят во главу угла упрощение процессов за счет автоматизации. Такой подход позволяет командам автоматизировать обнаружение уязвимостей и методы обеспечения безопасности.
Every application and service, whether on-premises or in the cloud, needs to be designed with security in mind. For example, a denial-of-service attack might prevent customers from reaching your website or services and block you from doing business.

SDL обычно включает не только программирование:

 

 

Authentication&AUTORIZATION-based attacks

Примеры атак на аутентификацию и авторизацию:

  1. Brute forcing
  2. Session hijacking
  3. Redirecting
  4. Использование default или weak credentials
  5. Использование authn/authz/encryption/hash уязвимостей (напр. WEP, RC5, MD5, DES, Kerberos)

Brute force

В brute-force мы пытаемся угадать ключ/пароль к зашифрованным или захешированным данным, защита через длину ключа/выбора хеш функции, но технически говоря, считается что 100% защиты от brute force не существует – все упирается во времени и ресурсах, если они безграничны – любая система в теории может быть взломана. Какие рекомендации – использовать сложный пароль, использовать salt/nonce, прогонять пароль и соль через hashing алгоритм много раз (до сотен) раз. 

Strong password & 2FA/MFA

Очень часто администраторы и пользователи не меняют пароль на устройства (свичи, роутеры, AP и даже Firewalls). Для таких есть поговорка – зачем вам нужны хакеры, если вы используете дефолтные пароли.

Слабо защищенные и не ротируемые credentials являются основной причины компрометации учетных данных. Чем более устойчивый к подбору пароль вы используете – тем лучше (немного капитаним). Еще лучше использовать 2FA/MFA как дополнительный этап аутентификации – они значительно уменьшают вероятность атак на базе простого подбора.

Незащищенные пароли – пароли можно найти в code девелопе и скриптах автоматизации.

Strong password не должен полагаться только на замену букв на созвучные буквы/цифры (типо f1rst), это учтенные вещи во многих password cracking tools. Обычно политики создания/обновления паролей задаются централизованно через AD, IPA (Identity Policy Audit) и уже AD/IPA проверяют пароли на политики – длина, наличие спец. символов, повторяемость, отсутствие словарных слов и прочее. И безусловно нельзя – передавать пароль, записывать на бумажке, использовать один пароль в нескольких системах. Пароли нужно периодически ротировать.

Из спец. публикации NIST 800-63B:

 

2FA/MFA

2FA/MFA – Уровень аутентификации обычно определяется по уровню угроз. Но в общем случае чем безопасней, тем лучше – даже геймеры используют MFA уже годы. Примеры данных, на основе которых проводят аутентификацию – по username/password, PIN, карта, по ключу, по смс, по токену (physical/software), face ID/IRIS scan/fingerprint, связка методов (2FA/MFA). К 2024 70% доступа к приложениям будет использовать многофактурную аутентификацию (10% на сегодня) (Gartner Magic Quadrant for Access Management)

Почему нельзя использовать только пароль: haveibeenpwned.com

Большое количество примеров есть на сайте Cisco Duo. Так же про Cisco duo в статье про AAA.

- SMS 2FA
- TOTP 2FA
- Push-Based 2FA
- U2F Tokens
- WebAuthn

При том, что когда говорят про 2FA, обычно подразумевают два несвязанных способа (фактора) аутентификации:

There are many ways to authenticate users, such as based on what a person knows, has, or is.
Knowledge factor: "Something you know." The knowledge factor may be any authentication credentials that consist of information that the user possesses, including a personal identification number (PIN), a user name, a password or the answer to a secret question.

Possession factor: "Something you have." The possession factor may be any credential based on items that the user can own and carry with them, including hardware devices like a security token or a mobile phone used to accept a text message or to run an authentication app that can generate a one-time password or PIN.

Inherence factor: "Something you are." The inherence factor is typically based on some form of biometric identification, including finger or thumb prints, facial recognition, retina scan or any other form of biometric data.

Location factors of authentication confirm the identity of a user based on their location in the world. If a user had registered an account in one country, for example, and suddenly there are login attempts from another, location factors could trigger and attempt to verify the identity of the new user. Many location factors are based on the IP address of the original user and compares the address to that of the new attempt to access information.

Time factors of authentication verify the identity of a user by challenging the time of the access attempt. This is based on the assumption that certain behaviors (like logging into a work computer) should happen within predictable time ranges. If an attempt to access a platform happens outside of the usual time range, the attempt can be challenged or terminated until a user can verify their identity.

В контексте аутентификации важным вопросом является session management – как проверяющая сторона принимает/передает/сохраняет информацию об аутентифицируемом объекте (клиенте/сервере). Чаще всего в WEB приложениях используется Session ID, который сохраняется на сервере как соответствие конкретному клиенту и передается клиентом в каждом запросе к серверу. Сессии должны быть уникальны и сложно математически вычисляемыми.

Пароли в правильных реализациях хранятся не в виде clear text, а в виде hash. Аналогичное справедливо и для биометрических данных – они не хранятся в том виде, в котором существуют.

They’re creating fake fingerprints using things like glue, allowing friends to mark each other as present if they’re late or skip school.

If a biometric characteristic, like your fingerprints, is compromised, your option for changing your "password" is to use a different finger. This makes "password" changes limited. Other biometrics, like iris scans, can't be changed if compromised. If biometric authentication material isn't handled securely, then identifying information about the individual can leak or be stolen.
 
Два типа ошибок различают при работе с биометрическими системами:
В контексте ошибок биометрики так же существуют понятие Crossover error rate (CER) которое так же называют Equal error rate (EER) – когда уровень False rejection errors (FRR) равен уровню False Acceptance Error (FAR). CER/EER обычно является индикатором точности биометрической системы.
 

 

 

Использование encryption/authn/authz уязвимостей (напр. WEP, RC5, MD5, DES, Kerberos)

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

Recommendations for Cryptographic Algorithms

Algorithm Operation Status Alternative QCR1 Mitigation
DES Encryption Avoid AES
3DES Encryption Legacy AES Short key lifetime
RC4 Encryption Avoid AES

Тоже самое справедливо для WEP – его плохой дизайн приводит к потере пользовательских credentials.

Сохранение hash паролей без salt/nonce приводит к возможности использования rainbow tables (подробнее поиском по randbow).

Session hijcking

Существуют разные способы “воровства сессии”:

Injection attackS

SQL injection attack (SQLi) – приводят к сливам/изменению SQL базы за счет доступа к ней напр. используя спец. символы, логические операторы и уязвимости приложения по их обработке. Вообще помимо SQL injection существуют и другие виды injection атак, основанных на том же принципе отправки “некорректных” данных – HTML script injection (ниже подробнее), Command Injection (ниже подробнее), Dynamic code evaluation, Object injection, Remote file inclusion, Uncontrolled format string, Shell injection. Как избежать: изменение кода, good software principles like validating input & sanitizing user input (часто включено в WEB frameworks), изоляция переменных, переиспользование функций. Для демо атаки можно использовать DVWA, OWASP WEBGOAT (линки на них поиском по OWASP), BurpSuite (прокси перехватывающее транзакцию между браузером и сервером) + sqlmap (подменяем запросы в сохраненной BurpSuite транзакции, узнаем название базы и сливаем ее с попыткой подбора по хешам паролей на основе словаря).

“Ручная” инъекция используя OWASP WEBGOAT

Способы эксплуатации SQL injection (примеры красным выше в выводе sqlmap; способы могут быть комбинированы вместе):

Категории SQL injection атак:

HTML injection – пользователь может инъецироать HTML код в web-приложение, что в итоге может приводить к потере cookies, изменению контента на сайте, XSS и другим проблемам.

Защита от SQL инъекций бывает разной:

Pattern check
Integer, float or boolean, string parameters can be checked if their value is valid representation for the given type. Strings that must follow some strict pattern (date, UUID, alphanumeric only, etc.) can be checked if they match this pattern

Parameterized statements

With most development platforms, parameterized statements that work with parameters can be used (sometimes called placeholders or bind variables) instead of embedding user input in the statement.

Escaping
A straightforward, though error-prone way to prevent injections is to escape characters that have a special meaning in SQL.

Database permissions
Limiting the permissions on the database login used by the web application to only what is needed may help reduce the effectiveness of any SQL injection attacks that exploit any bugs in the web application.

 

Command injection – атакующий исполняет команды, которые он не авторизован исполнять из-за уязвимости в приложении. Command injection отличается code execution/code injection атак тем, что он не использует уязвимости buffer overflow, а использует уязвимости некорректной валидации данных получаемых от пользователя (вообще довольно спорное утверждение, особенно что эта причина зачастую является следствием и buffer overflow).

Buffer overflow attacks

Buffer overflow (подтипом являются атаки возврата в библиотеку, ret2libc) – переполнение буфера. Атака, как и многие другие (SQL injection, XSS) является причиной недостаточного input validation/sanitation/escape technique – блок данных при записи переполняет выделенный буфер под эти данные, что приводит или к отказу в обслуживании или к (зачастую еще хуже) использованию участков памяти, предназначенных под другие данные (heartbleed, buffer over-read), что в свою очередь может приводить к remote/arbitrary code execution (RCE), чтению/изменению персональных данных или ключей шифрования и прочим радостям жизни. Обычно сама проблема возникает в системных языках типо C, C++. Сама проблема buffer overflow часто обнаруживается при использовании fuzzing утилит.

Для избежания buffer overflow (особенно с последующим code execution) могут быть использованы техники ОС:

Пример кода C скрипта содержащего уязвимость buffer overflow и эксплуатацию этой уязвимости с последующим code execution функции “secretFunction” (которая не вызывается вообще непосредственно кодом скрипта) с использованием objdump + edb (Evan’s Debugger) + немного python.

C script

 

XSS, CSRF attacks

Существует три типа XSS атак:

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

Методы защиты от XSS (как на уровне серверной так и на уровне клиентской стороны) описаны в статье на wiki.

Хороший пример самой атаки так же описан в статье на wiki.

Для тренировки с уязвимостью XSS и другими WEB-уязвимостями, которые рассмотрены в проекте OWASP можно использовать тулзы OWASP Juice Shop, OWASP WEBGOAT, OWASP ZAP (Zed Attack Proxy) или DVWA (Damn Vulnerable Web Application)  –  можно на практике посмотреть уязвимости OWASP top 10 и другие. К примеру вместо “omar was here” можно сгенерировать “please relogin” и перенаправить пользователя на фейк страницу, на которой собирать учетки. Примеры атак XSS. Чаще всего XSS/CSRF уязвимости являются причиной недостаточного input validation/sanitation/escape technique. 

 

MISC ATTACKS

 

Cryptology (криптография)
 

Сразу несколько определений по картинке ниже:

 RANDOM.ORG offers true random numbers to anyone on the Internet. The randomness comes from atmospheric noise, which for many purposes is better than the pseudo-random number algorithms typically used in computer programs. People use RANDOM.ORG for holding drawings, lotteries and sweepstakes, to drive online games, for scientific applications and for art and music. The service has existed since 1998 and was built by Dr Mads Haahr of the School of Computer Science and Statistics at Trinity College, Dublin in Ireland. Today, RANDOM.ORG is operated by Randomness and Integrity Services Ltd.
Symmetric encryption (симметричное шифрование)
A stream cipher takes data in as a continuous stream, and outputs the ciphertext as a continuous stream, too. A block cipher encrypts the data in chunks, or blocks.

Примеры популярных симметричных алгоритмов

- DES, 3DES, RC4, and AES # are all symmetric encryption algorithms (все блочные)
- Kerberos использует симметричное шифрование

Rivest Cipher 4 (RC4)симметричных поточных алгоритм,  поддерживает ключи от 40 бит до 2048 бит. Был очень широко распространен из -за простоты реализации и скорости работы. Сейчас не рекомендуется к использованию т.к. сам алгоритм (не длина ключа) признан слабым (например. RC4 NOMORE attack). RC4 используется во многих протоколах – TLS (старом), 802.11 WEP, 802.11 WPA. Многие браузеры отказались от поддержки RC4 (preferred secure browser/web server configuration: TLS 1.2 with AES GCM). 

Data Encryption Standard (DES) (так же известен как ) – придуман в 1970 IBM + USA Nation Security Agency и принят как стандарт под названием Federal Information Processing Standard (FIPS) в USA (т.е. может использоваться для шифрования правительственных данных). Является симметричным блочным шифром (работает с блоками в 64 бита), использует 56-битный ключ (64 бита всего, из них 8 бит используются под проверку четности, parity checking – простейшую и малоэффективную проверку на ошибки). Длина ключа в 56 бит изначально закрывала все вопросы, но потом, с ростом вычислительных мощностей, то что предполагалось только в теории, произошло – в 1998 EEF дешифровала ключ DES всего за 56 часов.

Advanced Encryption Standard (AES или Rinjndael, рэндал) – замена DES. Единственный публичный алгоритм, который разрешено использовать для секретных данных USA Nation Security Agency. В текущий момент является по сути “стандартом” шифрования. Создан Винсент РэйменЙоан Даймен.

AES-128/256 (c WinRAR 5) активно используется для шифрования файлов в WinRAR, 7z. Они не хранят пароли, а хранят hash от них (на основе PBKDF2). Проверку пароля Winrar делает на основе hash HMAC-SHA256 от пароля (ключа) и, если hash от пароля совпадает с hash, хранимым в архиве – дешифруют данные на основе этого ключа.

В контексте шифрования RAR стоит отметить что – всегда лучше использовать шифрования и содержимого и методанных “encrypt file names” – это вытекает из реальных взломов старых версий и того, что там используются “спец” алгоритм by Winrar (даже в новой версии).

Assymetric encryption, public key cryptography (ассиметричное шифрование, Криптографическая система с открытым ключом)
Basic algorithm (Базовый алгоритм работы)
Public Key infrastructure (PKI), Public Key Signature (Сертификат Открытого Ключа), Certification authority (ЦЕНТР СЕРТИФИКАЦИИ), Digital signature (ЦИФРОВАЯ ПОДПИСЬ)

Все бы хорошо в базовом алгоритме, только возможно такое, что злоумышленник выдаст свой public key представляясь тобой (dns spoofing, arp spoofing, reroute,  все что угодно) и другой участник будет обмениваться данными с злоумышленником, думая, что обменивается с тобой.

Поэтому тут появляется Public Key Signature (Сертификат Открытого Ключа). Сертификат открытого ключа позволяет на получающей стороне сопоставить публичный ключ с отправителем, проверить неизменность сообщения.

Public Key Infrastructure (PKI) – это инфраструктура (Infrastructure) по работе с публичными ключами (Public Key).

PKI – критичная часть в безопасности соединений в интернете сегодня. PKI является системой, которая определяет создание, сохранение, распространение и отзыв/аннулирование (revocation) цифровых сертификатов для public/private keys. PKI позволяет реализовать authentication, confidentiality, non-repudiation, integrity.

Базовая схема PKI.

Digital Certificate (цифровой сертификат) – файл, который подтверждает что сущность (сервер или сервера) является владельцем определенного публичного ключа. Существуют разные типы сертификатов. Один сертификат может быть выдан на несколько hostname или даже wildcard, что обозначает любой хостнейм в одном домене.

Сертификат состоит из открытого ключа отправителя, методанных (информация о владельце, времени действия, области применения ) и самое главное – электронной подписи от Certification Authority (CA), который сначала сам, используя Registration Authority (RA) (обычно CA и RA один сервер), проверяет принадлежность ключа владельцу (например, то что домен weril.me находится на том же веб-сервере, с которого идет запрос на сертификат), а потом, проверив, подтверждает принадлежность публичного ключа для других с помощью своей электронной подписи в сертификате. По сути сертификат устанавливает соответствие публичного ключа и владельца.

Сертификаты хранятся в central repository – это позволяет certificate management system (системе управления сертификатами) безопасно хранить и индексировать ключи, управлять ими (отзывать, выдавать). 

Стандарт X.509 (x509 version 3)  – представляет из себя сертификат, который включает ваш идентификатор (Subject: fqdn, mail), публичный ключ (Subject Public Key Info) вместе с доп. информацией (срок действия, адрес CRL, etc), который подписан УЦ (CA). Подробнее ниже поиском по “Пример сертификата”. Такой (в виде сертификата) способ передачи публичного ключа:

описывает формат цифровых сертификатов, первично появился в 1988. Текущая версия номер 3 (RFC 2459 от 1999). Так же определяет certification revocation list (CRL)  – способ распределения списка сертификатов, которые больше не валидны. CRL представляет собой список (по сути – файл) отозванных сертификатов (serial numbers сертификатов), который распространяется CA.

Пример сертификата, на основе моего сайта.

 

CERTIFICATION AUTHORITY (ЦЕНТР СЕРТИФИКАЦИИ)

Электронная подпись открытого ключа делается Certification Authority. Certification Authority (Центр Сертификации, Удостоверяющий Центр) – заведомо доверенная организация. Мы, доверяя центру сертификации, устанавливаем сертификат открытого ключа получателя и начинаем с ним обмен. Валидация центра сертификации происходит по электронной подписи CA в сертификате открытого ключа. Аутентичность подписи сертификата проверяется с помощью открытого ключа CA, которой заранее (до обмена, чаще всего идет с дистрибутивом OS, причем они могут обновляться, а браузеры чаще всего используют сертификаты системы) есть в системе всех участников. Подробнее о калькуляции и работе с цифровой подписью ниже. Примером CA в мире WEB является просто крутейший Let’s Encrypt, который позволяет автоматизировать процесс получения сертификата SSL для сайта (здоровья тебе, let’s encrypt).

Корневой CA может (и делает, в случае WEB) делегировать полномочия по подписи нижестоящим CA (устанавливает в сертификате поле CA=true, что делает выданный сертификат intermediary/subordinate CA их может быть несколько по дереву) – он подписывает своим private ключем публичный ключ нижестоящему CA в виде сертификата, а тот может подписать своим клиентам (intermediary CA или end-entity/leaf certificate – сертификат без права CA, права выдачи сертификатов). Это “поведение” называется anchor of a trust в PKI. При этом широкоизвестный ключ нужно иметь только корневому CA, но честными должны быть все члены цепочки. Корневые сертификаты являются self-signed (самоподписанными), такой сертификат можно сделать и самому – например, сайт без доступа в интернет даже для возможности получения сертификата (по сути это подписание своего public ключа с помощью private ключа). Такой сертификат не будет считаться валидным до тех пор, пока ты не согласишься доверять этому сертификату (в случае корневых CA – по умолчанию). 

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

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

OCSP – Online Certificate Status Protocol. Протокол проверки валидности сертификатов. Отвечает, в том числе, за CRL.

DIGITAL SIGNATURE (ЦИФРОВАЯ ПОДПИСЬ) или как работает Public Key Signature

Кратко

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

  1. К данным применяется hash алгоритм
  2. Цифровая подпись расшифровывается на основе публичного ключа
  3. Значения полученные на предыдущих шагах сравниваются, в случае валидной подписи и данных – будут совпадать

Подробнее

CA, при выдаче сертификата, применяет hash функцию со своим private ключем к данными сертификата (публичный ключ + методанные), который он выдает. Результатом является цифровая/электронная подпись в виде зашифрованного hash. По сути, тут обратный процесс от описанного Базового алгоритма работы ассиметричного шифрования:

  1. формируется цифровая подпись сертификата у CA: данные, в нашем случае все данные (публичный ключ отправителя + методанные), шифруются private ключем на стороне CA, с применением HASH функции (SHA1, MD5) + алгоритма шифрования (если говорить последовательно – сначала берется hash, потом он шифруется)
  2. отправитель отправляет сертификат (публичный ключ + методанные + цифровая подпись CA)
  3. получатель, используя public ключ CA, расшифровывает цифровую подпись и получает результат HASH функции для данных в сертификате, который рассчитан CA
  4. расшифровав подпись, мы рассчитываем hash от данных (публичный ключ отправителя + методанные) в сертификате, применяя туже hash функцию, что CA
  5. сравниваем значение hash из цифровой подписи, с результатом hash функции от данных в сертификате
  6. если совпадает – все ок, если нет – подделка сертификата или данных

Все это прекрасно расписано в wiki (тут есть и вполне понятное формальное описание) и stackoverflow.

У внимательного человека появляется вопрос, почему то, что зашифровано private key, расшифруется public key. Ведь по идее то что зашифровано публичным ключем расшифруется приватным (как в базовом алгоритме работы). 

Но ответ простой – это не ошибка и не симметричное шифрование. Так оно работает – то, что зашифровано публичным ключем, может быть расшифрованное приватным И НАОБОРОТ – то, что зашифровано приватным, может быть расшифровано публичным.

 

Web of Trust

Web of Trust является альтернативой системы PKI. Сами конечные люди (end-entity/leaf certificate в терминологии PKI) выдают сертификаты другим людям. Верификация identity при этом идет с помощью согласованного механизм (например, с помощью традиционных методов – паспорт, права, etc). После проверки ты подписываешь сертификат другого человека и ручаешься за него (схеме по сути аналогична PKI). Причем процесс обычно двунаправленный – оба партнера подтверждают ключи друг друга. В результате организуется Key Signing Parties (посиделка людей с подписанными друг дружкой ключами ;)). Причем как и в PKI, мы доверяем сертификатам, которым доверяют те, которым мы уже доверились (кого мы идентифицировали).

 

 

Message Authentication Codes (MACs)

Существуют разные коды с разной реализацией

HMAC – keyed-Hash Message Authentication Code. По сути это hashing with key (data + key на входе в hash функцию).

Информация, которая позволяет аутентифицировать отправителя сообщения (authenticity) и проверить отсутствие модификации сообщения (data integrity). По сути это функциональный аналог public key signature. MAC отправляется вместе с сообщением.

В HMAC MAC генерируется на основе двух вещей:

При приеме принимающая сторона вычисляет MAC на основе данных в сообщении и ключа сам и сравнивает с MAC в сообщении и по аналогии с public key signature: “если совпадает – все ок, если нет – подделка сертификата или данных”.

CMAC – Cipher-basedMessage Authentication Code. MAC на основе блочных/поточных симметричных шифров (AES/DES). Процесс очень похож на CMAC, просто вместо hash функции для генерации проверяемой на получении последовательности MAC используется шифр.

CBC-MAC – Cipher Block Chaining Message Authentication Code. Для генерации проверяемой на получении последовательности MAC используется блочный шифр, который работает в CBC режиме. CBC режим подразумевает включение предыдущего зашифрованного блока текста в следующий блок незашифрованного текста. В результате создается цепочка (Chain) зашифрованных блоков, которые требуют полной немодифицированной цепочки для расшифрования. Эта цель взаимосвязанно зашифрованных блоков подразумевает что любая модификация текста приведет к изменению вывода в конце цепочки, нарушив в результате целостность данных. 

 

Примеры популярных ассимметричных алгоритмов

RSA – одна из первых ассиметричных криптографических систем. Название в честь создателей – Ron Rivest, Adi Shamir, Leonard Adleman. Запатентована в 1983, стало публичной в 2000. RSA система определяет как механизм генерации и обмена ключами, так и механизм шифрования и дешифрования этими ключами. RSA основан на серьезной математической базе. Генерация ключей зависит от выбора двух уникальных, обычно очень крупных числа.

DSA (Digital Signature Algorithm) – другой пример ассиметричной криптосистемы. Используется для подписания и проверки данных. Запатентован в 1991, является частью правительственного стандарта USA. Подобно RSA, DSA описывает процесс генерации ключей с подписью и проверку данных с использованием ключевых пар. Безопасность этой системы зависит от рандомного исходного значения, которое используется для подписания. Если об этом рандомном значении стало известно или его можно как-то вычислить/угадать (например, т.к. число, которое используется как значение, не является по настоящему random) –  тогда у атакующего есть возможность выяснить private key. Это и произошло в 2010 у Sony с их PS3. Выяснилось, что они не обеспечили рандом этого значения для каждой подписи. Это позволило хакерам failOverflow восстановить private key, который Sony использовала для подписи софта в своей платформе. В результате стало возможно писать/подписывать и запускать софт на Sony, который она запустит, несмотря на то, что софт не из платформы. Это привело к пиратству игр в платформе Sony. 

 

Diffie-Hellman

Diffie-Hellman (DH) – алгоритм безопасного обмена ключами. Предназначен изначально только для обмена ключами, не для шифрования данных (хотя для этого так же пытался использоваться). DH решает ту же задачу, что и ассиметричное шифрование, когда оно используется для обмена shared-key, который в последующем будет использоваться в симметричном алгоритме шифрования. Используется в PKI системе (Public Key Infrastructure System). 

Пример работы DH (По описанию похож на симметричное шифрование):

  1. Стороны обмены согласуют стартовое число (shared number). Оно должно быть рандомное, очень большое и отличаться для каждой сессии. Подразумевается небезопасным (т.е. от безопасности этого элемента не зависит система).
  2. Каждая сторона выбирает еще одно крупное рандомное число, но это число уже хранится в тайне (secret number). 
  3. Каждая сторона складывает shared number со своим secret number, в результате получая общее число (combined number)
  4. Стороны обмениваются результатом сложения между собой. 
  5. Далее стороны складывают полученные данные (combined number соседа) со своим secret number.
  6. Результатом является shared number + secret numbet соседа + secret number свой. И это значение одинаково на обеих сторонах. При этом secret number обеих сторон остаются неизвестными (ну относительно неизвестными, т.к. операция вычитания из combined number потенциально украденного shared number приведет к получению secret number одной из сторон). 
ELLIPTIC CURVE CRYPTOGRAPHY (Эллиптическая криптография)

ECDH, ECDSA– вариации Diffie-Hellmen (DH) и Digital Signature Algorithm (DSA), которые работают с элиптическими кривыми

Elliptic curve cryptography (ECC, элиптическая криптография) – криптографическая система с открытым ключем, которая использует алгебраическую структуру эллиптических кривых над конечными полями для генерации безопасных ключей.

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

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

Польза эллиптических кривых состоит в том, что они способны достигать такого же уровня безопасности, как традиционные системы с открытым ключем, при этом используя меньший размером ключ. Например, 256 битный elliptic curve key сопоставим с 3,072 битным RSA ключем (внизу таблица). Это позволяет сильно сэкономить количество данных, которое нужно для хранения и передачи, при работе с ключами. Элиптические кривые с ключем 384 bit EC можно использовать для шифрования top secret данных в USA. Но так же в USA озабочены потенциальной уязвимостью EC к атакам на базе квантовых вычислений (однако тоже самое выше и про факторизацию числа, см. поиском factorization).

Сопоставление (на одной строке сопоставимые) уровня безопасности ECC и RSA ключей на основе информации NIST.

При этом производительность (на примере решения F5 Viprion) с элиптическим шифрованием пока значительно ниже “классического”.

Hashing

Hashing или hash function – тип функции, которая принимает набор данных произвольной длины на входе и выводит фиксированный набор данных (hash/digest) на выходе. Это константа. Криптографические hash функции похожи на симметричные блочные шифры т.к. работают с блоками данных (и даже больше – многие hash функции основаны на модифицированных блочных шифрах).

Идеальная hash функция

Hash используются во многих местах, например:

A common approach used in data transmission is for the sender to create a unique fingerprint of the data by using a one-way hashing algorithm. The hash is sent to the receiver along with the data. The receiver recalculates the data's hash and compares it to the original to ensure that the data wasn't lost or modified in transit.

Так как применение абсолютно разное, существует огромное количество разных hash функций, в том числе “самописных” (привет еще раз DES-3028 и Broadcom).

rainbow tables (радужные таблицы) – используются хакерами для ускорения процесса восстановления паролей из украденных hash. Такая таблица представляет собой просто предрасчитанную таблицу из password – hash. С ней достаточно сделать lookup в таблице по hash, чтобы найти пароль, не рассчитывая пароль самому, как в случае с brute force.

Такие таблицы есть в интернете для популярных паролей и хеш-функций.

Защитой от таких таблиц является соль (salt/nonce) – дополнительные рандомные данные, которые добавляются к паролю перед применением к нему hash функции. В результате, в таблице, на основе которой происходит аутентификация, сохраняется и hash и salt. Поэтому общие таблицы из интернета тут не подойдут и нужно расчитывать пароль на основе hash самому, что сложно, особенно если соль большая по длине. Но и этим занимаются – например популярный в свое время http://gpuhash.me, который активно использовался для взлома Wi-Fi предлагал и предлагает даже бесплатные проверки на основе перехваченного вами handshake. Ранние UNIX системы использовали под разрядности соли 12 бит, что составляет 4096 возможных комбинаций соли. Получается для каждого пароля и соли в базе нужно генерировать hash для всех 4096 возможных salt. В новых системах типо Linux/BSD используется 128 бит под соль. Это бесконечность вариантов (340 + 36 нулей) и rainbow таблицы бесполезны тут. 

 

Примеры hash функций

MD-5 – крайне популярная криптографическая hash функция. Разработана еще в далеком 1992. Она работает на блоки из 512 бит и генерирует 128-битный hash digest. Серьезные проблемы в MD-5 обнаружены уже в 1996, что привело к рекомендациям использования в качестве замены SHA-1. В 2004 обнаружено, что MD-5 подвержен коллизиям HASH, что позволяет хакеру создать зараженный файл, который будет иметь такой же MD-5 digest, что и настоящий файл. В 2008 так же смогли создать и fake SSL сертификат, с таким же MD-5 hash, что настоящий. С 2010 рекомендовано не использовать MD-5 в криптографических приложениях. В 2012 эта коллизионность была использована в Flame malware, что привело к тому, что вредоносное ПО было подписано сертификатом от Microsoft и система думала, что это софт Microsoft. Сам Flame вирус долгое время считался “произведением искусства” – он распространялся по сети, записывал аудио, клавиатурную активность, делал скриншоты и делал попытки скачивания контактной информации с блютус устройств, которые располагались рядом с зараженным компьютером.

SHA-1 (Secure Hash Algorithm) – набор функций для генерации hash. Создано мин. обороной США, NSA (National Security Agency). SHA-1 заменил MD-5 hash функцию. Является более безопасным в сравнении с MD-5. Но признан устаревшим с 2010 года. Современные браузеры не используют с 2017 года и пометят сайт с sha-1 подписью в сертификате небезопасным. SHA-1 работает на блоки из 512 бит и генерирует 160-битный hash digest. Используется в TLS/SSL , PGP SSH, IPSec, GIT/SVN VCS (для определения ревизий и обеспечения целостности данных). Имеет уязвимости (обнаружены в том числе Винсентом Рейменом, создателем AES), хотя и полную коллизию можно получить только с использованием больших вычислений с CPU (первоначально 2.7кк$), но при изменении способа атаки и добавлении GPU, что выяснилось в последствии, результат можно получить уже за 100-100к$ ресурсов cloud cpu+gpu. В 2017 получена первая коллизия на базе двух разных PDF при использовании CPU+GPU, на это потребовалось огромные вычислительные ресурсы – примерный эквивалент в 6500 лет одного CPU + 110 лет одного GPU. 

SHA-2/SHA-3/SHA-256 – наследники SHA-1. Рекомендуются (особенно SHA-3/SHA-256) к использованию вместо SHA-1 с 2010 года.

 

BLAKE2хеш-функция BLAKE2, потенциально способная заменить уязвимые MD5/SHA1 без просадки по производительности (в тестировании замены /dev/random даже более чем двухкратный прирост).

Так как алгоритм BLAKE2s опережает SHA1 по производительности, то его применение также положительно отразилось на производительности генератора псевдослучайных чисел (тестирование на системе с процессором Intel i7-11850H показало увеличение скорости на 131%).

MD5SUM, SHASUM
В первой части, используя MD5SUM/SHASUM рассчитываем hash для входных данных, а так же проверяем корректность рассчитанного hash. Во второй части, сначала копируем содержимое предыдущего файла в файл с новым именем, видим, что hash для нового файла не отличается от hash предыдущего – hash берется от содержимого, а не от методанных (напр. имени). Далее, добавив пробел в исходный текст, мы проверяем, что hash меняется и проверка относительно старого hash не проходит. Видим, что hash меняется кардинально, даже из-за изменения/добавления одного символа.

Все тоже самое справедливо для SHA. По умолчанию генерируется SHA-1 hash, поведение можно изменить задав алгоритм через опцию -a (-a 256 для SHA-256).

 

MIC (Message Integrity Check) – hash/digest от сообщения. По сути checksum для сообщения, который обеспечивает только целостность данных (аналог CRC) и при этом не предоставляет никакой защиты. Не путать с MAC (как с MAC address, так и с Message Authentication Check). В отличии от MAC, MIC не использует секретные ключи (т.е. не требует аутентификации) -> MIC не может никак защитить от того, атакующий изменит сообщение, пересчитает checksum и модифицирует MIC для сообщения. 

 

 

 

Applications

HTTPS – HTTP over SSL (old, 3.0 deprecated from 2015)/TLS (secure from 1.2). TLS инкапсулирует данные HTTP для их защиты, аутентификации (обычно только сервера) и проверки целостности. Про SSL/TLS offload/acceleration cards и методах реализации перехвата/дешифрования (с MITM или без) в NGFW.

• Secure Sockets Layer (SSL) is broken, obsolete and no longer in use 

TLS – Transport Layer Security. Используется не только для защиты/аутентификации в HTTP (HTTPS), но и во многих других местах – VoIP звонки, такие как Skype или Google Hangouts, API, SSL/TLS VPN, email, instant messaging, Wi-Fi network security. Использует как asymmetric encryption (ключи), так и symmetric (данные). TLS использует salt/nonce.

Стандарт TLS 1.3 (RFC-8446) – вышел в 2018 году, TLS стал быстрее и безопаснее.

Есть мнение, что мало кто реализовал его инспекцию на уровне Firewall (по факту уже многие, даже Usergate).
Performance has a major impact on user experience. TLS 1.3 represents a pivotal turning point for HTTPS performance.

Modern mobile networks will routinely add over 100ms of latency to each request. TLS 1.3 makes page load times significantly faster for mobile devices, improving the user experience for your visitors.

Utilizing Cloudflare’s global content delivery decreases the physical distance between your content and your visitors resulting in shorter physical round trip connection times (latency). The combination of reduced round trip connections and shorter distance results in enormous performance gains when establishing a secure connection.
Data integrity is critical to your entire community. TLS 1.3 represents a significant leap forward for security. TLS 1.3 removes all primitives and features that have contribute to a weak configurations and enabled common vulnerability exploits like DROWN, Vaudenay, Lucky 13, POODLE, SLOTH, CRIME and more. TLS 1.3 has also introduced more improvements than any previous version of the protocol. Additional features have been added to enhance the security and robustness of the protocol.

При перехвате TLS 1.3 дампа можно ошибиться т.к. одной из первых строк (Version) будет версия отличная от 1.3. По факту версия указывается в определенном поле (Preferred version) в опциях ниже.

https://networkengineering.stackexchange.com/questions/55752/why-does-wireshark-show-version-tls-1-2-here-instead-of-tls-1-3
https://www.cloudshark.org/captures/64d433b1585a

Sorry, for the confusion, I was missing the exact TLS 1.3 semantics: For instance, in the Client Hello, the field "version" must contain the fixed value 0x0303 (TLS 1.2), while the prefered version is contained in the extension "supported versions".

Session reuse (resumption) – сервер запоминает сессию с клиентом и при следующем handshake по запросу клиента он происходит неполный – нет по сути криптографических вычислений вовсе т.к. в новой сессии используется старый ключ. Как итог вычислительная нагрузка ниже и на сервер и на клиент, так же меньший оверхед для трафика. Слайд из презентации Дениса Батранкова PaloAlto Networks. Fortinet в своих тестах Fortigate 7121F отключали полностью session resumption.

TLS предоставляет три вещи:

Для организации безопасного канала связи используется TLS handshake – (пример однонаправленной проверки, только сервера):

Session key получается из public-private key и в случае компрометации private key у атакующего есть возможность декодировать все предыдущие сообщения, связанные этим private key. Для защиты от этого есть концепция forward secrecy, это свойство криптографической системы, который обеспечивает защиту session key в условиях компрометации private key.

Heartbleed – бага в OpenSSL библиотеке (реализует TLS) состоящая в обработке TLS сообщений hearbeat (сообщение одной стороны, что оно хочет сохранять сессию живой). heartbleed – пример уязвимости, которая находится прямо в ядре софта. Просто отключить такой софт до патча не получится т.к. он мега критичный. Одним из вариантов, до патча, был пересбор (перекомпиляция) OpenSSL с флагом, отключающим hearbeat сообщения.

Очень хорошо с картинками описано в вики.

Атака подразумевает отправку TLS hearbeat request и
1) аллоцирование на получающей стороне памяти под каждый такой request – это так и должно быть
2) использовании баги реализации обработки hearbeat сообщений в OpenSSL – он аллоцировал память (потом это исправили патчем) на основе значения в поле lenght, не на основе фактических данных. При такой аллокации (п2) уязвимые версии OpenSSL могли выдавать любую информацию (равную длине, запрашиваемой в поддельном heartbeat сообщении, которые называют heartbleed сообщениями) за пределами отведенного буфера – включая закрытые ключи/куки/данные других соединений и проч

Пример проблем подключения к серверу – сервер не выдал сертификат описан в статье APC RPDU.

Пример установления реального TLS соединения с данным сайтом weril.me при использовании TLS 1.2.

$ openssl s_client -connect weril.me:443 -tls1_2
CONNECTED(00000005)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = weril.me
verify return:1
---
Certificate chain
0 s:/CN=weril.me
i:/C=US/O=Let's Encrypt/CN=R3
1 s:/C=US/O=Let's Encrypt/CN=R3
i:/O=Digital Signature Trust Co./CN=DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----
......cert.....
-----END CERTIFICATE-----
subject=/CN=weril.me
issuer=/C=US/O=Let's Encrypt/CN=R3
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 3094 bytes and written 285 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : ECDHE-RSA-CHACHA20-POLY1305
Session-ID: 029032CEE7FD53C3CDB33617835C93771E73025890D21C0E226FA2828A3DBEA4
Session-ID-ctx:
Master-Key: 1CD8D38AAAAC963BEF6A79EB75B242181439163DE964AE8951BB4F77B0975B26E28FDA99D3CD5ECD3112B97232D12DFD
TLS session ticket lifetime hint: 300 (seconds)
TLS session ticket:
0000 - 5b 65 8d b9 6e b3 2f fe-f8 fa 17 1e 75 82 60 9a [e..n./.....u.`.
0010 - f9 0d 90 d5 c9 57 d6 49-df e6 1c 15 04 e8 cf c8 .....W.I........
0020 - 3f b8 a4 a0 56 60 5b af-64 2a 46 cb ea 3f 64 b9 ?...V`[.d*F..?d.
0030 - 28 f0 e6 7b 8b 38 ac 55-95 1f b6 86 80 a9 bc a9 (..{.8.U........
0040 - 36 7d 5c db 93 91 bf 5b-ed c7 d1 06 0f 6b ca e9 6}\....[.....k..
0050 - 61 9d 66 c4 76 3d 56 8f-f1 fa d7 e7 58 1f 03 0b a.f.v=V.....X...
0060 - 99 eb 24 b8 7e 78 bb 63-1d 44 61 10 2a 60 5b 16 ..$.~x.c.Da.*`[.
0070 - 5c ad 5d 5c d8 60 38 59-f2 13 65 f5 24 f5 6d ca \.]\.`8Y..e.$.m.
0080 - 78 f6 8c e9 86 dd 55 34-c1 f8 a4 9e 9b 2f 2f 6b x.....U4.....//k
0090 - 43 33 61 30 17 2c 75 47-d9 49 0b d5 f6 64 76 82 C3a0.,uG.I...dv.
00a0 - 27 3c 6a e8 e5 2c ad d4-b6 00 2f e1 17 9c 1f db '<j..,..../.....
00b0 - 75 e8 7d 74 93 18 e0 76-95 0d 53 d8 d3 e4 fd 56 u.}t...v..S....V

Start Time: 1619119850
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

HTTP/1.1 400 Bad Request
Date: Thu, 22 Apr 2021 19:31:07 GMT
Server: Apache/2.4.38 (Debian)
Content-Length: 301
Connection: close
Content-Type: text/html; charset=iso-8859-1

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
<hr>
<address>Apache/2.4.38 (Debian) Server at weril.me Port 443</address>
</body></html>
closed

Попытка подключения с TLS 1.1 безуспешна.

$ openssl s_client -connect weril.me:443 -tls1_1
CONNECTED(00000005)
write:errno=54
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Start Time: 1619120086
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

Пример успешного подключения по TLS 1.1 к ya.ru.

$ openssl s_client -connect ya.ru:443 -tls1_1
CONNECTED(00000005)
depth=3 C = PL, O = Unizeto Sp. z o.o., CN = Certum CA
verify return:1
depth=2 C = PL, O = Unizeto Technologies S.A., OU = Certum Certification Authority, CN = Certum Trusted Network CA
verify return:1
depth=1 C = RU, O = Yandex LLC, OU = Yandex Certification Authority, CN = Yandex CA
verify return:1
depth=0 C = RU, L = Moscow, OU = ITO, O = Yandex LLC, CN = *.yandex.az
verify return:1 r
---
Certificate chain
0 s:/C=RU/L=Moscow/OU=ITO/O=Yandex LLC/CN=*.yandex.az
i:/C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
1 s:/C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
i:/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA
2 s:/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum Trusted Network CA
i:/C=PL/O=Unizeto Sp. z o.o./CN=Certum CA
---
Server certificate
-----BEGIN CERTIFICATE-----
......cert.....
-----END CERTIFICATE-----
subject=/C=RU/L=Moscow/OU=ITO/O=Yandex LLC/CN=*.yandex.az
issuer=/C=RU/O=Yandex LLC/OU=Yandex Certification Authority/CN=Yandex CA
---
No client certificate CA names sent
Server Temp Key: ECDH, X25519, 253 bits
---
SSL handshake has read 5352 bytes and written 239 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.1
Cipher : ECDHE-RSA-AES128-SHA
Session-ID: B554589EA58D3797C47A1E1F770312674833D7A03C558DEDC0D6EB5D24116E03
Session-ID-ctx:
Master-Key: FECED800BB7BE9A90016DB206D3DCF8FB76026C0A2B329491C8426AACC3030B044E150FF597FB553595796CDCA14FC7D
TLS session ticket lifetime hint: 100800 (seconds)
TLS session ticket:
0000 - 2c 4d ae b5 f3 0d 94 86-dc 46 85 ee 73 ea ad fc ,M.......F..s...
0010 - 63 0e 62 d4 cc 21 01 0b-13 ec ef a1 6a 84 2c 8f c.b..!......j.,.
0020 - cc 87 a8 86 9d a5 cc e0-27 12 5f a2 26 22 39 75 ........'._.&"9u
0030 - 46 59 1d 57 88 e5 ef 8b-f1 2e 25 a3 b8 86 54 e9 FY.W......%...T.
0040 - 6a ec f1 e4 aa 69 5d 16-36 68 1f a5 91 d7 e6 51 j....i].6h.....Q
0050 - 6c 9d bc 8e 24 33 70 70-e3 c0 26 54 9d 3e 63 00 l...$3pp..&T.>c.
0060 - 7d 39 b1 4d 5d 59 2e d2-81 d8 c9 69 71 55 c9 23 }9.M]Y.....iqU.#
0070 - 40 ac 14 3d 56 b0 b2 45-40 2c e1 8d 38 0d 73 70 @..=V..E@,..8.sp
0080 - d8 8a fd 2b 11 91 92 0d-0b 97 76 79 c8 e5 af 0a ...+......vy....
0090 - 15 52 94 b1 1a 56 14 59-41 23 92 b9 e6 33 ef 8c .R...V.YA#...3..

Start Time: 1619120199
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---

 

Настройка пониженного уровня безопасности операционной системны в OpenSSL (последующие запуски программ (испытано на nginx) будут с новым уровнем безопасности SSL):
1. openssl version –a
2. Найти дирректорию с конфигурацией (OPENSSLDIR): напр. "/usr/lib/ssl"
3. В папке открыть CNF-файл
4. Найти строчку с level и установить значение в 0
 
Выпуск самоподписанного SSL/TLS сертификата.
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -sha256 -days 3650 -nodes -subj '/CN=localhost'

openssl x509 -in cert.pem -text -noout


You can also add -nodes (short for no DES) if you don't want to protect your private key with a passphrase. Otherwise it will prompt you for "at least a 4 character" password.
The days parameter (365) you can replace with any number to affect the expiration date. It will then prompt you for things like "Country Name", but you can just hit Enter and accept the defaults.
Add -subj '/CN=localhost' to suppress questions about the contents of the certificate (replace localhost with your desired domain).
 

SSH

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

Изначально задуман как замена небезопасным telnet/rlogin/r-exec, поэтому чаще всего используется для безопасного доступа к командной строке (remote login to command-line based systems). Но может использоваться и для других вещей, включая, например, туннелирование/проксирование трафика через SSH

В общем случае SSH использует public key cryptography для аутентификации удаленной машины, к которой подключается клиент.

Кроме того, SSH опционально поддерживает и клиентскую аутентификацию через client certificates (двухстронняя проверка). В таком случае Пользователь генерирует ключевую пару public key/private key, public ключ затем передается на те системы, на которые пользователь хочет подключиться. В последующем сервер при авторизации проверяет private ключ пользователя (который находится только у пользователя) по его открытому ключу (который хранится на сервере).

 

PGP/GPG

Pretty Good Privacy (PGP) – приложение по ассиметричному шифрованию, которое позволяет аутентифицировать данные, обеспечивать приватность от третих лиц.

Разработан PGP Phil Zimmerman в 1991, и распространялось (soft + source code) бесплатно, несмотря на требования об экспорте усиленного шифрования (key larger then 40 bits, в то время как в PGP минимальным размером ключа было 128 бит) от регулятора в USA. Зиммерман обошел это требование опубликовав source code в виде книги (воспользовался первой поправкой к конституции).

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

PGP первоначально использовал RSA алгоритм, но потом, во избежание проблем с лицензированием, стал использовать DSA. 

 

 

VPN

VPN (Virtual Private Network) – механизм, который позволяет хосту (remote access VPN) или сети (site-to-site VPN) удаленно подключится к частной сети, для передачи данных по публичному каналу, такому как Internet. Своего рода зашифрованный туннель.

Существует огромное количество VPN решений, каждое со своими плюсами и минусами. Под VPN обычно используется отдельная сеть/vlan и возможно отдельные правила мониторинга/ограничения безопасности этой сети – это менее безопасная среда (дополнительная потенциальный вектор атаки), чем обычная корпоративная LAN. Изначально VPN решения развивались для замены leased lines – отдельный физических каналов между объектами, но сейчас он используется не только для задачи site-to-site.

Существует огромное количество протоколов, реализующих VPN, самые популярные:

Существует огромное количество реализаций VPN, например:

L2TP (Layer 2 Tunneling Protocol) – по сути не VPN решение и не обеспечивает шифрование, но позволяет передать модифицированные пакеты из одной сети в другую инкапсулируя эти пакеты. Чаще всего реализовывается в связке L2TP over IPsec (RFC 3193). Так же может использоваться без VPN – например ISP могут предоставлять доступ в сеть на основе L2TP ;).

У крупных провайдеров, использующих L2TP как основной способ организации связи клиент-BRAS, чаще всего IPSec отключен. т.е. туннель создается, но он не шифруется и промежуточные устройства (DPI/СОРМ/хакеры) могут перехватить и прочитать трафик, если он не зашифрован еще каким-то образом (напр. перехваченный трафик содержит взаимодействие с google по HTTPS).

Работа L2TP over IPsec:

 

SSL/TLS

SSL/TLS так же могут использоваться для создания VPN tunnel. Например, Cisco clientless VPN на базе Cisco ASA.

 

OpenVPN

Так же как пример OpenVPN, который использует OpenSSL (практику работы с ней – по генерации private ключа на базе RSA и созданию public ключа на базе private, шифрования/дешифрования данных, генерации hash и его проверке смотри ниже) библиотеку для обмена ключами, шифрования данных. OpenVPN поддерживает шифрование до 256-бит с помощью OpenSSL. Использование OpenSSL так же позволяет OpenVPN выбирать любые шифры, которые реализованы в OpenSSL.

OpenVPN поддерживает разные типы аутентификации (Pre-shared secret PSK, certificate based, username-password). Username-password способ не встроен непосредственно в OpenVPN, а реализуется с помощью модуля. Certificate based считается наиболее безопасной опцией, но требует большей поддержки т.к. у каждого клиента должен быть свой сертификат. Если хочется мега безопасности то можно к certificate-based добавить еще проверку по username-password. 

 

 

Cryptographic Hardware

TPM (Trusted Platform Module), TAM (Trust Anchor Module), АПМДЗ (Аппаратно-программный модуль доверенной загрузки) – аппаратное устройство, обычно интегрированное аппаратно в компьютер(ную систему). Есть стандарт, описывающий TPM. TPM по сути выступает как выделенный крипто-процессор для системы. TPM имеет свой RSA (или другой) ключ, который зашит в hardware во время производства (это основной недостаток TPM, производитель может знать ключ и прошить его на другое устройство). TPM бывают различных версий, Microsoft со своим решением BitLocker для FDE рекомендует использовать TPM 1.2 и выше для шифрования диска. 

Может быть реализован:

TPM предоставляют:

 

FDE

FDE (Full Disk Encryption) – шифрование всего содержимого диска (не отдельных файлов) для защиты от воровства/изменения данных. Решения бывают разные, так же возможны разные способы миграции между этими решениями, в большинстве решений есть возможноcть восстановления доступа к данным при забытых паролях (key escrow, ниже о нем). Получить доступ к данным обычно можно с помощью пароля или ключа. Но сами данные, в “back end”, всегда шифруются/дешифруется ключами (при пароле – получение доступа к ключу). Чаще всего операция делается незаметно для пользователя – пароль для дешифрования (для ключа дешифрования) = пароль входа в систему.

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

Возможные реализации FDE:

FDE конфигурация включает один физический/логический раздел, который включает данные для мест, которые требуют шифрования (обычно root volume, где установлена OS). Данные шифруются не полностью – boot partition (kernel, bootloader, netRD) (чтобы BIOS смог запустить его) и окно авторизации (чтобы дешифровать данные) остаются незашифрованными. Чаще всего при использовании FDE невозможно по сети (если только это не IP-KVM) перезагрузить машину и ввести пароль после перезагрузки – сетевые службы чаще всего не стартуют до дешифрования FDE. 

В теории, через подмену незашифрованных данных (kernel, bootloader, netRD), можно атаковать зашифрованные данные, но подобная атака сложна и кроме того есть защита от атаких атак в UEFI в виде реализации протокола SBP (Secure Boot Protocol). SBP использует public key cryptography для шифрования/дешифрования этих элементов boot процесса. Изначально SBP настроен для использования platform key (зашит в прошивку UEFI) – публичный ключ, соответствующий приватному, который используется для шифрования файлов. В момент загрузки с помощью этого ключа происходит дешифрование (проверка подписи) файлов и только корректно подписанные файлы будут запущены в итоге. 

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

 

 

Использование OpenSSL

OpenSSL поддерживает ГОСТ шифрование, в том числе 2012 года.

OpenSSL библиотеку использовали в lab’е ниже для

  1. генерации private key на базе RSA и создания public key на основе private key (key pair)
  2. шифрования/деширования данных
  3. генерации hash от данных и проверки на основе hash

OpenSSL is a commercial-grade utility toolkit for Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. It’s also a general-purpose cryptography library. OpenSSL is licensed under an Apache-style license, which means that you’re free to get it and use it for commercial and non-commercial purposes (subject to some simple license conditions).

Generate RSA private and public key pairs using the OpenSSL utility.

Before you can encrypt or decrypt anything, you need a private and a public key, so let’s generate those first!

Remember, a key pair consists of a public key that you can make publicly available, and a private key that you need to keep secret. Shhhh. 🙂 When someone wants to send you data and make sure that no one else can view it, they can encrypt it with your public key. Data that’s encrypted with your public key can only be decrypted with your private key, to ensure that only you can view the original data. This is why it’s important to keep private keys a secret! If someone else had a copy of your private key, they’d be able to decrypt data that’s meant for you. Not good!

First, let’s generate a 2048-bit RSA private key, and take a look at it. To generate the key, enter command “openssl genrsa -out private_key.pem 2048” into the terminal. This command creates a 2048-bit RSA key, called “private_key.pem”. The name of the key is specified after the “-out” flag, and typically ends in “.pem”. The number of bits is specified with the last argument.

Now, let’s generate the public key from the private key, and inspect that one, too. Now that you have a private key, you need to generate a public key that goes along with it. You can give that to anyone who wants to send you encrypted data. When data is hashed using your public key, nobody will be able to decrypt it unless they have your private key. To create a public key based on a private key, enter the command below.

Use the key pair to encrypt and decrypt some small amount of data.

You’ll simulate someone encrypting a file using your public key and sending it to you, which allows you (and only you!) to decrypt it using your private key. Similarly, you can encrypt files using other people’s public keys, knowing that only they will be able to decrypt them.
echo ‘This is a secret message, for authorized parties only’ > secret.txt

This creates the file “secret.enc”, which is an encrypted version of “secret.txt”. Notice that if you try to view the contents of the encrypted file, the output is garbled. This is totally normal for encrypted messages because they’re not meant to have their contents displayed visually. To encrypt the file using your public key, enter this command:

The encrypted file will now be ready to send to whoever holds the matching private key. Since that’s you, you can decrypt it and get the original contents back. Remember that we must use the private key to decrypt the message, since it was encrypted using the public key. Go ahead and decrypt the file, using this command:

Use the key pair to sign and verify data to ensure its accuracy.

Now, you’ll create a hash digest of the message, then create a digital signature of this digest. Once that’s done, you’ll verify the signature of the digest. This allows you to ensure that your message wasn’t modified or forged. If the message was modified, the hash would be different from the signed one, and the verification would fail.

This creates a file called “secret.txt.sha256” using your private key, which contains the hash digest of your secret text file. To create a hash digest of the message, enter this command:

With this file, anyone can use your public key and the hash digest to verify that the file hasn’t been modified since you created and hashed it. To perform this verification, enter this command:

 

 

AAA

AAA (Authentication Authorization Accounting)

Authentication (authn) – проверяем что аутентифицируемый объект (клиент/сервер) является тем, кем он говорит, что он является.

Идентификация и аутентификация это разные вещи, несмотря на то, что они осуществляются (чаще всего) вместе.

Аутентификация включает идентификацию и проверку личности. Идентификация включена в процесс аутентификации, она позволяет описать объект уникально (например, адрес почты уникально идентифицирует объект).

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

Аутентификация должна быть реализована правильно, некорректная реализация может привести к компрометации учетных записей, токенов/ключей сессий и прочим проблемам. Такой кейс частый, поэтому Broken Authentication problem является вторым в топ 10 OWASP для WEB applications.

Broken Authentication. Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.

Примеры систем, которые аутентифицируют клиента (и не только – чаще всего используются для полного перечня AAA):

Могут контролировать доступ к любым ресурсам – сети (802.1x, VPN, Wi-Fi), серверам, ресурсам.

Многие из них используют EAP (Extensible Authentication Protocol), для согласования наиболее безопасных протоколов аутентификации для работы между клиентом и сервером. Данные пользователей зачастую хранятся в базе (иногда база и RADIUS – отдельные сущности), но некоторые системы могут работать и с обычными файлами (.htdigusers). RADIUS и TACACS, помимо задач аутентификации (пользователь тот, за кого себя выдает), решают и задачи авторизации (дать доступ туда/к тем командам, но не дать туда/к этим командам).

Clients don't actually interact directly with the RADIUS server; the authentication is relayed via the Network Access Server.

 

 
Электронные КАРТЫ (SMART CARDS)
«Классические» Memory card/bank ATM card содержат пользовательскую информацию на магнитной ленте, принцип работы:
  1. карта вставляется в читатель кард,
  2. далее читатель извлекает данные с карты,
  3. запрашивает от пользователя пароль/pin,
  4. пользователь вводит пароль/pin,
  5. читатель путем применения операции хеша к паролю сравнивает пароль пользователя и хешированный пароль/pin, сохраненный на карте
На карте может храниться
 
В smartcard и современных atm card принцип работы похож, но более безопасен в сранении с картами, работающими на магнтиной ленте:
 

 

Токены (Tokens)

Токены обычно ротируют коды (пароли) каждые n секунд (60 секунд для RSA SecureID), коды являются одноразовыми (OTP – One Time Password/Pad). СМС считаются менее надежными в сравнении с токенами – они не шифруются по умолчанию, их зачастую можно перехватить при хорошей тех. подготовке (или даже просто звонке оператору), сильная зависимость от организации безопасности у оператора связи.

One-Time Pad (OTP) - a key used only one time.

Примеры токенов на основе того с какими токенами работает Cisco Duo.

HOTP <serial number>,<HOTP secret key>[,<HOTP counter>]
TOTP <serial number>,<TOTP secret key>[,<TOTP time step>]
YubiKey <serial number>,<private identity>,<secret key> # Компании Facebook и Google используют YubiKey для аутентификации сотрудников и пользователей.

Токены:

Браузер (Google Chrome) имеет встроенную поддержку протокола U2F
- Браузер "знает", что полученный запрос на U2F-аутентификацию надо направить на
U2F-токен
- Браузер "умеет" это делать безо всяких дополнительных плагинов и пр.

Google все сервисы (Drive, Cloud, Gmail, YouTube, Wallet, Google+)
GitHub
WordPress
Dropbox
Linux PAM
OpenSSH

Представляют собой маленькие устройства или встроенные в устройства криптопроцессоры (по сути TPM, в котором хранятся ассиметричные ключи и дополнительное пространство для запуска встроенного кода). Включает challenge-response, механизм вместе с криптографией на базе публичного ключа, для реализации более безопасного и, как ни странно, удобного решения second-factor authentication. Поддержка U2F встроена в Chrome/Opera браузеры. Защищает от клонирования или подделки т.к. внутри них есть уникальный секретный ключ, который защищен. Не защищает напрямую от Man-in-the-middle атак, но подразумевается, что использование U2F (аутентификация посредством U2F), должно проходить поверх TLS, который эту защиту обеспечит. Как работает secure key:

 

 

SSO (Single Sign-On) – один раз авторизовался, а далее успешная авторизация позволяет заходить в сервисы, проходя окно авторизации (OpenID, Citrix SSO, SAML, LTPA IBM). Очень удобно – позволяет не хранить кучу разных паролей, не терять время пользователя на постоянные реавторизации и обслуживание систем с паролями. Недостаток в безопасности – один взлом (напр. традиционный или новый – воровство session cookie/token/ticket) потенциально дает доступ ко всему . Поэтому SSO обычно используется только в схеме 2FA/MFA.

SSO может быть реализован по разному, например:

Работа без SSO. На схеме юзер последовательно аутентифицируется к application 1, затем в application 2.
 
Работа с SSO. Схема подключения к двум application при использовании SSO. Несмотря на то, что картинка выглядит значительно сложнее первой, пользовательский опыт по факту в схеме с SSO лучше, чем без SSO т.к. пользователю только один раз (напр. в первом приложении одного SSO домена) нужно пройти аутентификацию, а далее он передает сохраненные куки/токен второму (в том же SSO домене). 
 
Понятия в SSO:
WS-Federation defines mechanisms for allowing different security realms to broker information on identities, identity attributes and authentication.

 

 

 

Методы аутентификации в WEB (кратко, подробно поиском по каждому в этой статье):

  1. SSL/TLS authentication на базе digital certificate PKI (подробнее PKI)
  2. HTTP Basic Auth – крайне простая аутентификация: никаких handshake, никаких cookie, никакого шифрования (нужно использовать SSL/TLS). В каждом запросе в HTTP header к серверу клиент в открытом виде передает закешированные учетные данные. Недостатки крайне серьезные: нет стандартного логаута, не кастомизируется форма по вводу логин-пароль (или других credentials), существующие реализации имеют уязвимости, несмотря на простоту самой концепции.
  3. HTTP Form-based Auth – самый популярный способ аутентификации. В сравнении с Basic Auth
  4. DAA (Digest Access Authentication) – по сути аналог Basic Auth, но вместо передачи в открытом виде каждый раз учетных данных передается MD5 hash от этих данных и так же nonce для защиты от атак на повторение (repay). Нужно учитывать, что MD5 небезопасен (уязвим для атак на коллизии хеша), поэтому хоть это и лучше чем в clear-text, но полагаться на эту защиту вообще не стоит.
  5. LTPA (Lightweight Third-Party Authentication) – IBM proprietory метод для SSO.
  6. OAuth, OAuth2
  7. OpenID, OpenID Connect (OID)
  8. SAML (security assertion markup language) – открытый стандарт аутентификации и авторизации на основе XML, так же как OpenID есть возможность передавать Attribute пользователя (напр. email/phone). Используется для обмена аутентификационными/авторизационными данными между identity providers. Раньше требовал использования SOAP over HTTP, но в версии SAML2 это больше не требуется. SAML широко используется для реализации SSO.

 

 

OpenID (OID) – open decentralized authentication system. Используется обычно в связке с OAuth. Открытый стандарт, который позволяет участвующим сайтам, известным как Relying Parties, аутентифицировать пользователей используя третью сторону (какой-то сервер аутентификации, Identity Provider – Google, Microsoft, Yahoo, FaceBook, etc). Похожая на SSO вещь, но аутентификация зачастую не сквозная. В результате сайты аутентифицирует пользователей, не требуя от пользователя данных и не требуя реализации аутентифиции на самом сайте. Так же пользователи могут посещать сайт, не создавая аккаунт. Хотя это зачастую и сложно реализовать/поддерживать, это очень удобно для клиента, который не хочет плодить сущности без нужды. Для работы сайту нужно создать shared secret с провайдером и все (используется для обмена сообщениями). После редиректа клиента, в результате успешной авторизации у третьего лица и подтверждения что клиента хочет авторизоваться на сайте, сайт получает факт успешной аутентификации и какие-то данные (Attribute Exchange Extension – напр. email/phone) + токен (не пароль).

 

OAuth2 – открытый протокол/стандарт авторизации, используемый многими API и современными приложениями. Является крайне популярным методом авторизации, похожий на OpenID. Самый главный плюс OAuth – пользовательские учетные данные никогда не передаются непосредственно приложению. Приложению передается только временный token (должен быть временным, по факту конечно можно реализовать и “криво”) который сопоставляется с пользователем и может быть отозван провайдером OAuth/пользователем. OAuth2 требует использования TLS для шифрования данных.

Схема работы OAuth очень похожа на OpenID, только вместо аутентификации, сайт получает какой-либо доступ от имени пользователя (например, отправлять сообщения/почту). Обычно OpenID используется совместно с OAuth – OpenID Connect это уровень аутентификации, встроенный в OAuth 2.0. По сути как RADIUS и TACACS, объединение задач аутентификации и авторизации. Для relaying parties/third party services позволяет аутентифицировать пользователей и при этом не хранить у себя пользовательские учетные данные, что зачастую является очень весомым аргументом (правовые аспекты). 

В отличии от чистого OpenID провайдер OAuth авторизации знает все о том, кто решил проверить клиента, так же OAuth привязан к конкретному провайдеру, в отличии от OpenID. И это огромный плюс для таких крупных игроков как google/facebook/vk. Полезно для небольших сайтов, например блогов – можно только таким пользователям давать возможность комментирования. В OAuth встроена поддержка Redirect URI – после авторизации OAuth (напр. в Google) происходит перенаправление “обратно” на исходный сайт это как удобно, так и позволяет избежать определенных векторов атак.

Пример совместной работы OAuth и OpenID. Так же OAuth работает и с SAML.

 

Authorization (authz) – выдача полномочий на основе аутентификации (куда имеет доступ аутентифицированный entity).  Авторизация (так же как и аутентификация) должна быть реализована правильно, некорректная реализация может привести к компрометации учетных записей, токенов/ключей сессий и прочим проблемам. Такой кейс частый, поэтому Broken Access Control является пятым в топ 10 OWASP для WEB applications. Подходом к контролю доступа (access control) называют политикой безопасности (security posture). Есть два основных подхода к контролю доступа:

[bpm] The DUT must be configured in ""fail close"" mode. We will describe this under section 4. Any failure scenarios like ""fail open"" mode is out of scope.

Also "Fail-Open" behavior MUST be disabled on the DUT/SUT.
https://blogs.keysight.com/blogs/tech/nwvs.entry.html/2020/05/20/fail_closed_failop-ZYAt.html
FAIL CLOSED
This strategy is common in situations where security concerns override the need for access.
To prioritize security: In an IP network, security appliances like firewalls can be configured to fail closed, to prevent incoming Internet traffic from being passed into your internal network when the firewall is unable to confirm that the packet is allowed.
It’s important to note that the fail closed strategy, even for a device like a firewall, has not always been the rule. In some environments, network interruption can be a greater concern than security, leading to the choice to fail open. This was more frequently the case in the early days of firewall deployment, when organizations were learning how to balance the need for security inspection with network availability.

Так же в контексте контроля доступа существуют принципы безопасности:

Контроль авторизации бывает на основе разных схем:

Authorization model – определяет то, как предоставляются авторизационные права.
Object capability used programmatically and is based on a combination of unforgible reference and an operational message
Security labels are mandatory access controls embedded in object and subject properties
Acls are used to determine access based on some combination of specific criteria such as a user id, group membership, classification, location, address, day.

Примеры двух уязвимостей в WEB приложениях, относящихся к авторизации:

ACL (Access Control Lists) – бывают не только на сетевом оборудовании, но например в файловой системе (разграничение по правам в Windows тоже делаются через Access Control Lists). Папка или отдельный файл может иметь список лиц/групп-лиц, которые могут иметь те или иные (R/W/E) права к папке/файлу. Индивидуальные разрешения для объекта называются Access Control Entries, они составляют ACL. 

 

Accounting

Accounting – сохранение данных о том, куда ходил/что делал пользователь в системе. Критичным компонентом accounting является Аудит, потому что сам запись в accounting не означает, что кто-то его смотрит (как с мониторингом). “Классический” TACACS используется как syslog – по сути кто, что ввел в консоли устройства. “Классический” RADIUS accounting часто используется для биллинга ISP – он записывает большое количество данных, которые могут использоваться для анализа достижения квоты (ограничить доступ в это время, ограничить полосу когда выкачал столько то):

 

 

Network security

Network hardening – процесс улучшения безопасности сети путем уменьшения потенциальных рисков через конфигурационные изменения и соблюдение политик. Implicit deny, monitoring & analyzing traffic. 

Мониторинг трафика (в том числе возможно и с клиентских устройств и приложений, не только логов с файрвола и аутентификаций; полезно и при разборе уже состоявшихся взломов в рамках post-fail analysis/post-mortem, чтобы предотвратить повтор/понять масштаб взлома) и анализ логов (причем чаще всего автоматический анализ, не ручной) крайне важен т.к. сначала нужно понять корректные паттерны поведения пользователей в сети, чтобы потом понять нетипичные, которые возможно говорят о взломе/заражении.

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

В контексте того, что нужно логгировать и сколько хранить, нужно найти середину:

SIEMS – Security Information and Event Management System – по сути централизованный сервер логов для СБ, с возможностью анализа логов. Примеры: rsyslog, Splunk (очень поплурный open-source), IBM Security Qradar, RSA Security analytics.

Системы по автоматическому анализу логов (logs analysis system, например Splunk):

 

 

 

 

MACSEC
Macsec, 802.1ae (в cisco – cisco trustec, cts) – Media Access Control Security, реализует шифрование на канально уровне.
 
Поддерживает работу (шифрование) в двух режимах:
 
SAP (security association protocol) используется для обмена ключами при шифровании switch-switch.
 
Аутентификация возможна по manual admin shared key (SAP PMK), но так же возможна и с использованием 802.1x
 
Режимы работы macsec:

 

 

 

Network separation – разделение сети на разные элементы, полезно в сетевой безопасности (разные vlan, подсети, vrf, контексты) – можно изолировать проблемы, проще мониторить трафик между элементами и проч.

Firewall, NGFW, NGIPS – подробнее в отдельной статье

Proxy и Reverse Proxy – подробнее в статье про proxy. 

HoneyPot – приманки для атакующих. Их огромное количество. Бывают универсальные, а бывают под конкретное направление – могут например даже эмулировать industrial сеть с SCADA контроллерами и управляющими сообщениями, передаваемыми посредством Modbus.

Или могут предоставлять функционал, которые расписывает подробно все действия вирусов в системе используя sandboxing – какой код запускался, какой файл/регистр изменился, состояние памяти, чем обменивался с сетью и проч. И самое главное безопасно для того, кто этим занимается. Примеры sandbox решений – Cisco Threat Grid, Cuckoo Sandbox. Пример в статье NGFW для Cisco (Dynamic Analysis), пример в отдельной статье для PaloAlto.

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

Вообще не любой malware код запустится в sandbox среде – вирусописатели люди тоже не глупые и зачастую реализовывают методы проверки. malware код не стартует:

 

Wi-Fi Security

Сюда все из IT раздела.

WEP (Wired Equivalent Privacy) – уже через после нескольких лет использования перевод звучит как стеб. Разбирать как он работает нет смысла – его нельзя использовать (если только в качестве honey pot)

WPA (Wi-Fi Protected Access) – изначально придумывался как временное решение, которое позволит заменить WEP на том же оборудовании, на котором работает WEP, через простую перепрошивку. Тут появился TKIP – temporary key integrity protocol, в нем реализованы новые (по сравнению с WEP) фичи:

При этом TKIP так же продолжает использовать RC4 алгоритм, но на каждый пакет генерируется свой уникальный ключ, в отличии от WEP.

WPA ввел возможность использовать разные методы авторизаций:

 

 

WPA2 – добавил еще безопасности, во первых он отказался от RC4 в пользу AES (TKIP WPA2 – неполноценный WPA, по сути). CCMP (AES GCM – Counter Mode CBC-MAC Protocol) – он позволил реализовать аутентифицированное шифрование (данные конфиденциальны и аутентифицированы), через механизм authenticate & encrypt.

  1. Довольно безопасный стандарт, но все таки его можно взломать в версии PSK через offline bruteforce attack процесса four way handshake. Если атакующий перехватывает все пакеты four way handshake (Nonce и MAC получаются из этих пакетов), то можно brute-force пытаться угадать PMK (см. утилиты типо aircrack). Для защиты нужен хороший пароль + необычный SSID. Для взлома GPU-cloud (прогонять 4094 раз через hash SHA-1 функцию) или ranbow table. Иначе, если SSID какой-то стандартный и предполагается что и пароль стандартный – для 1k top most SSID и 1kk top most password есть таблицы.

Сначала рассчитывается CBC-MAC digest, затем результирующий authentication code шифруется вместе с сообщением, используя блочный шифр (напр. AES в режиме counter, что превращает его в stream cipher, используется seed value с инкрементирующимся counter для создания key stream, который шифруются данные).

Как клиент проходит аутентификацию (four-way handshake).

  1. AP отправляет nonce клиенту
  2. клиент отправляет nonce AP
  3. AP отправляет GTK
  4. клиент отправляет ACK

В результате успешной аутентификации (AP понимает, что у клиента есть Preshared Master Key PMK, без непосредственного обмена им) генерируется временный ключ шифрования (Pairwise Transient Key PTK), который будет использоваться для шифрования данных от клиента и к нему. PTK генерируется из многих вещей – PMK, AP nonce, Client nonce (рандомные данные), AP MAC addr, Client MAC addr (конкатинируются и прогоняются через hash). PTK состоит из 5-ти ключей – два ключа для encryption и подтверждения EAPoL, два ключа для отправки/приема integrity check, ключ для шифрования данных (temporal key). Так же AP передает GTK – Groupwise Transient Key (шифруется EAPoL encryption key из PTK), который используется для broadcast/multicast пакетов (поэтому GTK разделяется между всеми клиентами одной сети), он периодично обновляется и переотправляется клиентам (или по событию отключения клиента).

 

 

WPS в любой его форме рекомендуют отключать. Скан утилита для проверки что WPS везде выкл – wash.

WPS бывает не только по кнопке:

Зашитый PIN в прошивку чаще всего ругают в контексте ругани WPS – его легко ломают brute force, причем метод вообще говно т.к. двумя частями отправляется pin (сначала первая часть и если она ок!!!!!!, то вторая). В результате за 11к попыток можно перебрать все варианты (без rate limit можно было взломать меньше чем за 4 часа, пока в спецификации не сделали тресхолд 3 неправильные попытки в минуту, но даже это воркэраунд = 3 дня).

 

 

Packet sniffing (tcpdump, wireshark, aircrack-ng, kismet)

Port mirroring, RSPAN

Отдельные статьи:

Обычно это происходит автоматически при запуске инструментов для снифинга, но перехват трафика требует помещение интерфейса в promiscuous (неразборчивый) режим, чтобы сетевая карта не дропала пакеты, которые не предназначены ей. В Wi-Fi карточку так же можно переместить в Monitor mode – она будет слушать даже пакеты в других (не только в подключенном) SSID и на других частотах.

 

 

Обновление ПО/системы/драйверов устройств (security updates)

В контексте атак типо OpenSSL heartbleed и множества других подобных проблем с безопасностью софта (например баги с Java, Adobe Flash Player, ОС или даже драйверами устройств) крайне важны инструменты, которые будут уведомлять о новых патчах/новых версиях софта. Зачастую это встроено в антивирусы, но есть и специализируемые инструменты типо Microsoft SCCM, Puppet Labs, которые позволяют изучить какой софт глобально установлен на всех ПК и обновить его при необходимости.

Общая практика – поддерживать работу только последней версии софта и запрещать явно ненужное/разрешать явно нужное. Под последней версией часто подразумевается именно стабильная последняя версия т.к. самая последняя версия может быть с багами.

Разрешенное унифицировано обновлять (унифицировано – чтобы иметь единообразный софт везде, упростив эксплуатацию и уменьшив attack surface). Ограничить использования софта определенной версией/запретить использование определенного софта (blacklist)/разрешить использования определенного софта (whitelist) можно через политики AD. Причем под софтом подразумеваются даже расширения в браузере – которые часто недооценивают в контексте безопасности. Они могут собирать/подменять информацию на сайтах, на которые пользователь ходит, отправлять на удаленные сервера user input и прочее.

Но как ни странно распространена и обратная ситуация – система (ОС, приложение) может не обновляться из-за рисков ИБ. К примеру,
 
В таком случае накладные расходы по закрытию уязвимостей ложаться на саму компанию (сигнатуры, доступы и проч).

 

 

Безопасность в Chrome OS
Under the hood ядро Linux (как и во многих других новых ОС).

Отличительная особенность Crome OS – простота и безопасность:

OS Recovery Mode – У Chrome OS простой процесс восстановления, в случае повреждения/изменения системных файлов система входит в режим восстановления и помогает пользователю восстановить ее.

Powerwash – позволяет легко сбросить ОС к заводским настройкам (как телефон), персональные данные восстанавливаются из облака. Причем powerwash стирает ключи пользователей отчищаемой системы из памяти, делая невозможным восстановление данных с ЖД (т.к. они шифруются данными пароля пользователя + ключами с TPM – см. ниже). 

Verified Boot

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

Состоит из четырех компонентов:

read-only firmware – прошивка с которой поставляется Chrome OS устройство. Изменить прошивку без физических изменений машины невозможно – прошивка защищена от удаленных атак. В прошивку включаются криптографические ключи, которые проверяет что последующий компонент (read-write fw) при загрузке из доверенного источника и что в последующем компоненте нет лишнего кода. Если проверка завершена успешна – исполняется код из read-write fw, если не успешна – read-only fw попытается восстановить систему из последнего backup read-write fw (предварительно проверив, что он валиден). Если и в backup какая то дрянь – система будет загружена в режиме восстановления (recovery mode).

 

read-write firmware – прошивка, которая может автоматически обновляться по необходимости. Проверяет непосредственно ОС (ядро ОС из доверенного источника) примерно таким же алгоритмом, что и read-only fw (алгоритм точно такой же – если найдено несоответствие – загружаем другой OS kernel или уходим в восстановление ОС).

OS kernel – при загрузке kernel проверит целостность root file system, которую использует. Алгоритм точно такой же – если найдено несоответствие – загружаем другую Root File System или уходим в восстановление ОС.

Root file system – хранит непосредственно данные ОС и пользователя.

Причем Kernel и Root File System хранятся на разных разделах. И их два – read only (который используется при обычной работе), read-write (меняется софтом при обновлениях).

 

Vulnerability scanners (сканеры на уязвимости)

Пример утилит – Nessus (Tenable), OpenVAS, Qualys.

Примерный алгоритм работы:

  1. Сканят сеть на хосты с помощью разных способов – ping sweep, port scanning
  2. Детальный скан запускается на каждый обнаруженный хост
  3. Делается попытка определения сервисов за портами
  4. Делается попытка взлома сервисов на основе баз известных уязвимостей  и мисконфигураций (напр. неоптимальные ciphers, пароли по умолчанию. Nessus проверяет как понимаю не реальными атаками, а их моделированием на основе Nessus attack scripting language. Базу с уязвимостями нужно регулярно обновлять (ничего нового), иначе не будет скана на новые уязвимости. 
  5. Отправляется репорт для последующего анализа/обработки, который включает уязвимые хосты/сервисы, уязвимости приоритезируются и категоризируются, можно почитать подробно о каждой найденной уязвимости (софтовой баги или даже неправильно настроенного сервиса или даже наличия бекдора в системе), иногда так же есть информация как можно избавится от нее/включается информация о том, есть ли возможность удаленного эксплойта найденной уязвимости и прочая важная информация для анализа.

Пример репорта из Nesus:

 

Тесты на проникновение (penetration testing)

Тесты на проникновение (penetration testing) – практика попытки взлома системы/сети для проверки корректности работы систем безопасности. Хакеры в белых шляпах. Использование эксплойтов и систем типо hacking linux (kali linux). 

Осуществление регулярных pentest и формирование/разбор отчетов по ним не менее важный аспект в безопасности, чем регулярные vulnerability scanning. Позволяет проверить что системы обнаружения/блокирования/логгирования вторжений работают корректно. Сами тесты (как pentest, так и vulnerability scan) могут производится как внутренними сотрудниками ИБ (in-house), так и внешней аудит организацией (third-party testing). Рекомендуют использование одновременно обоих подходов.

 

Стандарты в области безопасности

PCI DSS (Payment Card Industry Data Security Standard) – пример всеобъемлющего стандарта безопасности, которому нужно следовать, в случае если компания обрабатывает платежи по кредитным картам.

У стандарта 6 основных задач: 

 

Privacy Policy

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

Sensitive data exposure является третим в топ 10 OWASP для WEB applications – очень часто персональные данные хранят/обрабатывают не так, как нужно.

 

 

 

Cloud security

Облака:

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

Большое количество вопросов при сохранении данных в публичных облаках к тому – что вы начинаете доверять облачному провайдеру, что он обеспечивает необходимую защиту ваших данных (shared responsibility client & cloud provider). shared responsibilities (пример описания AWS) зависит от типа используемой cloud модели (IaaS, PaaS, SaaS) – в SaaS вы не отвечаете мало за что, в IaaS за многое. Shared responsibilities подразумевает и разделение вопросов по закрытию уязвимостей ПО и patch management в облаке для моделей IaasS, PaaS. В SaaS за patch management в облаке и уязвимости ПО полностью отвечает провайдер, в отличии от других моделей, где за что-то отвечает клиент.

К примеру, при использовании облаков требуется обеспечение облачными сервисами физической безопасности носителей данных клиентов (СКУД, камеры, физические замки, юридическая ответственность и прочие вопросы). Кроме того, все чаще требуется соблюдение требований регуляторов, под которые подпадают данные клиентов (подобные законы существуют в Europe, USA, Russia, etc).

Примеры атак, которые справедливы для облачной среды:

В контракте письменно провайдер должен подтвердить требования по ИБ, которые вы выдвигаете этому провайдеру. Примеры правильных вопросов облачному провайдеру до подписания с ним договора:

Top secret — Cryptologic and communications intelligence
Secret — Select military plans
Confidential — Data indicating the strength of ground forces
Sensitive unclassified — Data tagged “For Official Use Only”
Unclassified — Data that may be publicly released with authorization

Insufficient due diligence is one of the biggest issues when moving to the cloud. Security professionals must verify that issues such as encryption, compliance, incident response, and so forth are all worked out before a contract is signed.

Cisco Cloudlock

Cisco Cloudlock контролирует доступ к облачным приложениям и является DLP решением для облака. Cloudlock – изначально купленная Cisco компания. Это CASB (Cloud Access Security Broker) решение, которое обеспечивает видимость и проверку на соответствие (compliance checks) для защиты от некорректного использования (misuse), вывода данных (data exfiltration, DLP) и защиты от угроз (напр. ransomeware). Cisco Cloud Lock интегрируется с облачными провайдерами типа DropBox, GSuite, Office 365 (O365) и многими другими.

What is the function of Cisco Cloudlock for data security - DLP.

https://www.cisco.com/c/en/us/products/security/cloudlock/index.html#~features The Cloudlock Apps Firewall discovers and controls cloud apps connected to your corporate environment.

 

Cisco Tetration

Пример продукта Cisco, который реализует облачную безопасность: Cisco Tetration. Функционал крайне широк.

Когда виртуальных машин или контейнеров становится несколько тысяч (например, в Cisco несколько тысяч виртуальных машин и контейнеров используются для обеспечения нашей внутренней работы), то задача статического определения, куда можно, а куда нельзя перемещаться контейнерам и виртуальным машинам, становится неподъемной. Ровно эту задачу – автоматизацию управления виртуальными машинами, контейнерами, приложениями внутри ЦОДа и внутри облака – и решает Cisco Tetration. С помощью специальных алгоритмов он описывает структуру сети, структуру ЦОДа и облака, позволяет прописать и динамически отслеживать правила взаимодействия виртуальных машин, приложений, контейнеров между собой, блокировать их перемещения в неразрешенные места, увязывает это все с политиками доступа внутри корпоративной сети, например, с теми же самыми Cisco ISE и Cisco Stealthwatch, с защитой периметра и дает возможность оценивать уязвимость приложений и виртуальных машин, которые используются в ЦОДе. И опять же динамически, опираясь на информацию об уязвимостях, усиливать или понижать уровень защиты тех или иных корпоративных ресурсов. То есть Tetration – это инструмент, который позволяет сегментировать приложения, виртуальные машины и контейнеры внутри ЦОДа и облаков и делать это динамически.

 

 

INDUSTRIAL SECURITY

Вообще Industrial безопасность (Industrial Control Systems, ICS) стала важным вектором в ИБ и частично это из-за того, что Industrial сети начали реализовывать на базе IP (ICS moving to Ethernet/IP increases threat exposure).

Немного инфы из интервью David Bombal:
 

 

 

IoT security

В целом о IoT читаем тут.

Проблемы безопасности IoT устройств:

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

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

Для защиты периметра сегментов, где установлены интернет-вещи, мы используем традиционные Cisco Firepower. Для агрессивных сред, в которых устанавливается промышленное или медицинское оборудование, используются наши специализированные промышленные файерволы или промышленные системы обнаружения атак под названием ISA 3000.

 

 

 

Точки входа хакера в компанию/enterprise, пример
Точками входа хакера в компанию являются ((список, разумеется, не полный)):
– инсайдер,
– украденные пароли к пользовательским учетным записям,
– запущенные из вложений e-mail программы удаленного управления,
– загруженные из Интернет файлы c трояном внутри,
– временные открытые сервисы для соединения администраторов (RDP или SSH или HTTPS панель управления), 
– скачанные обновления после взлома поставщика обновления продуктов,
– уязвимые VPN без патчей,
– уязвимости сетевых устройств и серверов без патчей,
– запросы к полям ваших баз данных через SQL иньекцию,
– вредоносный код запущенный с флешки подключенной в USB-порты,
– взломанные компьютеры сотрудников, подключенные по VPN и используемые хакером как шлюз в компанию,
– подставной трафик с вредоносным кодом в соединение сотрудника с безопасным сервисом, но незащищенным от атаки человек посередине,
– незащищенные точки доступа  WiFi,
– исключения в правилах средств защиты для работы с контрагентами поставщиками,
– исключения политик для VIP-пользователей,
– неверная настройка средств защиты
– эзернет порты в той же приемной за телеком/принтером без всякого  802.1х

 

Пример политики безопасности для небольшой компании

Authentication system

 

External website security

 

Internal website security

 

Remote access solution

 

Firewall and basic rules recommendations

 

Wireless security

РеализоватьWPA2 enterprise (AES GCM encryption + 802.1x RADIUS authentication)

 

VLAN configuration recommendations

Создать VLAN и подсети в соответствии с группами пользователей

 

Laptop security configuration

 

Application policy recommendations

 

Security and privacy policy recommendations

 

Intrusion detection or prevention for systems containing customer data

Внедрить системы NIDS/NIPS, HIDS/HIPS для анализа трафика сотрудников внутри сети компании. Настройка систем в случае обнаружения угроз (атаки, вирусная активность, неавторизованный скан сети) – уведомление администраторов, ограничение доступа, карантин определенных систем.

 

Leave a Reply