sábado, 22 de marzo de 2008

Bug2 and exploit2 for destar

Destar es una interfaz web (programada en python) para manejar Asterisk.
La parte interesante es que unos colombianos son los que han estado liderando el proyecto en los ultimos años. (Buena por esa!!!).

Este otro bug lo encontre despues de encontrar el primero, antes de que se acabaran los caballeros del zodiaco y cuando ya tenia mucho sueño.

Este bug es un poco mas peligroso que el anterior, pues no se requiere tener usuario valido dentro de destar para ingresar como "administrador".

Se encuentra en el archivo Publisher.py, el cual maneja la conexión entrante.
exactamente en las líneas:

65
66 # Determine IP of originator, keep Squid in mind :-)
67 try:
68 ip = request.environ['HTTP_X_FORWARDED_FOR']
69 except:
70 ip = request.environ['REMOTE_ADDR']
71

Cual es el problema?, el problema puede ser no manejar sesiones, sabiendo que el quixote las soporta. segun el autor (que no los colombianos):

22 DeStarPublisher also has it's own session management. For simplicity, I put
23 the session stuff directly into the Publisher object, so I don't use
24 Quixote's classes 'Session' and 'SessionPublisher'.
25
26 Reasons:
27
28 a) they set a cookie, some browsers don't allow cookies
29
30 b) if you stop and start DeStar (which happens very often during
31 Development) Quixote's session handler would give you ugly error messages
32
33 c) Keeping the session data in the publisher object scales quite ok, because
34 DeStar will usually only be used inside the LAN anyway
35
36 But keep in mind that a session here is not a (user, host, browser_process)
37 tuple, but a (user, host) tuple.
38
39 TODO: the default implementation provided here is not persistent. There is
40 also no cleanup code to remove old sessions.
41
42
43 The Session holds several values:
44
45 request.session.user User name
46 request.session.level User level (0=disabled/not logged in
47 1=normal PBX user
48 2=PBX Administrator
49 3=PBX Configurator
50 4=Programmer
51 request.session.language User language

O sea que la cookie que conocemos normalmente se reemplaza por una dupla (ip,usuario). Esto no es del todo malo, si se toman las precauciones del caso.

Pero ...

El primer llamado lo hace a una variable que se encuentra en los encabezados y se llama: HTTP_X_FORWARDED_FOR

Como todos sabemos desde el colegio, esta variable se añade a las comunicaciones cuando hay proxies de por medio. Que pasaria entonces si le hacemos creer a destar que pasamos por un proxy y por eso llevamos esa variable puesta?

Uhmmm ...

Que el software creeria que nuestra IP es igual a lo que pongamos en la variable y ya tendriamos control. (yo se que tu tambien lo pensaste!)

Si un usuario tiene control de las variables internas, lo tiene todo.

Una vez conseguida la IP, creamos una sesión valida.

95 session.language = 'en'
96 else:
97 for user in users:
98 if user.pc == ip:
99 session.user = user.name
100 session.level = int(user.level)
101 session.phone = user.phone
102 session.language = user.language
103 break
104
105 language.setLanguage(session.language)
106 session.lastaccess = t
107 request.session = session

El for de la linea 97 lo que hace es buscar el primer usuario que tenga la IP que acabamos de ingresar por medio de la variable HTTP_X_FORWARDED_FOR
por lo tanto si queremos hacer un "auto login" solo necesitamos saber la IP de un usuario validado en el sistema y ponerla en la variable. :)

Pero para poner las cosas mejor, cuando se monta el software, destar trae un usuario por omisión que no tiene variable "pc" configurada.

Por lo tanto para el script esta variable tiene un valor ="" (nulo), entonces si hacemos un script que ponga la HTTP_X_FORWARDED_FOR="", estariamos ingresando como usuario administrador (Configurator). !Simple lógica!

Listo eso es todo, una posible solucion es validar las cadenas de entrada y obviamente mejorar el script que captura la IP.

Un ejemplo del uso del exploit:

debian:~# python destar_exploit2.py
Target host: i.e: http://127.0.0.1:8080/
Target host ( include http and /): http://127.0.0.1:8080/
Ok, now go and test your user at: http://127.0.0.1:8080/

Y ya tenemos un usuario valido en ese sistema. Si quieres cambiar los parámetros por defecto configura el exploit, estudialo, portate bien, no hagas daños, estos exploits son pruebas de concepto, solo buscan que aprendas un poco, nada mas.

Nos vemos en la próxima (cuando tenga tiempo) ...

Bug1 and exploit1 for destar

Destar es una interfaz web (programada en python) para manejar Asterisk.
La parte interesante es que unos colombianos son los que han estado liderando el proyecto en los ultimos años. (Buena por esa!!!).

El siguiente bug lo encontre mientras jugaba un poco con la interfaz, espero que lo entiendan, que apliquen el conocimiento, que usen los PoC de forma responsable and so on ...



La explotación del bug permite que un usuario normal (como tu o como yo), con privilegios de usuario: "user", pueda crear una cuenta de administrador para entrar a la plataforma. Como lo logra?

El bug esta en el archivo que parsea la informacion de la sección : PhoneSettings, a donde tiene acceso un usuario normal.



Estos datos pueden ser modificados por el usuario, ya que hacen parte de su perfil. Lo que voy a intentar es meterle a los campos cosas extrañas, voy a probar por ejemplo con el campo "Voicemail pin", que es la clave para escuchar los mensajes de voz que me dejen en la extension.

Cuando introduzco "cosas raras", puedo lograr que se modifique el archivo /etc/asterisk/destar_cfg.py que es el que guarda la informacion de destar y que hace a su vez de base de datos, puesto que el autor manifiesta que usara este modo, porque no quiere complicarse con otras cosas (el autor anterior a los colombianos).

La estructura normal del archivo es:

CfgOptUser(
name = "astridlabella",
secret = "astridlabella",
pc = "64.233.167.99",
phone = "agent1",
pbx = "pbx1",
level = "1",
language = "es",
)

CfgPhoneSip(
pbx = "pbx1",
name = "phone1",
secret = "/GPOyGmK",
ext = "2004",
dtmfmode = "rfc2833",
enablecallgroup = True,
callgroup = "2",
panel = True,
calleridnum = "2004",
calleridname = "Phone 1",
dialout_local = True,
dialout_international = True,
dialout_018X_numbers = True,
)
etc...

Dependiendo de los objetos que busque, hay algo que saca los campos correspondientes y los usa.

Bueno, lo que se hace inyectando codigo, es hacer que una entrada de una extension telefonica como la que vemos arriba, se transforme en:

CfgPhoneSip(
pbx = "pbx1",
name = "agent3",
secret = "LOCO",
ext = "2003",
dtmfmode = "rfc2833",
enablecallgroup = True,
callgroup = "1",
queues = "queue1",
panel = True,
pin = 1234,) ; CfgOptUser(name="theroot",secret="theroot",pc="200.13.247.89",phone="agent1",pbx="pbx1",level="2",language="en",) ;CfgPhoneSip(pbx="pbx1000",name="OpenBSD-Agent",secret="imsecure",ext= "2999",dtmfmode = "rfc2833",enablecallgroup = True,callgroup = "1",queues="queue1",panel= True,,
calleridnum = "2003",
calleridname = "Agent 3",
dialout_local = True,
dialout_international = True,
dialout_018X_numbers = True,
)


Observen el codigo despues de la clave '1234' en el campo "pin".
Ese codigo lo que hace es conservar la estructura del archivo y asu vez, crear una nueva instancia (un nuevo usuario), que tiene level="3" (administrador).
si logramos hacer ese cambio ya podemos loguearnos como usuario theroot, con clave theroot y seremos administradores de destar.

Recuerden que para esto es indispensable acceso como usuario sin privilegios.

La parte vulnerable del código es:
87
88 if form["pin"]:
89 phone.pin = form["pin"]
90 try:
91 if form["secret"]:
92 phone.secret = form["secret"]
93 except KeyError:
94 pass
95 backend.updateConfiglet(phone)
96 try:
97 backend.createPythonConfig()
98 except IOError:

En el archivo: page_user_settings.ptl, linea 89, donde no hay ninguna validacion para el valor del campo "pin" que se toma del formulario.

Un posible parche es verificar cada parametro que se recibe de los formularios antes de insertarlos en los archivos. O sea modificar el metodo updateConfiglet() de la clase ConfigletTree en el archivo configlets.py.

Aunque no se si eso hace parte de Quixote o de destar.
Sin embargo en el codigo de destar tambien se podria hacer algo (preventivo).

Una vez ejecutamos el exploit podemos ingresar a la interfaz y obtener lo siguiente:


El PoC lo pueden encontrar en los archivos de este blog -->

! Happy Hacking !

viernes, 14 de marzo de 2008

Flashing the WRT54G v.8 AP

W R T 54 G v. 8


Hace tiempo que no reflasheaba un AP, porque no habia tenido la necesidad, me he mantenido hace mucho con el firmware tomato porque lo tengo en produccion (my internal network).

El AP que necesitaba flashear esta en la version 8, un AP que ya no tiene antenas desmontables :( y que usa el firmware vxworks.

Los pasos son muy simples si eliges el firmware DD-WRT, que hasta donde lei es el proyecto que tiene mas soporte y que si quiere el harware de bajos recursos ;)

Los pasos basicamente estan descritos en esta pagina:
http://www.dd-wrt.com/phpBB2/viewtopic.php?t=20095

Lo que se hace es decargar los archivos:
  • dd-wrt.v24_micro_wrt54gv8.bin
  • vxworkskillerGv8-v3.bin
Uno es el firmware como tal y el otro es un "killer" para el firmware vxworks, porque lo primero que se hace antes de tener un nuevo firmware es eliminar el antiguo, por eso hay que cargar primero este antes de reflashear.

Una vez estamos dentro de la interfaz del AP que tiene por defecto la IP 192.168.1.1, buscamos el panel de administracion y buscamos el enlace para hacer una actualizacion.


Seleccionamos el killer del vxworks y presionamos el boton de upgrade (aqui es donde da susto ...)

Se empieza a actualizar (toma algun tiempo) ...

Despues de un tiempo me da error y el AP se queda solo con un LED encendido (no se asuste).


Despues de esto lo desconectamos (quitamos el cable de potencia) y lo volvemos a conectar, esperamos un ratico, todavia no funcionan los otros leds, entonces desconectamos nuevamente y preparamos la linea de comandos para reflashear:

[root@nonroot home]# tftp -m binary 192.168.1.1 -c put ./dd-wrt.v24_micro_wrt54gv8.bin

Este comando lo que haces es definir el modo de transferencia a binario, y decirle al cliente tftp que ejecute la accion de subir datos (put), el archivo a subir es obviamente el firmware DD-WRT version 8.

Cuando hagamos esto, esperamos un momento y volvemos a apagar el AP, nuevamente lo encendemos y verificamos que el led de WLAN encienda.

Por ultimo podemos hacer ping a la IP del AP, que seguira siendo 192.168.1.1, si funciona, entonces todo estara bien, si no funciona, tendras que ir a los foros de DD-WRT e intentar lo que te digan para recuperar el AP.

Verificamos que todo vaya bien, accediendo con un navegador a la IP del AP, donde tendremos que encontrar la interfaz web de configuracion del DD-WRT.


FIN

Entradas populares