Archive for the 'Seguridad' Category

BotNets!

Lunes, Junio 9th, 2008

Anoche un amigo y yo nos aburriamos y ya que ambos tenemos nuestras páginas en un server propio en casita decidimos echarle un ojo a nuestros registros de apache:

# grep txt access.log | grep -v robots

Al resultado de ejecutar esta busqueda aparecieron numerosas peticiones GET con el contenido ‘txt’ en su interior que llamaban a archivos que no estaban en mi directorio web, si no que eran intentos en su gran mayoría de convertir a un host en un zombie para alguna BotNet mediante algun bug RFI.

Las BotNets (o Red de bots o robots) son comunmente servidores bien privados bien públicos de IRC (Internet Relay Chat) que se emplean como HUBs de Zombies que normalmente se encuentran bajo las órdenes del script kiddie mas inútil que puedas encontrarte.

Un Zombie es una máquina que ha sido comprometida y que ejecuta código malicioso a la espera de instrucciones de su dueño (el “hacker”). Los Zombies que suelen conectar y formar BotNets corren un programa script (mayormente perl) que simula ser una persona que se conecta a un IRC específico y que cumple instrucciones de una determinada persona, normalmente identificada por el nick (pseudónimo) o por el host (Dirección IP).

Estos programas reciben el nombre de Shellbot, ya que son Bots que ejecutan instrucciones en la shell de la maquina víctima.A continuación pongo y enlazo mirrors de algunos bots y RFIs para infectar máquinas que he encontrado en la búsqueda anteriormente descrita:

Algunos jaquers infectan directamente con un shellbot, otros ejecutan un php para que luego este último ejecute el shellbot o un deface y los que menos saben programar simplemente suben un único script php como este que les deja ejecutar cuanto quieran siempre que PHP esté mal configurado y que se ve así:

Capura r57

A diario estos ataques se automatizan y se suceden ya que muchos de estos ShellBots actuan como gusanos, se copian en el public_html o www de un servidor al que hayan infectado y acto seguido escanean el mundo en busca de mas víctimas a las que infectar, y lo peor es que la gran mayoría de las botnets existentes se emplean para realizar ataques de denegación de servicio distribuidos (DDoS) por lo que hay que tener cuidado y cuidarse las espaldas si eres administrador de alguna página y/o servidor.

Ganando acceso de root en linux < 2.6.24.1

Miercoles, Febrero 13th, 2008

Pues sí, hasta hace poco había un xploit público para ganar privilegios de root en las versiones de la 2.6.13 a la 2.6.17, pero ahora debido a la vulnerabilidad de vmsplice que existe en las versiones 2.6.17 y superiores hasta 2.6.24.1 se ha hecho público un xploit capaz de devolver privilegios de root en estas máquinas.

Teniendo en cuenta que la última versión es la 2.6.24.2 (la que corrige el fallo) este xploit funciona en casi todas las maquinas que tengan linux instalado, por lo que es ALTAMENTE recomendable actualizar el nucleo de linux si la maquina en cuestión no es exclusivamente de uso personal.

Apoyo a Genbeta

Viernes, Febrero 8th, 2008

Últimamente de un par de días hacia aqui genbeta.com sufre un ataque de denegación de servicio distribuida (DDoS) debido a un articulo que uno de sus editores publicaba el pasado 13 de noviembre del 2007, que fué portada de meneame en su día y que debido a la falta de acceso al sitio original paso a citar a continuación:

¿Quieres saber quién te tiene no admitido/eliminado en el MSN? Pues no des tu contraseña a desconocidos

Parece mentira que después de tanto tiempo (¡años ya!) del invento de este fraude todavía haya gente que siga cayendo en él. Es muy simple, y seguro que muchos lo conocéis, simplemente se trata de páginas que ofrecen el servicio de mostrarte quién te tiene como no admitido o te ha eliminado del mésenyer a cambio de que les des tu datos de conexión, es decir, tu usuario y contraseña. Creía que este negocio ya estaba más que muerto, pero hoy mismo un par de contactos míos me han saltado con la típica ventanita que me acceda a una de esas páginas para que me lea el futuro.

Como norma general, dar la contraseña de tu correo a alguien que no pertenezca a tu familia ya es un suicidio tecnológico, y en este caso sería como darle la contraseña de tu tarjeta de crédito a una persona desconocida para que te muestre el dinero que tienes. ¿Quieres saber qué es lo que hacen? La mayoría de páginas, después de mostrarte esa información, se conectan a tu cuenta varias veces al día para molestar a todos tus contactos con spam descarado. Lo que es peor, esto puede colapsar tu cuenta y no sería raro que la perdieras para siempre, o al menos que la conexión sea pésima. Así que ya sabes, no des tu contraseña a ningún sitio web, o atente a las consecuencias.

Pero claro, ¡tú quieres saber quién te tiene como no admitido! Sorpresa: esos sitios, además de ser peligrosos, no funcionan. Microsoft cambió hace tiempo el protocolo para que los servidores de msn no difundieran esta información. Antes sí podías, pero ahora mismo ni siquiera puedes saber el estado de otra persona sin que ella te invite/admite o sin saber la contraseña de la cuenta (sin cambiar la configuración de la cuenta). Sin rebuscar demasiado, algunos sitios fraudulentos que siguen esta práctica serían: blockoo.com, scanmessenger.com, detectando.com, quienteadmite.info, checkmessenger.net, blockstatus, etc… Todos ellos son potenciales phishing, y ninguno funciona más allá de recolectar cuentas de correo.

Disculpad los lectores avanzados que ya habéis dejado atrás este tipo de engaños facilones hace mucho tiempo, pero es que hoy me he vuelto a conectar al messenger por obligación y me he dado cuenta de que las cosas han cambiado muy poquito.

El artículo aún se puede leer en la (bendita) cache de google.

Mucho tiempo después genbeta.com recibió un correo electrónico en el que le amenazaban de un ataque al sitio si no se retractaban del citado artículo:

Les comento que si no sacan esta nota [url de la entrada en cuestión] su pagina sufrira una denegacion masiva enorme, desde un datacenter de china, la cual no la podran detener, y es tan fuerte, que podra afectar toda la red donde alojan, es decir, a otros servidores dedicados.
(…) El motivo es simple, la gente como ustedes me da por las bolas, se la pasan hablando sin fundamentos, o acaso auditaron algun servidor y tienen constancia alguna de que esas web hagan “pishing” entonces para que hablan?
(…) ASI QUE HASTA QUE NO LA SAQUEN, GENBETA.COM NO FUNCIONARA.

CIUDAD DEL ESTE Y EL GRUPO CHINA SE ENCARAGA DE ESTO

A pesar de lo risotorio del correo la amenaza se ha hecho efectiva ya que genbeta.com sigue sin funcionar en el momento de la redacción de este artículo.

Desde aqui me gustaría mostrar mi apoyo a genbeta.com y mi desprecio a los engendros que ni humanos merecen ser llamados que están atacando genbeta.com y demostrando así cuanta razón tenían escribiendo el artículo. Un saludo

Red WiFi Segura: WPA+EAP-TLS+RADIUS

Miercoles, Abril 11th, 2007

Hasta hace un par de días tenía una red WiFi con cifrado WEP y controlaba los accesos a través de los logs del punto de acceso. Cada día crece el número de métodos para romper una red Wireless y crece el número de personas que lo intentan, por lo que al final me animé a cambiar el sistema.

El objetivo de este manual es montar una red WiFi segura, que empleará certificados de cliente y servidor para la autenticación, usando como servidor radius FreeRADIUS. Para ello realizaremos los siguientes pasos:

  1. Instalar FreeRADIUS
  2. Configurar el Punto de Acceso
  3. Configurar el Cliente.

La distribución que emplearé será Debian y trataremos de tirar de apt en la medida que se pueda.

El Punto de Acceso que emplearé a modo ejemplo será un DWL-2000AP+ con soporte WPA. El mio lo traia de fábrica, pero siel que vais a usar no lo tiene, probad actualizando el firmware.

El cliente que usaré, también como ejemplo, será el Mac OS X 10.4 y trataré de explicar tambien como hacerlo en Windows XP.

FreeRADIUS

Al principio traté de instalarlo por apt, pero descubrí que por un problema de licencias con openssl la versión de apt de freeradius no traia el módulo eap+tls, así que habrá que instalar freeradius desde el código fuente.

Primero, prepararle el entorno: necesiraremos openssl, libssl y libssl-dev.

# apt-get install openssl
# apt-get install libssl
# apt-get install libssl-dev

Ahora que ya tenemos el entorno, hay que bajarse la ultima versión de FreeRADIUS, compilarla e instalarla.

# cd /usr/src
# wget ftp://ftp.freeradius.org/pub/radius/freeradius-1.1.5.tar.gz
# tar xvfz freeradius-1.5.5.tar.gz
# cd freeradius-1.5.5
# ./configure –prefix=/ –with-raddbdir=/etc/raddb
# make
# make install

Ahora tendremos freeradius instalado en el sistema, queda configurarlo. Lo primero que haremos será crear los certificados apropiados con la ayuda de estos pequeños scripts procedentes en parte de aqui.

# cd /etc/raddb/certs
# wget http://karman.homelinux.net/blog/descargas/cascripts.tar.gz
# tar xvfz cascripts.tar.gz

Primero crearemos el certificado raíz:

# CA.root

Nos pedirá una serie de datos que realmente no son necesarios, yo solamente rellene los 3 primeros. Si todo ha salido bien, nos habrá creado los archivos root.der, root.p12 y root.pem. El siguiente certificado a crear es el del servidor:

# uname -n
karman.homelinux.net
# CA.server karman.homelinux.net

En este caso es importante que rellenemos el campo Common name con el nombre del servidor, karman.homelinux.net en este caso. Cuando nos pregunte [y/n], respondemos y ambas veces. Si todo ha ido bien, nos habrá creado los archivos karman.homelinux.net.p12, karman.homelinux.net.der y karman.homelinux.net.pem.

Ahora crearemos un certificado por cada usuario ejecutando el script con dos argumentos, el usuario y la contraseña:

# CA.client karman 12345

Como de costumbre, rellenamos los campos, le decimos que si a las dos ultimas preguntas y nos creará los archivos karman.der, karman.pem y karman.p12.

Como hemos dicho que el directorio de configuración sea /etc/raddb, el programa de instalación ha copiado una configuración básica para que arranque freeradius, pero no es lo que necesitamos, por lo que deberemos de modificar los siguientes archivos:

eap.conf

eap {

default_eap_type = tls
timer_expire = 60
ignore_unknown_eap_types = no
cisco_accounting_username_bug = no
tls {

private_key_password = whatever
private_key_file = ${raddbdir}/certs/karman.homelinux.net.pem
certificate_file = ${raddbdir}/certs/karman.homelinux.net.pem
CA_file = ${raddbdir}/certs/root.pem
dh_file = ${raddbdir}/certs/dh
random_file = ${raddbdir}/certs/random
fragment_size = 1024
include_length = yes

}

}

Este es todo el contenido que tiene que tener el archivo eap.con. Nótese de cambiar los parámetros private_ket_file y certificate_file con los valores correspondientes.

clients.conf

# Punto de Acceso DLink
client 192.168.0.50 {

secret = pruebadeap
shortname = AP
nastype = other

}

Así es como hay que configurar un cliente. Ya viene con 127.0.0.1, que podemos modificar o borrar para que sirva a nuestros propositos. En todo caso, con el que el clients.conf tenga solamente las lineas anteriormente mostradas será suficiente para funcionar. Nótese de cambiar la ip en el campo client por la del punto de acceso y cambiar el campo secret por una contraseña que nosotros queramos.

users

“karman” Auth-Type := EAP

Esto es todo lo que deberá de ir en users. A la hora de añadir un usuario nuevo será tan sencillo como crearle un certificado, añadir esta linea con el nombre de usuario adecuado y darle a ese user su certificado para configurar el ordenador (lo veremos más adelante).

Llegados a este punto, sería conveniente hacer un usuario para el servidor radius añadiendo las siguientes lineas a nuestros passwd, shadow y group:

/etc/passwd: freerad:x:106:106::/etc/raddb:/bin/false
/etc/shadow: freerad:!:13611:0:99999:7:::
/etc/group: freerad:x:106:

y cambiar de usuario y los permisos de todos los archivos de /etc/raddb:

# chmod 700 -R /etc/raddb
# chown -R freerad:freerad /etc/raddb

radiusd.conf

bind_address = 192.168.0.1
user = freerad
group = freerad

En este caso, la modificacion de bind_address no es necesaria, yo la hice porque el ordenador que alberga el radius es a su vez mi router, y no quería que escuchase peticiones de login en internet, solo en intranet. En este archivo hay muchas cosas que podríamos tocar para afinar la configuración, pero de momento nos bastará como viene, ajustes finos a gusto de cada cual.

Ahora que tenemos todo en su sitio como toca, haremos una prueba de arranque con

# radiusd -X

lo que nos dará una salida detallada de arranque. Si todo ha ido bien y sin problemas, podemos bajarnos este script de inicio para debian, copiarlo en /etc/init.d y arrancaremos el servicio con

# /etc/init.d/radius start

Punto de Acceso (AP)

Configuracion de WPA para el Dlink DWL-2000AP+El siguiente paso es configurar nuestro punto de acceso para que cifre la red wireless con WPA (ojo, NO WPA-PSK). Si lo soporta, nos pedirá básicamente tres datos: IP del servidor radius, puerto del servidor radius y el ’secreto’, que viene siendo una contraseña. En nuestro caso ejemplo:

IP: 192.168.0.1
Puerto: 1812
Shared Secret: pruebadeap

Configurando un Cliente Windows/Mac OS X

Es tan sencillo como copiar en el ordenador cliente el certificado /etc/raddb/certs/karman.p12 (o elnombredelusuario.p12) y añadirlo con un doble click sobre el mismo. Nos preguntará si queremos añadirlo a los certificados, le decimos que si y entonces nos preguntará la contraseña que pusimos para cifrar el certificado a la hora de crearlo (12345).

Ahora que tenemos el certificado añadido al sistema, simplemente le damos a conectar a la wifi, con esto tendremos ya la wireless wpa+eap-tls.

Cualquier problema o duda, posteadla como comentario, ya que el manual lo he escrito dos días después de configurar mi WiFi y no se si se me ha podido pasar algo. Si alguien sabe como añadir el certificado y usarlo para autenticación WPA en linux agradecería que me lo enviase por correo o lo posteara en comentarios.

Update: En adición al artículo, he notado que al mes los certificados dejan de funcionar por la siguiente opcion del /etc/ssl/openssl.cnf:

default_crl_days= 30

Yo la he cambiado a 365 días, para que tarde un año.

También hay que editar CA.root y añadir en la instruccion openssl la opcion -days X, donde X es el valor en días que tardará en caducar el certificado raiz, que por defecto está a 30 dias. Ej, lo tengo a 3650 días, 10 años:

openssl req -new -days 3650 -x509 -keyout newreq.pem -out newreq.pem -passin pass:whatever -passout pass:whatever

A veces veo errores…

Viernes, Febrero 2nd, 2007

01-02-07_1300.jpgA veces veo errores como el de hoy: un cajero automático con un error de windows, mas concretamente del componente ActiveX que se ve impotente para crear un objeto.

¿No os da que pensar que los cajeros automáticos empiecen a simplificar los SO tirando de uno que ya existe y que está catalogado como el peor en cuanto a seguridad informática se refiere?

¿Se podría crear un virus de cajeros que te quitase un par de centimos tan solo transfiriendolos a otra cuenta?

No me gusta que mi dinero se vea expuesto a tantas inseguridades. He decidido no usar uno de esos cajeros automáticos tan modernos que emplea ServiRed, prefiero algo mas clásico como un 4B ^^.

Update: Me entero por lemmke que los cajeros de la caixa son en su mayoría Pentiums a 133Mhz (algunos a 166Mhz) y corren nada menos que Windows 98 (que yuyu).