Puede ser una pregunta tonta, pero los piratas informáticos utilizan herramientas disponibles públicamente para encontrar vulnerabilidades. Entonces, ¿por qué las empresas, antes de lanzar sus productos (Windows, Adobe, etc ...), usan las mismas herramientas para encontrar esas vulnerabilidades y corregirlas?
No entiendo. ¿Me estoy perdiendo algo?
Lo están haciendo, o al menos se espera que lo hagan, como parte de su Ciclo de vida de desarrollo de software (SDLC).
En términos de administración de vulnerabilidades, una mejor práctica sería realizar primero una revisión del código fuente (estática / dinámica), y escanear su producto usando una escáner de vulnerabilidad . Tenga en cuenta que también hay otros pasos para imponer un SDLC seguro, como el modelado de amenazas, las pautas de codificación segura, etc. que también deben realizarse.
En la vida real , esto es el 90% del tiempo visto como una actividad "inútil", porque requiere recursos pero no genera ingresos ni agrega nuevas funciones a la aplicación.
Además de la respuesta de ack_, hay una curva de aprendizaje importante para usar estas herramientas. Como analista de penetración, el tiempo empleado en eliminar falsos positivos y vulnerabilidades no explotables a menudo lleva tanto tiempo (si no más) como intentar aprovechar un ataque. Agregue a eso el tiempo que se necesita para convertirse en un experto en el uso de estas herramientas y se encontrará buscando ocupar otro puesto de TI a tiempo completo. Hydra, por ejemplo, debería ser una herramienta simple de usar, pero en mi experiencia es un PITA real. Las herramientas automatizadas son un buen lugar para comenzar, pero no tan valioso como un ingeniero experimentado.
Lo hacen (deberían), especialmente las compañías que deben cumplir con algunos estándares de seguridad como la industria de tarjetas de pago: PCI-DSS o iso 27001. Deben tener un SDLC seguro que incorpore capacitación de codificación segura, revisión del código por un experto en seguridad (blanco pruebas de caja), y pruebas de penetración periódicas (pruebas de caja negra) también realizadas por compañías externas. También toda la red y no solo las aplicaciones se someten a evaluación.
Los errores de software se descubren principalmente a través de la auditoría de código fuente, la ingeniería inversa y la eliminación de fallas. Fuzzer es la herramienta que puede denominarse como "la herramienta hacker" que usted mencionó. Google invierte miles de horas en difuminar Chrome y otro software crítico antes de su lanzamiento. Adobe también está siguiendo estas prácticas después del horrible abuso de vulnerabilidades en su producto Reader. La razón por la que la mayoría de las empresas de tamaño medio o bajo no pueden permitirse el uso de estas herramientas de manera efectiva es:
Nosotros, en seguridad, generalmente pensamos que los errores de seguridad son un gran negocio y deben ser tratados con la mayor importancia. Los equipos de software no piensan así. Al igual que Haroon Meer mencionado en la Keynote de Troopers15 la semana pasada, los jefes que reciben bonos y promociones basadas en las versiones de productos de software, cuando se encuentran errores después de meses o años, ya sea que hayan abandonado la empresa o estén en una posición intocable.
Además, ¿cuándo fue la última vez que una empresa se declaró en bancarrota después de que se encontraron errores de seguridad en su software? El software Adobe, Oracle, IE, Flash y CMS tiene un suministro casi ilimitado de errores de ejecución remota de código que se encuentran todos los meses, pero el negocio de ninguna de estas compañías se está haciendo efectivo. Esa es la razón por la que las empresas no dedican tiempo y esfuerzo a mitigar las vulnerabilidades. Simplemente no es crítico para el negocio.
Personalmente, utilizo herramientas y técnicas adversas para probar mis sistemas, redes y aplicaciones de destino. Para la capa web, como ejemplo, las herramientas como Acunetix WVS históricamente han sido invocadas por delincuentes en línea.
Metasploit es un mal ejemplo para este escenario propuesto por el interrogador (y como se alude en algunos de los comentarios). Un ejemplo mejor sería utilizar la simulación de adversarios a través del C2 maleable de Cobalt Strike para reutilizar las IoC del adversario real activo, como el tráfico de red y los hashes de archivos de malware en disco (o incluso en memoria).
Las técnicas de ingeniería social, o en realidad cualquier TTP, se pueden combinar estrechamente con eventos realistas. Este es más el propósito de un análisis de formación de equipos rojos, que se utilizará durante un ejercicio cibernético, que en una prueba de penetración. Las pruebas de penetración buscan comprender la perspectiva de un experto de confianza, como el desarrollador mismo, no la de un experto no intencional simple, como el phishing de lanza, los ataques de pozo de agua o similar.
Lea otras preguntas en las etiquetas vulnerability static-analysis code-review fuzzing