No reemplaza el certificado SSL en un servidor Unix reconstruido y anteriormente rooteado

1

Si un servidor estaba rooteado, hasta el punto en que sabemos que un script Perl que crea un shell remoto se colocó en el sistema de archivos de forma remota, y el servidor se reconstruyó por completo, parcheando la vulnerabilidad de Apache original que permitía esa explotación, pero la misma El certificado SSL se usó para la nueva configuración de Apache (sé que esto es una tontería); Suponiendo que el servidor web solo hace que algunos archivos PDF estén disponibles a través de HTTPS, ¿qué escenarios distintos a la posibilidad de descifrar el tráfico HTTPS de ese servidor a través de MITM ahora son probables (debido a que un intruso puede tener la clave privada, csr, etc.)?

TL; DR ¿cuánto daño se puede hacer teóricamente en un servidor Linux bien parcheado y con firewall que sirve documentos PDF a través de HTTPS si un atacante tiene la clave privada utilizada? Entiendo que pueden realizar MITM y descifrar el tráfico SSL.

    
pregunta Gregg Leventhal 07.09.2014 - 00:54
fuente

3 respuestas

2

Si el atacante tiene la clave privada, puede suplantarte por completo. Pueden realizar ataques MitM en su flujo de tráfico, pueden redirigir las solicitudes a su servidor de manera indetectable para el cliente, y así sucesivamente.

    
respondido por el Mark 07.09.2014 - 02:29
fuente
0

Si tienen su clave privada y usted no está usando PFS, podrían inyectar contenido malicioso en el tráfico, robar todo lo que pasa en ese Conexión HTTPS, redirigir a las personas que visitan el sitio web, etc. ¡Sé lo mejor que revocas tu antiguo CERT!

Si aún desea utilizar su antiguo certificado, entonces:

Cuando configure el servidor HTTPS, use SOLAMENTE el secreto de reenvío (por ejemplo, ECDHE-RSA-AES128-GCM-SHA256 y solo permita TLS 1.2):

  

El secreto hacia adelante está diseñado para evitar el compromiso de un a largo plazo   la clave secreta no afectará la confidencialidad de conversaciones pasadas.

Con un simple servidor de validación SSL de Calomel para Firefox o Qualys SSL Labs Server test, puede verificar si PFS está bien en su servidor o no.

Puede asignar una contraseña a la clave privada, pero aún estará en texto simple en la memoria.

Si su servidor solo proporciona archivos PDF estáticos a través de HTTPS, ¿por qué no usa OpenBSD?

¿Sabes dónde entraron? ¿Usted o alguien administró este servidor desde una máquina con Windows? ¡Quizás deberías limpiar allí también!

Use solo PFS para evitar estas situaciones en el futuro.

    
respondido por el user54652 07.09.2014 - 12:12
fuente
0

Es "solo" el problema de MITM, incluido que el atacante no le transmita la solicitud. Sin embargo, el atacante no puede simplemente descifrar su tráfico, también puede modificarlo. Por ejemplo, podría agregar un virus al pdf, o agregar algunas páginas / cambiar algunos números.

Un csr no es algo que deba mantenerse en secreto.

    
respondido por el user10008 07.09.2014 - 01:02
fuente

Lea otras preguntas en las etiquetas