Las bases de datos modernas almacenan todo tipo de datos. De trivial a altamente sensible. Los restaurantes que frecuentamos, nuestras ubicaciones en el mapa, nuestras credenciales de identidad (por ejemplo, números de seguro social, direcciones, registros médicos, información bancaria, etc.) y todo lo demás probablemente esté almacenado en una base de datos en alguna parte. No es de extrañar que los datos sean tan valiosos.
Las tecnologías de bases de datos avanzan a un ritmo vertiginoso. La innovación, el progreso, la integridad y las mejoras abundan como resultado directo del trabajo de ingenieros, desarrolladores y comunidades sólidas que apoyan a esos proveedores.
Sin embargo, hay otra cara de la moneda. Eso, desafortunadamente, coexiste dentro de este mundo basado en datos en forma de malware, virus y exploits en una escala masiva y nunca antes vista.
Los datos también son valiosos para las partes en ese lado de la operación. Pero por diferentes razones. Cualquiera de ellos podría ser, entre otros, poder, chantaje, ganancia y acceso financiero, control, diversión, bromas, malicia, robo, venganza... Ya entiendes la idea. La lista es interminable.
Por desgracia, tenemos que operar con una mentalidad de seguridad. Sin esta mentalidad, dejamos nuestros sistemas vulnerables a este tipo de ataques. PostgreSQL es tan susceptible de compromiso, uso indebido, robo, acceso/control no autorizado como otras formas de software.
Entonces, ¿qué medidas podemos tomar para mitigar la cantidad de riesgos para nuestras instalaciones de PostgreSQL?
Creo firmemente que promover la conciencia de las amenazas conocidas que existen es un buen lugar para comenzar. El conocimiento es poder y debemos utilizar todo lo que esté a nuestra disposición. Además, ¿cómo podemos controlar eso de lo que ni siquiera somos conscientes para reforzar la seguridad en esas instancias de PostgreSQL y proteger los datos que residen allí?
Recientemente busqué 'inquietudes' y 'amenazas' de seguridad conocidas, apuntando al entorno PostgreSQL. Mi búsqueda abarcó informes, artículos y publicaciones de blog recientes dentro del primer trimestre de 2018. Además de ese marco de tiempo específico, exploré preocupaciones conocidas desde hace mucho tiempo que todavía son amenazas viables en la actualidad (a saber, SQL Injection), aunque no están pulidas. o exhibido como 'descubierto recientemente '.
Una oportunidad para tomar una foto
Una inmersión profunda en los ataques a bases de datos [Parte III]:¿Por qué la imagen de Scarlett Johansson hizo que mi base de datos de Postgres comenzara a minar Monero?
La noticia de este astuto ataque de malware devolvió la mayor cantidad de "accesos" de mis resultados de búsqueda objetivos.
Visitaremos una de varias excelentes publicaciones de blog y un resumen de su contenido. También he incluido publicaciones de blog adicionales hacia el final de esta sección, así que asegúrate de visitarlas y detallar esta intrusión.
Observaciones
Información de Imperva, informa que su base de datos honeypot (StickyDB) descubrió un ataque de malware en uno de sus servidores PostgreSQL. La red trampa, como Imperva llama al sistema, está diseñada para engañar a los atacantes para que ataquen la base de datos para que ellos (Imperva) puedan aprender sobre ella y ser más seguros. En este caso particular, la carga útil es un malware que criptomina Monero, incrustado en una foto de Scarlett Johansson.
La carga útil se vuelca en el disco en tiempo de ejecución con la función lo_export. Pero aparentemente, esto sucede porque lo_export es una entrada en pg_proc en lugar de una llamada directa normal (lo_export).
Detalles interesantes directamente de la publicación del blog aquí para una claridad extrema (consulte el artículo citado),
Ahora el atacante puede ejecutar comandos del sistema local utilizando una función simple:fun6440002537. Esta función SQL es un contenedor para llamar a una función en lenguaje C, "sys_eval", una pequeña función exportada en "tmp406001440" (un binario basado en sqlmapproject), que básicamente actúa como proxy para invocar comandos de shell desde el cliente SQL.
Entonces, ¿cuáles serán los próximos pasos del ataque? Algo de reconocimiento. Así que comenzó obteniendo los detalles de la GPU mediante la ejecución de lshw -c video y continuó con cat /proc/cpuinfo para obtener los detalles de la CPU (Figuras 3-4). Si bien esto parece extraño al principio, tiene mucho sentido cuando tu objetivo final es extraer más de tu criptomoneda favorita, ¿verdad?
Con una combinación de acceso a la base de datos y la capacidad de ejecutar código de forma remota, todo mientras 'pasa desapercibido ' de soluciones de monitoreo, el intruso luego descarga la carga útil a través de una foto de Scarlett Johansson.
(Nota:desde entonces, la foto se eliminó de su ubicación alojada. Consulte el artículo de enlace para ver la mención).
Según el informe, la carga útil está en formato binario. Ese código binario se agregó a la foto para pasar por una foto real durante la carga, lo que permitió una imagen visible.
Consulte la Figura 6 de la publicación para conocer el SQL responsable de utilizar wget, dd y ejecutar chmod para obtener permisos en el archivo descargado. Ese archivo descargado luego crea otro ejecutable que es responsable de minar Monero. Por supuesto, se necesita limpieza y limpieza después de todo este trabajo infame.
La Figura 7 muestra el SQL en ejecución.
Imperva recomienda monitorear esta lista de posibles áreas de incumplimiento en la sección de cierre:
- Cuidado con las llamadas directas de PostgreSQL a lo_export o llamadas indirectas a través de entradas en pg_proc.
- Cuidado con las funciones de PostgreSQL que llaman a binarios en lenguaje C.
- Use un firewall para bloquear el tráfico de red saliente desde su base de datos a Internet.
- Asegúrese de que su base de datos no esté asignada con una dirección IP pública. Si es así, restrinja el acceso solo a los hosts que interactúan con él (servidor de aplicaciones o clientes propiedad de DBA).
Imperva también realizó varias pruebas de antivirus junto con detalles de cómo los atacantes pueden localizar potencialmente servidores PostgreSQL vulnerables. Aunque no los incluí aquí por brevedad, consulte el artículo para obtener detalles completos de sus hallazgos.
Lecturas recomendadas
- Imperva tiene 2 artículos anteriores que acompañan a la Parte 3 (el que se analiza aquí). Si bien esos no apuntan mucho a PostgreSQL como lo que acabamos de pasar por alto, son lecturas muy informativas:
- Parte 1
- Parte 2
- El ataque de malware PostgreSQL de Scarlett Johansson
- Los piratas informáticos apuntan a las bases de datos de PostgreSQL con Coinminer oculto en la imagen de Scarlett Johannsson
- Un hilo de Hacker News sobre el exploit.
Detalles, informe y vulnerabilidades de CVE
Visité este sitio, que publica las últimas amenazas de seguridad por proveedor y descubrí 4 vulnerabilidades en el primer trimestre de 2018. La página de información de seguridad de PostgreSQL también las incluye, así que no dude en consultar ese recurso.
Aunque se han abordado la mayoría de ellos, sentí que era importante incluirlos en esta publicación para concienciar a los lectores que tal vez no los conocían. Siento que podemos aprender de todos ellos. Especialmente en las diferentes formas de vulnerabilidades descubiertas.
Se enumeran a continuación en el orden de la fecha de publicación:
Yo. CVE-2018-1052 fecha de publicación 2018-02-09:Fecha de actualización 3/10/2018
Resumen:
La vulnerabilidad de divulgación de memoria en el particionamiento de tablas se encontró en PostgreSQL 10.x antes de 10.2, lo que permitía a un atacante autenticado leer bytes arbitrarios de la memoria del servidor a través de una inserción especialmente diseñada en una tabla particionada.
Esta vulnerabilidad se solucionó con el lanzamiento de PostgreSQL 10.2 confirmado aquí. También se menciona la versión anterior 9.x corregida, así que visite ese enlace para verificar su versión específica.
II. CVE-2018-1053 fecha de publicación 2018-02-09:Fecha de actualización 3/15/2018
Resumen:
En PostgreSQL 9.3.x antes de 9.3.21, 9.4.x antes de 9.4.16, 9.5.x antes de 9.5.11, 9.6.x antes de 9.6.7 y 10.x antes de 10.2, pg_upgrade crea un archivo en el directorio de trabajo actual que contiene la salida de `pg_dumpall -g` bajo umask que estaba vigente cuando el usuario invocó pg_upgrade, y no bajo 0077 que normalmente se usa para otros archivos temporales. Esto puede permitir que un atacante autenticado lea o modifique un archivo, que puede contener contraseñas de bases de datos cifradas o no cifradas. El ataque es inviable si un modo de directorio bloquea al atacante que busca en el directorio de trabajo actual o si el umask prevaleciente bloquea al atacante al abrir el archivo.
Al igual que con el CVE-2018-1052 anterior, PostgreSQL 10.2 solucionó esta parte de la vulnerabilidad:
Asegúrese de que todos los archivos temporales creados con "pg_upgrade" no sean legibles en todo el mundo
Muchas versiones anteriores de PostgreSQL se ven afectadas por esta vulnerabilidad. Asegúrese de visitar el enlace provisto para todas las versiones enumeradas.
III. CVE-2017-14798 fecha de publicación 2018-03-01:Fecha de actualización 3/26/2018
Resumen:
Los atacantes que pueden acceder a la cuenta de PostgreSQL pueden utilizar una condición de carrera en el script de inicio de PostgreSQL para escalar sus privilegios a root.
Aunque no pude encontrar en ninguna parte de la página de enlaces que se mencionara la versión 10 de PostgreSQL, hay muchas versiones anteriores, así que visite ese enlace si ejecuta versiones anteriores.
Los usuarios de Suse Linux Enterprise Server pueden estar interesados en 2 artículos vinculados aquí y aquí donde se corrigió esta vulnerabilidad para el script de inicio de la versión 9.4.
IV. CVE-2018-1058 fecha de publicación 2018-03-02:Fecha de actualización 3/22/2018
Resumen:
Se encontró una falla en la forma en que PostgreSQL permitía a un usuario modificar el comportamiento de una consulta para otros usuarios. Un atacante con una cuenta de usuario podría usar esta falla para ejecutar código con los permisos de superusuario en la base de datos. Las versiones 9.3 a 10 se ven afectadas.
Esta versión de actualización menciona esta vulnerabilidad con un interesante documento vinculado que todos los usuarios deberían visitar.
El artículo proporciona una guía fantástica de la comunidad titulada A Guide to CVE-2018-1058:Protect Your Search Path que tiene una increíble cantidad de información sobre la vulnerabilidad, los riesgos y las mejores prácticas para combatirla.
Haré todo lo posible para resumir, pero visite la guía para su propio beneficio, comprensión y comprensión.
Resumen:
Con la llegada de la versión 7.3 de PostgreSQL, se introdujeron los esquemas en el ecosistema. Esta mejora permite a los usuarios crear objetos en espacios de nombres separados. De forma predeterminada, cuando un usuario crea una base de datos, PostgreSQL también crea un esquema público en el que se crean todos los objetos nuevos. Los usuarios que pueden conectarse a una base de datos también pueden crear objetos en el esquema público de esa base de datos.
Esta sección directamente de la guía es muy importante (ver artículo citado):
Los esquemas permiten a los usuarios asignar espacios de nombres a los objetos, por lo que pueden existir objetos con el mismo nombre en diferentes esquemas en la misma base de datos. Si hay objetos con el mismo nombre en diferentes esquemas y no se especifica el par esquema/objeto específico (es decir, esquema.objeto), PostgreSQL decide qué objeto usar en función de la configuración de ruta_búsqueda. La configuración search_path especifica el orden en que se buscan los esquemas cuando se busca un objeto. El valor predeterminado para search_path es $user,public donde $user se refiere al nombre del usuario conectado (que se puede determinar ejecutando SELECT SESSION_USER;).
Otro punto clave está aquí:
El problema descrito en CVE-2018-1058 se centra en el esquema "público" predeterminado y en cómo PostgreSQL usa la configuración search_path. La capacidad de crear objetos con los mismos nombres en diferentes esquemas, combinada con la forma en que PostgreSQL busca objetos dentro de los esquemas, presenta una oportunidad para que un usuario modifique el comportamiento de una consulta para otros usuarios.
A continuación se muestra una lista de alto nivel que la guía recomienda la aplicación de estas prácticas según lo estipulado para reducir el riesgo de esta vulnerabilidad:
- No permitir que los usuarios creen nuevos objetos en el esquema público
- Establezca la ruta de búsqueda predeterminada para los usuarios de la base de datos
- Establezca la ruta de búsqueda predeterminada en el archivo de configuración de PostgreSQL (postgresql.conf)
Inyección SQL
Cualquier 'tema de seguridad ' La publicación o artículo de blog de SQL no puede etiquetarse a sí mismo como tal sin mencionar la inyección de SQL. Si bien este método de ataque no es ni mucho menos imaginativo 'el chico nuevo en el bloque ', tiene que ser incluido.
SQL Injection siempre es una amenaza y quizás aún más en el espacio de las aplicaciones web. Cualquier base de datos SQL -incluyendo PostgreSQL- es potencialmente vulnerable a ella.
Si bien no tengo una base de conocimientos profunda sobre SQL Injection, también conocida como SQLi, haré todo lo posible para proporcionar un breve resumen, cómo puede afectar potencialmente a su servidor PostgreSQL y, en última instancia, cómo reducir los riesgos de ser presa. a ella.
Consulte los enlaces proporcionados hacia el final de esta sección, todos los cuales contienen una gran cantidad de información, explicaciones y ejemplos en aquellas áreas que no puedo comunicar adecuadamente.
Desafortunadamente, existen varios tipos de inyecciones de SQL y todas comparten el objetivo común de insertar SQL ofensivo en las consultas para su ejecución en la base de datos, lo que quizás no haya sido pensado ni diseñado originalmente por el desarrollador.
La entrada de usuario no desinfectada, la verificación de tipo mal diseñada o inexistente (validación AKA), junto con la entrada de usuario sin escape, pueden dejar la puerta abierta de par en par para los posibles atacantes. Muchas API de programación web brindan cierta protección contra SQLi:por ejemplo, ORM (Mapeador relacional de objetos), consultas parametrizadas, verificación de tipos, etc. Sin embargo, es responsabilidad del desarrollador hacer todo lo posible y reducir los escenarios principales para la inyección de SQL implementando aquellas desviaciones y mecanismos a su alcance.
Aquí hay sugerencias notables para reducir el riesgo de inyección SQL de la hoja de trucos de prevención de inyección SQL de OWASP. Asegúrese de visitarlo para obtener detalles completos de los usos de ejemplo en la práctica (consulte el artículo citado).
Defensas Primarias:
- Opción 1:uso de declaraciones preparadas (con consultas parametrizadas)
- Opción 2:uso de procedimientos almacenados
- Opción 3:Validación de entrada de lista blanca
- Opción 4:escapar de todas las entradas proporcionadas por el usuario
Defensas Adicionales:
- También:Hacer cumplir el privilegio mínimo
- También:Realización de la validación de entrada de la lista blanca como defensa secundaria
Lectura recomendada:
He incluido artículos adicionales con mucha información para mayor estudio y conocimiento:
- ¿Qué es la inyección SQL? Este viejo pero bueno puede dañar sus aplicaciones web
- Inyección SQL (Wikipedia)
- Inyección SQL (CLOUDFLARE)
- Inyección SQL (w3schools.com)
- Hoja de referencia para la prevención de inyección de SQL
- Pruebas de inyección SQL
- Vulnerabilidades de inyección SQL y cómo prevenirlas
- Hoja de trucos de inyección SQL
Privilegios de funciones de Postgres
Tenemos un dicho para algo como "Somos nuestro peor enemigo ."
Definitivamente podemos aplicarlo para trabajar dentro del entorno PostgreSQL. El descuido, los malentendidos o la falta de diligencia son una oportunidad para los ataques y el uso no autorizado tanto como los que se lanzan deliberadamente.
Tal vez aún más, sin darse cuenta, permitiendo un acceso, rutas y canales más fáciles para que las partes infractoras se conecten.
Mencionaré un área que siempre necesita reevaluación o reevaluación de vez en cuando.
Privilegios de funciones injustificados o superfluos.
- SUPERUSUARIO
- CREATROL
- CREADOB
- CONCESIÓN
Definitivamente vale la pena echarle un vistazo a esta fusión de privilegios. SUPERUSER y CREATROLE son comandos extremadamente poderosos y estarían mejor en manos de un DBA en lugar de un analista o desarrollador, ¿no le parece?
¿El rol realmente necesita el atributo CREATEDB? ¿Qué pasa con la CONCESIÓN? Ese atributo tiene el potencial de mal uso en las manos equivocadas.
Considere todas las opciones antes de permitir funciones de estos atributos en su entorno.
Estrategias, mejores prácticas y endurecimiento
A continuación se muestra una lista de publicaciones de blog, artículos, listas de verificación y guías útiles que regresaron para un 'año atrás' (al momento de escribir este artículo) de resultados de búsqueda. No se enumeran en ningún orden de importancia y cada uno ofrece sugerencias notables.
- Maneras sencillas de proteger sus servidores de Postgres de un vector de ataque improbable:una imagen falsa de Scarlett Johansson
- Ayudando a proteger su base de datos PostgreSQL
- No sea testarudo... Fortalezca su base de datos PostgreSQL para garantizar la seguridad
- Cómo proteger su base de datos PostgreSQL:10 consejos
- Proteger PostgreSQL de ataques externos
- Privilegios y seguridad de PostgreSQL:bloqueo del esquema público
Conclusión
En este blog, analizamos los problemas de seguridad que preocupan a los administradores de PostgreSQL en todo el mundo:estos incluyen la inyección de SQL, que es el santo grial de todos los incidentes de seguridad, errores en los enfoques básicos para el manejo datos de forma segura, como no ajustar adecuadamente los permisos en su infraestructura, y también algunos problemas de seguridad menos conocidos que podrían pasarse por alto. Cuando se trata de la seguridad de nuestros datos, es fundamental que tomemos y apliquemos los consejos de partes confiables como Imperva y similares, que nos brindan formas de protegernos tanto de los ataques básicos como de los días 0 (vulneraciones que aún no se han detectado). conocido antes) por igual, porque el asesoramiento de buena reputación significa un buen futuro para nuestras bases de datos e infraestructura en su conjunto.
Tenga en cuenta que las medidas de seguridad que debemos tomar dependerán en gran medida de las vulnerabilidades que queremos evitar, pero en general, conocer todas las defensas necesarias para evitar la inyección de SQL, usar correctamente privilegios, y siempre tratando de reducir nuestro nivel de riesgo relacionado con las vulnerabilidades es crucial. Mantenernos actualizados con lo que está sucediendo en el espacio de seguridad de PostgreSQL también nos hará maravillas:solo podemos defender bien nuestros servidores (y, en consecuencia, nuestros datos) si sabemos qué podrían estar buscando los atacantes.
Si está buscando más prácticas recomendadas para mejorar la seguridad o la postura de rendimiento de sus instalaciones de PostgreSQL, recurra a ClusterControl:como la herramienta está desarrollada por expertos en bases de datos de primer nivel de todo el mundo, hará que sus bases de datos canten en poco tiempo. El producto también viene con una prueba gratuita de 30 días, así que asegúrese de no perderse la oportunidad de probar todas las funciones que ClusterControl puede ofrecer para su negocio y pruébelo hoy mismo.
Para obtener más contenido sobre cómo debe proteger sus instancias de bases de datos PostgreSQL, consulte el blog de Variousnines para obtener consejos:aprender a automatizar auditorías de seguridad para PostgreSQL sin duda será un paso en la dirección correcta. Asegúrese de seguirnos en Twitter, LinkedIn y suscríbase a nuestro feed RSS para obtener más actualizaciones, y nos vemos en la próxima.
