Contenido- Conceptos
- Como reportar una vulnerabilidad
- Formato sugerido para el reporte de una Vulnerabilidad
- Lista de Advisories públicos mas relevantes
- Full Disclosure Policy
Advisories: En términos informáticos son Avisos sobre fallas de seguridad, generalmente son públicos después de que la falla a sido reportada hacia el vendor y este notifica que ya tiene un parche. Existen también aquellos que son liberados antes de que exista el parche y es cuando empiezan a salir Zero-day exploits.
Estos advisores pueden variar en contenido y forma, van desde la simple nota de la existencia de una vulnerabilidad en alguna función o modulo de programa o hasta la explicación técnica de en que puntos esta la falla, y la manera de explotarla.
Proof of concept: Prueba de concepto es un corto y/o incompleta realización (o síntesis) de un determinado método o idea para demostrar su viabilidad, o una manifestación, en principio, cuyo objetivo es verificar que un concepto o teoría es, probablemente, en condiciones de explotación de una manera útil. Un (algo sinónimo) plazo es "la prueba de principio".
La prueba de concepto es generalmente considerado un hito en el camino hacia el pleno funcionamiento del prototipo.
En seguridad informática, el término de prueba de concepto (código de prueba de concepto o PoC) se utiliza a menudo como un sinónimo de un Zero-day, principalmente para su pronta creación, no tiene ventaja sobre algunos de vulnerabilidad.
Lista de Advisories de elhacker.net
http://www.elhacker.net/advisories/
Como reportar una vulnerabilidad
Ya sea que encontremos un bug/error de pura casualidad o investigación y logremos detallar los pasos de como lo descubrimos y/o realizamos en ese momento podremos dar reporte a la falla.
- El primer paso es delimitar el alcance de la falla.
Verificamos si es la ultima versión del software ya que si no es así o si existen actualizaciones que no tengamos puede que demos con una falla vieja, esta puede o no puede estar reportada.
Dependiendo de esto ultimo procederemos o no y trataremos de ver si versiones anteriores son vulnerables también.
- Medir el impacto de la falla
Aqui determinamos el impacto de la falla sobre el sistema que la hospeda, entre los mas comunes tenemos:
Denegación de Servicio
Es el mas común, generalmente no pasaremos de hacer que la aplicación deje de funcionar
Consumo de recursos
Si no deja de funcionar, podremos causar algún consumo adicional de memoria y/o microprocesador
Ejecución de Código
Es lo que se busca en la mayoría de las veces, si logramos insertar código y ejecutarlo el sistema podría estar totalmente comprometido
Revelado de información
En dado caso podríamos revelar información que se supone que no deberíamos de poder ver.
Algun Error menor
Se podría dar la situación en la simplemente sobrescribamos alguna variable menor. Solo por mencionar algún ejemplo.
- Encontrar el medio de comunicación con el creador del software (vendor)
Esto es mas importarte. La mayoría de los software que son públicos tienen un correo/pagina de contacto. Es importante comunicarte con el vendor y darle detalles de la falla que encontraste los pasos que seguiste, y si puedes da sugerencias para mejorar el software.
Después de Intercambiar algunos correos y ver que el bug sea arreglado y este disponible un parche o nueva versión ahora si es posible publicar el bug en un blog/web propios y posteriormente publicarlo en alguna pagina como securityfocus, milw0rm entre otras.
Cabe mencionar que muchas veces el bug no sera parcheado o puede tardar mucho.
Formato sugerido para el reporte de una Vulnerabilidad
Generalmente estos se reportan en texto plano.
La mayoría de lista de correo esperan no mas de 80 caracteres por fila.
Organización y Secciones recomendadas
- Limitación
- Descripción del Software
- Descripción del Problema
- Impacto
- Solución
- Referencias
- Créditos
La organización de dichas secciones puede variar y por su puesto que estas se reportan en ingles.
Un ejemplo del reporte de una vulnerabilidad podria ser el siguiente
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
=============================================================================
Sun Mar 8 21:06:34 CST 2009 Heuristics and Exploiting Vulnerabilities
elhacker.net
Topic: flv2mpeg4: Malformed parameters Denial of Service
======================================================================
Table of Contents
1- Affected Software.
2- Background.
3- Problem Description.
4- Severity
5- Solution
6- Time Table
7- Credits
8- About elhacker.net
======================================================================
1) Affected Software
flv2mpeg4 v1.1
Prior versions may also be affected.
======================================================================
2) Background
flv2mpeg4 allows you convert a Flash Video / FLV file (YouTube's videos,etc)
to MPEG4 (AVI/MOV/MP4/MP3/3GP) file online. It is using a compressed domain
transcoder technology (outline in Japanese). It converts FLV to MPEG4 faster
and less lossy than a typical transcoder.
http://www.freebsd.org/cgi/url.cgi?ports/multimedia/flv2mpeg4/pkg-descr
======================================================================
3) Problem Description
As we can see flv2mpeg4 receives 2 parameters the first is expected to be
a flv file and second mpeg4 (AVI/MOV/MP4/MP3/3GP), the problem is a clerical
error in the parameters or a parameter poorly trained, causing the
application to stop running unexpectedly
for example:
Anon@localhost % flv2mpeg4 Video.flv Video.mpg
Segmentation fault (core dumped)
in this mpg extension is incorrect
Anon@localhost % flv2mpeg4 Video.flv `perl -e '{print "A"x4000,".avi"}'`
Segmentation fault (core dumped)
Although the extension is correct in this case, does not allow such a long
file name
======================================================================
4) Severity
Rating: Very low risk
Impact: Denial of service
Where: Local
======================================================================
5) Solution
Run flv2mpeg4 done correctly with the parameters in order
======================================================================
6) Time Table
22/12/2008 - Vendor notified.
23/12/2008 - Vendor response.
08/03/2009 - Public disclosure.
======================================================================
7) Credits
Discovered by Anon, elhacker.net
======================================================================
8) About elhacker.net
Overall objective of the forum elhacker.net
Promote research and encourage the dissemination of knowledge by providing
a means of information, protecting and fighting for their freedom.
Subforum Heuristics and exploitation of vulnerabilities.
Following the overall objective of the forum, subforum Heuristics and
exploitation of vulnerabilities (Bugs and Exploits), aims at promoting
research into techniques for detection and exploitation of vulnerabilities
in any operating system or program that might allow the execution of
arbitrary code, or any other means which violate the confidentiality,
integrity, or availability of information.
http://foro.elhacker.net/
http://foro.elhacker.net/bugs_y_exploits-b32.0/
=============================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (FreeBSD)
iEYEARECAAYFAkm0mE4ACgkQd963iVkvICn7GQCeIonHNhFV/pdu7uvuZG4ucq+A
lMEAoIEDL8JsG1mbb2RrAutEN2TaXs/5
=mi4f
-----END PGP SIGNATURE-----
Como ven tiene las secciones recomendadas y alguna extras, ademas va firmado mediante pgp lo cual es recomendable hacer.
Para reportar (en Ingles) algúna falla en las listas de BugTraq
:http://www.securityfocus.com/archive/post/1
Lista de Advisories públicos mas relevantes
Veremos los ultimos Advisories publicos, con las opciones de ir especificando el vendor del software y la version del mismo
:http://www.securityfocus.com/bid
La lista de Symantec no están extensa como las anteriores sin embargo contiene Advisores mas relevantes de la familia de M$ y algunos otros como Adobe
:http://www.symantec.com/business/security_response/landing/vulnerabilities.jsp
Full Disclosure Policy (RFPolicy) v2.0
:http://www.wiretrip.net/rfp/policy.html
Saludos.
Esta es una buena fuente de reportar bugs: https://www.zerodayinitiative.com (https://www.zerodayinitiative.com)
Siempre sales ganando. Aunque no se si es muy lícito. Venderan los exploits a grupos maliciosos?
Los utilizan para spam/espionaje/chantaje?
Saludos.
Tanto ZDI como iDefense labs son propuestas completamente legales respaldadas por empresas altamente reconocidas.
Que bueno que los mencionas porque son una alternativa para reportar vulnerabilidades muy importante.
El protocolo de la vida de la vulnerabilidad es publico, y se te reporta como evolucionan las cosas.. no se venden las vulnerabilidades a ningun grupo, los unicos que reciben los detalles de esta son el distribuidor.
Saludos!!
Bien ya estan quedando las FAQs
En este topic podremos poner un lista a los Advisories que estemos estudiando o discutiendo. Dicha lista tendría el link al advisory en este foro alguna explicación del mismo o informe de los avances, referencia CVE u Otra si es que tiene, porcentaje entre otros.
[P] PoC
[E] Exploit
[*] [url=LINK]Nombre[/url]
Referencia: AAA-XXXX-YYYY
[quote]Otro advisory del que podemos aprender cosas nuevas[/quote]
Paper: [url=LINK]Nombre[/url]
Porcentaje: %100
[P][E]
Bien aqui pondre en los que me he quedado.
- FFmpeg Type Conversion Vulnerability (http://foro.elhacker.net/bugs_y_exploits/cve20090385_ffmpeg_type_conversion_vulnerability-t248975.0.html)
Referencia: CVE-2009-0385
CitarEjecución de código confirmada por Tobias Klein. Es una vulnerabilidad muy bien explicada, sin embargo no he podido generar el PoC debido a que el archivo que he generado no tiene al parecer el formato adecuado
Paper: CVE-2009-0385.pdf (http://cid-4d0c9dba4e99e162.skydrive.live.com/self.aspx/.Public/papers/Heur%C3%ADstica%20y%20Explotaci%C3%B3n%20de%20vulnerabilidades/CVE-2009-0385.pdf)
Porcentaje: %50
- BoF en inet_network(), afecta a Servidor DNS: BIND (http://foro.elhacker.net/bugs_y_exploits/bof_en_inetnetwork_afecta_a_servidor_dns_bind-t196923.0.html)
Referencia: CVE-2008-0122
CitarPequeño Off-by-One, muy simple y no pude verlo desde el principio, con el analisis que se le dio se comprende del todo el por que del Advisory
Paper: CVE-2008-0122.pdf (http://cid-4d0c9dba4e99e162.skydrive.live.com/self.aspx/.Public/papers/Heur%C3%ADstica%20y%20Explotaci%C3%B3n%20de%20vulnerabilidades/CVE-2008-0122.pdf)
Porcentaje: %100
[P]
- Winamp <= 5.541, libsndfile <= 1.0.17 AIFF buffer unverified (http://foro.elhacker.net/bugs_y_exploits/winamp_5541_libsndfile_1017_aiff_buffer_unverified-t242245.0.html)
Referencia: CVE-2009-0263
Citar"Multiple Buffer Overflow Vulnerabilities" se analizo solo una de las vulnerabilidades debido a que preguntaron por el uso del PoC, me he comunicado con Erik autor de la libreria y hemos visto que solo es un DoS a la aplicacion que use la libreria.
Porcentaje: %50
[P]
@Anon
Te falta agregar la politicar FULL-DISCLOSURE , politica implementada ya de hace muchos años por RFP, existe ahora la v2.0, que ha grandes rasgos es la libertad de publicar o no, despues de un periodo del primer contacto con el vendor.
Full Disclosure Policy (RFPolicy) v2.0
:http://www.wiretrip.net/rfp/policy.html
-berz3k.
He agregado el
Full Disclosure Policy al primer post
- [OB] CVE-2009-3546 - Analisis de libgd (http://foro.elhacker.net/bugs_y_exploits/ob_cve20093546_analisis_de_lbgd-t281979.0.html)
Referencia: CVE-2009-3546
CitarlibGD -- _gdGetColors buffer overflow
Paper: CVE-2009-3546.pdf (http://cid-4d0c9dba4e99e162.skydrive.live.com/self.aspx/.Public/papers/Heur%c3%adstica%20y%20Explotaci%c3%b3n%20de%20vulnerabilidades/CVE-2009-3546.pdf)
Porcentaje: %100
[P]
Después de Intercambiar algunos correos y ver que el bug sea arreglado y este disponible un parche o nueva versión ahora si es posible publicar el bug en un blog/web propios y posteriormente publicarlo en alguna pagina como securityfocus, milw0rm entre otras.