(tardara un poco en cargar…)

Visto en la pagina web de un banco nacional… ¡La pobre mujer tambien tiene que comer!
(tardara un poco en cargar…)

Visto en la pagina web de un banco nacional… ¡La pobre mujer tambien tiene que comer!
Hoy no voy a hablar de mi, voy a dejar que la gente lo haga de nuevo y es que me hacen gracia (y me alagan) las descripciones que alguna gente pone de mi cuando me enlaza desde sus blogs.
Y ya esta, post de relleno para manteneros atentos que a veces me da por escribir cosas medio interesantes y os las podeis perder
Hoy os voy a hablar de una de las nuevas caracteristicas del ¿nuevo? SP1 de Visual Studio 2008 y mas concretamente del .Net Framework 3.5 SP1, de algo que no viene documentado en sus novedades.
Si estais al tanto de mis instalaciones, sabreis que hoy me puse a instalar el SP1 de Visual Studio 2008 para probar las extensiones de Silverlight que lo requerian (¿Seguridad en Silverlight dentro de un tiempo por este blog?) y al terminar de instalar me pidio reiniciarse a lo cual accedi gustoso pues ya era hora de volver a casa
Al arrancar de nuevo mi ordenador y esperar a que terminase la configuracion de las actualizaciones abri el Firefox y de repente me he encontrado con que se me abria la ventana de extensiones con el mensaje de: 1 nueva extension actualizada. De primeras me he quedado un poco sorprendido porque no recordaba haber instalado ninguna, pero todo puede ser porque mi Firefox es un compendio de extensiones de todo tipo, pero repasando la lista de extensiones instaladas me he encontrado con la extension que da nombre al post.
Repasandola un poco por encima se conoce que la extension lo que hace es permitir la funcionalidad de ClickOnce que ya esta disponible en Internet Explorer y que permite instalar aplicaciones .Net desde el propio navegador. Ademas añade algo que venia haciendo IE tambien desde hace mucho tiempo: informar al servidor que se visita sobre la version del framework .Net que tenemos instalada. Hasta aqui todo normal, solo que yo soy un poco friki y me he puesto a enrredar…
La extension se instala en el path “C:\Windows\Microsoft.NET\Framework\v3.5\Windows Presentation Foundation\DotNetAssistantExtension” y contiene, como buena extension de Firefox, dos carpetas: chrome y defaults.
Dandome una vuelta por la carpeta chrome (tip: el fichero jar lo podeis descomprimir con cualquier descompresor de ficheros zip) he visto algunas cosas interesantes:
[Siento la parrafada en ingles si sueles leer este blog en español pero el tema a tratar requiere que use la lengua inglesa para alcanzar a la mayor audiencia posible / If it's your first time reading me, understand that I'm from Spain and english isn't my primary language]
The Javascript Web Browser Fingerprinting is a web browser error-based technique that can tell us what is the browser that someone is using without checking his (probably) User Agent modified value.
The main goal of this technique can be detect real browsers to launch concrete exploits to the visitor of a malware website but it can be used to make more accurate visitors stats reports too.
In the PoC that I made I’m base on two different errors types. First of all I try to access with an XMLHttpRequest to the about:blank page, who has to be denied from the navigator render engine. It causes a different exception in every navigator engine and parsing the error code I’m able to determine between major versions of web browsers.
Actually with this code I can detect these browsers:
At the code you will see I’m doing a try catch block who parses the exception object message when it’s a version of Mozilla Firefox, Opera, Safari or Google Chrome. It’s because doesn’t mind which is your language of your browser, they will throw internally an English error and I can parse it.
If we start to talk about Internet Explorer versions we have to move to special properties of the exception object because they use a localized error message, but IE has some properties that other browsers doesn’t have, so I can use it to determine IE version.
When two browsers have the same navigator engine (like Safari and Chrome) I do another approach to determine which browser is it. Its base on error launched when a variable isn’t defined in a Javascript code and how the different browsers threat it.
I was working (and I’m currently doing too, Mozilla Firefox 3.1 will be the next) at this idea from early June of this year and I was waiting too long to publish because I was waiting that it was approved at Conferencia Ibero-Americana WWW/Internet 2008. At the date I started working of this I couldn’t find any information about this at internet, but this week I found that in the next release of Metasploit they are going to introduce a similar approach to the idea.
As you can see at the SVN they publish a code that made some similar tricks like I do but with some differences. This code only detects Firefox and IE but all of this in a more accurate version approach because they are focused in the exploits they have, but in the last lines of code they use the navigator object, something that I’m trying to avoid. I think I’ll be great to combine both codes to make a more powerful Javascript Web Browser Fingerprinting.
Bueno, hoy, en una entrada rapida y liviana (que el tiempo no da para mucho mas), voy a contaros un poco acerca de las cookies marcadas como httpOnly.
httpOnly fue una caracteristica que introdujo IE 6 y que permite marcar una cookie para que no pueda ser accedida desde el objeto DOM document.cookie. Esto nos permite asegurar de cierta manera nuestra aplicacion frente a ataques de XSS debido a la imposibilidad de capturar las cookies asociadas a un dominio.
Podeis ver aqui un ejemplo de httpOnly donde mediante PHP se han creado dos cookies, una con httpOnly y otra sin esta propiedad. Se comprueba que solo se muestra la cookie insegura al hacer clic sobre el boton. Podeis echarle un ojo al codigo fuente de la pagina para mas informacion
Actualmente lo soportan la mayoria de los navegadores, por ejemplo Firefox desde su version 2.0.0.5, y nos puede permitir asegurar en cierta manera nuestras cookies, aunque ya demostro RSnake que seria posible obtener las cookies mediante javascript en algunos casos muy concretos mediante una prueba de concepto.
Con esto terminamos de definir propiedades generales de las cookies y en proximas entradas nos meteremos en la generacion de cookies que presentan los lenguajes de programacion web mas utilizados y algunos uso incorrectos de las mismas.
Finalmente hace un rato he terminado de programar la aplicacion que postea automaticamente los eventos que requieren elevacion a Twitter (http://twitter.com/UAC).
El codigo fuente del programa lo teneis para descargar y modificar para crear vuestro propio bot posteador en Twitter, pero acordaros de activar los eventos de auditoria de Windows Vista para la creacion de procesos.
Y si quereis enteraros de que iba todo esto al principio pasaos por el blog que cree: An UAC Chronicle.
Actualizacion: Ahora el plugin tiene algunas mejoras en lo que a UX se refiere. Si habeis usado la version anterior las notareis. Estoy pensando en hacer una version que funcione como servicio de Windows, pero eso ya para el fin de semana si acaso…
Quizas el capitulo anterior se quedo un poco corto para la gran mayoria de lectores (cuando lectores tiende a 20) y algunos incluso asi me lo hicieron saber. Quise con el post anterior no hacer como en anteriores entradas donde creo que quizas doy por sabidas demasiadas cosas y la gente que pueda llegar a leerme andara un poco perdida. Hoy eso no nos va a pasar porque nos vamos a meter mas en faena y a programar un poquito incluso.
Hoy vamos a hablar sobre el tema de cookies seguras, o lo que es lo mismo, aquellas que tienen activadas su propiedad Secured. Estas cookies tienen la peculiaridad de que solo se envian si el canal de comunicacion es seguro, esto es, el protocolo usado para transferirlas esta cifrado mediante SSL.
Esto es de gran utilidad en paginas que requieren de una alta seguridad, tales como bancos, bancos y mmmmm ¿bancos?. En realidad deberiamos de marcar nuestras cookies como seguras siempre que asi lo requiera nuestra aplicacion, que sera cuando contengan datos importantes o sean de sesion.
Si nos logamos en una aplicacion en la cual navegamos siempre por zonas seguras no deberiamos de tener problemas en que nuestra cookie este marcada como tal o no, pero si desde la zona segura se nos redirige en algun momento hacia zona no segura nuestra cookie se enviara, poniendo en peligro nuestros datos.
Esto que parece tan logico y normal hay algunos bancos que no lo entienden:
En este caso las cookies no estan marcadas como seguras, aunque el hecho de que el valor Host sea un subdominio del principal hace imposible que se envien fuera de este. Sin embargo, aunque esto podria ser un sustitutivo de la marca segura para las cookies, no lo seria si el servidor, ademas de escuchar en el puerto 443 (HTTPS) escucha en el puerto 80 (HTTP).
Sin embargo hay otros bancos donde la zona privada esta en el mismo dominio que el resto de la aplicacion web, lo que hace que la cookie viaje hacia cualquier parte de la pagina que visitemos:
Esto es un evidente fallo de seguridad por parte de la entidad bancaria, pues cualquiera podria engañar a un usuario logado en la aplicacion para que hiciera clic sobre un enlace HTTP y capturar su cookie de sesion.
Si entramos en esta aplicacion mediante HTTP en lugar de HTTPS se nos redigira automaticamente hacia una zona segura, pero esto no nos vale, pues la peticion ya esta realizada (y la cookie enviada).
rec_sol = noese(document.location.href); if (rec_sol == "http://www.XXXXXXX.es/") top.location.href="https://www.XXXXXX.es/index.jsp";
¿Y realmente es tan dificil establecer nuestras cookies como seguras? Vamos a ver como lo hariamos en PHP y en ASP.Net:
En PHP la creacion de cookies se hace mediante la funcion setcookie(); que recibe un monton de parametros.
setcookie("Cookie segura", "Dato privado!!", 0, "/", "www.equilibrioinestable.com", true);
En ASP.Net es igual de facil, disponemos del objeto HttpCookie que tiene la propiedad Secure, la cual recibe un booleano y que si lo asignamos a true pondremos nuestra cookie como segura.
Y con esto terminamos la parte de cookies seguras, para el proximo ¿numero? hablaremos y practicaremos con la propiedad httpOnly.
Las cookies pueden parecer simples pares de clave-valor, pero en realidad esconden mucho mas. En estas entradas veremos varias consideraciones de seguridad de las cookies y de como asegurarlas en nuestro servidor. Aquí no se va a discutir nada acerca de su uso para mantener la sesión o para almacenar datos del usuario (aunque se puede comentar de pasada)
Para empezar las cookies son datos que nos envía un servidor y que se almacenan en nuestro equipo con una serie de campos requeridos y opcionales. Estos son los mas comunes:
Nuestras cookies se almacenan en distintas partes y en distintos formatos dependiendo del navegador que usemos. Mientras que en IE son unos simples ficheros de texto, en Firefox son almacenadas en un fichero SQLite. Para Firefox usaremos extensiones como Web Developer, Firecookie para Firebug o Add N Edit Cookie mientras que para IE deberemos de hacer uso de herramientas como Galleta para realizar un volcado mas “amigable” de los ficheros que se generan en el directorio (en Windows Vista) C:\Users\<usuario>\AppData\Roaming\Microsoft\Windows\Cookies\Low
En breve (o no) mas!
Si, de nuevo a hablar de XSS… ¿que remedio no? Hoy os quiero intentar hablar de distintos trucos o recursos a la hora de introducir codigo XSS no permanente dentro de una pagina web que este copiando los parametros dentro de su codigo HTML.
Para organizarnos un poco y que os perdais menos voy a intentar separar por categorias los tipos de XSS reflejados que nos podemos encontrar:
En el primero de los casos podemos olvidarnos de intentar introducir algo de XSS en la pagina, pero en los otros dos supuestos podremos intentar cerrar la etiqueta HTML con un >.
Dependiendo de si nuestra etiqueta cerrada cumple su cometido o no podremos empezar a posteriori a introducir nuestro codigo Javascript. No olvideis abrir una etiqueta HTML para que sean cerradas por el codigo que queda tras nuestro Javascript, asi el codigo generado sera perfecto.
“><script>alert(document.domain);</script><div class=”
El codigo se copia dentro de codigo Javascript
Este es el caso mas divertido (y el que me ha llevado a escribir este post). Cuando nuestro codigo se introduce dentro de un codigo Javascript debemos de generar codigo completamente valido para que el navegador pueda interpretarlo y ejecutarlo (al contrario del caso anterior donde una etiqueta HTML mal cerrada no impide que nuestro codigo se ejecute).
Toca realizar un analisis sobre la parte en la que nuestro codigo ha ido a caer y encontrar la manera de que se ejecute. Como norma general nuestro payload estara ubicado dentro de una variable de tipo string, por lo que deberemos de cerrar las comillas (simples o dobles) y añadir el ; de final de linea. Para lograr todo esto aqui van algunos consejos:
Usa los comentarios de una sola linea (//) para eliminar todo aquello que no nos sirva tras nuestro codigo Javascript.
A veces la manera mas facil de asegurarnos que nuestro codigo se ejecuta es cerrando la etiqueta <script> existente y creandonos una propia.
Si nuestro codigo “cae” dentro de una funcion o de un bucle deberemos de cerrar los corchetes abiertos por estos para colocar nuestro codigo dentro del flujo general de la ejecucion del codigo. No olvideis que luego debemos de crear bucles o funciones vacios para que los corchetes que evitamos no nos molesten.
A veces (y esto tambien se aplica al codigo HTML) encontramos dos o mas variables que permiten la inclusion de XSS pero que, por alguna razon, estan limitados en el numero de caracteres. En este caso hemos de comprobar cual es el orden en el que aparecen en el codigo fuente y usar los caracteres de comentarios multilinea para hacer que nuestro codigo sea uno solo juntando las variables disponibles.
Con todo esto en mente y teniendo en cuenta que el codigo ha de ser valido (la extension Firebug de Firefox puede ayudarnos mucho) se puede empezar a jugar contra el programador de la aplicacion.
Evidentemente pueden ocurrir multitud mas de situaciones, aunque creo que la mayoria vienen reflejadas aqui o son subcasos de lo aqui comentado. Tambien es cierto que aqui apenas se han comentado metodos para insertar XSS en los casos donde la cosa este ajustada (filtros potentes, limitaciones reales de tamaño, etc.) pero eso puede dar para otra entrada…
Hola, en esta entrada no voy a hablar de nada de seguridad ni nada de cosas de “manazas”. Hoy os voy a hablar de algo que, aunque debi de verlo hace tiempo, vi recientemente y me llena de orgullo personal.
Hara cosa de un mes estuve por Barcelona dando una charla en la LANcelona 2008 sobre seguridad web que titule “Cagadas en la red” donde comentaba, de manera introductoria, algunas tecnicas y algunos errores de bulto que suelen comenter los desarrolladores web y que nos permiten ganar privilegios en una aplicacion web. La verdad es que no tuvo un nivel excesivamente alto pero yo creo que fue absequible para todos los presentes y que nadie se fue sin aprender nada.
Pues bien, hoy mirando el dashboard este de WordPress me veo que tengo una serie de enlaces entrantes y entre ellos una referencia desde la pagina web de Albert Mata. En ella cuenta su experiencia personal sobre la LANcelona 2008 y comenta sobre la ponencia que di:
Acto seguido comenzó la ponencia de Hacking, a cargo de Pedro Laguna, experto en seguridad de Informática64. En mi opinión estuvo muy, muy bien. Mostró un gran dominio del tema, se basó en una presentación PowerPoint pero en esta ocasión no estaba vacía. Supo mantener el ritmo de la ponencia y hacerla amena e interesante. Realmente de lo mejorcito de las ponencias de Lancelona. Además, como detalle de lo cuidado de la exposición, al terminar nos pasó un formulario en donde pudimos valorar el ponente y la ponencia e incorporar nuestra dirección de e-mail si estábamos interesados en recibir el documento utilizado durante la presentación. Y debo decir que hoy mismo he recibido un correo desde el departamento de formación de Informática64 con dicho documento. Notable muy alto para ellos.
La verdad es que nunca me habian dicho nada tan bonito (mi madre no cuenta) y el hecho de que una persona opine de esta manera tan favorable mi trabajo hace que me plantee que puede llegar a resultar que haga bien las cosas. No se, seguire cuestionandomelo pero quizas un poco menos.
P.D. Esta entrada esta escrita desde Windows Live Writer, una herramienta de Microsoft para escribir de manera comoda en distintas plataformas de blogs. Corrector ortografico incluido
Comentarios recientes