Mostrando entradas con la etiqueta vulnerabilidades. Mostrar todas las entradas
Mostrando entradas con la etiqueta vulnerabilidades. Mostrar todas las entradas

[Part 2][EN] Hacking NETGEAR JWNR2010v5 Router - Command Injection

[Part 1] Hacking NETGEAR JWNR2010v5 Router - Authentication Bypass
[Part 2] Hacking NETGEAR JWNR2010v5 Router - Command Injection


We already saw how to bypass the authentication so in this post I want to focus in the compromise of the underlying system. In order to do this we have to understend how the router works internally and the management of the administration interface.

 Checking the filesystem we got in the previous post I found that everything is handled by just one cgi called setup.cgi:


# ls -l | grep cgi
lrwxrwxrwx 1 root root     18 Jul 28 07:51 conf -> restore_config.cgi
lrwxrwxrwx 1 root root      9 Jul 28 07:51 htpwd_recovery.cgi -> setup.cgi
-rwxr-xr-x 1 root root  59784 Apr  1 01:34 restore_config.cgi
-rwxr-xr-x 1 root root 613588 Apr  1 01:34 setup.cgi
-rwxr-xr-x 1 root root 277152 Apr  1 01:34 setupwizard.cgi
lrwxrwxrwx 1 root root      9 Jul 28 07:51 upgrade_flash.cgi -> setup.cgi

One of the most common vulnerabilities we can see on SOHO routers are command injection through bad implemented functions, so my priority is to find where a command is executed to against the system and that allows me to control the input. For this I opened setup.cgi in IDA and search for keywords, in this case '/bin':




The ping command caught my attention as it meets both conditions. In this case the webpage that handles this is diag.htm which allows the user to perform different tests to validate the internet connectivity.



By opening diag.htm and reading the source code we find the first interesting thing. Input data is validated client side, so just changing return ping_ck() by return true or modifying the POST request we can send our crafted data.



As you can see above we tried to inject a command appending ';' to the IP address but the command never reaches the server. It's filtering it server side, so let's take a look at the cgi:



As you can see, it searches for a semicolon in the request and if exists the command is never executed...but..what happens here? It only filters the semicolon so if we replace it with '&&' we bypass the check and the command is successfuly executed...or it should...


If we run the command against the system we receive a 403 error but I noticed that setup.cgi gets a GET numeric parameter as follows...setup.cgi?id=0000000 So let's move again to IDA and search for 'id=' string:


First main() search for POST parameters and environment variables, if not found seek for GET parameters. In case it finds 'id' runs strtol() and if succeed extract the content of /tmp/SessionFile and compares against the id parameter where if doesn't match returns the 403 error.

 Finally we know that we need to sign the request with this parameter in order to run the command, so we use the auth bypass vulnerability from the previous post to access the web interface, scrap the source code to extract a valid sessionid before it changes, craft the injection and returns the response.

Here is a script to do this:


And finally we got the expected result in the response after running a 'pwd' command:


Unlike the previous vulnerability this only affects to two models JWNR2000v5 and JWNR2010v5.

In the following link you can find a PoC exploit:

 https://github.com/remot3/exploit-POC/blob/master/NETGEAR_JWNR2010v5.py

[Part 1] Hacking NETGEAR JWNR2010v5 Router - Authentication Bypass
[Part 2] Hacking NETGEAR JWNR2010v5 Router - Command Injection



It has been a long time since my last update so today I want to show you two vulnerabilities found while reversing the firmware from a NETGEAR router. The exploitation of these two vulnerabilities provides the attacker full remote unauthenticated root access to the device if it has WAN administration enabled.

First things first, the content you are about to read is intended as educative content, do not hack random thing out there, don't be stupid. Ok, let's start with this. In this case I analyzed the firmware 1.1.0.31 published on 05/11/2015 for the Netgear JWNR2010v5.

You can download the file here: http://www.downloads.netgear.com/files/GDC/JNR1010V2/ N150_N300_FW_V1.1.0.31_1.0.1.zip

From the binwalk output we know that the arch is MIPS and there is a SquashFS filesystem at 0x160000 which we extract using dd:



DECIMAL         HEX             DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
60352           0xEBC0          U-Boot boot loader reference
[...]
131072          0x20000         uImage header, header size: 64 bytes, header CRC: 0x23F4018D, created: Thu Nov 21 21:18:53 2013, image size: 1266253 bytes, Data Address: 0x80000000, Entry Point: 0x8000C2F0, data CRC: 0xE8A06868, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
131136          0x20040         LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 4632092 bytes
1441792         0x160000        Squashfs filesystem, little endian, version 4.0, compression:lzma (non-standard type definition), size: 2376782 bytes,  1160 inodes, blocksize: 131072 bytes, created: Thu Nov 21 21:18:35 2013
[...]
4028341         0x3D77B5        End of Zip archive


# dd if=N300.bin bs=1 of=N300.squashfs skip=1441792
2752512+0 records in
2752512+0 records out
2752512 bytes (2.8 MB) copied, 2.73591 s, 1.0 MB/s

# file N300.squashfs
N300.squashfs: Squashfs filesystem, little endian, version 4.0, 2376782 bytes, 1160 inodes, blocksize: 131072 bytes, created: Thu Nov 21 21:18:35 2013

# ./unsquashfs_all.sh N300.squashfs
[...]
created 850 files
created 60 directories
created 144 symlinks
created 106 devices
created 0 fifos
File system sucessfully extracted!


I use to run a script that test every file in the webserver and returns the error code, so I did, and from this preliminary file access analysis I found that an unauthenticated user can access every static file located in the webroot which is interesting but not very useful, anyway reviewing the results of this test I found the tip of the iceberg. Every time I ran the script and reached one file the following files were available without authentication (Error 501 == 200):



501http://192.168.1.1:8080/401_access_denied.htm
501http://192.168.1.1:8080/401_recovery.htm
401http://192.168.1.1:8080/Add_WPS_Client.htm
200http://192.168.1.1:8080/advanced.js
401http://192.168.1.1:8080/adv_index.htm
[...]
401http://192.168.1.1:8080/BAS_basictop.htm
200http://192.168.1.1:8080/bas_bpa.js
200http://192.168.1.1:8080/base.gif
401http://192.168.1.1:8080/BAS_ether_h.htm
401http://192.168.1.1:8080/BAS_ether.htm
[...]
401http://192.168.1.1:8080/BRS_05_networkIssue.html
401http://192.168.1.1:8080/BRS_check_manulConfig.html
401http://192.168.1.1:8080/BRS_hijack_index.htm
401http://192.168.1.1:8080/BRS_hijack_success.htm
401http://192.168.1.1:8080/BRS_index.htm
501http://192.168.1.1:8080/BRS_netgear_success.html [From this point every 401 error becomes a 501]
501http://192.168.1.1:8080/BRS_plzWait.html
501http://192.168.1.1:8080/BRS_RUS_auto_account_input.html
501http://192.168.1.1:8080/BRS_RUS_auto_attention.html
[...]

And even worse...when I ran the script again every file returned a 501 error, so by doing this I disabled the authentication for the router somehow and with this we reached the "IDA Time!". By analyzing the router behaviour we can see that the authentication is handled by the webserver binary, so we import it to IDA and search for our reference string ( BRS_netgear_success.html ) which returns an intermediate function between 'main' and other function that we called 'auth_req_check' because of a .htpasswd reference.




This intermediate function will be called 'url_handle' as we can see a clasic staircase pattern comparing the reveived URL with hardcoded strings using strstr() function and executing different actions. Now we identified and isolated the authentication and url handler functions, lets move to our suspicious string. As you can see in the following image if the url contains the string ( BRS_netgear_success.html ) it moves to an interesting piece of code which sets two variables in the nvram to 0 (need_not_login and start_in_blankstate)




With this in mind it's easy to understand what is this doing, wen we access BRS_netgear_success.html the router redirects to NETGEAR webpage just to check whether we have internet access or not, and allows the user to access the router without credentials just for change the administrative password...but...this should be only allowed the first time the router is connected which is not the case... Finally lets confirm our assumptions checking where the bypass is done. For this, we have to move to the 'auth_req_check' function that we named previously ( offset 00403858 if you want to check) and read from the beginning where the function checks the existence of the .httpasswd file. If yes, we find a reference to start_in_blankstate where it's compared to be different to 1 and if yes the login is bypassed:



With the we confirmed that if start_in_blanckstate is 0 the .htpasswd is disabled and we have free access to the admin panel of the router.

So in short, if we hit this URL http://[IP_ROUTER]:[PORT]/BRS_netgear_success.html the login for every page in the router is temporary disabled.

 I could confirm that the following models are vulnerable to this: NETGEAR_JNR1010v2, NETGEAR_JNR3000, NETGEAR_JWNR2000v5, NETGEAR_JWNR2010v5, NETGEAR_N300, NETGEAR_R3250, NETGEAR_WNR2020, NETGEAR_WNR614, NETGEAR_WNR618

 But this is only the beginning and we want to get unauthenticated root access to the router.

 In the following post I explain a vulnerability that affects just these two models (JWNR2010v5 and JWNR2000v5) that allows us to fully compromise the router and also you can find a PoC to test with your own router.

[Parte 2] Hacking NETGEAR JWNR2010v5 Router - Command Injection

Ya hemos visto como podemos acceder al router bypasseando la autenticación por completo por lo que en esta entrada quiero centrarme en el compromiso del sistema subyacente. Para esto tenemos que entender como funciona el router internamente y la gestión del interfaz de administración.

Revisando el sistema de archivos que descomprimimos en el anterior post nos encontramos con que casi toda la lógica es gestionada por un unico cgi llamado setup.cgi:


# ls -l | grep cgi
lrwxrwxrwx 1 root root     18 Jul 28 07:51 conf -> restore_config.cgi
lrwxrwxrwx 1 root root      9 Jul 28 07:51 htpwd_recovery.cgi -> setup.cgi
-rwxr-xr-x 1 root root  59784 Apr  1 01:34 restore_config.cgi
-rwxr-xr-x 1 root root 613588 Apr  1 01:34 setup.cgi
-rwxr-xr-x 1 root root 277152 Apr  1 01:34 setupwizard.cgi
lrwxrwxrwx 1 root root      9 Jul 28 07:51 upgrade_flash.cgi -> setup.cgi


Una de las vulnerabilidades mas habituales es la inyección de comandos a traves de funciones mal controladas, por lo que mi prioridad es encontrar en que punto se ejecuta un comando contra el sistema donde nosotros tengamos control sobre el input. Para ello una vez abierto el cgi en IDA hago una búsqueda sobre palabras clave que pueden reportar el resultado deseado, por ejemplo el string '/bin' entre otros:


Como se puede ver en la imagen uno de los resultados mas interesantes es el comando ping que muchos routers utilizan en la página de diagnóstico para validar la conexión a internet y que en el caso concreto de este NETGEAR se encuentra en la página diag.htm, por lo que buscaremos como se realiza la llamada:



En la propia web nos encontramos el primero de los fallos. La integridad de los datos enviados por el usuario se realiza del lado del cliente por lo que simplemente sustituyendo return ping_ck() por return true o interceptando la petición POST podremos modificar los datos a nuestro antojo.


Como ya he dicho en mas de una ocasion uno de los aspectos en los que mas me gusta gastar mi tiempo es en la investigación de sistemas embebidos. Así que como ya hace mas de un año que no actualizo el blog, hoy os traigo el analisis de dos vulnerabilidades que afectan a un gran numero de dispositivos NETGEAR. La explotación de estas dos vulnerabilidades en conjunto llevan al compromiso total del router de manera remota si tienen el acceso WAN activado.

En este caso el firmware a analizar es la versión 1.1.0.31 del modelo JWNR2010v5 publicado el 11/05/2015 y disponible para su descarga en el siguiente enlace http://www.downloads.netgear.com/files/GDC/JNR1010V2/N150_N300_FW_V1.1.0.31_1.0.1.zip

A partir de la lectura de binwalk sabemos que el router tiene una arquitectura MIPS y que el sistema de archivos se encuentra en el offset 0x160000 por lo que lo extraemos usando dd:



DECIMAL         HEX             DESCRIPTION
-------------------------------------------------------------------------------------------------------------------
60352           0xEBC0          U-Boot boot loader reference
[...]
131072          0x20000         uImage header, header size: 64 bytes, header CRC: 0x23F4018D, created: Thu Nov 21 21:18:53 2013, image size: 1266253 bytes, Data Address: 0x80000000, Entry Point: 0x8000C2F0, data CRC: 0xE8A06868, OS: Linux, CPU: MIPS, image type: OS Kernel Image, compression type: lzma, image name: "Linux Kernel Image"
131136          0x20040         LZMA compressed data, properties: 0x5D, dictionary size: 33554432 bytes, uncompressed size: 4632092 bytes
1441792         0x160000        Squashfs filesystem, little endian, version 4.0, compression:lzma (non-standard type definition), size: 2376782 bytes,  1160 inodes, blocksize: 131072 bytes, created: Thu Nov 21 21:18:35 2013
[...]
4028341         0x3D77B5        End of Zip archive


# dd if=N300.bin bs=1 of=N300.squashfs skip=1441792
2752512+0 records in
2752512+0 records out
2752512 bytes (2.8 MB) copied, 2.73591 s, 1.0 MB/s

# file N300.squashfs
N300.squashfs: Squashfs filesystem, little endian, version 4.0, 2376782 bytes, 1160 inodes, blocksize: 131072 bytes, created: Thu Nov 21 21:18:35 2013

# ./unsquashfs_all.sh N300.squashfs
[...]
created 850 files
created 60 directories
created 144 symlinks
created 106 devices
created 0 fifos
File system sucessfully extracted!


Hacking indirecto (o como lo quieras llamar)

En este post quiero tratar un tema que normalmente no se controla en las empresas y puede suponer un riesgo grave. Es muy común que la política de contraseñas de una empresa sea como la de BYOD, traete tu contraseña de casa que así te la memorizas y no nos das el coñazo. Pero esto supone un problema y es que según las estadísticas el 75% de las personas utilizan la misma contraseña para todos los servicios.

Supongamos un caso de una empresa con un portal web a través del cual todos los empleados acceden a la intranet y su webmail, un atacante intenta acceder a esta intranet pero no logra ningún acceso directo, dicho atacante antes de plantearse la ingeniería social utiliza la FOCA para extraer nombres de empleados a través de los metadatos de los documentos alojados en el portal web. Una vez con estos nombres extraidos y tras un poco de trabajo de recopilación de información el atacante rastrea un poco el Twitter, Facebook y la información indexada en los buscadores asociada a cada persona pudiendo conocer los hábitos y servicios que ésta utiliza. En este punto el atacante puede buscar una vulnerabilidad en una página usada por uno o varios empleados y hacerse con los credenciales de estos empleados aprovechandose de un incorrecto o nulo cifrado de la página secundaria.

En relación a la anterior otra manera de proceder sería utilizar un dork para rastrear los emails que hay indexados en los buscadores relacionados a un dominio. Por ejemplo podríamos usar intext:"@dominio.com" y nos encontraríamos con una serie de personas que han utilizado su cuenta de correo empresarial para registrarse en diversos servicios en los cuales no está garantizada la seguridad.

Como veis hay varias posibilidades de conseguir unos credenciales básicos para acceder a vuestro objetivo primario sin necesidad de utilizar métodos ruidosos contra él y levantar alarmas antes de tiempo. Los responsables de seguridad de una empresa siempre deben dejar claro que el empleado debe separar sus contraseñas personales de las laborales y nunca registrarse en servicios externos con correos y/o contraseñas  empresariales. Esto no siempre se lleva a cabo y las consecuencias pueden ser muy graves como para no valorarlo.




Comprometen el sistema de navegación de un avión mediante Android


Hugo Teso, piloto comercial e investigador de seguridad en la compañía de seguridad alemana N.Runs ha presentado un método a través del cual logra el control total sobre el sistema de navegación de un avión logrando manipular la ruta de éste.

Teso dijo que fue capaz de interceptar las comunicaciones con el enlace de 1Mbps descartando la información real e inyectando información falsa utilizando hardware de control de navegación y software específico que se puede encontrar públicamente el cual fue usado de puente.
"Esperaba que tuviesen agujeros de seguridad pero no me esperaba que fuesen tan fáciles de  detectar. Pensaba que tendría que luchar duro para entrar pero no fue tan difícil", Dijo Teso
Su aplicación no era mas que una prueba de concepto y comentó que las agencias europeas y americanas ya están trabajando en arreglar el problema. Dada la gravedad del problema esperemos ver una solución en el plazo mas breve posible.

Paper: Aircraft Hacking: Practical Aero Series

Nuevo 0-Day descubierto en Adobe Reader 11.0.1



El equipo de FireEye ha reportado una nueva vulnerabilidad en Adobe Reader que está siendo explotada por atacantes para instalar malware saltandose el sandbox de la aplicación. La vulnerabilidad afecta a las versiones 9.5.3, 10.1.5 y 11.0.1 aunque probablemente sea extensible a otras.

Por el momento no han transcendido detalles de la vulnerabilidad dado que Adobe está trabajando en un parche, pero una vez publicado éste se publicarán los detalles técnicos según comentan los investigadores en su blog.

Como recomendación para el usuario es recomendable no utilizar Adobe Reader hasta que salga a la luz una solución y tener mucho cuidado con los PDF de personas desconocidas.

Vulnerabilidad en el manejo de cookies de Outlook y Hotmail permiten el secuestro de sesiones


Hoy TheHackerNews ha hecho pública una vulnerabilidad existente en el manejo de cookies que hacen Outlook y Hotmail además han puesto a disposición del que quiera una cuenta de Outlook con la que testear la vulnerabilidad.

El problema reside en que cuando un usuario hace logout en cualquiera de los dos servicios la cookie almacenada en el buscador no caduca, por lo que un atacante podría robar esa cookie de un ordenador que la víctima haya usado y reutilizarla posteriormente para tener acceso a dicha cuenta. Si bien es una vulnerabilidad limitada ya que requiere de acceso local al ordenador de la víctima, la gestión incorrecta de las cookies es algo que Microsoft debería de tener controlado.

En THN afirman que el problema fue reportado a Microsoft pero éstos cerraron el caso y no corrigieron el problema alegando que un atacante debería saber la contraseña para apoderarse de la cuenta totalmente.

Aquí tenéis un vídeo de la POC:




Fuente: The Hacker News

Recopilación de VM's y WebApps vulnerables para entrenamiento

Una de las mejores formas de aprender es recrear escenarios reales y llevar a cabo intrusiones sobre ellos, en esta tarea un buen recurso son las imágenes preconfiguradas que hay a nuestra disposición en la red, para todos aquellos que están dispuestos a ponerse manos a la obra va dedicada esta entrada.

Todo lo que necesitas es un programa de virtualización - VBox o VMWare por ejemplo -, un servidor web, paciencia y muchas ganas.


Vamos con la lista:


Metasploitable

Ya hablamos de él en una entrada anterior, Metasploitable es una imagen creada por el equipo de Metasploit sobre Ubuntu donde se han preconfigurado una serie de servicios como Tomcat, Tikiwiki o MySQL para llevar a cabo tests de intrusión.


Metasploitable 2

Se trata de una evolución de la imagen anterior con mas vulnerabilidades añadidas.


Lamp Security

Lampsecurity consta de una serie de imágenes dedicadas al entrenamiento en seguridad de linux, php, mysql y apache. Además en la web tenéis a mano documentación para no perderse por el camino.


Moth

Moth es una imagen dedicada al aprendizaje de seguridad de aplicaciones web. Integra PHP-IDS y mod-security para ayudar al alumno a entender como funcionan los firewall de aplicaciones webs.


Damn Vulnerable Linux

DVL integra todo lo que un sistema inseguro debe tener, configuraciones pobres, servicios desactualizados y software explotable para deleite del estudiante.


PwnOS

Como su propio nombre indica es una distribución preparada para la intrusión, la finalidad es conseguir acceso root a traves de uno de los multiples puntos de entrada disponible.


DVWA

Damn Vulnerable Web App es una aplicación web que podeis desplegar en un servidor web local, tiene diversos niveles de dificultad y podréis entrenar vuestras habilidades con numerosos ataques web como LFI, RFI, XSS, XSRF o SQLi.


Gruyere

Es una aplicación de Google que te da la posibilidad no solo de aprender diferentes ataques web sino tambien de como defenderte de ellos. 


webgoat

webgoat es una aplicación construida en J2EE y provista por OWASP que te guiará a traves de diferentes retos simulando escenarios reales mientras aprendes los diferentes tipos de ataques existentes en la web.


Aquí lo dejamos por hoy, existen muchos mas entornos de entrenamiento pero las dejaremos para una futura entrada. Si creéis que nos hemos dejado alguna imprescindible no dudéis en dejarlo en los comentarios.

THN desvela XSS en Google

La historia de hoy viene de la mano de Mohit Kumar, fundador de The Hacker News. Según cuentan en la entrada en su página, Kumar reportó el 11 de Septiembre al programa de recompensas de Google una vulnerabilidad de Cross Site Scripting en el dominio googleusercontent.com a lo que el equipo de Google respondió que se trataba de un sandbox y no existían datos del usuario en él por lo que descartaron el aviso.

Un tiempo mas tarde, otro hacker búlgaro llamado Keeper contactó a Kumar para comentarle que la vulnerabilidad seguía activa y que tras avisar repetidas veces a Google no lo habían resuelto, por lo que Kumar optó por publicar su PoC de la vulnerabilidad para presionar a Google a corregirlo.

A coninuación podeis ver la POC:
  1. Página de phishing en Google aqui.
  2. El usuario llega a una página alojada en un dominio google.com/...
  3. Usando el XSS crea un popup para engañar a la víctima
  4. El formulario de login es creado con los servicios de Google apuntando a un servidor malicioso.
  5. Una vez el usuario introduce sus credenciales son enviados al atacante/aquí

Twitter ha comenzado a enviar masivamente emails a sus usuarios con la petición de un cambio de contraseña debido a que un numero indeterminado de cuentas han sido comprometidas. Por el momento se desconoce la causa por la que se han filtrado las contraseñas.

TechCrunch informa que ha contactado con Twitter para conocer la gravedad del problema pero no ha recibido respuesta, simplemente Twitter se ha limitado a afirmar que el email es real y que todo usuario que lo haya recibido debe seguir el enlace adjunto.

Puede que vuestro email haya filtrado el email y lo enviase a spam por lo que es recomendable que lo reviséis. Por otra parte que Twitter envíe un correo con un enlace adjunto para resetear la contraseña me parece una irresponsabilidad por lo que si es tu caso te recomiendo que escribas manualmente el link en la barra de direcciones para asegurarte que realmente te diriges a la página de reset de password y no hacia un rápido ataque de phishing.

A continuación dejo el contenido del email:

Hi, [name]
Twitter believes that your account may have been compromised by a website or service not associated with Twitter. We’ve reset your password to prevent others from accessing your account.
You’ll need to create a new password for your Twitter account. You can select a new password at this link:
https://twitter.com/pw_rst/…
As always, you can also request a new password from our password-resend page: https://twitter.com/account/resend_password
Please don’t reuse your old password and be sure to choose a strong password (such as one with a combination of letters, numbers, and symbols).
In general, be sure to:
Always check that your browser’s address bar is on a https://twitter.com website before entering your password. Phishing sites often look just like Twitter, so check the URL before entering your login information!
Avoid using websites or services that promise to get you lots of followers. These sites have been known to send spam updates and damage user accounts.
Review your approved connections on your Applications page at https://twitter.com/settings/applications. If you see any applications that you don’t recognize, click the Revoke Access button.
For more information, visit our help page for hacked or compromised accounts.
The Twitter Team

UPDATE:
Twitter asegura que el reset de cuentas ha sido un error por su parte y que su seguridad no ha sido comprometida. Podéis leer el post aquí.



Descubierta vulnerabilidad 0day en Adobe Reader X y XI


Blackhole es el Exploit-Kit del momento, hoy tenemos que hablar de él debido a que Group-IB un grupo de investigación ruso ha descubierto una vulnerabilidad incluida en una version modificada del kit de explotación que afecta a Adobe Reader X y XI y que está siendo utilizada para infectar con los troyanos bancarios Zeus, Spyeye, Carberp, Citadel.

Este exploit que está a la venta por 50.000$ logra bypasear el sandbox implementado en Adobe Reader y ejecutar código en la máquina víctima, por lo que se conoce la falla solo es explotable en sistemas Windows y hasta que el usuario cierra su navegador (o lector de pdf) el exploit no es ejecutado en su totalidad.

Por el momento Adobe afirma que no tiene conocimiento de este fallo y de confirmarse y parchearse se rompería la racha de dos años sin ataques reales sobre las versiones con sandbox del lector.

Múltiples vulnerabilidades descubiertas en Sophos

Vulnerabilidades Sophos
Tavis Ormandy ha publicado un paper con los resultados de su análisis de antivirus Sophos titulado "Practical Attacks against Sophos Antivirus". En él se analizan varios casos de ataques prácticos contra el antivirus que pueden comprometer la integridad del sistema que lo alberga. Tavis afirma que Sophos le ha comunicado que publicarán un aviso para sus usuarios en un plazo corto de tiempo, pero no le han permitido revisar el contenido, por lo que recomienda la lectura de su investigación si eres un usuario afectado.

Las vulnerabilidades encontradas son las siguientes:

  1. Ejecución de codigo al analizar un binario malintencionado en formato PDF, RAR, VB o CAB.

  2. Bypass del ASLR de Windows a traves de una falla en el sistema de protección de Buffer Overlflows.

  3. Ejecución de código a traves de una falla en el módulo LSP debido a la la carga de éste desde un directorio de integridad baja y con permisos de escritura.

  4. XSS en la pagina de protección contra contenido malicioso.

  5. Escalada de privilegios debido a un problema en la gestión de éstos por parte de Sophos.

Si administras un sistema con Sophos desplegado se recomienda la lectura del estudio para comprender los riesgos y seguir los checklists de mitigación incluidos en él.

Como lectura añadida os recomiendo leer la conclusión que Tavis dejó escrita en exploit-db.com : Conclusión Tavis Ormandy

Mas información:

A Critical Analysis of Sophos Antivirus
Applied attacks against Sophos Antivirus

Tutorial básico Cross Site Scripting

Tutorial Cross Site Scripting
Hoy nos toca tratar una de las vulnerabilidades mas habituales en el desarrollo web actualmente, el XSS. Esta falla de seguridad se debe a un incorrecto filtrado de los valores que un usuario puede introducir en una web dando así pie a la ejecución de código de scripting en la web atacada.
A través de este método un atacante puede robar los credenciales de un usuario o administrador, modificar contenido en la web, eliminar restricciones impuestas desde el lado del cliente y muchas otras cosas.

Existen dos tipos de XSS:

  • Indirecto o reflejado: Funciona modificando valores que una web pasa entre página. Ocurre cuando se envía un mensaje o ruta en una URL, una cookie o en la cabecera HTTP.
  • Directo o persistente: Consiste en almacenar código en la web para que se ejecute una vez que la web se carga, por ejemplo inyectando en un libro de visitas de una web en un blog o en una sección de comentarios.
Este fallo está muy extendido debido a que muchos dessarrolladores no son conscientes de que los filtros -si los hay- se pueden evadir fácilmente con algunas técnicas.

Vupen anuncia el desarrollo del primer exploit 0Day para Windows8

Tras el lanzamiento de Windows8 por parte de Microsoft, Vupen se han puesto a trabajar para dar lugar al desarrollo del primer 0-Day para el sistema operativo.

Chaouki Bekrar publicaba en su twitter el siguiente mensaje:

"We welcome #Windows8 with various 0Ds combined to pwn all new Win8/IE10 exploit mitigations. Congrats to our mitigation mitigator @n_joly"

Cabe recordar que Windows8 pese a su cambio estético es en esencia un Windows7 fortificado y con algunos sistemas de seguridad añadidos como DEP, ASLR o Anti-ROP. Además según Vupen el exploit es una combinación de una serie de bugs tanto en IE10 -Con el que se saltan el sandbox de éste- como en Windows8.

Para terminar hace escasas horas salía a la luz un módulo para metasploit que se aprovecha de un fallo en el servicio WinRM para conseguir una sesión de Meterpreter.

La lluvia ha empezado y el balón está del tejado de Microsoft.

Fuentes:

Bypass del filtro XSS de Internet Explorer 9

Recientemente se ha descubierto la forma de bypasear el filtro de Internet Explorer 9 que limita la acción de un Cross Site Scripting en el navegador de Microsoft.
Como sabéis IE9 te avisa de que ha modificado la página -si se tiene activada la funcionalidad- cuando detecta cierto patrón en un parámetro recibido en la url, por ejemplo, si tenemos el siguiente código vulnerable del lado del servidor:

<?php
echo $_GET['id'];
?>


Y recibimos la siguiente URL:

www.ejemplo.com/test.php?id=<script>alert("XSS");</script>

El navegador desplegará el siguiente mensaje:

Bypass filtro Internet Explorer
Mensaje mostrado por IE9

Sin embargo IE nos permite romper etiquetas insertando nullbytes entre los carácteres del siguiente modo <script>, aunque nos será imposible insertarlo directamente en la url, por lo que para solucionarlo deberemos convertir esta cadena a hexadecimal e insertarlo en un enlace, veamos unos ejemplos:

[NULL] =

No funciona: www.ejemplo.com/test.php?id=<s[NULL]cript>alert("XSS");</s[NULL]cript>

No funciona: <a href="www.ejemplo.com/test.php?id=<s[NULL]cript>alert("XSS");</s[NULL]cript>"</a>

Funciona: <a href="www.ejemplo.com/test.php?id=\x3C\x73\x00\x25\x30\x63\x72\x69\x70\x74\x3E\x61\x6C\x65\x72\x74\x28\x22\x58
\x53\x53\x22\x29\x3B\x3C\x2F\x73\x00\x25\x30\x63\x72\x69\x70\x74\x3E"</a>


Si bien esto es una vulnerabilidad menor, los usuarios acostumbrados a que el navegador pare un ataque de este tipo pueden quedar expuestos ya que por el momento no existe forma de mitigar este fallo.



FUENTE: Security Focus

ReVuln desvela vulnerabilidades críticas en Steam

Vulnerabilidades en Steam
El equipo ReVuln ha publicado recientemente una investigación sobre posibles vectores de ataque a la red de distribución de videojuegos de Valve que podría ser aprovechada por un atacante para hacerse con el control de la máquina de un usuario.

Como explican en el paper que han publicado, Steam utiliza urls propias para interactuar desde la web con su aplicación, por lo que han analizado el comportamiento del navegador embebido de Steam y comprobado que a través de la sección de vídeos incluida en el perfil del usuario un atacante puede redireccionar a la víctima a un host externo para ejecutar comandos de Steam a través del protocolo de navegacion de Steam (steam://) .

Una vez logrado ejecutar código dentro de steam, un atacante tendría varias vías de ataque ejecutando comandos de steam o explotando el sistema de comandos de diferentes motores gráficos.

Podéis ver una demo en el siguiente vídeo:



A los que os estáis preguntando como podemos protegernos de este tipo de ataque, es bastante sencillo.

Según ReVuln el problema puede ser resuelto desactivando el gestor de URLs de steam o utilizando un navegador que no permita la ejecución directa del protocolo de navegación de Steam como Google Chrome.


ShellShock Labs es un blog dedicado a seguridad y hacking en general, un lugar donde buscamos que la gente participe con sus opiniones.

Síguenos




Posts Populares