Categoría: Seguridad

Un servidor Asterisk, el único que se salva del ataque al Ayuntamiento de Jeréz
Todos somos humanos y aunque muchas veces pongamos todos los medios posibles para evitar que nos ataquen, nos infecte un virus, un troyano o se nos caiga un sistema, es inevitable que en un plazo de tiempo indefinido, habrá un momento en que alguien cometerá un fallo y tendremos un sistema vulnerable.
El problema viene cuando ese sistema vulnerable infecta al resto de sistemas que tiene a su alrededor conectados a la red. Esto fue lo que ocurrió al sistema informático del Ayuntamiento de Jeréz en el que un ransomware (un virus que cifra todo el contenido de los discos duros de los sistemas infectados y que se propaga por la red interna de las empresas) ha sido el causante de que todos los ordenadores y servidores de este consistorio hayan sido cifrados y obligados a pagar si quieren recuperar los datos (lo que nunca es seguro que pueda hacerse).
Curiosamente como en los tebeos de Uderzo se menciona…
«…¿Todos? ¡No! Un servidor, poblado por un irreductible Linux resiste todavía y siempre al invasor…»
Extracto modificado del comienzo de los tebeos de «Astérix el Galo».
Y es que parece que el único sistema que no ha sido vulnerable al ataque del ransomware ha sido el servidor Asterisk que controla las comunicaciones de este ayuntamiento.
Así que otra prueba más (por si hiciera falta más pruebas) que un servidor Linux y un buen Asterisk, bien controlado y bien configurado es mucho más seguro que muchas otras alternativas que hay por ahí.
Os lo garantizo. 😉
P.D. Jamás confundiría el nombre ‘Asterisk‘ con ‘Astérix‘, pero según he leído en esta página sobre el significado de Astérix: «Su nombre proviene de la palabra ‘asterisco’ (‘asterisque’ en francés). Sin embargo, otras teorías dicen que proviene del griego ‘Aster’ (estrella) y del celta ‘Rix’ (rey)» así que el juego de palabras entre uno y otro nombre siempre ha estado muy relacionado desde hace muchos, muchos años. 😛
Más información:
http://ganemosjerez.es/blog/2019/10/03/un-servidor-con-linux-el-unico-que-sigue-funcionando/
2019-10-05
Los bots empiezan a atacar a Asterisk
Internet es una jungla, hay quien quiere poner puertas en medio y quien pone alambradas, pero está claro que por muchos firewalls, antivirus, protecciones y leyes se instalen, siempre hay alguien que consigue meter un troyano, un virus, o algún resquicio legal para que tu estancia en Internet no sea tan placentera como esperabas. Si montas un blog, hay cientos de exploits sobre el software que utilizas como servidor web, otros cientos de exploits para la plataforma que utilizas, decenas de exploits para cada uno de los plugins que has instalado y por si fuera poco, además el servidor incluye otros servicios que también son vulnerables y siempre hay alguien intentando explotarla.
Si pones un servidor VoIP accesible desde el exterior (por la razón que sea) siempre hay quien intenta aprovecharla, no en vano existen bots especializados en atacar sistemas VoIP que buscan puertos SIP (en el 5060 o donde sea), probar cientos de miles de combinaciones de usuarios/contraseñas y en el caso de que exista alguna cuenta desprotegida con una contraseña sencilla o incluso sin contraseña, empieza un ataque mediante llamadas SIP a números internacionales que pondrán a prueba, no solo el rendimiento del sistema de comunicaciones, si no nuestra capacidad y velocidad para darnos cuenta de que estamos siendo atacados y están haciendo llamadas a través de nuestra infraestructura.
Siempre he dicho que cada fabricante echará la culpa a los productos de la competencia, pero está claro que independientemente de qué software o hardware utilicemos, si ponemos usuarios y contraseñas estándar, vamos a ser atacados tarde o temprano ocasionándonos un gran dolor de cabeza (en el mejor de los casos). Por esta razón, aunque soy de los que defienden que cada protocolo debería funcionar en su puerto (SIP en el 5060), si es cierto que hay que prestar atención a que cada usuario tenga su contraseña bien difícil de adivinar y que no debemos llevarnos las manos a la cabeza ni preocuparnos cuando veamos que un bot intenta registrarse. Cambiar de puerto solo evita ser encontrado de buenas a primeras, pero los bots hacen escaneo de puertos, por lo que el puerto SIP seguirá siendo encontrado tanto si está en el 5060 como si está en el 65535.
Resulta que los bots no solo atacan al puerto SIP, si no también buscan sistemas vulnerables y para ello hacen también varias pruebas:
- Comprueban si el servidor SIP tiene un servicio WEB.
- Comprueban si el servidor WEB tiene ciertas aplicaciones instaladas.
- Comprueban si las aplicaciones instaladas tienen una versión vulnerable.
- En caso afirmativo, usan un exploit para, o bien hacer llamadas desde la aplicación, o bien para abrir una puerta con un usuario nuevo y poder hacer llamadas desde ahí.
Los ataques son cada vez más sofisticados, y por suerte, si estamos medianamente al día en cuanto a las versiones, la probabilidad de que la aprovechen es mínima, pero siempre hay algún exploit más nuevo que no hemos visto, siempre instalamos más aplicaciones de las que deberíamos (y luego no las borramos) y por esta razón los «sipbots» encuentran huecos donde conseguir un suculento bocado.
Visualizador de ataques en tiempo real http://community.sicherheitstacho.eu/start/main
Una versión de Elastix antigua, un A2Billing antiguo, un PHPMyAdmin, un WordPress, un … cualquier aplicación es susceptible de ser vulnerable y abrir la puerta en un momento dado a un ataque. En Alemania, el vicepresidente de seguridad de Deutsche Telekom avisaba del aumento de ataques al puerto 5038 (puerto generalmente utilizado por el servicio AMI -Manager- de Asterisk) y es que es un servicio que puede ser explotable por fuerza bruta similar al que tendríamos abriendo un puerto Telnet a nuestro servidor. Por supuesto es importantísimo no disponer de cuentas «de pruebas», pero lo que los bots buscan son cuentas «comunes» utilizadas por aplicaciones conocidas, aquellas que para que funcionen, por defecto son «stats» y «statspass» o «a2billing» y «changethepass«, o similares. (you know what I mean)
We see a lot of #cyber #attack traffic on Port 5038/tcp, this is a config port of Asterisk PBX. Somebody is trying to bruteforce the confic of VoIP PBX systems. #TelekomSecurity https://t.co/wNe8QTb1eI
— Thomas Tschersich (@Ttschersich) February 26, 2018
Siempre he defendido que no hay que ser un paranoico de la seguridad, eso solo nos lleva a consumir un tiempo precioso en vigilar cuando deberíamos invertirlo en avanzar y mejorar, pero también es cierto que hay que ser conscientes en que la seguridad debe venir de la mano de una serie de hábitos básicos como desinstalar una aplicación si no la vamos a utilizar, siempre contraseñas fuertes y mucho cuidado con «las pruebas» que luego se olvidan que están ahí.
2018-03-07
Explicación de la vulnerabilidad de los procesadores Intel
Para empezar bien el año, nos hacemos eco de algo que va a traer cola, una vulnerabilidad encontrada en el diseño hardware de los procesadores Intel. Si bien este tema no es el típico para Sinologic, su extrema importancia nos obliga a tomar parte y al menos intentar aclarar algunos aspectos que se vienen dando a conocer.
La vulnerabilidad consiste en que un atacante puede acceder a toda la memoria de un ordenador, servidor, móvil, reloj, dispositivo, etc. que tenga un procesador afectado por dicha vulnerabilidad.
Aquí es donde viene uno de los grandes problemas ¿qué procesador está afectado por esta vulnerabilidad? Pues aunque inicialmente se había asociado a Intel, éste afirma que también son vulnerables otros fabricantes como AMD y ARM, así que prácticamente el 95% de los procesadores del mundo tienen este fallo.
Este fallo se puede corregir mediante un parche software en el núcleo del sistema operativo, pero tiene una pega: la aplicación del parche hace que el rendimiento se reduzca en torno al 30% (que no es poco).
De momento ya han aparecido dos grandes exploits que vienen a confirmar que dicho bug existe: Meltdown y Spectre.
Desde cierto punto de vista, parece que el problema está ahí y que existe una decisión que tomar: seguridad o velocidad.
Si quieres seguridad, tienes que aplicar los parches, pero eso reduce el rendimiento. Si quieres rendimiento, tienes que saber que puedes ser atacado y el fallo no es poca cosa (contraseñas, cuentas, etc. están en memoria y son accesibles «fácilmente»).
Ejemplo gracias a @misc0110 (https://twitter.com/misc0110)

Pero no todo es tan sencillo como aplicar un parche:
Meltdown puede ser utilizado por cualquier persona mediante un script tonto.
Spectre en cambio es algo más difícil de utilizar pero es prácticamente imposible de solucionar con los procesadores actuales.
Imagina qué puede hacer un atacante en una máquina en la nube que está compartida por varias empresas. La cosa es mucho más seria de lo que parece.
Para relajarnos, vamos a poner una captura de pantalla del informe de vulnerabilidad del Departamento de Seguridad Ciudadana de los EEUU y la solución que proponen:
En fin… empezamos bien el año. 😉
Gracias a @okercho por la información. 😉
Actualización:
Al parecer ya se empiezan a conocer cuanto empiezan a afectar a los procesadores de distintos fabricantes:
1) Intel: Le afectan todas las variantes de la vulnerabilidad. Igual para un usuario normal no se verá afectado, pero en servidores la cantidad de información propiciará los ataques y se verán expuestos muchos datos privados.
2) AMD: Tras analizar sus sistemas, ha reconocido que le afecta una variante de las que hay en versiones por debajo de los FX (incluido) pero por suerte no existe aún el exploit para aprovechar dicha vulnerabilidad. Así que AMD, aunque le afecta también esta vulnerabilidad, parece que el daño es menor. AMD asegura que los Ryzen no son vulnerables a este ataque. Aunque no se ha podido confirmar.
3) ARM: Le ocurre lo mismo que a AMD: Sobre el papel es vulnerable a un tipo de ataque.
2018-01-04
La seguridad informática como responsabilidad común de todos
A menudo se confunden los términos de privacidad con los de seguridad. Quizá porque debido a algunos problemas de seguridad, se pierde privacidad al exponer los datos de los usuarios, datos personales, propios y confidenciales que los usuarios han confiado a una empresa u organización para que los vigile, cuide y proteja y que no caigan en malas manos que puedan hacer un uso descontrolado de ellos para, a saber qué objetivos.
Si me doy de alta en un servicio, relleno un usuario, mi e-mail y una contraseña para poder crearme un usuario en el sistema, mi fecha de nacimiento para garantizar que soy mayor de 18 años, dirección, teléfono, datos de mi tarjeta bancaria para pagar aquellos servicios que voy a utilizar, etc… y luego esta empresa, por un fallo de seguridad «supuestamente ajeno» a ellos, exponen mis datos a otras personas que a su vez venden a otras empresas, no solo es delito (al menos en Europa) si no que debería indemnizar de alguna forma a aquellos usuarios por negligencia sobre sus datos y posibles datos y perjuicios al «ceder» accidentalmente estos datos a terceros sin ningún tipo de control.
(más…)
2016-09-26
Seguridad: Cómo cifrar y descifrar archivos en Linux
Uno de los campos donde quizá siempre me he considerado un aficionado (por mucho que lea y estudie sobre ello) es en de los algoritmos de cifrado, quizá por que hay tantos y las explicaciones tan enrevesadas, que uno pierde el hilo fácilmente, pero recuerdo de alguna que otra asignatura donde se veían algunos de estos algoritmos, que, además de cifrar cadenas, existen herramientas orientadas a cifrar archivos y cuya seguridad es tan absoluta, que un ordenador podría tardar «teóricamente» miles de millones de años en descifrarla por fuerza bruta.
Otro de los motivos por lo que me llama la atención este tipo de algoritmos es porque nos permite proteger un archivo de forma que, en el caso improbable de que caiga en malas manos (nos roben el móvil, obtengan nuestras contraseñas, etc.) pueden permanecer a buen recaudo con la tranquilidad de que nadie más que nosotros puede descifrarlo.
Para ello, este artículo «chuleta» me sirve como recordatorio de cómo cifrar un archivo de una forma bastante segura pese a que en algún sitio ya se avisa que el algoritmo AES-256 no es tan seguro como se pensaba, pero sigue siendo de los más seguros, razón por la cual fue el utilizado por Julian Assange para cifrar el famoso archivo Insurance.AES256 que según decían, contenía más de 250.000 documentos confidenciales y secretos de Estados Unidos y cuya contraseña publicaría si a él le ocurría algo haciéndose público para todo el mundo.
En nuestro caso, seguro que no tenemos una información tan valiosa, pero igualmente, tras el aumento de lugares de terceros donde subir archivos (Dropbox, Amazon, Google, Microsoft, Apple, Mega, etc…) siempre es recomendable que, si no queremos lamentar el día que veamos un titular del tipo: «Hackers han accedido a XXXXXXX y han obtenido todas las contraseñas de los usuarios» y obtengan acceso a todos nuestros datos, es mejor tenerlos cifrados y a buen recaudo.
Por supuesto, lo ideal es no disponer de datos privados en un almacenamiento generalista, pero si aún así lo hacemos, tenerlos cifrados no nos costará tanto con este tutorial.
(más…)
2015-06-01
Cómo generar una contraseña segura
Uno de los grandes problemas que nos encontramos al conectar un sistema a la red (Internet) es sin duda, los distintos ataques a los que tenemos que hacer frente. Por desgracia, no hay una persona como tal jugando con direcciones IP buscando a alguien a quien atacar, eso hoy día ha sido delegado a un ejército de sistemas «zombies» repartidos por todo el globo de forma que los ataques sean distribuidos, automatizados, rápidos y efectivos.
El momento de generar una contraseña se suele tomar a la ligera y es algo bastante importante plantear:
Primero, necesitamos una contraseña que sea fácil de recordar para poder escribirla siempre que nos la pidan.
Por otro lado, la contraseña debe ser difícil de obtener mediante fuerza bruta, (aunque el uso de GPU para desencriptar contraseñas, unido a algoritmos distribuidos en cientos de máquinas, puede reducir el tiempo para descifrar la contraseña en apenas unos minutos), de manera que cada vez hay más sitios que utilizan sistemas de autentificación en dos pasos o bien te exigen poner una contraseña con letras, números, simbolos, mayúsculas, y una longitud mínima de 15 caracteres.
Existen sistemas mnemotécnicos para ayudarnos a recordar contraseñas fuertes, pero lo que mucha gente empieza a hacer es disponer de un archivo donde guardar todas las contraseñas fuertes que utilizan y hacer uso del «copy+paste» para evitar recordarlas. Hay otras personas que utilizan contraseñas aleatorias y hacen uso del «he olvidado la contraseña» para evitar recordar semejante cadena. Sea como fuere, el uso de contraseñas fuertes es algo obligatorio incluso para algo rápido y sencillo.
En VoIP, vamos a ver que la cosa es mucho más sencilla…
(más…)
2015-05-29
Cómo solucionar el error: ssl_error_no_cypher_overlap
Debido al descubrimiento de que el algoritmo SSLv3 no es seguro, hubo una carrera a contrarreloj para eliminar este algoritmo de todo sistema y pasar a utilizar el algoritmo TLS que sí es seguro. Tanto es así, que los navegadores han dado un paso más allá, prohibiendo conectarnos a sistemas que funcionen con SSL y forzándonos a utilizar TLS. No obstante, existen sistemas que, o bien por traer un firmware antiguo, bien por que no tienen una actualización correcta o bien por que son demasiado antiguos, únicamente soportan SSL, de manera que es imposible conectarnos con un navegador actualizado y obtendremos un mensaje de error «ssl_error_no_cypher_overlap» como el de la siguiente imagen:
Por suerte, existe una manera de permitirnos acceder aunque sea a este dispositivo aunque sea para actualizar el firmware y que empiecen a utilizar el algoritmo TLS, así que vamos a utilizar el navegador Firefox y modificaremos temporalmente una variable que nos permitirá acceder al dispositivo.
(más…)
2015-02-13
Un fallo en el protocolo SS7 permite escuchar conversaciones de líneas móviles

A través del diario The Washington Post, nos enteramos que un fallo en el protocolo SS7 permite escuchar conversaciones y leer mensajes de texto de líneas móviles, algo que lleva siendo explotado por los servicios de espionaje e inteligencia norteamericanos para escuchar conversaciones.
Está claro que, pese a todo, las conversaciones VoIP > VoIP convenientemente cifradas parecen ser el método más seguro hasta la fecha para evitar las escuchas, espionaje industrial y otros problemas de seguridad.
Más información: http://www.washingtonpost.com/blogs/the-switch/wp/2014/12/18/german-researchers-discover-a-flaw-that-could-let-anyone-listen-to-your-cell-calls-and-read-your-texts/
2014-12-22
Cifrado SSL 3.0 ya no es seguro. Cómo mejorar la seguridad de tu web
Prácticamente cualquier lector de Sinologic sabe (o debe saber) lo que es SSL y TLS, al menos sabrá que son algoritmos de cifrado que mantienen «segura» la comunicación entre dos sistemas: un cliente y un servidor, un navegador y una web, un datáfono y un banco, … Pero acaba de darse a conocer algo que ha movido los cimientos de la seguridad, y es que el algoritmo SSL v.3.0 (el algoritmo utilizado por el 90% de las páginas) ha sido roto y por lo tanto, existen mecanismos para descifrar en tiempo real una comunicación cifrada con este sistema.
Google acaba de anunciar que el sistema de cifrado SSL v.3.0 tiene más agujeros que un queso suizo y que no debería ser utilizado nunca más. Esto implica a las páginas webs «seguras» https que incluyen en la URL su candado de colores. Si quieres saber en qué consiste el bug, se explica en muchas páginas:
¿Qué significa esto?
Que si te conectas a la página web de tu banco, compruebas que tiene el famoso «candado» en el navegador, e introduces tus datos de acceso, si te logueas en Paypal para realizar un pago, alguien podría tener algún sniffer que guarde esta información y la utilice cuando menos lo esperes.
¿Cómo funciona?
Dicho de un modo comprensible… los servidores web y los navegadores incorporan diversos algoritmos de cifrado, SSL v.3, SSL v.2, TLS 1.0, TLS 1.1, TLS, 1.2… y cuando un navegador se conecta a un servidor web «seguro» se negocia el algoritmo de cifrado que se va a utilizar. Generalmente, empiezan por el más nuevo y si ambos no soportan el mismo sistema de cifrado, van bajando la versión hasta dar con algún algoritmo que tengan en común.
Hoy día, los servidores web seguros ya no incluyen algoritmos antiguos como SSL v.2 ni TLS 1.0, pero sí incluyen SSL v.3.0 y TLS 1.1 y TLS 1.2.
Hoy día, el algoritmo SSL v.3.0 ha sido roto y por lo tanto, cualquier comunicación navegador – servidor web que utilice dicho algoritmo es vulnerable y puede ser objeto de espionaje y robo de información.
¿Cómo se soluciona?
Por un lado, hay que entender que para que no nos «espíen» tenemos que configurar nuestro navegador para indicar que no queremos utilizar el cifrado SSL v.3.0, de esa manera, en la negociación de algoritmos, nuestro navegador buscará otro sistema común que nos permita mantener una comunicación cifrada y que funcione. Por otro lado, también debemos configurar nuestros servidores Web o servicios para que no utilicen el algoritmo SSL v.3.0 y de esa manera, evitar que espíen a usuarios cuyos navegadores permitan utilizarlo.
Vamos a ver algunas maneras sencillas de solucionarlo.
(más…)
2014-10-16
SIPCheck2 vigila tu Asterisk en busca de atacantes
Hace exactamente 4 años, en Sinologic lanzamos una aplicación llamada SIPCheck que se encargaba de monitorizar el log de Asterisk y vigilar los intentos de conexión por parte de bots y atacantes para así, añadirlos al firewall y crear una lista de atacantes pública y utilizable por cualquiera, algo similar a lo que hace la aplicación fail2ban aunque más orientado a Asterisk y, al reportar las direcciones IP a una base de datos general que pueda ser consultada por todos, más social y útil.
Tras 4 años, el resultado ha sido realmente interesante: más de 4000 direcciones IP atacantes y más de 400 usuarios detectando ataques ha hecho que desde Sinologic nos planteásemos una mejora considerable: SIPCheck2
En esta nueva versión, desarrollada en Python, permite, no solo informar de cualquier atacante, si no también recibir la lista de los atacantes que dos o más usuarios hayan reportado, adelantándonos a los posibles ataques incluso antes de que se produzcan.
Se han añadido alguna mejoras como posibilidad de no detectar «falsos ataques» de direcciones IP y redes «conocidas» (clientes, red local, pruebas, etc.).
Cuando nuestro SIPCheck2 detecta un atacante, lo reporta al servidor y esa dirección IP queda almacenada en tu cuenta, de forma que queda baneada automaticamente en todos los sistemas que compartan dicha cuenta.
Si otros sistemas reportan también la misma IP atacante, esa dirección pasa a ser oficialmente un atacante y es reportada a todos los usuarios de SIPCheck con otras cuentas.
Otra de las novedades es que las direcciones IP atacantes caducan, desapareciendo al cabo del tiempo, ya que está demostrado que pertenecen a sistemas zombies que tienen fallos de seguridad y que con el tiempo son bloqueados o arreglados y no tiene sentido que permanezcan más tiempo en nuestro firewall.
Como variante, incluye un archivo de configuración desde el que se puede modificar algunos parámetros para adaptarlo mejor a nuestro sistema, añadir direcciones IP y redes nuestras para evitar falsos positivos y algunas mejoras más.
(más…)
2014-06-03