Herramientas simples para buscar en la memoria del proceso las cadenas de conexión MSSQL

Los atacantes utilizan de forma común el malware de rastreo de memoria para rastrear los números de cuenta de los sistemas POS. La mayoría de los raspadores de RAM están controlados por una expresión regular configurable, donde los atacantes buscan en la memoria de otro proceso el patrón de un número de cuenta.

El atacante puede configurar completamente el patrón que se está buscando. No habría nada que impida que dicho software se reconfigure para buscar cadenas de la memoria de otra aplicación como "Provider=", "UID=", "PWD=" u otros datos que puedan estar presentes en una cadena de configuración de la base de datos.

Si los atacantes lo han hecho o no en la vida real, es una pregunta para los investigadores forenses (o los atacantes).

Ha demostrado uno de los inconvenientes de usar la autenticación de SQL Server en lugar de la autenticación de Windows. Es por esto que Microsoft recomienda usar la autenticación de Windows a menos que tenga una buena razón para no hacerlo. Aquí es una descripción de los pros y los contras de cada uno. En particular:

  

La contraseña de inicio de sesión autenticada de SQL Server cifrada, se debe pasar a través de la red en el momento de la conexión. Algunas aplicaciones que se conectan automáticamente almacenarán la contraseña en el cliente. Estos son puntos de ataque adicionales.

Aquí es otro artículo de Microsoft que habla sobre cómo asegurar la conexión de SQL Server cadenas para Entity Framework, pero las mismas reglas se aplican incluso si no está utilizando EF. Esta declaración reitera por qué recomiendan usar siempre la autenticación de Windows:

  

Tenga en cuenta que la información de inicio de sesión y las contraseñas pueden estar visibles en un volcado de memoria.

     

Cuando la información de inicio de sesión y contraseña del origen de datos se proporciona en la cadena de conexión, esta información se mantiene en la memoria hasta que la recolección de basura recupera los recursos. Esto hace que sea imposible determinar cuándo una cadena de contraseña ya no está en la memoria. Si una aplicación falla, un archivo de volcado de memoria puede contener información de seguridad confidencial, y el usuario que ejecuta la aplicación y cualquier usuario con acceso administrativo a la computadora pueden ver el archivo de volcado de memoria. Use la autenticación de Windows para las conexiones a Microsoft SQL Server.

¿En cuanto a si alguna aplicación de malware existente se aprovecha de esto? Ciertamente, sabemos que pueden existir, y usted mismo lo ha demostrado. Todo lo que se requiere es que una aplicación se ejecute con suficientes permisos para ver la memoria de otra aplicación que almacena las contraseñas en la memoria. La parte difícil es que es probable que necesites saber cómo está distribuida la memoria para poder aprovechar esto. En otras palabras, probablemente necesite saber cómo funciona primero la aplicación, y luego construir el rastreador de memoria a su alrededor. Quizás hay palabras clave generales que podrías buscar, pero eso requeriría un poco de suerte. Algo así como buscar en el fondo del océano barcos perdidos que aún podrían tener algunos tesoros en ellos; en algún punto, el costo / recompensa simplemente no hace que valga la pena.

Dicho esto, si supiera que una aplicación particular (popular) tenía este tipo de falla de seguridad, podría intentar diseñar un malware que se adapte a esa aplicación, y luego dirigirse a los usuarios de esa aplicación para intentar convencerlos. para instalar su malware en la misma máquina.

Todas las respuestas proporcionadas fueron útiles, pero ninguna en realidad me indicó una herramienta que lo hace rápida y automáticamente. Yo mismo escribí uno que escanea rápidamente la memoria de un proceso de Windows usando ajustes configurables. Aquí está el proyecto en Github si es útil para alguien más:

memvulnscan

Creo que la ruta más probable para un atacante sería simplemente rastrear el cable de la contraseña. Si un atacante tiene un nivel de acceso lo suficientemente bajo como para rastrear la memoria, también debe tener suficiente acceso para ejecutar un rastreador de paquetes y simplemente buscar cadenas de conexión de SQL Server en el cable no cifrado. (SQL Server generalmente tiene una conexión sin cifrar).

Entonces tendría la ventaja adicional de poder detectar cualquier otra conexión sin cifrar, que para las aplicaciones empresariales son muchas. Con la arquitectura de rastreador correcta, sería trivial poder agregar cosas nuevas e interesantes para rastrear, incluidas las conexiones de SQL Server.

Si este malware existe, no lo sé, pero tiene un propósito mucho más general que el que se dirige específicamente a la autenticación de SQL Server.