В связи с чем возникают уязвимости

Причины возникновения уязвимости информации. Классификация и характеристика уязвимостей. Модель уязвимостей

Уязвимость (информационной системы)- Свойство информационной системы, обусловливающее возможность реализации угроз безопасности обрабатываемой в ней информации.

Причины возникновения уязвимостей.

· уязвимости сетевых протоколов;

· уязвимости уровня операционной системы;

· уязвимости конкретных СУБД ;

· уязвимости программного обеспечения.

· уязвимость со стороны персонала

5. Недостаточное обучение

6. неосведомленность персонала

7. немотивированность персонала

8. отсутствие мониторинга

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

5. отсутствие дверей/окон и пр.

6. Подверженность оборудования затоплению/температурам/пыли/перепадам напряжения

Управление коммуникациями и операциями:

6. Сложный интерфейс, приводящий к ошибкам при использовании

7. Плохой контроль изменений

8. Плохое управление сетью

9. отсутствие резервного копирования

10. Отсутствие обновлений ПО

Рис. Модель уязвимостей

Ответ: См. ГОСТ Р ИСО/МЭК 27001-2006.

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

Задачами организации является:

3. обеспечение функционирования,

6. поддержка и непрерывное улучшение СМИБ

Менеджмент рисков информационной безопасности.

Можно выделить три группы возможных целей создания СМИБ по уровню возрастания сложности решаемых задач:

1. Провести высокоуровневую оценку рисков информационной безопасности и предложить адекватные рискам меры и средства управления системы менеджмента информационной безопасности (СМИБ).

2. Повысить эффективность СМИБ организации за счет обоснования адекватных рискам мер контроля и управления.

3. Повысить эффективность бизнеса за счёт совершенствования системы управления СМИБ и снижения ущерба от реализации возможных угроз информационной безопасности.

b) Обоснование системы информационной безопасности на основе экономических оценок рисков.

Задание 4 (10 баллов)

Дата добавления: 2019-09-13 ; просмотров: 1109 ; Мы поможем в написании вашей работы!

Источник

Безопасность веб-приложений: от уязвимостей до мониторинга

Уязвимости веб-приложений возникают тогда, когда разработчики добавляют небезопасный код в веб-приложение. Это может происходить как на этапе разработки, так и на этапе доработки или исправления найденных ранее уязвимостей. Недостатки часто классифицируются по степени критичности и их распространенности. Объективной и наиболее популярной классификацией уязвимостей считается OWASP Top 10. Рейтинг составляется специалистами OWASP Project и актуализируется каждые 3-4 года. Текущий релиз выпущен в 2017 году, а следующий ожидается в 2020-2021.

Распространенные уязвимости

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

Инъекции

Как и полагается, атаки класса «Инъекции» занимают лидирующую строчку рейтинга OWASP Top 10, встречаясь практически повсеместно и являясь крайне разнообразными в реализации. Уязвимости подобного класса начинаются SQL-инъекциями, в различных его вариациях, и заканчивая RCE — удаленным выполнением кода.

Межсайтовый скриптинг — уязвимость, встречающаяся на данный момент куда реже, чем раньше, если верить рейтингу OWASP Top 10, но несмотря на это не стала менее опасной для веб-приложений и пользователей. Особенно для пользователей, ведь атака XSS нацелена именно на них. В общем случае злоумышленник внедряет скрипт в веб-приложение, который срабатывает для каждого пользователя, посетившего вредоносную страницу.

LFI/RFI

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

Атаки через JSON и XML

Веб-приложения и API, обрабатывающие запросы в формате JSON или XML, также подвержены атакам, поскольку такие форматы имеют свои недостатки.

JSON (JavaScript Object Notation) — это облегченный формат обмена данными, используемый для связи между приложениями. Он похож на XML, но проще и лучше подходит для обработки с помощью JavaScript. Многие веб-приложения используют этот формат для обмена данными между собой и сериализации/десериализации данных. Некоторые веб-приложения также используют JSON для хранения важной информации, например, данных пользователя. Обычно используется в RESTful API и приложениях AJAX.

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

JSON Injection

Простая инъекция JSON на стороне сервера может быть выполнена в PHP следующим образом:

Простая инъекция JSON на стороне клиента может быть выполнена следующим образом:

JSON Hijacking

Захват JSON — атака, в некотором смысле похожая на подделку межсайтовых запросов (CSRF), при которой злоумышленник старается перехватить данные JSON, отправленные веб-приложению с веб-сервера:

XML External Entity

Атака внешней сущности XML (XXE) — это тип атаки, в котором используется широко доступная, но редко используемая функция синтаксических анализаторов XML. Используя XXE, злоумышленник может вызвать отказ в обслуживании (DoS), а также получить доступ к локальному и удаленному контенту и службам. XXE может использоваться для выполнения подделки запросов на стороне сервера (SSRF), заставляя веб-приложение выполнять запросы к другим приложениям. В некоторых случаях c помощью XXE может даже выполнить сканирование портов и удаленное выполнение кода.

XML (Extensible Markup Language) — очень популярный формат данных. Он используется во всем: от веб-сервисов (XML-RPC, SOAP, REST) до документов (XML, HTML, DOCX) и файлов изображений (данные SVG, EXIF). Для интерпретации данных XML приложению требуется анализатор XML, известный как XML-процессор. XML можно использовать не только для объявления элементов, атрибутов и текста. XML-документы могут быть определенного типа. Тип указывается в самом документе, объявляя определение типа. Анализатор XML проверяет, соответствует ли XML-документ указанному типу, прежде чем обрабатывать документ. Вы можете использовать два варианта определений типов: определение схемы XML (XSD) или определение типа документа (DTD). Уязвимости XXE встречаются в последнем варианте. Хотя DTD можно считать устаревшими, но он все еще широко используются.

Фактически, объекты XML могут поступать практически откуда угодно, включая внешние источники (отсюда и название XML External Entity). При этом, XXE может стать разновидностью атаки подделки запросов на стороне сервера (SSRF). Злоумышленник может создать запрос, используя URI (известный в XML как системный идентификатор). Если синтаксический анализатор XML настроен для обработки внешних сущностей, а по умолчанию многие популярные анализаторы XML на это настроены, веб-сервер вернет содержимое файла в системе, потенциально содержащего конфиденциальные данные.

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

Источник

Программные уязвимости

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

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

Предпринималось много попыток четко определить термин «уязвимость» и разделить два его значения. MITRE, исследовательская группа, финансируемая федеральным правительством США, занимающаяся анализом и разрешением критических проблем с безопасностью, разработала следующие определения:

Согласно терминологии MITRE CVE:

[…] Уязвимость — это состояние вычислительной системы (или нескольких систем), которое позволяет:

Предпринималось много попыток четко определить термин «уязвимость» и разделить два его значения.

В MITRE считают, что атака, производимая вследствие слабой или неверно настроенной политики безопасности, лучше описывается термином «открытость» (exposure).

Открытость — это состояние вычислительной системы (или нескольких систем), которое не является уязвимостью, но:

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

Поиск

Продукты для дома

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

Бесплатные утилиты

Наши бесплатные утилиты помогают обеспечить защиту ваших устройств на базе Windows, Mac и Android.

О компании

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

Пробные версии

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

Связаться с нами

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

Источник

Основы информационной безопасности. Часть 1: Виды угроз

Безопасность виртуального сервера может быть рассмотрена только непосредственно как «информационная безопасность». Многие слышали это словосочетание, но не все понимают, что же это такое?

«Информационная безопасность» — это процесс обеспечения доступности, целостности и конфиденциальности информации.

Под «доступностью» понимается соответственно обеспечение доступа к информации. «Целостность» — это обеспечение достоверности и полноты информации. «Конфиденциальность» подразумевает под собой обеспечение доступа к информации только авторизованным пользователям.

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

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

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

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

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

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

Угрозы информационной безопасности, которые наносят наибольший ущерб

Рассмотрим ниже классификацию видов угроз по различным критериям:

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

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

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

Вам как администратору виртуального сервера, данные виды угроз нужно принимать во внимание только в случаях при которых даже кратковременная потеря доступа или частичная или полная остановка в работоспособности сервера по вине хостинг компании могут привести к не соизмеримым проблемам или убыткам. Это случается достаточно редко, но по объективным причинам ни одна хостинг компания не может обеспечить Uptime 100%.

Угрозы непосредственно информационной безопасности

К основным угрозам доступности можно отнести

Основные угрозы целостности

Можно разделить на угрозы статической целостности и угрозы динамической целостности.

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

С целью нарушения статической целостности злоумышленник может:

Основные угрозы конфиденциальности

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

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

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

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

Рис. 1. Классификация видов угроз информационной безопасности

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

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

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

Источник

Разбираем Log4j уязвимость в деталях… с примерами и кодом

Что-то пошло не так

Думаю все слышали про критическую уязвимость в Log4j, которая существует уже не один десяток лет, но была обнаружена совсем недавно. В итоге ей присвоили самый высокий критический статус CVE-2021-44228 и многие компании, включая Microsoft, Amazon и IBM признали, что некоторые их сервисы подвержены этой уязвимости. Ее суть в том, что Log4j позволяет выполнить любой вредоносный код на сервере при помощи Java Naming and Directory Interface (JNDI). Хотя последние 2 года Java я использую крайне редко, мне все равно стало интересно разобраться с проблемой более детально.

История о том как я искал ключи

А уже после, мы видим только маску в формате хххх (что в принципе тоже очевидно)

К слову, в первые годы жизни CircleCI это еще работало, но в конце 2019 хак сломали починили.

Запускаем локально, тестируем

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

Получаем HTTP и HTTPS ссылки, которые “видно из интернета”

Осталось собрать все до кучи и отправить curl запрос из CircleCI. Для этого обновляем /.circleci/config.yml

Коммитим, пушим, смотрим в CircleCI и видим что curl запрос был отправлен успешно

А в консоле Node.js HTTP сервера находим значение переменной окружения AWS_SECRET_ACCESS_KEY которая пришла в теле curl запроса

Разберем ключевые моменты

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

Второе, жертва (в нашем случае CircleCI) выполняет код, выдает cекрет и даже не подозревает об этом.

Третье, извлечение секрета наружу происходит с помощью ngrok и очень простого Node.js HTTP сервера.

Пишем и взламываем RESTful Web Service

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

Не теряя времени, пишем простой LDAP сервер на Node.js единственная задача которого, печатать информацию о запросе в консоль

Как и в предыдущем примере, запускам ngrok и просим его делать forward TCP запросов (LDAP протокол использует именно TCP) на локальный 1389 порт (тот на котором “бегает” Node.js LDAP сервер)

Получаем TCP ссылку, которую “видно из интернета”

Обновляем Java-приложение таким образом что бы Log4j писал в лог запрос к нашему LDAP серверу с использоваением JNDI

Смотрим в консоль Node.js LDAP сервера и видим значение переменной окружения AWS_SECRET_ACCESS_KEY которая пришла в теле запроса

Так же “говорим” Spring, что хотим писать в лог всю информацию о входящих запросах, включая headers

Запускаем сервис и убеждаемся что он работает

И в консоле Node.js LDAP сервера видим значение переменной окружения AWS_SECRET_ACCESS_KEY

Ключевые моменты остались теми же, немножко изменилась реализация

Второе, жертва (в этом случае Log4j) выполняет код, выдает cекрет и даже не подозревает об этом.

Третье, извлечение секрета наружу происходит с помощью ngrok и очень простого Node.js LDAP сервера.

Даже если облако (AWS, GCP, Azure, etc) фильтрует заголовки запросов перед тем как отправить их на срвер, все не отфильтруешь и проблема может вылезть даже в таких неожиданных местах как имя пользователя или сообщение в чате. Как например с изменением имени устройства в iCloud You can set the name of your iPhone and exploit Apple iCloud currently

Ковыряем внутри JNDI

Забегая наперед, скажу пару слов о сериализации и десериализации. Сериализация и десериализация в Java это способ сохранить обьект в текстовом виде (сериализация) и восстановить этот же обьект в Java позже (десериализация). Это как конвертировать Java-обьект в JSON, а потом JSON конвертировать в Java-обьект на другом сервере, почитать детальнее можно здесь Java Object Serialization.

Дальше совсем не долго посмотреть в исходный код JNDI и разобраться, какие еще атрибуты нужно вернуть (см. Obj.java#L63-L81 и Obj.java#L227-L260)

Конвертируем ее в Base64

Собираем jar файл с классом Exploit и закидываем в любое место доступное по HTTP (для простоты я залил на GitHub). Обновляем LDAP сервер таким образом, что бы он возвращал нужные нам атрибуты

И отправляем curl запрос на сервер как и в предыдущем случае

В данном случае, как только сервер получит ответ из LDAP

ClassLoader загрузит Exploit.jar и узнает о классе Exploit

Десериализуется обьект класса Exploit

Содержимое printenv “сольется” curl запросом

Источник