blog

Si se tiene la fortuna de tener acceso hacia el código fuente de la aplicación, el trabajo para realizar ingeniería inversa a la aplicación será más fácil. Se seguirá un proceso laborioso y largo para entender exactamente como la aplicación realiza cada tarea, pero esto debería ser más fácil comparado con abordar el binario de la aplicación correspondiente. Existen una serie de herramientas las cuales intentan escanear el código fuente automáticamente, para detectar prácticas de programación deficientes. Estas herramientas pueden particularmente ser útiles para aplicaciones grandes. Recordar estas herramientas automatizadas tienden a detectar casos comunes, y no ofrecen ninguna garantía de una aplicación sea segura.

Existen muchas herramienta para auditar el código fuente, las cuales están libremente disponibles en Internet. Algunas de ellas son cppcheck, flawfinder, splint, yasca, entre otros. Desde la perspectiva comercial se tienen a AppScan Source, Fortify, entre otros.

Claramente las herramientas para auditar código fuente puede centrar la atención de los desarrolladores en áreas problemáticas en el código, pero ¿Qué tan útiles son para los Hackers Éticos?. La misma salida está disponible tanto para los Hackers de sombrero negro, como las los de sombrero blanco, entonces ¿Cómo es probable cada uno de ellos utilice esta información?.

Perspectiva del Sombrero Blanco

El objetivo de un Hacker de sombrero blanco es revisar la salida de una herramienta para auditoría de código fuente, el cual debería hacer software más seguro. Si confiamos en estas herramientas apuntan con precisión al código problemático, será de mejor interés para el sombrero blanco, invertir tiempo corrigiendo los problemas anotados por estas herramientas.

Perspectiva del Sombrero Negro

El Hacker de sombrero negro, por definición, está interesado en descubrir como explotar un problema. La salida de las herramientas para auditoría de código fuente, pueden servir como un punto de partida para encontrar vulnerabilidades. Se tienen pocas razones para invertir tiempo arreglando el código, porque esto anula su propósito. El nivel de esfuerzo requerido para determinar si un posible punto problemático es vulnerable, es generalmente mucho mayor comparado con el nivel de esfuerzo de un sombrero blanco para arreglar este mismo punto problemático. Y al igual de un sombrero blanco, la salida de las herramientas para auditoría no es definitivo. Es totalmente posible encontrar vulnerabilidades en áreas de un programa no marcado durante la auditoría automatizada del código fuente.

Perspectiva del Sombrero Gris

¿Dónde encaja el Hacker de sombrero gris?. Frecuentemente su trabajo no es arreglar el código fuente auditado. Sin duda debe presentar sus hallazgos a los mantenedores del software, pero no hay garantía de se actuará sobre la información, especialmente si no tienen el tiempo, o peor aún, se niegan a considerar seriamente la información proporcionada. En casos donde los mantenedores se niegan a abordar los problemas señalados en una auditoría de código fuente, ya sea de forma automática o manual, puede ser necesario proporcionar una demostración “prueba de concepto” de la vulnerabilidad del programa. En estos casos el sombrero gris debe entender como hacer uso de los resultados de la auditoría para ubicar las vulnerabilidades reales, y desarrollar un código de prueba de concepto para demostrar la gravedad de estas vulnerabilidades. Finalmente, es posible el auditor ayude a desarrollar una estrategia para mitigar las vulnerabilidades, en ausencia a una solución del proveedor, así como desarrollar herramientas para ubicar automáticamente todas las instancias vulnerables de una aplicación dentro de la red de la organización.

Auditoría Manual de Código Fuente

¿Cómo se puede verificar todas las áreas de un programa, las cuales han sido omitidos por los escáneres automáticos?. ¿Cómo se analizan las construcciones de programación demasiado complejas para ser seguidas por las herramientas automáticas de análisis?. En estos casos , la auditoría manual del código fuente puede ser la única opción. El enfoque principal deben ser las formas en las cuales los datos proporcionados por el usuario se manejan dentro de la aplicación. Debido a la mayoría de vulnerabilidades se aprovechan cuando los programas no pueden manejar la entrada del usuario de manera adecuada, es importante comprender primero como se pasan los datos hacia una aplicación, y segundo, aquello suscitado con los datos.

Auditoría Automática de Código Fuente

Era solo una cuestión de tiempo hasta a alguien se le ocurriera una herramienta para automatizar algunas de las revisiones comunes en el código fuente. Estas herramientas automatizan el proceso, aunque se debe siempre tener en consideración, no son la solución absoluta, ni sus resultados son totalmente fiables.

Fuentes:

https://www.owasp.org/index.php/Source_Code_Analysis_Tools
https://blackarch.org/code-audit.html

Las vulnerabilidades existen en el software por un diverso número de razones. Algunas personas podrían decir, todas estas provienen de la incompetencia del programador. Aunque hay quienes nunca han visto un error en la compilación. En la actualidad las razones son mucho más variadas y pueden incluir:

• Falta de verificación para las condiciones de error
• Pobre comprensión sobre los comportamientos de las funciones
• Protocolos diseñados pobremente
• Inadecuadas pruebas para las condiciones de límites

Así como se puede examinar una pieza de software, se pueden buscar problemas como los antes mencionados. La facilidad con la cual se pueden encontrar estos problemas dependen de un número de factores:

• ¿Se tiene acceso hacia el código fuente del software. Si es así, el trabajo para encontrar vulnerabilidades puede ser más fácil porque el código fuente es mucho más fácil de leer a comparación del compilado?
• ¿Cuanto código fuente existe?. Software complejo está constituido de miles (quizás decenas de miles) de líneas de código, el cual requerirá mucho tiempo para analizar, comparado con piezas de software pequeñas.
• ¿Cuales herramientas están disponibles para ayudar a automatizar algunos o todos los análisis del código fuente?
• ¿Cual es el nivel de experiencia requerido en un lenguaje de programación determinado?
• ¿Se está familiarizado con áreas problemáticas comunes para un lenguaje determinado?
• ¿Qué sucede cuando el código fuente no está disponible y sólo se tiene el acceso hacia un binario compilado?
• ¿Se tiene herramientas para ayudar a entender los archivos ejecutables?. Herramientas como desensambladores y descompiladores pueden drásticamente reducir la cantidad de tiempo para auditar un archivo binario.

Fuentes:

https://ethics.csc.ncsu.edu/intellectual/reverse/study.php
https://beginners.re/

Con todas las diversas técnicas ya conocidas sobre Hacking Ético y Pruebas de Penetración, la pregunta es ¿Porqué se querría recurrir a algo supuestamente tan tedioso como la ingeniería reversa?. Pues se debería estar interesado en la ingeniería inversa, si se requiere expandir las habilidades y conocimientos sobre evaluación de vulnerabilidades, más allá de únicamente utilizar las herramientas y trucos estándar. No hace falta tener muchas capacidades para ejecutar un escaner de vulnerabilidades y reportar sus resultados. Desafortunadamente tales herramientas únicamente pueden reportar aquello lo cual conocen. No pueden reportar vulnerabilidades no descubiertas, y es aquí donde las habilidades y conocimientos sobre ingeniería inversa son relevantes.

Si se requiere ir más allá de las características estándar de las herramientas para encontrar vulnerabilidades, como Metasploit Framework, probablemente se requiera desarrollar al menos algunas habilidades rudimentarias sobre ingeniería inversa. Los investigadores de vulnerabilidades utilizan una variedad de técnicas sobre ingeniería inversa, para encontrar nuevas vulnerabilidades existentes en el software. Se puede estar complacido al esperar la comunidad en seguridad en general, descubra y publique vulnerabilidades para los componentes de software más comunes utilizados por el cliente, durante una prueba de penetración. Pero, ¿Quién hace el trabajo para descubrir problemas con una aplicación personalizada de nóminas creada por un tercero para el departamento de contabilidad?. El poseer algunos conocimientos y habilidades sobre ingeniería inversa puede proporcionar grandes réditos, si se requiere realizar un análisis más detallado de software popular, o si se encuentran aplicaciones personalizadas, las cuales algunas organizaciones insisten en ejecutar.

Fuentes:

https://en.wikipedia.org/wiki/Reverse_engineering
https://www.eff.org/issues/coders/reverse-engineering-faq

¿Dónde encaja la ingeniería inversa para el profesional en Hacking Ético y Pruebas de Penetración?. La ingeniería inversa es frecuentemente vista como el arte del “Cracker”, quien utiliza sus conocimientos y habilidades para eliminar la protección de copia desde un software o medio. Como resultado de esto, se podría dudar en emprender cualquier esfuerzo de ingeniería inversa. DMCA (Digital Millennium Copyright Act), se presenta frecuentemente cuando se discute la ingeniería inversa de software. De hecho, la ingeniería inversa se aborda específicamente en las disposiciones antielusión de la DMCA.

No es el propósito debatir los méritos de la DMCA, pero lo resaltante es el aún ser utilizada para evitar la publicación de información relacionada con la seguridad obtenida a través del proceso de ingeniería inversa. Es bueno mencionar, el explotar un desbordamiento de buffer en un servidor de red, es algo diferente a romper el esquema de administración de derechos digitales protegiendo un archivo “mp3”. (DRM). Se puede argumentar razonablemente, esta situación se aleja de la DMCA, mientras la segunda aterriza justo en el medio de esta.

Cuando se trata con trabajos relacionados a derechos de copia, dos secciones de la DMCA son de principal interés para el profesional en Hacking Ético y Pruebas de Penetración, las secciones 1201(f) y 1201(j). La sección 1201(f) aborda la ingeniería inversa en el contexto de aprender a interoperar con el software , el cual no es lo buscado en una evaluación de vulnerabilidades típica. La sección 1201(j) aborda las pruebas de seguridad, y se relaciona más cercanamente hacia la misión del profesional en Hacking Ético y Pruebas de Penetración, en el sentido de ser más relevante cuando se trata de ingeniería inversa hacia un mecanismo para el control de acceso. El punto esencial es estar permitido de realizar tal investigación, siempre y cuando se tenga el permiso del propietario del sistema, y se esté actuando de buena fe para descubrir y asegurar posibles vulnerabilidades.

Fuentes:

https://en.wikipedia.org/wiki/Digital_Millennium_Copyright_Act

En los recientes años, los proveedores han adoptado algunos principios como parte de sus programas para recompensar el reporte de fallas. Microsoft por ejemplo, alguna vez mencionó el hecho de no demandar a los investigadores quienes envíen de manera responsable las potenciales vulnerabilidades de seguridad en los servicios en linea. Mozilla también tiene un programa para la recompensa de errores, por informes válidos o vulnerabilidades críticas. Google también ofrece recompensas en efectivo por las vulnerabilidades encontradas. Las organizaciones incluso han desarrollado un plan de negocios para administrar estos programas para la recompensa de errores. Un ejemplo de esto es BugCrowd, el cual es un sitio donde se reúnen a profesionales en evaluaciones de seguridad con clientes quienes desean el software sea aprobado, y estén dispuestos a pagar por esto.

Aunque más y más proveedores de software están reaccionando apropiadamente cuando se reportan vulnerabilidades (debido a la demanda en el mercado de sus productos), muchas personas creen los proveedores no gastarán dinero adicional, tiempo, y recursos para realizar este proceso adecuadamente, hasta encuentren algún problema legal con la seguridad el software. Estos posibles problemas legales de los proveedores de software, los cuales podrían o no enfrentar, están ganando impulso en la industria.

“Zero-Day Initiative” (ZDI) es otra organización la cual paga por la divulgación de vulnerabilidades. Ofrece un portal web para los investigadores reporten y hagan un seguimiento de las vulnerabilidades. ZDI realiza identificaciones con los investigadores quienes reportan vulnerabilidades, incluyendo el investigador no esté relacionado a negocios con el gobierno de los estados unidos. ZDI valida la falla en un laboratorio antes de ofrecer al investigador un pago y contactar al proveedor. TRENDMICRO tiene un sistema para la prevención de intrusiones (IPS), y escribe filtros para cualquier área del cliente afectada por una vulnerabilidad. Las descripciones para los filtros están diseñados para proteger a los clientes, pero siguen siendo lo suficientemente vagas para mantener en secreto los detalles de las fallas no reportadas. ZDI trabaja con el proveedor para notificar al público cuando el parche este listo, y darle el crédito correspondiente al investigador, si este lo solicita.

Fuentes:

https://www.microsoft.com/en-us/msrc/bounty
https://www.mozilla.org/en-US/security/bug-bounty/
https://www.google.com/about/appsecurity/reward-program/
https://www.bugcrowd.com/product/bug-bounty/
https://www.zerodayinitiative.com/
https://www.trendmicro.com/en_us/business/products/network/intrusion-pr…

Aquellos quienes descubren vulnerabilidades usualmente están motivados para mejorar la protección de la industria. Esto realizado mediante la identificación y ayuda en la eliminación de software peligroso en los productos comerciales. Un poco de fama, admiración y derechos para jactarse son agradables también para aquellos con bastante ego. Los proveedores de otro lado, son motivados para mejorar sus productos, evitar problemas legales, no tener malas noticias en lo medios de comunicación, y mantener una imagen pública responsable.

No hay duda las fallas en el software son rampantes. Existen varios sitios webs como el de la CVE (Common Vulnerabilities and Exposures), la cual es una lista de entradas, conteniendo un número de identificación, una descripción y al menos una referencia pública; para vulnerabilidades conocidas en ciberseguridad. Otro sitio web es de la NVD (National Vulnerability Database), el cual es un repositorio del gobierno de los Estados Unidos de estándares basado en los datos sobre gestión de vulnerabilidades, representados utilizando un SCAP (Security Content Automation Protocol).

Las consideraciones para el reporte de vulnerabilidades incluyen aspectos financieros, legales, y morales, ya sea por parte de los investigadores y los proveedores. Las vulnerabilidades pueden implicar malas relaciones públicas para un proveedor, quien para mejorar su imagen, debe publicar un parche una vez la falla se hace pública. Pero al mismo tiempo, los proveedores deciden invertir más dinero en arreglar el software después de su liberación al público, en lugar de hacerlo perfecto (o casi perfecto) con antelación. De esta manera, utilizan los reportes sobre vulnerabilidades como una consultoría de seguridad postventa.

La divulgación pública ayuda a mejorar la seguridad, pues la única razón por la cual los proveedores parchan la vulnerabilidades es por la divulgación completa, y el no tener sentido mantener el error en secreto, pues los hackers lo descubrirán de todos modos. Antes de la divulgación completa, era demasiado fácil para las compañías de software ignorar estas fallas y amenazar al investigador con acciones legales. Ignorar las fallas era más fácil para los proveedores, especialmente porque una falla no reportada afecta más al usuario de software comparado con la afectación al proveedor.

Existe también una visión tenue sobre la divulgación pública de vulnerabilidades. Donde toda una economía de investigadores está intentado obtener provecho de las vulnerabilidades encontradas, para luego venderlas al mejor postor, ya sea esto con propósitos benignos o no. Estos investigadores buscan constantemente fama, donde la divulgación de vulnerabilidades es “recompensar el mal comportamiento”, en lugar de hacer mejor software.

Pero los investigadores de vulnerabilidades quienes encuentran y reportan fallas tienen una perspectiva diferente, especialmente cuando se les paga. Otro problema surgió, pues los investigadores están cansados de trabajar gratis sin ninguna protección legal.

Fuentes:

https://cve.mitre.org/
https://nvd.nist.gov/

Entender las fases para una divulgación responsable de vulnerabilidades es fundamental. Este procesose resume a continuación. Sin embargo se sugiere revisar el documento de la “Organization for Internet Safety”, o por su traducción al idioma español, La Organización para la Seguridad de Internet. La cual publicó hace muchos años un documento titulado “Guidelines for Security Vulnerability Reporting and Response”, o por su traducción al idioma español, Directrices para el Reporte y Respuesta de Vulnerabilidades de Seguridad. En este documento se incluye una metodología detallada, con ejemplos y mapas de procesos.

1. Descubrimiento de una falla encontrada. El investigador debe descubrir si una vulnerabilidad ha sido reportada o parchada, asegurarse de se puede reproducir de manera consistente, y asegurar impacte en la configuración por defecto. Si es así, el descubridor creará un reporte con el resumen de la vulnerabilidad (VSR).
2. Notificación. El descubridor envía su información de contacto, como también el VSR hacia el proveedor, refiriendo su política de seguridad. Estos detalles son enviados hacia la dirección listada en la política de seguridad, o hacia una de las direcciones estándar de correo electrónico establecidas. El proveedor debe responder en esta etapa.
3. Validación. El proveedor investiga y valida la vulnerabilidad. Actualizaciones de estado regulares hacia quien reportó son sugeridos en esta fase.
4. Hallazgos. Una vez el proveedor finaliza la investigación, la confirma, refuta o indica hallazgos no concluyentes. El proveedor es requerido de demostrar la investigación fue hecha, y típicamente cumple con este requerimiento proporcionando listas de productos, versiones y pruebas realizadas.
5. Resolución. Si una falla no es concluyente o es refutada, la debilidad puede ser hecha pública. Si es confirmada, el proveedor típicamente tendrá treinta días para emitir un parche o solución.
6. Liberación. El remedio es liberado, como también la notificación.

Fuentes:

https://www.sourcewatch.org/index.php/Organization_for_Internet_Safety
http://www.symantec.com/security/OIS_Guidelines%20for%20responsible%20d…

Antes de la lista Bugtraq fuese creada, los individuos quienes descubrían vulnerabilidades y las maneras de explotarlas, únicamente se comunicaban directamente los unos con otros. La creación de Bugtraq proporcionó un foro abierto para estos individuos, de tal manera podían descubrir los mismos temas y trabajar de manera colectiva. El fácil acceso hacia las maneras de explotar las vulnerabilidades dio paso a diversas herramientas “fáciles” disponibles en la actualidad, las cuales permiten a personas quienes no entienden una vulnerabilidad explotarlas satisfactoriamente. Bugtrag provocó un aumento en los ataques en Internet, en redes, y contra proveedores. Muchos proveedores se levantaron en armas, demandando una perspectiva más responsable sobre la divulgación de vulnerabilidades.

En el año 2001, ISS (Internet Security Systems) descubrió muchas vulnerabilidades críticas en productos como el Servidor web Apache, Servicio de fuentes Solaris X Windows, y el software de ISC Bind. ISS trabajó con los proveedores directamente para encontrar la solución. Un parche el cual fue desarrollado y publicado por Sun Microsystems estaba defectuoso y debió ser retirado. Un parche de Apache no fue liberado al público, sino hasta después de la vulnerabilidad fuera publicada a través de divulgación pública, incluso aunque el proveedor conocía la vulnerabilidad. Aunque estos son ejemplos antiguos, estos tipos de vulnerabilidades y muchos más similares, dejaron a los individuos y compañías vulnerables; ellos fueron victimas de ataques y eventualmente desarrollaron un profundo sentimiento de desconfianza en los proveedores de software. Los críticos también acusaron a las compañías de seguridad, como ISS, de tener motivos alternos para divulgar este tipo de información. Sugieren al liberar las fallas y vulnerabilidades de los sistemas, generan “buena prensa” para ellos mismos, y por lo tanto, promueven negocios y mayores ingresos.

Debido a las fallas y controversias resultantes, ISS decidió iniciar su propia política de divulgación para manejar tales incidentes a futuro. Se crearon procedimientos detallados a seguir cuando se descubra una vulnerabilidad, además de como y donde la información podría ser divulgada hacia el público. Aunque esta política se considera “divulgación responsable”, en general esta incluye una advertencia importante; los detalles de la vulnerabilidad se divulgarán a los clientes y al público en un “periodo de tiempo de prescripción”, después del proveedor haya sido notificado. ISS coordina su divulgación pública de una falla con la divulgación del proveedor. Esta política sólo alimentó las personas sientan la información sobre la vulnerabilidad debe estar disponible para el público se proteja a si mismo.

Este dilema y muchos otros, representan una desconexión continua entre los proveedores, compañías de seguridad, y hackers de sombrero gris. Diferentes perspectivas y motivaciones individuales conducen a cada grupo por diversas rutas. Los modelos de divulgación adecuada deben ayudar a las entidades a trabajar en conjunto con un esfuerzo concertado. Aunque sigue existiendo mucha controversia en este tema.

Fuentes:

https://en.wikipedia.org/wiki/Bugtraq
https://en.wikipedia.org/wiki/IBM_Internet_Security_Systems

Desafortunadamente casi todos los productos de software actuales están plagados de fallas. Estas fallas pueden presentar serias consecuencias para los consumidores. Para los clientes quienes dependen en gran medida de las aplicaciones para realizar funciones empresariales fundamentales, los errores pueden ser paralizantes, y por lo tanto deben tratarse adecuadamente. La mejor manera de abordar el problema es un tema complicado, pues involucra dos actores quienes usualmente tienen muy diferentes perspectivas sobre como lograr una resolución.

El primer actor es el cliente. Una persona o empresa compra un producto, confía en este, y espera funcione. Frecuentemente el cliente posee una comunidad de sistemas interconectados (una red), los cuales se basan en una operación exitosa del software para la empresa. Cuando el cliente encuentra una falla, la reporta al proveedor y espera una solución en un lapso de tiempo razonable.

El segundo actor es el proveedor del software. El proveedor desarrolla el producto, y es responsable de una operación exitosa. El proveedor es buscado por miles de clientes por su experiencia técnica y liderazgo en el mantenimiento de su producto. Cuando una falla es reportada hacia el proveedor, usualmente es una de las muchas con las cuales debe lidiar el proveedor, y algunas caen por una razón u otra.

El problema con la divulgación pública ha creado un gran revuelo en la industria de la computación, porque cada grupo visualiza el problema de manera diferente. Muchos creen el conocimiento es un derecho público, y todas la información sobre vulnerabilidades de seguridad debe ser divulgada en principio. Además, muchos clientes sienten la única manera de obtener resultados rápidamente de un gran proveedor de software es presionarlo para solucionar el problema, amenazándolo con hacer esta información pública. Los proveedores han tenido la reputación de simplemente seguir adelante, y retrasar las correcciones hasta se lance una versión o parche posterior, el cual solucionará el problema. Sin embargo esta perspectiva no siempre se considera de los mejores para los intereses de los clientes, pues deben sentarse a esperar el proveedor arregle las vulnerabilidades, lo cual pone en riesgo la empresa.

El proveedor busca el problema desde una perspectiva diferente. La divulgación de información sensible sobre la falla de software causa dos problemas principales. Primero, los detalles de la falla ayudarán a los atacantes a explotar la vulnerabilidad. El argumento del proveedor es si el problema se mantiene confidencial mientras la solución se desarrolla, los atacantes no conocerán como explotar la falla. Segundo, la divulgación de esta información puede dañar la reputación de la empresa, incluso en circunstancias donde la falla reportada es luego probada de ser falsa. Es muy parecido a una campaña de desprestigio en una carrera política, la cual aparece como la noticia principal en un periódico. Las reputaciones están empañadas, e incluso si la historia resulta ser falsa, una retracción es usualmente impresa en la página posterior una semana después. Los proveedores temen la misma consecuencia para las publicaciones masivas sobre reportes de vulnerabilidades.

Debido a estas dos diferentes perspectivas, muchas organizaciones se han unido para crear políticas, pautas, y sugerencias generales sobre como manejar las divulgaciones sobre vulnerabilidades de software. Se hace necesario por lo tanto abarcar el tema desde todos los lados, y ayudar a educar sobre los fundamentos detrás de las divulgación ética de vulnerabilidades de software.

Fuentes:

https://blog.rapid7.com/2016/04/11/vulnerability-disclosure-and-handlin…
https://www.ceps.eu/system/files/CEPS%20TFRonSVD%20with%20cover_0.pdf

Durante muchos años los clientes han solicitado los sistemas operativos y aplicaciones proporcionen cada vez más funcionalidades. Los proveedores continuamente se apresuran a satisfacer este requerimiento, mientras también intentan incrementar las ganancias y su participación en el mercado. Esta combinación de competir en el mercado y mantener una ventaja competitiva, ha resultado en software conteniendo fallas, fallas las cuales abarcan desde las únicamente molestas, hasta críticas y peligrosas vulnerabilidades las cuales directamente afectan el nivel de protección del cliente.

Las habilidades de la comunidad de Hacking están continuamente incrementándose. Solía tomar meses para la comunidad de Hacking realice un ataque exitoso para una vulnerabilidad identificada; actualmente esto ocurre en días o incluso horas. El incremento de interés y talento en la comunidad criminal, equivale a ataques y malware más rápido como también dañino. Es imperativo los proveedores no se centren únicamente en el descubrimiento de vulnerabilidades verdaderas, sino también trabajen para publicar soluciones necesarias para los clientes lo antes posible.

Para esto suceda, los profesionales en Hacking Ético deben entender y seguir métodos adecuados para revelar las vulnerabilidades identificadas en el software de un proveedor. Si un individuo descubre una vulnerabilidad y la explora ilegalmente, además de comunicarlo a otros como realizar esta actividad, a esta persona se le considera un “sombrero negro”. Si un individuo descubre una vulnerabilidad y la explota con autorización, se le considera un “sombrero blanco”. Si una persona diferente descubre una vulnerabilidad, no la explota ilegalmente ni le dice a otros sobre esto, además de trabajar con el proveedor para arreglarlo, a esta persona se le considera un “sombrero gris”.

Actualmente se promueve la utilización del conocimiento y el compartilo de una manera responsable, lo cual no únicamente ayudará a la industria sino también a la comunidad. Para hacer esto se debe entender las políticas, procedimientos, y directrices, las cuales han sido desarrolladas para permitir a los Hackers Ético y proveedores trabajar juntos.

Fuentes:

https://en.wikipedia.org/wiki/Responsible_disclosure
https://www.eff.org/security