Comprueba que tu servidor de correo está bien configurado con mail-tester

Que levante la mano quien gestione uno o más servidores de correo electrónico. Y que sigan con la mano levantada los que tengan esos servidores de forma dedicada. 

A la hora de configurar un servidor de correo, hay varios puntos a tener en cuenta: que si no sea open relay, que requieran autenticación antes de envío, que los algoritmos de autenticación y firma no sean débiles, que los certificados utilizados tengan una longitud de clave adecuada, etc, etc,...   

Sin embargo, el post de hoy tiene una mezcla entre seguridad y sistemas, y está pensado en verificar varios puntos que hacen que otros servidores de correo verifiquen que el servidor es correcto y que no marque como spam, o no le asigne puntos al menos por las cabeceras o por el servidor de donde viene. Si el contenido del correo contiene viagra, Rolex, invoice, archivos con doble extensión, etc,... pues ya no se puede garantizar, pero al menos que el servidor esté lo más correcto posible.

Para ello vamos a utilizar un servicio online gratuito, llamado www.mail-tester.com. Se nos muestra una dirección de correo aleatoria de mail-tester.com.

La forma de hacer la prueba es tan fácil como enviar un correo electrónico desde un cliente que salga desde el servidor de correo electrónico que queremos comprobar a la dirección propuesta por mail-tester.

Una vez enviado, se pulsa en "Then Check Your Score" y se puede ver el análisis realizado por el servicio. Inicialmente se ve un resumen:

¿Qué puntos de control se verifican?

• Análisis con Spamassassin
• Comprobaciones de SPF, DKIM, DMARC, Resolución inversa 
• Verificación del contenido del correo
• Verificación en listas negras o blacklists

Viéndolo en detalle, la primera verificación la hacen con spamassassin. Es decir, qué diría este software sobre el correo que enviaste. Hay ciertas comprobaciones que spamassassin ya hace, que serán repetidas con las que hace mail-tester posteriormente, pero es una métrica tan válida como otra cualquiera.

Las más importantes, para mi gusto, son las siguientes: 

• Se comprueban registros SPF, que como se puede ver en el enlace, son registros DNS de tipo TXT que autoriza a qué máquinas (por dirección IP, redes en formato CIDR o por nombre DNS) pueden enviar correos electrónicos. El servidor que recibe el email, comprueba que la dirección IP de donde viene la comunicación de envío de correo está dentro de los hosts autorizados.
• Se comprueba la firma DKIM que se envía en las cabeceras del correo electrónico. No es el objetivo explicar cómo se configura DKIM, pero en esencia, el servidor de correo emite una firma que va en la propia cabecera. Dicha firma se puede verificar con la clave pública, complementaria a la privada que emitió la firma, que se puede rescatar de un registro DNS de tipo TXT. Dicho registro viene notificado en la propia cabecera DKIM. Si la firma es correcta, es otra forma de verificar que el servidor de correo está autorizado para enviar el mensaje analizado. Hay una buena saga de posts de Chema Alonso que explican en detalle los internals de DKIM. 

• Se comprueba la existencia y validez de un registro de tipo DMARC. No conocía bien este tipo de registro (de hecho la primera vez que hice la prueba me dio que tenía fallo por este item). Su funcionamiento está muy bien documentado en https://dmarc.org/overview/. Si sólo queremos su existencia (con esto ya no nos penaliza la comprobación), pero sin aplicar ninguna política, tendrá que tener un formato como este: _dmarc.securizame.com TXT "v=DMARC1\; p=none".

• Comprobación de equivalencia de resolución inversa de DNS de la IP origen, con el dominio que envía el correo electrónico. Puede que esto no sea idéntico siempre, si se piensa en que un servidor de correo puede albergar cientos de dominios, y la resolución inversa de la IP, corresponde a uno de ellos (o incluso a ninguno, si se piensa en un ISP). 

La última de las comprobaciones se hacen relativas a la dirección IP, que no se encuentre en ninguna lista negra (de las muchas que hay). Es lo que hacía la herramienta AmISpammer, uno de mis proyectos de abandonware.

Respecto a la configuración de DKIM, SPF y DMARC, tenéis una excelente guía para entender el funcionamiento y afinamiento en la wiki de Zimbra.

Como he dicho al principio, no garantizamos la seguridad del servidor de correo por pasar correctamente esta checklist, pero por lo menos, os aseguráis (o en una muy buena medida) que la mayoría de los correos electrónicos que envíe vuestro servidor, no irán a parar a la carpeta Spam, si van dirigidos a servidores que aplican políticas de antispam estrictas como Gmail, Outlook, etc,... 

Leer más...

¡ Malditos ! Ya no me puedo creer nada !

Vivimos en una sociedad en la que aparentar significa mucho, no es lo mismo sacar de tu bolsillo un precioso Iphone de 900 dólares que un simple Huawei de 100. Igual que tampoco genera la misma imagen bajar de un Mercedes a bajarse de un Skoda.

Sí, es injusto, tan injusto como inherente al ser humano, como bien lo describió Maslow en su pirámide

Gracias a esa necesidad de aparentar, desde hace mucho tiempo circula una floreciente economía de las imitaciones, hay trajes (H)armani, pantalones Lavis e incluso en muchos casos hasta es un copy / paste con marca incluida pero de calidad inferior.

Lamentablemente en Internet esto se está trasladando muy rápidamente a las redes sociales, hay que aparentar, todo el mundo conoce y sabe que se pueden comprar followers en twitter, no son caros y generan 'imagen', no es lo mismo andar con 200 followers que con 20.000.

Lo que me ha sorprendido es que, el tema de las redes sociales está tan prostituido que no es solo twitter o Facebook, es que prácticamente cualquier red social tiene su servicio que-vende-algo.

Crees que los likes y los followers de Instagram son reales ?

Si piensas en la siempre reputada Linkedin, tampoco te puedes fiar

Ni en followers ni en 'Endorsements'

Te sorprende cómo ese artista que a ti te resulta tan penoso tiene tantos visionados en Youtube ? Apuesta a que también ha hinchado sus stats a base de visionados falsos

Y Quora ? esa red social que vino empujando tan fuerte y de la que ya nadie se acuerda 

Tal vez puedas pensar que Google+ (que está muerta, dicen ...) se salva

Igual alguien se esté preguntando qué tiene que ver esto con la seguridad informática, es una buena pregunta y la respuesta es: RE-PU-TA-CI-ÓN

Mucha gente, si le presentan una super oferta de Iphones a 200 euros y ve una web con un perfil twitter asociado con, digamos, 2000 followers, 1000 tipos en G+, otros cientos en Instagram, le va a transmitir una sensación de confianza para 'creer' ese fake y caer en el timo.

Al final todo es aparentar

Leer más...

Análisis de phishing que simula el portal iTunes Connect de Apple

Revisando los correos que llegan a SPAM, en ocasiones te puedes llevar más de una sorpresa. Sin ir más lejos, ayer 17 de Agosto recibí un correo con el alarmante asunto Apple: Your account has been frozen, que más o menos venía a decir que mi cuenta de Apple había sido congelada a la espera de que confirmase algunos datos:

Spam supuestamente de Apple para reactivación de cuenta de iTunes

Analizando el mensaje original, incluyendo las cabeceras del correo, podemos comprobar como se utilizó un script PHP de envío de correo a través de internet, el cual se encuentra en la siguiente ruta (reflejada por completo en la cabecera X-PHP-Script:

Extracto de las cabeceras del e-mail

Como veréis en la segunda linea de la imagen, la cabecera X-PHP-Script contiene la ruta completa al fichero temp.php dentro del dominio every-tickets.com (que seguramente fuese comprometido previamente para contener este tipo de scripts de envío de correos de forma anónima):

Script PHP de envío de correos anónimos a través de un servidor online posiblemente comprometido

Atendiendo ya al contenido del e-mail, éste contiene un enlace que llevaba a la siguiente URL: 

+ http://myserviceson.com/applllle/WebObjects/iTunesConnect.html

en la cual apreciaréis que es similar a la simulada del servicio iTunes Connect de Apple que originalmente se encuentra en la siguiente URL:

+ https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa

Accediendo al phishing, ya directamente solicita el CVV de la tarjeta de crédito además del Apple ID y la contraseña...

Diferencia entre el portal original y la copia phishing de iTunes Connect

Analizando el código fuente del html de phishing, buscamos la acción del formulario al hacer click en "Sign in", detectando un fichero php llamado:

+ myserviceson.com/applllle/WebObjects/emsg1.php

el cual si accedemos directamente a él (petición GET), se nos muestra un formulario para introducir todos los datos posibles de la cuenta (que obviamente, incluye todo lo referente a tarjetas de crédito, códigos de seguridad, datos personales, etc) al redirigirse a un html llamado details.html:

Formulario de solicitud de datos completos del usuario (paso 2 del proceso)

De nuevo, analizamos el código fuente para obtener un nuevo recurso que actuará de acción para el formulario al introducirse los datos, llegando a un nuevo php en:

+ myserviceson.com/applllle/WebObjects/tabli8.php

Al acceder a este por GET de nuevo, se muestra un error típico de PHP, ya que obviamente este PHP no se pensó para ser llamado directamente, si no tras completar el formulario y hacer click en enviar los datos:

Aviso mostrado por el fichero php al no ser ejecutado correctamente a través del flujo original

Recapitulando hasta aquí, disponemos de los siguientes recursos típicos que está utilizando este phishing:

1. Dominio myserviceson.com
2. applllle/WebObjects/
3. applllle/WebObjects/emsg1.php
4. applllle/WebObjects/tabli8.php

Una vez hemos hecho esta recopilación, procedemos a buscar información a través de google referente tanto al dominio, como a estos ficheros PHP y rutas concretas, para determinar si pudiera encontrarse en más servidores o si ya se hubiera reportado previamente un phishing de estas características pero alojado en otros sistemas. Al realizar la búsqueda en Google, mediante site: sobre el dominio afectado, nos encontramos como en la caché de Google se encuentra un antiguo listado de directorios, en los que vemos dos ficheros de texto: ID.txt y Full.txt, el directorio applllle y el php temp.php:

Búsqueda en Google relacionada con el dominio dónde se encuentra el phishing

• El fichero temp.php (que ya no está presente), podría corresponder con el script de envío de correos mencionado anteriormente en el análisis de las cabeceras del e-mail.
• El fichero ID.txt, presente en el servidor, parece registrar la información referente al primer formulario de login que ya solicitaba el CVV
• El fichero Full.txt, presente en el servidor, parece registrar la información referente al segundo formulario de registro de datos completos. 

Debido a que durante la investigación no se llegó a realizar ningún envío a través del formulario, pero si se accedieron a los PHP directamente (emsg1.php y tabli8.php), quizás fuera lo que provocó la creación y registro de los intentos (aún sin incluir datos) de acceso a los formularios, y serían los ficheros que almacenarían toda la información de las víctimas que picasen en este phishing.

Por desgracia, este phishing finalmente si que fue utilizando en anteriores ocasiones (durante los últimos días, y con gran éxito de recogida de información) y estuvo alojado en otros hostings que ya fueron denunciados como que se utilizaban para estos menesteres. Lo peor de todo es que aún todavía a día de hoy, se pueden encontrar ficheros ID.txt y Full.txt con multitud de datos sensibles de usuarios  (víctimas) que llegaron a cumplimentar tanto el primer formulario como el segundo....

Leer más...

Análisis de intrusión y malware en PHP: Un caso práctico

Sucedió hace unas semanas. Recibo la llamada de un cliente preocupado, en la que me dice que algo raro está pasando en dos de sus servidores, que las colas de los procesos de correo se han vuelto locos y que están brutalmente sobrecargados. Se trata de una humilde empresa que da servicios de hosting web y correo a varios clientes a través de dos servidores alquilados. Me envía las credenciales de acceso a los mismos, tanto para SSH como para Plesk.

Una vez conectado a las máquinas, y tras comprobar que la carga de las mismas no es excesivamente elevada, descargo un kit de herramientas para diagnosticar el problema. Mediante unhide, rkhunter y chkrootkit, veo que el sistema no muestra procesos ocultos ni malware conocido. La ejecución de unhide-tcp así como un nmap remoto completo, me deja ver que no hay sockets ocultos aparentes (me parecería extraño que hubiese algún malware que exigiese port knocking previo para activarse/desactivarse, aunque la idea es bastante buena). Por otra parte, el tipo de empresa, y la de sus clientes, no me pareció que fuesen a ser el objetivo de ninguna organización ni gobierno que quiera robar secretos nucleares, por lo que no me hago a la idea que vaya a ser muy complejo el mecanismo por el que le están atizando.

Sin embargo, las colas de correo siguen incrementándose más y más. La sangre no ha debido llegar al río suficientemente, puesto que amispammer no indica que las direcciones IP de mi cliente hayan sido incluídas en alguna lista antispam. Los logs de diferentes servicios no arrojan excesiva información, excepto el de qmail, que no para de mostrar montones de intentos de conexión a servidores de AOL, a los que no puede enviar determinados mensajes por no ser válidos los buzones buscados. ¿Pero esto de AOL no se había muerto ya hace años? Sin embargo, con un simple "top" observo que se ejecuta frecuentemente un mismo cgi en php. No veo un aumento significativo de recursos cada vez que se ejecuta, pero por echarle un vistazo, nada pierdo, ¿verdad?

Pues touché… según edito el fichero, me encuentro con un script php en una única línea, que claramente han ofuscado. ¿Adivináis la ruta? Dentro de un directorio con plugins para joomla de uno de los dominios clientes de hosting. En concreto en /components/com_content/newso2p.php y /components/com_content/statgpZO.php, con idéntico contenido.

Probé a subirlo a virustotal, y oh sorpresa, aparecía referenciado por muy pocos antimalware. En concreto, los únicos que lo detectaban eran ClamAV, DrWeb, Sophos, Trendmicro y VBA32… 

Entre otras acciones, como borrar los ficheros en concreto, le propuse al cliente que actualizara Joomla y sus componentes, eliminara los plugins inútiles, etc, etc, dentro de lo que el panel de hosting le permite.

A partir de aquí caben dos preguntas. ¿Cómo ha llegado ese PHP ahí? ¿Y qué es lo que hace?

La primera de las preguntas parece de fácil respuesta: dado que el fichero tenía como dueño el usuario de Apache, y dado el lugar donde estaba, tiene toda la pinta que por alguna vulnerabilidad de Joomla! que permita escribir ficheros en sus directorios de plugins o componentes. 

¿Qué hace el "malware"?

Como indiqué más arriba, el código PHP está ofuscado y, en una sola línea, hace bastante incómoda su lectura:

Por no liarme a buscar el ofuscador utilizado para este script, usé mi manido Perl para dejarlo de una forma más legible. Me hice un script quick & dirty que me permitiese pre-procesarlo:

Con lo que me queda en out.php, la idea era identificar las diversas variables del fichero, y cambiarlas por un valor más sencillo de ver, como por ejemplo $a en vez de $v1cb251ec, f1 en vez de n9a2d8ce3 para los nombres de funciones, etc,… Aproveché a eliminar funciones que no eran llamadas nunca, que simplemente confundían más al análisis.

Así, el script PHP quedaría de esta manera:

Fundamentalmente, el atacante, simplemente tenía que hacer llamadas a este PHP, mediante el método HTTP POST y en el POST DATA enviaba en varios campos diferentes la información necesaria para construir los correos: origen, destino, subject y cuerpo.

Inicialmente, estos datos vienen codificados en Base64 y se descodifican en tiempo de ejecución. Por otra parte, se procesa en el código, una lista con las direcciones  de correo destino, que viene también en la llamada. Se establecen las cabeceras necesarias del correo y el propio bicho busca si hay servidor de correo en localhost. Si lo hay, lo usa, y si no lo hay resuelve él mismo los registros MX de los correos que recibirán el spam y les abre un socket al puerto 25, estableciendo una comunicación SMTP, enchufándoles el contenido con cabeceras del correo generado.

Conclusiones

• Pese a no ser un troyano muy mediático, el script está suficientemente bien hecho para que llame poco la atención dentro del sistema. No consume muchos recursos, ya que envía correos según se le hacen llamadas desde fuera, y en una sola llamada puede generar la ejecución de muchos correos de spam a la vez.
• Los logs que deja no son muchos, debido a que al ser con POST, no quedan datos almacenados por los parámetros que tendría si se hiciese mediante GET.
• Además, si da algún error la llamada POST, tampoco deja rastro, puesto que lo primero que hace en su ejecución, es deshabilitar cualquier tipo de traza así: "@error_reporting(0); @ini_set('error_log', NULL); @ini_set('log_errors',0); "
• En cualquier caso, y supongo que para evitar WAFs o algunos IPS que analicen las llamadas HTTP, codifica los parámetros en base64. De esta manera evitas la detección de los ingredientes necesarios para construir correos con spam en base a patrones.
• En este caso, quien se quejaba, era el sistema de monitorización de procesos del hosting, en los que el administrador veía que las estadísticas de envío de correo no eran normales, para lo que estaban acostumbrados a ver. 
• Es interesante que se comunica con el atacante (o con el bot que lo ejecuta) mediante códigos OK + el md5 de "1234567890" cuando es correcto y un código de estado + el md5 de "0987654321" cuando es incorrecto. 
• Los logs generados por Qmail se dispararon también en tamaño y un tcpdump del puerto 25 era como ver pasar las letras de Matrix pero a alta velocidad.

Leer más...

Cómo no hackearon el whois de facebook.com

Este lunes se cayó Facebook. Entre los posibles motivos que circularon sobre su caída se encontraba el de que habían hackeado su DNS. Este rumor se fundaba en que en ese momento alguien hizo un whois desde la consola al dominio facebook.com y se encontró lo siguiente:

Efectivamente, Facebook no ha puesto eso ahí ni creo que le haga muy feliz verlo. Pero no han hackeado su DNS ni la base de datos de Whois, como se llegó a decir. Al menos no en el significado más extendido de la palabra hackear.

Es un hack en el significado de que se ha aprovechando de una forma original una característica de un sistema para un fin para el que no estaba previsto (spam, básicamente) y es algo que se lleva haciendo con los dominios más populares desde antes incluso de que existiera la primera red social. Lo sufren, entre otros, Google, Yahoo, Microsoft y prácticamente cualquier dominio popular que se nos ocurra.

Si nos fijamos, lo que nos muestra son subdominios de otros dominios que no tienen nada que ver. Por ejemplo, facebook.com.more.info.at.www.beyondwhois.com es un subdominio de beyondwhois.com y yo diría que su propietario tiene algo que ver con que ese subdominio aparezca ahí.
Pero espera, ¿subdominios? ¿No se supone que whois es sólo para consultar información de registro de dominios y no debería listar subdominios? Pues no exactamente.

El uso más popular de whois es comprobar los datos de un dominio (titularidad, registrador, DNS, etc.) pero tiene más usos, como obtener el rango y operador al que pertenece una dirección IP o la conectividad de un sistema autónomo.

Fijándonos en la respuesta del servidor a algunas peticiones de whois veremos qué tipos de datos nos está dando:

• inetnum:        1.1.1.0 - 1.1.1.255

  Nos está dando información sobre un rango de direcciones IP.

• as-block:       AS3209 - AS3353

  Nos da información sobre un sistema autónomo.

• Domain Name: FACEBOOK.COM

  En esta respuesta nos incluye información sobre un dominio.

• Server Name: FACEBOOK.COM.LOVED.BY.WWW.SHQIPHOST.COM

  En este caso, sin embargo, la información se refiere a un servidor DNS.
  

Bien, ya tenemos la primera pista: las entradas 'falsas' son de distinto tipo (servidores de nombres) que la 'real' (nombre de dominio). De hecho, si en la solicitud a whois indicamos que queremos información sobre un nombre de dominio, los demás subdominios ya no aparecerán:

Ahora ya sabemos que las otras entradas que aparecían eran servidores DNS.
Pero entonces, ¿whois también nos lista servidores DNS? Parece que sí, vamos a comprobarlo:

Efectivamente, así es. ¿Por qué sucede esto?

En la respuesta que nos da el servidor whois podemos ver que también se incluye la dirección IP a la que apunta ese subdominio. Este es un registro glue.
Vamos a ver en qué consiste y qué utilidad tiene, pero primero vamos a recordar cómo funciona la resolución de un nombre de host obviando algunos detalles:

1. Queremos acceder a www.google.com así que le preguntamos a los servidores raíz root-servers.net.
2. root-servers.net nos dice que debemos preguntarle a gtld-servers.net ya que es el NS que figura para la zona com.
3. gtld-servers.net nos dice que debemos preguntarle a ns1.google.com ya que es el NS que figura para la zona google.com
4. ns1.google.com finalmente nos da la dirección IP de www.google.com

Podemos reproducir todo este proceso con dig:

Como podemos ver, cuando root-servers.net nos dice que preguntemos a gtld-servers.net, añade una sección adicional a la respuesta en donde nos dice las direcciones IP de gtld-servers.net y lo mismo cuando gtld-servers.net nos dice que preguntemos a ns1.google.com. De esta forma, evitamos más consultas DNS para tener que resolver también esos nombres de host. Y esta es la primera utilidad de los registros glue.

Ahora supongamos que Google no hubiese creado registros glue para sus NS, volvamos repasar los pasos anteriores para poder resolver www.google.com:

1. Queremos acceder a www.google.com así que le preguntamos a root-servers.net.
2. root-servers.net nos dice que debemos preguntarle a gtld-servers.net ya que es el NS que figura para la zona com y además nos da las direcciones IP de gtld-servers.net.
3. gtld-servers.net nos dice que debemos preguntarle a ns1.google.com ya que es el NS que figura para la zona google.com
4. gtld-servers.net no nos dio la dirección IP de ns1.google.com (no tiene glue record) y nosotros no la sabemos, así que tenemos que inicar otra petición para resolverlo.
5. Pedimos a root-servers.net que nos resuelva el dominio ns1.google.com.
6. root-servers.net nos dice que debemos preguntarle a gtld-servers.net ya que es el NS que figura para la zona com y además nos da las direcciones IP de gtld-servers.net. (= paso 2)
7. gtld-servers.net nos dice que debemos preguntarle a ns1.google.com ya que es el NS que figura para la zona google.com (= paso 3)
8. ... (= paso 4)

Entraríamos en un bucle sin fin, del que sólo salimos si creamos un registro glue para que los servidores raíz conozcan la dirección IP de los NS.

Bien, ¿qué tiene todo esto que ver con el caso de los subdominios falsos en el whois de facebook.com? Pues que son simplemente registros glue. Cuando hacemos una petición a whois por facebook.com sin decirle el tipo, busca en todos los tipos de registro que conoce (nombres de dominio y registros glue) los que empiezan por facebook.com.

Así que estos spammers lo que han hecho ha sido crear subdominios de sus dominios que sean registros glue para que aparezcan en las búsquedas de whois.

Artículo cortesía de Jesús Pérez 

Leer más...

Construyendo un sistema firewall/antispam telefónico

 
¿Cuántas veces os ha sonado el teléfono fijo interrumpiendo la comida, despertándoos de la siesta, o incluso hecho salir del baño porque un sistema de telemárketing "avanzado" llama aleatoriamente tu número para ofrecerte un mejor ADSL, cobertura de noseque seguro, una tarjeta de crédito nueva, o vaya usted a saber?

Bueno pues a mí unas cuantas. Además, desde que tengo la oficina en mi propia casa, es un coñazo soberano la cantidad de molestas llamadas "spam" personas o bots. Antes, tenía un pool de actitudes a tomar cuando recibía estas llamadas, pero ahora, todo esto ha cambiado.

En el móvil, ya instalé una aplicación como la que comentamos tiempo atrás para evitar el Spam via SMS, y para casa, desde que monté una centralita con Asterisk con el ATA Linksys con el que simulaba hacer llamadas como si estuviera en mi casa/oficina, quien contesta las llamadas es el propio Asterisk. He de decir, que lo de las centralitas VoIP es todo un mundo y me ha sorprendido, muy gratamente, la cantidad de cosas que se puede hacer con ellas.

En el briconsejo de hoy, vamos a ver cómo se puede hacer para que sea la propia centralita quien filtre las llamadas, blacklisteando números de teléfono origen de los que no queremos oir hablar.

Dentro del propio interfaz con FreePBX, hay una sección Blacklist, donde se pueden ir añadiendo aquellos números que consideremos molestos.

Incluso, podemos habilitar el check para que bloquee directamente aquellas llamadas con número oculto (ojo si recibís llamadas internacionales, que a veces entran con CallerID oculto).

Por otra parte, y con fines más dinámicos, puede que quiera añadir un número a la blacklist, simplemente usando la línea de comandos que tanto me gusta, o delegarlo como un comando más a mi bot GTalk.

Así que me hice un script, en Perl, que interactúa con el módulo de gestión de la centralita, de manera que pueda pasarle el número de teléfono origen que quiero bloquear.

#!/usr/bin/perl
use Asterisk::AMI;

#Vars Asterisk
my $IP_asterisk="192.168.52.47";
my $peerport_asterisk="5038";
my $username_asterisk="admin";
my $secret_asterisk="esperasentadoqueteladigoeh";
#/Vars Asterisk


        my $astman = Asterisk::AMI->new(PeerAddr => $IP_asterisk,
                                        PeerPort => $peerport_asterisk,
                                        Username => $username_asterisk,
                                        Secret => $secret_asterisk
                                );

        die "Unable to connect to asterisk" unless ($astman);

        my $quehacer=$ARGV[0];
        my $phone=$ARGV[1];

        my $lecommand=undef;

        if ($phone)
        {#Hay un telefono leido
                if ($quehacer eq "block")
                {
                        $lecommand="database put blacklist $phone 1";
                }
                elsif ($quehacer eq "unblock")
                {
                        $lecommand="database del blacklist $phone";
                }
                else
                {
                        die "Usage: $0 <block || unblock> <phone>";
                }

                my $action = $astman->send_action ({ Action => 'Command',
                                                 Command => $lecommand
                                                 });

                my $response1 = $astman->get_response($action);

                print "$response1->{'CMD'}[0]\n";
                #printamos la respuesta
        }
        else {die "Usage: $0 <block || unblock> <phone>";}   

En mi caso, llamando con oculto, el Linksys SPA3102 (recordad que es el dispositivo que me reenvía la señal de línea analógica convertida en VoIP a mi Asterisk) lo que mi centralita ve es SPA, que es el alias que le configuré, por lo que tampoco vale la opción "block" que introducía FreePBX. Si intentas añadir manualmente una entrada identificada con letras, FreePBX comprueba mediante Javascript que sea un número y lo bloquea. Sin embargo la API de Asterisk sí que lo permite.

Hasta ahora, cada vez que me llamaban (e importunaban) apuntaba el número, lo googleaba el número de teléfono y lo guardaba en un fichero de texto. Casi todos hasta ahora han sido de una empresa contratada por Jazztel (pesados!) y Citibank. Investigando por listas de spam telefónico, hay incluso una especie de ranking con teléfonos de mala reputación, al estilo de las listas de reputación IP como las ofrecidas por Alienvault.

Me he hecho otra herramienta que parsea diariamente el listado de "Top spam" ofrecido por la web  http://www.listaspam.com que, diariamente parsea el Top 10 y, si son números de teléfono de España, los blacklistea directamente en mi Asterisk:

#!/usr/bin/perl
use strict;
use LWP::UserAgent;
use Asterisk::AMI;

#Vars Asterisk
my $IP_asterisk="192.168.52.47";
my $peerport_asterisk="5038";
my $username_asterisk="admin";
my $secret_asterisk="esperasentadoqueteladigoeh";
#/Vars Asterisk


my $astman = Asterisk::AMI->new(PeerAddr => $IP_asterisk,
                                PeerPort => $peerport_asterisk,
                                Username => $username_asterisk,
                                Secret => $secret_asterisk
                         );
        die "Unable to connect to asterisk" unless ($astman);



sub blacklistea
{
        my $lecommand="database put blacklist $_[0] 1";
        my $action = $astman->send_action ({ Action => 'Command',
                                         Command => $lecommand
                                                 });

        my $response1 = $astman->get_response($action);

        print "$response1->{'CMD'}[0]\n";
}

#MAIN

my $url="http://www.listaspam.com";

my $browser= LWP::UserAgent->new;
my $response = $browser->get($url);

if ($response->is_success)
{
        my $web=$response->content;

        my @cachos=split (/Top spam<\/p>/,$web);
        my @trozos=split (/\<\/a\>\\<\/ul\><\'item_top\'\>/,@cachos[1]); 
        my @mascachos= split (/Telefono=/,@trozos[0]); 
        @mascachos[0]=undef;
        foreach (@mascachos) 
        { 
              my @trocitos=split(/>/,$_); 
              if ($trocitos[0] =~ /^[6-9]\d{8}/)                 
              {
                  print "$trocitos[0]\n";               
                  blacklistea ($trocitos[0]);                 
              }
        }
 }

Si además queremos poner una grabación personalizada de bienvenida a este tipo de llamadas, podemos hacerlo modificando en el fichero /etc/asterisk/extensions_additional.conf en la sección siguiente

[app-blacklist-check]
include => app-blacklist-check-custom
exten => s,1,GotoIf($["${CALLERID(number)}" = "Unknown"]?check-blocked)
exten => s,n,GotoIf($["${CALLERID(number)}" = "Unavailable"]?check-blocked)
exten => s,n,GotoIf($["foo${CALLERID(number)}" = "foo"]?check-blocked:check)
exten => s,n(check-blocked),GotoIf($["${DB(blacklist/blocked)}" = "1"]?blacklisted)
exten => s,n(check),GotoIf($["${BLACKLIST()}"="1"]?blacklisted)
exten => s,n,Set(CALLED_BLACKLIST=1)
exten => s,n,Return()
exten => s,n(blacklisted),Answer
exten => s,n,Wait(1)
exten => s,n,Zapateller()
exten => s,n,Playback(ss-noservice)
exten => s,n,Hangup

; end of [app-blacklist-check]

En este bloque cambiar la línea  "exten => s,n,Playback(ss-noservice)" por "exten => s,n,Playback(ss-spam)"

Además deberemos tener en formato .sln en el directorio /var/lib/asterisk/sounds/ el fichero "ss-spam.sln".
Para ello, convertir el .wav mediante "sox" así:

sox ss-spam.wav -t raw -r 8000 -s -2 -c 1 ss-spam.sln

Os dejo el que he creado yo para cuando me llama algún pesado desde un número que está en la blacklist:

Leer más...

Spam-IP y su honeypot para Spammers

Spam-IP.com es un sitio web dedicado a informar y luchar contra el Spam.

En su labor de lucha se dedican a mantener una lista de IPs actualizada cada hora que han sido detectadas enviando Spam para que puedan ser incluidas en listas negras, y que distribuyen en formato CSV para su procesado o vía web.

Una de sus fuentes de datos principales es la propia colaboración de los usuarios, que mediante este formulario pueden publicar IPs en la lista.

La otra fuente es de lo más curiosa e innovadora.

El principio es simple. El comportamiento de los Spambots es recorrer internet constantemente en busca de formularios para enviar su Spam.

En Spam-IP han creado un Honeypot que se trata de un formulario cualquiera como los de blogs, páginas de contacto, etc. Cuando un bot envía información en dicho formulario, su IP es automaticamente incluida en la lista.

Por supuesto, si es un usuario normal el que envía información en el formulario, su propia IP quedará incluida en la lista, por lo que NO hay que interactuar con el Honeypot.

Una forma de ayudar al proyecto es incluir un enlace al Honeypot en nuestro sitio web, de forma que el enlace será seguido por los Spambots y éstos podrán ser incluidos en la lista. Cuanto mayor sea el número de enlaces a la dirección en Internet, mayor será la llegada de bots y por lo tanto mayor será la lista de IPs.

Con mucho gusto, desde SecurityByDefault aportamos nuestro granito de arena, por lo que además de escribir sobre ellos, incluimos a continuación un enlace al Honeypot. Recordad que NO se debe interactuar con él.

Un interesante proyecto que esperamos que continúe aportando por mucho tiempo.

Leer más...

Nueva característica de Hotmail para luchar contra cuentas robadas

Si Gmail hace poco introducía medidas para luchar contra la suplantación de direcciones de email, ahora Microsoft ha anunciado una nueva función muy curiosa para usuarios de Hotmail que debería ayudar a luchar contra spammers y fraudes vía email.

Seguro que todos hemos recibido alguna vez un email de un amigo que no teníamos muy claro si era verídico o, por el contrario, había sido enviado por alguien que ha obtenido el control sobre su cuenta.

En muchas ocasiones ocurre lo segundo, bien porque usaba una contraseña débil, bien porque usaba la misma contraseña en múltiples servicios y han comprometido su cuenta en alguno de ellos, o bien porque no le importaba mucho la seguridad de su ordenador.

Por ejemplo, fue sonado un caso de hace unos años, cuando una cuenta de Hotmail de Jack Straw, político del Reino Unido, fue comprometida y envió cientos de emails intentando engañar a sus contactos.

La nueva característica de Hotmail está diseñada para hacer más rápida y fácil la restauración de la cuenta para su dueño.

Cuando un usuario reciba un email de un contacto que indique que la cuenta ha sido comprometida, podrá reportar directamente a Hotmail que la cuenta de su contacto ha sido pirateada.

Además, si se marca un mensaje como basura, también permite reportar que la cuenta parece haber sido comprometida.

Con esta acción, se avisa a Hotmail de que tiene que tomar acciones sobre esa cuenta, al menos para determinar si ha sido comprometida, y en este caso tomar medidas.

Puede pasar que el email llegue desde otro servicio como Gmail o Yahoo!, en ese caso Hotmail promete que enviará el aviso al otro proveedor.

Todo ésto se combina con el sistema de detección que tiene Microsoft aparte, y que intenta detectar comportamientos extraños en las cuentas. Esta información y el reporte se combinan para verificar que, efectivamente, el reporte es verídico. La acción de los usuarios puede ser importante ya que pueden dar una respuesta más rápida que el sistema automático.

Según Microsoft la funcionalidad lleva habilitada sólo durante unas pocas semanas, y ya ha ayudado a identificar y recuperar cientas de cuentas comprometidas.

Además de curiosa, parece una buena idea, siempre que Hotmail tome las medidas adecuadas sobre la cuenta, y siempre verificando que la intrusión se ha realizado y tus amigos no te están gastando una pequeña "broma".

Leer más...

Malditos Spammers

Los spamers están cada día más organizados y la verdad es que hay una verdadera mafia entorno a todo este mundillo. No es ninguna novedad esto que comento, pero la verdad es que es difícil llegar a interceptarlos dado que usan programas que se ‘autoeliminan’ una vez terminada su función.

La forma de trabajo de esta gente suele ser algo así:

• Infectan equipos con troyanos, awares, virus y demás vainas (por los métodos habituales como fallos en navegadores, aceptación de activex no confiables por usuarios confiados, ejecución de programas que no son lo que parecen, etc).
• Esos programas roban contraseñas almacenadas en los equipos, entre otras, las de acceso a servidores FTP, en el caso de que tengas una web (¡quién no tiene una web hoy en día!).
• Teniendo el usuario FTP y el dominio, sólo queda hacer una conexión, subir un script y ejecutarlo vía web.
• El script comienza a mandar mails a diestro y siniestro a una velocidad increíble.
• Termina su trabajo y, en la mayoría de los casos, se autodestruye.

¡¡Cuánto daño se puede en tan sólo unos minutos!! La verdad es que los logs del sistema llegan a asustar cuando algo de esto sucede.

Consecuencias:

• La IP de tu servidor empieza a aparecer en listas de spam, que muchas de ellas tardan 1 mes en borrarte tras enviarles la solicitud (siempre se puede tardar menos si pagas).
• Los servidores más estrictos (como hotmail) te rechazan todos los correos hasta no estar ‘totalmente limpio’.
• Tus clientes no pueden mandar correos y comienzan las quejas y problemas.

Soluciones:

• Desactivar la ejecución de cgis, de perl y de PHP en aquellas cuentas que no sea estrictamente necesario.
• Por supuesto, una buena configuración del servidor SMTP.
• Obligar a tus clientes a cambiar las contraseñas cada X tiempo.

Haciendo limpieza en mi equipo me he encontrado con un backup que hice, hará aproximadamente un año, de unos scripts que intercepté en uno de mis servidores dedicados.

Tras abrirlo en una máquina virtual, sin acceso a Internet, podemos ver un menú (en ruso) que ofrece diferentes opciones:

Buscando información en Google acerca de DirectMailer llegamos a la página web del autor (http://www.yellsoft.net) donde venden este software por 200€ (o $240):

Usando el traductor de Google podemos ver que se trata claramente de un software orientado a envío de spam.

El autor lo describe como un software que permite envío anónimo de correos y, capaz de usar todos los recursos del hardware para realizar su fin. Además, una vez instalado, posee una interfaz gráfica para que, hasta el más lerdo pueda usarlo:

200 euros de programa para que luego me lo dejen gratis en mi servidor. ¡¡Qué detalle!!

Bueno, y ya que han sido tan amables de regalármelo, totalmente gratis, quería compartirlo con vosotros :)

El script principal (dm.cgi) está en Perl y podemos ver varias cosas interesantes:

my %c = (

 ver   => '1.6.8',
 rel   => 'u999999999999',
 path  => $ENV{'SCRIPT_FILENAME'},
 addr  => $ENV{'SERVER_ADDR'},
 name  => $ENV{'SERVER_NAME'},

 mailbase => './upload/mailbase.txt',
 from  => './upload/from.txt',
 replyto  => './upload/replyto.txt',
 subject  => './upload/subject.txt',
 letter  => './upload/letter.txt',
 attach  => './upload/attach.txt',
 proxy  => './upload/proxy.txt',

 dns   => '194.186.45.226',
 threads  => 200,
 timeout  => 5,

 charset  => 'koi',
 mailer  => 'outlook',
 priority => 'normal',

 proxyer  => 10,
 proxycn  => 1,
 proxywr  => 1,
 proxyrd  => 1,
 proxyup  => 30,

 ctime  => 3,
 local  => hostname || 'localhost',

Por un lado, tiene una serie de ficheros TXT de donde coge todos los datos que necesita:

• mailbase.txt: es el listado de víctimas, es decir, todas las direcciones de mail a las que se va a spamear.
• from.txt: contiene una o más direcciones de mail que aparecerán como remitente.
• replyto.txt: donde se quiere recibir respuesta (normalmente coincide con from.txt y es alguna dirección inventada).
• subject.txt: asunto(s) para los mails (ej: vendo viagra! Me la quitan de las manos, oiga!).
• letter.txt: contiene la ruta al fichero con el cuerpo del mensaje.
• attach.txt: yo no tengo ese fichero pero debe tratarse de un listado de adjuntos.
• proxy.txt: tampoco lo tengo, pero debe ser un listado de proxys para poder spamear aún mejor.

Otra cosa que podemos ver es que usa su propio DNS y que arranca, nada menos, que 200 threads para mandar mails simultáneamente.

En los ficheros HTML que aparecen como cuerpo de mensaje podemos ver algunos mails, que seguro que a más de uno le suenan:

^Viagra BEST Viagra^

Aquí va otro:

***Best sex and love***

Si seguimos analizando el script vemos más cosas curiosas, como la capacidad de falsear la fecha del mail, IPs, etc:

$fakedate = $date if $c{'fakedate'} eq 'no';
 $fromname = $replyname = $toname = '' if $c{'exctname'} eq 'no';

 $header =~ s/%FAKENAME%/$fakename/;
 $header =~ s/%FAKEIP%/$fakeip/;
 $header =~ s/%HOST%/$host/;
 $header =~ s/%DATE%/$date/;
 $header =~ s/%FAKEDATE%/$fakedate/;
 $header =~ s/%MESSAGE_ID%/$messageid/;
 $header =~ s/%X_PRIORITYNUM%/$xprionum/;
 $header =~ s/%X_PRIORITYTXT%/$xpriotxt/;

 $header =~ s/%FROMNAME%/$fromname/;
 $header =~ s/%FROMADDR%/$fromaddr/;
 $header =~ s/%REPLY_TONAME%/$replyname/;
 $header =~ s/%REPLY_TOADDR%/$replyaddr/;
 $header =~ s/%TONAME%/$toname/;
 $header =~ s/%TOADDR%/$toaddr/;
 $header =~ s/%SUBJECT%/$subject/;

 $header =~ s/%BOUNDARY%/$boundary/g;
 $header =~ s/%CONTENT_TYPE%/$contenttype/;
 $header =~ s/%CHARSET%/$charset/;
 $header =~ s/%CONTENT_ENCODING%/$contentenc/;

Convierte en base64 los ficheros adjuntos, para mejorar el envío y obtener una mejor visualización:

if ($message =~ /$file/ && $contenttype eq 'text/html') {

    $newcid .= '_csseditor';
    $message =~ s/$file/cid:$newcid/g;

    $attach .= "Content-ID: <" . $newcid . ">\n";
    $attach .= "Content-transfer-encoding: base64\n"; }

   else {

    $attach .= "Content-transfer-encoding: base64\n";
    $attach .= "Content-Disposition: attachment; filename=";
    $attach .= '"' . $fname . '"' . "\n"; } }

  else {

   $attach .= $ctype . ";\n\t";
   $attach .= 'name="' . $fname . '"' . "\n";
   $attach .= "Content-Transfer-Encoding: base64\n";

   if ($message =~ /$file/ && $contenttype eq 'text/html') {

    $newcid .= '@' . $fakename;
    $message =~ s/$file/cid:$newcid/g;

    $attach .= "Content-ID: <" . $newcid . ">\n"; }

   else {

    $attach .= "Content-Disposition: attachment;\n\t";
    $attach .= 'filename="' . $fname . '"' . "\n"; } }

  $attach .= "\n$files{$file}"; }

Creación aleatoria de IPs y fechas, como dije antes:

sub ip
{
 my @ip; for (1..4) { push (@ip, int rand 256); } @_ = ('a'..'z');
 return (join ('.', @ip), join ('', @_[map { rand @_ } (0..((int rand 6) + 2))]));
}

sub date
{
 my $date = localtime (time - int rand shift);

 $date =~ s/^(\w+)\s+(\w+)\s+(\d+)\s+(\d+:\d+:\d+)\s+(\d+)$/$1, $3 $2 $5 $4/;

 my %month = (Jan=>'01',Feb=>'02',Mar=>'03',Apr=>'04',May=>'05',Jun=>'06',
 Jul=>'07',Aug=>'08',Sep=>'09',Oct=>'10',Nov=>'11',Dec=>'12');

 my $time = $5 . $month{$2} . (sprintf "%02d", $3) . join ('', split (':', $4));

 return ("$date " . &gmtdiff, $time);
}

Todo ello sumado a un buen control de envío, discriminando los que se han conseguido mandar, los incorrectos y los que, no hubo mucha suerte:

my ($mx, $err) = &getmx($domain);
  unless ($mx)
  {
   &chgsta(4=>1);
   &log("<$addr>\x01" . $err);
   &bad($line);
   next;
  }

  if ($mx =~ m!^\d$! && $mx == 1)
  {
   &chgsta(3=>1);
   &log("<$addr>\x01" . $err);
   &unlucky($line);
   next;
  }

  my ($sock, $resp, $proxy);

En la carpeta sys nos encontramos con una colección bien estructurada de ficheros MX, para una mejor resolución de dominios:

La verdad es que merece la pena echarle un ojo a este tipo de programas ya que te das cuenta de cómo se lo curran para vendernos viagra y otros menesteres. Y es por ello que os dejo una copia de los scripts por si queréis analizarlos. Los podéis bajar aquí: spam_scripts.tar.gz

Un saludo.

----------------------------------

Contribución por Pepelux

Leer más...

¿Vuelos low-cost, seguridad low-cost?

<Disclaimer: Las acciones que se deriven de la lectura de este post son de tu completa responsabilidad. No se incita a cometer ningún tipo de ilegalidad>

La semana pasada tuve <IRONIC> la grata experiencia de repetir viaje en una de mis líneas aéreas favoritas: Ryanair </IRONIC> o Ryanfail, como lo bauticé tiempo atrás en "El Sumidero".

Lo más importante es que lleves la tarjeta de embarque impresa, si no te dejarás una pasta en que te la impriman en el aeropuerto. Para ello, lo más normal es irse a la web de gestión de reservas y curiosamente fue ahí empieza a verse el tinte lowcost de esta aerolínea:

1.- Fácil deducción en validación de usuarios para gestión de reservas

Para poder gestionar la reserva, se nos pide seleccionar una de las diferentes opciones de "seguridad":

• Localizador + código de tarjeta de crédito
• Localizador + correo utilizado + origen + destino
• Fecha de salida + correo utilizado + origen + destino
  

Está claro que el localizador, sólo lo sabe el que hizo la reserva y aunque son "sólo" 5 caracteres alfanuméricos, hay una opción mejor para juguetear. Sin embargo, en caso de conocer la fecha de vuelo, origen, destino y uno o varios correos de un individuo, Ryanair lo da por suficiente como para permitir la gestión de la reserva... OMG!

Supongamos que conocemos a algún amig@/conocid@, del que conocemos su correo electrónico, que va a volar con Ryanair. Muy posiblemente sepamos el día que se va (si es usuario muy activo de twitter a lo mejor sí), o al menos de dónde sale/dónde va. Gracias a las preguntas de seguridad low-cost de la web de Ryanair, es posible hacer un ataque de fuerza bruta para despejar la incógnita que nos falte y acceder a los datos de la reserva sin mayor problema.

Podemos hacer ataques de fuerza bruta acotados sobre la fecha o destino; probablemente el origen lo sepamos o podamos deducir. De esta manera, se puede ver/cambiar (previo pago) los datos personales de pasajero (y sus acompañantes), localizador y modificación de datos de alquiler de coche (en caso que lo hayas hecho). Vamos, que puedes dejar sin viajar ese día a es@ "amig@" por un módico precio.

Este "pequeño" problema se mitigaría para alguien que no conociese todos los datos del problema, mediante la implantación de Captchas, mecanismo que hemos recomendado en más de una ocasión en SbD, o mediante un WAF que permita crear reglas de bloqueo por cada X intentos fallidos.


Gracias a Inr0m por su colaboración con las pruebas para este punto (tenía un billete en Ryanair próximamente y lo prestó para las pruebas).

2.- Versión de servidor web Apache muy antigua

Con hacer una simple petición web vía línea de comandos se observa que la versión utilizada es Apache 2.2.9 (publicada en Junio de 2008). Mirando las vulnerabilidades corregidas se puede comprobar que lo más probable es que sea vulnerable al bug de la renegociación SSL.

Como bien detalló Yago allá por Noviembre de 2009, si el servidor web permite renegociar la sesión SSL, bajo ciertas condiciones, podría permitirse a un atacante inyectar texto en el tráfico cifrado entre el cliente y el servidor.

# openssl s_client -connect www.ryanair.com:443
CONNECTED(00000003)
depth=1 /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
verify error:num=20:unable to get local issuer certificate
verify return:0
---
Certificate chain
0 s:/C=IE/ST=Co Dublin/L=Dublin Airport/O=Ryanair Ltd./OU=MIS/OU=Terms of use at www.verisign.co.uk/rpa (c)05/OU=Authenticated by VeriSign/OU=Member, VeriSign Trust Network/CN=www.ryanair.com
....

.....
---
New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
Secure Renegotiation IS NOT supported
SSL-Session:
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: 61A48C7FBDC41EEE55E51C17DD3800ADC336169BB9077019D271980C90862D00
Session-ID-ctx:
Master-Key: 734E373B5CAA8CDC722F1EDA14157FC2B823197F4B11966D7713891C35E1E88497429E37415271C654105AB903946069
Key-Arg : None
Krb5 Principal: None
Start Time: 1274807031
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---

Pulsamos R para renegociar y....

R
RENEGOTIATING
depth=1 /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
verify error:num=20:unable to get local issuer certificate
verify return:0

Re-negociación exitosa!

La verdad es que nada más sentarte en el avión, sólo rezas porque no se hayan ahorrado medios en la formación de los mecánicos, pilotos y mantenimiento en general, como en la seguridad de la web y te preparas para recibir una gran dosis de continuo spam.

Leer más...