Micropíldora – Forzar el uso de HTTPS

Paso de HTTP a HTTPS Prevent SQL Injection. Fuente imagen: Planetainformatico.es

Paso de HTTP a HTTPS. Fuente imagen: Planetainformatico.es

Estamos acostumbrados a que cuando accedemos a una página cifrada con certificados SSL nuestro navegador nos lo muestre en la barra de direcciones con un icono de un candado y cambiando el protocolo HTTP por el HTTPS. El hecho de utilizar este cifrado nos asegura que el tráfico entre el cliente y la web accedida es seguro, pero ¿cómo hacemos que nuestros visitantes de nuestra web pasen de utilizar el protocolo HTTP estándar por el HTTPS?

Suponiendo que tengáis instalado correctamente un certificado SSL en vuestro servidor (consultar con la ayuda de vuestro hosting sino lo sabéis) la solución es tan sencilla como modificar el fichero de configuración .htaccess para que todas las peticiones que lleguen al puerto 80 (el usado por HTTP) se redirijan a la correspondiente URL pero usando el prefijo https://. Así el navegador de nuestros usuarios utilizará el protocolo seguro siempre que se conecte a nuestra web.

Tan sólo buscar el modulo rewrite y añadir las dos instrucciones marcadas en azul: en la primera se indica la condición que debe suceder (un acceso al puerto 80 del servidor) y qué cambio debe realizarse (cambiar la URL para que empiece por https://securizando.com/):

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://securizando.com/$1 [R,L]
</IfModule>
# END WordPress

Obviamente deberéis cambiar la URL en rojo por la de vuestro blog 😉

Prevent SQL Injection. Fuente imagen: Exclutips.com

Micropíldora 3 – Protege tu Apache contra SQL Injection

Los ataques SQL Injection son los más comunes en el mundo web y uno de los primeros que e suelen probar contra los servicios web de cualquier empresa.  Los ataques más básicos de esta categoría consisten en solicitar información no prevista a la base de datos de tal manera que bien nos la muestre en pantalla o bien que la podamos deducir (Blind SQL Injection). Esta solicitud de información suele realizarse añadiendo instrucciones SQL a la petición normal de tal forma que el servicio responda, además de la petición original y legítima, con la información que solicita el atacante o bien de tal forma que se pueda extrapolar. El funcionamiento de los ataques a ciegas (Blind SQL Injection) se tratará en su propio artículo.

Ejemplo ficticio de ataque SQL donde se solicitaría la versión de la base de datos que funciona tras la página web:

http://www.webvictima.com/?id=1 union select @@version()

Las instrucciones SQL utilizan diferentes palabras claves por lo que intentar localizarlas en las cadena de texto de las peticiones que llegan a nuestro navegador podría servir como medida de protección ante estos ataques. En el siguiente código se busca las palabras claves union y select dentro de la URL solicitada y en caso de encontrarlas se devolverá la página de error 404 (Page Not found) que haya definida en la configuración del servidor Apache. Como una de las técnicas básicas de los atacantes para evitar ser detectado es ofuscar las cadenas de peticiones para evitar su fácil detección se han incluido las conversiones de las cadenas de caracteres en formatos hexadecimal y Unicode que suelen ser utilizados:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{QUERY_STRING} ^.*(union|%75%6E%69%6F%6E|&#117;&#110;&#105;&#111;&#110;).* [NC,OR]
RewriteCond %{QUERY_STRING} ^.*(select|%73%65%6C%65%63%74|&#115;&#101;&#108;&#101;&#99;&#116;).* [NC]
RewriteRule . – [R=404,L,NC]
</IfModule>

Este truco supone que el servidor Apache tiene correctamente activado y configurado el módulo de rewrite y se ha definido correctamente la página de error 404. Como siempre que se tocan ficheros de configuración haced una copia de seguridad antes 😉

Whaling

Fuente imagen: condiesit.co.uk

Fuente imagen: condiesit.co.uk

En seguridad informática se denomina whaling a las técnicas de phishing dirigidas contra objetivos de alta importancia dentro de una organización (altos directivos de empresa, políticos, etc.) o simplemente de gran transcendencia social (cantantes, artistas, famosos, etc.).

El término whaling es un juego de palabras entre whale, ballena, y phishing. En el mundo de los casinos se denomina “ballena” a aquellos jugadores de altas apuestas a los que se les da  un tratamiento y servicios especiales. También es común denominar como big-fish a una persona importante dentro de una organización por lo que el nombre de whale también se ajusta a esta costumbre.

Como se trata de un ataque muy dirigido a una persona en concreto, o a un grupo muy reducido (consejeros de una empresa o similar), es un ataque que precisa de una fase de recopilación de información meticulosa. Los correos electrónicos, las páginas webs falseadas o la ingeniería social para apoyar la estrategia de phishing deben ser específicamente creadas y diseñadas para estos objetivos concretos. Se trata pues de ataques que implican una gran carga de trabajo pero que pueden obtener una recompensa muy elevada.

Cabe indicar que estas técnicas de whaling son difíciles de detectar por parte de los servicios de seguridad informática corporativos debido a que su especificidad hace que el volumen de transmisiones sea muy bajo, comparándolo con otros ataques phishing.

Ejemplos de whaling

Las definiciones teóricas están muy bien, ¿pero de verdad es un riesgo? Pues sí. Parece que los ataques de whaling están en aumento. Si bien son ataques de ingeniería social muy elaborados y que requieren de una buena documentación previa pueden obtener grandes beneficios con relativo poco riesgo. Veamos un par de ejemplos:

Defensas ante ataques whaling

Como se ha indicado anteriormente este tipo de ataques suelen pasar desapercibidos ante los sistemas de detección automáticos ya que se tratan de comunicaciones, generalmente correos electrónicos, muy precisas y de poco volumen por lo que no suelen saltar las alarmas.

En estos casos la mejor defensa es una buena concienciación de todos los trabajadores, sean del rango que sean, que tengan capacidad de realizar movimientos de dinero importantes. Es importante que ante cualquier petición fuera de lo común se confirme con la persona que supuestamente la realizado: así cualquier empleado debe consultar a su superior ante una petición extraña que supuestamente envía el director general y alguien en la cadena de mando debería contactar con dicho alto cargo para confirmar que realmente ha realizado esa petición y no estamos ante un caso de whaling. De igual forma los consejeros o directores generales deben entender que los procedimientos de una empresa deben ser seguidos para maximizar la seguridad.

Ejemplo de CSRF. Fuente imagen: IT College.ee

Cross Site Request Forgery – CSRF

En seguridad informática, al igual que en la mayoría de parcelas técnicas, se intenta dar nombres concretos a todas y cada una de las técnicas, tanto defensivas como atacantes, que van apareciendo y evolucionando para así, con una categorización clara, poder analizar cada caso y evolución. En este artículo veremos una evolución de los ataques XSS: la Cross Site Request Forgery (CSRF).

Estos ataques están muy ligados a la facilidad de la mayoría de navegadores modernos para gestionar diferentes recursos web, generalmente utilizando pestañas, y de memorizar las claves de acceso y sesión a los servicios web para facilitar al máximo la comodidad del usuario. La mayoría de usuarios se han acostumbrado a acceder a muchos servicios web (correo electrónico, redes sociales, foros, etc.) y que el navegador ya se autentique de forma automática sin que le pida las claves de acceso. Una vez hemos accedido a un servicio web el navegador gestiona una cookie de sesión que nos identificará frente al servicio web hasta que cerremos la sesión.

Con este entorno un atacante podría generar una página web, que podría facilitar a la víctima por ingeniería social, especialmente diseñada para que realizase una acción sobre una segunda página web que, al estar previamente autenticado, se llevaría a cabo.

Ejemplo de CSRF

Ejemplo de CSRF. Fuente imagen: IT College.ee

Ejemplo de CSRF. Fuente imagen: IT College.ee

Intentaremos ilustrar este tipo de ataque con un ejemplo simple si bien no es difícil imaginar situaciones más delicadas.

La víctima suele participar en un foro web (www.forovictima.com) por lo que generalmente abre una pestaña del navegador con ese foro. Una vez hecho esto, probablemente a primera hora de la mañana, se ha establecido una cookie de sesión que el navegador utilizar para autenticarse con el foro hasta que se cierre la sesión (que puede ser al finalizar su horario laboral).

Conociendo este comportamiento (que será muy similar al de la gran mayoría de usuarios activos en ese foro) un atacante prepara una página web maliciosa que tras una apariencia inocente en realidad lanza una petición del tipo www.forovictima.com/perfil?accion=baja

Cuando el navegador ejecuta esa llamada utilizará la cookie de sesión previamente almacenada para autenticarse en el foro y realizar la consulta pedida. En nuestro ejemplo (accion=baja) el resultado podría ser la baja del usuario en el foro.

En este ejemplo se trata de una simple baja de un foro pero este tipo de ataque podría, por ejemplo, obligar a un usuario a comprar un producto en una tienda por lo que no hay que descuidarlo.

Protección frente CSRF

Por parte de los usuarios los consejos que protegerían frente a CSRF sería básicamente cerrar sesión cada vez que terminemos de utilizar un servicio e impedir que el navegador almacene nuestras contraseñas de acceso. Así sólo nos autenticaríamos de forma consciente.

Otro consejo para los usuarios sería utilizar navegadores diferentes para acceder a las aplicaciones de ocio y a las críticas. De esta forma, al no compartirse sesiones entre navegadores diferentes, sería imposible que acceder a una web maliciosa enlazada en un foro afectase a nuestra cuenta bancaria.

Existen librerías que facilitan el desarrollo de aplicaciones seguras. Fuente imagen: Bkcore.com

Existen librerías que facilitan el desarrollo de aplicaciones seguras. Fuente imagen: Bkcore.com

Por parte de los desarrolladores de aplicaciones web hay que tener en cuenta qué acciones son críticas para su sistema, y sus clientes, y reforzar su realización mediante sistemas que obliguen a la interacción con el usuario (captchas, segundos factores de autenticación, identificaciones únicos de peticiones, tokens, etc.).

Concepto Wardriving. Fuente imagen:Flylib.com

Wardriving

Concepto Wardriving. Fuente imagen:Flylib.com

Concepto Wardriving. Fuente imagen:Flylib.com

Se denomina Wardriving a la búsqueda y recolección de información sobre redes Wi-Fi realizada desde un coche en movimiento. Seamos claros: la idea es pasearse por una zona que nos interesa con un portátil, o cualquier otro equipo con capacidad de conectarse a una red Wi-Fi, de manera que guardemos toda la información de las redes Wi-Fi que nos encontremos (SSID, protocolos de cifrado, direcciones MAC de los routers, ubicación GPS etc.) por el camino.

Hay que tener en cuenta que la mayoría de routers ADSL instalados por los operadores de telecomunicaciones en España vienen con una red Wi-Fi configurada por defecto que, hasta hace no demasiado, permitía el cálculo automático de la contraseña de acceso. Así pues, un usuario podría utilizar la información recogida para intentar, a posteriori, obtener las claves de acceso a las redes inalámbricas y utilizar así esas redes cuando lo considerase conveniente con las intenciones que fueran.*

Esta técnica puede utilizarse como parte de la fase de recolección de información de un ataque posterior. El hecho de detectar diferentes redes Wi-Fi puede dar información sobre la existencia, o no, de infraestructura de control de redes inalámbricas, la existencia de líneas ADSL independientes que puedan favorecer una infección remota, etc.

Ejemplo de equipo par wardriving. Fuente imagen: Wigle.net

Ejemplo de equipo par wardriving. Fuente imagen: Wigle.net

¡Pero no sólo los malos usan el concepto de wardriving! Resulta que si quieres que tu empresa disponga de un certificado PCI-DSS hay que cumplir muchos requisitos y uno de ellos, el 11.2 ( “Test for the presence of wireless access points and detect unauthorized wireless access points”) obliga a los administradores de red a pasearse por la empresa en busca de redes Wi-Fi desconocidas que puedan suponer una puerta de salida de información privada. Efectivamente. Habréis visto en algunas películas que alguien detecta un pincho USB que emite por Wi-Fi la información que el malo malísimo necesita… y resulta que sí, que los administradores de red buscan estos puntos Wi-Fi dentro de sus instalaciones.

* Como anécdota personal puedo decir que cuando tuve un familiar ingresado durante bastante tiempo utilicé esta técnica (aunque caminando y no en coche) para encontrar una red Wi-Fi con la que conectarme a Internet. Aunque ya nos hemos acostumbrado a la conectividad móvil 4G no hace tanto que las conexiones eran muuuuy lentas y caras 😉

Fuente imagen: Kaspersky

Micropíldora 2 – Protege la red Wi-Fi de tu casa

Fuente imagen: Kaspersky

Fuente imagen: Kaspersky

En esta micropíldora podréis encontrar algunos consejos para fortificar la red Wi-Fi que la mayoría tenemos en casa. Se trata de una lista de consejos básicos para usuarios no profesionales que buscan tener una red más segura pero sin entrar en modo paranóico. Así pues aquí tenéis un listado básico de pequeños cambios que protegerán vuestra red Wi-Fi para que sea más complicada que la del vecino porque en seguridad casera no hace falta correr más que el león sino ser más rápido que otra víctima.

Cámbiale la contraseña

Existen múltiples herramientas públicas para calcular la contraseña por defecto que traen los routers de las principales operadoras por lo que la primera medida de seguridad será cambiar la contraseña de acceso.

Cámbiale el nombre o directamente ocultalo

Todos los routers Wi-Fi de las operadoras incluyen nombre estandarizado (WLAN_0ce, VODAFONE_A345, etc.). Las operadoras incluyen una contraseña por defecto que se calcula en usando este SSID. Como ya hay diversas aplicaciones de móviles que calculan la contraseña por defecto en base al SSID el mero hecho de cambiar el nombre de la red (SSID – Service Set IDentifier) ya es una medida de seguridad a aplicar, aunque como hemos comentado en el primer punto debes cambiarla.

Otra medida de seguridad que evitará los intentos de conexión automatizados es ocultar el SSID. Así la red no se anuncia públicamente y tan sólo se podrán conectar aquellos equipos que conozcan el nombre de la red y su contraseña de acceso. Hay que tener en cuenta que podemos tener equipos que tengan dificultades para conectarse a redes Wi-Fi ocultas: los primeros iPhone no mantenían la conexión en redes ocultas.

Método de cifrado

Aunque muchos routers Wi-Fi incorporan protocolos antiguos por temas de compatibilidad con equipamiento antiguo debemos evitar el uso de éstos ya que sus características en el plano de seguridad están totalmente sobrepasadas. Así debemos elegir el protocolo de cifrado de más seguro compatible con nuestros equipos, a ser posible WPA2.

Fuente imagen:Taringa.net

Fuente imagen:Taringa.net

Controla la potencia de emisión

La calidad de la señal, y con ella la velocidad de transmisión, requiere de una cierta potencia de emisión por parte del router por lo que generalmente se suele configurar dicho equipo para que emita con la máxima potencia posible para tener la mayor zona de cobertura posible. El problema de esta estrategia es que parte de la potencia sale al exterior de nuestra vivienda y permite que cualquier persona cerca (vecinos, gente en la calle, etc.) se pueda conectar a nuestra red. Por ello es inteligente reducir la potencia de emisión a aquella que permita una buena conexión dentro de nuestra casa. Si tenemos zonas de casa con poca cobertura es preferible utilizar extensores de red, ya sea usando repetidores Wi-Fi o equipos PLC, para focalizar la red en aquellas zonas donde nos interesa.

Securización por MAC

Éste quizás sea el punto más controvertido de este artículo. En la mayoría de guías de bastionado de redes Wi-Fi indican que es importante activar la opción de securización por dirección MAC: así nos aseguramos que únicamente los equipos que nosotros demos de alta podrán conectarse aún conociendo la contraseña de acceso. Esto es totalmente cierto y altamente recomendable si tenemos una red muy estable (redes Wi-Fi domésticas) pero se convierte en inviable en el momento que queramos dar un servicio ágil a usuarios temporales (redes en un piso compartido, etc.). Si bien existen técnicas para falsear las direcciones MAC con las que saltarse este punto de seguridad ya estaríamos ante un ataque demasiado profesional para lo que afecta a esta entrada. La securización por MAC es útil si es viable tener controlados e identificados los equipos que se van a conectar a la red (teléfonos móviles, portátiles, televisiones, etc.).

Desactiva WPS

El sistema WPS (Wifi Protected Setup) se creó para facilitar la conexión de equipos en redes Wi-Fi de tal manera que los nuevos dispositivos se autoconfiguraban de forma fácil, sencilla y muy cómoda para el usuario final. El problema es que este sistema de autoconfiguración ha permitido que un usuario malicioso también pueda conectarse de forma sencilla a la red, así pues si no lo necesitas desactívalo. Siempre puedes activarlo cuando quieras conectar esa nueva televisión Wifi 4K.

Micropíldora 1 – Qué usuario administrador no usar en tu WordPress

Este artículo comienza una nueva categoría: las micropíldoras de seguridad.

En estos artículos pretendo dar alguna pinceladas de pequeñas configuraciones que permiten mejorar la seguridad de diferentes entornos. No se trata de exámenes exhaustivos ni grandes configuraciones sino de pequeños detalles que ayudan a securizar algo los entornos.
_________________________________

Micropíldora 1: ¿Qué usuario administrador no usar en tu WordPress?

Acceso WordPress

Acceso a WordPress. Fuente imagen: Ayuda WordPress

Revisando los intentos de acceso a la consola de administración de este blog (que como ya habrás averiguado utiliza WordPress) podemos ver que los usuarios que más intentos de acceso (todos fallidos) son:

  • admin
  • test
  • securizando

Se puede observar que se intenta acceder con el usuario de administración genérico de la plataforma WordPress (admin) y el nombre de dominio de la web (securizando). Este mismo patrón aparecen en mi otro blog sobre aviones militares de tal forma que los usuarios más probados son admin, test y avionesmilitares.

Intentos conexión blog AvionesMilitares

Intentos conexión blog AvionesMilitares


Sabiendo que hay muchos robots por el mundo que intentan acceder a nuestro sistema WordPress utilizando estas combinaciones lo mejor es evitar utilizarlos. Una vez instalado WordPress una de las primeras cosas debería ser cambiar el usuario administrador y dejar de utilizar admin. Si el acceso a nuestro sistemas se basa en una pareja usuario/contraseña evitemos que el usuario sea demasiado fácil de averiguar 😉

Hay que decir que también hay intentos de acceso con usuarios que serían combinaciones de mi nombre tales como andresadrover, aadrover, andresaadroverandres y similares, si bien estas combinaciones son mucho menos utilizada y parecen más intentos manuales que sistemas automatizados.

P.D. No. Ninguno de los usuarios aquí mencionados existe 😉

Modelo STRIDE

Categorización de ataques STRIDE

Modelo STRIDE

Modelo STRIDE. Fuente imagen: Infosec Institute

Se dice que para abordar un problema primero hay que saber definirlo. Así si podemos analizar el problema podremos idear soluciones adecuadas. Dentro de esta política de definir y categorizar las posibles amenazas aparece la categorización de ataques STRIDE que surge de las iniciales de los diferentes tipos de ataques. A partir de esta clasificación es posible estudiar con mayor profundidad la implementación de los distintos ataques y así evaluar las medidas de protección adecuadas si bien, por regla general, los ataques reales pueden aparecer en varias categorías de forma simultánea.

Spoofing

La categoría de suplantación (spoofing en inglés) hace referencia a cualquier técnica que permita al atacante tomar una identidad que no le corresponde. Probablemente los ataques tradicionales más conocidos sean IP spoofing, donde el atacante falsea su dirección IP, o MAC spoofing donde el atacante falsea su dirección MAC (muy utilizado en ataques a redes inalámbricas). Las técnicas de phising, donde la víctima es engañada al creer que está accediendo a un sistema confiable, también caben en esta categoría.

Tampering

Las técnicas de tampering buscan manipular la información que almacenan los sistemas, ya sea directamente o en mientras se envía por la red. Dentro de esta categoría entrarían aquellas técnicas que buscan ofuscar la presencia de un malware en un sistema falseando la información de logs de un sistemas de seguridad o bien modificar los registros para que la información que reciban los administradores sea indescifrable o engañosa.

Repudation

Asociación STRIDE-CIAAAA.

Asociación STRIDE-CIAAAA. Fuente imagen: gaurabb.com

La tercera categoría del modelo STRIDE , repudio, abarca aquellas técnicas que evitan la certificación o garantía de un hecho. Si un sistema no puede garantizar el no-repudio, es decir que el ejecutante no pueda negar su acción, entonces no se puede garantizar la veracidad de la información mostrada por el sistema. Este puede tener consecuencias legales y es importante en entornos de análisis forense.

Information Disclosure

La revelación de información implica que un usuario no permitido acceda a información o documentación sensible. Probablemente sea el tipo de ataque que más temen las empresas por sus consecuencias legales. Los estados europeos han desarrollado legislaciones especiales para asegurar la protección de los datos personales que pueden manejar las empresas. En España se regula por la Ley Orgánica de Protección de Datos (LOPD).

Denial of service

Los ataques de denegación de servicio probablemente sean los más reconocidos por el público general (lo cual incluye la mayoría de directivos de empresa). Estos tipos de ataque buscan bloquear el acceso a un servicio de tal manera que interrumpan la continuidad del negocio. Estos ataques pueden tener un fuerte impacto económico al que se añade un posible impacto en la reputación de la empresa.

Elevation of privilege

Los ataques ataques por elevación de privilegios ocurren cuando un usuario, debido a un fallo de seguridad, puede cambiar su nivel de privilegios dentro del sistema y acceder a información o servicios a los que, por su identidad, no debería tener acceso.

Formato CVE

CVE

Cuando trabajamos con cualquier listado o categorización necesitamos utilizar identificadores únicos para poder trabajar de forma compartida. Con la utilización de estos identificadores únicos se evitan confusiones y malosentendidos entre todas las personas que trabajan con estos sistemas. En nuestro ámbito, la seguridad informática, el sistema de identificación de vulnerabilidades más conocido y utilizado a nivel mundial, si bien no es el único, es el CVE (Common vulnerabilities and Exposures) creado y mantenido por MITRE.

Procedimiento etiquetado de vulnerabilidades

La numeración de las nuevas vulnerabilidades es responsabilidad de las CVE Numbering Authority (CNA). Actualmente las CNA oficiales son la propia MITRE y 18 fabricantes de software (Adobe, Apple, Cisco, Google, HP, Microsoft, Mozilla, Symantec…) a los que se unen los tres principales coordinadores de equipos de seguridad: CERT/CC, ICS-CERT y JPCERT/CC. Cada uno de estos CNA dispone de bloques de numeración no coincidentes y que gestionan por si mismos.

El procedimiento para crear un identificador único de vulnerabilidad CVE es relativamente simple:

  1. Se descubre una nueva vulnerabilidad ya sea de forma interna (los propios fabricantes de software) o desde un tercero (que avisaría al CERT correspondiente).
  2. La CNA avisada asigna un identificador CVE, de la numeración que tiene asignada, en estado candidato. Se trata de la numeración que será asignada de forma oficial si la vulnerabilidad se confirma y se publica.
  3. Se revisa y confirma la vulnerabilidad y se estudia su alcance, afectación y criticidad.
  4. La vulnerabilidad se publica, con la numeración asignada inicialmente, en la web de CVE y se propone al consejo editor de CVE para su aprobación final. En caso positivo la numeración pasa al estado entry quedando fijada.

Formato CVE

El formato de numeración CVE es sencillo pero efectivo. En la misma numeración se indica qué se está identificando y el año de aparición. Tras estos datos se muestra un identificador único para cada vulnerabilidad. Debido al sistema de reparto de la numeración entre CNA, por bloques, no es posible asegurar que el orden numérico de las vulnerabilidades correspondan con el cronológico de su publicación.

Ejemplo de código CVE:

Pondremos como ejemplo el identificador de una vulnerabilidad que afecta al sistema operativo Android y que se popularizó con el nombre de Stagefright: CVE-2015-1538 donde podemos ver que está compuesto por tres partes:

  • CVE: Estas tres siglas identifican que la numeración siguiente corresponde a una vulnerabilidad CVE. Se introdujeron para evitar cualquier posible confusión con otros sistemas de identificación tanto públicos como privados (despieces de motores, etc.).
  • 2015: El año de descubrimiento de la vulnerabilidad. Se trata del año en el que la primera CNA le asigna un código. Es posible que la publicación definitiva se realice durante el año siguiente, como pasaría con muchas vulnerabilidades descubiertas en diciembre.
  • 1538: Identificador único dentro de CVE, del año en cuestión, que hace referencia a esta vulnerabilidad en concreto.
Virus policia

Ransomware

Virus policia

Ejemplo de ransomware: Virus Policia Fuente imagen: ComputerWorld

El nombre de este tipo de programas maliciosos viene de la unión de los vocablos ingleses ransom (rescate) y software (programa informático), por lo que la definición del mismo es bastante precisa: se considera ransomware aquel programa que bloquea o limita el acceso a servicios o archivos de un sistema y solicita un pago para devolver el acceso .

Este tipo de software fue detectado por primera vez en Rusia si bien en 2013 tuvo un gran crecimiento internacional. Los casos más sonados en España aparecieron a finales de 2014 y primera mitad de 2015.

Este tipo de software suele infectar a las víctimas como un troyano que el propio usuario instala si bien se han detectado algunos que utilizaban vulnerabilidades conocidas para autoinstalarse. Una vez el programa está instalado en el equipo se activa su función maliciosa (ya sea bloquear acceso a los archivos de sistema, cifrar los archivos del usuario, modificar el arranque del sistema, etc.) y muestra un aviso por pantalla explicando al usuario que el sistema está bloqueado y que deberá pagar una cantidad para volver a tener acceso al mismo. La cantidad a pagar no suele ser excesiva para no desalentar al usuario final. El atacante propone una serie de métodos de pago que dificultan la trazabilidad de las operaciones (monedas digitales tipo  bitcoin, cheques viaje, pagos internacioneles, etc.) para evitar ser localizado. Una vez la víctima ha realizado el pago puede, o no, recibir la solución a su infección.

Probablemente el ejemplo de ransomware más famoso sea CryptoLocker. Este programa cifraba los archivos de usuario con un par de claves RSA de 2048bits. El programa ofrecía descifrar los archivos mediante un pago en bitcoins en los tres primeros días de la infección. Pasado este tiempo el precio iba aumentando. Debido a la longitud de la clave de cifrado se considera que los archivos son irrecuperables.

Defensas frente al ransomware

Aunque siempre se dice que la mejor defensa es el sentido común todos sabemos que ése es precisamente el menos común de los sentidos, así que las empresas deben preparar sus sistemas para evitar este tipo de infecciones y en caso de sufrirlas minimizar sus efectos.

Control de navegación

La mayoría de estas amenazas surgen como un troyano que el propio usuario descarga de Internet y ejecuta. Por esto es importante que la navegación de los usuarios corporativos sea a través de un proxy que permita filtrar y bloquear el acceso a páginas web con mala reputación. Si a este primer control de accesos se añade un sistema antivirus en el propio proxy que analice los archivos descargados y detecte las amenazas se reducirá en gran medida la posibilidad de infección corporativa.

A este primer filtro, que no es útil para equipos portátiles que pueden conectarse a Internet desde cualquier sitio, habría que añadirle tener un sistema antivirus instalado en cada equipo y con unas políticas de actualización adecuadas para detectar estos programas maliciosos antes de que puedan ser ejecutados.

Control de instalación

Por regla general los usuarios corporativos no necesitan privilegios para la instalación de nuevo software. Los servicios informáticos pueden instalar todas las herramientas necesarias para el trabajo por lo que los propios usuarios no necesitan de estos permisos. El hecho de no poder instalar nuevo software evita la infección de varias formas de malware. Nuevamente la aplicación de estas políticas en equipos móviles se dificulta.

Control acceso a directorios compartidos

Las variantes de ransomware que encriptan los archivos de usuario pueden provocar problemas a las empresas si llegan a infectar los servidores corporativos. La infección de un usuario con acceso a un directorio compartido de ficheros puede provocar que nadie pueda acceder a los mismos al estar cifrados. Este escenario es uno de los que mayores problemas dolores de cabeza ha provocado entre los departamentos técnicos de las empresas.

Para reducir el impacto de una infección hay que limitar a los mínimos imprescindibles los permiso de escritura o modificación en directorios compartidos. Así se limitaría el alcance del cifrado de archivos en una infección.

Copias de seguridad

Una vez se ha infectado un equipo y ha cifrado los archivos de usuario la única solución para recuperarlos, aparte de pagar y esperar que los atacantes nos envíen una solución, es utilizar nuestras copias de seguridad previas a la infección.

Para asegurarse de tener copia de la mayoría de información las empresas pueden configurar los equipos de usuario para que sólo puedan almacenar archivos en servidores compartidos evitando así almacenar información en los equipos de usuario. Aunque esto pueda parecer entrar en conflicto con el punto anterior en realidad, con una buena configuración de permisos, evitará la pérdida de datos por este tipo de malware.

Para evitar la infección de las copias de seguridad es importante que todas las copias estén almacenadas en directorios de solo lectura donde el único usuario con permisos de escritura sea uno específico para el servicio de copias de seguridad. Este usuario debe tener prohibido el acceso a Internet para evitar que se infecten nuestras copias.