¿Cómo la inteligencia artificial, en particular la nueva inteligencia artificial generativa, afecta la ciberseguridad? Este trabajo examina desarrollos en inteligencia artificial, sus posibles implicaciones en ciberseguridad, y las esperadas tendencias en la industria.

Capacidades IA

Antes de discutir ciberseguridad, debemos entender primero la IA y qué puede hacer.

IA intenta imitar a la gente. Y significa mímica sin pensar. Solo actuar en formas que parecen similares. La IA no tiene una agenda, no entiende consecuencias, no aplica la lógica, sentimientos, o incluso sentido común. La IA no entiende qué dice o hace o por qué. Solo busca lo que la gente ha hecho y trata de imitarlo así los resultados lucen similar.

Para conseguir esto, necesitamos entrenar una inteligencia artificial. Entrenar a una IA significa darle muchos ejemplos y dejándole encontrar los patrones. No sabemos usualmente o entendemos que ve la IA en la información con la que la alimentamos, o si al seguir esos patrones conseguiremos los resultados esperados.

Pero desde que no entiende o piensa, podemos asumir errores cuando aplicamos escenarios intrincados. Errores que incluso niños no cometerían porque aún un chico entiende qué está haciendo.

Desafíos en ciberseguridad

Más allá de sus capacidades limitadas, la IA representa una significativa y en aumento amenaza a la ciberseguridad.

Una razón por esta amenaza es que la IA es mucho mejor hoy imitando humanos. Sistemas de seguridad y protocolos que intentan establecer que están hablando con una persona probablemente fallarán eventualmente. El ejemplo más simple es CAPTCHA, pero hay otros casos, incluyendo protocolos de mesa de ayuda, cuyo propósito es establecer que no se están comunicando con una máquina.

Un tema más alarmante es que las imitaciones de la IA aparecen como falto de patrones o, más precisamente, tiene patrones muy complejos de reconocer. Esto significa que la seguridad de los sistemas basados en la firma no será capaz de identificar las firmas de los ataques. Estos incluyen anti-virus, anti-malware, WAF, filtros de email, y más.

Por ejemplo, los virus polimorfos no son nuevos, pero la IA puede reescribir el código de ataque en formas elaboradas, haciéndola imposible de detectar. El mismo aplica a WAF y muchos otros sistemas de seguridad basados en firmas.

Finalmente, la IA moderna a menudo aparece como humana, y no podemos decir cuál es la diferencia. Entonces los ataques de ingeniería social pueden ser automatizados y escalados en volumen y complejidad. Las personas encontrarán más difícil de identificar phishing emails en tanto lucirán como los realistas.

Desde que cada phishing email será completamente diferente, ellos también engañarán spam filters. Así que usen filtros Bayesian u otros algoritmos, será duro reconocer múltiples emails son esencialmente una reescritura del mismo mensaje. Por lo tanto, protección de email será menos efectiva.

Debido a que las capacidades generativas de las IAs modernas las vuelven indistinguibles de los humanos, la mayoría de las defensas de seguridad basadas en IA probablemente se volverán ineficaces contra una IA atacante.

Mientras todo esto suena muy severo, en última instancia es solo otro clavo en la muerte del perímetro. El perímetro sufrió múltiples golpes a través de los años recientes, incluyendo trabajo remoto y BYOD. Junto con la actual alta tasa de éxito de los ataques de phishing, estamos perdiendo la batalla. Es probable que esta batalla empeore cuando los atacantes empiecen a aprovechar la IA.

Asegurar que nadie penetre el perímetro es imposible, y nuestra habilidad para controlarlo probablemente continuará siendo menor.

Diferenciación de actor

Mientras la IA presenta desafíos, muchos actores probablemente no tendrán acceso a ella. Puede cambiar en el futuro, pero el acceso directo a la tecnología y recursos requeridos de informática es poco probable se convierta en un lugar común.

Actor estatales probablemente ya tienen acceso a IA o pronto la tendrán. Ataques de grupos grandes tal vez también obtengan acceso a los recursos necesarios. Pero los script kiddies son el grupo más grande de atacantes y es poco probable que tengan acceso a tales capacidades.

En otras palabras, la diferencia entre los actores grandes y pequeños se volverá más extrema. Grandes actores son probablemente ya capaces de penetrar tu perímetro y encontrarán eso más fácil de hacer en el futuro, mientras pequeños actores continuarán utilizando sus actuales métodos y herramientas.

De cualquier forma, mejorar nuestras defensas contra las amenazas de la IA no solo mitigará los riesgos de la IA pero además significativamente reducirá el riesgo de pequeños actores.

Medidas efectivas

Es importante considerar qué tipo de medidas son efectivas contra la IA. Lo más alto que percibes la amenaza de actores con accesos a la IA, más debes invertir en tecnologías resilientes.

La seguridad más efectiva es la basada en la verdad. Esta reside en saber la respuesta correcta. La respuesta más simple es un usuario & contraseña. Ahí hay solo una respuesta correcta, y más allá de como los humanos- como una IA es, no será capaz de adivinarlo. Lo mismo aplica a autenticación de dos factores, preguntas de seguridad, cartas clave, biométricos, y más. Pero no es necesario invertir en complejidad o seguridad cara para combatir la IA desde que toda la seguridad basada en la verdad es IA resiliente.

Una medida en la que vale invertir es la gente. Más precisamente, pensando en la gente. Las IAs atacantes pueden imitar gente pero no puede pensar, y las IAs defensivas tienen la misma limitación. Trayendo a la gente de vuelta en el juego de la seguridad traerá de vuelta la fortaleza de pensamientos humanos y sentido común.

Pero hay buenas razones para nuestra mayor dependencia de la automatización en lugar de las personas. Estos incluyen el costo de personal, encontrar la persona apropiada, y, más importante, el desafío de humanos controlando volúmenes masivos de actividad.

Traer gente de vuelta a la seguridad requiere armarlos con sistemas detectives que pueden manejar los volúmenes de actividad y dar visibilidad a ella. Como los sistemas de prevención y detección automática continúan tu declive en efectividad, seguridad basada en el humano se volverá más crítica.

Finalmente, deberíamos volvernos menos predecibles y no confiar tanto en paradigmas estándardes de seguridad y buenas prácticas. Pero personalizando nuestra seguridad y haciendo cosas diferentes, sistemas automatizados no sabrán qué esperar y falta de patrones para seguir o imitar.

Incluso hoy, escaneos de vulnerabilidad es una herramienta efectiva usada por atacantes. Es efectiva porque el software escaneado sabe que esperar y puede testear un número grande de vectores de ataques contra un número grande de sistemas. Lo más único de nuestra seguridad, lo menos probable es que sea por un escaneo de vulnerabilidad o una IA entrenada para asistir a un atacante.

Educación & Entrenamiento

¿Por qué están el desafío del perímetro e IA haciendo las cosas peor? La principal razón nuestros usuarios. Y también es una actitud general que Internet puede ser seguro y usarlo requerirá pequeños entrenamientos y conocimiento.

Nuestros usuarios constantemente interactúan con internet pero carecen de habilidades para protegerse y a la organización. También usan softwares que pretenden ser fáciles pero promueven comportamiento de seguridad pobre.

Por ejemplo, métodos de automatización de emails como SPF, DKIM, y DMARC pueden validar la fuente de email y están aumentando su popularidad. Como sea, la gente no mira la dirección de email o el dominio – miran lo más rápido de leer que es el nombre del display. Y las personas solo tienen parte de la culpa porque la mayoría del software de emails solo muestra este nombre para mostrar en la lista de corre electrónico y, usualmente, luego de abrir el email también.

Para empoderar a la gente a ser consiente de quién les manda el email, debemos hacer más que meramente hacer cumplir DMARC políticas. Debemos exponer a la gente a una dirección de email y nombre de dominios de quien envía y entrenarlos para mirar y entender esto.

Otro ejemplo es la facilidad con la cual la gente puede abrir un adjunto o hacer click en un link en un email. Dichas acciones deberían requerir al menos dos pasos. Por ejemplo, usuarios deberían salvar archivos adjuntos antes de ser capaces de abrirlos. Un link debería ser copiado y pegado en un navegador. Mientras tales pasos extra hacen el uso menos amigable, eso evita el accidental común click y fuerza a los usuarios a ser más consiente de acciones potencialmente peligrosas.

Similarmente, encriptado y certificados pueden validar la máquina remota y asegurar el secreto de la comunicación. Como sea, para esto ser efectivo, la gente necesita mirar el dominio en la URL.

Internet no es un lugar seguro. Esa es la realidad. Son individuos, grupos, y organizaciones que quieren hacernos daño. Con la IA a su lado, nuestra capacidad para fingir que estas entidades nefastas no existe disminuirá.

Centrado en datos

Como el perímetro se vuelve menos efectivo, debemos continuar cambiando nuestro foco a seguridad centrada en datos. Esto es una tendencia en crecimiento, y las amenazas de IA pueden probablemente potenciarlo.

Seguridad centrada en datos va alrededor de proteger los sistemas responsables por procesamiento de datos y almacenamiento. La motivación es que una filtración de perímetro será una filtración de datos fallidos si el atacante no puede comprometer los sistemas internos que manejan los datos.

Proteger las aplicaciones y bases de datos es efectivo contra amenazas internas y no solo las externas. El tipo de seguridad también crea una capa donde los ataques pueden ser detectados por múltiples medidas de seguridad, por lo tanto reduciendo las oportunidades de una filtración exitosa.

Seguridad centrada en datos busca proteger contra la gente, entonces una IA imitando exitosamente el comportamiento humano no es un riesgo en crecimiento. Centrado en datos es además más resiliente a la IA porque estos sistemas internos son usualmente separados de Internet por la menos una capa de protección de red. Esta separación de red hacer que sea más difícil para una IA basada en la nube atacar sistemas internos.

Seguridad detective

La creciente importancia de la seguridad centrada en datos, involucramiento humano, y menos predecible defensas llevan atención para un tipo particular de soluciones de seguridad detectives.

Estas son soluciones que pueden:

• Manejar el volumen extremadamente alto de actividad de bases de datos y aplicaciones.
• Ofrece personalizaciones usando ambientes específicos atributos en alertando, reporteando, análisis, y más.
• Dar al personal de seguridad completa visibilidad sobre todo lo que está sucediendo usando herramientas forenses interactivas y de avanzada.

Core Audit de Blue Core Research hace más fácil conseguir estos objetivos. Desde análisis de anomalías a 360° forenses, y mucho más, Core Audit es un solución integral que puede ayudar a que encuentres y superar tu actual y futura seguridad y desafíos de cumplimiento normativo.

Ideas finales

Es difícil predecir cuando la amenaza de IA de ciberseguridad se materializará o por cuánto tiempo tomará antes que sepamos de una filtración asistida por IA. Hoy, esta amenaza es probablemente limitada por el estado o muy grandes actores de quien las filtraciones de datos son a veces no descubiertas y cuyos métodos pueden mantener desconocidos.

IA es poco probable que cambie los riesgos de pequeños actores, pero IA- defensas resilientes probablemente también será efectivo contra ellos.

El desafío principal continúa siendo mejorar el comportamiento humano. Es probable que la Ingeniería social aumente como riesgo principal, ya que las personas siguen siendo el talón de Aquiles de la seguridad.

IA no parece forzar un cambio en las tendencias de seguridad, solo acelerarlas y demandar atención a cambios ya necesarios. Estos incluyen el valor menguante de las defensas perimetrales de alta gama ya que luchan por la justificación y el cambio de enfoque hacia la seguridad centrada en los datos.

Antecedentes

El sitio web de Blue Core Research usa WordPress (sistema libre y de código abierto de gestión de contenidos). WordPress usualmente usa MySQL como base de datos de backend, y nuestra instalación no es diferente.

Mientras nuestro WordPress no contiene información sensible, aún lo protegemos con Core Audit. Parcialmente, lo hacemos porque producimos Core Audit, y las licencias no nos cuestan nada. Pero para contextos más grandes, protegemos esta base de datos porque nuestro sitio web es la cara de la compañía, y aún sin información sensible, una filtración dañaría nuestra reputación.

Como verás en este trabajo, protegiendo la base de datos proteges la aplicación (WordPress) también. Y eso defiende nuestro servidor de ataques en Internet.

La Anomalía

Nuestra instalación de Core Audit cuenta con una configuración relativamente simple con alertas diarias de detección de anomalías. Recibimos algunos falsos positivos cada tanto, pero una mañana de domingo del 19 de marzo de 2023, recibimos un alerta de un nuevo error.

Access denied for user ''@'' (using password: YES)

Eso inmendiatamente me levantó una bandera roja. Esto es porque las anomalías solo alertan sobre algo diferente, como un cambio en la actividad del perfil de la aplicación. Pero un cambio que causa un acceso denegado parece sospechoso.

La Investigación

Las anomalías de Core Audit descansan en el repositorio de seguridad de Core Audit. Y esta anomalía particular está basada en la reducción de la porción de SQL de ese repositorio. El repositorio reducido SQL contiene cada construcción SQL que la base de datos ejecuta con la resolución de 5 minutos.

Una vez que recibí el alerta, me logué en Core Audit y revisé la vista relevante forense. Rápidamente encontré sobre qué fui alertado:

Date:     Sat 2023/03/18
Time:     18:55 - 19:00
Count:    1 per 5 minutes
Rows:     0
Command:  ERROR TEXT
Activity: Access denied for user ''@'' (using password: YES)

Esto es un error interno MySQL resultante de un log in fallido. El usuario y anfitrión en este error están entre comillas simples (‘) y son, por lo tanto, despojados desde el repositorio reducido de SQL. La división de literales es parte de cómo opera el repositorio reducido de SQL.

Mi próxima parada fue para buscar la sesión fallida que la causó. Al alternar a la sesión de vista forence, encontré esta sesión:

Start:    2023/03/18 18:55:59
End:      2023/03/18 18:55:59
Type:     No Login
Username: username_here
Machine:  localhost

Esto luce inusual desde que no contamos con un usuario en la base de datos llamado username_here Esto es, obviamente, un usuario inválido. Mi próxima parada fue mirar los logs del web server para ver quién o qué disparó este login inusual.

Aquí hay un extractro del log de Apache:

[18:55:36] GET /.wp-config.php_copy
[18:55:38] GET /.wp-config.php.rar
[18:55:39] GET /.wp-config.php.7z
[18:55:41] GET /.wp-config.php.tmp
[18:55:42] GET /.wp-config.php_tmp
[18:55:44] GET /.wp-config.php.old
[18:55:46] GET /.wp-config.php.0
[18:55:47] GET /.wp-config.php.1
[18:55:49] GET /.wp-config.php.2
[18:55:50] GET /.wp-config.php.zip
[18:55:52] GET /.wp-config.php.gz
[18:55:53] GET /.wp-config.php~
[18:55:55] GET /wp-config.php.templ
[18:55:56] GET /wp-config.php1
[18:55:58] GET /wp-config.php2
[18:55:59] GET /wp-config-sample.php
[18:56:00] GET /wp-config-backup.txt
[18:56:02] GET /wp-config.php.orig
[18:56:03] GET /wp-config.php.original
[18:56:05] GET /wp-license.php?file=..%2F..
[18:56:06] GET /wp-config.save
[18:56:07] GET /wp-config.txt
[18:56:09] GET /wp-config.dist
[18:56:10] GET /.wp-config.php.swo
[18:56:12] GET /wp-config%20copy.php
[18:56:12] GET /wp-config_good
[18:56:14] GET /wp-config-backup
[18:56:15] GET /wp-config-backup.php
[18:56:16] GET /wp-config-backup1.txt
[18:56:18] GET /wp-config-good
[18:56:19] GET /wp-config-sample.php.bak
[18:56:21] GET /wp-config-sample.php~
[18:56:22] GET /wp-config.backup

El culpable es claramente wp-config-sample.php, y mirando dentro de él, podemos encontrar estas líneas:

define( 'DB_USER', 'username_here' );
define( 'DB_PASSWORD', 'password_here' );
…
require_once ABSPATH . 'wp-settings.php';

Ahora entendemos qué pasó: alguien escaneó el sitio web buscando vulnerabilidades y llamó wp-config-sample.php. Ese script PHP contiene un usuario y contraseña inválido que disparó una falsa conexión a la base de datos. Core Audit detectó este inusual comportamiento y elevó una alerta.

Resolución

En WordPress, wp-config-sample.php es parte del paquete de instalación de WordPress. El proceso de instalación de WordPress copia este archivo en wp-config.php y define algunos parámetros como el usuario y contraseña de la base de datos.

Por lo tanto, wp-config-sample.php es esperado que exista en una instalación de WordPress. Y si el equipo de desarrollo de WordPress ha hecho bien su trabajo, es probable que no signifique una filtración de WordPress al llamarlo así.

Pero como todos sabemos, los errores existen, y ataques 0-dia pueden siempre ocurrir. Teniendo este archivo alrededor parece preguntar por problemas. Este archivo no tiene otro propósito en WordPress que no sea como plantilla para wp-config.php, entonces ¿no deberías eliminarlo?

Esto nos lleva a otro comportamiento de WordPress: su actualización. Cuando WordPress actualiza, sobre escribe todos los archivos que son parte del paquete de WordPress. Por lo tanto, borrando wp-config-sample.php será desecho tan pronto como WordPress automáticamente actualice.

Otra opción es dejar el archivo en el lugar pero cambiar los permisos del archivo así Apache no puede acceder ahí. Esto prevendría este script PHP de ejecutarse. Como sea, esto tal vez cause errores cuando WordPress intenta actualizar porque no será capaz de sobre escribir el archivo. Entonces la actualización requiere intervención manual.

Por ejemplo, puedes eliminar permisos ejecutando:

chown root:root wp-config-sample.php
chmod 000 wp-config-sample.php

Más allá

Como expliqué previamente, wp-config-sample.php es usado para crear wp-config.php durante la instalación. Esto significa que wp-config.php puede ser también vulnerable al mismo ataque u otro similar ataque 0-dia.

Más problemático es si una actualización de WordPress arregla una vulnerabilidad en wp-config-sample.php, este arreglo no actualizará wp-config.php desde que ese copy nunca es modificado.

wp-config.php está pensado para ser incluido por otros archivos de WordPress como index.php. Luego de definir los parámetros de la conexión de la base de datos, el script llama wp-settings.php para configurar el ambiente WordPress, incluyendo la conexión a la base de datos.

En otras palabras, wp-config.php nunca quiere ser ejecutado directamente. Para protegerlo contra un ataque ejecutado directamente, podemos agregar una línea en la parte de superior de wp-config.php para detener el proceso.

if (get_included_files()[0] == '/path_to_site/wp-config.php') exit();

¿WordPress?

Mientras muchos no van a considerar WordPress un buen ejemplo de seguridad de aplicación, pensamos que aporta valor por estas razones:

3ra Parte & Cadena de suministro

Primero y más importante, esto es una aplicación 100% de terceros. Nosotros no la codeamos, no revisamos el código fuente, y no tenemos casi conocimiento del código, el modelo de datos, y ningún otro aspecto de la aplicación.

WordPress es un software de código abierto expuesto tanto para vulnerabilidades descubiertas por hackers como ataques a la cadena de suministro.

Para hacerlo peor, los sitios de WordPress casi siempre usan plug-ins. Mucho del poder de una plataforma de WordPress está en su extensibilidad por las decenas de miles de plugins que existen. Los plugins significativamente expanden la superficie del área de la tercera parte del software y ataques a la cadena de suministro. Plug-ins significan un montón de código adicional desconocido de vendors o desarrolladores múltiples, diferentes estándares de código, mejoras al modelo de datos con más tablas, y más.

SQL dinámico

WordPress lleva el concepto de SQL dinámico a un extremo. No solo todos los SQLs embebidos literales, sino que los SQLs a menudo se generan dinámicamente con cláusulas creadas sobre la marcha en función de la entrada del usuario.

El desafío no es solo los dinámicos ataques SQL pero también el gran vocabulario SQL donde es imposible predecir todas las combinaciones SQL que WordPress puede generar.

De nuevo, plug-ins empeoran el problema debido a un todavía más grande y desconocido vocabulario SQL, y más potenciales vulnerabilidades en el código que genera SQLs dinámicos.

Popular & De cara a Internet

WordPress es muy popular y es una aplicación orientada a Internet. Hackers son, por lo tanto, altamente incentivados para encontrar vulnerabilidades. Explotar estas vulnerabilidades puede ser también fácil desde que Internet está lleno de sitios en WordPress con poca o no adicional seguridad.

Ideas finales

A pesar de estos desafíos, los análisis de anomalía de Core Audit proveen seguridad efectiva así como tiene un razonable nivel de falsos positivos y, en este caso, ha sido alertado de un ataque contra la aplicación.

Es importante notar que Core Audit no tiene un soporte especial para PHP o WordPress. Tampoco miramos ninguna vulnerabilidad en particular en la base de datos o la aplicación. Solo teníamos un objetivo general de detección de anomalía que nos alertó tan pronto como la aplicación se comportó diferente. Esto fue suficiente para identificar un ataque.

Como has visto, monitorear cambios en el perfil de la actividad de la base de datos de la aplicación nos permite detectar muchos cambios en el comportamiento de la aplicación. Mientras algunos cambios ocurren naturalmente, otros indican un problema de seguridad o un ataque.