Para comenzar, habría que repasar los 4 tipos de bloqueo del dispositivo que Android nos proporciona:

Slide (none). Es el modo más básico, simplemente realizando el gesto del desplazamiento el dispositivo quedará desbloqueado.

Pattern lock. En este modo se proporciona un patrón sobre los puntos marcados que debe seguirse para conseguir el desbloqueo del dispositivo. El único requisito sobre dicho patrón es que contenga al menos el paso por 4 puntos.

PIN. En este modo el usuario debe introducir un código numérico para desbloquear el dispositivo.  El único requisito sobre el PIN es que conste de al menos 4 digitos.

Password. En este modo el usuario debe introducir con código alfanumérico para desbloquear el dispositivo.  El único requisito sobre la contraseña es que conste de al menos 4 caracteres.

Los modos de bloqueo pueden configurarse desde las opciones generales, en el apartado de seguridad, en la opción “Screen lock”, como podemos ver a continuación:

Una vez clasificados los tipos, vamos a enumerar las diferentes aproximaciones para evadir estas protecciones:

Smudge Attacks. En esencia se trata de ver las marcas físicas sobre la pantalla del dispositivo. Aunque a priori parezca un tanto cojido con los pelos, el hecho de tomar una fotografía de la pantalla y jugar con los cambios de colores, brillos, ponerla en negativo y demás pueden tener resultados muy satisfactorios. En el siguiente papper detallan esta aproximación desde una manera formal: http://static.usenix.org/event/woot10/tech/full_papers/Aviv.pdf
Pattern Lock Crack Evadir esta protección es muy sencilla solo si se tiene acceso al modo debug del dispositivo rooteado. En patrón se almacena en el dispositivo en forma de hash en el fichero /data/system/gesture.key, como podemos ver a continuación:

Si tenemos acceso ADB de root, podemos eliminar el fichero y crear uno nuevo vacío:  

rm gesture.key
touch gesture.key

A partir de ese momento, cualquier gesto desbloqueará el dispositivo. Si no tenemos acceso al modo debug, es posible a través de la interfaz JTAG, el proceso está descrito en el siguiente enlace:
http://forensics.spreitzenbarth.de/2012/02/28/cracking-the-pattern-lock-on-android/

Password Crack && PIN Crack Evadir estas protecciones es muy sencillo solo si se tiene acceso al modo debug del dispositivo rooteado. La contraseña y/o PIN se almacena en el dispositivo en forma de hash en el fichero /data/system/password.key, como podemos ver a continuación:

Si tenemos acceso ADB de root, podemos eliminar el fichero y crear uno nuevo vacío:

rm password.key
touch password.key

A partir de ese momento, cualquier contraseña y/o PIN desbloqueará el dispositivo.
La gracia visto lo visto es tener el dispositivo rooteado, pero rootear un dispositivo en el transcurso de un análisis forense entraña dificultades en el proceso, ya que el principio fundamental es que las modificaciones de la envidencia tiendan a cero. Vamos a repasar el proceso.
Lo primero al acceder a un dispositivo es saber si somos root en el mismo, tal vez el usuario lo tiene rooteado. ¿Cómo saberlo manipulando lo menos posible el dispositivo? Lo más sencillo es conectar al mismo mediante ADB y ejecutar la siguiente sentencia:

adb shell su

Si como respuesta entramos a la shell, somos root, si obtenemos un “Permision denied” nos lo tenemos que ganar. Antes que nada, no pensemos que ser o no root es algo abosluto, en entornos Android tenemos diferentes tipos de rooteo, y no todos tienen las mismas implicaciones desde el punto de vista forense, por lo que debemos evaluar en cada caso cuál necesitamos y actuar en consecuencia.

Root permanente. Es el más habitual. Entramos al dispositivo y somos root, ¿porqué? Normalmente es así porque se ha habilitado alguna ROM personalizada o se le han proporcionado al dispositivo binarios ARM para comandos como “su“. La referencia es XDA Developers.

Root temporal. Se elevan privilegios solo hasta el renicio, normalmente tras aprovechar una vulnerabilidad en ejecución. Esta forma es ideal desde el punto de vista práctico, si bien entraña riesgos porque se va a modificar en dinámico, puede causar inestabilidad y aprovechar vulnerabilidades para elevar privilegios puede ser muy discutido desde el punto de vista del proceso.

A continuación indico un par de aplicaciones para conseguir este objetivo:

psneuter. Aplicación que gana acceso a root utilizando una vulnerabilidad en Android. https://github.com/tmzt/g2root-kmod/tree/master/scotty2/psneuter

SuperOneClick. Aplicación que reune múltiples exploits para rootear el dispositivo. http://shortfuse.org/?page_id=2

Mercury. Este framework de análisis dinámico incorpora exploits para rootear el dispositivo. http://labs.mwrinfosecurity.com/tools/2012/03/16/mercury/

Root recovery. En este modo se habilita una particion de recuperación en el dispositivo que permite el acceso privilegiado solo cuando se carga dicha partición. Este tipo de rooteo es el más indicado para procedimientos forenses. La problemática es que cada fabricante maneja las particiones de recuperación de una manera diferente y en algunos casos no será trivial. A continuación dejo, por cortesía de @hidark, a modo de ejemplo el proceso para el modelo ASUS Transformer TF101:

Arrancamos el dispositivo presionando los botones “power” y “subir volumen“, no ves nada en la pantalla, pero si la tienes conectada al PC puedes apreciar con un “dmesg” desde el PC que el dispositivo entró en modo APX:

Después ya se puede cargar un bootloader específico mediante wheelie (http://androidroot.mobi/2012/05/27/introducing-wheelie-nvflash-for-asus-transformer-tf101-b70/) y extraer las particiones mediante nvflash (http://forum.xda-developers.com/showthread.php?t=1676845).

Es importante tener en cuenta que este método ha de ser probado previamente en entorno de laboratorio para que la ejecución sobre la evidencia sea lo más limpia posible.

–

Daniel Medianero

Enlaces duros (Hard Links)

Un enlace duro o hard link es una copia total del fichero, entendiendo por total la copia de los metadatos asociados. En el caso de Windows 7 nos estamos refiriendo a la MFT (Master File Table) del fichero.

Imaginemos que tenemos un fichero llamado “fichero.txt” y queremos hacer un hard link, lo ejecutaríamos con el siguiente comando:

Como resultado tenemos un enlace duro en el fichero “hard_link.txt”

Enlaces simbólicos (Soft Links)

El enlace simbólico es un enlace al fichero original, no una copia del mismo. Imaginemos que tenemos un fichero llamado “fichero.txt” y queremos hacer un soft link, lo ejecutaríamos con el siguiente comando:

Como podemos apreciar en la imágen, no se ha creado por falta de permisos.Esto es debido a que ciertas aplicaciones no se comportan de manera segura en presencia de enlaces simbólicos, por lo que la creación de estos enlaces requiere el privilegio “SeCreateSymbolicLink”.

Lo ejecutamos desde una consola con privilegios de administración:

Como resultado tenemos un enlace duro en el fichero “hard_link.txt“. Si abrimos la carpeta que contiene los ficheros podemos apreciar algunas diferencias a simple vista:

Pero vamos a ver las implicaciones de manea forense. Es por ello que tomamos evidencia de toda la carpeta (miento, en realidad de una unidad NTFS que contiene dicha carpeta). Para ello utilizé la herramienta FTK Imager y el contenedor forense AFF (Advanced Forensic Format). Mi evidencia forense es el fichero “links_w7.aff“, que tiene la siguiente información:

Created By AccessData® FTK® Imager 3.0.1.1467 110406

Case Information:
Acquired using: ADI3.0.1.1467
Case Number: Ejemplo hard and soft links
Evidence Number: 001
Unique description: links_w7
Examiner: dmedianero
Notes: Ejemplo hard and soft links

————————————————————–

Information for C:\tmp\links_w7:

Physical Evidentiary Item (Source) Information:
[Drive Geometry]
Bytes per Sector: 512
Sector Count: 18.432
Source data size: 9 MB
Sector count:    18432
[Computed Hashes]
MD5 checksum:    03d6fb63927ce8df2697a2ece063b13d
SHA1 checksum:   d4717b8960afd3bb7bb07556cf2877a73855c180

Image Information:
Acquisition started:   Thu Jan 05 16:40:53 2012
Acquisition finished:  Thu Jan 05 16:40:56 2012
Segment list:
C:\tmp\links_w7.aff

Para analizar la evidencia utilizaremos la conocida suite Sleuthkit. Antes que nada, vamos a fijarnos en la MFT del fichero original, el fichero “fichero.txt”:

$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 260  ()
Created:        Thu Jan  5 16:37:16 2012
File Modified:  Thu Jan  5 16:37:16 2012
MFT Modified:   Thu Jan  5 16:37:27 2012
Accessed:       Thu Jan  5 16:37:16 2012

$FILE_NAME Attribute Values:
Flags: Archive
Name: hard_link.txt, fichero.txt
Parent MFT Entry: 5     Sequence: 5
Allocated Size: 0       Actual Size: 0
Created:        Thu Jan  5 16:37:16 2012
File Modified:  Thu Jan  5 16:37:16 2012
MFT Modified:   Thu Jan  5 16:37:16 2012
Accessed:       Thu Jan  5 16:37:16 2012

Notese que la salida está limitada a los atributos $Standard_Information y $File_Name por claridad. Contrastemos dichos datos con la MFT de nuestro enlace duro o hard link:

$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 260  ()
Created:        Thu Jan  5 16:37:16 2012
File Modified:  Thu Jan  5 16:37:16 2012
MFT Modified:   Thu Jan  5 16:37:27 2012
Accessed:       Thu Jan  5 16:37:16 2012

$FILE_NAME Attribute Values:
Flags: Archive
Name: hard_link.txt, fichero.txt
Parent MFT Entry: 5     Sequence: 5
Allocated Size: 0       Actual Size: 0
Created:        Thu Jan  5 16:37:16 2012
File Modified:  Thu Jan  5 16:37:16 2012
MFT Modified:   Thu Jan  5 16:37:16 2012
Accessed:       Thu Jan  5 16:37:16 2012

Como podemos apreciar es exactamente la misma MFT. A continuación mostramos la MFT del enlace simbólico “soft_link.txt”:

$STANDARD_INFORMATION Attribute Values:
Flags: Archive, Reparse Point
Owner ID: 0
Security ID: 264  ()
Created:        Thu Jan  5 16:38:09 2012
File Modified:  Thu Jan  5 16:38:09 2012
MFT Modified:   Thu Jan  5 16:38:09 2012
Accessed:       Thu Jan  5 16:38:09 2012

$FILE_NAME Attribute Values:
Flags: Archive
Name: soft_link.txt
Parent MFT Entry: 5     Sequence: 5
Allocated Size: 0       Actual Size: 0
Created:        Thu Jan  5 16:38:09 2012
File Modified:  Thu Jan  5 16:38:09 2012
MFT Modified:   Thu Jan  5 16:38:09 2012
Accessed:       Thu Jan  5 16:38:09 2012

Como podíamos esperar todos los timestamps son posteriores. Un análisis pormenorizado nos llevaría a descubrir que en el soft link el atributo $Data ocupa 0 bytes, esto se debe, logicamente, a que es un enlace, no tiene contenido propio. La manera de “enlazar” se hace a través del atributo $Reparse_point, cuyo contenido muestro a continuación:

00000000:  0C00 00A0 3800 0000 1600 1600 0000 1600    ....8...........
00000010:  0100 0000 6600 6900 6300 6800 6500 7200    ....f.i.c.h.e.r.
00000020:  6F00 2E00 7400 7800 7400 6600 6900 6300    o...t.x.t.f.i.c.
00000030:  6800 6500 7200 6F00 2E00 7400 7800 7400    h.e.r.o...t.x.t.

Asique ya sabéis, los enlaces duros y simbólicos existen en Windows y aunque apenas sean utilizados, no por ello dejan de ser interesantes.

El enfoque en el presente artículo no es hablar del análisis en sí (lo haremos próximamente) sino sobre cómo poder realizarlo sin tener las fuentes originales. Como es bien sabido, muy pocas aplicaciones en el Market oficial son OpenSource, por lo que el código no está disponible. Sin embargo si que podemos acceder a los ficheros apk, ya que son copiados a los dispositivos en la ruta “/data/apk“. En esta ruta se copian todas las aplicaciones que tenga instaladas el dispositivo (también las que se compran, antes del refund como bien sabe @hidark ).

Tenemos por tanto acceso a la aplicación apk, ¿de qué nos sirve? la extensión apk es una variante de jar, por lo que podemos extraerla con la genial herramienta apktool. Para ello seguiremos los siguientes pasos:

1. Obtención del fichero AndroidManifest.xml
Para obtener este fichero a través del apk utilizamos la herramienta apktool con la opción b.
Este fichero contiene información esencial acerca de la aplicación. Para nuestra tarea la parte que nos interesa es la referente a los permisos que requiere, contenidos en el apartado uses-permission. Para una completa comprensión recomiendo leer la amplia documentación oficial al respecto.

2. Adquirir el fichero jar
Para ello nos servimos de la herramienta dex2jar. El funcionamiento de esta herramienta es el siguiente: traduce el fichero .dex (ejecutable de dalvik byetcode) a un fichero jar corriente.

3. Extraer el fichero jar
Es tan sencillo como utilizar un descompresor normal y corriente.

4. Acceso al código fuente
Al seguir el paso tres tendremos un directorio con ficheros .class de JAVA, los cúales pueden traducirse en sus .java correspondientes a través de herramientas como JAD, o incluso visualizarse directamente mediante herramientas como JD-GUI.

Hay que destacar que al hacer la decompilación se pierde mucha información, como nombre de variables, lo que dificulta el análisis manual del código. Normalmente se suele empezar por identificar ciertas funciones susceptibles de mal uso (funciones sink) y seguir el dataflow manualmente a través de entornos de desarrollo (Eclipse, NetBeans, etc).

Como hacer muchas veces lo mismo sin automatizar es pecado he preparado un pequeño script en bash que hace todo el proceso de manera automática, esto es:

1. Se definen en una variable del script las funciones que queremos localizar en el código JAVA resultante.
2. Se ejecuta el script, que recibe dos parámetros: el fichero apk y directorio de salida
3. Decompila el apk, extrae los permisos y ejecuta el grep análisis, dejando la salida en el fichero output.txt. Adicionalmente deja el código decompilado en el directorio de salida para su posterior revisión manual.

El script precisa logicamente tener instalado apktook, dex2jar y jad con los ejecutables en el path.
Está probado en Fedora, si hay algún problema por favor notificármelo a dmedianero@buguroo.com
Podéis descargarlo desde el siguiente enlace:

http://pastebin.com/SBu0bfky

Un saludo !!

Como todo en la vida, visto en perspectiva se gana en claridad. Cuando entras en ecosistemas de cliente te das cuenta de que en multitud de ocasiones no entienden correctamente la implicación de las vulnerabilidades a pesar de que se les indiquen con exactitud las líneas, ficheros, etc y que aunque sean programadores no van a ser capaces de discernir un falso positivo de una vulnerabilidad real. De todo esto surge una importante duda: ¿cómo actuar?
La respuesta es obvia: hay que ser flexible y permitir una parametrización que haga útil la herramienta a ambos tipos de usuarios. Problema resuelto, ¿o no?

Aún con los criterios definidos tomar la decisión de qué herramienta utilizar sigue siendo complicado. ¿cómo comparo varias herramientas? está claro que en el caso de las OpenSource tengo acceso a las mismas y puedo probar multitud de códigos con ellas, aún así salvo que tenga un análisis manual con qué comparar no puedo establecer un marco técnico unificado, y además extrapolar resultados de un puñado de códigos concretos no aporta una visibilidad real de la calidad técnica de una herramienta.
Cada vez el agujero es más profundo, ¿debemos pensar en dejar de cavar? No, de hecho hay más miga, pensemos en que como indicabamos al principio, el criterio de valoración de una herramienta no debe consistir únicamente en la detección. De cara a que sea útil en los ecosistemas cliente hay un puñado de requerimientos importantes que no deben menospreciarse: integración de la misma en el ciclo de desarrollo, apoyo a la corrección de las vulnerabilidades detectadas, gestión de los resultados, parametrización de los informes, creación de reglas personalizadas y un largo etcétera.

Desde la organización WASC (Web Application Security Consortium) han iniciado un proyecto para definir un criterio de evaluación de herramientas de análisis estático que tenga en cuenta estos requerimientos, se trata del SATEC (Static Analysis Tool Evaluation Criteria). Desde buguroo apoyamos estas iniciativas y formamos parte de las mismas.

Hasta el momento hay definido un pequeño borrador con las categorías, aunque por el momento está en fase muy alpha. Para apoyar el proyecto reomendamos seguir la lista de correo creada a tal efecto, y estar atento al twitter ofifical de WASC.

En los últimos artículos sobre SQL Injection hemos tratado siempre de dejar claro que uno de los métodos más eficaces para solventar este tipo de vulnerabilidades es realizar consultas parametrizadas.
Si bien hemos querido dejar claro que hay que prestar atención a la implementación, puesto que el simple hecho de parametrizar no es efecitvo (no solo es hacerlo, es hacerlo bien).

Hoy quiero transmitir una idea clara, que no debe caer como una losa sobre los programadores, pero debe ser tenida en cuenta: No siempre es posible parametrizar. ¿Porqué?
Las consultas parametrizadas o prepared statements solo sirven para datos, no funcionan en identificadores SQL o keywords. Es por ello que consultas como las siguientes pueden ser parametrizadas:

SELECT * FROM items WHERE producto = ?
SELECT * FROM items WHERE producto LIKE ? ORDER BY precio

Mientras que consultas como estas otras no:

SELECT * FROM ? WHERE producto = 'ebook'
SELECT * FROM items WHERE producto LIKE 'parametro%' ORDER BY ?

Tras ver esto la pregunta es obvia, si tengo una consulta que no puedo parametrizar, ¿qué hago? La respuesta no es simple ni genérica. Lo primero que hay que fijarse es en la consulta, ¿es necesario hacerla así? ¿puede reescribirse de manera que sí lo sea?
Mi recomendación personal en caso de que no lo sea es que el parámetro que va a formar parte de la consulta y que constituye un keyword o identificador SQL sea “mapeado”, esto es, que a ser posible se controle como un entero y que se transforme en el dato deseado a través de dicho mapeo.

Repasaremos brevemente algunas de las técnicas más utilizadas en aplicativos web, centrándonos en ataques de tipo SQLi.

+ Aprovechando case sensitive

El filtrado más rudimentario es aquel basado en los caracteres utilizados. Normalmente las bases de datos son case-insensitive por lo que el resultado de las consultas, en el caso particular de ataques SQLi, no se verá afectado:

Payload normal: ' or es_admin=1 --
Payload ofuscado: ' oR eS_aDmIn=1 --

Parece muy simple y tonto, pero esta técnica aún funciona en determinados sitios.

+ Aprovechando comentarios inline

En algunas ocasiones los filtros están basados en una sucesión de “or” (|| en el código) con los tags de la lista negra comparados, por limpieza de código el desarrollador añade un espacio entre estas sentencias sin darse cuenta de que ese espacio compromete la seguridad de su filtro. Vemos un estracto del código de filtrado:

stristr($variable, 'INSERT') || stristr($variable, 'UNION') || .......

Gracias a los comentarios inline es posible evadir este filtrado, lo vemos a continuación:

Payload normal: ' or es_admin=1 --
Payload ofuscado: '/**/or/**/es_admin=1/**/--

Notese que al introducir comentarios inline nos evitamos tener que utilizar espacios en la sentencia.

+ Aprovechando ejecución dinámica de consultas

La ejecución dinámica de consultas es una característica de las BBDD que las permite recibir un string que contiene la consulta dentro de una función de la base de datos que ejecuta dicha consulta. Leído así uno no se entera de nada. La explicación es más simple, la base de datos recibe un string que aparentemente no es una consulta, pero que en ejecución se “transforma” en consulta.
Con un ejemplo mejor, pensemos en ORACLE, si introducimos la siguiente sentencía:

'IN'||'SERT'

Es un string que no contiene una consulta, es al ejecutarse dinámicamente cuando la base de datos realiza la concatenación que tiene como resultado una consulta. Como ya imaginaréis esta funcionalidad se utiliza para evadir filtros.

En MySQL: 'IN' 'SERT'
En MS-SQL: 'IN'+'SERT‘

Otra variante muy utilizada es el uso de la función CHAR. Esta función recibe un número y en ejecucion se “transforma” en el caracter ASCII correspondiente a dicha tabla, por ejemplo:

CHAR(73)+CHAR(78)+CHAR(83)+CHAR(69)+CHAR(82)+CHAR(84)

Equivale a INSERT. Hay que tener en cuenta que en ORACLE esta función se invoca con CHR en lugar de CHAR. Por otro lado esta es una de las muchas funciones que pueden utilizarse, hay muchas (SUBSTR, TRANSLATE, etc)

+ Aprovechando URL Encoding

Es uno de los métodos más conocidos, hay muchas herramientas automáticas que nos permiten traducir nuestras consultas a encoding URL, UTF-8, etc, dejo algunos enlaces útiles:

http://www.w3schools.com/TAGS/ref_urlencode.asp
https://www.owasp.org/index.php/Category:OWASP_CAL9000_Project
https://addons.mozilla.org/es-ES/firefox/addon/hackbar/

+ Aprovechando Null Bytes

Esta técnica está enfocada a evadir WAFS. Los firewalls de aplicación tienden a estar programados en lenguajes nativos como C o C++. Es por ello que el uso de Null Bytes puede permitirnos evadir dichos dispositivos.
Para una definición formal de este tipo de ataques recomiendo la lectura de las siguientes referencias:

http://projects.webappsec.org/w/page/13246949/Null-Byte-Injection
http://hakipedia.com/index.php/Poison_Null_Byte

A continuación un ejemplo de este tipo de ofuscación:

Payload normal: ' or es_admin=1 --
Payload ofuscado: %00' or es_admin=1 --

+ Aprovechando anidación de expresiones

Algunos WAFS y filtros leen de izquierda a derecha y cuando encuentran una conincidencia con la lista negra la eliminan. El problema es cuando no lo realizan recursivamente, y podemos aprovecharnos de ello, veremos cómo:

Payload normal: INSERT
Payload ofuscado: ININSERTSERT

Un WAF o filtro con este problema eliminaria el tag INSERT, dejando el IN que hay delante y el SERT que hay detrás juntos, formando para nuestra satisfacción una sentencia INSERT

Hasta aquí el respaso de hoy, volveremos a hablar de técnicas de ofuscación en el futuro.

Para ilustrarlo con un ejemplo, haremos referencia a una vulnerabilidad de este tipo muy conocida, la redirección arbitraria en el OWA de Microsoft Exchange Server 2003:
SA14144 – http://secunia.com/advisories/14144/

Hay varias maneras de realizar redirecciones: HTTP status code 3xx, javascripts, tags META, refresh header, etc pero hoy nos detendremos en uno de los más usuales: utilizar el propio código del aplicativo para realizar la redirección. Supongamos por ejemplo el siguiente código JAVA:

public class RedirectServlet extends HttpServlet {
protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
String query = request.getQueryString();
if (query.contains(“url”)) {
String url = request.getParameter(“url”);
response.sendRedirect(url);
}
}
} 

Como podemos apreciar, el código está buscando una variable “url” en la petición, y en caso de encontrarla realiza una redirección al contenido de dicha variable mediante la función “sendRedirect“. Algo similar al caso del OWA.
En la práctica esto produce que tengamos una URL similar a la siguiente:

https://www.mibanco.com/exchweb/bin/auth/owalogon.asp?url=https://www.mibanco.com/exchange/&reason=0  

El proceso es el siguiente, al introducir las credenciales el usuario es redirigido a la URL contenida en la variable URL. Esto permite, por ejemplo, que un usuario malicioso podría construir la siguiente URL:

https://www.mibanco.com/exchweb/bin/auth/owalogon.asp?url=https://www.bancofake.com/exchange/&reason=0  

En este caso, tras introducir las credenciales, el usuario sería redirigido a bancoface.com, habiendo sido víctima de un phishing. Al robo de credenciales hay que añadir que el daño a la imagen es irreparable, pensemos en titulares del tipo “una vulnerabilidad en mibanco facilita el fraude a sus propios clientes“.

A continuación, vamos a centrarnos en cómo solucionar esta vulnerabilidad. Volvemos al código inicial, pero fijándonos únicamente en las dos líneas que producen la vulnerabilidad:

String url = request.getParameter(“url”);
response.sendRedirect(url);  

Lo que está claro es, que el aplicativo no debe utilizar entrada de usuario, por lo que desde el código podemos realizar algunas aproximaciones a su solución:

1. Filtrar la entrada.
Es posible aplicar filtros en base a expresiones regulares, si bien esta no debe ser una solución, sino una medida adicional de seguridad. La causa es que un filtro (especialmente los basados en listas negras) puede ser evadido.

2. Restringir el uso de la variable de entrada.
Una opción interesante es no dejar bajo control del usuario el dominio destino, sino únicamente el path, en ese caso el usuario podría construir únicamente paths alterados. Si bien no es una solución elegante puede resultar efectiva, por ejemplo si implementáramos lo siguiente:

String url = request.getParameter(“url”);
response.sendRedirect(“https://www.mibanco.com/” + url);  

Un atacante no podría redirigir contra la URL maliciosa. No obstante es recomendable analizar en profundidad esta solución, ya que puede acarrear vulnerabilidades nuevas como Path Transversal.

3. Mapeado de recursos.
Esta solución es más compleja pero muy efectiva, consiste en que el parámetro que se recoge es de un tipo numérico e internamente en el código del aplicativo se transforma en la URL destino mediante un mapeo. Si optamos por esta solución debemos forzar en el código que la entrada sea del tipo que esperamos y únicamente en el rango deseado.

Detectar estas vulnerabilidades no siempre es fácil, una auditoría de tipo caja negra con frecuencia no cubre la totalidad de las URLs y parámetros. Es por ello que es recomendable una auditoría de código a tal efecto. Herramientas como buguroo bugScout tienen un alto ratio de detección de este tipo de vulnerabilidades, de manera automática y en multitud de lenguajes de programación.

Referencias:

CWE-601: http://cwe.mitre.org/data/definitions/601.html
OWASP: https://www.owasp.org/index.php/Open_redirect
WASC: http://projects.webappsec.org/w/page/13246981/URL-Redirector-Abuse

Fedora instala por defecto repositorios denominados updates. A continuación muestro un extracto del fichero /etc/yum.repos/fedora-updates.repo:

[updates]
name=Fedora $releasever - $basearch - Updates
failovermethod=priority
#baseurl=http://download.fedoraproject.org/pub/fedora/linux/updates/$releasever/$basearch/
mirrorlist=https://mirrors.fedoraproject.org/metalink?repo=updates-released-f$releasever&arch=$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$basearch

Como podemos apreciar no hay distinción en base a tipos de actualizaciones. ¿Quiere decir eso que no puedo realizar unicamente actualizaciones de seguridad en Fedora? La respuetsa es no. Como veremos sí es posible.

Yum Secuirty Plugin
Para estas tareas tenemos un plugin de yum disponible. Para instalarlo simplemente ejecutamos el siguiente comando:

Para listar las actualizaciones de seguridad pendientes ejecutamos el siguiente comando:

yum list-sec

Y para realizar actualizaciones de seguridad sustituimos el clasico yum update por el siguiente comando:

yum update --security

Para más información y opciones es recomendable leer la guía de seguridad de Fedora.

http://www.elreservado.es/news/view/220-noticias-espias/1131-metadatos-datos-incrustados-en-la-informacion-pueden-delatarnos

A continuación reproduzco el texto del mismo:

La información es uno de los activos más importantes de una entidad. Las causas de esta afirmación son múltiples: la pérdida, sustracción o fuga de información hacia entidades competidoras les proporciona una clara desventaja, por no hablar de las pérdidas económicas. Casos hay cientos, por nombrar uno haremos referencia a la reciente batalla legal por espionaje industrial entre las multinacionales Nokia y Apple [1]. De lo que no cabe duda es de que tener la información adecuada de la competencia es tan inmoral como lucrativo para el beneficio propio.

¿Cómo se guarda la información? Desde hace ya varias décadas el cambio tecnológico nos lleva cada vez más hacia los soportes digitales. Desde el punto de vista de la protección de la información esto cambia el paradigma: la información sensible puede estar en un servidor en un sótano custodiado por fuertes medidas físicas de seguridad (guardias, accesos biométricos, etc) y sin embargo es posible acceder a la misma desde la otra punta del mundo a través de un hilo telefónico.

En la siguiente serie de artículos repasaremos algunas de las técnicas utilizadas actualmente para obtener información sensible desde el punto de vista de un atacante externo que no dispone, a priori, de contactos dentro de las entidades objetivo. Veremos cómo es posible obtener multitud de informaciones que no deberían ser accesibles, repasaremos también, algunos casos relacionados que han salido a la luz pública.

Comenzaremos con los Metadatos. Los metadatos son datos que hablan de datos [2]. Por ejemplo en un libro los datos referentes a su fecha y lugar de impresión, ISBN, etc. En el mundo electrónico los metadatos son información incrustada, por ejemplo en ficheros ofimáticos o imágenes, que aportan información acerca de los propios ficheros. Como veremos a continuación estos datos pueden ser inofensivos si bien en algunos casos pueden constituir una información muy valiosa.

Pongamos un ejemplo para verlo con claridad, descargamos de la web del CNI un documento pdf titulado “La inteligencia como respuesta a los nuevos retos de seguridad” [3]. Este documento es un simple pdf (portable document format), pero contiene más información de la que podemos ver abriéndolo con un visor de pdfs [3]. Utilizando herramientas públicamente disponibles podemos extraer dicha información, en este ejemplo utilizaremos unas herramientas denominadas Exiftool [5], que muestra la siguiente metainformación sobre el fichero:

File Name : ev_113.pdf
Directory : .
File Size : 85 kB
File Modification Date/Time : 2011:04:07 12:25:30+02:00
File Permissions : rw-rw-r–
File Type : PDF
MIME Type : application/pdf
PDF Version : 1.6
Linearized : No
Tagged PDF : Yes
XMP Toolkit : Adobe XMP Core 4.0-c316 44.253921, Sun Oct 01 2006 17:14:39
Metadata Date : 2008:12:30 10:19:19+01:00
Format : application/pdf
Document ID : uuid:3efef69a-98de-4f18-bace-7676164f5cb8
Instance ID : uuid:a8953cc0-3ab1-4992-87e0-ba823d9f14c2
Page Count : 19
Language : ES
Create Date : 2007:09:13 18:28:17Z
Producer : Acrobat Distiller 4.0 for Windows
Modify Date : 2008:12:30 10:19:19+01:00

Muchos de los campos son autoexplicativos, la información más significativa en este caso son las herramientas software utilizadas para la creación de este documento (Acrobat Distiller 4.0 for Windows) y las fechas de creación (2007:09:13 18:28:17Z) y de modificación (2008:12:30 10:19:19+01:00). En algunos documentos los datos pueden ser más jugosos, incluyendo usuarios del sistema operativo, rutas internas hacia las impresoras, versionado software utilizado por la entidad o los datos cruciales que veremos en dos casos prácticos.

El caso Tony Blair y las armas de destrucción masiva

En el 2003 el ejecutivo de Tony Blair publicó un documento en el contexto de la Guerra de Irak y la supuesta existencia de armas de destrucción masiva [6]. El fichero en cuestión contenía multitud de metadatos en los que se podía comprobar la multitud de revisiones [7] que dicho documento había recibido por parte de miembros de su gabinete (con nombres y apellidos), quedando en evidencia la manipulación del mismo.

Utilización de metadatos para capturar pederastas

El 18 de mayo del 2009 saltó la noticia de que un pederasta había sido detenido en Guipúzcoa [8]. La investigación en este caso tuvo mucho que ver con los metadatos de las fotografías que el pederasta colgaba en Internet. Muchas cámaras de fotos, incluidas las de los modernos teléfonos móviles, incrustan metadatos en las mismas, algunos de ellos son de vital importancia en estas investigaciones, estamos hablando de coordenadas GPS en las que se toma la fotografía, versión y modelo del dispositivo, etc.

Buscando documentos

La manera más sencilla de acceder a documentos es a través de los propios buscadores. Por ejemplo en Google podemos afinar la búsqueda para que nos muestre solo determinados documentos. Imaginemos que queremos listar los documentos de Word con extensión .doc que ha indexado el motor de búsqueda en la página web del Ministerio de Defensa (mde.es), sería tan simple como introducir el siguiente texto en el campo de búsqueda:

A fecha del 7 de abril del 2011 podemos apreciar que aparecen 167 resultados/documentos.

Hay varias herramientas automáticas públicas destinadas a recopilar metadatos en documentos disponibles en Internet. Además de la ya mencionada Exiftool [5] una de las más utilizadas es la FOCA [8]. Existen igualmente multitud de herramientas para eliminar metadatos de los ficheros, desde el propio Microsoft Office 2007 [10] es posible eliminar metadatos haciendo click en “Menú Office -> Preparar -> Inspeccionar Documento”.
Como conclusión, hay que prestar atención a este tipo de fugas de datos, ya que en algunos casos esta información puede ser muy perjudicial para la entidad que los expone. Y lo más peligroso es que en la mayoría de los casos las entidades no son conscientes de ello.

Referencias:

[1] Nokia vuelve a denunciar a Apple: http://www.suite101.net/content/nokia-vuelve-a-denunciar-a-apple
[2] Wikipedia: http://es.wikipedia.org/wiki/Metadato
[3] La inteligencia como respuesta a los nuevos retos de seguridad: http://www.cni.es/comun/recursos/descargas/ev_113.pdf
[4] Acrobat Reader: http://get.adobe.com/es/reader/
[5] Exiftool: http://www.sno.phy.queensu.ca/~phil/exiftool/
[6] Documento Tony Blair: http://www.computerbytesman.com/privacy/blair.doc
[7] Microsoft Word bytes Tony Blair in the butt: http://www.computerbytesman.com/privacy/blair.htm
[8] Detenido un pederasta por colgar fotos de amigos de sus hijos en internet: http://www.abc.es/20090518/nacional-sucesos/detenido-pederasta-colgar-fotos-20090518.html
[9] FOCA: http://www.informatica64.com/foca/
[10] Microsoft Office: http://office.microsoft.com/es-es/

Informa: Daniel Medianero, dmedianero@buguroo.com
Security Consultant en Buguroo Offensive Security (http://www.buguroo.com)

En PHP hay decenas de funciones para interactuar con Bases de Datos MySQL. Es habitual encontrar implementaciones deficientes y de rápida programación (desde el punto de vista del programador). Por ejemplo, tenemos la siguiente página de login:

function login($usuario, $password) {
$consulta = “select * from user where usuario = ‘$usuario’ and password = ‘$password’”;
$resultado= $db->query($consulta);
if($db->count_rows($resultado)) {
$row = $db->fetch_assoc($resultado);
}

Como podemos apreciar, esta función no filtra los parámetros que recibe (aunque los mete entre comillas simples, de manera que delega la seguridad en las magic quotes) en principio es vulnerable, no obstante hay que rastrear desde dónde vienen los parámetros $usuario y $password, los encontramos en otro fichero con este aspecto:

$usuario = $_POST['usuario'];
$password = $_POST['password'];

Como se puede observar, las variables se toman directamente de la entrada de usuario ¿Cómo solucionar esto? La respuesta son las consultas parametrizadas.

Las consultas parametrizadas realizan 3 pasos:

1. Preparación de la consulta (método prepare)
2. Paso de parámetros (método bind_param)
3. Ejecución de la consulta (método execute)

A continuación muestro el código tal y como debería estar implementado:

function login($usuario, $password) {
$sql = $db->prepare(“SELECT usuario, password FROM user WHERE usuario = ? AND password = ?”);
$sql->bind_param($usuario, $password);
$resultado= $db->query($consulta);
$sql->execute();
$sql->bind_result($this->user_id, $this->usuario, $this->password);
$sql->fetch();
……..
$sql->close();
}

Tal y como viene indicado, en el prepare no se incluyen los parámetros, sino que se indican con el símbolo “?“. En bind_param se indican en órden los parámetros que serán pasados a la consulta y en el execute se ejecuta. Posteriormente se recogerían los datos con bind_result.

Hay que destacar que este es un ejemplo de libro. Para facilidad de entendimiento he omitido el control de errores sobre la consulta. En algunos casos no es posible establecer consultas parametrizadas, en cambio, en los que si, es recomendable el filtrado de los parámetros de entrada, por ejemplo, mediante librerías destinadas a tal efecto como ESAPI de OWASP. ]]> http://garmedsecurity.com/2011/04/utilizando-preparedstatements-en-php/feed/ 0