Estoy trabajando en una tesis sobre la comunidad de hackers de seguridad.
Cuando se publica un día 0, ¿cómo puede un administrador proteger su aplicación / sitio web entre el momento en que se publica el día 0 y se desarrolla el parche?
Además, la mayoría de las veces, este mismo día se usa durante meses por los blackhats, ¿así que los blackhats están por delante de los whitehats?
La persona que descubre un problema de seguridad a menudo lo informa primero al proveedor de software o al desarrollador. Esto le da tiempo al proveedor de software para solucionar el problema antes de la publicación. Luego, una vez que se soluciona, el error se revela públicamente. Este proceso se llama divulgación responsable .
A veces, alguien no revela el día cero al proveedor de software, sino que lo utiliza para piratear otros sistemas. Hacer esto puede alertar a las compañías de seguridad y revelar el error, quemando el día cero .
No creo que tu declaración "la mayor parte del tiempo, este mismo día se use durante meses con sombreros negros" es cierto. Esto es cierto para algunos problemas de seguridad, pero muchos piratas informáticos detectan por primera vez muchos errores de día cero. No diría que los hackers de sombrero negro están por delante de los hackers de sombrero blanco. Ambos encuentran problemas de seguridad y algunos de estos se superponen. Sin embargo, la ofensiva es más fácil que la defensa, ya que la ofensiva solo necesita encontrar un error y la defensa debe corregir todos los errores.
Cuando se publica un día 0, ¿cómo puede un administrador proteger su aplicación / sitio web entre el momento en que se publica el día 0 y se desarrolla el parche?
Utilizan soluciones temporales hasta que se implementa un parche.
Cuando se publican las noticias de un día, a menudo se publican varias soluciones que rompen la vulnerabilidad al eliminar algunos requisitos previos para abusar de la vulnerabilidad. Hay muchas posibilidades:
El cambio de una configuración puede deshabilitar la funcionalidad vulnerable.
Desactivar los servicios vulnerables, cuando sea práctico, puede evitar la explotación.
Habilitar medidas de seguridad no predeterminadas puede interrumpir la explotación.
Cada error es diferente, y cada mitigación es diferente. Un administrador con una buena comprensión de la seguridad puede descubrir soluciones por su cuenta si se publican suficientes detalles sobre la vulnerabilidad. Sin embargo, la mayoría de los administradores consultarán los avisos de seguridad publicados por el proveedor de software.
A veces, un administrador no tiene que hacer nada . Este puede ser el caso si la vulnerabilidad solo afecta una configuración no predeterminada o una configuración que no está establecida en sus sistemas. Por ejemplo, una vulnerabilidad en el subsistema de video DRM para Linux no debe preocupar a un administrador de sistemas con una pila LAMP, ya que sus servidores no usarán DRM de todos modos. Una vulnerabilidad en Apache, por otro lado, podría ser algo de lo que deberían preocuparse. Un buen administrador de sistemas sabe lo que es y no es un factor de riesgo.
Además, la mayoría de las veces, este mismo día se usa durante meses por los blackhats, ¿así que los blackhats están por delante de los whitehats?
Los whitehats son más sofisticados, pero los blackhats son más eficientes.
Si los blackhats están o no por delante de los whitehats es una pregunta muy subjetiva. Blackhats utilizará lo que funcione. Esto significa que sus hazañas son efectivas, pero sucias y, a veces, poco sofisticadas. Por ejemplo, si bien es posible descubrir el diseño de ASLR de un navegador a través de ataques de canal lateral, esto no se usa realmente en la naturaleza, ya que ya existen omisiones omnipresentes de ASLR. Por otro lado, los blancos tienen que pensar arreglos y, de hecho, hacer que el proveedor de software se tome en serio el informe. Esto no afecta a los blackhats en la misma medida, ya que a menudo pueden comenzar a beneficiarse de su descubrimiento en el momento en que lo logran. No necesitan esperar a un tercero.
Desde mi propia experiencia, los blackhats a menudo tienen una ventaja significativa. Esto se debe principalmente a que la cultura actual entre los blancos es cazar y aplastar insectos individuales. Se pone menos énfasis en aplastar clases enteras de errores y, cuando lo es, se crean las mitigaciones por debajo del nivel y sobreescritas (como KASLR). Esto significa que los blackhats pueden bombear 0 días más rápido de lo que pueden ser parcheados, ya que se presta poca atención al área de la superficie de ataque y a los vectores de explotación que se siguen utilizando y reutilizando.
Cuando se publica o publica un día cero, viene con más que un simple nombre e icono. Hay detalles sobre cómo se utiliza el día cero para explotar el sistema. Esos detalles forman la base de la respuesta del defensor, incluido cómo El parche necesita ser diseñado.
Por ejemplo, con WannaCry / EternalBlue , la NSA descubrió la vulnerabilidad y mantuvieron el conocimiento para sí mismos ( lo mismo sucede en la comunidad criminal donde las vulnerabilidades se pueden comercializar en el mercado negro). Los detalles se filtraron, lo que informó a Microsoft cómo crear el parche y también informó a los administradores cómo defenderse: deshabilite SMBv1 o al menos bloquee el puerto SMB de Internet.
Así es como los administradores se protegen a sí mismos. La aplicación de parches es solo una parte de la "administración de vulnerabilidades". Hay muchas cosas que un administrador puede hacer para administrar las vulnerabilidades, incluso si no pueden o no desean aplicar parches.
En el caso de WannaCry, el NHS no corrigió, pero tampoco emplearon las otras defensas que se habrían protegido.
Una gran parte de mi trabajo es diseñar mitigaciones de vulnerabilidad para sistemas que no pueden ser parcheados por varias razones comerciales. La aplicación de parches es la mejor solución, en general, pero a veces simplemente no es posible en el momento de la aplicación de parches.
... ¿los blackhats están por delante de los whitehats?
Eso plantea un problema interesante. Si un blackhat encuentra un problema y solo lo comparte con otros blackhats (u otros miembros de la comunidad de inteligencia), ¿eso significa que los blackhats, en agregado , están por delante de los whitehats? Sí. Una vez que se expone un día cero, pierde su poder (ese es el punto de revelación). Así que para mantenerlo en secreto, le da poder.
¿Los blackhats están mejor capacitados o usan mejores técnicas que los whitehats? No. Pero los secretos compartidos le dan a los blackhats más poder, en conjunto.
Cuando se publica 0 días, ¿cómo puede un whitehat proteger su aplicación / sitio web entre el momento en que se publica 0 días y se desarrolla el parche?
A veces hay soluciones que solucionan o mitigan el problema.
/usr/tmp/sh . Esto confundió al gusano e impidió que funcionara. Pero a veces ninguno de estos es una opción viable. En ese caso, solo puedes esperar que haya un parche pronto.
Además, la mayoría de las veces, este mismo día se usa durante meses por los blackhats, ¿así que los blackhats están por delante de los whitehats?
Sucede con bastante frecuencia que los desarrolladores / whitehats descubren una posible vulnerabilidad de seguridad en su software y lo parchean antes de que sea explotado. El primer paso de la divulgación responsable es informar a los desarrolladores para que puedan corregir la vulnerabilidad antes de publicarla.
Pero usualmente no escuchas sobre eso en los medios. Cuando el punto 59 de las notas de parche para SomeTool 1.3.9.53 lee "posible desbordamiento de búfer posible al procesar archivos de foobar con formato incorrecto", por lo general no es de interés periodístico.
La mayoría de las posibles explotaciones requieren una cadena de vulnerabilidades para poder ejecutarse. Al leer el día cero aún sin parchear, aún puede identificar otras vulnerabilidades o condiciones previas que requeriría el día cero.
Para defenderse contra la amenaza de (digamos) un ataque RDP desde fuera de la red (se publicó un error de autenticación RDP de día cero), no permita RDP desde fuera del sitio. Si realmente no necesita un PDR de afuera, entonces esta es una oportunidad para corregir un descuido. O, si debe tener RDP desde fuera del sitio, tal vez pueda identificar una lista blanca de IPs desde las cuales permitir estas conexiones, y reducir la apertura en el firewall.
Del mismo modo, para defenderse de una amenaza RDP interna (y en cierta medida externa), limite la capacidad de A) de los usuarios para ejecutar máquinas RDP, B) para ejecutar RDP, C) la red para pasar máquinas RDP, D) para aceptar RDP, E) usuarios para permitir RDP. ¿Qué VLAN deberían tener la capacidad de generar RDP de salida? ¿Qué máquinas deberían poder hacer esto? Etcétera.
Cada uno de estos pasos, tanto en el escenario externo como en el interno, trabaja para fortalecer su red contra una explotación de autenticación RDP incluso sin un parche.
Una mentalidad de defensa en profundidad le permite romper la cadena de vulnerabilidades / condiciones requeridas incluso para contrarrestar un día cero sin parches. A veces.
He elegido intencionalmente un problema bastante sencillo aquí para ilustrar el punto.
Fuente - He hecho esto antes.
El problema no es solo con cero días. Hay muchas empresas que aún arrastran parches de 200 días por una multitud de razones (algunas buenas y otras malas).
Tiene una gran lista de soluciones, otra es usar parcheo virtual . Por lo general, crea una mitigación para el problema antes de que llegue al servicio (lo aprendí hace años, aunque a producto de Trend Micro : no tengo vínculos, pero lo probé y funcionó en su mayor parte).
Otra defensa clave es monitorear y conocer tu sistema.
¿Dónde están tus valiosos secretos y quién tiene acceso a ellos?
Si alguien intenta conectarse a su servidor de correo en el puerto 80, marca roja.
¿Por qué el servidor de correo, de repente, envía tráfico a una IP inusual?
El servidor de correo ahora tiene 10 veces más tráfico, ¿por qué?
Supervise a las personas que se conectan a las direcciones de su IP externa. Descarte y / o bloquee todos los puertos y protocolos externos que no estén en uso.
Ningún usuario legítimo se conectará a su servidor web en nada que no sea 80 o 443. A menos que haya agregado servicios adicionales. Podría considerar bloquear esos IP por algún tiempo. A veces, la propiedad intelectual es parte de grupos dinámicos, y no siempre se puede resolver un problema con una lista negra, simplemente se eliminan los paquetes.
Si su empresa solo hace negocios en 1 país, tal vez debería bloquear todos los demás países.
Puede usar whois para encontrar el propietario global del rango de direcciones IP y, si está presente, use la información de contacto del administrador para notificar al propietario. Ellos pueden rastrearlo en su extremo. (Vale la pena intentarlo)
Debería recibir una notificación cuando cualquier sistema sea contactado por otro sistema de manera inesperada. Después de la primera, puede recibir una tonelada de notificación, pero si la (s) computadora (s) está (n) en su red, puede investigar ambos lados. Luego, elimínelo o en la lista blanca como tráfico esperado.
Estas herramientas de monitoreo también le notificarán acerca de las exploraciones de puertos, a menos que tenga un equipo de seguridad autorizado, nadie más debería realizar estas exploraciones.
Esté atento a los eventos regulares, y si se detienen misteriosamente, ¿por qué?
Compruebe si hay infecciones en la máquina. Si los servicios están deshabilitados, debe recibir una notificación con anticipación para que los cambios se esperen y no sean misteriosos.
Bloquee tanto como sea posible y supervise el resto.
Ahora, una vez que tienes un ataque, debes hacer algo al respecto.
A veces, apagar el sistema temporalmente es la única opción. Tal vez necesite bloquear su dirección IP por un tiempo.
Aún tiene que proteger y monitorear todos sus servicios legítimos.
Además de monitorear la comunidad en busca de anuncios de vulnerabilidad. Debes tener probadores de penetración para encontrar los errores antes de los hackers. Entonces tienes la oportunidad de mitigar el ataque en tus términos. Notificar al mantenedor del sistema de efectos para que puedan parchearlo. Si es de código abierto, puedes hacer que alguien lo parche por ti.
Los sistemas de detección de intrusos, y snort también pueden examinar y potencialmente bloquear los ataques entrantes detectando patrones sospechosos.
Es posible que tenga que encontrar un producto alternativo para reemplazar el vulnerable, dependiendo de la gravedad del problema.
Como siempre mantener actualizado tu software ayuda a protegerte.
De esta manera puede bloquear actividades sospechosas, hasta que determine que es legítimo.
Relativamente pocos hacks permiten al atacante entrar en un sistema. La mayoría son errores de "escalada de privilegios" que permiten a un atacante tener un mayor control sobre el sistema después de tener acceso a él. Hay tantas formas de lograr el control administrativo de una máquina una vez que un hacker tiene acceso a ella, que es más o menos una pérdida de tiempo intentar asegurar una máquina contra la escalada de privilegios. Su mejor política es centrarse en evitar que los hackers entren y monitorear su red para detectar intrusiones.
Casi todas las intrusiones provienen de solo tres métodos. Quieres gastar todos tus recursos de defensa cibernética disponibles defendiéndote de estos. Ellos son:
(1) Correos electrónicos de phishing que contienen PDF o PPT envenenados. Hay toneladas de días cero dirigidos a PDF y PPT, y la naturaleza de estos dos formatos de aplicación es tal que no hay forma de protegerse contra un troyano contemporáneo en ninguno de los dos. Por lo tanto, básicamente tiene dos opciones: requerir que todos los archivos adjuntos PDF / PPT pasen por un proceso de verificación, que no es práctico para la mayoría de las organizaciones, o capacitar a sus empleados para que revisen los correos electrónicos ellos mismos, que es la mejor opción en la mayoría de los casos. Una tercera opción es probar todos los PDF y PPT enviados a la organización en un entorno de espacio aislado, pero esto solo es posible para organizaciones avanzadas, como el ejército, no la compañía promedio. La opción 3, por supuesto, no evita la intrusión, solo te avisa de inmediato si ocurre alguna.
(2) Vulnerabilidades del navegador. La gran mayoría de las vulnerabilidades basadas en el navegador se dirigen a Internet Explorer, por lo que puede defender probablemente el 95% de ellas simplemente impidiendo que los usuarios utilicen IE y exigiéndoles que utilicen Chrome o Firefox. Puede evitar el 99% de las vulnerabilidades basadas en el navegador al exigir a los usuarios que utilicen NoScript y capacitarlos en su uso, lo que desafortunadamente no es práctico para la mayoría de las organizaciones.
(3) Vulnerabilidades del servidor. Un ejemplo sería el error NTP de hace unos años. Puede defenderse en gran medida contra estos asegurándose de que todos los servidores de la empresa se ejecuten en redes aisladas (una "zona desmilitarizada") y de que esos servidores estén ajustados y no ejecuten servicios innecesarios. Especialmente desea asegurarse de que los servidores web de cualquier empresa se ejecuten solos en entornos aislados y que nada pueda entrar o salir de esos entornos sin que un ser humano haga la copia de forma controlada de forma explícita.
Por supuesto, hay muchas vulnerabilidades que quedan fuera de estas categorías, pero es mejor dedicar su tiempo a abordar las tres clases de vulnerabilidades enumeradas anteriormente.
Bueno, está bien tener 0 días desde un atacante, el problema es cuántos días cero tienen y cuánto cuesta quemar todos los 0 días en su red.
Si no tiene parches actualizados, se reduce el costo para que un atacante desarrolle una cadena de eliminación.
Cuando lo pienses, ¿cómo enviarías a comenzar a atacar una red? Digamos que empiezas con un ataque de phishing / un pozo de agua.
Si se trata de un ataque de pozo de agua, es posible que deba encontrar un día en flash de 0 días que le permita ejecutar código en el navegador y, luego, tal vez deba salir de la caja de arena del navegador, lo que requiere otro día. Y a continuación, podría enfrentar a appcontainer, que requiere otra vulnerabilidad para alcanzar el privilegio de nivel de sistema operativo. Y hay mecanismos de protección como SIP en macOS, lo que significa que incluso si tiene acceso de root, no puede acceder a la memoria importante. Eso significa que necesitas otro exploit de kernel 0day. Si ejecuta Windows 10 con cred guard y está apuntando a Lsass.exe, es posible que necesite otro día para atacar el hipervisor.
Por lo tanto, resulta que el ataque es muy costoso y requiere un gran esfuerzo de investigación, y mientras tanto, mientras los explota, puede activar una alerta de seguridad.
Entonces, como defensor, asegúrese de que conoce bien su red, tenga controles de defensa en cada capa y debe poder defenderse contra el ataque de 0 días.