Hace algún tiempo hablamos de SHODAN. Desde entonces ha crecido bastante, incluso la FOCA de Chema se ha integrado en él.

El caso es que es una fuente inagotable de diversión y aprendizaje, debido a la posibilidad de comprobar la existencia de ordenadores corriendo software/hardware muy específico. Aunque a veces te encuentras con cosas que sería mejor que no estuvieran ahí.

Hablemos del ciclotrón!

No puedo ser muy prolífico en detalles por razones obvias. En cualquier caso, andaba yo buscando ordenadores con un determinado software muy específico usado en sistemas de control industrial, SCADA, M2M… cuando me encontré con uno perteneciente a los Lawrence Berkely National Laboratories, dependientes del Departamento de Energía de EEUU.

Una mala configuración de este software había hecho que se pudiera acceder a todas las unidades del ordenador expuesto, es decir tenía acceso a todo el disco duro. La máquina es un Windows, por lo tanto os imagináis toda la información que se puede sacar.

Entre la información accesible se encuentra Software de entornos industriales y destinados a procesos SCADA y M2M. Analizando ciertos ficheros se llega a la conclusión que este software está funcionando en el ordenador, por lo que se puede inferir que esta máquina al estar expuesta es un nexo de unión entre internet y la LAN industrial.

Tras analizar ciertos ficheros de log, hacer algunas pruebas etc me “permito” inferir que es una de las máquinas que forma parte del sistema de telemetría del ciclotrón de 88 pulgadas que tienen en dichos laboratorios.

Tocaba consultar con mi hermana Raquel, que es una señorita Doctora en Física de Partículas ( se me nota cómo presumo de hermana ¿no? jeje ) , a ver las posibles implicaciones que podría tener el poseer cierto control sobre las medidas de alarma, control etc en un “aparato” como estos. Me aclaró bastantes cosas de su funcionamiento, si bien no vas a provocar un chernobil, ciertamente es peligroso mientras está en funcionamiento. De hecho, tiene un protocolo de seguridad en el marco de las instalaciones nucleares.

Así que dicho y hecho, he contactado con el US-CERT para avisarles de que, bajo mi punto de vista, eso no debería estar “abierto” al público. De hecho analizando logs, esa máquina ha sido escaneada en repetidas ocasiones por software de “seguridad” automático. Pero como una IP más, no percatándose de las características del mismo.

A día de hoy, la máquina sigue estando abierta. Entiendo que en esta semana se solucionará.

Os dejo algunas capturas del sistema de telemetría del Cyclotron 88-inch de los LBNL

Ya me veo en guantánamo con “the Snake” en vez de “el Polilla” xD

Mola. Te das cuenta como entidades financieras como Cetelem usan IIS 4.0 ¬¬ y cosas peores.
Por lo que he podido investigar, está bastante bien para buscar sistemas SCADA y sistemas embebidos que puedan ser interesantes. Vamos a ver algunos ejemplos:

En muchos de los sistemas SCADA expuestos también es posible acceder al ModBus via TCP con todo lo que ello supone.Incluso aunque el propio software de gestión/monitorizacion web no nos permita hacer demasiado.Sí que nos da una pista de por donde pueden ir los tiros.

Fuji Electric Embedded Web Server:
http://shodan.surtri.com/?q=fuji+electric

Ouman embedded Web Server for SCADA. Basado en una versión vulnerable de Boa Server.
http://shodan.surtri.com/?q=webscada

eWon
http://shodan.surtri.com/?q=ewon

Boa Web Server
Muchas cosillas chulas. Incluidas cámaras de vigilancia
http://shodan.surtri.com/?q=boa

EIG Embedded Web Server
A rio revuelto, ganancia de amperios.
http://shodan.surtri.com/?q=EIG

EnergyICT
http://shodan.surtri.com/?q=energyICT

Ojito con este tipo de sistemas. No rompas nada ni juegues demasiado si no sabes lo que estás haciendo.Yo no me hago responsable de que la mangues.

Hola amigos de lo ajeno. Ya se acabarón las vacaciones, Salvo para algunos suertudos que se las habrán pillado ahora. Aunque bien merecidas eh, que para eso han estado currando todo agosto como unos campeones.

Pues eso, para que quede constancia en el internel, ya que no he visto nada con respecto al tema ( de inseguridades ), hoy comentaremos un poco cómo chutan los puestos de consulta de las bibliotecas públicas (amén de privadas y/o las de ciertas universidades) del Estado y cómo se pueden “petar”. No de todas pero sí de un número a tener en cuenta.
Antes de seguir con el tema es muy recomendable que eches un ojo a las siguientes páginas para que te quedes con la copla:

http://es.wikipedia.org/wiki/Cat%C3%A1logo_en_l%C3%ADnea
http://www.baratz.es/
http://www.absysnet.com/
http://www.eliza.es/

En la última pásate por la sección de manuales. Ahora asumiendo que has leido las cosas, obviaré la explicación de ciertos conceptos.
Pues bien la cosa es sencilla, en muchos de los puestos “tontos” de consulta de las bibliotecas lo que se usa es el OPAC de absysnet para el catalogo de la libreria que corresponda, accediendose a él desde un “navegador neutro”, en este caso el Eliza, que sólo nos permite en teoría navegar por el interior del catálogo.Es decir, por la interfaz web de absysnet OPAC.

El “problema” de esta aproximación, entrecomillo problema porque realmente es una cuestión documentada dentro de los manuales de Eliza, es qué pasa si de alguna manera podemos tener acceso a enlaces externos de internet.

El navegador neutro carece de la barra de direcciones o cualquier otro elemento que nos permita introducir dónde queremos navegar. A su vez, al instalar el Eliza GMRC, todo “Windows” pasa a ser un terminal tonto que sólo permite usar el navegador Eliza para consultar el catálogo configurado. Sin embargo está preparado para integrarse con el sistema OPAC de absysnet.Es decir, sólo podremos acceder a enlaces externos si de alguna manera conseguimos generarlos usando la interfaz de Absysnet OPAC.

Ahora vamos a echar un ojo a la interfaz desde nuestro propio navegador.Por ejemplo, el catálogo de la biblioteca de la Comunidad de Madrid

http://www.madrid.org/biblio_catalogos/BaratzCL/
Introducimos en el buscador “patatas fritas” y le damos a buscar. Pinchamos en algún resultado de los que nos salen y nos fijamos en la esquina inferior derecha, donde pone

“Enlaces en la red:
- Generador de enlaces absysNETc+I/link

Pinchamos ahí y bingo! tenemos salida directa a Google. con lo que ello significa. Poder acceder a cualquier dirección que queramos. A partir de ahi ya es echarle imaginación al tema. Hay que destacar que Eliza GMRC implementa sus propios métodos de control para evitar descargar o ejecutar programas. Pero bueno, vosotros que sois hackers digitales de esos seguro que encontráis algo para saltároslo…;)

En definitiva, es un método para poder hacer el cabra desde un ordenador “anónimo”. Me ha dicho un amigo del primo de mi cuñao que lo ha probado y que una vez dentro de la red interna se encontró routers de los de 1234/1234 y cosas de esas chulis…Todo depende de cómo se tomen la seguridad en la biblioteca de vuestra zona. En cualquier caso, la posibilidad de petar este tipo de puestos Eliza+Absysnet OPAC está ahí y es factible en varias comunidades autónomas. No voy a entrar a opinar en la calidad del software de Eliza ( desarrollado por JMJ ) si alguno lo quiere destripar y comprobarlo él mismo que se pase por www.jmj.es/descargas :/

Para terminar un video del primo del concuñao de una tia segunda mía que tiene tuenti y que me encontré en benidorm. Me dijo que también lo ha probado y se sacó una shell.

feliz caza!

El caso es que la mayoría de hoteles, cafeterías, aeropuertos y estaciones de tren nos ofrecen la posibilidad de conectarnos a Internet a través de sus redes “públicas”, pero con un coste muy elevado por lo que, si no puedes pagarte una tarifa plana de 3G ni pagar 25 por día de conexión en una red pública, vamos a explicar como conseguirla, “de gratis” en nuestra nueva sección de Tecnología for dummies.

Nuestro ejemplo aleatorio, va a ser la T4, desde donde estoy escribiendo estas líneas, aunque tambien se incluyen referencias a otros entornos. Nada más encender mi portátil observo múltiples puntos de acceso abiertos a las que me puedo conectar. El funcionamiento es el siguiente, una vez conectado a dicha red, el servidor DHCP remoto me asigna una dirección IP. Hasta aquí todo bien.

El problema está en que mi equipo portátil se encuentra en un segmento “aislado”, es decir, el servidor dns redirige cualquier petición que yo realice contra un “portal cautivo”, es decir, un frontal Web que requiere autenticación.

La idea es que, cuando nos autentiquemos, automáticamente se generará una nueva regla en el firewall que permita tráfico saliente desde mi equipo hacia Internet, mientras tanto, el tráfico estará bloqueado y solo podremos tener acceso por HTTP o HTTPS a las páginas Web definidas por el proveedor de acceso, habitualmente un portal de compra online para pagar con tarjeta y la Web de la compañía.

Llegados a este punto tenemos varias posibilidades:

1) Tunelizar el tráfico: Montar un tunel DNS que nos permita enrutar tráfico a través del protocolo DNS. Para ello necesitamos un sistema externo conectado a internet y un dominio del que seamos propietarios. Esto es habitualmente muy lento y no todo el mundo dispone de la infraestructura necesaria. http://dnstunnel.de/

2) Hack Sk1llz: Atacar el portal Web del proveedor de acceso o alguna de las páginas accesibles desde el portal captivo, encontrando alguna vulnerabilidad, por ejemplo un php include path, que nos permita acceder a páginas externas o alguna vulnerabilidad de inyección sql que nos permita volcar usuarios y contraseñas de la base de datos. Siendo realistas, esto no lo vamos a encontrar nunca .

3) Atacar algún sistema de la red o alguna estación de trabajo: conectada a la red, que tenga la pasta suficiente como para pagar y que pueda estar autenticado. Podemos para ello usar alguna herramienta “for dummies” estilo metasploit, e instalar un proxy http en su maquina. El problema es que no sabemos cuanto tiempo estará conectado dicho cliente.

4) Cambio de direccionamiento: Una opción que funciona muy bien en algunos entornos, es simplemente realizar un cambio de IP. Si el servidor nos asigna una 10.x.x.x/24 vamos a probar a meternos a mano una dirección ip 192.168.x.x/16 con gw por defecto 192.168.0.1 a ver que vemos. No sería la primera vez que nos encontremos de este modo salida directa a Internet y acceso a la red de servidores de la empresa que ofrece la conectividad.

5) Suplantación de identidad: Si todo consiste en tener una dirección MAC valida para poder tener salida a Internet… vamos a intentar localizar una válida. Para ello solo es necesario lo siguiente:
- Ordenador portátil con tarjeta Wireless
- Librerías Winpcap: Disponibles en winpcap.org
- Tu sniffer favorito: Por ejemplo Wireshark
- Herramienta para cambiar la MAC. Por ejemplo etherchange

Lo primero que debemos hacer es ejecutar el sniffer y realizar una captura de por ejemplo 1 minuto. Paramos la captura con el sniffer, y hacemos un pequeño filtro del tráfico, en el wireshark establecemos “TCP” para buscar solo conexiones establecidas, y le damos a ordenar por dirección de origen.

Dentro de las conexiones establecidas nos vamos a encontrar dos cosas:

a) conexiones http y https contra el portal cautivo (las dos direcciones ip de origen y destino serán de la red en la que estamos conectados)
b) conexiones establecidas a través de cualquier protocolo con direcciones IP de Internet o de redes externas

Seleccionamos una de las conexiones establecidas hacia el exterior y apuntamos la dirección MAC. una vez apuntada, haremos uso de la herramienta etherchange.

Trás realizar el cambio, debemos ir ala sección “conexiones de red”, deshabilitar la tarjeta y volver a habilitarla. En ese momento el interfaz de red se refrescará con la dirección MAC que hayamos establecido.

En este momento, nos podemos conectar nuevamente a la red inalámbrica. La diferencia será que el servidor DHCP nos asignará la dirección IP del otro cliente, que está asociada con dicha dirección MAC.

Interneeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeet

Vulnerability and Exploit: Javier Vicente Vallejo, http://www.vallejo.cc
Vulnerability Analysis: Ruben Santamarta, http://www.reversemode.com

Abstract

Un DoS ocurre cuando se envía un SMB Write malformado a una máquina con Windows Vista instalado, a través de una pipe conectada.

En un principio el bug se reprodujo con la interfaz SRVSVC. Por defecto esta pipe se podría conectar con cualquier usuario, aunque las NULL sessions están restringidas por defecto para esta interfaz rpc. Tras el análisis se pudo comprobar que el bug se reproducía también con otras interfaces que usen Named Pipes como endpoints, por ejemplo, con LSARPC. Esta interfaz podría conectarse mediante una NULL Session, lo que nos permite llevar a cabo el DoS sobre cualquier Vista sin necesidad de conocer ningún usuario.

Affected versions

Windows 2000,XP,2003 Server,Vista y Server 2008. (32-bit)

Probado exitósamente con Microsoft Windows Vista SP1 con los últimos parches.

Analysis

La causa para este DoS es un paquete de tipo SMB WRITE_ANDX (http://msdn.microsoft.com/en-us/library/aa302278.aspx) con valores erróneos para los campos DataOffset y DataLength.

El casque ocurre cuando npfs.sys llama a memcpy con un puntero inválido para el parámetro src.

1: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced. This cannot be protected by try-except,
it must be protected by a Probe. Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: 92bc0000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 81c834b3, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 00000000, (reserved)

Debugging Details:
——————
READ_ADDRESS: 92bc0000 Nonpaged pool

FAULTING_IP:
nt!memcpy+33
81c834b3 f3a5 rep movs dword ptr es:[edi],dword ptr [esi]

MM_INTERNAL_CODE: 0

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0×50

PROCESS_NAME: System

CURRENT_IRQL: 0

TRAP_FRAME: 90126b40 — (.trap 0xffffffff90126b40)
ErrCode = 00000000
eax=92bc02cf ebx=90126c4c ecx=000000b4 edx=00000000 esi=92bbffff edi=98640b98
eip=81c834b3 esp=90126bb4 ebp=90126bbc iopl=0 nv up ei pl nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010212
nt!memcpy+0×33:
81c834b3 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] es:0023:98640b98=00000000 ds:0023:92bbffff=????????
Resetting default scope

LAST_CONTROL_TRANSFER: from 81cd86df to 81c81720

STACK_TEXT:
901266b4 81cd86df 00000003 9012dc44 00000000 nt!RtlpBreakWithStatusInstruction
90126704 81cd914c 00000003 00000000 8c3236b0 nt!KiBugCheckDebugBreak+0x1c
90126ab0 81ca9df2 00000050 92bc0000 00000000 nt!KeBugCheck2+0x5f4
90126b28 81c8fa34 00000000 92bc0000 00000000 nt!MmAccessFault+0×106
90126b28 81c834b3 00000000 92bc0000 00000000 nt!KiTrap0E+0xdc
90126bbc 8726422c 98640a68 92bbfecf 00000400 nt!memcpy+0×33
90126c04 87261f32 952ad314 00000001 92bbfecf Npfs!NpWriteDataQueue+0xf6
90126c58 8726289d 839f3c40 00000001 90126c70 Npfs!NpInternalWrite+0×124
90126c7c 872628e7 839f3c40 92baf9a8 0000ffff Npfs!NpCommonFileSystemControl+0x17b
90126c94 81c27fae 839f3c40 92baf9a8 92baf008 Npfs!NpFsdFileSystemControl+0×19
90126cac 901736d0 90827482 9016562c 92baf008 nt!IofCallDriver+0×63
90126d30 9015a39b 83a01dd8 83a01da0 92baf010 srv!SrvSmbWriteAndX+0x9a1
90126d54 9016be8d 00000000 8c3236b0 00000000 srv!SrvProcessSmb+0×151
90126d7c 81e25472 00a01da0 9012d680 00000000 srv!WorkerThread+0x12c
90126dc0 81c9141e 9016bd61 83a01da0 00000000 nt!PspSystemThreadStartup+0x9d
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0×16

Srv.sys se encarga de procesar el paquete recibido y enrutarlo hacia el driver que corresponda, en este caso npfs.sys (named pipe file system driver) al servir la NamedPipe SrvSvc como endpoint para la interfaz RPC que estamos usando. Veamos cómo maneja el paquete enviado.

En esta porción de código, el driver podría hacer un chequeo para evitar continuar con el proceso en caso de que los offsets no se correspondan con el tamaño real del paquete enviado. A continuación srv.sys construye ( o reusa ) una IRP del tipo FILESYSTEM_CONTROL (0xD) cuyo IOCTL es 0x119FF8 ( FSCTL_PIPE_INTERNAL_WRITE, METHOD_BUFFERED ) que envía al driver correspondiente a traves de una llamada a IofCallDriver. Esta IRP contendrá en el paquete enviado, aunque puede no mantener la coherencia respecto a los campos internos del paquete. Recordemos que la memoria reservada por el IO Manager para crear un buffer en METHOD_BUFFERED se obtiene del area de memoria NonPaged Pool, este es un punto importante para entender porqué se puede producir el fallo.

Srv.sys reusa una IRP anteriormente reservada.

Esta IRP es procesada dentro de la rutina npfs!NpCommonFileSystemControl

Dentro de esta rutina acabamos finalmente en npfs!NpWriteDataQueue que es donde se puede disparar el fallo.
Npfs recupera una entrada de una cola que contiene IRPs pendientes asociadas a la conexión.

Debido a que el driver realiza una comprobación en base a la entrada adquirida, no es posible que se de un overflow en la operación memcpy, como vemos a continuación

Es decir, cualquiera que sea la cantidad de bytes que se vayan a copiar durante memcpy, esa cantidad se reserva dinámicamente por lo que nunca podrá dar lugar a un overflow.
Y finalmente llegamos a donde se produce el fallo

Al ajustar los parámetros para leer la parte de datos del paquete, no se tiene en cuenta que tanto DataOffset como DataLength son incorrectos, por lo que la dirección final que se le pasa como parámetro “src” a memcpy puede apuntar a una memoria no válida, más alla del buffer reservado por Srv.sys en el area NonPaged Pool. Las tags de la memoria reservada por Srv.sys vienen dadas por ‘LSxx‘ y son reservadas a través de srv!SrvAllocateNonPagedPool

En el caso de que esa memoria no fuera válida, se produciría un BugCheck dando lugar a un fallo DoS a nivel de Kernel. Aunque todas las versiones de Windows están teóricamente afectadas, debido a la naturaleza del fallo, este puede no ser reproducible. Se ha comprobado empíricamente que bajo ciertas circunstancias Vista es más propicio a desarrollar el fallo que otros sistemas operativos, donde los Work Context de Srv.sys son más grandes desde un inicio.
Ejemplo:

Vista SP1
kd> !poolused 2
Pool Used:
NonPaged Paged
Tag Allocs Used Allocs Used
[...]
LSwi 1 16464 0 0 initial work context
LSwn 4 33088 0 0 normal work context
[...]

Recordemos

eax=92bc02cf ebx=90126c4c ecx=000000b4 edx=00000000 esi=92bbffff edi=98640b98
eip=81c834b3 esp=90126bb4 ebp=90126bbc iopl=0 nv up ei pl nz ac po nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010212
nt!memcpy+0×33:
81c834b3 f3a5 rep movs dword ptr es:[edi],dword ptr [esi] es:0023:98640b98=00000000 ds:0023:92bbffff=????????
Resetting default scope

1: kd> kv
ChildEBP RetAddr Args to Child
[...]
90126bbc 8726422c 98640a68 92bbfecf 00000400 nt!memcpy+0×33
[...]

1: kd> !pool 92bbfecf-($Packet.DataLength)
Pool page 92bafed0 region is Nonpaged pool
*92baf000 : large page allocation, Tag is LSwn, size is 0×2050 bytes
Pooltag LSwn : normal work context

Comprobamos como sí es posible que se pueda llegar a dar el caso.

1: kd> !pte 92bbfecf – ($Packet.DataLength)
VA 92bafed0
PDE at 00000000C06024A8 PTE at 00000000C0495D78
contains 00000000030B8863 contains 0000000009A40963
pfn 30b8 —DA–KWEV pfn 9a40 -G-DA–KWEV

1: kd> !pte 92bbfecf + ($Packet.DataLength)
VA 92bcfece
PDE at 00000000C06024A8 PTE at 00000000C0495E78
contains 00000000030B8863 contains 0000325E00000000
pfn 30b8 —DA–KWEV not valid
PageFile: 0
Offset: 325e
Protect: 0

Inspeccionando la memoria

1: kd> db 92bbfecf – ($Packet.DataLength)
92bafed0 ff 53 4d 42 2f 00 00 00-00 18 07 c8 00 00 cc cc .SMB/………..
92bafee0 cc cc cc cc cc cc 00 00-00 08 dc 24 01 08 37 72 ………..$..7r

1: kd> db 92bbfecf + ($Packet.DataLength)
92bcfece ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????
92bcfede ?? ?? ?? ?? ?? ?? ?? ??-?? ?? ?? ?? ?? ?? ?? ?? ????????????????

Aunque el bug no se reproduce de esta manera (ya que es debido al manejo de las IRP por parte srv.sys), si te interesa depurar parte del código involucrado en el casque, es posible llegar hasta npfs!NpInternalWrite y npfs!NpWriteDataQueue localmente con Kartoffel:

kartoffel -d \\.\pipe\lsass -n 0×20 -o 0 -z 0×101 -Z 0×0 -I 0x119ff8 -g -u ADDRESS,INVALID_ADDRESS

Exploit

Aquí hay un exploit PoC para metasploit que reproduce el DoS: