Bienvenido al mundo despuéssangrado del corazón. Hemos parcheado nuestros servidores y estamos reemplazando nuestros certificados SSL. Pero el hecho de que nuestros servidores estén arreglados no significa que el resto de Internet esté arreglado. Tenemos empleados y ellos utilizan Internet para intercambiar secretos como números de tarjetas de crédito y credenciales de inicio de sesión. Nos buscan para que les aconsejemos.
Podemos aconsejar a nuestros clientes que utilicenuna página de prueba de Heartbleedpara ver si el sitio al que quieren ir tiene la vulnerabilidad. Si un sitio arroja resultados positivos, no intercambie secretos con él. Pero si un sitio nonoSi arroja positivo para Heartnet, entonces la situación puede ser cualquiera de:
- El sitio nunca tuvo la vulnerabilidad (buena)
- El sitio tenía la vulnerabilidad y la solucionó, pero todavía usa el certificado SSL posiblemente comprometido (malo)
- El sitio tenía la vulnerabilidad y la solucionó, y regeneró el certificado SSL pero sin regenerar claves (malo)
- El sitio tuvo la vulnerabilidad, la solucionó, regeneró claves y reemplazó el certificado SSL. (bien)
¿Existe algún medio que podamos brindar a nuestros empleados, antes de que ingresen su número de tarjeta de crédito en el formulario, para informarle albienescenarios de lamalo¿unos?
¿Cómo instruimos a nuestros empleados para que minimicen su exposición a servidores comprometidos por Heartbleed?
Respuesta1
Básicamente, no, no existe una única forma de distinguir los escenarios buenos de los malos, porque los usuarios no tienen una visibilidad completa de los sistemas que están utilizando.
Aún se desconoce en gran medida el alcance del daño causado por el error; la mayor parte del daño se produjo potencialmente en el pasado y seguirá afectando a Internet durante mucho tiempo. Simplemente no sabemos qué secretos fueron robados, cuándo ni quién.
Por ejemplo: el corazón OpenSSL de Google sangra durante aproximadamente un año. Adversarios desconocidos recolectan los servidores y buscan secretos interesantes (nuevamente, no hay manera de que sepamos si hicieron esto o no) hasta que encuentran una cuenta que pertenece a alguien con acceso autorizado a otro sistema, digamos Twitter.com o AnyBank. co.uk o dev.redhat.com. Con acceso a dichas cuentas, podrían seguir investigando, obteniendo acceso a otros sistemas, causando otros daños (visibles o no), comprometiendo aún más otras cuentas, sin que nadie sospeche el origen de la infracción. En esta etapa ya estás lejos de los sangrantes servidores OpenSSL, y esta es una de las consecuencias más desagradables de Heartbleed. A esto se suma el riesgo de que las claves privadas de los servidores se vean comprometidas.
La confianza tarda mucho en desarrollarse y puede perderse rápidamente. No digo que antes no tuviéramos problemas de confianza en Internet, pero Heartbleed definitivamente no ayudó. Reparar el daño llevará mucho tiempo, y comprender esto es parte de comprender cómo puede protegerse a sí mismo y a sus empleados/clientes/jefes, etc., y cómo no. Hay algunas cosas que puedes controlar para limitar tu exposición a la vulnerabilidad, y hay cosas que no puedes controlar, pero aun así te afectarán. Por ejemplo, no se puede controlar cómo los demás deciden responder a esta vulnerabilidad: según se informa, la NSA descubrió el error pero guardó silencio. Eso fue bastante malo para el resto de nosotros, pero no teníamos forma de protegernos contra ello.
Como usuario de Internet puedes y debes:
- Entenderque maloel error es
- NO responda ni siga enlaces en correos electrónicos que le indiquen que restablezca su contraseña; en su lugar, vaya directamente al sitio web de la empresa/organización y restablezca activamente su contraseña. En tiempos como estos a los estafadores les gusta hacer phishing
- Verifique si hay Heartbleed en su teléfono Android. Hay unaplicaciónde Lookout Mobile Security que verifica su versión de OpenSSL.
Verifique los sitios web que visita para detectar Heartbleed (lista de verificación incompleta):
¿El servidor utiliza OpenSSL?
- No: No te verás afectado directamente (por este error). Continúe usando el sitio, pero cambie su contraseña en caso de que otro servidor directa o indirectamente afectado por el error haya tenido acceso a su contraseña. Esto supone, por supuesto, que todos los servidores de esa red han sido parcheados, emitidos nuevos certificados... etc.
- Sí: Vaya a 2.
¿El servidor tiene una versión de OpenSSL sin Heartbleed? Asegúrese de que su herramienta check-for-heartbleed realmente busque la vulnerabilidad y no el encabezado HTTP o algún otro "indicador".
- No: No envíe ningún secreto al sitio, pero si es posible envíe una nota al webmaster.
- Sí: Vaya a 3.
¿Alguna versión anterior de OpenSSL tenía Heartbleed?
- No: Algunos administradores no actualizaron a la última versión de OpenSSL porque no se había probado en campo durante el tiempo suficiente. Sus servidores nunca fueron vulnerables a este error, pero por las razones expuestas anteriormente, es posible que sea mejor que cambies tu contraseña.
- Sí: El servidor era vulnerable y es posible que cualquier dato en la memoria se viera comprometido entre el momento de la actualización a la versión vulnerable y el momento de la divulgación (hasta dos o incluso tres años).
Aquí volvemos a la confianza: cuando pierdes la confianza de alguien, eso es algo malo. Especialmente si ese alguien es su usuario/cliente/jefe. Para recuperar su confianza, debes comenzar a construir de nuevo y abrirte al diálogo.
Esto es lo que un administrador web puede publicar para comenzar:
- Versiones anteriores de OpenSSL (vulnerables/no vulnerables)
- Versión actual y cuándo se actualizó.
Y si la versión anterior de OpenSSL era vulnerable:
- Cuándo se generó el certificado SSL actual
- Descripción detallada de cómo se ha revocado el antiguo certificado
- Garantía de que se utilizó un nuevo secreto para el nuevo certificado
- Sugerencias para los usuarios basadas en la información anterior
Si eres usuario, tienes todo el derecho a solicitar este tipo de información, y deberías hacerlo, por el bien de todos los usuarios del servicio. Esto aumentaría la visibilidad para la comunidad de seguridad y facilitaría a los usuarios minimizar su exposición a servidores comprometidos.