RSS |

Blog de Omar

Just another WordPress weblog

Advertisement

Si se han tomado la molestia de revisar el Top Ten de OWASP 2010 habrán notado que en la cúspide de esa concisa lista se encuentra el término “A1.- Inyecciones” y lejos de pensar que sólo existen las inyecciones del tipo SQL, lo cual no es cierto, hoy vamos a explicar y revisar las inyecciones del tipo PHP.

Lo cierto es que hace poco me topé con una página web con este tipo de vulnerabilidad, así que me he animado a explicar un poco como funciona esto. Por cierto en la lista candidata para el Top Ten del OWASP 2013 las vulnerabilidades del tipo Inyecciones sigue siendo la primera.

image

La historia es así: me contrataron para hacer la revisión de una página web (un Ethical Hacking), inicié revisando los formularios, los parámetros que se envían entre páginas, no suelo ponerle demasiada atención al XSS a menos que sean persistentes (no saben lo difícil que es explicar y que logren entender el riesgo de un XSS reflejado sobre una página web), empecé a buscar SQL Injection y que creen? si pensaste que sí, estas equivocado, nada!! no encontré nada.

Allí estaba yo… tirado en mi cama como una ballena varada en la orilla del mar pero no suplicando porque me regresen al agua sino preocupado por mostrar alguna vulnerabilidad que deje satisfecho a las personas que me habían contratado y es que cuando sólo les muestras XSS reflejado … te miran con cara de pocos amigos, como diciendo: “¿para esto te he pagado? no jodas pues!!!”.

Para este post voy a simular lo más posible la vulnerabilidad que encontré pero en mi aplicación web y obviamente no en la verdadera página vulnerable, ¿los motivos? no me quiero meter en problemas legales.
Aquí muestro la secuencia del ataque, espero les guste:

  1. Browseando encontré este formulario, no encontré inyecciones del tipo SQL se enviaba el comentario pero advertí que no se usaban los clásicos botones para “Enviar” o “Cancelar” el comentario del formulario sino que se utilizaban imágenes para realizar la misma función. Lo extraño era que para que las imágenes enviaran el formulario y cumplieran funciones distintas en realidad habían dos (02) formularios embebidos.

    image

  2. Revisé el código HTML y encontré los dos formularios, además encontré un campo invisible que también formaba parte del segundo formulario. Tranquilos en la siguiente imagen se ve y explico mejor esto para que todos los logren entender.

    image

  3. Como ya les comenté líneas arriba no encontré inyecciones del tipo SQL (una lástima realmente), así que decidí revisar las variables que se pasaban por el formulario cuando alguien decidía cancelar su comentario. Para analizar las variables que se pasaban en el formulario (hacia la misma página web si es que han notado el ACTION en el formulario) me apoyé del plugin de Firefox, TAMPER DATA. Aquí les muestro lo que me mostró el TAMPER cuando cancelaba el comentario, es decir cuando le daba click en la “X” del formulario.

    image

    Lo curioso ocurrió cuando advertí que al enviar el parámetro ELIMINAR cuyo valor era “eliminado”, aparecía encima del formulario un mensaje que decía que mi comentario había sido eliminado, un momento…. “ELIMINADO” es el valor de la variable, verdad? entonces… ¿qué pasa si modifico con el TAMPER el valor de esa parámetro? quizás sea sólo una coincidencia o de pronto algún STRING toma ese mismo valor y lo concatena.

    image

    La suposición era cierta, el parámetro “ELIMINAR” envía su valor a la página web y luego alguna variable toma ese valor y lo concatena con alguna cadena para mostrar el mensaje encima del formulario.

  4. Ahora toca entender un poco del lenguaje de programación PHP, vamos a tratar de ir suponiendo como el programador de la APP ha escrito el código. Antes de continuar debo aclarar que este punto (o sea el punto 4) no es un análisis que hice cuando realicé en verdadero Ethical sobre la página web, ya mas o menos sabía que debía colocar como valor del parámetro enviado (quizás sea algo de práctica y porque ya antes había visto esta vulnerabilidad y toca ser prácticos) y como este blog está dedicado a explicar como es que funcionan las cosas vamos a explayarnos un poco. Si quieren sólo ver como funciona el ataque sin entender ni papa pueden ir a otros blogs donde se jactan de lanzar un ataque sin explicar como funciona y al que tiene el atrevimiento de preguntar le terminan lanzando puntiagudos adjetivos como “lammer” o “script kiddies”, en fin….. esa gente son un caso, aquí vamos.

    image

    Entonces…. que pasaría si modificamos el valor de la variable $eliminar y lo ponemos algo más interesante como para ver que pasa con el código PHP. Podríamos poner algo así:

    image

    Hemos modificado la variable $eliminar y lo hemos con modificado convenientemente para que no genere ningún error de sintaxis, si se dan cuenta hemos colocado estratégicamente las comillas, los puntos y comas (;) y hasta agregamos una variable adicional para que se concatene con el resto del STRING. Perfecto!!! somos muy hackers!! sólo que si fuera así NO funcionaria. ¿por qué? sigue leyendo este post para enterarte el motivo. La verdadera salida en la web sería de la siguiente manera:

    image

    Si han logrado notar lo único que está ocurriendo es que se está concatenando como una cadena y se está haciendo un ECHO de la misma, nada mas y no se está ejecutando la función PRINT de PHP. Así que… lamentablemente la suposición no es correcta y así NO lo ha hecho el programador.


    ¿Entonces cómo lo ha hecho el programador?

    Pues toda la explicación anterior ha servido para entender como es que se hubiera podido concatenar cadenas con un parámetro modificado por un atacante, es decir, la explicación superior sólo sirvió para que se den una idea de como es el ataque realmente. Ahora si vamos a explicar como es que realmente el programador escribió el código, el programador escribió así realmente:

    image

    La función EVAL( ) de PHP está explicada en la página oficial de documentación del lenguaje: AQUÍ, y como verán permite que se ejecute automáticamente el valor de la variable sin necesidad de concatenar cadenas con puntos (.), obviamente usar la función EVAL( ) tiene sus riesgos y muchas veces es usado para obtener un RETURN del tipo NULL o FALSE y al parecer el programador la utilizó con ese propósito, si quieres entender más sobre la función EVAL( ) revisa estos dos links:

    - Aquí un blog donde lo explican paso por paso, muy detallado y muy didáctico: AQUÍ
    - En la página del proyecto OWASP también está explicado pero muy superficialmente, de igual forma conviene verlo: AQUI


    Importante:

    Sin la función EVAL( ) la inyección de código PHP no hubiera sido posible.

    Con el código que realmente escribió el programador, el resultado de la página web al modificar la variable $eliminar y colocar la función PRINT sería el siguiente:

    image

  5. Interactuando con el Sistema Operativo y CURL
    Ahora que ya sabemos como funciona la inyección de código PHP vamos interactuar con el Sistema Operativo (en este caso un Linux Fedora 14) colocando comandos que se ejecuten sobre el sistema. Básicamente usaremos la función EXEC ( ) que nos permitirá ejecutar comandos a nivel del sistema y lo mezclaremos con la función PRINT ( ) para que sean mostrados como resultado en la página cargada. Luego automatizaremos el ataque con un script que he desarrollado en PHP con CURL y que todo sea más sencillo.

    image

    Por ejemplo aquí hemos ejecutado el comando “WHOAMI” y nos ha devuelto como resultado “APACHE”, si prueban ejecutando otros comandos verán que les devuelve el resultado siempre y cuando el usuario Apache tenga los privilegios para ejecutarlo, sin embargo, hay un pequeño detalle con esto:

    A) Si el comando que ejecutamos devuelve más de una línea como resultado, por ejemplo, el comando “LS /ETC/” sólo se imprime en la pantalla la primera línea del resultado y no todo el listado del resultado.
    B) Que flojera estar ejecutando comando por comando con el TAMPER DATA, no terminaríamos nunca con lo que quisiéramos logra, así que toca automatizar el ataque con un SCRIPT.

  6. Automatizando el Ataque con CURL
    Desarrollé un pequeño script que automatiza el ataque y me permite colocar el comando que quiero ejecutar de manera sencilla, obviamente tocaría customizar el script para algún otro caso particular. Les comparto el script para que puedan revisarlo ya que no está nada complicado.

 

Ahora que ya he automatizado el ataque puedo hacer muchas cosas más con esta vulnerabilidad pero eso lo estoy haciendo en el videotutorial que voy a colgar mañana (al menos eso espero), cosas como: Ejecutar comandos en la base de datos y apoderarme del servidor jejeje.

Saludos,

 

Popularity: 18% [?]

Si te gusto este post, asegurate de suscribirte a mi RSS feed!

Omar Palomino

Hola mi nombre es Omar Palomino. Si te gustan las noticias de mi blog, no olvides suscribirte a la página. Puedes leer más en Acerca de MI, o bien ponerte en contacto conmigo al correo: omarc320@gmail.com

More Posts - Website

Post Relacionados

  • No Related Posts

SI TE GUSTO ESTE ARTICULO, COMPARTELO!


Comments

There are 4 comments for this post.

  1. Alguien on Reply to this comment Abril 11, 2013 11:50 pm

    Hola Omar, excelente post :)

    Un saludo.

  2. Alguien 2 on Reply to this comment Mayo 5, 2013 2:00 am

    Omar tus videos tutoriales son muy buenos y muy didacticos a la hora de explicar, sigue asi y ojala de que ya estes posteando otros tutos :)

  3. BC on Reply to this comment Julio 6, 2013 8:39 am

    Hola Omar, buen post, he tratado de repetir el ejemplo, pero no he logrado ejecutar el código inyectado de prueba. ¿Será que tengo que configurar algo en php.ini relacionado a eval()?. Gracias

  4. Omar Palomino on Reply to this comment Julio 8, 2013 9:52 am

    @BC,
    No toca configurar nada, ahora que veo el post no he colocado el código fuente, estas probando con el tuyo? Subiré el código más tarde.
    Saludos,

    Omar

Write a Comment

*

Spam Protection by WP-SpamFree