¡Qué registros buscar en Ubuntu cuando se hackea Postgres DB! [cerrado]

-3

Actualicé el título de la pregunta para aclarar que esta publicación no le pide a la comunidad que responda "cómo nos piratearon", sino "qué registros buscar o indicadores que puedan ayudar en nuestra investigación". Creemos que esta pregunta fue rechazada porque se entendió mal.

Nuestro Postgres DB fue pirateado y retenido por rescate. Hacker eliminó todas las tablas en la base de datos y creó una sola tabla llamada "advertencia" con una sola fila que pedía 0.5 BTC para devolver una copia de nuestra base de datos.

No tenemos ningún experto en seguridad residente ni ningún miembro de Ops, ni experto en Linux ni DBA.

¿Alguien podría sugerir dónde comenzar nuestra investigación? ¿Qué archivos de registro buscar para Postgres o Ubuntu o Red?

Afortunadamente, teníamos una copia de seguridad para poder restaurar nuestro sistema, pero aún no pudimos descubrir cómo nos piratearon.

Fila de la tabla de "advertencia". columna: warning_text: envíe 0.5 BTC a esta dirección y vaya a este sitio enlace para recuperar su base de datos. ¡El volcado de SQL estará disponible después del pago!

Actualizar: Más información Un poco más de información: SSH fue solo para iniciar sesión en esta instancia. Sin embargo, teníamos todos los puertos abiertos, lo que, sin duda, fue un error, pero fuimos un poco descuidados porque era nuestro entorno de prueba. Nuestra primera conjetura es que la contraseña predeterminada de la cuenta postgres db fue hackeada a través de la fuerza bruta, pero no sabemos dónde buscar para rastrear eso.

Los archivos de registro de Postgres tienen registros como el que se muestra a continuación, lo que muestra que algunos scripts sh estaban cargando la base de datos. Pero no sabemos qué registros buscar para rastrear cómo piratearon la contraseña y cómo / cuándo borraron las tablas en la base de datos y crearon la tabla de advertencia.

--2016-12-29 01: 01: 25-- enlace Conectando a 173.199.124.112:8090 ... conectado. Solicitud HTTP enviada, esperando respuesta ... 200 OK Longitud: 1061 (1.0K) [solicitud / x-sh] Guardando en: ‘/tmp/mpool.sh’

 0K .                                                     100%  249M=0s

2016-12-29 01:01:25 (249 MB / s) - ‘/tmp/mpool.sh’ guardado [1061/1061]

% Total% recibido% Xferd Velocidad media Tiempo Tiempo Tiempo actual                                  Carga de Carga Total de Velocidad Izquierda Gastada ^ M 0 0 0 0 0 0 0 0 -: -: - -: - - -: -: - 0 ^ M100 1061 100 1061 0 0 6567 0 -: -: - -: -: - -: -: - 6590

    
pregunta Sudeep Kaushik 02.03.2017 - 20:24
fuente

2 respuestas

2

Esa advertencia es irrelevante -

El ataque en sí podría haber sido a través de cualquier debilidad que tengas en tu red, a través de un phish, un servicio web o cualquier otra cosa.

Debes extraer todos tus registros de:

  • cortafuegos
  • enrutadores
  • plataformas host
  • sistemas de usuario final
  • base de datos
  • sistemas de gestión de ID / usuario, etc.

Luego analícelos juntos para comprender la línea de tiempo.

Sin embargo, este es realmente un trabajo forense calificado, si realmente quieres estar seguro de cómo sucedió.

En su lugar, es posible que desee trabajar con cada dispositivo, limpiar y reforzar (por ejemplo, eliminar contraseñas predeterminadas, parchear hasta actualizarse, agregar configuraciones de seguridad, etc.)

    
respondido por el Rory Alsop 02.03.2017 - 20:53
fuente
1

Además de lo que dice Rory, estos ataques son muy comunes con las bases de datos no seguras expuestas a Internet. Sé que están ocurriendo con MongoDB, pero cualquier plataforma de base de datos es posible suponiendo que esté expuesta a Internet y tenga una autenticación débil.

Para un rescate de .5 BTC, me imagino que el vector de ataque no era sofisticado. Es poco probable que pongan demasiado tiempo y esfuerzo en esto, y es probable que se haya automatizado de alguna forma.

Ahora con eso dicho:

  • Haga un inventario de su entorno. ¿Qué versión de SO / Frameworks / languages / Web server / PostgreSQL estabas ejecutando? ¿Hay alguna hazaña conocida para ellos? Compruebe expoit-db.com
  • ¿Qué puertos estaban abiertos en su firewall? ¿El TCP 5432 estuvo expuesto a Internet?
  • ¿Se permitieron conexiones remotas en la base de datos? Si es así, ¿qué usuarios pudieron iniciar sesión?
  • ¿Cómo eran tus contraseñas? ¿Eran complejos?
  • ¿Cómo se concedió el acceso SSH? ¿Se le permitió a la raíz acceso SSH remoto?

Debería terminar esto diciendo que no tengo experiencia formal en DFIR, sin embargo, creo que se puede asumir con seguridad que no fue un ataque demasiado sofisticado, por lo que comenzar con lo básico sería donde empezaría.

    
respondido por el DKNUCKLES 02.03.2017 - 21:11
fuente

Lea otras preguntas en las etiquetas