Yamila Levalle

Yamila Levalle

Information Systems Engineer (UTN FRBA). CISSP (ISC2). Specialties: Information Security, Ethical Hacking, ISO 27001, Information Security Management, Network Security, PCI DSS, Vulnerability Management, Web Application Security, Security Audits, Risk Management, Security Awareness, Security Assessments
Ciberseguridad
El lado oscuro de la impresión 3D: desafíos, riesgos y usos maliciosos (II)
La tecnología de impresión 3D está revolucionando los procesos de fabricación y sus entusiastas imaginan un futuro donde cada hogar y empresa tenga al menos uno de estos dispositivos, lo que transformaría la forma en que producimos, consumimos y reciclamos los objetos. Ahora bien… ¿Qué riesgos de ciberseguridad son los más probables en este escenario? Espionaje, malware, destrucción, creación de armas… Tras analizar la modificación no autorizada de archivos de impresión y la modificación de software o firmware, veamos el resto. Exposición a internet o redes inseguras Al conectar una impresora 3D a Internet, se convierte automáticamente en un dispositivo IoT. Cualquier acceso a la red que posea, ya sea directamente o a través de un middleware, aumenta la superficie de ataque y la expone a nuevas debilidades de seguridad. Como ejemplo de lo anterior podemos mencionar Octoprint, que es un proyecto open source para la administración web remota de impresoras 3D. Este software se conecta a la impresora y permite desde iniciar nuevos trabajos de impresión hasta ver y grabar una impresión actual desde una cámara web. Recientemente se reportó a Octoprint un fallo en su software de administración de impresoras por el cual si Octoprint está expuesto a Internet y no bien configurado, un usuario no autorizado podría obtener acceso de administrador a este software y, en consecuencia, a la impresora 3D. Al margen de los problemas en la industria, imaginemos por si fuera poco que una impresora 3D en el hogar, en manos de atacantes que modifiquen malintencionadamente su configuración, podría sobrecalentarse, fundirse, generar un cortocircuito o quedar fuera de servicio. También podría ser usada para cargar archivos de impresión maliciosos como el mencionado en la vulnerabilidad del Firmware Marlin, que permitieran tomar control de equipo. Robo de modelos y archivos de impresión confidenciales Los proyectos de impresión 3D en industrias como la aviación o la fabricación de autopartes suelen ser costosos e incluir el diseño de modelos muy específicos, que llevan tiempo y esfuerzo de diseño, prototipado y pruebas de resistencia e integridad antes de llegar a su versión final. Estos modelos suelen ser críticos y confidenciales. El problema es que la mayoría de los archivos de impresión 3D no poseen cifrado nativo, si un atacante pudiera acceder a ellos, podría sustraerlos y compartirlos públicamente, venderlos en el mercado negro o reproducir el objeto en otro dispositivo de impresión 3D con las consecuentes perdidas económicas y de reputación para la empresa víctima del ataque. Las armas fabricadas a través de impresión 3D también son un área preocupante para sus fabricantes, dado que si un atacante logra obtener los diseños y los comparte, el fabricante podría ser considerado legalmente responsable en caso de que alguna persona se descargue el archivo, imprima el arma y la utilice en algún tipo de ataque (aunque claro, esto depende de la legislación de cada país). Arma Impresa en 3D "The Liberator" Impresión de Piezas con Fines Maliciosos: Los investigadores y especialistas en seguridad informática siguen encontrando formas cada vez más creativas de utilizar las impresoras 3D en esta área. Por ejemplo, una investigadora utilizó una impresora 3D para hacer un compartimiento oculto en sus zapatos para ocultar herramientas de hacking. Otro investigador utilizó una cabeza impresa en 3D para burlar el sistema de reconocimiento facial de Android y en sitios de modelos de impresión 3D como Thingiverse se pueden encontrar desde drones diseñados para pentesters hasta la famosa tarjeta de Kevin Mitnick con ganzúas. Cabeza impresa 3D para burlar sistemas de identificación facial Pero los criminales también pueden utilizar la tecnología de impresión 3D para imprimir armas o piezas potencialmente peligrosas como las siguientes: Skimmers: un carder es un tipo de delincuente que se centra en el fraude con tarjetas de crédito, intenta robar la información digital o física de las tarjetas ya sea en los dispositivos POS o en los cajeros automáticos para crear luego copias falsas. Con una impresora 3D, resulta mucho más fácil incluso para un criminal de escasos recursos crear un dispositivo para clonar tarjetas de crédito (denominado skimmer) que parezca un lector de tarjetas normal y simule creíblemente ser parte del cajero automático. Duplicación de llaves y master keys: en Alemania utilizaron una impresora 3D para reproducir llaves de esposas de alta seguridad. En el MIT realizaban tomografías computadas de llaves y luego utilizaban los escaneos para imprimir llaves maestras en 3D de una marca de llaves "no duplicables". También se conocen diseños imprimibles en 3D para llaves maestras de equipaje aprobadas por la TSA, incluso actualmente en Thingiverse pueden encontrarse Key Decoders para duplicar llaves de hogares. Lo mencionado anteriormente no es ilegal, pero los delincuentes podrían adoptar estos métodos para usos indebidos. Distribución de drogas: distintos grupos de distribución de drogas utilizan la impresión 3D, como por ejemplo el grupo DougHeffernan, que imprimía cartuchos de inyección de tinta, contenedores falsos, cajas de maquillaje y cartuchos de juegos para ocultar drogas en su interior y entregarlas a sus clientes sin despertar sospechas. Falsificación: la impresión 3D permite materializar casi cualquier objeto de acuerdo a un modelo de diseño creado por el usuario, descargado de internet o copiado. Como se explicó en el punto anterior, si estos modelos son sustraídos a empresas legítimas y compartidos o vendidos por parte de criminales, podrían usarse para la falsificación de productos. Conclusiones y recomendaciones Parte de la solución proviene de la industria de la impresión 3D que debe tener en cuenta las mejores prácticas en el desarrollo de software y firmware para evitar vulnerabilidades, pero las empresas y los propietarios individuales de impresoras 3D pueden desempeñar un papel importante en la protección de su dispositivo de la siguiente manera: Utilizando un cortafuegos correctamente, configurado además de la propia configuración del dispositvo que permita limitar el acceso para proteger la impresora y la red en la que se encuentra. Si es posible, no conectar la impresora 3D a Internet, y en caso de ser indispensable, utilizando al menos una VPN y un segundo factor autenticación para proteger las comunicaciones y asegurarse que solo los usuarios autorizados tengan acceso a su administración. Actualizando periódicamente el firmware de la impresora 3D y el software utilizado para las distintas etapas del proceso de impresión. Protegiendo los archivos de impresión y modelos críticos o confidenciales con controles de acceso adecuados, cifrando su contenido y verificando su integridad antes de ser utilizados para la impresión de piezas, pudiendo así detectar modificaciones no autorizadas. La mayoría de las impresoras 3D son simplemente ordenadores de propósito especial y, por lo tanto, tienen los mismos riesgos potenciales de seguridad que cualquier otro equipo. Al conectarlas a Internet se convierten en dispositivos de IoT y se exponen al mundo, por lo cual podrían usarse como plataforma para atacar más fácilmente a otros equipos críticos en la red o también podrían ser atacadas directamente y fundirse, sobrecalentarse o quedar fuera de servicio. En entornos industriales las impresoras 3D son activos altamente sensibles puesto que fabrican objetos físicos en los que se necesita confiar y que a menudo se basan en un diseño o modelo confidencial. Antes de que todos los hogares y empresas tengan una impresora 3D, la industria necesita encontrar una manera de abordar estos riesgos de seguridad. Primera parte del análisis: » El lado oscuro de la impresión 3D: desafíos, riesgos y usos maliciosos (I)
5 de marzo de 2019
Ciberseguridad
El lado oscuro de la impresión 3D: desafíos, riesgos y usos maliciosos (I)
La tecnología de impresión 3D está revolucionando los procesos de fabricación, sus entusiastas ya imaginan un futuro donde cada hogar y empresa tenga al menos uno de estos dispositivos, lo que transformaría la forma en que producimos, consumimos y reciclamos los objetos. Ahora bien… ¿qué riesgos de ciberseguridad son los más probables en este escenario? Espionaje, malware, destrucción, creación de armas…Vamos a analizarlos. Tabla de impresión 3D La impresión 3D es un grupo de tecnologías de fabricación por adición, en las que se crea un objeto tridimensional a partir de modelos CAD o 3D, mediante la superposición de capas sucesivas de material. Las impresoras 3D por lo general son más rápidas, económicas y fáciles de usar que otras tecnologías de fabricación por adición, y además ofrecen la capacidad para imprimir piezas de diferentes materiales, con diferentes propiedades físicas y mecánicas, normalmente con un proceso de ensamble sencillo. Existen varios tipos de impresoras 3D, sus principales diferencias se encuentran en la técnica empleada para superponer las diferentes capas, la tecnología utilizada y los materiales que soportan. Algunos métodos funden o ablandan el material para producir las capas, por ejemplo, sintetizado de láser selectivo (SLS) y modelado por deposición fundida (FDM), mientras que otros depositan materiales líquidos que luego son solidificados. Cada método tiene sus propias ventajas e inconvenientes. Pero como toda tecnología, l a impresión 3D también tiene su lado oscuro, incluyendo los riesgos de seguridad que implica su utilización y los usos maliciosos o abusos posibles de esta tecnología. Vamos a analizar cinco de estos aspectos, que a nuestro entender son los más representativos: Modificación no autorizada de archivos de impresión Vulnerabilidades en software y firmware Exposición a Internet o redes inseguras Robo de modelos o archivos de impresión confidenciales Impresión de piezas con fines maliciosos Modificación no autorizada de archivos de impresión Para imprimir en 3D con la técnica FDM, el proceso consiste en ir alimentando con un filamento termoplástico a un extrusor, éste lo funde y lo deposita en capas siguiendo un recorrido de acuerdo a la forma que posee el objeto a cada altura. Las instrucciones para ir disponiendo el material fundido y construir así la forma de la pieza se suelen describir usando G-Code, que es un lenguaje de programación con el que se expresan las órdenes que debe ejecutar la impresora 3D. G-Code es en realidad un estándar muy difundido para programar máquinas de control numérico como tornos o fresadoras (no sólo impresoras 3D), e indica a la impresora por medio de un archivo los movimientos exactos que debe realizar a través de un sistema de coordenadas cartesiano 3D, cómo de caliente debe estar el extrusor, cómo de rápido rápido deben girar los motores, la cantidad de material a fundir y demás aspectos. Ejemplo de G-Code El problema es que l a mayoría de los archivos de impresión 3D no poseen verificación de integridad. Si un atacante pudiera acceder a ellos antes de ser impresos, podría modificarlos sin ser detectado y esa modificación podría tener graves repercusiones, sobre todo en entornos industriales. Los objetos impresos en 3D tienen una estructura interna que, en general, no es visible para el ojo humano una vez que se completa la impresión. Muchos proyectos incluyen elementos de diseño específicos, cruciales para la resistencia y la integridad estructural del objeto impreso. Un atacante con acceso a los archivos G-Code o archivos de modelo podría modificarlos o sabotearlos, introduciendo puntos débiles en su diseño que solo saldrían a la luz cuando se use el objeto, lo cual podría ser desastroso para una fábrica que utiliza impresoras de alta gama para desarrollar piezas industriales. A este respecto, un grupo de investigadores de varias universidades lanzó un vídeo que muestra lo que ellos denominan el ataque dr0wned. En el video se puede observar, desde el principio hasta el final, cómo un atacante podría infectar el equipo de una víctima, encontrar los modelos de impresión 3D que contiene (en este caso, uno para una hélice de avión no tripulado) y posteriormente modificar esos modelos para que finalmente fallen durante el uso. Vulnerabilidades en software y firmware Si bien las impresoras 3D difieren entre sí en muchos aspectos, comparten atributos similares que las hacen vulnerables a ataques informáticos. Uno de ellos es el hecho de que incluyen software y firmware que (por supuesto) pueden contener vulnerabilidades de seguridad que podrían ser aprovechadas por los criminales para atacar estos equipos. En cuanto al firmware, las impresoras 3D "Do It Yourself" o DIY más simples y económicas, como por ejemplo los clones de la conocida Prusa I3 MK2 y las impresoras 3D de RepRap, a menudo utilizan el firmware open source denominado Marlin. En junio de 2018, un investigador descubrió una vulnerabilidad de buffer overflow en el firmware Marlin, que fue corregida en las últimas versiones. Si un atacante convence al operador de la impresora (ya sea en entorno doméstico o industrial) para que cargue un archivo de impresión 3D malintencionado con instrucciones específicas en G-Code, podría explotar esta vulnerabilidad para ejecutar código arbitrario en la impresora de la víctima. Sobre el software, existen herramientas de software 3D específicas que se utilizan en cada una de las distintas etapas de la impresión 3D, como el diseño de modelos ( modeling) y la traducción de estos modelos a capas ( slicing), estas herramientas también podrían contener vulnerabilidades de seguridad. Por ejemplo, Blender, es un software usado para slicing que posee varias vulnerabilidades de buffer overflow, como se detalla en los siguientes CVEs, por las que un atacante podría convencer al operador de la impresora de abrir un archivo .blend malicioso especialmente manipulado, lo que resultaría en la ejecución código arbitrario en el equipo. Blender Continuación del análisis describiendo el resto de riesgos: » El lado oscuro de la impresión 3D: desafíos, riesgos y usos maliciosos (II)
26 de febrero de 2019
Cloud
Ciberseguridad
Análisis técnico de un SIEM… ¿están seguros tus logs?
Los SIEM suelen utilizarse en ambientes de alta seguridad o regulados, donde se requiere un monitoreo y análisis de logs periódico en busca de incidentes de seguridad. Ayudan a que una red esté más segura, sí… pero… nos preguntamos un poco más allá: ¿realmente los logs de los equipos de nuestra infraestructura están adecuadamente protegidos? Vamos a abordar en esta entrada unas pautas mínimas que se deben tener en cuenta para securizar un SIEM, poniendo como ejemplo y caso de uso una investigación particular sobre Splunk, uno de los SIEM más conocidos. Hace un tiempo atrás, en uno de nuestros webinars de #11PathsTalks, Claudio Caracciolo y David Prieto nos hablaban sobre qué es un SIEM y sobre correlación avanzada. Analizaremos las distintas cuestiones que pueden influir de forma positiva o negativa en la seguridad de un SIEM, pero en este caso nos basaremos en Splunk. Como cualquier SIEM, permite buscar, monitorear y analizar información generada por diferentes equipos de la infraestructura, en su caso por medio de una interfaz web. Este software captura, indexa y correlaciona información en tiempo real en un repositorio que permite generar gráficos, reportes, alertas y diferentes visualizaciones. Según su web, tiene más de 3700 clientes, incluyendo más de la mitad de las Fortune 100. Las versiones de Splunk más utilizadas son tres: Splunk Free, Splunk Enterprise y Splunk Cloud. También hay una versión light que se utiliza principalmente para AWS pero que no analizaremos en esta oportunidad. Si bien es posible analizar un SIEM desde muchos posibles vectores de ataque, para esta primera aproximación en particular nos gustaría centrarnos en 4 puntos en concreto: Métodos de autenticación Usuarios de instalación Administración e instalación de aplicaciones Exposición a Internet En base a esto y trabajando en el análisis sobre las diferentes versiones, nos hemos encontrado con algunas curiosidades que mencionamos a continuación, y que podrían servir como "molde" para el análisis de cualquier sistema de este tipo. Métodos de autenticación Splunk Free no posee ningún tipo de autenticación, cualquier usuario que conozca la dirección IP y el puerto correspondiente puede iniciar sesión en Splunk con privilegios administrativos. En la misma web del fabricante indica claramente que esta versión no es adecuada para ambientes corporativos. Splunk Enterprise posee varias opciones de métodos de autenticación a elegir (Splunk, LDAP, Scripted, SAML, ProxySS) que se configuran en el archivo $SPLUNK_HOME/etc/system/local/authentication.conf. La autenticación propia de Splunk (método de autenticación seleccionado por defecto) tampoco es adecuada para ambientes corporativos ya que el único parámetro de contraseña que permite configurar es la longitud de contraseña, y por defecto se encuentra configurada con valor 0. Splunk no permite configurar bloqueo por intentos fallidos de acceso, lo cual lo hace susceptible a ataques de fuerza bruta, ni tampoco reglas que garanticen la complejidad de contraseñas. El usuario por defecto de la versión Enterprise es admin y su correspondiente contraseña "changeme". Splunk Cloud viene en dos versiones diferentes, Managed Splunk Cloud y Self-Service Splunk Cloud. Para diferenciar uno de otro se puede analizar la URL. Las URLs de los Self-Service son del estilo: https://prd-*.cloud.splunk.com y las URLs de los Managed son del estilo: https://*.splunkcloud.com. En los Splunk Self-Service los usuarios se autentican con su cuenta de splunk.com que tiene restricciones de longitud y complejidad de contraseña. En los Splunk Managed los usuarios pueden autenticarse por medio de SAML, aunque suele utilizarse la autenticación propia de Splunk ya que viene por defecto. Si bien trae configurada una longitud máxima de 8 caracteres, es el único parámetro que permite configurar. Es importante tener en cuenta que al configurar Splunk para utilizar otro método de autenticación que no sea la autenticación propia (como por ejemplo LDAP), todas las cuentas de usuario locales con autenticación propia de Splunk siguen activas (incluyendo la cuenta admin). Para eliminar todas las cuentas locales se debe dejar en blanco el archivo $SPLUNK_HOME/etc/passwd. Este archivo no debe ser eliminado, ya que , en caso contrario, se vuelve al usuario por defecto admin con contraseña "changeme". Usuario de instalación Tanto Splunk Free como Enterprise pueden ser instalados con privilegios de root en plataformas Linux/Unix, con privilegios administrativos en plataformas Windows o con usuarios con menores privilegios en ambas plataformas, configurando adecuadamente los permisos necesarios en el sistema de ficheros. Esta última opción es la más recomendada en ambientes corporativos ya que reduce la superficie de ataques en caso de que Splunk sea comprometido. La documentación de instalación de Splunk indica cómo realizar la instalación con usuarios con privilegios restringidos en las diferentes plataformas. También los universal forwarders o clientes de Splunk que se instalan en los equipos de los cuales se van a recolectar logs, deben ser instalados con usuarios de privilegios limitados, puesto que podrían ser usados para ejecutar comandos o scripts enviados desde el servidor Splunk utilizándolo como deployment server. Administración e Instalación de Aplicaciones Splunk Free y Enterprise pueden administrarse de diversos modos: desde la consola web, el Splunk CLI, modificando los archivos de configuración correspondientes en el sistema operativo o utilizando la REST API. Tanto Splunk Free como Enterprise permiten la instalación de aplicaciones "custom" o creadas por el usuario (por ejemplo en Python) además de las presentes en Splunkbase, que es el repositorio oficial de aplicaciones y add-ons de Splunk. La instalación de aplicaciones creadas por el usuario presenta riesgos, ya que una vez comprometido el servidor Splunk se podría instalar cualquier tipo de aplicación maliciosa que, por ejemplo, permita administrar el servidor por medio de un web shell o un reverse shell(siempre teniendo en cuenta los permisos de la cuenta de usuario utilizada para la instalación de Splunk), o se envíe a los universal forwarders para comprometer a los equipos clientes de Splunk. En Splunk Cloud no se tiene acceso para administrar Splunk desde el CLI ni al sistema de ficheros para modificar los archivos de configuración. Se pude utilizar Splunk Web y la REST API para realizar algunas tareas administrativas. Tampoco se puede instalar cualquier aplicación, sino únicamente las aprobadas por Splunk para ser usadas en un ambiente cloud. Las aplicaciones antes de ser aprobadas pasan por una validación por medio de la herramienta AppInspect que determina si cumplen con los requisitos de seguridad definidos, como por ejemplo: no requerir elevación de privilegios con sudo, su, groupadd o useradd, no usar reverse shells, no manipular archivos fuera del directorio de la aplicación, no manipular procesos fuera del control de la aplicación ni el sistema operativo, ni reiniciar el servidor. Exposición a Internet Búsqueda en Shodan de servidores Splunk En el caso de Splunk Free y Enterprise, no es recomendable exponer la interfaz web (puerto por defecto 8080) ni la interfaz de management (puerto 8089) a Internet. Sin embargo, lamentablemente, es una práctica bastante común como se puede apreciar en el buscador Shodan buscando por http.component:"splunk" donde aparecen casi 8000 equipos. También es posible identificar de qué tipo de Splunk se trata analizando el código fuente de la página de login del mismo Splunk: [dirección ip="" n=""]:[puerto]/en-US/account/login?return_to=%2Fen-US%2F[/puerto][/dirección] "isFree":true nos indica que se trata de un Splunk Versión Free (sin autenticación) "instance_type":"cloud" nos indica de que se trata de Splunk versión Cloud "instance_type":"download" y "product_type":"enterprise" nos indican que se trata de un Splunk Versión Enterprise. "hasLoggedIn":false nos indica que ningún usuario inició sesión en el equipo, lo cual es un claro indicador de que ese Splunk aún mantiene la contraseña por defecto ya que nadie pudo iniciar sesión para cambiarla. Como dato curioso, para el caso particular del análisis de Splunk, nos hemos encontrado con que al momento de instalación, se crea un archivo con la clave a utilizar para cifrar información de autenticación en archivos de configuración y para cifrar las claves utilizadas por las diferentes aplicaciones. Esta clave se encuentra en el archivo $SPLUNK_HOME/etc/auth/splunk.secret y es única por cada instalación de Splunk. Las aplicaciones que se bajan de Splunkbase (como por ejemplo el addon que permite la integración con Active Directory, o los que permiten integrar Splunk con dispositivos de comunicaciones) necesitan almacenar credenciales en los archivos de configuración de la propia aplicación. Splunk cifra esas contraseñas por medio de splunk.secret. El riesgo en este caso, es que una vez comprometido el servidor Splunk, se puede utilizar la misma API de Splunk para descifrar la contraseña de estas aplicaciones con un simple script de Python y así poder comprometer otros componentes de la infraestructura. Conclusiones Como en muchos otros ámbitos, se pueden proteger los equipos de la infraestructura, y el servidor donde se encuentra instalado el SIEM eligiendo adecuadamente la versión a utilizar y configurándolo de manera segura (siguiendo las mejores prácticas del fabricante). Lógicamente, ante una infraestructura tan delicada, cualquier error podría exponer información muy valiosa para los atacantes, e incluso algunas veces podría dar a conocer claves de las aplicaciones internas de la organización. En este ejemplo nos hemos centrado en Splunk como "caso práctico" pero, en general para realizar el hardening de un SIEM, deberían considerarse los siguientes aspectos: Utilizar un usuario no privilegiado (ni root ni administrador) para la instalación Modificar las contraseñas por defecto apenas instalado Seleccionar un método de autenticación robusto y asegurarse que no existan formas fáciles de eludirlo (como vimos en el caso de Splunk que requería borrar el archivo $SPLUNK_HOME/etc/passwd) Utilizar certificados en la interfaz web, preferentemente no autogenerados Deshabilitar el componente web en caso de no utilizarlo No exponer los puertos del SIEM a redes no confiables Actualizar el SIEM regularmente, e incorporarlo en el alcance de las auditorias o test de intrusión que se realicen periódicamente Activar la auditoria propia del SIEM y monitorear los eventos resultantes Para cerrar este post, y dado que hemos hablado de Splunk durante nuestro análisis, recopilamos a continuación los enlaces propios del fabricante con las mejores prácticas para proteger estos equipos: Best practices in protecting splunk enterprise Community: Deploy Hardened Splunk Documentation Splunk latest security hardeningstandards
14 de mayo de 2018