389meneos
Microsoft podría estar ocultando agujeros de seguridad en Vista
Un blogger español, y usuario de Meneame meneame.net/user/jcarlosn encuentra un presunto agujero de seguridad en Windows Vista, incluido el sp1, y se le censura de la famosa lista bugtraq de seguridad, con excusas, para no hacer público el error. ¿Podría ser esto una estrategia de Microsoft para lavar la cara a su seguridad?
Es un bug bastante grave (MUY grave), aunque no haya manera obvia de exploitearlo. Es vergonzoso es que se cause un overflow de una manera tan fácil para un programa que corre ¡como root!
Sin embargo, cuando es windows, entonces todo se mira con lupa, y a la mínima, se censura.
Dejando a un lado los flames, no tenemos certeza de cuantos agujeros mas se están censurando así, y luego microsoft dice que hay menos bugs en su software, que en los productos libres...
El problema aquí no es que tenga un bug de seguridad, todo software más o menos complejo suele tenerlo, sino en cómo han tratado a este reporte en securityfocus a diferencia de otros que se explica en al apunte.
Esto es como el canon (en mi opinión), el problema no es que tengamos que pagar, sino el proceso por el cuál se decidió y quiénes son los que administran el dominio. En este caso el problema NO es el bug, sino en cómo tomaron decisiones en securityfocus.
¿Es infantil o conspiranoico preguntarse porqué para una empresa gorda son tan "así" y para productos libres son tan liberales de acpetar bugs que no lo son o que inlcuso no están demostrados que sea un bug?
Envié el enlace de mi blog a un conocido para que le echara un vistazo.
Entonces, como supongo que sabéis, en las estadísticas te sale quien te ha vistado y desde donde.
Pues resulta que al acceder esta persona a mi blog, en las estadísticas salía directamente el enlace vía webmail.
Me da por clicarlo y accedí directamente al correo de esta persona (evidentemente esta persona estaba con sesión abierta en su correo vía web).
Y tenía acceso completo a su correo.
Cabe decir que no me pude resistir y miré la agenda, jejejeje.
Pero como vi que era un error enorme avisé.
Aunque mis conocimientos de informática no me permitieron saber si era un bug en los blogs de msn, o en el correo vía web de esta persona.
Esto es un poco similar a los binarios suid en linux.
en.wikipedia.org/wiki/Integer_overflow
Su explotación y riesgos está descrita en phrack 60:
www.phrack.org/archives/60/p60-0x0a.txt
Llegados a este punto sabemos que existe un agujero de seguridad en winsat.exe, que es una aplicación que a través del UAC, hereda los privilegios totales del usuario, por defecto root.
En windows vista, existe una separación root | usuarios, por defecto, tu usario es root, pero lo que ejecuta NO es root, sino que hereda privilegios limitados, es una de las features mas innovadoras de vista, según microsoft.
El problema reside en que si puedes tomar el control de un proceso que hereda privilegios completos del UAC, puedes usarlo como puente en tu aplicación, para escalar privilegios.
Lo que no entiendo es tanta confusión entorno a un concepto tan sencillo, de algo que se lleva haciendo años en linux, con los binarios suid.
Aparte de esto, en el correo digo que no estoy seguro por que como windows es closed source yo se que hay un bug, pero no puedo tener una idea precisa de como controlarlo para explotarlo.
Esto no significa que no exista un bug, significa que yo no tengo la información suficiente para continuar con esto, aun y sabiendo que hay bug.
Como nota histórica, el bug que aprovechaba el blaster, el rpc-dcom long filename buffer overflow, fue descubierto 8 meses antes, y enviado a bugtraq, pero no fue hasta 8 meses después, que alguien lo consiguió explotar.
Los bugs son bugs, y existen, aunque no los consigas explotar de antemano, tampoco hay que olvidar que el 90% de los bugs que leemos en listas de seguridad, nunca llegan a ser explotados, sino que se solucionan antes, para evitar que alguien descubra como hacerlo y que no haya parche, como pasó con el blaster.
Y aún así hay gente que continua diciendo que nos quejamos de Microsoft por mania y que el software propietario es también bueno. en fin...
En ubuntu el usuario por defecto en la instalación, no es root, pero está en el /etc/sudoers, por lo que si quiere ejecutar algo como root, puede hacerlo usando sudo y proporcionando su contraseña.
En vista, es casi igual, la diferencia es que funciona un poco diferente, en vista el usuario por defecto es root, pero los procesos que ejecuta, no lo son, a menos que el proceso lo pida expresamente, cuando un proceso lo pide, sale en pantalla un aviso, con la empresa que firma el ejecutable, y su ruta.
De esta forma, si te aparece en pantalla que C:userspepitoDesktopmalware.exe quiere mas privilegios, tu le das a cancelar.
Esta arquitectura es correcta, no puedes conseguir que tu binario sea root, sino pasas antes por el usuario, preguntando, es algo muy similar al sudo que hacen las aplicaciones que requieren root en ubuntu, que saltan pidiendote la password, por ejemplo, al darle a configuración manual en la red.
El problema reside en que winsat.exe es parte de windows, está firmado por microsoft, está en C:windowssystem32 y encima es de los que están marcados para correr siempre con privilegios totales. (esto en linux se llama binario suid, aunque hay diferencias en como funciona)
Si tu pudieses tomar el control de ese proceso, podrías evadir toda esta historia, y ejecutar tu malware.exe, con privilegios totales.
Bien, aquí es donde entre en juego el bug.
Yo no he metido un número larguísimo y ha petado, puedes probar a meter otros números y verás que no peta :) te recomiendo 2^32/2+1, (lo cual ya no lo dejaría negativo) o 2^32/2-1 lo cual no lo llegaría a overflowear, si tienes dudas sobre si hay overflow, puedes comprobarlo con ollydbg www.ollydbg.de/ el debugger por excelencia en windows, si lo haces, verás como se arrasa el stack, la dirección de retorno, el framepointer...todo se sobreescribe con memoria.
Que memoria? es un poco relativo, son cosas del 3d, algunas las puedes controlar con los parametros de la aplicación, otras no.
Fijate a que extremo lo hemos llevado, tenemos un binario especial, que corre siempre como root, que es parte de windows, tenemos un bug, tenemos la prueba debuggeando de que es un bug e incluso sabemos como actua ese bug.
Lo único que falta es controlar algún argumento que nos permite colocar un dato arbitrario en el stack, y conseguir que coincida con la dirección de retorno sobrescrita, y creeme, esto sería mucho mas fácil si fuese de código abierto.
Pero no confundas, no es que haya puesto un numerito y haya petado, hay mucha ciencia detrás de estos bugs.
Y por favor, no confundas bug y exploit, mira:
www.securityfocus.com/archive/1/490263/30/0/threaded
www.securityfocus.com/archive/1/490176/30/0/threaded
Esos dos sin ir mas lejos, de hoy y ayer, no han sido explotados.
etc...etc... como digo, el 90% de los bugs de seguridad, aceptados como tal, nunca han sido explotados, no hay que confundir términos, una cosa es una brecha en la seguridad, y otra muy distinta es como aprovecharla.
Perdón, creí que era un concurso de obviedades. Soy muy competitivo.
– Dr. Gregory House.
Edit: "The worm spread by exploiting a buffer overflow in the DCOM RPC service on the affected operating systems, for which a patch had been released one month earlier in MS03-026"
en.wikipedia.org/wiki/Blaster_%28computer_worm%29
for(int i=0;i<NUMERO_RECIBIDO_COMO_ARGUMENTO;i++) {
crea_figura();
}
con lo cual no es un fallo de seguridad. Ahora bien, si hiciera algo como:
char buffer[NUMERO_RECIBIDO_COMO_ARGUMENTO];
o accediese al elemento n (n=NUMERO_RECIBIDO_COMO_ARGUMENTO) de una región de memoria sí sería peligroso. Lo que te pedía el tipo de Microsoft es que le dieras pruebas de que eso era explotable, no que le explicaras lo que es un integer overflow. Como dicen en el artículo de Phrack:
Of course most integer overflows are not exploitable because memory is not being directly overwritten, but sometimes they can lead to other classes of bugs, frequently buffer overflows.
es decir, que normalmente no son explotables, salvo cuando se usan para trabajar con buffers.
De todas formas, no es esto motivo suficiente para no censurarlo, y que quien quiera lo investigue y se sepa el final? ahora seguro que no lo sabremos nunca.
A mi lo que me ofende es que si esto mismo hubiese sido en otro producto que no fuese de microsoft, como ya ha pasado en el pasado, no hubiese sido censurado en securityfocus, y mucha gente podría haberlo investigado, y se hubiese sacado una conclusión finalmente.
De todas formas, por lo que se ve en el debugger (miralo si tienes un rato) parece ser que ese indice se usa para reservar memoría, por lo que si sería peligroso.
Esto se complica ya muchísimo, lo máximo que le puedo dar a los de Microsoft es la prueba de que hay un buffer overfloweado como consecuencia del entero, y que se puede controlar parcialmente, pero sabes que? al final acabamos todos trabajando para microsoft, te cansas, lo envias a bugtraq para que lo sigan los demás, y te lo censuran, cuando bugs calcados a este, pero en preoductos de software libre, los aceptan a diario, ese es el punto del artículo.
La verdad es que en el bugtraq se comen casi cualquier cosa... que suene a esto es una bomba. Así que si hay exploit, de la chorrada más chorra, lo publican seguro. Que le de exposición al problema y, si se puede explotar, ya saltará algo.
Si lo ha descubierto él, tendrá crédito seguro.
meneame.net/story/macbook-hackeado-en-2-minutos
P.D: que curioso, el meneo anterior no ha salido a portada.
P.D2: eventos.barrapunto.com/article.pl?sid=08/03/28/1134238
Ya lo sabía, por eso lo puse ;) . Me explico, a windows le criticamos hasta el fondo de pantalla pero los demás... los demás tienen carta blanca.