¿Deben cifrarse y firmarse los volcados (por ejemplo, desde Breakpad, Windows)?

16

Como desarrollador de software, ¿mis archivos de volcado (por ejemplo, desde Breakpad, Windows) deben estar cifrados y firmados? Proporciono la capacidad de exportar volcados de fallos para que pueda identificar el problema cuando el usuario informa uno.

Mis preocupaciones, en términos de proteger mi producto (el atacante es un usuario que está pirateando el producto para obtener algo):

  • Los volcados proporcionan demasiada información para que los piratas informáticos realicen ingeniería inversa o pirateen el software. ¿Desea habilitar funciones o licencias?
  • Las contraseñas y las claves pueden almacenarse en los vertederos para que los piratas informáticos puedan piratear el software.
  • Un usuario podría devolvernos un volcado malintencionado malintencionado, lo que causa estragos cuando intentamos descifrar el volcado en nuestras máquinas. Si nuestra aplicación firma el volcado, al menos podemos abrir el archivo con confianza.

Actualización: Para el último punto, una de las respuestas me ha recordado que no hay ningún signo en la firma de los datos, ya que la clave debe estar en el producto, que el pirata informático puede entonces úsalo para firmar de todos modos. Además, el miedo a los volcados malintencionados se puede sortear mediante el uso de máquinas virtuales temporales.

La última preocupación restante es cómo los volcados, dado que contiene direcciones y cosas, podrían ayudar a los piratas informáticos a evitar restricciones como las funciones con licencia.

    
pregunta Ryuu 05.06.2018 - 10:47
fuente

3 respuestas

28
  

¿Los volcados proporcionan demasiada información para que los piratas informáticos realicen ingeniería inversa o pirateen el software, digamos para habilitar funciones o licencias?

Los volcados deben, en algún momento, existir sin cifrar. Un atacante con control local completo puede agarrar los vertederos en ese instante, o simplemente ignorarlos y mirar la memoria de la aplicación en ejecución a voluntad.

Algunos programas, como Spotify, intentan detectar si se están ejecutando en un entorno de depuración y utilizan varios esquemas de ofuscación para ralentizar la ingeniería inversa. Esto puede frustrar a los atacantes no experimentados o ralentizar a los experimentados. Pero probablemente no detendrá a un atacante. Esta es básicamente la razón por la que empresas como Microsoft optan por la validación de licencias en línea.

Sin embargo, el cifrado en tránsito es un asunto completamente diferente. La protección de los activos de los clientes que pueden estar disponibles en un volcado, o incluso las licencias instaladas en la computadora de un cliente, hace que esta sea una buena propuesta, asegurando que ningún tercero pueda acceder al volcado.

También es fácil de implementar; enviar el volcado, por ejemplo, https. Si bien la ganancia de esto puede ser pequeña, dependiendo del contenido de los volcados, también es muy barato de implementar y reduce los riesgos tanto para los datos suyos como de los clientes. Recuerde que su cliente probablemente valora sus datos más que su producto.

  

Un usuario podría devolvernos un volcado malicioso malicioso, que causa estragos cuando intentamos descifrar el volcado en nuestras máquinas. Si nuestra aplicación firma el volcado, al menos podemos abrir el archivo con confianza.

Para firmar los archivos, la aplicación tiene para acceder a una clave privada. La clave privada debe estar presente en la memoria de la máquina que realiza la firma en algún momento. Debe distribuirse con cada instancia del software.

Un atacante puede acceder a la clave y firmar su archivo de volcado malintencionado.

No servirá de nada usar los volcados como un vector de ataque.

    
respondido por el vidarlo 05.06.2018 - 14:51
fuente
5
  

[...] ¿deberían mis archivos de volcado [...] estar encriptados y firmados?

Alguien puede crear cualquier número de volcados con varias herramientas, como el Administrador de tareas, el Explorador de procesos, el ProcDump, WinDbg, Visual Studio, DebugDiag, WER, AdPlus (y potencialmente más) y no tienes oportunidad de interceptarlos. Un atacante no usaría su volcado de volcado Breakpad encriptado, sino que en su lugar creará sus propios volcados de volcado.

Sin embargo, debe asegurarse de cumplir con las normas de privacidad y de que solo personal autorizado pueda acceder a los vertederos. En ese caso, el cifrado puede ayudar, pero cualquier otro control de acceso también está bien.

  

¿Los volcados proporcionan demasiada información para que los piratas informáticos realicen ingeniería inversa o pirateen el software, digamos para habilitar funciones o licencias?

Una instancia en vivo de la aplicación da aún más información. Solo piense así: puede crear muchos volcados de memoria, por lo que tiene más información para analizar.

También: ¿sabía que puede influir en el tamaño del volcado de emergencia? Dependiendo de las opciones de MINIDUMP_TYPE , el volcado de seguridad contiene más o menos información.

  

Un usuario podría devolvernos un volcado con malformación maliciosa, lo que causa estragos cuando intentamos descifrar el volcado en nuestras máquinas.

De ti es posible, pero poco probable. Sería un error relacionado con la seguridad en el depurador como sea posible en cualquier otra aplicación. El depurador solo leerá la información del volcado de bloqueo, no la ejecutará.

¿Cómo le envía el atacante un volcado de emergencia sin identificarse?

    
respondido por el Thomas Weller 05.06.2018 - 22:19
fuente
3

Mi opinión personal es que dependerá del costo / beneficio para usted.

Firmar digitalmente los archivos si. Reducirá el trabajo y le permitirá recibir volcados de sus clientes reales. Para el transporte de información sí. Debe utilizar un canal encriptado y, si no es posible, cifrar los datos. Creo que es más fácil entregarlo utilizando https , por ejemplo, en lugar de intentar implementar algún método de cifrado en los datos que pueden fallar.

Localmente dependerá del paisaje.

Normalmente, los volcados no deberían estar permitidos por defecto y deberían estar habilitados solo para solucionar problemas específicos en servidores de producción.

Cuando está habilitado, es recomendable configurar una partición específica para volcados y para que se le permita el acceso a usuarios privilegiados, y nunca dejar los datos de volcado en reposo en el sistema, tan pronto como se genera, se debe mover desde Entorno de producción para el análisis.

En estas situaciones es una cosa controlada, e implementar el cifrado aquí no agregará ningún beneficio real.

Si tiene algún tipo de automatización que genera volcados y los entrega a su organización, le diría que sí, DEBE implementar el cifrado en todas partes, especialmente si el volcado puede tener datos de PII ... Los volcados en reposo que no se han eliminado o sobrescrito son una buena fuente de información sobre lo que se está ejecutando en el servidor.

Esto no es una práctica recomendada, ya que los servidores de producción deberían tener DUMPS deshabilitado y DEBUG también deshabilitado. Esto debería habilitarse solo cuando sea necesario y con algún administrador del sistema en vivo.

El cifrado traerá algunos desafíos que le costarán dinero.

infra PKI: Si posee la clave privada, a ninguno de sus clientes se les permitirá acceder a los datos a nivel local a menos que comparta la clave.

Si desea permitir que sus clientes tengan la clave privada para acceder a su volcado local, ingresará en un problema de administración de claves que puede llevar mucho tiempo, ya que tendrá que generar una clave privada por cliente.

La revocación de una clave requerirá la actualización de la aplicación en todos sus clientes ...

Clave síncrona: No tiene mucho sentido ya que la clave tendrá que existir en algún lugar del sistema para permitir el cifrado de los datos.

Cambiar la clave también será un desafío y llevará mucho tiempo.

    
respondido por el Hugo 05.06.2018 - 14:16
fuente

Lea otras preguntas en las etiquetas