Quantcast
Channel: ElevenPaths Blog
Viewing all 1287 articles
Browse latest View live

News: Latch plugin for phpBB 3.x is out

$
0
0
We have uploaded to GitHub our latest plugin for phpBB 3.x. It makes it easier to use Latch technology with this popular forum system. You can download it form here. Here is a little how to so you can check how easy the integration is. If you want a full step by step guide, visit our slideshare channel.

Prerequisites
  • phpBB version 3.0.X. 
  • Curl extensions active in PHP (uncomment "extension=php_curl.dll" or "extension=curl.so" in Windows or Linux php.ini respectively. 
  • To get the "Application ID" and "Secret", (fundamental values for integrating Latch in any application), it’s necessary to register a developer account here. On the upper right side, click on "Developer area". 
Installing  
  • Once the administrator has downloaded the module, copy its content in phpBB root folder. 
  • Next step is to activate Latch module. From control panel, go to SYSTEM tab, and then to User Control Panel. Select from the menu Latch configuration and press add module button. 
  • After accepting the message, go back to User Control Panel, where there will be a table with installed modules. Latch will be the last one. 
  • Next to Latch configuration text are the options available for the module. You must press on Enable to activate it. Last configuration is for removing the module.

    Adding the module
     Configuring
    • Next step is to include Application Id and Secret previously generated. Got to General tab, and to Authentication. The existing authenticating method should be replaced in the selectbox, indicating that from now on, authentication based in Latch is added. 
    • The second selectbox only appears when Latch is installed, and indicates the method Latch uses for authentication. This method must be the one that was previously indicated in the selectbox above.
    • Press submit to end with module configuration. 
    • The module is now ready to be used. There will be a new tab Latch Configuration in user control panel. Go to Board index and then User Control Panel.

      Latch configuration for phpBB


      Descubriendo los activos de una organización (II)

      $
      0
      0
      Como se describía en la entrada anterior, uno de los puntos clave en una auditoria es la parte de descubrimiento. Se repasaron distintas técnicas de crawling, búsquedas en servidores DNS, uso de buscadores web y otros elementos para obtener un considerable número de activos. Cuantos más activos se analicen, mayor es la probabilidad de encontrar vulnerabilidades.

      Estas técnicas suponen un importante apoyo para conseguir activos o información referente a la organización representada en la web. Para decidir cuál es la más adecuada en cada momento, es necesario tener en cuenta que algunas dependen del lenguaje, del servidor, otras de la configuración implantada por los administradores, de la plataforma de desarrollo y los múltiples gestores de contenido... Para cada uno de estos niveles o circunstancias, surgen habitualmente nuevos métodos o técnicas que pueden ser aprovechadas.


      Algunos de los plugins en Faast

      Fuerza bruta

      Los ataques por diccionario se usan para descubrir archivos o directorios que no se encuentran referenciados en la propia web. Durante una auditoria resulta muy recomendable utilizar herramientas versátiles y con grandes diccionarios como DirBuster o WFuzz que aporten resultados que no han podido ser recuperados a través de otras vías.

      Las técnicas de fuerza bruta dinámica también se recomiendan para localizar copias de seguridad basadas en los activos ya encontrados. Por ejemplo, en ocasiones los editores de texto como EMACS o Vim generan ficheros temporales con extensiones que el servidor web no interpretará. De esta forma el servidor enviará el fichero en texto plano, como los ficheros con extensión .bak. Un ejemplo claro de descubrimiento de información sensible son los scripts de automatización que podrían realizar la copia de seguridad de un directorio y dejarlo comprimido en el mismo directorio o adyacentes.

      Así, apoyándose en la fuerza bruta, Faast es capaz de detectar elementos ocultos que genera el sistema operativo para retroalimentarse gracias a la información que aportan determinados ficheros sobre la estructura de archivos. Algunos de estos ejemplos son:

      • En Linux, de forma predeterminada, al usar el comando wget se genera el archivo .listing. En su interior se encuentra información sobre la ejecución del comando, con datos sobre el dónde se ha subido o dónde se han descargado determinados ficheros.
      • Por otro lado en sistemas operativos de Apple, es posible encontrar archivos .DS_Store, generados por Finder, donde se pueden extraer información sobre archivos similar a la que podría encontrarse en el archivo .listing.
      • En entornos Microsoft y en concreto en XP y 2003, no es extraño encontrar los archivos desktop.ini que almacenan opciones de personalización para el explorador de Windows y que puede contener rutas internas y nombres de usuarios.
      • En Windows también se generan archivos thumbs.db que almacenan miniaturas de imagen para ser previsualizadas por el explorador de Windows. 
      • Independientemente del sistema operativo, Faast también es capaz de detectar archivos ocultos generados por repositorios de código, como por ejemplo GIT, Mercurial o subversion. 

      Análisis de fuga de información

      Además de la recolección de activos, también es fundamental identificar el software del servidor que se está auditando. Faast implementa un fingerprint pasivo capaz de analizar e identificar qué tipo de servidor o gestor de contenido usa el sitio. Al forzar la aparición del error 404 o 500 en las aplicaciones web, se pueden recuperar rutas internas u otro tipo de información sensible, sobre todo cuando el servidor se encuentra en modo depuración (debug).

      Eror 404 en Apache

      Con respecto a la fuga de información, es importante aprovechar que los administradores hacen uso de las "buenas prácticas" para un mejor posicionamiento en los buscadores. Por ejemplo el uso de ficheros robots.txt y sitemap.xml que pueden dar pistas de rutas que contienen información sensible. Igual ocurre con el fichero humans.txt, que podría contener información sobre los desarrolladores, los lenguajes implementados o las herramientas usadas.

      La correcta combinación de técnicas de descubrimiento como el crawling, la fuerza bruta y la recolección de información filtrada en la posterior parte de análisis y explotación, serán las encargadas de retroalimentar el flujo y generarán cada vez más activos que deban ser auditados, multiplicando las posibilidades de una auditoría en la que se realmente se compruebe por completo la seguridad del servidor.

      * Descubriendo los activos de una organización (I)
      Óscar Sánchez
      oscar.sanchez@11paths.com

      News: Latch ya se encuentra en el repositorio oficial de WordPress

      $
      0
      0
      Latch dispone de diferentes plugins para poder integrarse en muchas infraestructuras de forma de que llegue al máximo número de usuarios posible. Uno de los entornos sobre los que se puede instalar es WordPress. Hasta hace poco solamente se podía acceder al plugin desde el repositorio GitHub oficial de ElevenPaths, pero ya se encuentra disponible en los repositorios oficiales de WordPress.

      Veamos el proceso de instalación para integrar en WordPress la funcionalidad de Latch. Se debe acceder con privilegios de administrador al sitio y buscar "latch" en el campo "Buscar" del apartado "Plugins".


      Buscando el plugin de Latch Los resultados se muestran a continuación, aunque pueden variar.

      Solo queda pulsar sobre "Instalar ahora". Automáticamente empezará el proceso de instalación. Una vez terminado se recibirá el mensaje "El plugin Latch 2.0 se ha instalado correctamente" y solo quedaría activar el plugin para tenerlo completamente disponible y funcional. Es posible verificar la correcta instalación del plugin accediendo al apartado "Gestionar".

      Configuración del plugin tras instalación

      El administrador del sitio debe obtener el "Application ID" y "Application Secret" desde los detalles de la aplicación creada en el sitio web de Latch. Con ellos, se debe acceder a la zona de configuración de WordPress, en la sección "Ajustes", donde se deben introducir estos datos y "Guardar cambios".

      Configurando el plugin de Latch


      Desinstalación

      Al igual que con la instalación, es necesario acceder como administrador del entorno WordPress. Para eliminar el plugin se debe acudir a la zona de administración, sección "Plugins" y "Plugins Instalados". Se mostrará la lista de plugins que ya se encuentran instalados en el entorno. Una vez aquí se debe marcar la casilla de "Latch" y hacer click sobre "Desactivar".

      Desactivando el plugin de Latch

      El resultado de la desactivación es la siguiente pantalla, en la que se debe marcar el plugin de Latch y posteriormente pulsar sobre la opción "Borrar".

      Aparecerá una confirmación: "Si, quiero borrar estos archivos y datos". Pero antes, es posible verificar cuáles van a ser los archivos que se van a borrar en el proceso de eliminación del plugin, pulsando en “Haz clic para ver toda la lista de archivos que se borrarán.

      Proceso de desinstalación

      Tras pulsar definitivamente sobre "Si, quiero borrar estos archivos y datos", se pude comprobar que el plugin de Latch se ha desinstalado completamente del sistema.

      Jhonattan Fiestas
      jhonattan.fiestas@11paths.com

      Antivirus falsos en Google Play y algunos trucos curiosos

      $
      0
      0
      Ya se sabe que desde hace algunas semanas, en Google Play se han colado un buen puñado de programas que dicen ser antivirus para ese sistema operativo. Aprovechando las noticias sobre malware y adware para Android, utilizan la imagen de antivirus para engañar o inducir al usuario a la compra de otros productos de diferentes maneras. Si hace tiempo ya se afirmó que los antivirus legítimos para Android "no servían para nada", vamos a ver en esta entrada las técnicas y los trucos más curiosos que utilizan supuestos antivirus que tampoco sirven para nada... pero ni siquiera lo intentan demasiado.


      En realidad, las apps de pago de este mismo developer corresponden a tarifas anuales, perpetuas, etc.

      A principios de 2013 un estudio afirmaba que los antivirus para Android no servían para nada. La afirmación se sustentaba en que, estudiado el funcionamiento de los antivirus legítimos para Android en ese momento, los resultados eran muy pobres. Lo cierto es que, lejos del sensacionalismo, los antivirus para Android no están en un momento maduro como en Windows, y sus sistemas de detección, en comparación son muy rudimentarios y básicos. Resulta muy sencillo eludirlos... pero es que también los antivirus para Windows pueden eludirse (con más trabajo, pero es práctica habitual).

      Desde el punto de vista del atacante, utilizar la imagen de un antivirus como sistema de infección para Android presenta varias ventajas. Los usuarios quizás tienen más predisposición a pagar por este producto. Además, no verán raro que un antivirus requiera muchos permisos para el teléfono. Al fin y al cabo, los necesita para proteger mejor al dispositivo.

      Las primeras muestras

      Kaspersky falso encontrado en Google Play
      En abril de 2014, se encontraba en Google Play una app llamada "Virus Shield". Decía ser un antivirus y, por cuatro dólares activaba en el sistema un sistema de protección. En realidad, solo cambiaba la forma de un icono.La estafa se encontraba en el pago de esos cuatro dólares. Llegó a encontrarse entre las cinco aplicaciones de pago más populares.

      Más tarde, los atacantes también subieron otro antivirus falso por 4 dólares, esta vez imitando a Kasperksy.

      A partir de ahí, el número de antivirus (o apps que dicen serlo) ha ido en aumento. Veamos los trucos más utilizados. La siguiente lista de técnicas no son más que curiosidades recopiladas de una muestra. Algunas técnicas son conocidas y otras nos han resultado interesantes. No pretende ser una recopilación exhaustiva, ni un análisis completo de cada app.

      Apps que ofrecen información sobre antivirus

      Estas apps parecen antivirus, pero no son más que punteros a páginas donde se habla de antivirus o enlaces a descargas. No son una estafa en sí, pero juegan con la potencial confusión del usuario. Su negocio consiste en la publicidad agresiva asociada a la app.


      Supuesto antivirus que no ofrece más que enlaces a otros, pero instala publicidad

      Apps gratis pero no

      Son apps que se ofrecen como versión "lite" o gratuita de alguna otra. En realidad, estos antivirus no contienen nada en su interior, más que un "puntero" a otra app del mismo desarrollador pero de pago, que probablemente tampoco cumpla su función.

      Otra modalidad es que el supuesto antivirus simplemente redirija a otra app cualquiera muy reconocida en el mundo del adware. A la derecha, toda la lógica del antivirus anunciado a la izquierda en la imagen. El enlace lleva a una supuesta app de limpieza, aunque puede variar.


      A la derecha, toda la lógica del antivirus que se anuncia como lo último en protección para Android. En realidad,  solo abre una ventana y redirige

      Comprobar permisos

      ¿Comprobar los permisos es ser un antivirus? Así lo hacen algunas aplicaciones, que asocian riesgo al uso de permisos de aplicaciones. Aunque se trate de una actividad completamente legítima, es cuando menos discutible el llamarse "antivirus" tal y como podría entenderse una herramienta con ese nombre. Por ejemplo, en la app analizada, en su código se observa que las apps con SEND_SMS se clasifican como de alto riesgo.

      Comprueba los permisos de los paquetes instalados y emite alertas según su propia clasificación


      Si el paquete contiene la palabra virus, es un virus

      Este antivirus falso, lo que hace es recorrer los paquetes instalados y buscar la cadena "virus" en los metadatos. Como se puede observar en el extracto de código mostrado en la imagen, esto lo hace la función isPackageExisted, a través de getPackageInfo. El flag 128 indica GET_META_DATA del nombre del paquete.


      Dos funciones diferentes. El "motor" arriba, y la lógica de detección abajo en isPackageExisted

      Si el paquete contiene la palabra "virus", con una lógica un poco extraña, el programa alertará de que ha encontrado malware en el teléfono. Por supuesto, esto incluiría a cualquier otro "antivirus".

      La detección aleatoria

      Este código de otro antivirus en Google Play habla por sí mismo. Tanto la detección de malware como la elección de la firma se producen de forma totalmente aleatoria. Eso sí, cada firma está asociada más abajo a un color más o menos intenso dependiendo de la gravedad del malware encontrado.

      La firma de lo que encuentra es elegida de forma aleatoria

      Tienes un virus que solo mi versión PRO puede eliminar 

      Esto es un clásico de los antivirus falsos para Windows. Se simula encontrar malware falso y se anima a comprar la versión pro. El nombre de la función habla por sí misma "addFakeVirus". Además, la condición es claramente "si la app no se ha pagado". En este caso se usa como reclamo Android.Lotoor.C, que es un exploit usado para "rotear" al teléfono y detectado con ese nombre por algunos motores.


      Rutina que encuentra malware falso si no se ha pagado

       Robo de otros antivirus y otras técnicas

      Otro supuesto antivirus realiza el registro de la app (que en realidad podría verse como un acceso ilegítimo a los datos) sin consentimiento explícito del usuario.

      Envío de datos a un servidor remoto

      Otras técnicas observadas durante este pequeño estudio han sido, por ejemplo el uso de librerías de apps legítimas para la inteligencia del motor. Este caso mostrado parece utilizar una librería de BitDefender.

      En la librería aparecen referencias al antivirus BitDefender

      Otras técnicas de antivirus que parecen legítimos son, cuando menos, curiosas. Esta app dispone de una base de datos colgada en un servidor (sin SSL) que no es más que un xml con unas 400 entradas.


      Sistema de firmas de un antivirus

      Luego utiliza esta lógica para detectar malware:

      Y su motor de detección...

      Es cierto que realiza otras acciones sobre el teléfono (bloquea llamadas, y vigila qué páginas se introducen en el historial), pero todo parece estar basado en una lista negra.

      RogueAntivirus: De Windows a Android

      Todas estas técnicas, y más, se detectan ya desde hace tiempo en escritorio. No son novedad en sí mismas. Quizás lo novedoso es observarlas en Google Play en tal cantidad y poder mostrar su código abiertamente, tal como lo han concebido los atacantes.

      Como regla general y en resumen, recordar que conviven relativamente pocas casas antivirus en el mercado. Y menos aún que dispongan de versiones para Android. Todas son marcas reconocidas en el mundo de la protección de escritorio. Cualquier otra debería descartarse. 


      Sergio de los Santos
      ssantos@11paths.com

      Miguel Ángel García
      miguelangel.garcia@11paths.com

      The weakest hand (on security)

      $
      0
      0
      Users have much more at stake in the digital world than ever before. Arguably as much or more, even, than our employers: our personal and professional reputations, livelihood, assets, family, friendships and homes. Yet, most of us use little more than an antivirus, desktop firewall, and whatever has been built into our routers and implemented for us by our local ISPs to safeguard all of this. Meanwhile, the businesses we work for have hired experts to monitor the organization, its systems, applications, and devices around the clock. They invest in layered defenses, analytics, forensics, intelligence and so forth. But, they do little to protect users when we leave the office.

      The weakest link

      Finding Nemo. Source: imdb.com
      Whether or not they realize it, organizations depend on us, also around the clock, to defend both personal and enterprise interests. Attackers can leverage vulnerabilities in our personal digital lives to get at our employers, and vice versa; and often, this is precisely what they do. Users are an easy mark. We are the weakest link, "the fish" as they say at the poker table susceptible to phishing, water-holing, and social engineering. We are error prone, willing to sacrifice security for productivity gains, often lazy, or resistant to security policy. To make matters worse, when we leave the office we haven’t got the resources our employers have; and so, we don’t take the precautions that might otherwise help our organizations minimize the risks associated with attacker-leap-frogging from the personal to the professional.

      Just as with businesses, the overall level of risk to which we, the fish, are exposed is increasing, and we ought to dedicate more care and awareness to safeguard our personal digital lives, the same way our employers do to protect their assets. But, we don’t (at least not the majority of us) and so long as we don’t do enough to protect ourselves we will continue to be fish.

      Long live the antivirus?

      There´s a paternalistic aspect to securing users and consumers that, though well intentioned, may ultimately have caused this problem. I am referring to the very global security policies and measures to which our organizations subject us. Take the antivirus as an example. The antivirus is practically ubiquitous in desktop systems of all large and medium enterprises, and its presence is enforced; sometimes even on visitors and contractors, through policy, and complex and expensive network admission control systems. Enterprises have been singing the praises of antivirus in this way, both explicitly and implicitly, even when "fake-av" aka "rogue antivirus" came along in 2008 to sound the death knell on the venerated, but tired bluff of recursive decompression, signatures, heuristics, and so forth.


      Virustotal statistics

      Enterprises and households could have saved themselves numerous headaches, by focusing their time and budgets on alternatives to the antivirus, years ago. At least since 2007, when studies began to demonstrate that the trusted software was only effective 20-30% of the time. Instead, we all soldiered on, long after the tool was rendered more or less useless. It survived, thanks in no small part to organizations that insisted on playing this losing game, throwing good money after bad on a losing hand. The thing is, antiviruses have become largely irrelevant to attackers, who now avail themselves of novel vectors of entry inaugurated by the mobile-cloud-social era in which we all live.

      But, let’s set aside the irrelevance of antiviruses, and their technical limitations. (Antivirus technology has always imposed significant system performance issues, the risk of false positives, and even an additional attack target due to its kernel level access). Their ineffectiveness is not just limited to the underlying technology, but also due to the lack of user involvement and understanding. How many users know, or even bother to tune the software to their system? How many are aware that it does not adequately address zero day threats, or most malware on websites, phishing, advanced malware and Trojans, and so on? Is it any wonder that users continue to download free and purchased antivirus software? Is it any wonder they think themselves secure once it’s installed?

      Recently, Symantec officially proclaimed the death of the antivirus through a Wall Street Journal interview. For large manufacturers antiviruses continue to generate a lot of revenue, but the business proposition is no longer acceptable. It is a saturated market, in which top firms compete against cost free alternatives, including Windows Essentials, fight to displace competitors for miniscule changes in enterprise B2B market share, and depend largely on renewals. For such companies the shift to a replacement technology could not have come soon enough. Enter sandboxing and automated malware analysis engines, which overcome many of the shortcomings of the antivirus, including performance and detection of advanced threats.

      Involve the user

      What such technology does not address, however, is the fundamental need to involve the user in securing their digital identity. Sandboxing may be a solid step forward in detection. But, it is also a toolset which promotes continued reliance on a hackneyed, cat-and-mouse updating model. Similar to antivirus technology, this new technical approach to defeating malware lulls users into the belief that they are supremely protected, even against zero day threats. Sandboxing combined with malware analysis may be big business. However, it may also be, that security technologies which do not engage and motivate users to take an active role in their own defense are of limited benefit.

      Excessive attention focused on new, advanced detection and mitigation technologies will likely result in the same blowback of unprepared, ignorant, and vulnerable user populations, as traditional antivirus. We are still "weakest link". Sandboxing doesn’t change that. But, times have changed; and like the skin of an expanding balloon our vulnerabilities are spreading out across an ever-widening attack surface: mobile, cloud and social. Systems, applications, and users are becoming increasingly difficult to secure; and global security policies and measures imposed across these surfaces are stretched thin.

      Perhaps it is not the technology, but our focus which must shift, from global policies, toolsets, and procedures, to one that leverages the user’s help. After all, we bring our own advanced, mobile computing devices to work; we subscribe to cloud based storage systems, and upload and share company documents; we use professional and personal social networks, and leverage them to the benefit of ourselves and our employers, spin up new systems and servers, for trials, training and our own curiosity. It doesn’t require much imagination to see how our public and private lives have never been so intricately interwoven.

      Data Leakage Worldwide: Common Risks and Mistakes Employees Make
      Source: http://www.cisco.com/c/en/us/solutions/collateral/enterprise-networks/data-loss-prevention/white_paper_c11-499060.html

      A quick review of some statistics show this intermingling is likely to deepen, that there are business incentives it to happen, as well as significant business risks. According to Citrix, organizations predict that the percentage of BYO desktops and laptops will grow from 18-25%; Gartner says that by 2017, 50% of businesses will not supply employee computing devices; Deloitte adds that 69% of polled companies experience no technical support problems after implementing BYOD; despite the finding by Acronis that 80% of businesses do not provide education or training on BYOD.  In a 2012 survey, commissioned by Check Point, of 768 IT professionals in the US, Canada, UK, Germany and Japan 78% said there were more than twice as many personal devices connecting to corporate networks than there were two years before; and 47% reported that customer data was stored on mobile devices; 90% of which, according to Forbes, are used for email, calendar, shopping, banking and social.

      Source: http://dreamscashtrue.com
      The new digital polis in which we live involves a combination of the private with the public, the personal with the professional, and requires organizations to change their perspective on securing systems, applications, users and other assets. This new view opens unprecedented opportunities to engage with us users (whether we are employees, partners or consumers). Organizations can become protagonists in our active involvement both within and without the workplace to secure ourselves, and thereby protect the enterprise. Currently, few security solutions help in this way. Most strive to do precisely the opposite: to minimize users’ roles in the security process. Rather than encouraging us to secure ourselves, these solutions lead us into taking foolish risks, shortcuts, and workarounds, making erroneous judgments and mistakes. In sum, we end up behaving like the weakest player at the poker table, the mark for all of our adversaries, the fish who, no matter what, always has the weakest hand.

      Christopher Adelman 
      christopher.adelman@11paths.com

      Orientando el pentesting hacia un ataque APT: Correos electrónicos

      $
      0
      0
      La seguridad de las empresas depende de muchos factores y ya se sabe que el eslabón más débil suele ser no tanto el servidor como el usuario. Con este enfoque, el pentesting debería evolucionar y llegar a combinar el proceso de intrusión "habitual" con la información recopilada sobre los usuarios. ¿Por qué no añadir a un proceso de hacking ético pruebas que simularían un ataque del tipo APT, (Advanced Persistent Threat) contra el objetivo con la idea de retroalimentar las dos vertientes del proceso? El resultado podría ser mucho más provechoso.

      Un test de intrusión "tradicional", ofrece la posibilidad de realizar ataques controlados a sistemas expuestos, pero lo cierto es que si un atacante real quiere vulnerar una organización, quizá el camino más corto consista en el ataque a los empleados. Y para que este camino más corto sea aún más efectivo, debe recopilar información sobre ellos, obteniendo una visión global que aumente las posibilidades de éxito. Así, el concepto de pentest se expande, ya no solo a todo lo que se exponga en la red, sino además a la necesidad de concienciar y poner controles para que los datos "filtrados" sobre empleados no estropeen la inversión en seguridad.

      Cuando en un proceso de hacking ético se han realizado pruebas de pentesting externo a la organización, los resultados han podido ser utilizados para pruebas de APT o ingeniería social y viceversa. En realidad, ambos procesos se encuentran unidos de alguna manera y no deberían ser tomados como independientes. Un atacante no lo hará en el mundo real.

      Un APT es un concepto complejo que puede que se haya desvirtuado, pero en general, es un conjunto de ataques informáticos que suceden de una manera continua sobre una persona o un conjunto de personas de interés. El fin es conseguir la información de valor de las que esta persona o conjunto de personas disponen por sí mismas o en su entorno. Existen tres vertientes en un APT:
      • Es un proceso avanzado. Aunque no siempre se utilizan técnicas avanzadas para lograr los objetivos, en muchas ocasiones se necesitan varios desencadenantes o condiciones para que el ataque tenga éxito.
      • Es un proceso persistente. Se hace un seguimiento del objetivo, intentando monitorizar acciones, clasificar comportamientos en el mundo digital, incluso fuera de él, y realizando un profiling de la persona.
      • Es un proceso basado en las amenazas del mundo digital. Un usuario está expuesto a más amenazas cada día y los empleados de una organización no son una excepción.
      Atendiendo a esta definición, el resultado de un pentesting podría considerarse como una entrada muy útil para un proceso de ataque tipo ATP: metadatos, tipos de software que se utiliza en una organización, correos electrónicos de usuarios, correos electrónicos personales, direcciones IP, números de teléfono, etcétera... Por sí solos pueden no suponer un gran descubrimiento para el informe de un test de intrusión, pero es información valiosa para potenciar un APT.

      Ejemplos del mundo real

      En un pentest clásico, es habitual conseguir cuentas de correo para aplicar fuerza bruta o ataques de diccionario contra un servicio. Esta prueba suele hacerse usando un diccionario de contraseñas no seguras, para asegurar que no se protegen las cuentas con contraseñas débiles. Para conseguir correos electrónicos en Internet se pueden utilizar diversos medios: el primero son buscadores como Google, Bing o Exalead. Para facilitar la tarea existen varias herramientas como TheHarvester o Maltego.

      Ejemplo de salida de TheHarvester

      Aunque en la imagen no se pueda visualizar se han obtenido más de 30 resultados. Esta puede ser una buena manera de comenzar con la recolección de cuentas de usuario. Pero es que, además, esta es información muy valiosa para un profiling de empresa orientándolo a un ataque del tipo APT.

      Otra de las vías para la recolección de correos electrónicos y cuentas de usuario es la búsqueda a través de los servidores de claves PGP. Esta plataforma proporciona mucha información interesante para poder utilizar y personalizar a los usuarios. Por ejemplo, realizando una simple búsqueda por dominio se obtiene lo siguiente:

      Ejemplo de información sobre claves PGP

      Donde se concluyen varios datos interesantes:
      • El usuario y el correo electrónico.
      • El nombre completo de la persona. En este caso, el nombre será real la mayoría de las veces, puesto que un usuario configura su clave pública con su nombre verdadero para que pueda ser encontrado en estos servidores.
      • Puesto de trabajo en la organización. Algunos usuarios así lo hacen.
      • Correo alternativo. En algunas ocasiones los usuarios utilizan la misma clave PGP para varios correos, por lo que será posible encontrar cuentas genéricas de Gmail, Hotmail, o el ISP contratado. Esto permitirá relacionar a una persona entre su correo profesional y su correo personal. De ahí se puede saltar hacia las redes sociales y otros entornos de interés. 
      Si se elige una búsqueda avanzada en un servidor de claves, es posible extraer más información aun. Por ejemplo, obtener información sobre si la clave está revocada o si la confirman otros usuarios. Este es un punto interesante: conocer con quién se relaciona una persona es importante puesto que, para la preparación de un ataque más sofisticado del tipo APT, permite disponer de diferentes caminos alternativos para poder llegar al objetivo final.

      Ejemplo de "círculo de confianza" en claves PGP

      En Eleven Paths estamos realizando un plugin para obtener este tipo de información en nuestra herramienta de pentesting persistente Faast. El objetivo es que nuestra visión global de la seguridad de una organización no se quede simplemente en el estado de los servicios expuestos, malas configuraciones, vulnerabilidades en aplicaciones, etcétera. Nuestra idea es ofrecer un informe de todo lo que puede afectar a una organización además de los elementos que un atacante pueda utilizar para dañar la imagen de una empresa. El ejemplo expuesto, centrado en el correo electrónico, es una muestra de cómo ampliar el campo de acción de un pentest y enriquecerlo con datos personales "descuidados" en la red.

      Plugin de Faast

      En la imagen se puede visualizar un ejemplo de salida de nuestro plugin en desarrollo. Nuestro sistema Faast pronto proporcionará esta información, pero lo más importante es que Faast es capaz de brindar más información utilizable en estos procesos. En las pruebas que vamos realizando en entornos controlados se encuentran nombres de personas, DNI, usuarios, software asociados a máquinas de ciertos usuarios, sistemas operativos, etcétera. Esta información resulta muy valiosa como punto de partida para un ataque de tipo un APT.

      Pablo González
      pablo.gonzalez@11paths.com

      Proteger servidores OpenSSH y OpenVPN (también con Latch) (I)

      $
      0
      0
      Latch nació de la idea de evitar que posibles atacantes pudieran acceder a nuestros servicios aunque dispusieran de las credenciales de inicio de sesión. De esta forma, es posible controlar cuándo se puede acceder a los diferentes servicios como banca online, correo electrónico, redes sociales y blogs incluso si un atacante conociera la contraseña.¿En qué mejora Latch la seguridad de servicios con OpenSSH y OpenVPN? En esta entrada se cuenta la experiencia de cómo se protegen los servidores OpenSSH y por qué Latch podría resultar útil.

      Protegiendo OpenSSH

      OpenSSH es el servidor SSH más utilizado en el mundo. Proporciona acceso a través de terminal un equipo para administrarlo de forma remota y segura. Además permite hacer "SSH Tunneling" para cifrar cualquier protocolo desde el equipo cliente hasta el servidor.

      Al trabajar con OpenSSH, algunas opciones fundamentales de seguridad para proteger el servidor pasan por: elegir la versión dos del protocolo, cambiar el puerto por defecto, deshabilitar el login como "root" del sistema, crear una lista blanca con sólo determinados usuarios, elegir un número máximo de autenticaciones antes de desconectar la sesión y reducir el tiempo de introducción de la contraseña...

      Por ejemplo, para reducir el número de intentos de conexión se debe usar el módulo recent del cortafuegos iptables. Con esta característica, es posible bloquear los intentos de conexión desde una determinada IP que ha intentado conectarse varias veces de forma fallida. Una mejora de seguridad muy importante es autenticarse a través de una pareja de claves RSA. Cuando se obliga a autenticar a los usuarios mediante RSA, el acceso estará protegido contra ataques de diccionario o fuerza bruta.

      Sin embargo, todas estas medidas de seguridad se vienen abajo si, por algún motivo, un atacante conoce las credenciales o tiene en su poder la clave RSA. No es difícil imaginar un escenario en el que el usuario pierde las contraseñas, o un dispositivo donde se almacenan las claves privadas. Hasta ahora, una posible solución a este problema pasaba por el conocido "port knocking". Gracias al "golpeo de puertos" podríamos abrir el cortafuegos a los accesos SSH a través de una determinada secuencia preestablecida de intentos de conexión a puertos. Aunque eficaz, en la práctica es bastante incómodo puesto que se debe utilizar knock para golpear los puertos y que se abra el utilizado por SSH, después utilizar el servicio SSH, y por último realizar otro golpeo para dejarlo en su estado original. Otros puntos débiles de "port knocking" es "recordar" la secuencia de puertos a utilizar. Acceder desde un terminal móvil al servidor SSH, podría resultar poco práctico.

      ¿Qué ofrece Latch?

      Mensaje de bloqueo cuando se intenta acceder con el pestillo cerrado
      Una solución para añadir seguridad en servidores SSH es Latch.roporciona una forma elegante de solucionar los accesos no legítimos a un servidor. Esta herramienta simplifica al máximo el intento de evitar que un atacante con las credenciales pueda acceder al servicio protegido. Con el "pestillo" digital cerrado, aunque un atacante conozca nuestras credenciales, no podrá acceder. Además, es posible pedir de forma obligatoria una clave de un solo uso (One Time Password) cada vez que se acceda. De esta forma el atacante no solo tendrá que conocer o tener en su poder las credenciales, sino que también tendrá que conocer la clave generada aleatoriamente por Latch para iniciar sesión.

      La instalación y configuración de Latch para OpenSSH es muy sencilla, ni siquiera se debe modificar el archivo de configuración de OpenSSH. Cuando un usuario intenta entrar en el servicio con el "pestillo" cerrado, se enviará un aviso al terminal móvil indicando que alguien ha intentado acceder. Además, desde el panel de control de Latch se podrá comprobar el intento de intrusión. Otra característica con la que cuenta este panel de control es la posibilidad de ver el número de claves OTP que se han generado para acceder al servicio.

      Panel de administrador desde donde se pueden controlar los intentos de acceso


      La facilidad con la que se puede bloquear y desbloquear el servicio es realmente simple: basta con arrastrar un interruptor disponible en la app para cerrar el servicio. Todo ello con una instalación rápida y fácil. Latch se ha convertido en una herramienta fundamental para proteger los accesos a servidores en Redes Zone, sin necesidad de configuraciones complejas con iptables y además con un uso muy intuitivo.

      Sergio de Luz
      sergio.deluz@redeszone.net

      Para qué sirve el Attack Surface Reduction en EMET

      $
      0
      0
      Durante 2013, fue necesario "detener" la locura de exploits y problemas de seguridad que aparecían en el plugin Java que utilizan la mayoría de los navegadores. Casi todos acabaron desactivándolo por defecto. Pero Java no es el único culpable de las vulnerabilidades a través del navegador. EMET incorpora ahora una interesante funcionalidad llamada Attack Surface Reduction (ASR) que puede suponer una importante mejora para la seguridad de, no solo Internet Explorer en particular, sino de cualquier programa en general.

      El origen de la idea

      Hoy por hoy, el problema con los exploits no se encuentra tanto en los navegadores como en los plugins que utilizan. Suelen ser los culpables de los graves problemas de ejecución de código arbitrario con solo visitar una web. Es cierto que cada cierto tiempo, se encuentran nuevas vulnerabilidades que permiten ejecutar código en el sistema por culpa del navegador en sí, pero incluso para llegar a esta fase, deben eludir ciertas medidas de seguridad. Y para eludirlas se apoyan en los plugins. Por ejemplo, para conseguir eludir ASLR es común utilizar librerías de plugins comunes (Flash, por ejemplo) para "orientarse" en memoria y ejecutar un exploit de forma eficaz en el sistema. O a veces, ocurre que se actualiza el navegador, pero no los plugins asociados. La exposición del usuario sigue existiendo entonces.

      Pero, por mucho que se aconseje su desactivación, no se puede pretender vivir sin algunos plugins. Las páginas legítimas los necesitan. Así que es necesario utilizar herramientas que permitan crear listas blancas o negras. Y ni aun así se estaría bien protegido. Algún atacante podría perpetrar ataques de tipo watering hole, esperando intentar explotar una vulnerabilidad en una web de uso habitual pero comprometida.

      ¿Pero no se podía ya evitar los plugins desde las zonas de internet Explorer? No era fácil. En varias ocasiones se demostró que las opciones que parecían lógicas para evitar la ejecución de Java en el navegador, no conseguían de verdad deshabilitarlo en todas las circunstancias.

      También estaban los kill bits... pero eran difíciles de activar, y no dejaban de estar pensados como sistemas de mitigación. Aunque en los últimos tiempos, muchas de las actualizaciones de seguridad de Microsoft se dedicaban activamente a activar los kill bits de plugins para el navegador permanentemente.

      Sentadas estas bases, aparece Attack Surface Reduction en EMET para intentar evitar que cualquier programa sea capaz de cargar cualquier plugin, desde sus fundamentos: impidiendo las llamadas a librerías DLL.

      EMET al rescate

      Attack Surface Reduction es una nueva funcionalidad de EMET, introducida en su versión 5. Si EMET comenzó como un proyecto para detener los "trucos" usados por atacantes para hacer que funcionasen los exploits, (bloquear los intentos de eludir DEP, ASLR, y otros métodos comunes de explotación) desde hace algún tiempo ha crecido en funcionalidad y potencia:

      • Ya es también una herramienta de certificate pinning para Internet Explorer
      • Es además un sistema de bloqueo selectivo de plugins y DLLs para programas... aunque todavía le queda mucho que mejorar, esto es el ASR. 

        Cómo funciona

        Visualmente, se debe marcar la opción en el panel de EMET para un programa concreto. Hay que pensar en ASR como un sistema que impide que un proceso cargue ciertas DLL, OCX o cualquier complemento, lo que pueda dar más juego del que en principio se piensa.


        En esta pantalla se le indica a EMET que vigile un proceso con ASR


        Luego será necesario ir al registro, y configurar a mano los módulos que se quieren bloquear. La organización habitual de EMET consiste en asignar un CLSID aleatorio a una aplicación. Dentro de ella, la rama contendrá la configuración específica. Se encuentra en HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\EMET\_settings_\. Ahí se creará una rama con el nombre del programa y su CLSID. Más arriba (por encontrarse en orden alfabético) se podrá comprobar que existe otra rama con ese mismo CLSID y la configuración correspondiente al programa en su interior. Por ejemplo la de Internet Explorer será:

        Configuración interna de ASR para Internet Explorer en EMET

        Ahí se encuentran la cadena "ASR" (con valor 1 si se ha activado en el panel gráfico de EMET) y "asr_modules". Esta puede contener, separados por ";", los módulos que no se quieren cargar cuando se ejecute el programa. EMET ya viene configurado de forma predeterminada con la opción de impedir que Internet Explorer cargue npjpi*.dll, jp2iexp.dll, vgx.dll y flash*.ocx. Pero solo en las zonas 1, y 2, que se corresponden con Local (0), Intranet (1), Sitios de confianza (2), Internet (3), Sitios no confiables (4). O sea, el valor "asr_modules" mantiene una lista de librerías que están prohibidas para ese proceso, mientras que para Internet Explorer, existe el valor "asr_zones" que marca las excepciones según las zonas. Es mejor ver la imagen para entenderlo. Las librerías prohibidas de forma predeterminada son:

        • npjpi*.dll y jp2iexp.dll: Relacionadas con Java. 
        • vgx.dll: El procesador de gráficos de vectores VML
        • flash*.ocx: Flash.

        Así, la configuración por defecto permitiría estas tres tecnologías en las zonas de confianza e internet y las bloquearía en el resto. Sería posible eliminar o añadir tecnologías bloqueadas y hacerlo más granular añadiendo dominios a las zonas tradicionales.

        Para Office (o cualquier otro programa), es más sencillo aún, porque no se ofrece el concepto de zonas de bloqueo ("asr_zones"). Así, por ejemplo solo se indica que a Word se le prohíbe cargar Flash en su interior (con "asr_modules"). Esta es la configuración por defecto:

        Configuración interna de ASR para Word en EMET


        Cuando el navegador intente activar una web con  un plugin (Flash en el ejemplo) que cae sobre la zona correspondiente y bloqueada, aparecerá un mensaje de este tipo en EMET.


        Pero esto puede llevarse a cabo con cualquier programa. Lo que abre la posibilidad de bloquear selectivamente la carga de DLLs en cualquier proceso. 


        Sergio de los Santos
        ssantos@11paths.com
        @ssantosv

        La seguridad en los métodos HTTP

        $
        0
        0
        Según describe el estándar HTTP 1.1, existen 28 métodos (o verbos) para la comunicación mediante el protocolo HTTP. Aunque muchos son desconocidos para la mayoría de usuarios (y administradores de sistemas) por no ser de uso habitual, existe un riesgo potencial si el administrador del servidor web no los tiene controlados. Veamos algunas técnicas comunes.

        Entre los métodos más comunes, definidos en el RFC 2616, se encuentran:

        • GET: El método más común en la navegación web. Devuelve un código de respuesta y las cabeceras asociadas. Incluye el documento solicitado (habitualmente una página) en el cuerpo del mensaje.
        • HEAD: Idéntico al anterior, con la salvedad de que no devuelve el documento en el cuerpo de la respuesta. Se utiliza para extraer información sobre el documento solicitado o comprobar si existe sin necesidad de enviar y recibir el documento como tal.
        • POST: Pensado para publicar la información contenida en el cuerpo de la petición en el recurso donde se envía esa petición. La información que se publica y la forma de hacerlo depende completamente del servidor y el recurso. Hoy, el uso que se le da a este método es el de paso de parámetros de cliente a servidor (en muchas ocasiones para ficheros). La respuesta por parte del servidor es la misma que para una petición GET.
        • TRACE: Implementa la función de eco para los mensajes HTTP. El servidor responde en el cuerpo del mensaje con la misma petición que el cliente ha realizado. Se utiliza para comprobar que las peticiones son recibidas correctamente. Su finalidad es la de depuración.
        • OPTIONS: Este método presenta las opciones que el recurso o servidor dispone o requiere. De esto se puede obtener información como por ejemplo los métodos permitidos (en la cabecera ALLOW). 
        • CONNECT: Utilizado para crear la comunicación con un proxy HTTP (SSL).
        • PUT: Mediante este método es posible almacenar el documento que se envía como cuerpo de la petición en el propio servidor (físicamente en disco). Si el recurso al que se hace referencia en la petición no existe se creará y si existe se sobrescribirá.
        • DELETE: Al igual que el método PUT, este verbo afecta directamente al recurso al que se hace la petición. Tiene la capacidad de eliminar el elemento y dejar al servidor sin ese recurso. 

        El resto de verbos (menos usados) son PROPFIND, PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK (RFC 2518), VERSION-CONTROL, REPORT, CHECKOUT, CHECKIN, UNCHECKOUT, MKWORKSPACE, UPDATE, LABEL, MERGE, BASELINE-CONTROL, MKACTIVITY (RFC 3253), ORDERPATCH (RFC 3648) y ACL (RFC 3744).

        PUT y DELETE

        A primera vista, dos de estos métodos pueden resultar críticos en el entorno web donde se encuentren habilitados. Tanto PUT como DELETE permiten interactuar directamente con recursos legítimos del sistema El primero para crearlos (por ejemplo una web shell para controlar el servidor, o fichero modificado para conseguir desfigurar alguna web legítima) y el segundo para eliminar archivos o activos de, por ejemplo, una compañía. Encontrarse este tipo de configuración en servidores en producción no es demasiado común, pero aun hoy no es extraño localizarlos. Para demostrarlo, basta con hacer consultas avanzadas sobre los motores de búsqueda, o basarse en las respuestas a las peticiones OPTIONS.

        Ejemplo de petición y respuesta OPTIONS usando el complemento RestClient de Firefox

        Este método devuelve información del servidor, pero esta información no tiene que ser ni completa, ni veraz. En ocasiones se mostrará una cabecera ALLOW con métodos HTTP permitidos, lo que no quiere decir que estos métodos estén implementados. Es decir, a pesar de que el verbo OPTIONS indique que se admite un método concreto, al utilizar este método es muy posible que retorne un código de error, ya sea de no implementado (501), no encontrado (404), etcétera.


        Ejemplo de volcado del paquete de petición y respuesta con verbo OPTIONS

        Y en otras ocasiones ocurrirá lo contrario, la cabecera ALLOW de la petición OPTIONS no mostrará métodos que realmente están permitidos e implementados... aunque luego es posible su ejecución. En resumen, no se deben descartar los métodos que no reflejados en esa cabecera.

        TRACE y ataques XST

        Además de PUT y DELETE (peligrosos si no se tienen completamente controlados) no hay que olvidar el método TRACE, en principio "inofensivo".

        Ejemplo de volcado del paquete de envío y respuesta con verbo TRACE

        Como ya se observa en la imagen, este método devuelve como cuerpo las cabeceras de la petición del cliente, incluyendo la cabecera Cookie que (según entornos) puede resultar crítica si existe una sesión establecida con el servidor. La combinación de este verbo HTTP con un fallo "Cross Site Scripting" en la aplicación web puede acabar en un robo de sesión de usuario, incluso si las Cookies han sido establecidas como HttpOnly. Este ataque es conocido como "Cross Site Tracing" o XST.

        El ataque consiste en, cuando se inyecta código JavaScript explotando la vulnerabilidad XSS, realizar una petición con el método TRACE al propio servidor y enviar el cuerpo de esta respuesta al propio atacante por la vía que sea más cómoda. El contenido devuelto incluirá la cabecera Cookie con sus valores, tenga el flag que tenga. Un ejemplo de código JavaScript que es posible inyectar se muestra en la imagen siguiente, aunque en vez de enviar la respuesta a un servidor propiedad del atacante, se muestra en un mensaje "alert" como prueba de concepto.


        Ejemplo de código JavaScript para inyectar y explotar un fallo XST


        Aunque lo cierto es que hoy los navegadores más modernos ya bloquean este tipo de peticiones para evitar específicamente este ataque. Pero tampoco hay que olvidar que existen otras alternativas a JavaScript para realizar peticiones TRACE como Flash, Applets Java, etcétera. Con ellos se puede llegar a conseguir el mismo resultado eludiendo los bloqueos del navegador.

        Desde el punto de vista del servidor, la manera obvia de evitar estos problemas es, cómo no, reducir la superficie de ataque deshabilitando aquellos métodos que no sean útiles para el entorno concreto, y controlar exhaustivamente los que sí se estén utilizando. Faast, el servicio de pentesting persistente, monitoriza este tipo de configuraciones en los servidores web y analiza cualquier método HTTP inseguro que pueda estar habilitado o implementado.

        Ioseba Palop
        ioseba.palop@11paths.com

        Proteger servidores OpenSSH y OpenVPN (también con Latch) (y II)

        $
        0
        0
        OpenVPN es el software multiplataforma que permite crear redes privadas virtuales y punto a punto de forma remota y segura. Imiplementar una buena seguridad en OpenVPN es fundamental para evitar accesos no deseados, debido a que se utiliza principalmente en entornos profesionales para acceder desde cualquier punto a la red corporativa, el control de un atacante podría resultar fatal.

        Algunas recomendaciones para asegurar un servidor OpenVPN pasan por:

        • Crear claves criptográficamente robustas. Para ello es importante usar los algoritmos más recientes de cifrado. Para establecer TLSv1.2 (sólo en versiones OpenVPN a partir de 2.3.3) se debe utilizar la siguiente directiva en el archivo de configuración: 
        Tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384
        Gracias a esta directiva, el servidor utilizará Diffie-Hellmann Ephemeral, de tal forma que si en algún momento un atacante captura la clave privada, las comunicaciones anteriores no podrán descifrarse por usar Perfect Forward Secrecy. También se utilizan las claves RSA para la autenticación, un cifrado simétrico robusto como AES-256 en modo GCM y un algoritmo de hash como SHA2.

        • Incorporar TLS-AUTH para que todos los paquetes que no posean la firma HMAC se bloqueen. Esta característica proporciona un nivel de seguridad adicional a la que proporciona TLSv1.2 porque mitiga posibles ataques DoS. El mecanismo consiste en cerrar la comunicación sin esperar a comprobar los certificados y así la carga de CPU es mucho menor.

        • Algunas recomendaciones adicionales de seguridad pasan por autenticar a cada cliente OpenVPN contra la PAM del servidor al que se conecta, utilizando su usuario y contraseña de acceso al sistema. 

        Pero una vez más, estas medidas de seguridad se ven empañadas si un atacante consigue credenciales de acceso. Latch soluciona este problema de forma elegante. Permite controlar permanentemente los accesos al servidor OpenVPN, avisando de los intentos de acceso cuando el "pestillo" digital está cerrado. La instalación y configuración de Latch con OpenVPN es realmente fácil.

        La única modificación necesaria en el servidor OpenVPN es habilitar la autenticación PAM (si no lo está ya) añadiendo la siguiente línea al archivo de configuración (ejemplo para Ubuntu 14.04 LTS):

        plugin /usr/lib/openvpn/openvpn-plugin-auth-pam.so openvpn

        Al intentar iniciar una conexión con el Latch cerrado, se generará el siguiente log en el servidor:

        Logs de OpenVPN con Latch

        Con el correspondiente aviso de la aplicación advirtiendo que se ha intentado acceder con el "pestillo" cerrado.

        El proceso de instalación de Latch en este tipo de servidores es realmente rápida y sencilla, puesto que el proceso se encuentra perfectamente documentado. El uso de esta herramienta es recomendable tanto para los usuarios que se conectan al servidor como para los administradores que podrán proteger sus accesos de forma sencilla.

        Conclusiones

        Hace un tiempo perdí el smartphone, con todas las claves privadas en su interior. Quien encontrase el terminal podría haberlas extraído y usarlos para conectarse al servidor. La primera medida que tomé fue acceder vía SSH para detener el servidor OpenVPN, porque en ese momento no disponía ni de las herramientas ni del tiempo necesario para revocar los certificados. De esta forma evité que el potencial atacante se pudiera conectar, pero aun así hubo un tiempo de exposición que supuso un riesgo. Si Latch hubiera existido entonces, la ventana de exposición y por tanto el problema hubiera sido menor (o incluso nulo), puesto que el "pestillo" habría estado cerrado y aunque tuviera los certificados no podría haberse conectado.

        Aunque Latch por sí solo no proporcione mayor seguridad, sí permitirá tener todos los accesos bajo control. Desde el punto de vista del usuario, le será útil para disfrutar de una mayor seguridad en banca o en el correo electrónico, pero para los administradores de sistemas podría suponer un elemento fundamental en entornos donde un acceso no autorizado tendría graves consecuencias.

        Proteger servidores OpenSSH y OpenVPN (también con Latch) (I)

        Sergio de Luz
        sergio.deluz@redeszone.net

        El negocio de las "FakeApps" y el malware en Google Play (IX): ¿Qué hacen y cómo se programan las apps?

        $
        0
        0
        Durante este estudio de las apps falsas que simulan ser otras más populares, hemos hablado de varios aspectos relativos a este negocio. Sin embargo, ¿qué ocurre exactamente cuando un usuario se instala una de estas apps? ¿Cómo crean tantas y tan rápido los atacantes? Veamos qué hacen y cómo lo hacen.


        Las apps falsas "puras", que simulan ser algún otro juego popular, suelen pesar poco (entre 200 y 500 kbs) y estar destinadas directamente a la publicidad invasiva. Pueden realizar varias funciones en el dispositivo de su "víctima", entre otras:
        • Como se ha mencionado, y la razón de todo esto, es bombardear al usuario con ventanas emergentes, banners y todo tipo de publicidad, hasta el punto de que (si los programas se inician con el teléfono) sea complicado utilizar el dispositivo.


              Ejemplo de publicidad superpuesta a cualquier otra app
            • Obligar al usuario a valorar otras aplicaciones (normalmente también falsas) con 5 estrellas. Así consiguen dar veracidad a otras apps que han subido previamente, y pueden mejorar su ingeniería social. Normalmente avisan que hasta que no se vote, no se puede jugar. Este es el modelo clásico y permite posicionar bien la app en el market, al tiempo que "invalida" en cierta forma este método de reputación.

              Ejemplo de Minecraft falso que solo busca que se le
              puntúe con 5 estrellas y mostrar publicidad


            • Obligar al usuario a descargar otras aplicaciones falsas o modificadas. También aumenta así el número de descargas. Igualmente, esto hace que el usuario que confíe en el número de descargas como parámetro de la popularidad o fiabilidad de un programa, pueda equivocar su evaluación. Como regla general, hay que tener en cuenta que el número de descargas no significa nada en números relativamente pequeños.

              Ejemplo típico de app que instala markets alternativos, y busca una descarga y una puntuación

            • Modificar el market o instalar nuevos markets. Las búsquedas de apps se realizan así sobre otro servidor de descarga, donde no se ejerce ningún control de la calidad de las apps.


              Ejemplo de anuncio de market alternativo

              ¿Pero las apps falsas contienen juegos o no?

              Muchos no son más que el adware o malware en sí, pero otros sí que contienen alguna función. Durante 2012 y 2013, sí fue muy habitual el "reempaquetamiento" de apps y juegos a los que se añadía "funcionalidades extra". Sin embargo esto ya no es tan habitual debido a los controles actuales de Google Play. 

              Pero no por eso existen "FakeApps" que no contengan funcionalidad. Aunque esto emparenta con actividades completamente legítimas, también lo aprovechan los creadores de adware y malware en Google Play. Son las llamadas "plantillas" para juegos y utilidades, que se comercializan y subastan. Han favorecido la aparición de empresas que gestionan este intercambio y que permiten que, sin saber programar una sola línea, sea posible crear apps populares (incluso para otras plataformas diferentes a Android). Empresas como Binpress, Apptopia, Chupamobile, CodeCanyon o españolas como Mobincube ofrecen maneras de crear y personalizar apps con solo pulsar algunos botones. Las "plantillas" proporcionan la funcionalidad básica. Por ejemplo, del juego de moda del momento. Son compañías y actividades completamente legítimas, pero cuyos servicios son aprovechados por atacantes.

              La razón es que en realidad, en el mundo móvil los juegos o apps de moda suelen ser muy parecidas en su funcionalidad. Lo único que suele cambiar es el diseño. Por tanto, los "motores" (puzles, fondos de pantalla, plataformas, cortadores de fruta, estilo flappy birds...) pueden reutilizarse. Se añaden algunos gráficos propios, y ya se dispone de un juego que se puede monetizar partiendo de una mínima inversión en dinero y tiempo. También ocurre con pequeñas funcionalidades como linternas, bromas, frases... que tanto abundan en Google Play.


              Venta legítima de plantillas para aplicaciones para Android


              Algunas de estas compañías, dejan preparada la app para introducir la publicidad configurada directamente y así generar beneficio al autor. De esta forma, el programador (o atacante, en el caso de que introduzca adware demasiado agresivo o malware) solo debe entender la "tendencia" de descarga del momento que existe en Google Play, que fundamentalmente se basa en:
              • Conocer los juegos o funcionalidades de moda, que suele coincidir con las palabras clave que le proporcionarán descargas.
              • Estar al tanto de apps muy codiciadas que vayan a aparecer de manera inminente en Google Play, y simular que se trata de esa app para cazar a los usuarios que la buscan activamente incluso cuando no se encuentra oficialmente disponible para esa plataforma.

              Empresa de creación de apps de forma sencilla

              Con esta información, el creador de adware solo tendrá que adquirir la plantilla correspondiente, incrustar su publicidad, y subirla a Google Play. Normalmente Google Play lo retirará después de algunos días (o no), pero lo más probable es que el negocio le sea rentable durante el tiempo que se mantenga online.

              El negocio de las "FakeApps" y el malware en Google Play (I): Introducción 
              El negocio de las "FakeApps" y el malware en Google Play (II): Tipos de "fakes"
              El negocio de las "FakeApps" y el malware en Google Play (III): Estrategias
              El negocio de las "FakeApps" y el malware en Google Play (IV): Política y rentabilidad
              El negocio de las "FakeApps" y el malware en Google Play (V): Limpieza automática
              El negocio de las "FakeApps" y el malware en Google Play (VI): Limpieza "manual"
              El negocio de las "FakeApps" y el malware en Google Play (VII): Cómo llegan a las víctimas
              El negocio de las "FakeApps" y el malware en Google Play (VIII): Permisos en las apps

              Sergio de los Santos
              ssantos@11paths.com

              News: New versions and features in Latch apps

              $
              0
              0
              Facing the summer and holidays for most of you, in Eleven Paths we have created a new important update for Latch app, We have a new version for Android, iOS and Windows Phone, with several improvements and new features.

              In this post we're going to specify the most important new features and improvements you can get with the new app for Android, iOS, and Windows Phone, so you can keep protecting services more effectively and easily.

              Main improvements

              The most flashy improvement for the user updating to the newer version is this new big sliding element that we call here in the office "latchón" as in "big latch". This slider replaces the "Lock Everithing" button in the previous version.

              "Latchón" in Android


              Another new thing is that when a service is locked with this element, every operation existing below will be locked too. But besides, they will be disabled from the app, so you can't modify the status of any of them.

              Locking all the paired services when "Latchon"
              is activated.

              Locking internal operations when activating the
              big Latch of a service
              Unlocking the big latch keeps the latest status of any service or operation. The usual slide buttons (that we call "little latches" or "latchitos") now come with text indicating the service status ("LOCK" for locked and "UNLOCK" for unlocked), these texts are translated into Spanish, English, Portuguese and German.
              "Latchito" of a locked service

              A new intermediate screen when generating the pairing token

              Now, when generating a new token, a new intermediate screen appears from where you may access the guide explaining the pairing process or directly generate the token. This offers time for the user to click on the exact form field in the website where the token is being required.

              Step before generating the pairing token


              Scheduled lock and autolock


              Now it's easier to schedule a lock. In previous versions it was done with a clock shaped button next to the lock and unlock buttons. This resulted confusing for some users. Now it's configured from a separate "Schedule lock" field and Latch will automatically set the status depending on the configured time span.

              Besides, "Scheduled lock" and "Autolock" are now self-exclusive to avoid confusion between the status of a service or operation at a given time. When one is set, the other is disabled.
              "Scheduled lock" set and "Autolock" disabled

              Another new feature is that the services or operations with a "Scheduled lock" will show a clock shaped icon inside their "latchitos" (little latches).
              A little clock in the latch indicates a "Scheduled lock"


              The autolock time is now global for all services or operations, and is set from the "Settings" menu.

              Notifications about unlocking parent operations


              When unlocking an operation from a notification, if this operation is locked because a lock is set in a "parent" operation, a message indicating the operations that will be unlocked will be received too.

              This is because if a lock is set for a service, all the elements below will be locked too. Thanks to this feature the user may choose if he wants to unlock or not the operation and will be informed about the services or operations that will be unlocked too.
              Notification about unlocking parent operations
              Improvements on devices

              Beside theses common features, Android and Windows Phone have integrated some improvements:
              • For Android the app is now optimized for MDPI resolution. 
              • Latch for Windows Phone is the one that has been modified the most. Now, notifications are received when upairing services, and may be configured to be received when accessing an unlocked service. Another improvement: if the service provider modifies the status of the service, the app will show an orange notification. Windows Phone 8.1 is now supported.
              Resources



                News: Nuevas versiones y características en las apps de Latch

                $
                0
                0
                De cara al verano y las vacaciones para muchos, en Eleven Paths hemos querido que los usuarios de Latch, dispongan de una significativa actualización de la app para Latch. Se ha creado una nueva versión para Android, iOS y Windows Phone, con diversas mejoras y novedades respecto a la anterior.

                En esta entrada vamos a indicar las principales novedades y mejoras incorporadas en la app de Android, iOs, y Windows Phone, orientadas a seguir protegiendo los servicios de los usuarios con eficacia y mayor comodidad.

                Novedades generales

                La novedad más llamativa para el usuario que actualice su versión es la incorporación de un elemento deslizable que nosotros coloquialmente hemos llamamos "latchón". Este elemento viene a sustituir al botón "Bloquear todo", que existía en la versión anterior.

                "Latchón" en un dispositivo Android

                Otra novedad es que cuando se bloquea un servicio o una operación con este elemento, todas las operaciones que existan por debajo quedan bloqueadas. Pero además quedan deshabilitadas desde la app, de tal forma que no se pueda modificar el estado de ninguna de ellas.

                Bloqueo de todos los servicios pareados al activar el "Latchón"
                y servicios deshabilitados

                Bloqueo de operaciones internas al activar el "Latchón"
                de un servicio

                El desbloqueo del "latchon" mantiene el estado anterior de cada servicio u operación. Los botones de tipo interruptor (a los que coloquialmente llamamos "latchitos") ahora incorporan un texto indicando el estado del servicio ("BLOQ." para bloqueado y "DESBLOQ." para desbloqueado), estos mismos textos con su correspondiente traducción se indican en los cuatro idiomas de la app (español, inglés, portugués y alemán).
                "Latchito" de un servicio bloqueado


                Pantalla intermedia al generar el pareado

                Ahora, cuando se quiere generar el pareado, aparece una pantalla intermedia desde la que se puede acceder al manual de explicación acerca del pareado o se puede pulsar el botón que genera el código directamente. Esto ofrece un tiempo al usuario para posicionarse en la sección exacta de la página web o consola donde le están pidiendo este código.

                Pantalla previa a la generación de un código de pareado

                Bloqueo programado y autobloqueo

                Ahora es más fácil establecer un "Bloqueo programado". En la anterior versión se hacía con un botón con forma de reloj junto a los botones de bloqueado y desbloqueado. Esto confundía a algunos usuarios. Ahora simplemente hay que configurarlo desde el apartado "Programar bloqueo", y Latch automáticamente establecerá el estado actual del servicio según el horario indicado.

                Además el "Bloqueo programado" y el "Autobloqueo" son ahora autoexcluyentes para evitar cualquier confusión sobre el estado de un servicio u operación en un momento determinado. Cuando se establece uno, el otro queda deshabilitado.

                "Bloqueo programado" establecido y "Autobloqueo" deshabilitado

                Otra novedad es que los servicios u operaciones que tengan un "Bloqueo programado", mostrarán un icono con forma de reloj en su "latchito".

                Reloj en el "latchito" indicando que se ha establecido un "Bloqueo programado"

                El tiempo de "Autobloqueo" ahora es global para todos los servicios u operaciones, y se establece desde el menú de "Configuración".

                Aviso de desbloqueos de operaciones padre

                Al realizar un desbloqueo de una operación desde una notificación, si esta operación está bloqueada porque se ha establecido un bloqueo en una operación superior o padre, se recibirá un aviso indicando el listado de operaciones que se desbloquearán también.

                Esto es debido a que si se ha establecido un bloqueo en una operación o servicio todos los elementos que estén por debajo estarán a su vez bloqueados. Gracias a esta opción el usuario puede elegir si desea o no desbloquear la operación y estará informado de los servicios u operaciones que se desbloquearán a su vez.


                Aviso de desbloqueo de operaciones padre

                Mejoras en los dispositivos

                Además de estas múltiples mejoras, Android y Windows Phone han incorporado algunas mejoras propias:
                • En Android ahora la app está optimizada para dispositivos de densidad media (mdpi). 
                • La versión de Latch en dispositivos Windows Phone ha sido la que más modificaciones ha incorporado. Entre otras, ahora se reciben notificaciones cuando se desparean servicios, y se pueden configurar para recibirlas cuando se accede a un servicio desbloqueado. Otra mejora es que si el proveedor del servicio realiza una modificación en el estado del servicio, se mostrará en la app con un llamativo color naranja. Además de todo esto ahora incorpora soporte para Windows Phone 8.1.

                Recursos




                  Errores de configuración y malas prácticas: PHP Info

                  $
                  0
                  0
                  Cada día se configuran cientos de servicios, se actualizan y quedan expuestos a olvidos y fallos de configuración. La tecnología PHP se encuentra muy distribuida en Internet y la configuración de manera desatendida o por defecto puede provocar que se exponga más información de la se desea. En esta entrada nos centramos en las características de la función de "phpinfo" y cómo aprovecharlas para obtener el máximo beneficio.

                  Con simples búsquedas en Google y mediante parámetros avanzados se podrían encontrar gran cantidad de archivos del tipo phpinfo.php. En la imagen se puede observar cómo quedan al alcance de la mano alrededor de 22.500 resultados. Muchos de ellos serán archivos de este tipo.


                  Archivos phpinfo disponibles públicamente

                  ¿Por qué estos resultados son importantes en un pentesting? La primera fase del pentest es el descubrimiento o "discovery". Es importante conocer el objetivo marcado todo lo que se pueda. Internet es un lugar donde buena parte de lo que se haga, configure y publique queda expuesto y por esta razón, recopilar y conocer todos los detalles de lo que dispone de una organización es fundamental para progresar en el pentest.

                  ¿Es posible obtener información jugosa? La cierto es que sí. A continuación vamos a enumerar los elementos de interés que es posible obtener de estos archivos:
                  • Usuarios del sistema.
                  • Rutas internas que ayuden a conocer cómo se estructura el sistema de archivos y qué aplicaciones se ejecutan. Siguiendo un ejemplo real sobre el que se han realizado pruebas, en el caso del servidor de correo si se analiza la directiva sendmail_path es posible deducir que se realiza a través de la ruta C:\xampp\mailtodisk\mailtodisk.exe. Las rutas internas provocan fugas de información que puede ayudar al pentester a modelar su siguiente paso.
                  • Direcciones de correo. Este documento puede aportar información sobre correos. Evidentemente no es la mejor vía en un pentesting para encontrar correos electrónicos pues para ello tenemos otras vías como son las de The harvester, Maltego o el propio Faast. pero sí puede resultar complementaria.
                  • Módulos habilitados que posibiliten otros ataques. Esto es una característica que un pentester debe observar a conciencia. Este tipo de descubrimientos puede hacer que un pequeño descuido en la configuración de un servidor acabe convirtiéndose en el punto de inflexión por el que se accedió a datos relevantes de la organización.
                  • El sistema operativo y versión que corre la máquina. Esto es importante para saber rápidamente si existen vulnerabilidades que puedan comprometer la seguridad del servidor.
                  • Versiones de aplicaciones y servicios. La información que se puede obtener con este archivo es importante. Por ejemplo en las siguientes imágenes podemos comprobar que existe un MySQL en el puerto 3306 (detalle que podíamos conocer también con un nmap sin demasiado esfuerzo); que la versión de OpenSSL es posible que sea vulnerable a HeartBleed (CVE-2014-0160); o que la versión de Python es la 2.7.

                  Ejemplo de información extraíble en un archivo phpinfo

                  En el caso de las directivas comentadas anteriormente, podemos concluir también que, por ejemplo, si safe_mode está deshabilitado se podría realizar la ejecución de comandos desde un archivo php. Por otro lado la directiva display_errors en modo "on" significa que los mensajes de error de php se volcarían para cualquier usuario, por lo que el pentester buscaría provocar fallos en busca de "leaks". Existen diversas directivas que, por ejemplo, son analizadas por Faast en busca de estos fallos, una vez descubierto un archivo PHP info. Un pequeño error en la configuración puede abrir cientos de puertas o vectores de ataque a un pentester.

                  Utilizando el servicio Faast y haciendo pruebas sobre demofaast se obtuvo la siguiente evidencia:

                  Ejemplo de conversación HTTP

                  Se puede ver una petición al servidor, una respuesta y parte del contenido que es la evidencia de que estamos ante un PHP Info que provocará la fuga de información. Además, la herramienta se nutre de toda la información para seguir explorando las posibilidades que este tipo de fuga ha provocado.

                  Como curiosidad, recordar que Faast, además de detectar este archivo y "destriparlo" para avanzar en la investigación,  permite alertar sobre cualquier otro fichero sospechoso que pueda suponer un peligro para el servidor, como pueden ser la mayoría de shells documentadas que, por sus características, resultan identificables.

                  Pablo González
                  pablo.gonzalez@11paths.com

                  Ocho siglas relacionadas con las vulnerabilidades (V): CVRF

                  $
                  0
                  0
                  Evidentemente, uno de los factores críticos sobre el que gira el mundo de la seguridad es el estudio y control de vulnerabilidades. Organizaciones como MITRE, FIRST e ICASI se encargan de gestionar y estandarizar este importante aspecto. Otra de las iniciativas de estas organizaciones para cubrir este ámbito es CVRF o Common Vulnerability Reporting Framework.

                  Estas siglas pertenecen a ICASI (The Industry Consortium for Advancement of Security on the Internet), una organización sin ánimo de lucro que intenta solucionar desafíos de seguridad, con la finalidad de proteger mejor las infraestructuras que ofrecen servicios a empresas, gobiernos y ciudadanos de todo el mundo. En concreto, el formato CVRF intenta afrontar el problema que surge a la hora de comunicar vulnerabilidades tanto entre profesionales de diferentes compañías como entre sistemas automáticos.¿Qué información debe contener la descripción de una vulnerabilidad? ¿Qué campos se deben comunicar? ¿En qué formato? CVRF es la fórmula estándar para resolver estas cuestiones.

                  CVRF se trata de un lenguaje basado en XML que permite compartir información crítica relacionada con la seguridad en un formato único, permitiendo así un rápido intercambio y gestión de la información. En realidad este lenguaje no solo es utilizado para compartir información relacionada con las vulnerabilidades, sino que también ha sido desarrollado para poder transmitir cualquier tipo de información concerniente a la seguridad. Su primera versión fue publicada en mayo de 2011, sin embargo, la versión actual es la 1.1 y fue creada en mayo de 2012.

                  La siguiente imagen resume esquemáticamente cuánta información puede contener y comunicarse con este lenguaje, a la vez que desvela cómo se organizan los datos. Se cubren los aspectos más importantes relacionados con temas de seguridad y requerimientos a la hora de difundir esta información.

                  Mapa lógico del formato CVRF 1.1

                  La siguiente leyenda es necesaria para comprender los distintos elementos y atributos contenidos en este lenguaje.

                  Leyenda para comprender el mapa lógico de CVRF


                  Dentro del lenguaje, en caso de que sea aplicable, se incluyen algunas de las iniciativas del MITRE como lo son CVE, CWE y CPE (Common Platform Enumeration), que permiten afinar la información y estandarizar todo lo posible los diferentes campos que definen una vulnerabilidad.

                  En la actualidad, el CVE ha adoptado el formato CVFR para publicar el contenido de la información registrada en cada una de sus entradas. Con esto, el CVRF permite que la información sobre vulnerabilidades pueda ser compartida en un formato estandarizado, y que además sea fácilmente interpretado por sistemas o herramientas de proveedores y consumidores.

                  Compañías como Red Hat, Microsoft, Cisco Systems u Oracle utilizan este lenguaje propuesto tanto con sus consumidores como con otros proveedores de información (como es el caso del CVE). A su vez, el CVE alimenta con esta información distintas bases de datos de vulnerabilidades que son constantemente utilizadas por muchas de las herramientas de diagnóstico de vulnerabilidades. Algunas de estas bases de datos que colaboran con la difusión de la información relacionada con las vulnerabilidades son OSVDB, NVD o CVE Details. Por tanto, la difusión de la información con estándares de este tipo garantiza una homogeneidad en los datos mostrados sin importar la fuente y disponer de fuentes tan completas como sea posible.

                  Las listas de CVEs correspondientes a cada año se pueden descargar en este formato desde la web de oficial de CVE. En su contenido puede verse la estructura de este lenguaje basado en XML donde cada CVE contiene una serie de propiedades y cada una de ellas contiene la información correspondiente a la vulnerabilidad.

                  Lista CVRF del año 2012


                  * Ocho siglas relacionadas con las vulnerabilidades (I): CVE
                  Ocho siglas relacionadas con las vulnerabilidades (II): CWE y CAPEC
                  Ocho siglas relacionadas con las vulnerabilidades (III): CVSS
                  Ocho siglas relacionadas con las vulnerabilidades (IV): CWSS
                  Umberto Schiavo
                  umberto.schiavo@11paths.com

                  Havex no es el nuevo Stuxnet (y la falta de profesionalidad)

                  $
                  0
                  0
                  Desde que Stuxnet apareció (hace ya cuatro años) parece que se espera un sucesor. Al menos en el campo del espionaje industrial y ámbitos SCADA. Desde entonces, se han descubierto varios "hijos", "primos" y familiares en general, pero ninguno parecía estar a la altura. Havex tampoco, ni mucho menos. De hecho, a pesar de los titulares, no tiene mucho que ver.

                  Havex suena en los medios porque se ha descubierto atacando a sistemas industriales. Lo cierto es que Havex no es nuevo. Se trata de una herramienta de control remoto (RAT) genérica que quizás se esté usando desde 2011. Crowdstrike lleva ya tiempo asociando esta herramienta a ataques a grandes empresas energéticas europeas (una buena parte en España).

                  Este gráfico es de 2013, en realidad, cuando Havex fue usado para otros fines
                  Lo que ha ocurrido ahora es que el interés de esos atacantes parece haberse centrado en compañías industriales y sistemas SCADA, adaptando su "herramienta" a las nuevas necesidades.

                  Infraestructura y finalidad

                  Usaron sistemas legítimos comprometidos como C&C (servidores de control para el troyano). No es la mejor manera de conseguirlo puesto que vuelve "frágil" la infraestructura. Comprometer servidores de terceros eleva las posibilidades de que los legítimos dueños puedan recuperar el acceso a sus servidores (con la información robada en ellos) o que los atacantes lo pierdan en cualquier momento. Bastante poco profesional por parte de los atacantes.

                  En el código, se observan funciones específicas para obtener y recolectar información concreta de sistemas SCADA, además de la capacidad habitual de tomar el control de los sistemas infectados.

                  Métodos de infección

                  Esta es la parte interesante. Al parecer usaron métodos tradicionales de infección (exploits o correos) junto con ataques de tipo "watering-hole" más que curiosos.

                  Comprometieron al menos tres empresas, todas ellas involucradas en el negocio de sistemas industriales. Estas compañías (con sede en Suiza, Bélgica y Alemania) proporcionaban software y sistemas de control remoto para sistemas ICS, cámaras de alta precisión, etc., y permitían la descarga (como muchas otras) de drivers, instaladores y software. Los atacantes tuvieron acceso a estos repositorios (al parecer por fallos en su infraestructura web) y alteraron los programas legítimos para instalar un "troyano" a la vieja usanza, donde el programa troyanizado funciona correctamente pero permite también el control remoto a los atacantes entre bambalinas.

                  ¿Quién descargaría y usaría ese software? Solo técnicos específicos de sistemas industriales. Así que el objetivo era muy específico para los atacantes. Uno de los archivos detectados en este ataque fue enviado a Virustotal en marzo. Ningún motor lo detectaba por firmas. El resto de DLLs utilizadas, no habían sido enviadas antes del 23 de junio de 2014, pero tampoco eran detectadas ese día. En pocas horas, la mayoría de los antivirus eran ya capaces de detectarla.

                  Tanto los proveedores de software como los que lo consumían, han cometido una serie de errores graves durante el proceso de infección.

                  • Las páginas que proporcionan estos sistemas industriales han sido comprometidas y sus programas sustituidos sin que sus legítimos dueños lo hayan advertido a tiempo. Los errores de estas empresas, tanto reactivos como preventivos, son innumerables. No se han dado los nombres concretos de las compañías, pero no resulta muy difícil poder reducir el círculo de candidatas.
                  • Los operarios o administradores han descargado este software y no han comprobado las firmas o integridad (si es que las compañías firmaban todo su software u ofrecían algún método de comprobación). Esto es quizás lo más preocupante. En entornos de este tipo, instalar un programa debe ser un proceso compuesto por varias fases, aunque haya sido descargado de una página oficial. En concreto comprobar firmas e integridad debería ser obligatorio en el procedimiento. También la ejecución en sandboxes que desvelen el comportamiento exacto del programa antes de pasar a producción. Por ejemplo, esta línea en un sistema de debug hubiera podido delatar el comportamiento anómalo.

                  Ejecución de una DLL en un programa legítimo de control SCADA. Fuente: F-Secure

                  • Los sistemas en producción disponían de conexión directa a internet. Se deduce porque, tras instalar los componentes troyanizados, el malware concreto era descargado y actualizado sin contratiempos. Además de enviar la información robada. Parece que los sistemas industriales afectados no contaban con listas blancas de conexión a internet, IDS o cortafuegos... en definitiva, las nociones básicas de seguridad. 

                  No es Stuxnet

                  Los medios de comunicación tampoco se han mostrado muy certeros con esta comparación. Stuxnet estaba específicamente diseñado para atacar el producto SCADA WinCC de Siemens. Y hasta aquí las similitudes. Esta variedad de Havex, aunque con un objetivo claro, no parecía estar tan específicamente programada. Stuxnet contenía vulnerabilidades completamente desconocidas, operaba de forma mucho más inteligente, utilizaba certificados válidos... era una verdadera arma muy pensada y diseñada con un objetivo concreto (parece que las centrales nucleares iraníes).

                  Nadie duda de que esta operación con Havex se considere un ataque relevante, pero Stuxnet fue mucho más allá, y se podría decir que fue diseñada por un equipo muy potente y poderoso que desarrollaron su "producto" durante años. Con Havex lo que se ha realizado es un ataque concreto a sistemas SCADA, pero no se ha diseñado específicamente un arma contra ellos. Aunque resulte preocupante y haya causado en una infección alta, se queda casi en la anécdota si lo comparamos con Stuxnet, al menos por ahora sin más datos.

                  Las infecciones han sido variadas, sobre todo en Europa. Se diría que Havex ha infectado a compañías más modestas, aunque no por ello pequeñas. Por tanto no caben demasiadas comparaciones. Pero sí sirve para recordar, una vez más, que para realizar una campaña de infección medianamente eficaz a muchos sistemas críticos, quizás no haga falta una inversión tan alta.

                  Sergio de los Santos
                  ssantos@11paths.com

                  News: Eleven Paths Security Day el 3 de julio. Plugin de Latch para Windows y más

                  $
                  0
                  0
                  Los ataques cometidos por los usuarios internos son una amenaza significativa para las redes y datos de una organización. A la hora de desarrollar políticas y procedimientos de seguridad es importante tener en cuenta los potenciales atacantes internos que disfrutan de privilegios suficientes como para convertir en crítica cualquier brecha de seguridad. El 3 de julio Eleven Paths mostrará una evolución de sus productos para intentar mitigar estos problemas.

                  Una de las demandas más reiteradas sobre Latch, ha sido poder controlar las cuentas de los sistemas operativos, para evitar que alguien pudiera entrar en el sistema aun conociendo la contraseña. El próximo día 3 de julio tendrá lugar el evento "Escenarios de seguridad contra atacantes internos con Latch", orientado a mostrar cómo dotar a los sistemas de las redes locales de la protección de Latch.

                  Eleven Paths Security day 2014

                  Se mostrarán varios escenarios en los que Latch puede ayudar a proteger las redes internas, además de hablar de Faast y la importancia de encontrar fallos en tiempo real. La agenda del evento detallada es la siguiente:
                  • 11:45 - 12:00. Acreditación.
                  • 12:00 - 12:45. Asegúrate de quién usa las contraseñas de tus empleados en entornos Windows, Mac y Linux, por Chema Alonso, CEO de Eleven Paths.
                  • 12:45 - 13:15. Cómo proteger el uso de certificados en la empresa con Latch, por Rames Sarwat, de SmartAccess
                  • 13:15 - 13:45. Fallos de seguridad en tiempo real, por Pablo González, Faast Project Manager de Eleven Paths.
                  Después habrá un cóctel y un almuerzo. Se celebrará en el auditorio del centro de demostraciones de Telefónca, en la sede central de la Ronda de las Comunicaciones. Es necesario el registro previo en: https://securityday.elevenpaths.com/

                  Protección de autenticación en entornos corporativos

                  Una de las funcionalidades más esperadas que se presentarán será la integración de Latch con Windows, que ahora está disponible para dos entornos diferentes:
                  • El plugin de Latch para Windows (Enterprise Edition) permite proteger toda la infraestructura de autenticación de Microsoft Windows en entornos centralizados desde un controlador de dominio. Este plugin no requiere instalación de software en los equipos de usuario. Los usuarios podrán parearse a través de un entorno web que proporciona Latch, que puede integrarse en una intranet o usar de manera independiente. Latch se distribuye con un instalador que realiza de forma automática y simple toda la configuración, integrándose con los principales sistemas operativos de servidor Microsoft Windows Server 2003, 2008, 2012 (32 y 64 bits).
                  • El plugin de Latch para Windows (Personal Edition) permite proteger el inicio de sesión local en estaciones de trabajo independientes. Es compatible con Microsoft Windows XP, Vista, 7, 8 y 8.1 (32 y 64 bits).
                  Las licencias del plugin de Latch para Windows (Enterprise Edition) se pueden adquirir como un complemento a su suscripción actual de Latch. El plugin de Latch para Windows (Personal Edition) es gratuito.

                  También existe Latch para entornos OS X, Linux y otros UNIX. Latch protege cualquier servicio del sistema que soporte PAM de forma totalmente configurable, y permite un control de las operaciones del sistema operativo. Además de proteger el inicio de sesión, también posibilita la protección de operaciones que puedan realizarse a través de estos sistemas, como el acceso por SSH, el acceso por consola, accesos por entornos gráficos, comandos de administración como "sudo" o "su", etc. Los usuarios podrán parearse por medio de una utilidad en modo gráfico o por línea de comandos.

                  El plugin de Latch para OS X permite la integración en las versiones recientes de OS X. El plugin de Latch para Linux permite la integración en cualquier distribución de Linux que integre los módulos de PAM para cualquier operación de autenticación y autorización (Debian, Ubuntu, RedHat, CentOS, Fedora, etc.), así como versiones actuales de otros UNIX como FreeBSD y OpenBSD.

                  El problema de los "Server Side Includes" en un servidor web

                  $
                  0
                  0

                  SSI es el acrónimo de "Server Side Include" y se trata de un mecanismo (en desuso) que permite a un servidor web añadir contenido dinámico a los documentos que sirve. Actualmente encontrar sitios que hagan uso de ésta característica no es muy habitual y los pocos que lo hacen es probablemente como consecuencia de herencias de antiguos desarrollos. Sin embargo, en ocasiones es posible encontrar sitios que todavía lo implementen, por lo que aún puede resultar interesante saber cómo funciona.

                  Este es un ejemplo simple y práctico de en qué consistiría una inclusión de otro fichero mediante SSI. Por ejemplo, la inclusión se realizaría mediante este código:

                  Inclusión del fichero content.txt mediante SSI


                  Lo que parece un comentario HTML se trata sin embargo de una directiva de "Server Side Include". El servidor la reemplazará por el contenido del fichero "content.txt" y se enviará al cliente una respuesta final como la mostrada en la siguiente captura de pantalla.

                  Respuesta del servidor web

                  La configuración

                  Para hacer uso de la característica de ‘Server Side Include’ en un servidor web, es necesario configurarlo adecuadamente además de introducir una directiva SSI en el documento que se vaya a visualizar. La configuración para los dos servidores web más utilizados (Apache e Internet Information Services), es tan sencilla como añadir la siguiente directiva al fichero de configuración de Apache o en un fichero .htaccess.

                  Options +Includes

                  En IIS, sin embargo, es necesario activar la característica localizada en "Internet Information Services > World Wide Web Services > Application Development Features > Server-Side Includes".

                  Configuración de SSI en IIS

                  Una vez activada la característica, es necesario habilitar el manejador del módulo desde "Handler Mappings > Add Module Mapping".

                  Configuración de SSI en IIS

                  Las directivas

                  Una vez habilitado, únicamente será necesario introducir en el documento a servir una directiva que sea reconocida por el servidor web. No existe un estándar en cuanto a éstas directivas, por lo que cada servidor web implementa las que considera oportunas. Esto genera grandes diferencias y matices a la hora de implementar directivas entre los distintos servidores web. En estas páginas se puede encontrar la documentación oficial de las directivas permitidas en Apache e IIS.

                  Una de las directivas más interesantes es "exec". Permite la ejecución de comandos en el servidor. Una sintaxis correcta para esta directiva podría ser la siguiente,

                  < !-- #exec cmd="dir" -- >

                  Sin embargo, al tratarse "exec" de una directiva potencialmente peligrosa (debido a que ejecuta comandos directamente en el servidor) viene deshabilitada de forma predeterminada, por lo que es necesario realizar unas configuraciones extra para su ejecución.

                  El problema 

                  Otra característica curiosa en cuanto a los "Server Side Includes" es que, en determinados entornos, son procesados después del resto de manejadores. Supongamos que disponemos de un servidor web que tiene instalado el módulo de PHP y además tiene habilitado los "Server Side Includes". Si el flujo de ejecución de una petición pasa primero por el motor de PHP y posteriormente por el de SSI, nos encontramos potencialmente ante un fallo de seguridad.


                  En resumen, si un usuario pudiese alterar la salida generada por el módulo de PHP, esta salida se convertiría en la entrada directa del módulo de SSI. De este modo, si un usuario es capaz de generar en la salida de ejecución de PHP algo que contenga una directiva SSI, esta sería la entrada directa para el módulo de ‘Server Side Include’ y por lo tanto se podrían "crear directivas" al vuelo gracias a PHP.

                  Con una representación gráfica muy simplificada, este sería el flujo con entradas y salidas de ejecución de los manejadores, así como la salida final la cual es enviada al cliente final.
                  Flujo de ejecución

                  El vector de explotación contra la arquitectura se basa fundamentalmente en las capas inferiores que son ejecutadas antes que el SSI. Por ejemplo, en el esquema mostrado con PHP, se perseguiría que el módulo de PHP muestre una directiva SSI en su salida. Esto puede conseguirse por ejemplo mediante ataques de "Cross Site Scripting" (XSS). A continuación se muestra un ejemplo de esta vulnerabilidad encontrada mediante el servicio de pentesting persistente Faast.


                  Explotando una vulnerabilidad SSI

                  El proceso de detección en este ejemplo consiste en la creación de una variable llamada "faastvar" con la cadena "FA$ST" como contenido. Posteriormente ésta variable es mostrada mediante otra directiva "echo".


                  Directiva SSI inyectada por Faast

                  En resumen, es recomendable no utilizar la característica de "Server Side Includes" debido a los posibles fallos de seguridad que puede acarrear, además de existir infinidad de alternativas mucho más modernas.

                  Manuel Fernández 
                  manuel.fernandez@11paths.com

                  Cómo y cuándo se ataca a Microsoft: análisis de vulnerabilidades

                  $
                  0
                  0
                  Microsoft ha publicado un par de artículos muy interesantes en su blog de seguridad, donde se desgrana qué tipo de fallos de seguridad son los más atacados y cuándo se ha descubierto un exploit para ellos. Pretenden dejar claro que han mejorado (y es cierto), pero veamos algunos detalles que no mencionan y reflexiones derivadas de la evolución mostrada en los últimos años.

                  Lo primero, ha sido estudiar las causas de las vulnerabilidades más graves (las de ejecución de código) en su software desde 2006 a 2013. Según la raíz del problema, la vulnerabilidad será más o menos difícil de explotar por un atacante, aunque todas concluyan con la posibilidad de controlar del sistema. Es un estudio interesante porque:

                  • Se centra en vulnerabilidades graves y explotables. Nada de números camuflados entre las "no explotables" o la gravedad.
                  • No se compara más que con sus propios productos.
                  • Las vulnerabilidades estudiadas no se encuentran contaminadas por el comportamiento del usuario. En este caso no importa qué haga ni qué ejecute (tan solo un poco qué visite, quizás, pero no parece relevante).

                  El estudio se resume en esta gráfica.

                  Causa de las vulnerabilidades de ejecución de código en Microsoft desde 2006

                  Lo primero que se observa es un descenso pronunciado de los desbordamientos de pila clásicos. Estas son las más sencillas de explotar por un atacante... y detectar por el equipo de programación. Es cierto, Microsoft ha librado una lucha contra este tipo de fallo y al pensar en la seguridad desde el diseño, ha prohibido el uso de técnicas de programación que puedan derivar en este tipo de desbordamiento y de librerías de C que se sabían inseguras. Incluso incorporan un "banned.h" para que el compilador avise directamente. Parece que da resultado...

                  Pero nada desaparece sin que lo sustituya otra técnica, puesto que los niveles de explotación se mantienen. Use-after-free es un fallo más complejo de detectar programando, y por eso Microsoft no puede detenerlo tan fácilmente. Si los atacantes no encuentran desbordamientos de pila, acuden a este fallo de manejo de objetos que puede derivar en ejecución de código. Además, da la "casualidad" de que este tipo de vulnerabilidades se encuentra más en los programas "cliente" y en concreto en el navegador, que es el tótem preferido por los exploiters: ejecución de código en IE implica tener el control del cliente con solo visitar una web.

                  Los exploits que evitaban la carga de DLL desde otras rutas fue una moda desde que se detectó el método, pero era fácil de corregir y dos años después ya casi no se encuentran programas que lo lo permitan (al principio la lista fue interminable, tanto de Microsoft como de otros). El desbordamiento de heap, más difícil de detectar en tiempo de programación (y de explotar), se mantiene invariable en estos años.

                  ¿Han descendido las vulnerabilidades?

                  Una de los métodos que tiene Microsoft para luchar contra las vulnerabilidades de ejecución de código son DEP y ASLR, introducidos en Vista en 2006. Son las armas implementadas de forma predeterminada para amedrentar a los exploiters. Pero no tanto. La aparición de ROP, las fugas de direcciones de memoria, o el uso de librerías que no son compatibles con ASLR ha permitido a los atacantes seguir sacando provecho de estas vulnerabilidades. Pero aunque el el statu quo se ha mantenido, "huyendo" a otros tipos de vulnerabilidad o con la aparición de métodos nuevos... parece que según Microsoft, el número de vulnerabilidades de ejecución de código explotadas ha descendido un 70% en los últimos tres años en el software de la compañía. Este gráfico así lo muestra:

                  ¿Cuándo se ha detectado un exploit para una vulnerabilidad de ejecución de código en Microsoft?
                  Esta imagen explica que, de las 20 vulnerabilidades que fueron explotadas en 2013 en sus productos, 13 se descubrieron siendo explotadas en forma de 0-day. 6 vulnerabilidades se descubrieron siendo explotadas durante los 30 días siguientes al anuncio del fallo, y solo una más tarde. Y, aunque en Microsoft destaquen sus bondades y la interpretación de estadísticas y barras se preste a todo tipo de argucias argumentales, este gráfico es muy curioso por varias razones. Algunas que consideramos relevantes.

                  ¿Qué se deduce del gráfico?

                  • En los titulares, Microsoft habla de la caída de vulnerabilidades desde 2010, pero no de la subida desorbitada hasta ese año, ni sus razones. ¿Por qué esa explosión de un año a otro? En 2010, con IE8 y Windows ya en el mercado, el número de vulnerabilidades se dispara... fue un año convulso en Microsoft, y también para los atacantes. La creación de exploits les costó más esfuerzo (muchos más se crearon dentro de los 30 días posteriores al anuncio de la vulnerabilidad). Quizás sea porque estaban naciendo las nuevas técnicas para eludir DEP y ASLR, ya implantados con Windows 7, que se introducía en el mercado en ese momento y al que necesitaban llegar los atacantes. O también cabe otra teoría. ¿Puede ser que muchas de esas vulnerabilidades fueran encontradas por la propia Microsoft y luego los exploiters crearan el ataque? Esto en realidad sería positivo, una especie de "cura" interna por parte de la compañía para eliminar puntos débiles.
                  • Si se habla desde 2006 es porque fue cuando se introdujo Vista, el primer sistema operativo con medidas de seguridad reales de serie... Si miramos de nuevo el gráfico, vemos que el número de vulnerabilidades de ejecución de código para las que se ha encontrado exploit, no ha variado sustancialmente desde 2006. Quizás, tras la desaparición de XP y la introducción de mejoras sustanciales de seguridad en el sistema, se podría esperar una caída más pronunciada en los exploits contra Microsoft... pero no parece que sea el caso. Como decíamos, el statu quo se mantiene. Las defensas mejoran pero los ataques son más sofisticados.
                  • Echamos de menos una aclaración sobre a qué software se refieren exactamente en las gráficas. Pero aunque no lo mencionen, sí es cierto que el número de vulnerabilidades de ejecución remota de código explotadas en programas servidor de Microsoft (Exchange, MSSQL, IIS, etc) es casi anecdótico desde hace años.
                  • El número de vulnerabilidades descubiertas en forma de 0-day (siendo explotadas) no ha descendido en absoluto desde 2006. Son las más peligrosas y las que más daño causan a los usuarios.
                  • En 2013, los exploits posteriores a los 30 días ya no tienen apenas presencia. No sirven a los atacantes. Y aquí quizás entra en juego el parcheo rápido y automático de Windows, que tanto bien ha proporcionado a los usuarios.
                  • Se nota un descenso pronunciado a partir de 2012 del número de vulnerabilidades. ¿Microsoft ha mejorado o es que ya no suponían mucho interés para los atacantes? Un poco de todo. Recordemos que a partir de 2012 ocurrió algo muy interesante en el mundo de la seguridad: Java y sus fallos. Un auténtico caos que, hasta 2013, lo dominó todo (Oracle fue objeto de mofa durante dos años). Lo más sencillo para los atacantes era crear exploits triviales para Java y conseguir resultados óptimos. Solo hace falta ver el gráfico más abajo para comprender qué ocurrió en 2013. Entonces, desde el punto de vista de los atacantes ¿para qué analizar tanto el software de Microsoft (que además se hace más complicado cada vez) si se dispone de Java para mantener los niveles de infección y poder explotar? Ya sabemos que la correlación no implica causalidad, pero puede ser una teoría interesante. Habría que ver qué ocurre durante este año y el próximo para confirmar.

                  Fuente: Kaspersky

                  Pero en resumen, no se puede decir que Microsoft no haya mejorado. Es un hecho que explotar IE es ahora mucho más "caro" para un atacante, entre otras razones. Un detalle que mencionan, casi de pasada, es que aunque el número de 0-day en 2006 es parecido a los de 2013, no son de la misma "naturaleza": una buena parte se han encontrado atacando a objetivos muy específicos, es decir, hablamos de ciber-guerra. A medida que un 0-day tiene más valor, los atacantes no lo "malgastan" en el usuario medio... lo aprovechan para usos más "lucrativos" y potentes.

                  Sergio de los Santos
                  ssantos@11paths.com

                  Introducción a la seguridad en redes industriales (I)

                  $
                  0
                  0
                  Aunque algunos prefieran pensar que el mundo de la seguridad es exclusivo del "underground" y que solo personas muy esmeradas y profesionales están en ello, no podemos negar que en nuestra profesión también existen modas, nombres "cool" y por supuesto, existe el marketing. Nos encanta lo que hacemos pero no deja de ser un negocio y una profesión además de un hobby. Por eso, el hecho de enfrentarse con una nueva moda en seguridad, nos pone frente a una situación muy particular: la necesidad de volver a estudiar. Aunque parezcan conceptos viejos, aunque la seguridad sea cíclica en cuanto a sus errores, cada nueva moda, o cada nueva tecnología o cada nueva implementación supone un nuevo desafío y no podemos darnos el lujo de abordarlo desde la confianza. Al contrario debemos ser muy cautos y volver a nuestras bases. Volver a estudiar.

                  Por qué explicar la seguridad industrial

                  Hoy en día, las modas de la seguridad de la información están relacionadas directamente con las redes de sistemas industriales, con drones, con dispositivos médicos, con el internet de las cosas, ciberguerra y algún que otro tema más. En esta serie de entradas, trataremos exclusivamente la relacionada con los sistemas industriales. Los métodos "tradicionales" de abordar esta disciplina (se puede buscar "hacking scada" o "ataques a redes scada" en Google) no ofrecerán más que exploits, sin conocer qué afecta realmente o cuáles son los vectores de ataque en una red industrial. Pero en esta serie veremos por qué se supone que los SCADA son distintos a los demás sistemas.

                  Parece necesario porque hay mucha información pero no tantos datos concretos, porque el mercado empieza incluso a lanzar carreras relacionadas con este tema; porque se organizan congresos sobre seguridad en las redes industriales; porque está relacionada directamente con la ciber-defensa de un país o una región; porque sus vulnerabilidades afectan a todos de una manera diferente a las que puedan existir en otros ambientes: está en juego incluso la vida y la salud de las personas.

                  Safety is not security

                  Un sistema de control industrial tiene por objeto controlar de manera automática un proceso industrial (antes controlado manualmente, aunque cabe aclarar que todavía existen en muchas fábricas) sin tener que depender de la reacción o interpretación de un operador sobre una medida. Los procesos industriales manuales dependen en gran parte de la experiencia del operador, pero agregan variables difíciles de controlar: el nivel de cansancio, su estado de ánimo, las frecuencias en que el cerebro humano puede tener huecos o vacíos de atención ante un proceso de alta concentración, etc. La automatización de estos temas no es algo novedoso, los sistemas de control industrial existen desde hace muchísimos años y funcionan bien.

                  La integración a las redes TCP/IP es lo que ha hecho que se convierta en una moda porque principalmente cambia varios escenarios. Ahora están expuestos a internet, cualquier usuario de la LAN puede alcanzar los controles del sistema, el malware comienza a desarrollarse con el fin de afectarlos directamente, etc.), pero sobre todo plantean una especie de dogma: "safety is not security". En los sectores o áreas de operaciones, hablar de "safety" (hablar de la protección de las vidas humanas) es algo muy común y sobre todo muy tenido en cuenta; pero hablar de "security" no es cosa de todos los días. Un buen objetivo como profesionales de la seguridad es tener presente siempre que una planta industrial que piensa en concepto de "safety" no necesariamente involucra "security". Sin embargo una que piensa en "security", colabora a mantener los niveles de "safety" donde deben permanecer. Vamos a ir entendiendo por qué a medida que avancemos en el tema.

                  Los sistemas de control industriales se basan en 3 etapas:

                  • Medición de los datos del proceso (monitorización).
                  • Evaluación de la información obtenida en cuanto a parámetros estándar.
                  • Control del proceso en base a la información medida y evaluada.

                  Estos sistemas de control pueden ser completamente manuales, automatizados en su totalidad, o ambas formas (híbridos). Los sistemas conocidos particularmente como SCADA ("supervisory control and data acquisition") pueden permitir evaluar desde una consola la información de múltiples puntos de un proceso y tomar decisiones de control.

                  Esto nos lleva a la necesidad describir cuáles son los componentes habituales, y por qué no, de una forma que nos resulte conocida como el modelo OSI.

                  Un modelo de capas

                  En este modelo, de la misma manera que en el modelo OSI, las capas están relacionadas entre sí.


                  Fuente cci-es.org

                  Empezando por la capa inferior (1), la capa de los Sensores y Actuadores (equipos que regulan las variables y ejecutan los controles), sería algo así como la capa física, donde lo que importa es el medio o los dispositivos de campo. Básicamente, aquí se concentran a nivel de dispositivos de campo, los sensores de movimiento, sensores de temperatura (termopar o termocuplas), sensores de niveles, sensores magnéticos, etc. y por otro lado, a este nivel lo que se transmiten son señales.

                  En la capa siguiente (2), se encuentran:
                  • Los famosos PLC (Programmable Logic Controller o Controlador Lógico Programable) 
                  • Las RTU (Remote Terminal Unit o Unidad Terminal Remota) que básicamente son un microprocesador capaz de adquirir señales de campo y actuar en consecuencia en base a una programación existente
                  • DCS (Distributed Control System). Son un Sistema de Control Distribuido (se comunica con los dispositivos de campo y presenta los datos a un HMI o interfaz para humanos), que obtiene información de los PLC o de las RTU. Por lo general la forma antigua más común de interconexión era RS232 o Ethernet utilizando protocolos específicos como MODBUS o DNP3, entre otros (existen más protocolos y más medios de interconexión). Los términos y conceptos de DCS y SCADA son muy similares entre sí, y en ocasiones se utilizan indistintamente, dependiendo del sector en el que se esté trabajando.

                  Subiendo un poco más en el modelo hasta la capa (3), nos encontramos con el nivel de los HMI/SCADA donde, fundamentalmente, se recolecta toda la información de los PLC y/o RTU distribuidos de manera automática, y donde empezamos a encontrarnos con un protocolo conocido como TCP/IP.

                  En la capa superior siguiente (4) aparece un nuevo jugador pocas veces mencionado, el MES (Manufacturing Execution System) cuyo objetivo no es la evaluación del proceso en sí mismo, sino la de su eficiencia a partir de la información recibida. Por ejemplo, si determinada máquina no tuvo el mantenimiento necesario en fecha y tiene disponible otro equipo que sí lo tuvo como para asegurar la calidad; el cumplimiento de un determinado proceso; o si el turno de tarde produce más que el turno  de mañana, etc.

                  Y finalmente, en la última capa (5) se encuentra el también conocido ERP, donde básicamente se decide qué tipo de controles se ejecutarán, con qué frecuencia y con qué esfuerzo, con el objetivo de disponer de una planificación coherente.

                  No todas las plantas industriales o las fábricas disponen de la totalidad de estos componentes aplicados en sistemas. Por ejemplo, puede que  muchas no cuentan con un ERP y todo lo relacionado a ella lo hacen "en procesos manuales". Pero lo importante es comprobar la existencia de vectores de ataque, que veremos en el próximo artículo junto a los principales protocolos.

                  Claudio Caracciolo
                  claudio.caracciolo@11paths.com
                  Viewing all 1287 articles
                  Browse latest View live