No siempre es un hacker quien causa la pérdida de confidencialidad

Los ataques de ransomware son tan comunes y hay tanta prensa alrededor de vulnerabilidades como Meltdown, que a veces se pierde de vista que pueden existir otras causas que ocasionen pérdida de datos.

Un ejemplo es el caso del operador de seguros Triple-S en Puerto Rico. Esta empresa notificó a cerca de 36.000 usuarios de la pérdida de confidencialidad en la información debido al envío de correo a direcciones equivocadas. Usualmente los balances médicos pueden contener información acerca del número de cuenta, muy útil a la hora de configurar el usuario en línea, y otra información personal acerca de las dolencias médicas que puedan al recipiente legítimo.

Triple-S ha indicado que ha revisado sus procesos de manejo de correo y corregido las fallas que permitieron este error. Sin embargo, no es la primera vez que Triple-S se ve envuelta en este tipo de problemas. Anteriormente en el 2015 el regulador médico ya le había impuesto cuantiosas multas por sus descuidada administración y malas prácticas de seguridad informática.

Como he hecho notar en similares casos, esta información solo es sabida por las estrictas regulaciones existentes en los Estados Unidos y Europa que exigen que se haga público cuando los datos de usuarios son capturados por hackers o simplemente llegan a la persona equivocada. Como es bien sabido, Puerto Rico debe cumplir la legislación norteamericana y por eso hemos sabido del caso Triple-S.

Mientras tanto el resto de usuarios latinoamericanos tenemos que contentarnos con la oscura respuesta “por motivos de seguridad”. Esta falta de transparencia y el atraso latinoamericano en este campo y la ausencia de transparencia nos impide saber si la entidad donde depositamos nuestro dinero o tiene nuestra historia médica falla en su responsabilidad como garante de nuestra privacidad.

El regreso de un viejo conocido. Medidas para defenderse de un DoS

Las noticias sobre el ataque a Github han dado la vuelta alrededor del mundo y ya es sabido que es el mayor ataque realizado hasta ahora. Vale la pena recordar que estos ataques siguen aumentando en capacidad e intensidad.

Pero esto no es nuevo, ya el año 2016 presenció severos ataques contra proveedores de servicio DNS y el conocido periodista del blog KrebsonSecurity. El común denominador de estos ataques fue una capacidad inusitada en el ancho de banda utilizado. Ya no son raros los ataques de 400 Gbs o más.

En la entrega anterior expliqué brevemente como se desarrolla un ataque DoS. La fórmula conocida, pero a veces opacada por su primo ransomware, nos recuerda lo fácil de estos ataques y la magnificación posible por el abuso de dispositivos del Internet de las cosas. Pero a veces los ataques son prevenibles.

En el caso particular de Github, los atacantes aprovecharon una mala configuración que es común en administración de sistemas de información. El software en cuestión, que permite un mejor aprovechamiento de memoria, usa un puerto UDP que estaba expuesto externamente. En otras palabras, el software no tenía todos sus puertos lógicos protegidos por un firewall.

Muchos sistemas de información presentan debilidades porque su configuración simplemente no se ha terminado. A veces esto se debe a el afán, ignorancia o simple desdén burocrático. Sea cual sea la razón, el resultado es la presencia de vulnerabilidades que pueden ser fácilmente prevenidas.

En inglés se utiliza la palabra “hardening” para indicar que una vez un sistema es instalado se debe seguir un proceso de configuración para proteger el mismo sistema.

Algunas buenas prácticas incluyen deshabilitar o proteger puertos TCP o UDP, cambiar las claves del usuario administrador, verificar que el usuario común no tenga capacidades de administración, etc.

¿Cómo asegurar que un departamento de informática siga estas prácticas? La respuesta, como todo en este ramo, depende de la madurez del departamento y el entendimiento del riesgo al que la organización está expuesta. Documentar y poner en práctica procesos es difícil, y aunque no es tan llamativo como comprar y aprender nueva tecnología es vital para la protección de información.

Otras prácticas que ayudan incluyen la regularidad en el uso de escáneres de vulnerabilidades y servicios de pentest. Finalmente, es el apoyo de la alta administración de una empresa la que permite que estas buenas prácticas se den. De poco sirve tener un informe pentest si sus recomendaciones no se siguen.

Así como esperamos que un banco proteja nuestro dinero, las empresas que manejan nuestra información también tienen un deber con sus usuarios y clientes. Ya me he referido en varias oportunidades a la responsabilidad compartida de las empresas que son víctimas de ataques informáticos.

El ataque a Github nos recuerda una vez más que los adversarios y otros delincuentes del ciberespacio siempre aprovecharán cualquier descuido de su personal técnico.

El regreso de un viejo conocido

Si hubiera un concurso de popularidad para malware sin duda ransomware se llevaría el primer lugar. Un rápido atisbo de las noticias e incluso algunas de mis entradas a este blog muestran que este mal ocupa el tiempo de los profesionales de seguridad informática.

Sin embargo, siempre hay otros tipos de ataques igualmente severos y sería peligroso desestimar esta realidad. Un vector conocido, pero a veces relegado son los ataques de negación de servicio o DoS (Denial of Service por sus siglas en inglés). Como su nombre lo indica, DoS simplemente niega el acceso a un servicio en particular.

Hoy en día el servicio más común es un sitio web, pero un ataque DoS se puede dar contra un servidor de correo o sistemas de administración. Al final el resultado es que el usuario legítimo no puede acceder los servicios que necesita.

Desafortunadamente para nuestra profesión realizar un ataque DoS es relativamente sencillo. Este hecho se da porque existe el fenómeno de amplificación. En términos generales amplificación funciona de esta manera: el adversario envía datos a dispositivos en Internet que previamente ha identificado con la dirección IP de origen de la víctima y estos realizan el ataque.

¿Cómo es posible personificar a una víctima? En el mundo de redes esto es conocido como IP spoofing. Herramientas de libre distribución como Scapy permiten construir un paquete TCP/IP con los atributos y valores que uno quiera. Uno de esos atributos es la dirección IP y quien construye el paquete TCP/IP puede usar cualquier dirección de origen, en este caso la dirección IP del sistema a atacar.

Otra característica común es que el paquete original enviado es relativamente pequeño y su tamaño es de solo unos bytes. Una vez se envía este paquete a una multitud de destinos con una sola dirección falsa de origen (la de la víctima), estos destinatarios responderán a la víctima y no a quien originó el ataque.

Además, estos paquetes de datos contienen algún error o tipo de datos que obliga al dispositivo que lo recibe a responder con un paquete de datos más grande (debe recordarse que el dispositivo no responderá al atacante sino a la víctima).

El sistema víctima entonces recibe cientos o miles de paquetes de gran tamaño que consume recursos de procesador o memoria. Luego, el sistema víctima tratará de responder a los dispositivos que le enviaron datos y estos a su vez responderán con un paquete más grande. Este círculo vicioso continua hasta que el sistema no es capaz de responder o el ancho de banda utilizado es tan grande que simplemente no hay más acceso a Internet.

Capturar o identificar un alto número de destinatarios es hoy posible por la omnipresencia del llamado Internet de las Cosas (Internet of Things, IoT). Las cámaras de vídeo vigilancia como Ring o Blink  son de relativo bajo costo y hoy miles de hogares tienen sistemas de este tipo, pero a veces conectados directamente a Internet. Son este tipo de dispositivos que los atacantes han identificado previamente y magnifican la capacidad del atacante.

Dada estas características, un ataque DoS no requiere sistemas sofisticados ni poderosos y para empeorar la víctima nunca sabrá quién le atacó. En una próxima entrega esta breve descripción de un ataque DoS servirá para explicar el ataque contraGithub que sucedió el primero de marzo.