Bing hace mejor que Google? el chema responde.

Aunque a muchos les suene a anatema, Google, aún siendo quizá el mejor buscador de contenidos y de gran utilidad no es perfecto. Si bien Bing debe aprender muchas cosas de Google, en este artículo voy a recoger algunas de las cosas en las que Google hace agua y debería mejorar. Es por eso que el libro de Hacking con Buscadores que publicamos en Informática64 no va solo con Google.

1.- Filetype y Extensión

La primera de las cosas que debe mejorar Google ya la sabéis, porque de ella hablé tiempo ha, y es la implementación del operador filetype como tal, y no como está actualmente, que es solo un sobrenombre del operador ext. Es decir, si se buscan ficheros de filetype:doc, realmente está buscando URLS en las que la extensión del fichero acabé en .doc. 

Figura 1: Búsqueda de ficheros filetype:PDF en psoe.es en Google

Como se puede ver, solo devuelve aquellos que tengan la extension del fichero en .pdf. Ahora buscamos por filetype do, y se puede ver como aparecen ficheros con extensión do que devuelven PDF.

Figura 2: Búsqueda de ficheros filetype:do en psoe.es en Google

Sin embargo, si se hace en BING, se obtienen tanto los que tienen extensión pdf, como los que son devueltos por aplicaciones, siempre que el tipo del fichero sea PDF.

Figura 3: Búsqueda de ficheros filetype:PDF en psoe.es usando BING

Por desgracia BING solo reconoce algunos de los filetypes más comunes, como ya os puse en el artículo de Bing Hacking. Además, en BING no se puede hacer uso del operador extensión, lo que tan buenos resultados da a veces en Google para buscar ficheros ocultos de UNIX o los .listing.

2.- Análisis de binarios

Esta característica es muy especial en BING y es bastante curiosa ya que BING está indexando ficheros ejecutables, objetos OCX, ActiveX o DLLs, haciendo algo muy, muy, muy curioso: Analizarlos. De esta forma es posible buscar ficheros OCX haciendo uso del truco que os conté en Bing Hacking de hacer uso del filetype:txt.

Figura 4: Búsqueda de OCX en BING, se puede ver los strings

Si se mira la caché de la indexación del fichero en BING se accede a una cosa muy chula como son los métodos que exporta, las funciones que utiliza a nivel de kernel o user, las librerías que importa y las secciones que contiene el binario. Muy curioso.

Figura 5: Parte del análisis que indexa BING

De esta manera, por ejemplo, podemos buscar ficheros ejecutables y descubrir malware. Para hacer esta prueba hemos ido a descubrir malware con droppers publicados en Internet. Lo que hemos hecho ha sido un dork para BING buscado ficheros ejecutables (com, exe, src), tal y como éste:

Figura 6: Buscando ejecutables en BING

Después hemos buscado uno de los métodos utilizados por los droppers como por ejemplo URLDownloadToFileA y aparecen algunos muy chulo.

Figura 7: Buscando ejecutables que usen el método URLDownloadToFile en BING

Después, para comprobar la suposición, hemos mandado la URL de uno de ellos a VirusTotal... et voila.

Figura 8: Malware, como era esperado.

Google, directamente no hace ninguna indexación de estos ficheros más allá de la URL y de aquellos que actúan como un CGI. ¿A que mola esta función de BING?

Como hay mucha gente que no lo utiliza, y alguno se ha escandalizado y todo porque en un programa de TV dije que "Bing es uno de los mejores buscadores", hoy he decidido dejaros 10 motivos por los que debes pensar en hacer Bing Hacking también:

1.- Tiene soporte del operador IP: Esto te permite encontrar otros sitios web - tal vez vulnerables - alojados en la misma dirección IP de un objetivo en un proceso de pentesting. Puede ser que no estén alojados en el mismo servidor y que sea solo un proxy inverso, pero si están en el mismo servidor, aparecerán al usar el operador IP.

2.- Implementa correctamente el operador EXT y Filetype: Aunque no lo creas, Google no lo hace. Para Google, tanto EXT con Filetype son lo mismo, cuando no es así. Si buscas en Bing con el operador EXT dará resultados cuyos ficheros acaben en la extensión que decidas. Si usas Filetype lo hará por el tipo de fichero - no importa la extensión que tenga -. En Google tanto Filetype como EXT devuelven ficheros que tengan esa extensión.

3.- No indexa los mismos resultados que Google: A pesar de que la gente piensa que Bing indexa menos que Google, no es solo así. A veces se indexan resultados distintos debido a múltiples factores, como a la forma en la que siguen los enlaces basados en campos de formularios, lo que hace que el motor de spidering encuentre cosas distintas. 

4.- Implementa el operador Contains: Ya os he hablado de él, pero la posibilidad de encontrar páginas con enlaces a ficheros con una extensión concreta es de gran utilidad. Yo lo utilizo, por ejemplo, para encontrar páginas a ficheros de configuración Citrix.

5.- Indexa el contenido de ficheros empaquetados: Se pueden encontrar ficheros que estén dentro de un archivo comprimido o empaquetado, lo que puede arrojar más resultados a la hora de buscar ficheros raros en Internet.

6.- No implementan de igual forma el fichero robots.txt: Esto tiene impacto cuando por ejemplo haya una configuración específica para Google Bot y otra para el motor de Bing, pero también a que los webmasters hagan solo una configuración general y en esos casos  la forma en que interpretan un fichero robots.txt se haga de forma distinta, con lo que podría llevar a que en Bing aparezcan - wait for it - resultados que no están indexados en Google.

7.- La detección de búsquedas automáticas es más relajada: Debido a que Google es el motor que principalmente se usa para todas las herramientas de búsqueda automática de objetivos, Bing no muestra el captcha con tanta rapidez, lo que permite jugar más a gusto durante largo tiempo con los dorks. En FOCA, usar Bing evita que salga ningún captcha.

8.- No es común el Bing Hacking: Casi todos los libros y referencias de hacking con buscadores son sobre Google Hacking y no sobre Bing Hacking, con lo que los resultados que se obtienen a través de Bing no están tan "trillados". Es posible encontrar cosas chulas en poco espacio de tiempo.

9.- Tiene comandos distintos: Google y Bing no tienen exactamente los mismos operadores, como se ha visto ya con Filetype, Contains o IP. En Bing hay algunos como feed, prefer, loc o hashfeed para hacer búsquedas más concretas que te pueden venir bien en algún caso.

10.- No hay excusa para no hacerlo: Puedes enfadarte y negarte a usarlo, pero no hay ninguna razón para no utilizarlo si te puede dar más información. Cuando buscas información debes utilizar todas las fuentes que te vengan bien, desde Google a DuckDuckGo, pasando por Robtex, Shodan, Exalead o ... Bing. Herramientas como FOCA o Maltego utilizan todas las fuentes posibles, no usarlas... es de necios.

Fuente:http://www.elladodelmal.com/2013/04/10-motivos-por-los-que-debes-pensar-en.html

BSOD: Pantallazos azules y como identificarlos

Muchas veces realizando pruebas a los software nos encontramos con pantallazos azules los cuales muchas veces nos dejan con ese sabor amargo a "que paso?" "cual fue el problema?".

Muchas veces excedemos los buffers, pilas entre otros pero no sabemos interpretar el volcado que se realiza.


Antes de nada aclarar que un BSOD es un pantallazo azul. De sobra son conocidas las famosas pantallas azules de Windows que tan temidas son por el usuario y tan dificiles de interpretar son para el experto, en algunos casos dando auténticos quebraderos de cabeza por no saber identificar la causa del pantallazo. A continuación escribiré una breve guía para identificar la causa de un pantallazo azul. Lo primero que hay que conocer es que en Windows XP los pantallazos azules han sido reemplazados por la acción de reiniciar el equipo sin mostrarlo antes, quizás por la mala prensa que éstos han generado del sistema de Microsoft. Existen dos tipos de pantallazos azules, los que muestran el fichero causante y los que muestran una dirección y un error determinado, como pudiera ser PAGE FAULT IN NON PAGED AREA, IRQ NOT LESS OR EQUAL o KMODE EXCEPTION NOT HANDLED. En el caso de que el pantallazo azul nos muestre el fichero que produce el error, no hay ningún problema, porque ya sabemos quién esta generando el error, pero en el caso de que no muestre ningún fichero, procederemos a analizar el pantallazo azul. Lo primero que debemos hacer es activar la característica para que nos muestre las pantallas de error en lugar de reiniciar. Para ello vamos al Panel de Control / Sistema / Opciones avanzadas / Inicio y recuperación.


Nos aparece la siguiente imágen: En ella deberemos desmarcar la opción Reiniciar automáticamente para que nos muestre el pantallazo, y Volcado de memoria del núcleo (en la información de depuración) para poder identificar el pantallazo azul en caso de que no lo consigamos en los primeros pasos. Con un Volcado de memoria pequeño (64kb) no obtendríamos suficiente información para determinarlo. En el caso de tampoco conseguirlo con el volcado del núcleo, haríamos un volcado completo. Considerar que necesitamos en éste caso, tener al menos la capacidad de nuestra memoria RAM de espacio libre en nuestro disco, ya que se va a generar un dump de nuestra memoria.



He leído que para que el dump no resulte corrupto, hay que tener establecida la paginación de memoria virtual en la partición donde tengamos instalado el sistema operativo. Asi que, si no es así debemos proceder a ello, en la misma ventana de Opciones avanzadas pero en el primer botón: Rendimiento / Opciones avanzadas / Memoria virtual. Para analizar el dump, vamos a usar el Debugging Tools para 32bits (o para 64bits, AMD64 si posees uno), y aunque podemos descargar los simbolos desde la web, vamos a configurar el programa para que descargue automáticamente los simbolos según los necesite. Para ello, arrancamos el WinDBG, y en el menú File / Symbol File Path pegamos lo siguiente:

SRV*dir*http://msdl.microsoft.com/download/symbols

Donde dir es la ruta donde se descargarán los símbolos (por ejemplo: c:\simbolos). Asi pues, procedemos a ejecutar la opción File / Open Crash Dump y elegir el fichero MEMORY.DMP, generado por el Windows al recibir un pantallazo, que coloca en %SYSTEMROOT% (usualmente C:\WINDOWS). Estaremos analizando el pantallazo azul si todo ha ido bien:
Microsoft (R) Windows Debugger Versión 6.4.0007.2
Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\WINDOWS\MEMORY.DMP]
[...]
Use !analyze -v to get detailed debugging information.

Probably caused by : usbehci.sys
Followup: MachineOwner

En este caso, podemos ver que el causante del error es un usbehci.sys junto a mucha más información que he obviado porque sería ya demasiada, pero que explica detalladamente el error y el motivo por el que ocurre. En el caso que se quiera obtener información más concreta sobre el bsod, convendría investigar un poco más sobre los argumentos, las direcciones de memoria que nos indica el windbg y el uso del !irp. Una cuestión a tener en cuenta, es que en caso de que suframos congelaciones o cuelgues en lugar de pantallazos, existe una forma de generar el dump. Vamos a Inicio / Ejecutar / regedit.exe, a la clave HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters, donde crearemos un nuevo valor DWORD con el nombre: CrashOnCtrlScroll y valor: 1. Reiniciamos el equipo para que capte la información que acabamos de introducir, y, en el caso de producirse un cuelgue o congelamiento pulsamos CTRL (derecho) + BLOQ DESPL (2 veces) para provocar la generación del dump.

Más información en: http://www.emezeta.com/articulos/bsod-pantallazos-azules-y-como-identificarlos

Antes de nada aclarar que un BSOD es un pantallazo azul. De sobra son conocidas las famosas pantallas azules de Windows que tan temidas son por el usuario y tan dificiles de interpretar son para el experto, en algunos casos dando auténticos quebraderos de cabeza por no saber identificar la causa del pantallazo. A continuación escribiré una breve guía para identificar la causa de un pantallazo azul. Lo primero que hay que conocer es que en Windows XP los pantallazos azules han sido reemplazados por la acción de reiniciar el equipo sin mostrarlo antes, quizás por la mala prensa que éstos han generado del sistema de Microsoft. Existen dos tipos de pantallazos azules, los que muestran el fichero causante y los que muestran una dirección y un error determinado, como pudiera ser PAGE FAULT IN NON PAGED AREA, IRQ NOT LESS OR EQUAL o KMODE EXCEPTION NOT HANDLED. En el caso de que el pantallazo azul nos muestre el fichero que produce el error, no hay ningún problema, porque ya sabemos quién esta generando el error, pero en el caso de que no muestre ningún fichero, procederemos a analizar el pantallazo azul. Lo primero que debemos hacer es activar la característica para que nos muestre las pantallas de error en lugar de reiniciar. Para ello vamos al Panel de Control / Sistema / Opciones avanzadas / Inicio y recuperación. Nos aparece la siguiente imágen: En ella deberemos desmarcar la opción Reiniciar automáticamente para que nos muestre el pantallazo, y Volcado de memoria del núcleo (en la información de depuración) para poder identificar el pantallazo azul en caso de que no lo consigamos en los primeros pasos. Con un Volcado de memoria pequeño (64kb) no obtendríamos suficiente información para determinarlo. En el caso de tampoco conseguirlo con el volcado del núcleo, haríamos un volcado completo. Considerar que necesitamos en éste caso, tener al menos la capacidad de nuestra memoria RAM de espacio libre en nuestro disco, ya que se va a generar un dump de nuestra memoria. He leído que para que el dump no resulte corrupto, hay que tener establecida la paginación de memoria virtual en la partición donde tengamos instalado el sistema operativo. Asi que, si no es así debemos proceder a ello, en la misma ventana de Opciones avanzadas pero en el primer botón: Rendimiento / Opciones avanzadas / Memoria virtual. Para analizar el dump, vamos a usar el Debugging Tools para 32bits (o para 64bits, AMD64 si posees uno), y aunque podemos descargar los simbolos desde la web, vamos a configurar el programa para que descargue automáticamente los simbolos según los necesite. Para ello, arrancamos el WinDBG, y en el menú File / Symbol File Path pegamos lo siguiente: SRV*dir*http://msdl.microsoft.com/download/symbols Donde dir es la ruta donde se descargarán los símbolos (por ejemplo: c:\simbolos). Asi pues, procedemos a ejecutar la opción File / Open Crash Dump y elegir el fichero MEMORY.DMP, generado por el Windows al recibir un pantallazo, que coloca en %SYSTEMROOT% (usualmente C:\WINDOWS). Estaremos analizando el pantallazo azul si todo ha ido bien: Microsoft (R) Windows Debugger Versión 6.4.0007.2 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\WINDOWS\MEMORY.DMP] [...] Use !analyze -v to get detailed debugging information. Probably caused by : usbehci.sys Followup: MachineOwner En este caso, podemos ver que el causante del error es un usbehci.sys junto a mucha más información que he obviado porque sería ya demasiada, pero que explica detalladamente el error y el motivo por el que ocurre. En el caso que se quiera obtener información más concreta sobre el bsod, convendría investigar un poco más sobre los argumentos, las direcciones de memoria que nos indica el windbg y el uso del !irp. Una cuestión a tener en cuenta, es que en caso de que suframos congelaciones o cuelgues en lugar de pantallazos, existe una forma de generar el dump. Vamos a Inicio / Ejecutar / regedit.exe, a la clave HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters, donde crearemos un nuevo valor DWORD con el nombre: CrashOnCtrlScroll y valor: 1. Reiniciamos el equipo para que capte la información que acabamos de introducir, y, en el caso de producirse un cuelgue o congelamiento pulsamos CTRL (derecho) + BLOQ DESPL (2 veces) para provocar la generación del dump.

Más información en: http://www.emezeta.com/articulos/bsod-pantallazos-azules-y-como-identificarlos

Antes de nada aclarar que un BSOD es un pantallazo azul. De sobra son conocidas las famosas pantallas azules de Windows que tan temidas son por el usuario y tan dificiles de interpretar son para el experto, en algunos casos dando auténticos quebraderos de cabeza por no saber identificar la causa del pantallazo. A continuación escribiré una breve guía para identificar la causa de un pantallazo azul. Lo primero que hay que conocer es que en Windows XP los pantallazos azules han sido reemplazados por la acción de reiniciar el equipo sin mostrarlo antes, quizás por la mala prensa que éstos han generado del sistema de Microsoft. Existen dos tipos de pantallazos azules, los que muestran el fichero causante y los que muestran una dirección y un error determinado, como pudiera ser PAGE FAULT IN NON PAGED AREA, IRQ NOT LESS OR EQUAL o KMODE EXCEPTION NOT HANDLED. En el caso de que el pantallazo azul nos muestre el fichero que produce el error, no hay ningún problema, porque ya sabemos quién esta generando el error, pero en el caso de que no muestre ningún fichero, procederemos a analizar el pantallazo azul. Lo primero que debemos hacer es activar la característica para que nos muestre las pantallas de error en lugar de reiniciar. Para ello vamos al Panel de Control / Sistema / Opciones avanzadas / Inicio y recuperación. Nos aparece la siguiente imágen: En ella deberemos desmarcar la opción Reiniciar automáticamente para que nos muestre el pantallazo, y Volcado de memoria del núcleo (en la información de depuración) para poder identificar el pantallazo azul en caso de que no lo consigamos en los primeros pasos. Con un Volcado de memoria pequeño (64kb) no obtendríamos suficiente información para determinarlo. En el caso de tampoco conseguirlo con el volcado del núcleo, haríamos un volcado completo. Considerar que necesitamos en éste caso, tener al menos la capacidad de nuestra memoria RAM de espacio libre en nuestro disco, ya que se va a generar un dump de nuestra memoria. He leído que para que el dump no resulte corrupto, hay que tener establecida la paginación de memoria virtual en la partición donde tengamos instalado el sistema operativo. Asi que, si no es así debemos proceder a ello, en la misma ventana de Opciones avanzadas pero en el primer botón: Rendimiento / Opciones avanzadas / Memoria virtual. Para analizar el dump, vamos a usar el Debugging Tools para 32bits (o para 64bits, AMD64 si posees uno), y aunque podemos descargar los simbolos desde la web, vamos a configurar el programa para que descargue automáticamente los simbolos según los necesite. Para ello, arrancamos el WinDBG, y en el menú File / Symbol File Path pegamos lo siguiente: SRV*dir*http://msdl.microsoft.com/download/symbols Donde dir es la ruta donde se descargarán los símbolos (por ejemplo: c:\simbolos). Asi pues, procedemos a ejecutar la opción File / Open Crash Dump y elegir el fichero MEMORY.DMP, generado por el Windows al recibir un pantallazo, que coloca en %SYSTEMROOT% (usualmente C:\WINDOWS). Estaremos analizando el pantallazo azul si todo ha ido bien: Microsoft (R) Windows Debugger Versión 6.4.0007.2 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\WINDOWS\MEMORY.DMP] [...] Use !analyze -v to get detailed debugging information. Probably caused by : usbehci.sys Followup: MachineOwner En este caso, podemos ver que el causante del error es un usbehci.sys junto a mucha más información que he obviado porque sería ya demasiada, pero que explica detalladamente el error y el motivo por el que ocurre. En el caso que se quiera obtener información más concreta sobre el bsod, convendría investigar un poco más sobre los argumentos, las direcciones de memoria que nos indica el windbg y el uso del !irp. Una cuestión a tener en cuenta, es que en caso de que suframos congelaciones o cuelgues en lugar de pantallazos, existe una forma de generar el dump. Vamos a Inicio / Ejecutar / regedit.exe, a la clave HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters, donde crearemos un nuevo valor DWORD con el nombre: CrashOnCtrlScroll y valor: 1. Reiniciamos el equipo para que capte la información que acabamos de introducir, y, en el caso de producirse un cuelgue o congelamiento pulsamos CTRL (derecho) + BLOQ DESPL (2 veces) para provocar la generación del dump.

Más información en: http://www.emezeta.com/articulos/bsod-pantallazos-azules-y-como-identificarlos

Antes de nada aclarar que un BSOD es un pantallazo azul. De sobra son conocidas las famosas pantallas azules de Windows que tan temidas son por el usuario y tan dificiles de interpretar son para el experto, en algunos casos dando auténticos quebraderos de cabeza por no saber identificar la causa del pantallazo. A continuación escribiré una breve guía para identificar la causa de un pantallazo azul. Lo primero que hay que conocer es que en Windows XP los pantallazos azules han sido reemplazados por la acción de reiniciar el equipo sin mostrarlo antes, quizás por la mala prensa que éstos han generado del sistema de Microsoft. Existen dos tipos de pantallazos azules, los que muestran el fichero causante y los que muestran una dirección y un error determinado, como pudiera ser PAGE FAULT IN NON PAGED AREA, IRQ NOT LESS OR EQUAL o KMODE EXCEPTION NOT HANDLED. En el caso de que el pantallazo azul nos muestre el fichero que produce el error, no hay ningún problema, porque ya sabemos quién esta generando el error, pero en el caso de que no muestre ningún fichero, procederemos a analizar el pantallazo azul. Lo primero que debemos hacer es activar la característica para que nos muestre las pantallas de error en lugar de reiniciar. Para ello vamos al Panel de Control / Sistema / Opciones avanzadas / Inicio y recuperación. Nos aparece la siguiente imágen: En ella deberemos desmarcar la opción Reiniciar automáticamente para que nos muestre el pantallazo, y Volcado de memoria del núcleo (en la información de depuración) para poder identificar el pantallazo azul en caso de que no lo consigamos en los primeros pasos. Con un Volcado de memoria pequeño (64kb) no obtendríamos suficiente información para determinarlo. En el caso de tampoco conseguirlo con el volcado del núcleo, haríamos un volcado completo. Considerar que necesitamos en éste caso, tener al menos la capacidad de nuestra memoria RAM de espacio libre en nuestro disco, ya que se va a generar un dump de nuestra memoria. He leído que para que el dump no resulte corrupto, hay que tener establecida la paginación de memoria virtual en la partición donde tengamos instalado el sistema operativo. Asi que, si no es así debemos proceder a ello, en la misma ventana de Opciones avanzadas pero en el primer botón: Rendimiento / Opciones avanzadas / Memoria virtual. Para analizar el dump, vamos a usar el Debugging Tools para 32bits (o para 64bits, AMD64 si posees uno), y aunque podemos descargar los simbolos desde la web, vamos a configurar el programa para que descargue automáticamente los simbolos según los necesite. Para ello, arrancamos el WinDBG, y en el menú File / Symbol File Path pegamos lo siguiente: SRV*dir*http://msdl.microsoft.com/download/symbols Donde dir es la ruta donde se descargarán los símbolos (por ejemplo: c:\simbolos). Asi pues, procedemos a ejecutar la opción File / Open Crash Dump y elegir el fichero MEMORY.DMP, generado por el Windows al recibir un pantallazo, que coloca en %SYSTEMROOT% (usualmente C:\WINDOWS). Estaremos analizando el pantallazo azul si todo ha ido bien: Microsoft (R) Windows Debugger Versión 6.4.0007.2 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\WINDOWS\MEMORY.DMP] [...] Use !analyze -v to get detailed debugging information. Probably caused by : usbehci.sys Followup: MachineOwner En este caso, podemos ver que el causante del error es un usbehci.sys junto a mucha más información que he obviado porque sería ya demasiada, pero que explica detalladamente el error y el motivo por el que ocurre. En el caso que se quiera obtener información más concreta sobre el bsod, convendría investigar un poco más sobre los argumentos, las direcciones de memoria que nos indica el windbg y el uso del !irp. Una cuestión a tener en cuenta, es que en caso de que suframos congelaciones o cuelgues en lugar de pantallazos, existe una forma de generar el dump. Vamos a Inicio / Ejecutar / regedit.exe, a la clave HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ i8042prt \ Parameters, donde crearemos un nuevo valor DWORD con el nombre: CrashOnCtrlScroll y valor: 1. Reiniciamos el equipo para que capte la información que acabamos de introducir, y, en el caso de producirse un cuelgue o congelamiento pulsamos CTRL (derecho) + BLOQ DESPL (2 veces) para provocar la generación del dump.

Más información en: http://www.emezeta.com/articulos/bsod-pantallazos-azules-y-como-identificarlos

W3C ¿Utilidad para los Testers?

Sumario

Debate iniciado en el grupo de discusión TESTING & QA, comunidad de testers dentro de la red LinkedIn, para discutir sobre la herramienta W3C y si es útil para los testers. Título del Debate: W3C Markup Validation Service, ¿Es de utilidad para los Testers actualmente?

W3C

http://validator.w3.org/, es el link que nos lleva a este site y que propone las siguientes acciones:
1. Validate by URI
2. Validate by File Upload
3. Validade by Direct input

1. Validate by URI

Luego de ingresar una url, se debe pulsar el botón ‘Check’ para obtener el resultado del análisis. (existe la posibilidad de acceder a More Options)*

2. Validate by File Upload

Luego de seleccionar el archivo, se debe pulsar el botón ‘Check’ para obtener el resultado del análisis. (existe la posibilidad de acceder a More Options)*

(*) More Options
-Character Encoding
-Document Type
-List Messages Sequentially
-Group Error Messages by Type
-Show Source
-Clean up Markup with HTML-Tidy
-Show Outline
-Validate error pages
-Verbose Output

3. Validate by direct input

Luego de ingresar el Markup para validar, se debe pulsar el botón ‘Check’ (existe la posibilidad de acceder a More Options)**

(**) More Options
-Validate Full Document
-Validate HTML fragment
-Show Source
-Clean up Markup with HTML-Tidy
-Show Outline
-Validate error pages
-Verbose Output

Básicamente esta herramienta permite validar el lenguaje de marcas HTML.

La validación puede realizarse a partir de la URL de la página que deseamos validar (opción 1), o bien descargando el fichero a validar desde nuestro equipo (opción 1).

Tras la validación, la herramienta muestra un listado de las líneas del código HTML que no cumplen el estándar (siempre y cuando se haya seleccionado esta opción previamente desde ‘More options’), junto con una descripción del problema.

En algunos errores, además, añade una explicación de la posible causa, que puede ayudar a solucionar el error. (siempre y cuando se haya seleccionado esta opción previamente desde ‘More options’)

Entre las opciones avanzadas de validación existe la posibilidad de seleccionar el juego de caracteres y el tipo de documento utilizado en la página a validar (en caso de que no esté expresado en la primera línea de la misma).

El objetivo de usar esta herramienta -para el tester- es verificar y validar la calidad del código HTML.

Herramientas a nuestra disposición (algunas de ellas):

W3C (X)HTML Validation Service
W3C CSS Validation Service
W3C Link Checker
Links relacionados:

W3C
Wikipedia
Listado de herramientas para software testing
Testing Framework and Methodologies

FUENTE;

http://testingbaires.com/debate-w3c-es-de-utilidad-para-los-testers-actualmente/

Nunca uses un Proxy de Internet

Muy buena entrada de la cueva del dragon:


La mayoría de los novatos de Internet usan proxy, según ellos para ser anónimos. Nada mas falso. Son trampas mortales.
Como haría el gobierno para atrapar a todos estos chicos, algunos del grupo Anonymous.
Como todos sabemos la gente de Anonymous realmente no tiene experiencia ni son profesionales de las computadoras. Son vulnerables a acciones contra ellos de forma profesional.
La misión era que tan rápido podría sembrar un proxy y que Anonymous e incluso otros delincuentes lo usaran. Fue impresionante, la misma infraestructura de los delincuentes que buscan proxys abiertos se volvio encontra de ellos mismos.
Me dieron una IP de Queretaro y un servidor de alta disponibilidad y anchos de banda muy generosos, solo tuve que configurar un Squid Proxy abierto. En menos de una semana el proxy aparecía en la lista de proxys de internet. Ya confirmando que la IP ya era parte de las recomendada por delincuentes.
Una vez con la recomendación de sitios para proxys, empezó la captura de datos. Infinidad de claves, datos personales, nombres, nicknames, chats incriminatorios y demás información se pudo capturar, se limpiaron los logs para obtener solo ips mexicanas y discriminar entre anonymous de lugares a los que no interesan.
Con la lista de ips se podría catear domicilios gracias a que Prodigy lleva un registro de las Ips, igual que otros proveedores
En poco tiempo harban proxys mexicanos pero con Ips extranjeras para engañar a los delincuentes y que los usen. Ahora Anonymous , delincuentes que “hackean paginas web” no sabrán si el proxy que usan los ayuda a ocultarse o todo lo contrario le entrega información de ustedes.
Imagen de la lista de proxy, donde se recomienda usar el proxy diseñado para intervenir

Ver mas grande
El vídeo donde el proxy muestra las Ips homologadas, las reales. Donde los victimarios se vuelven víctimas, se ven pasar conexiones de teamviewe entre otras.


fuente: http://www.lastdragon.net/?p=717

Herramienta de Prueba de Datos Estructurados – Parte I

Desde su área de Herramientas para webmasters de Google, se puede acceder a esta herramienta.
La pregunta que me hice cuando llegué por casualidad a esta página fue: Para qué sirve?

En principio y según una definición que la dá el mismo Google, su alcance es el siguiente:

La herramienta de pruebas de datos estructurados te permite comprobar el marcado y asegurarte de que Google pueda extraer los datos estructurados de tu página. Esta herramienta muestra el marcado de una página web determinada, así como una vista previa de cómo puede aparecer dicha página en los resultados de la búsqueda de Google. También puedes ver ejemplos de marcado extraído para tipos de información específicos. Si has creado fragmentos enriquecidos para un motor de búsqueda personalizado de Google, también puedes utilizar esta herramienta para obtener una vista previa de los resultados.
Bien, ahora es solo cuestión de ‘probar’ entonces, … En el próximo artículo comentaré resultados. Hasta pronto.

Fuente: google
http://support.google.com/webmasters/bin/answer.py?hl=es&answer=173839
http://testingbaires.com/herramienta-de-prueba-de-datos-estructurados-parte-i/

Técnicas para descubrir los ficheros de un sitio web

Buenos días,

Las siguientes entradas tratan de encontrar ficheros importantes sobre nuestro sitio web , esto ya lo hemos trabajado en el blog pero copio estas dos entradas del blog del chema las cuales me parecieron que sirve para entender muchos conceptos.

____________________________________________________________________________

Una de las cosas que es necesario realizar cuando se hace una auditoría es qué archivos hay en el servidor web, ya que en cualquiera de ellos puede estar la llave con que abrir la lata. Para ello existe una gran variedad de maneras de intentar encontrar todas las carpetas y ficheros que en el servidor web están "ocultos" a simple vista. Encontrarlos es un juego divertido similar a buscar las piezas de un puzzle que permitan ver la foto completa que se esconde tras el nombre de dominio original, y son diversas.

Muchas de estas técnicas están implementadas en FOCA, otras no, y como quiero que se implementen, este fin de semana pasado le dedique un tiempo a recopilarlas todas en una lista que me ha quedado un poco larga, por lo que os la voy a publicar en un par de posts. Estas son todas ellas:

1.- Crawling

La primera y más evidente es leer los códigos fuentes de las páginas web de un sitio y seguir todos los enlaces que de ellas se pueden extraer. Esto es algo que tradicionalmente hacemos con Burp Suite ya que podemos conectar la búsqueda de URLs con las pruebas de FOCA. El módulo de spidering es suficientemente bueno cómo para sacar un fichero con todas las rutas a archivos de un sitio.

Figura 1: Spidering con Burp

2.- Robots.txt

Estos archivos guardan rutas a documentos y carpetas, así que por si el crawling no hubiera encontrado todos, merece la pena darles una lectura a ver qué aparece por allí. Algunas veces pueden aparecer rutas sorprendentes como vimos con el robots.txt de RTVE o curiosas como el famoso robots.txt de la Casa Real.

3.- Sitemap.xml

Los archivos sitemap.xml también recogen ficheros y contenidos de un sito. Generalmente son URLs públicas con información para mejorar la indexación que de un sitio hacen los buscadores. Conviene sacar estas URLs y alimentar con ellas el motor de crawling, por si el sistema se hubiera parado antes de localizar una de esas direcciones.

Figura 2: El sitemap.xml de Casa Real a día de hoy

4.- Buscadores

Los buscadores pueden indexar URLs que hayan llegado a su base de datos por medio de un enlace directo que se haya puesto en alguna otra página - recordad el caso de los XSS-Google Persistentes - o porque alguna barra del navegador o el mismo Google Chrome, hayan reportado esa URL como el caso de Blogger y la predicción del futuro o el sofá del Bank of América. Hay que revisar los archivos indexados por los buscadores. Además, un fallo de configuración antiguo de un sitio puede haber sido utilizado para indexar los archivos, y están en la base de datos del buscador.

5.- Directory Listing

Por supuesto, hay que revisar todas las carpetas de todas las URLs para encontrar aquellas que puedan tener un directory listing abierto. Esta es la mejor de las opciones, pues permite ver todo lo que hay en una carpeta sin necesidad de buscar más.

6.- Ficheros .listing

Los ficheros .listing, que son creados por el wget son un ls -la de la carpeta donde se ha subido o de donde se han descargado determinados ficheros. Aunque no tienen porque ser lo que haya en ese directorio, si que salen muchas URLs que deben ser probadas.

Figura 3: Aspecto de un fichero .listing

7.- Ficheros .DS_Store

Los ficheros .DS_Store generados por el infame Finder de Mac OS X han demostrado ser una fuente jugosa de información para obtener archivos y carpetas de un directorio, tal y como vimos esta semana con el programa DS_Store.

8.- Ficheros Thumbs.db

Los ficheros Thumbs.db también guardan nombres de archivos - y miniaturas - de los thumbnails asociados a los archivos en Windows XP o Windows 2003. Para analizar los ficheros thumbs.db podéis utilizar el servicio online que está disponible hace mucho tiempo en Informática64 llamado Thumbando.

Figura 4: Salida de Thumbando cuando se le pasa un Thums.db

9.- Repositorios de código fuente de los sitios web

En ellos suelen quedar ficheros que registran los archivos subidos y/o actualizados en cada post de un desarrollador. Sistemas como subversion o BuildBot pueden ser auténticas fuentes de información para conocer qué hay en un sitio web escondido, donde el amigo .SVN/Entries y su base de datos wc.db junto con el directorio pristine son un autentico regalo en una auditoria. 

10.- Ficheros de error 404

Los mensajes de error también pueden tirar rutas internas o del sitio web. De ellos merece la pena recordar los mensajes de error 404 en aplicaciones ASP migradas a IIS 7, o los mensajes de error 404 en documentos TCL de WebDNA.

Figura 5: Rutas en un mensaje de error 404 de IIS con ASP

11.- Multiple Choices con Mod_negotiation

Cuando se solicita un fichero que no existe en el servidor web este módulo de Apache devuelve la lista de ficheros que se llaman igual que el solicitado, pero que tienen distintas extensiones. Es perfecto para encontrar backups de ficheros, por lo que la idea es tan sencilla como solicitar todos los ficheros  que se conocen en el servidor y pedirlos sin extensión. A ver qué sale.

Figura 6: Ficheros de backup descubiertos con mod_negotiation

12.- Fuzzing estático

Las técnicas de fuzzing en web construyen a partir de palabras de un diccionario reglas de predicción de nombres de archivos y carpetas. Estas técnicas tuvieron su exponente hace tiempo ya en la herramienta Wikto de Sensepost, que hacía todo esto de manera eficiente y añadió lógicas de inspección de carpetas y parametrización por tipos de archivos.

Figura 7: Wikto

13.- Fuzzing dinámico

En este caso la idea es generar los nombres de fuzzing en tiempo real a media que el crawler, o el motor de spidering que se utilice descubra nuevos ficheros basandose en los nombres encontrados. En FOCA se añadió un pequeño módulo llamado Backups que realiza fuzzing dinámico buscando los posibles nombres de las copias de seguridad de los ficheros seleccionados. Si no recuerdo mal, esto solo estaba en la FOCA PRO.

Figura 8: Backups buscados con FOCA PRO

14.- Diccionario de software conocido

Por supuesto, puestos a hablar de fuzzing, hay que citar que otra manera es utilizar las herramientas que llevan cargadas las rutas donde se instalan los archivos de las aplicaciones web más comunes, como el caso de Moodle, Wordpress, Joomla, etcétera. El éxito es tener el diccionario de todas las rutas de todas las versiones de todo el software, así que sería fácil localizar una buena cantidad de archivos en el momento en que se detecte el software instalado. Una buena herramienta para hacer esto es SWAT (Swiss Web Attack Tool).

Figura 9: Módulos que se pueden probar en SWAT

15.- Metadatos de documentos ofimáticos

Por supuesto, si os digo que la FOCA hace esto, supongo que no os digo nada nuevo. La idea es que en muchos archivos, especialmente archivos PDF generados con impresoras virtuales que crean documentos desde un sitio web, en el mismo campo título queda la ruta de la aplicación que lo generó.

16.- Directorios de usuarios con Mod_user_dir en Apache

Este es otro ejemplo para descubrir URLs haciendo uso de la publicación de los $HOME de los usuarios del sistema en servidores web Apache. Si se detecta uno de ellos, es bueno hacer un poco de fuzzing a las rutas /~usuario para ver si existen. Para ello se puede usar un diccionario de nombres de usuarios a lo bestia o nombres de usuario extraídos de los metadatos de los archivos publicados en el sitio, o de alguna web que hayas podido "scrappear".

Además, si has descubierto el módulo mod_user_dir, deberías probar a lanzar un fuzzing de los archivos de perfil de los usuarios en *NIX*. Puede que aparezcan los .login, .bashrc, .profile, .bash_profile y compañía por allí.

17.- Bug de IIS Short name

Ya hemos hablado mucho de esto. Si hay un IIS 6 o un IIS 7, debes probar a ver si es posible enumerar los nombre 8:3 de los archivos mediante este bug. En FOCA hicimos un plugin, pero puedes hacerlo a manopla en el sistema.

18.- URLs de web históricas

A veces, cuando se migra la web, los archivos del sitio web anterior siguen en el servidor. Solo hay que tener las rutas y buscarlas. Para ello, usar un servicio como Archive.org puede darte una buena cantidad de URLs que utilizar. Para ello hay que hacer crawling con las copias, limpiar un poco las URLs que te salen y por último generar un fichero de diccionario que puedas lanzar con tu fuzzer favorito. Trabajosillo, pero salen cosas.

Figura 10: URLs de la web del FC Barcelona del año 1998

19.- Decompiladores

Otro sitio donde pueden salir muchas URLs es en los archivos compilados. Casos como los Applets Java o los archivos .swf pueden darte mucha información de nuevas URLs, y puede que localices hasta los códigos fuentes de estos mismos. Esto también pasa en los archivos binarios, ya que también salen rutas en ellos, aunque normalmente son del equipo donde se trabajó con ellos, como en el caso de la operación Aurora.

Figura 11: La ruta que dio nombre a la operación Aurora

20.- Peticiones de plugins

El último sitio que os voy a dejar en esta lista son los componentes que hacen peticiones al servidor. Casos como los ActiveX que son difíciles de decompilar - a pesar de que hay muchas y buenas alternativas para analizarlos - en el caso de que quieras hacer una lista de URLs, podrías analizar las peticiones que espera recibir del servidor y enchufárselas, a ver qué sale por ahí...

Al final, como se ve en estos casos, hay muchas formas de conseguir sacar un poquito más de información de una web.

FUENTES:

http://www.elladodelmal.com/2013/04/tecnicas-para-descubrir-los-fiheros-de.html

http://www.elladodelmal.com/2013/04/tecnicas-para-descubrir-los-ficheros-de.html

Gestión de mantenimientos a testear -Parte 1

Sumario->

Primer acercamiento referido a la gestión de los distintos tipos de mantenimiento por atender, ésto son: evolutivo, correctivo y adaptativo.

Introducción->

Diferentes tipos de requerimientos que nos llegan desde el área de desarrollo ó funcional por mantenimientos que se deben atender, pueden ser de carácter evolutivo, correctivo o adaptativo, obligándonos a aplicar no sólo diferentes tipos de testing sino además diferentes procedimientos para gestionar interna y externamente esos procedimientos de prueba con sus posibles relaciones.

Primeros conceptos

Vayamos por parte y entendamos la definición y alcance de estos tres tipos de mantenimiento, en este sentido Métrica V.3, los define de la siguiente forma:

- Mantenimiento evolutivo: “Incorporaciones, modificaciones y eliminaciones necesarias en un producto software para cubrir la expansión o cambios en las necesidades del usuario.”

- Mantenimiento adaptativo: “Modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios en la configuración del hardware, software de base, gestores de bases de datos, comunicaciones, etc…”.

Es decir, el ‘mantenimiento evolutivo’ aplica a requisitos de usuarios, mientras que el ‘mantenimiento adaptativo’ aplica al entorno.

Ahora bien, Cómo o Dónde entra a jugar el ‘mantenimiento correctivo’?

Partamos de la base que la garantía de los desarrollos afecta sólo a los mantenimientos correctivos y por tanto no se facturan y en muchas ocasiones se “cuelan” evolutivos como mantenimientos correctivos y se convierte en trabajo adicional y no previsto para las empresas, que en muchas ocasiones requiere un notable esfuerzo y que, por supuesto, no se cobra.

Un mantenimiento correctivo es aquel que tiene como objetivo solventar una deficiencia en un componente del sistema de información (puede ser software o documental). Entiéndase ‘deficiencia’ como algo que debería funcionar o estar correcto y que no lo está.

Un mantenimiento evolutivo es aquel que pretende modificar algo que funcionaba o estaba correcto, con el objeto de aumentar, disminuir o cambiar las funcionalidades del sistema, ya sea por las necesidades del usuario o por otras causas como pueden ser, por ejemplo, cambios normativos.

El problema está en la definición de qué es lo que debería funcionar o estar correcto en el sistema de información, es decir la delimitación clara de la frontera entre el correctivo y evolutivo.

Este problema de definir los límites que puede afectar en una primera instancia al área funcional y/o de desarrollo, es decir, aquella que tenga el primer contacto con el ‘cliente’, se nos puede estar transfiriendo a nosotros, generandonos algunas veces otros inconvenientes, a la hora de tener que estimar esfuerzo de prueba.

Quedará entonces para una segunda parte, seguir con este tema y abordar la tarea de estimación y elaboración de la estrategia y plan de pruebas.

Fuente de inspiración:
Mantenimiento adaptativo
Mantenimiento correctivo y mantenimiento evolutivo

http://testingbaires.com/gestion-de-mantenimientos-a-testear-parte-1/

Testing en diferentes navegadores web en espacios aislados.

Buenos días.

Hoy vamos a tratar un tema muy importante cuando hablamos de testing, cuantas veces nos llenamos de navegadores solo por garantizar que la aplicación que estamos testiando sea compatible y funcional en distintos navegadores?.

Ya hemos hablado en el blog sobre complementos que permiten abrir pestañas con el "protocolo" de los distintos navegadores pero hoy vamos a ver una solución "mejor" librándonos de estar instalando navegadores, actualizándolos y evitando daños sobre el S.O.

La herramienta a usar se llama SPOON, el cual segun sus creadores es un "Browser Sandbox" permitiendo realizar pruebas con los distintos navegadores y sin afectar el S.O.

Los pasos a seguir son los siguientes:

Entrar al sitio oficial  https://spoon.net/browsers/
Eligir cualquier navegador
Registrarse y descargar el ejecutable.
Iniciar sesión con el ejecutable y en la página seleccionar que navegador queremos usar.

Cabe anotar que se puede seleccionar las diferentes versiones de cada navegador y lo mas importante se esta ejecutando en un espacio aislado.

FUENTE:

https://spoon.net/browsers/

Testing de seguridad - Ejecutables y librerías en windows.

Buenos días.

Muchas veces nos encontramos entornos donde nos facilitan el código o por lo menos el software ya instalado, pero en caso de tener los ejecutables y librerías que podríamos hacer para complementar nuestras pruebas?.

Existen muchas pruebas que podríamos llevar a cabo pero hoy nos centraremos en pensar que el .exe puede llegar a tener un comportamiento de malware lo cual podría ocasionar conflictos con el AV que se tenga instalado en la maquina.

Cuckoo Sandbox: Automated Malware Analysis

Cuckoo que es un sistema abierto automatizado para el analisis de Malware, se utiliza para ejecutar, analizar y recopilar informacion sobre el malware, mientras es ejecutado en un entorno aislado, en pocas palabras en una Sandbox.

Cuckoo es una alternativa a otros proyectos como dionaea,  Sandboxie, o Buster Sandbox
Con Cuckoo se puede utilizar para analizar:

• Genéricos ejecutables de Windows
• Archivos DLL
• Los documentos PDF
• Documentos de Microsoft Office
• URL
• Scripts PHP
• Casi todo lo demás

Generando los siguientes resultados:

• Los rastros de win32 llamadas API realizadas por todos los procesos generados por el malware.
• Los archivos que se crean, eliminan y descargar el malware durante su ejecución.
• Los volcados de memoria de los procesos de malware.
• Red de seguimiento de tráfico en formato PCAP.
• Capturas de pantalla del escritorio de Windows tomada durante la ejecución del malware.
• Volcados de memoria completos de las máquinas.

Arquitectura

Cuckoo consiste en un software de gestión central que se encarga de la ejecución y análisis de muestras.

Cada análisis se pone en marcha en una máquina virtual nueva y aislada. La Infraestructura de Cuckoo está compuesto por una máquina host (software de gestión) y un número de máquinas de clientes (máquinas virtuales para el análisis).

La configuracion de cuckoo recomendada es usarlo en un sistema operativo Linux con un windows xp virtualizado, pero tambien funciona desde un Mac Os con windows xp o 7 virtualizado.

Ya que vimos un poco de lo que es Cuckoo, pasaremos a la instalación.

Como habíamos visto en la bugtraq2 habían agregado esta herramienta, así que partiré de la configuración de cuckoo desde el sistema operativo de Bugtraq2.

En caso de que quieras hacer la instalación de Cuckoo con otro sistema operativo linux les dejo aquí una guia.

Para el uso de Cuckoo necesitamos instalar las siguientes librerias en nuestra maquina anfitrion

 sudo apt-get install python
sudo apt-get install python-sqlalchemy
 sudo pip install sqlalchemy
sudo apt-get install python-dpkt python-jinja2 python-magic python-pymongo python-libvirt python-bottle python-pefile
sudo apt-get install tcpdump

Y necesitamos darle permisos de root al Tcpdump, lo hacemos con el siguiente comando

sudo setcap cap_net_raw,cap_net_admin=eip /usr/sbin/tcpdump

Ahora para los que hagamos la configuración de cuckoo en la bugtraq2  donde cuckoo ya viene instalado y solo hay que configurar, solo tenemos que hacer algo antes de empezar.

En este caso como sistema para el virtualizado usaremos virtualbox, pero también con vmware podemos usar cuckoo.
Si usamos el virtualbox desde la bugtraq2 nos encontraremos con un pequeño fallo al querer correr cualquier sistema.

Kernel driver not installed (rc=-1908)

En este caso quise recompilar el kernel pero no me funciono así que tuve que volver a reinstalar el virtualbox que venia por defecto en la bugtraq2.

Podemos hacerlo fácilmente, lo puedes eliminar desde el Centro de Software o desde el Gestor de Paquetes Synaptics.

Una vez eliminado podemos descargar la version mas actual desde la pagina de Virtualbox

Y la instalación la podemos hacer con el siguiente comando:

sudo sh ./nombre del archivo.run

Con esto tenemos ya listo nuestro virtualbox para configurar cuckoo

Primeramente instalaremos nuestro sistema operativo invitado. En mi caso use el Windows XP SP1  ya que es el que mas vulnerabilidades tiene para que el malware a prueba pueda explotar.

Crearemos una maquina virtual con el nombre de “cuckoo1″ en caso de que vallamos agregando mas usar un orden(cuckoo2,cuckoo3,cukoo4), si instalamos un windows xp le pondremos 256 mb de ram, si es un windows 7 le ponemos 5120mb.

Una vez ya instalado el windows, pasaremos a configurar la maquina invitado, empezamos instalando el “Guest Additions”
Para instalar lo pueden hacer dando click en Dispositivos y luego en “Instalar Guest Addtions” en virtualbox

Configuramos nuestra maquina virtualbox el area de Red y la pondremos en modo Bridge (puente) y recuerden el nombre de la interfaz que usaran(vboxnet, eth0,etc)

Instalaremos Python en nuestra maquina virtual http://www.python.org/getit/

También podemos instalar aplicaciones de preferencia versiones viejas que sean vulnerables, las podemos descargar desde Oldapps

Configuramos una ip estática para nuestra maquina virtual, desactivamos el firewall y las actualizaciones automáticas y reiniciamos la computadora.

Ahora tenemos que agregar el Agente de Cuckoo a nuestra maquina virtual, el agente es un archivo en python que hara la conexion de nuestra maquina invitada a la anfitriona,
El archivo esta localizado en /bugtraq/tools/laboratories/sandbox/cuckoo/agent/agent.py

Copiaremos el agent.py a nuestra maquina virtual en el directorio que tu quieras.

Despues de esto abrimos el archivo, y tomaremos una imagen instantanea, esto hara que cada que iniciemos la maquina virtual inice en ese estado en cual tomamos la imagen.  Para hacer la instantanea lo podemos hacer dando clicl en Maquina, luego en Tomar Instantanea.

Ahora configuraremos los archivos .conf  de cuckoo.

En el archivo cuckoo.conf solo modificaremos la interface que configuraste en el virtualbox.

En el archivo Virtualbox.conf configuraremos el nombre de la maquina que especificamos en el virtualbox.
Y especificaremos la IP que le habíamos asignado a la maquina virtual.

El archivo reporting.conf ese lo pueden modificar a su gusto, y no olviden guardar los cambios.

Ahora ya tenemos configurado nuestra maquina virtual invitada y nuestra maquina anfitriona.

Para iniciar cuckoo podemos hacerlo con el comando

python cuckoo.py

O hacerlo desde el acceso directo que viene en la bugtraq2

Cuckoo quedara a la espera de el envió de algún archivo para su análisis.

Ahora para enviar un archivo para analizarlo podremos hacerlo de diferentes formas.

Podemos hacerlo usando el submit.py

usage: submit.py [-h] [--url] [--package PACKAGE] [--custom CUSTOM]
                 [--timeout TIMEOUT] [--options OPTIONS] [--priority PRIORITY]
                 [--machine MACHINE] [--platform PLATFORM] [--memory]
                 [--enforce-timeout]
                 target

Ejemplo : enviar un binario local:

$. / Utils / submit.py / ruta / hacia / binario

Ejemplo : enviar una URL:

$. / Utils / submit.py - http://www.example.com url

Ejemplo : enviar un binario local y especificar una prioridad más alta:

$. / Utils / submit.py - Prioridad 5 / ruta / hacia / binario

Ejemplo : enviar un binario local y especificar un tiempo de espera de análisis personalizado de 60 segundos:

$. / Utils / submit.py - timeout 60 / ruta / hacia / binario

Ejemplo : enviar un binario local y especifique un paquete de análisis personalizado:

$. / Utils / submit.py -  / ruta binario

Ejemplo : enviar un binario local y especificar un paquete de análisis personalizado y algunas opciones (en este caso un argumento de línea de comandos para el malware):

$ / Utils / submit.py -. Exe paquete - Opciones argumentos = - dosomething / ruta / al / Binary.exe

Ejemplo : enviar un binario local que se ejecuta en la máquina virtual de cuckoo1 :

$. / Utils / submit.py - cuckoo1 máquina / ruta / hacia / binario

Ejemplo : enviar un binario local que se ejecuta en un equipo Windows:

$. / Utils / submit.py - Windows / plataforma binarios camino / al /

Ejemplo : enviar un binario local y tomar un volcado de memoria completa de la máquina de análisis:

$ / Utils / submit.py -. Memoria / ruta / hacia / binario

Ejemplo : enviar un binario local y forzar el análisis a ser ejecutado por el tiempo muerto (sin tener en cuenta el mecanismo interno que Cuckoo utiliza para decidir cuándo terminar el análisis):

$. / Utils / submit.py - aplicar-timeout / ruta / hacia / binario

O hacerlo desde la interfaz WEB 

Para usar la interfaz web hay que correr el archivo web.py localizado en la ruta: Bugtraq/tools/laboratories/sandbox/cuckoo/utils
Una vez ya estando en ese directorio solo usamos el comando python web.py  y correra el servicio, para ingresar usaremos la direccion 0.0.0.0:8080
Para actualizar las firmas usaremos el siguiente comando. 
python community.py -a
Con esto añadiremos las firmas creadas por la comunidad de Cuckoo, tambien puedes crear tus propias firmas  aqui les dejo el link de como hacerlo.
Tambien podemos añadir al reporte la deteccion con virustotal para agregar esto debemos modificar el archivo virustotal.py que se encuentra dentro de /modules/processing/

Para conseguir el API de virustotal hay que registrarnos y en el area de tu perfil te dan tu codigo de la API.
Para agregarlo a cuckoo solo pegas el codigo de la API dentro de las comillas de VIRUSTOTAL_KEY

Aquí reportes de Análisis ya hechos.

Un Analisis al troyano de FLU.

Un analisis de Zeus con Cuckoo

embedded by Embedded Video

Cuckoo against a Flash Player Exploit. 

Bueno aqui termino, les dejo este gran proyecto para el analisis de malware, aunque tiene sus Pros tambien tiene sus contras. Si no chequen este articulo de Iñaki Rodriguez

de Securitybydefault

FUENTES:

Twitter: IvanFlores

http://www.flu-project.com/cuckoo-sandbox-automated-malware-analysis-por-ifsecurity.html

Pautas generales para pruebas de autenticación

El siguiente texto busca dar a conocer las pautas necesarias o los procesos a seguir cuando se realiza pruebas a una pagina de autenticación(logín)  

ID de usuario

Asegúrese de que los nombres de usuario / ID de usuario distinguen entre mayúsculas y minúsculas. Muchos sitios utilizan direcciones de correo electrónico de nombres de usuario y direcciones de correo electrónico son ya sensibles a mayúsculas. De todos modos, sería muy extraño para 'smith' usuario y el usuario 'Smith' ser diferentes usuarios. Podría resultar en una grave confusión.

Implementar controles adecuados de seguridad de la contraseña

Una de las principales preocupaciones cuando se utilizan contraseñas para la autenticación de la contraseña es. Una "fuerte" política de contraseñas hace que sea difícil o improbable, incluso para una de adivinar la contraseña a través de medios manuales o automatizados. Las siguientes características definen una contraseña segura:

Longitud de la contraseña

Las contraseñas más largas proporcionan una mayor combinación de caracteres y por lo tanto hacer que sea más difícil para un atacante adivinar.

• La longitud mínima de las contraseñas deben ser aplicadas por la aplicación.
  • Contraseñas de menos de 10 caracteres se consideran débiles ( [1] ).

Mientras que la aplicación longitud mínima puede causar problemas con la memorización de contraseñas entre algunos usuarios, las aplicaciones deben alentarlos a establecer contraseñas (frases o combinaciones de palabras) que pueden ser mucho más largas que las contraseñas típicas y sin embargo, mucho más fácil de recordar.

• Longitud máxima de la contraseña no debe ser demasiado baja, ya que evitará que los usuarios creen contraseñas. Longitud máxima típica es de 128 caracteres.
  • Las palabras de paso de menos de 20 caracteres se consideran generalmente débil si sólo se componen de caracteres en minúsculas latinas.

• Cada carácter cuenta!
  • Asegúrese de que todos los caracteres que el usuario escribe en realidad está incluido en la contraseña. Hemos visto que los sistemas de truncar la contraseña a una longitud más corta que lo que el usuario siempre (por ejemplo, truncado en 15 caracteres cuando entraron 20).
  • Esto generalmente se maneja mediante el establecimiento de la longitud de todos los campos de contraseña de entrada a ser exactamente la misma longitud que la contraseña de longitud máxima.Esto es particularmente importante si la longitud de la contraseña max es corta, como 20-30 caracteres.

Contraseña Complejidad

Las aplicaciones deben cumplir las reglas de complejidad de contraseñas para impedir contraseñas fáciles de adivinar. Contraseña mecanismos deben permitir prácticamente cualquier carácter que el usuario puede escribir a formar parte de su contraseña, incluido el carácter de espacio. Las contraseñas deben, obviamente, ser sensible a mayúsculas el fin de aumentar su complejidad. De vez en cuando, nos encontramos con sistemas en los que las contraseñas no son sensibles a mayúsculas, a menudo debido a problemas legados del sistema, como los mainframes antiguos que no tienen contraseñas mayúsculas y minúsculas.

El mecanismo de cambio de contraseña deben exigir un nivel mínimo de complejidad que tenga sentido para la aplicación y su población de usuarios. Por ejemplo:

• Las contraseñas deben cumplir al menos 3 de los siguientes 4 reglas de complejidad
  • por lo menos un carácter en mayúsculas (AZ)
  • por lo menos un carácter en minúscula (az)
  • al menos 1 dígito (0-9)
  • por lo menos un carácter especial ("£ $% &! ...) - no se olvide de tratar el espacio como caracteres especiales (común en frases de paso)
• al menos 10 caracteres
• más a 128 caracteres
• no más de 2 caracteres idénticos consecutivos (por ejemplo, 111 no permitido)

Como aplicación requieren políticas de contraseñas más complejas, tienen que ser muy claros acerca de lo que estas políticas.

• La política requiere debe mencionarse explícitamente en la página de cambio de contraseña
  • asegúrese de incluir todos los caracteres especiales que permiten, por lo que es evidente para el usuario

Recomendación:

• Idealmente, la aplicación podría indicar al usuario que escriba como su nueva contraseña en qué parte de la directiva de complejidad de su nueva contraseña cumple
  • De hecho, el botón de envío debe estar sombreados hasta que la nueva contraseña cumple la directiva de complejidad y la segunda copia de la nueva contraseña coincide con la primera. Esto hará que sea mucho más fácil para el usuario a entender y cumplir con la política de la complejidad.

Independientemente de cómo se comporta la interfaz de usuario, cuando un usuario envía su solicitud de cambio de contraseña:

• Si la nueva contraseña no cumple con la directiva de complejidad, el mensaje de error debe describir todas las reglas de complejidad que la nueva contraseña no cumple, no sólo la primera regla que no cumple con

Cambio de contraseñas debe ser fácil, no una caza en la oscuridad.

Implementar Mecanismo Secure Password Recovery

Es común para una aplicación para tener un mecanismo que proporciona un medio para que un usuario para obtener acceso a su cuenta en el caso de que se olvide su contraseña. Por favor, consulte Forgot_Password_Cheat_Sheet para más detalles sobre esta función.

Requerir Re-autenticación para las características sensibles

Con el fin de mitigar CSRF y secuestro de sesión, es importante exigir las credenciales actuales para una cuenta antes de la actualización de la información de cuenta confidencial, como la contraseña del usuario, el correo electrónico del usuario, o antes de las transacciones sensibles, como el envío de una compra a una nueva dirección. Sin esta contramedida, un atacante puede ser capaz de ejecutar transacciones confidenciales a través de un ataque CSRF o XSS sin necesidad de conocer las credenciales actuales del usuario. Además, un atacante puede obtener acceso físico temporal en el navegador del usuario o robar su ID de sesión para hacerse cargo de la sesión del usuario.

Utilizar la autenticación de factores múltiples

Múltiples factores de autenticación (AMF) está utilizando más de un factor de autenticación para iniciar sesión o procesar una transacción:

• Algo que saber (datos de la cuenta o contraseñas)
• Algo que tiene (teléfonos fichas o móvil)
• Algo que está (biometría)

Esquemas de autenticación como contraseñas de un solo uso (OTP) implementados utilizando un token de hardware también puede ser clave en la lucha contra los ataques como CSRF y malware de cliente. Un número de tokens de hardware adecuados para MFA están disponibles en el mercado que permiten una buena integración con aplicaciones web. Véase: [2] .

Autenticación de cliente SSL

Autenticación del cliente SSL, también conocida como la autenticación de doble vía SSL, consta tanto, el navegador y el servidor, enviando a sus respectivos certificados SSL durante el proceso de negociación TLS. Así como usted puede validar la autenticidad de un servidor mediante el certificado y pedir una autoridad de certificación bien conocida (CA) si el certificado es válido, el servidor puede autenticar al usuario mediante la recepción de un certificado del cliente y validar contra un tercer partido CA o su propia CA. Para ello, el servidor más proporcionar al usuario con un certificado generado específicamente para él, asignando valores a los sujetos para que éstos se pueden utilizar para determinar el usuario debe validar el certificado. El usuario instala el certificado en el navegador y ahora lo utiliza para el sitio Web.

Es una buena idea hacer esto cuando:

• Es aceptable (o incluso preferido) que el usuario sólo tiene acceso al sitio web de un solo ordenador / navegador.
• El usuario no se asusta fácilmente por el proceso de instalación de certificados SSL en su navegador o habrá alguien, probablemente de soporte de TI, que lo hará por el usuario.
• El sitio web requiere un paso adicional de seguridad.
• También es una buena idea usar si el sitio web es para una intranet de una empresa u organización.

Generalmente no es una buena idea utilizar este método para la amplia y públicamente sitios web disponibles que tendrán un usuario medio. Por ejemplo, no sería una buena idea para implementar esto para un sitio web como Facebook. Si bien esta técnica puede evitar que el usuario tenga que escribir una contraseña (lo que protege contra un keylogger promedio de robar), todavía se considera una buena idea considerar el uso de una contraseña y la autenticación de cliente SSL combinados.

Para obtener más información, consulte: [3] o [4]

Autenticación y mensajes de error

Aplicado correctamente mensajes de error en el caso de la funcionalidad de autenticación se puede utilizar para los fines de identificación de usuario y contraseña enumeración. Una aplicación debe responder (HTTP y HTML) de una manera genérica.

Las respuestas de autenticación

Una aplicación debe responder con un mensaje de error genérico, independientemente de si el ID de usuario o la contraseña es incorrecta. También debe dar ninguna indicación a la condición de una cuenta existente.

Ejemplos incorrectos de respuesta

• "Inicio de sesión de usuario foo: Contraseña no válida"
• "Error de acceso, ID de usuario no válido"
• "Error de acceso, cuenta deshabilitada"
• "Error de acceso, este usuario no está activa"

Ejemplo de respuesta correcta

• "Error de acceso, ID de usuario o contraseña no válidos"

La respuesta correcta no indica si el ID de usuario o la contraseña es incorrecta el parámetro y, por tanto inferir un ID de usuario válido.

Códigos de error y de URL

La aplicación puede devolver un código de error HTTP diferente dependiendo de la respuesta de intento de autenticación. Se puede responder con un 200 para un resultado positivo y un 403 para un resultado negativo. A pesar de que una página genérica de error se muestra a un usuario, el código de respuesta HTTP pueden diferir que puede filtrar información acerca de si la cuenta es válida o no.

Transmitir contraseñas sólo sobre TLS

Véase: Protección de la capa de transporte Cheat Sheet

La página de inicio de sesión y todas las páginas siguientes deben ser autenticados exclusivamente accede a través de TLS. La página de inicio de sesión inicial, conocida como la "página de inicio de sesión de aterrizaje", debe ser servido a más de TLS. Si no se utiliza TLS para la página de destino de inicio de sesión permite a un atacante modificar la acción del formulario de inicio de sesión, lo que las credenciales del usuario se registre en una ubicación arbitraria. Si no se utiliza TLS para las páginas de inicio de sesión autenticado después de que el permite a un atacante ver el identificador de sesión sin cifrar y comprometer sesión autenticada del usuario.

Implementar bloqueo de cuentas

Si un atacante es capaz de adivinar las contraseñas de la cuenta sin quedar incapacitado debido a los intentos de autenticación fallidos, el atacante tiene la oportunidad de continuar con un ataque de fuerza bruta hasta que la cuenta se ve comprometida.

Automatizar brute-force/password adivinar los ataques a aplicaciones web es un desafío trivial. Contraseña mecanismos de bloqueo debe ser empleado que bloquear una cuenta si hay más de un número predeterminado de intentos de conexión fallidos se hacen.

Contraseña mecanismos de bloqueo tiene una debilidad lógica. Un atacante que lleva a cabo un gran número de intentos de autenticación en los nombres de cuentas conocidas pueden producir un resultado que bloquea bloques enteros de cuentas de usuario.

Dado que el propósito de un sistema de bloqueo de contraseña sea la protección contra los ataques de fuerza bruta, una estrategia sensata es de bloqueo de cuentas por un período de tiempo (por ejemplo, 20 minutos). Esto reduce de forma considerable los atacantes, al tiempo que permite la reapertura de las cuentas automáticamente para los usuarios legítimos.

El uso de protocolos de autenticación que no requieran contraseña

Mientras que la autenticación a través de una combinación de usuario / contraseña y el uso de autenticación de múltiples factores se considera generalmente seguro, hay casos de uso en los que no se considera la mejor opción o incluso seguro. Un ejemplo de esto son las aplicaciones de terceros que deseen conectarse a la aplicación web, ya sea desde un dispositivo móvil, otra situaciones sitio web, de escritorio o de otro tipo. Cuando esto sucede, no se considera seguro para permitir la aplicación de terceros para almacenar la combinación de usuario / contraseña, ya continuación se extiende la superficie de ataque en sus manos, en las que no está bajo su control. Por esto y otros casos de uso, existen varios protocolos de autenticación que pueden protegerlo de la exposición de los datos de los usuarios a los atacantes.

OAuth

Autorización Open (OAuth) es un protocolo que permite que una aplicación para la autenticación en el servidor como usuario, sin necesidad de contraseñas o cualquier servidor de un tercero que actúa como proveedor de identidad. Se utiliza una señal generada por el servidor, y proporciona la autorización cómo fluye la mayoría se producen, de modo que un cliente, tal como una aplicación móvil, puede indicar al servidor qué usuario está usando el servicio.

La recomendación es usar y aplicar OAuth 2,0, desde la primera versión se ha encontrado para ser vulnerables a la fijación de sesión.

OAuth 2.0 es actualmente utilizado y aplicado por la API de empresas como Facebook, Google, Twitter y Microsoft.

OpenId

OpenID es un protocolo basado en HTTP que utiliza proveedores de identidad para validar que un usuario es quien dice ser. Es un protocolo muy sencillo que permite a un proveedor de servicio inicia camino para el inicio de sesión único (SSO). Esto permite que el usuario vuelva a utilizar una identidad única administrada a un proveedor de identidad OpenID confianza y ser el mismo usuario en varios sitios web, sin la necesidad de proporcionar cualquier página web de la contraseña, excepto por el proveedor de identidad OpenID.

Debido a su simplicidad y que proporciona una protección de contraseñas, OpenId ha sido bien adoptada. Algunos de los proveedores de identidad bien conocidos para OpenId son Stack Exchange, Google, Facebook y Yahoo!

Para no empresarial ambiente, OpenId se considera una opción segura y mejor frecuencia, siempre que el proveedor de identidad es de confianza.

SAML

Aserción de seguridad Markup Language (SAML) es considerado a menudo compiten con OpenID. La versión más recomendada es de 2,0, ya que es muy característica completa y proporciona una gran seguridad. Al igual que con OpenID, SAML utiliza proveedores de identidad, pero a diferencia de ella, está basado en XML y proporciona una mayor flexibilidad. SAML se basa en redirige el navegador que envían datos XML. A diferencia de SAML, no sólo se inicia por un proveedor de servicios, pero también puede ser iniciada desde el proveedor de identidad. Esto permite al usuario navegar a través de diferentes portales sin dejar de ser autenticados sin tener que hacer nada, por lo que el proceso sea transparente.

Mientras OpenId ha tomado la mayor parte del mercado de consumo, SAML es a menudo la mejor opción para las aplicaciones empresariales. La razón de esto es que a menudo hay pocos proveedores de identidad OpenID que se consideran de clase de la empresa (lo que significa que la forma en que validar la identidad del usuario no tiene altos niveles requeridos por la identidad de la empresa). Es más común ver SAML se usa dentro de los sitios web de intranet, a veces incluso utilizando un servidor de la intranet como el proveedor de identidades.

En los últimos años, las aplicaciones como SAP ERP y SharePoint (SharePoint mediante Active Directory Federation Services 2.0) han decidido utilizar la autenticación SAML 2.0 como un método a menudo preferido para inicio de sesión único empresarial federación implementaciones cuando se requiere para los servicios web y la web aplicaciones.

Gestión de Sesiones de Directrices Generales

La administración de sesiones está directamente relacionada con la autenticación.Las directrices generales de gestión de sesión disponibles anteriormente en esta Hoja de trucos de autenticación de OWASP se han integrado en la nueva hoja de OWASP Sesión Cheat Gestión .

Administradores de Contraseñas

Encargados de la contraseña son programas, plugins del navegador o servicios web que automatizan la gestión de un gran número de credenciales diferentes, incluyendo la memorización y colmatación, lo que genera contraseñas al azar en sitios diferentes, etc La aplicación web puede ayudar a los administradores de contraseñas por:

• utilizando formularios HTML estándar para la entrada de nombre de usuario y contraseña,
• no usar en varias fases esquemas de acceso (nombre de usuario en la pantalla, luego la contraseña),
• no usar muy scripted (JavaScript) de autenticación Schem

Fuente: http://www.vietnamesetestingboard.org/zbxe/?mid=download&document_srl=804047&listStyle=&cpage=