Accediendo a los servidores de desarrollo de LAN

Muchas empresas acostumbran a exponer en internet sus servidores de desarrollo y QA, en este caso, LAN ha dejado con libre acceso el servidor de desarrollo.

El servidor tiene una URL y dirección IP distinta y se conecta a una base de datos distinta,y me imagino que los controles de seguridad no son los mismos. Siendo un servidor de desarrollo deberian existir opciones de “debug”, filtros y protecciones desactivados que podrian ser aprovechadas por un atacante.

En el codigo fuente de un javascript, encontré una sentencia que discriminaba si el sitio era “lan.com” o “dev.lan.com”, sumiendo que el segundo corresponde a un servidor de development/desarrollo.

El host dev.lan.com no resuelve a ninguna IP, pero con la ayuda de Google podemos encontrar el host correcto.

Finalmente, llegamos al host que buscabamos: www.adougher.dev.lan.com.

Este host resuelve a la IP 50.97.81.12, distinto al de producción www.lan.com 190.13.74.215. Tambien tenemos ssl.adougher.dev.lan.com versus ssl.lan.com, los cuales resuelven a 50.97.81.12 y 67.15.147.203 respectivamente. Tambien tienen versiones distintas, el primero usa Apache/2.2.3 y el segundo Apache/1.3.33.

Para comprobar que los sistemas se conectan a bases de datos distinta solo deben registrarse en uno y probar esos datos de registro en el otro servidor, verán que no comparten bases de datos; los datos registrados en uno no son accesibles desde el otro.

Al comunicarme con gente de LAN.com me indicaron que es un comportamiento esperado, es decir, para ellos está bien que se pueda acceder al servidor de desarrollo. Yo me pregunto ¿Conoceran las VPN?
ACTUALIZACION (6/Oct)

Finalmente restringieron el acceso mediante autenticación http básica

11 comentarios

  1. y el lfi bien conocido por muchos donde se ve el hash de root cuando hacen sudo: https://ssl.lan.com/cgi-bin/site_login.cgi?extra=../../../../../../../../../../../etc/passwd

  2. Lan tiene mayores problemas que esos…

    drwxrwxr-x 4 602 602 4096 LAN_CPAN_20100312

    drwxr-xr-x 3 605 605 4096 amaxus

    drwxr-xr-x 13 602 602 4096 backpan

    drwxr-xr-x 4 0 0 4096 centos

    drwxr-xr-x 2 0 0 4096 centos-5.4

    drwxr-xr-x 3 605 605 4096 dell

    -rw-r–r– 1 0 0 4 host

    drwxr-xr-x 3 0 0 4096 ks

    drwxr-xr-x 9 0 0 4096 lan

    drwxr-xr-x 2 0 0 4096 pub

    lrwxrwxrwx 1 0 0 14 src -> /usr/local/src

    drwxr-xr-x 3 0 0 4096 xenserver

  3. Interesantes aportes.

    Comunicandome con personas de LAN, me dicen que esa falla que expone “exploit-shell” se debe a un servidor obsoleto con un vsftpd obsoleto.

    Respecto a lo que dice xzite, dicen que el LFI lo tenian parcheado pero se les traspapelo en algun upgrade a produccion y uno de los servidores quedo vulnerable, pero ya lo tienen bajo control.

    Respecto al XSS, hay otros mas aprte de ese, deberian estar trabajando en ellos

  4. Zerial,

    me imagino que como “se les traspapelo” en algun upgrade no tienen un repositorio de versiones. que curioso 😉

  5. primero, me parece buen termino y concepto “se les traspapelo” osea si tnego un bug no es por mala seguridad es por que….

    segundo, Apache/1.3.33 ??? es mas añejo q me abuelita, para qu decir lo que se podria hacer cion un server d esas caracteristicas

    tercero… “indicaron que es un comportamiento esperado”

    Nada mas q decir
    saludos , buen articulo Zerial

  6. creo que no es tan peligroso eso que encontraste en lan, es mas peligroso lo que encontro el xzite o me equivoco…

  7. Si hablamos de “peligrosidad”, si

  8. El sitio de lanpass.cycmarketing.cl esta lleno de XSS persistentes

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Esto sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.