¿Debería considerarse comprometido un servidor simplemente porque el puerto estaba abierto?

15

Hoy mismo recibí una notificación de un incidente de seguridad en Mandrill . Al principio, me preocupé, pero luego, después de adentrarme en los detalles, me confundí en cuanto a por qué consideraban esto digno de mención.

Para resumir, parece que Mandrill realizó algunos cambios en sus grupos de seguridad EC2, lo que hizo que algunos puertos de sus servidores de registro estuvieran accesibles a Internet durante unas semanas.

  

El 10 de marzo, descubrimos pruebas de que se hicieron intentos automáticos contra los servidores de registro interno de Mandrill en un esfuerzo por usarlos en una red de bots. El análisis de los servidores que se vieron afectados, incluidos los registros de tráfico de red y los archivos presentes en los servidores, indica que estos intentos no tuvieron éxito. No hay indicios de que los servidores hayan sido diseñados para acceder a los datos almacenados en ellos.

     

Investigamos el problema y encontramos que la oportunidad de este ataque surgió de un cambio en el cortafuegos que hicimos el 20 de febrero para controlar de forma más granular el acceso a algunos de los servidores de Mandrill. Partes de la infraestructura de Mandrill se alojan en los servicios web de Amazon (AWS), y usamos grupos de seguridad EC2 para controlar el acceso. Se hizo un cambio a un grupo de seguridad que contenía más servidores de los que pretendíamos afectar. Como resultado, se hizo público un grupo de servidores que alojan los registros de aplicaciones internas de Mandrill en lugar de permitir el acceso solo interno.

Ahora, todos tratamos con botnets todo el tiempo y es bastante conocido cómo mantener sus máquinas razonablemente a salvo de ellas. Sobre todo porque casi todo lo que ejecuto es público y veo millones de intentos de botnets, ninguno de los cuales tiene éxito en hacer nada más que generar entradas de registro.

Pero debido a esto, recomiendan que todos invaliden y cambien todas sus claves API. Personalmente, tengo cerca de una docena de claves API activas y me llevará más de una tarde cambiar todas estas en las que se deben cambiar.

Mi pensamiento personal es que han reaccionado de forma masiva a esto. Pero no lo sé todo. ¿Hay alguna razón por la que simplemente tener puertos abiertos se consideraría un compromiso potencial aquí?

    
pregunta Michael Hampton 19.03.2015 - 02:12
fuente

1 respuesta

16

Al leer la divulgación, parece que lo que sucede es que el puerto abierto no es en realidad solo un puerto aleatorio, sino que es un puerto donde un cierto servicio interno que nunca había sido diseñado para exponerse directamente al mundo externo estaba escuchando en Si existe una vulnerabilidad en ese servicio interno, eso podría haber permitido a un posible atacante obtener la clave API de los usuarios que usan su servicio dentro del período de tiempo especificado.

Si bien notan que el ataque parece un ataque automatizado en lugar de un ataque dirigido, se debe considerar que los atacantes sofisticados a menudo usan un ataque automatizado altamente visible para desviar la atención del servidor y del administrador de sistemas de otro ataque encubierto y dirigido que están sucediendo al mismo tiempo, es decir, la gran DDoS que causa mucha atención es solo una desviación.

Un atacante sofisticado podría haber borrado sus huellas si hubiera logrado obtener privilegios en el sistema para que pareciera que nadie ha comprometido datos importantes. Esta es la razón por la que recomiendan cambiar sus claves de API, a pesar de que no encontraron evidencia de que los datos realmente fueron consultados. Especialmente porque se trata de un servidor de registro que se vio comprometido, y dado que sysadmin usualmente usaría los registros para detectar el compromiso, un servidor de registro comprometido puede ocultar lo que realmente sucede.

Un atacante sofisticado también podría haber dejado una puerta trasera / rootkit en el sistema para permitirse volver a ingresar al sistema en una fecha posterior, cuando todos pensaron que las cosas se habían calmado, para poder atacar a un ritmo más pausado desde el interior del Límite de seguridad, que podría ser altamente peligroso. Es por esto que están retirando la máquina involucrada.

O podría ser que estén haciendo esto como un espectáculo para algunos posibles clientes preocupados por la seguridad que están en la barrera de las decisiones de compra debido a dudas sobre su seguridad. Esto podría cambiar la actitud de los clientes potenciales para decidir aceptar su servicio, ya que ahora están seguros de que la compañía no se quedaría callada cuando hay vulnerabilidades que podrían afectarlos.

  

¿Hay alguna razón por la que simplemente tener puertos abiertos se consideraría un posible compromiso aquí?

Sí, el puerto abierto expone un servicio interno que no fue diseñado para uso externo. Los servicios destinados a uso interno a menudo carecen del refuerzo de seguridad que obtendrían los servicios públicos, ya que se supone que el servicio solo es accesible desde máquinas confiables. Por ejemplo, es posible que un servicio interno no use SSL para comunicarse dentro de la red de confianza, o que no validen sus entradas tan a fondo como suponen que los remitentes de confianza ya hacen las validaciones necesarias, o pueden tener comandos administrativos que se pueden usar sin autenticación , porque asumió que las autenticaciones necesarias han sido realizadas por los servicios públicos.

    
respondido por el Lie Ryan 19.03.2015 - 13:03
fuente

Lea otras preguntas en las etiquetas