31 mayo 2011

$Internet = $Internet - "Irán";

A nadie le sorprenderá que diga que la sociedad del mundo árabe está revuelto, en los últimos meses. Que gracias fundamentalmente a las redes sociales, Facebook y Twitter, pudieron organizarse las revoluciones populares que comenzaron en Túnez, siguieron en Egipto, Bahrein, Siria, Libia, etc, etc… y los telediarios nos siguen recordando a día de hoy que todavía hay bastante lío en Yemen.

En España el movimiento #nolesvotes, #democraciarealya, así como las diversas #acampadas en diversas ciudades españolas se han podido producir con una excelente organización gracias a Internet. Los gobiernos están viendo en la "libertad" de Internet, cada vez más, un peligro que no pueden controlar. Bueno, espera, sí que intentan hacerlo mediante las leyes Sinde y la última brillante idea de Leire Pajín: "La Ley de Igualdad de Trato" con el que los administradores de los blogs tendremos que contratar un abogado antes de moderar o no un comentario.

Con motivos supuestamente anti-ciberterroristas, la administración Obama proponía la elaboración de un proyecto de ley que ofreciese la posibilidad de poder tener el control de controlar Internet cerrando webs, o incluso todo Internet. Y el que no se lo crea, que le pregunte a Julian Assange y el entorno Wikileaks si cuando la "seguridad nacional" sale a relucir, se hace todo lo posible para censurar el disclosure de información que no les conviene, con medios poco o nada éticos.

Tiempo atrás ya mencionábamos en SbD cómo las ansias por querer tener el control del tráfico de red en Arabia Saudí, incluso llevó a la distribución de spyware en una actualización de Blackberry, o cómo en China fuerzan a sus usuarios a atravesar a través del Gran Cortafuegos Chino.

Me he quedado perplejo cuando he leído en Wwwhatsnew, en newser, y en muchos otros medios de divulgación de noticias, el caso de Irán y como su gobierno, en base al concepto de "guerra suave" propuesto por el Ayatollah Ali Khamenei, han ido "one step ahead" y, han propuesto directamente, que sus usuarios no se conectarán nunca más a Internet. Sí, sí, leéis bien; Si tenéis alguna máquina en un hosting iraní, id haciendo un backup del mismo, porque según las ideas de este gobierno, de aquí a un tiempo, dejaréis de tener acceso. 

La idea es crear una red similar a Internet, autónoma en sí misma, que conectará de forma obligatoria a sus usuarios. Por supuesto, esta red podrá ser manipulada y monitorizada por el propio gobierno a su criterio y conveniencia. La excusa esta vez es la de distribuir contenidos más acordes a la moral islámica que lo que se puede encontrar en Internet, canal por el cual entran rumores y mentiras.

En el momento en el que haya una iniciativa #novotesalúnico o un #acampadaTeherán, alguien podrá apretar un botón rojo y los iraníes tendrán que comunicarse con señales de humo. El despliegue de dicha red, se efectuará de forma paralela a lo que actualmente conocemos como Internet y llegará un momento en el que sólo se podrá utilizar la nueva red.

Ya en la revuelta de Egipto, el gobierno de Hosni Mubarak, desconectó los ISPs de Internet y los servicios de ADSL, para evitar que los ciudadanos pudiesen organizarse y convocar las protestas mediante Facebook y Twitter por ejemplo.

Supongo que en el caso de Irán, finalmente exisitirán gateways para interconectar todo el tráfico de "Iránnet" con "Internet", evidentemente con todos los mecanismos que posibiliten la censura. ¿Os imagináis tener que volver a antes de los 90 utilizando cartas con sellos, faxes para las transacciones comerciales,…? ¿Cómo afectará este nuevo paso por el control sobre los usuarios iraníes, en las relaciones comerciales y las comunicaciones entre Irán y el resto del mundo? 

Por si acaso, haced vuestros pedidos de caviar iraní cuanto antes, no sea que luego, limiten la exportación del número de latas :D
Leer más...

30 mayo 2011

Monitorizando La Ley Sinde - ¿Hasta donde pueden llegar?

¿Podrá Sinde cerrar SeriesYonkis? ¿Y SeriesPepito? ¿Y las más de 500 páginas similares? ¿Como está afectando la nueva ley a estos sitios de enlaces? ¿Qué medidas se pueden tomar? ¿Las han tomado ya? Estas son algunas de las preguntas que quiero contestar en esta entrada. Tal vez sea demasiado ambicioso por mi parte intentar dar una respuesta exacta a todas ellas, pero seguro que alguna duda se aclara.

Usando el magnífico Manual de desobediencia a la Ley Sinde, publicado por el colectivo hacktivistas.net con la colaboración de Traficantes de Sueños. He sacado algunos puntos de control y añadido alguno más, para saber que impacto real puede tener esta ley hoy por hoy en nuestra cultura.

Las medidas que hacktivistas.net propone a los webmasters se resumen en:
  • Utilizar un hosting fuera de España: ya que sobre los nacionales pueden intervenir fácilmente. 
  • No usar registradores españoles: sobre los que podrán tomar acciones para suspender el dominio.
  • Compartir servidor: porque cerrando nuestra web, cerrarán otras colateramente que tienen derechos fundamentales
  • Web Social: donde se reúna una comunidad, de esta forma no se puede cerrar ya que se estará violando una ley fundamental: la libertad de expresión.
  • Pagos Anónimos: para que el dinero no pueda ser investigado.
También comentan que Estados Unidos tiene leyes incluso más duras que las nuestras y no debería ser una alternativa a la que migrar.

De todas ellas he descartado la parte de compartir servidor, crear una web social y los pagos anónimos, añadiendo dos puntos que considero más fáciles de ser intervenidos y con los que también tendría completa efectividad la censura:
  • Utilizar servidores de nombre fuera de España: para que no puedan modificar nuestro DNS. No sirve de nada alojar y comprar el dominio fuera, si luego el DNS se gestiona en España.
  • No utilizar dominios .es: porque podrán gestionar con NIC.es todo lo necesario para robarnos el nombre sin problemas.
Es decir, que la infraestructura de la web no tenga absolutamente nada que ver con España. Una vez identificados, elaboramos una lista con más de 500 páginas que almacenan enlaces a todo tipo de contenido, como series, películas o libros.

Para el estudio he hecho un script que adjunto y no descarto volver a ejecutar el año que viene, a ver cual es la situación pasado un tiempo. También puede servir para añadir otros dominios que no haya contemplado.

La herramienta genera un XML con todos los datos (resultado) para su procesado automático (yo he usado Excel) y un archivo de texto inteligible (resultado). Tal y como se muestran las imágenes siguientes.

Ejemplo de un trozo de XML generado

Un trozo del log generado

Una vez con los datos procesados saco algunos números.

Estados Unidos aloja 217 servidores web y España 156, en total 373 dominios que podrían ser cerrados rápidamente si reciben notificación los proveedores.


Con los DNS ocurre algo similar. Ojo, que los números pueden engañar, hay que pensar que cada dominio tiene más de un servidor. Unos están alojados fuera, otros dentro. 793 en Estados Unidos y 179 en España.


Como sabemos todos el DNS es un árbol y todos los dominios con el TLD ".es", dependen y son gestionados por nuestro NIC, que podrá bloquearlo, eliminarlo o hacer lo que quiera con ellos. Aquellos que tengan su nombre únicamente con esta extensión, ya deberían estar migrando.


El análisis automático de los registradores es más complicado, son nombres de compañías y las únicas pistas que tenemos para identificar su origen (sin consultar otros servicios) es ver si se componen con "S.L", "S.A" o por el contrario son "INC" y similares. A simple vista queda claro que la empresa de Estados Unidos "GoDaddy" es la gran vencedora con 79 dominios. 


¿Los resultados finales? Terribles. El 41% de las páginas podría ser cerrado sin esfuerzo o dicho de otra forma: Sindeables. Ya que tienen alguna parte de su infraestructura dependiente de este nuestro querido pais.


Todos aquellos webmasters que necesiten ayuda técnica, consejos o aclaraciones, pueden dejar un comentario y trataré de facilitarles toda la información posible.

Para finalizar adjunto el script:

#!/usr/bin/python

import GeoIP
import dns
import dns.resolver
import fileinput
import pywhois
import chilkat

gi = GeoIP.open("/usr/local/share/GeoIP/GeoIP.dat",GeoIP.GEOIP_STANDARD)

f = open("lista-sinde.txt")
xml = chilkat.CkXml()
xml.put_Tag("lista-sinde")


for dom in f:
   rega = 0
   regns = 0
   dom = dom.rstrip("\n")
   domixml = xml.NewChild("dominio","")
   domixml.AddAttribute("nombre",dom)
   domname = domixml.NewChild("nombre",dom)
   print dom
   print "-------------------"
   # ip y localizacion hosting de "www"
   try:
    answers = dns.resolver.query("www."+dom, "A")
    for rdata in answers:
          ip = str(rdata.address)
          countryip = gi.country_name_by_addr(ip)
          ipwww = domixml.NewChild("WWW",countryip)
          ipwww.AddAttribute("ip",ip)
          print "Registro A: %s Pais: %s" % (ip,countryip)
          if countryip == "Spain":
                rega = 1
   except:
        next
   # servidores de nombre
   try:
      answers = dns.resolver.query(dom, "NS")
      for rdata in answers:
          ns = str(rdata)
          countryns = gi.country_name_by_name(ns)
          ipns = domixml.NewChild("NS",countryns)
          ipns.AddAttribute("host",ns)
          print "Registro NS: %s Pais: %s" % (ns,countryns)
          if countryns == "Spain":
                regns = 1
   except:
        next
   # registrador
   try:
     w = pywhois.whois(dom)
     regis = domixml.NewChild("Registrador",w.registrar[0])
     print "Nombre del registrador %s" % w.registrar[0]
   except:
     next
   # si es o no un ".es"
   if dom[-3:] == ".es":
     tld = "Si"
   else:
     tld = "No"
   tldxml = domixml.NewChild("TLD Espanol",tld)
   print "TLD Espanol: %s" % tld

   # Conclusion
   if regns == 1 or rega == 1 or tld == "Si":
     conxml = domixml.NewChild("Sindeable","Si")
     print "Sindeable: Si"
     print "===================\n\n"
   else:
     conxml = domixml.NewChild("Sindeable","No")
     print "Sindeable: No"
     print "===================\n\n"
xml.SaveXml("lista-sinde.xml")

Leer más...

29 mayo 2011

Enlaces de la SECmana - 73

Leer más...

28 mayo 2011

Tor en Android con Orbot, proxy incluido y sin root

Ya vimos como hacerlo en iPhone, y ahora es el turno de Android. Hay muchos, muchos artículos en Internet que dan la noticia "Orbot, por fin Tor en Android", pero no he encontrado ninguno en el que se recoja de forma convincente la configuración necesaria. En la mayoría se recurre a programas que necesitan un dispositivo "rooteado" para poder configurar el proxy local y enrutar las conexiones a través de Tor.

Para quien no lo sepa, Orbot es la implementación oficial de Tor para Android. En el propio asistente de configuración de Orbot podemos, si tenemos el dispositivo rooteado, darle al programa la capacidad para que gestione la configuración y que ésta sea bastante más completa.

Lo que vamos a ver no necesitará root ni programas externos, y podremos enrutar toda la navegación a través de Tor. Es importante comentar que sólo lo he probado mediante Wi-Fi, ya que no dispongo de 3G. La versión de Android es la 2.2 Froyo.

En primer lugar iniciamos Orbot, que nos abrirá dos puertos locales. El 8118 con un proxy HTTP y el 9050 con un proxy SOCKS.


Para continuar abrimos la configuración de Wi-Fi, una vez ahí pulsamos la tecla de Menú y vamos a la configuración avanzada para configurar el proxy de la siguiente manera.


Abrimos el navegador estándar de Android para verificar que navegamos a través de la red Tor ...


¡Y ya está hecho!

Hay que tener cuidado ya que parece que no todas las aplicaciones hacen caso de la configuración de red general. Si probamos navegar a través de Opera Mini o Dolphin (por cierto, excelente navegador) no nos enrutan vía Tor. Captura de ejemplo en Dolphin:


Si bien la configuración del proxy de la red está un poco escondida, una vez encontrada no tiene mayor dificultad.
Leer más...

27 mayo 2011

El archivo de localización "cells.plist" de IOS3

Pese a que el tema de la localización que se publicó hace unos meses en IOS4 ya está un poco trillado. He querido portar el script de juanito para las versiones anteriores y de las que no se ha hablado tanto, además creo que no hay ninguna aplicación que lo haga hasta la fecha.

La diferencia principal entre los teléfonos con IOS4 (iPhone 3GS o iPhone 4) y los que llevan versiones IOS3 es que este fichero no se almacena en el ordenador cuando se realiza una copia de seguridad de iTunes, además de no estar accesible para el usuario si el móvil no tiene jailbreak.

En la nueva versión este fichero de tipo binario "plist", pasó de ser "/private/var/root/Library/Caches/locationd/cells.plist" al sqllite de nombre "consolidated.db".

El script en cuestión, para el que hace falta tener biplist y pymaps instalado:

from biplist import *
from PyMaps import Map, PyMap
from datetime import datetime
NewMap = Map()
NewMap.zoom = 3
try:
    plist = readPlist("cells.plist")
    for v in plist.values():
        print v
        a, latitud, longitud, d, f, appledate = v.split(",")
        appledate = int(float(appledate))
        tstamp = appledate + 978307200
        tstamp = str(datetime.fromtimestamp(int(tstamp)))
        pointhtml = tstamp
        point = (latitud, longitud, pointhtml)
        print "La lat es %s, y la long es %s el dia %s" % (latitud,longitud,tstamp)
        NewMap.setpoint(point)
        gmap = PyMap(key="clave", maplist=[NewMap])
        mapcode = gmap.pymapjs()
    showhtml = gmap.showhtml()
    print showhtml
    file = open('Coordenadas.html', 'w')
    file.writelines(showhtml)
    file.close()
except (InvalidPlistException, NotBinaryPlistException), e:
    print "Not a plist:", e


El resultado es muy poco fiable, ya que este trazado me pertenece a mí y ahí se marcan sitios que no he visitado (15km de error):


Leer más...

26 mayo 2011

Recopilación de los ataques a Sony

Tras más de un mes esperando al momento adecuado para hablar sobre todo lo que estaba ocurriendo, en vez de un post, deberíamos haber dedicado una wiki única y exclusivamente a todos los problemas de seguridad a los que se está enfrentando Sony, y todo lo que le rodea, durante este último mes.

Podríamos decir que hemos llegado a unos 10 incidentes a fecha del 25 de Mayo, y viendo la tendencia de intrusión/deface/fuga de información diaria, es hora de parar, recopilar, diferenciar y concluir. Esto se está convirtiendo en una especie de MOSB (Month Of Sony Bugs), iniciativas tan de moda en los últimos años. Todos sabemos como comenzó todo (más o menos), pero quizás estos incidentes contra Sony ahora están teniendo tanta repercusión mediática debido a la gran incidencia ocurrida en su PlayStation Network.

Dejamos por tanto un listado de los incidentes, incluyendo fechas por orden cronológico (no de la propia intrusión, si no de publicación de las primeras informaciones acerca del hecho en sí), en qué ha consistido, autoría de la intrusión y algunos comentarios al respecto. Veréis que la lista contiene 11 puntos, y todo el mundo contempla 10 (¿no os suena a resultado deportivo de Malta y España?) pero ahora entenderéis el por qué he decidido añadir un punto más:

(1) Intrusión en Sony PlayStation Network

[2 de Mayo de 2011] Aún sabiendo que la intrusión se pudo realizar a mediados de Abril, y tras profundas investigaciones (se ha determinado incluso que el ataque fue realizado utilizando los servicios de Amazon EC2), se notifica el compromiso de la red de PlayStation Network, con más de 77 millones de cuentas de usuarios que podrían haber sido obtenidas. 

La noticia da la vuelta al mundo, Sony está en el candelero, comienzan las teorías sobre la información incluida en dichas cuentas (datos de tarjetas de crédito, etc), a quién se atribuye el ataque (como no, Anonymous queda en el punto de mira inmediatamente), posibles logs de IRC comentando la jugada... Lo que está claro es que todo esto fue posible por no tener servidores y servicios actualizados a sus últimas versiones.

(2) Intrusión en Sony Online Entertainment



[2 de Mayo de 2011] Seguidamente se informa de la obtención de 25 millones más de cuentas de usuarios por una intrusión en otra comunidad online de jugadores, Sony Online Entertainment. Aunque se atribuía como ataque a raíz de la primera intrusión a la PlayStation Network, se aclara que ambos servicios se encuentran en ámbitos diferentes, por lo tanto, deben tratarse como hechos aislados técnicamente.

Además de los millones de usuarios, se confirma que se tendría acceso a más de 12,000 datos de tarjetas de crédito de los usuarios. Los titulares en la prensa cambian el mensaje, y ahora ya se habla de la fuga total de 100 millones de usuarios, uniendo ambos incidentes. La bola ya es gigante, toda la comunidad está cabreada, bajan las acciones de Sony (que luego reflotan debido a las ruedas de prensa que ofrece la compañía a raíz de los ataques) y ya es imposible pensar que puede ocurrir algo más...Pero sí, comienza una oleada que comparte objetivo (SONY) pero difiere en muchos otros aspectos que veréis a continuación.

(3) Deface a Sony BMG Greece

[5 de Mayo de 2011] Tímidamente, se publica en el portal Zone-H, en la sección Archive encargada de recopilar defaces a webs, un ataque deface a Sony BMG Greece cuya direción es sonyMusic.gr. Un usuario llamado b4d_vipera es el autor. Y digo tímidamente, ya que esta incidencia tiene poco eco, sobretodo con la bola que ya había formada por la grandísima fuga de información y la necesidad de recuperar el servicio cuanto antes. 

No trasciende más allá de la modificación de la página, por lo que dicha notificación se pierde entre los ataques masivos que recopila Zone-h diariamente.

(4) Ficheros con información sensible en products.sel.sony.com

[5 de Mayo de 2011] El portal de seguridad The Hacker News, recibe en exclusiva un correo electrónico de un usuario, en el que se dan varios enlaces directos a ficheros albergados dentro del subdominio de Sony products.sel.sony.com, que contienen información sensible de usuarios. Mediante unas búsquedas típicas de documentos ofimáticos en Google (site:products.sel.sony.com filetype:xls), es posible ver dicha información directamente como resultados de Google. ¿Robots.txt? ¿Para qué?

Sony reacciona publicando una nota de prensa en la que se informa de la eliminación de dichos ficheros del servidor. No es un hack como tal, ya que la información era perfectamente pública en sus propios servidores, pero aún así Sony se refiere a la información como "datos robados por hackers" (no comments...). Aprovechan la nota de prensa para comentar que se retrasa la restauración del servicio PlayStation Network.

(5) Robo de cuentas mediante sistema de recuperación de cuentas de PlayStation Network recién restaurado

[17 de Mayo de 2011] Tras todo tipo de informaciones acerca de la intrusión en la red PlayStation Network, estudios, infografías, análisis de varias empresas, etc, por fin parece que se restablece el servicio. El mensaje de Sony fue claro desde el principio: "Es conveniente que todos los usuarios cambien sus contraseñas de acceso al servicio". Por lo tanto, se puso en línea un formulario para la restauración de las cuentas. 

Duró unas horas, ya que se evidenciaron fallos de diseño de la aplicación de recuperación de contraseñas que permitirán el robo de sesiones de usuarios por otros. Sony se vió obligada a cerrar dicho servicio online, avisando a sus usuarios que tendrían que realizar el proceso mediante sus consolas PS3, hasta que se restaurase el servicio.

(6) Phishing en Sony Tailandia

[19 de Mayo de 2011] La compañía de seguridad F-Secure informa en su blog de que habían encontrado una página de phishing alojada en el servidor de la página de Sony Tailandia, con dominio sony.co.th. La página de phishing emulaba la web de una compañía italiana de tarjetas de crédito llamada CartaSi. Tras informar a Sony, esta bloqueo el acceso a la url. Otro dolor de cabeza, a saber como habría llegado esa página ahí, cuanto tiempo llevaba, alcance del ataque...

(7) Acceso a cuentas de So-Net Entertainment y robo de dinero virtual

[20 de Mayo de 2011] Una de las compañías subsidiarias de Sony en Japón, So-Net Entertainment, es comprometida. El ataque da lugar al robo de puntos utilizados para el canjeo de productos (denominados so-net points) de 128 usuarios y acceso a casi la mayoría de sus cuentas de correo electrónico. En dicho servicio existe la posibilidad de contar con dinero virtual. 

Se informó que además de a las cuentas, y el acceso a los correos electrónicos de la mayoría de ellas, se consiguió obtener más de 1200 dólares en dinero virtual. Un portavoz de So-Net confirma que este incidente no tiene nada que ver con lo ocurrido anteriormente, pero claro...ahora el punto en común es que, de nuevo, el nombre/marca de Sony se volvía a citar, así que un palito más.

(8) Deface a Sony Music Indonesia

[21 de Mayo de 2011] Volvemos a los defaces, esta vez viajamos a Sony Music Indonesia (www.sonymusic.co.id ), cuya página fue modificada por k4L0ng666. Al parecer es un simple deface, que quizás hace un año hubiera pasado bastante desapercibido como la cantidad de defaces que se reportan y archivan en Zone-H...pero estábamos hablando de una nueva vuelta de tuerca a algo relacionado con la marca Sony, otra vez.

Todo vale ya: red de usuarios, proveedor de servicio, portal musical, comunidad online de jugadores...Ya eran casi 4 días consecutivos de incidencias de seguridad en algo que llevaba la palabra "sony" como parte de un dominio, y se empezaba a convertir en una rutina diaria. Obviamente estos ataques no tienen la misma importancia que los iniciales, en el que los usuarios afectados alcanzan las 8 cifras, pero la imagen queda por los suelos y la mofa es generalizada.

(9) Publicación de información del hack a Sony BMG Greece

[22 de Mayo de 2011] ¿Recordáis el deface a Sony BMG Greece del punto (3)? Al parecer no fué solo un deface. Tras semanas, y con la consiguiente publicación de información acerca del ataque en un texto subido a pastebin, se determina que hubo una intrusión en toda regla, con la obtención mediante inyección SQL de más de 8000 usuarios registrados en el portal. 

De nuevo, se supo de la existencia de estos datos en el servidor de pastebin debido a que el autor del deface, b4d_vipera, contactó directamente con el portal The Hacker News.


(10) Inyección SQL en Sony Music Japan

[23 de Mayo de 2011] El grupo de hacking de moda, Lulzsec (los mismos que mencionamos en los enlaces de la SECmana 71 por publicar información de Fox.com y de los candidatos al X Factor de Estados Unidos) publica datos de otro portal de Sony, Sony Music Japan - sonymusic.co.jp, anunciando el volcado de información en pastebin mediante su cuenta de twitter.

No ofrecen datos concretos de usuarios como en otras ocasiones, únicamente tablas y columnas, además de las páginas vulnerables mediante inyección SQL y parámetros afectados, para obtener todo el contenido de base de datos. En bandeja, para el disfrute del personal.

(11) Inyección SQL en eShop de Sony Ericcson Canada

[24 de Mayo de 2011] La última de la que se tiene constancia en el momento de escribir este post, la tienda electrónica de Canadá de la linea de productos Sony Ericcson de Sony (aplicación alojada en ca.eshop.sonyericcson.com), fue comprometida por un usuario llamado Idahc, y con ello, cuentas de usuario registrados en la tienda. El propio autor confirmó que podría haber obtenido información más valiosa, como datos de tarjetas de crédito, pero que no se considera un hacker malo.

De nuevo, una inyección SQL muy simple que permite la obtención de cualquier dato de la base de datos. El propio Idahc publica en pastebin (información ya retirada) una pequeña muestra de los datos obtenidos, incluyendo hashes de contraseñas de los clientes, e-mails y sus nombres completos.

------

Sacad vuestras propias conclusiones, pero es que parece como si se estuviera jugando al Risk con Sony, y diferentes grupos o individuos con nicks que alternan letras y números, conquistando sus países día tras día. Muchos piensan que el establecer a Sony como un objetivo comenzó con la publicación del grupo fail0verflow de la grave vulnerabilidad en el sistema de seguridad de la PlayStation 3 en la pasada 27C3, o la posterior persecución a George Hotz "GeoHot".

Lo que está claro es que Sony debería hacer una recopilación de todo sitio web que tenga su marca en internet, sea portal musical, productora, club de fans o tienda de golosinas, y comenzar u ordenar diferentes revisiones de seguridad. Es algo imposible, pero debido a colocarse ya en el punto de mira tanto de medios de comunicación como de hackers/crackers/defacers, además de técnicamente, el daño que se le está haciendo es ya a nivel de marca, y seguro que eso a ellos les está doliendo mucho más.

El atacar cualquier página relacionada con Sony ya se ve como una manera de obtener fama por parte de pequeños grupos, así que quizás podamos esperar más pequeños ataques durante los próximos días.
Leer más...

25 mayo 2011

Hace unos días AegisLab detectó en el market de Android una nueva amenaza camuflada en aplicaciones de terceros. El malware (en esta ocasión apodado zsone por ser el pseudónimo del autor que desarrolló las aplicaciones, yo le he llamado Cudeiro en honor a Chino Cudeiro) se caracteriza por enviar sin el consentimiento del usuario mensajes de texto a servicios de suscripción en China.

En esta ocasión además de centrarnos en el análisis estático del malware, vamos a ver algunas utilidades que integra el emulador del SDK de Android, además de otras bien conocidas que nos facilitaran la tarea en el análisis dinámico.

Adentrándonos en el reversing

El procedimiento por el que vamos a guiarnos para hacer el análisis estático será el mismo al que estamos acostumbrados, primero dex2jar para obtener los ficheros de clase y posteriormente jd-gui para leer los ficheros con extensión .class.

Posteriormente para el análisis dinámico vamos apoyarnos de utilidades como monkey, tcpdump, logcat y wireshark para observar el comportamiento de la aplicación.

Análisis estático

Las apks infectadas han sido varias, nosotros trabajaremos con iCalendar (md5: acbcad45094de7e877b656db1c28ada2) que presenta el siguiente AndroidManifest. Solicitando permisos como android.permission.SEND_SMS y android.permission.RECEIVE_SMS.

De su estructura de clases obtenida, destacamos los ficheros SmsReceiver y iCalendar como los principales contenedores de código malicioso.
El funcionamiento del malware es muy básico, por un lado la primera parte la podemos resumir así:
  • Una vez iniciada la aplicación tras hacer una carga de cinco imagenes el método ShowImg hace una llamada a SendSms
  • SendSms recoge el valor del fichero XML que se crea de comprobación y comprueba si el SMS de suscripción ya ha sido enviado.
  • Si el SMS no ha sido enviado crea una instancia de SmsManager y se pasa como atributos entre otros, el número premium 1066185829 y el mensaje de texto 921X1.
  • Acto seguido se llama al método save() para que cree un fichero XML donde almacene el string Y que sirva de comprobación para no volver a enviar el SMS de suscripción

Por otro lado con el método onReceive el teléfono se queda monitorizando todos los SMS entrantes a la espera de recibir uno procedente de 10086, 10000, 10010, 1066185829, 1066133, 106601412004 que indique que la suscripción al servicio premium ha sido realizada con éxito, estos mensajes nunca serán mostrados al usuario. De forma que el proceso se ejecute en todo momento en un segundo plano.


 Investigando los parámetros que son enviados al método sendTextMessage averiguamos que el número pertenece a la compañía China Telecom y su procedencia está asociada a la ciudad costera de Zhejiang.



Análisis dinámico

Nuestra intención en esta etapa será recabar la mayor cantidad posible de información enviada por nuestro teléfono. Utilizando para ello:
  • tcpdump Para obtener en un pcap la actividad que realice nuestro teléfono interna y externamente
  • monkey Para simular actividad falsa en la aplicación y ver cómo se comporta esta
  • Wireshark Para analizar el pcap obtenido con tcpdump y obtener las evidencias buscadas
A veces, en situaciones no tan esclarecedoras podemos guiarnos de utilidades que nos realicen Diffs del sistema momentos previos y posteriores a la instalación de la aplicación. Simular el envío de mensajes de texto, llamadas de teléfono, cambiar nuestras coordenadas o simular conectarnos a una nueva red. Son sólo algunos ejemplos.

Nosotros comenzaremos automatizando el proceso y levantamos el emulador junto a tcpdump con el fin de realizar lo anteriormente descrito.

sebas@Helios:~/Android/sdk/tools$ ./emulator -port 5560 @Cudeiro-Malware -tcpdump cudeiro.pcap 

Instalamos la aplicación en el teléfono:

sebas@Helios:~/Android/sdk/platform-tools$ ./adb install ~/Android/infected/iCalendar.apk 
1278 KB/s (782964 bytes in 0.597s) 
pkg: /data/local/tmp/iCalendar.apk 
Success 

Creándose la siguiente jerarquía de directorio:

# cd com.mj.iCalendar 
# ls 
lib 

Si utilizamos monkey para simular actividad en el teléfono podremos ver el comportamiento que tiene el malware, para ello hacemos uso de:

sebas@Helios:~/Android/sdk/platform-tools$ ./adb shell monkey -v -p com.mj.iCalendar 1000 > ~/Escritorio/monkey-report 

La actividad simulada podéis revisarla aquí. Comprobemos si ha habido algún cambio en los ficheros del teléfono:

# sebas@Helios:~/Android/sdk/platform-tools$ ./adb shell 
# cd data/data/com.mj.iCalendar 
# ls -l 
drwxrwx--x app_32   app_32            2011-05-12 14:05 shared_prefs 
drwxrwx--x app_32   app_32            2011-05-12 14:05 cache 
drwxr-xr-x system   system            2011-05-12 13:44 lib 
# cd share* 
# ls -l 
-rw-rw---- app_32   app_32        148 2011-05-12 14:05 iBookT.xml 
# cat i* 

Contenido de iBookT.xml

Vemos que han creado nuevos directorios y ficheros, entre ellos un xml, y en su contenido hay algo que llama la atención, el string Y es lo que comentábamos antes que era usado para evitar reenviar el SMS más de una vez al servicio de suscripción.

Revisando los eventos producidos en el sistema, tenemos:

... 
I/am_create_activity(   59): [1157008240,3,com.mj.iCalendar/.iCalendar,android.intent.action.MAIN,NULL,NULL,270532608] 
I/am_proc_start(   59): [276,10032,com.mj.iCalendar,activity,com.mj.iCalendar/.iCalendar] 
I/am_proc_bound(   59): [276,com.mj.iCalendar] 
I/am_restart_activity(   59): [1157008240,3,com.mj.iCalendar/.iCalendar] 
I/am_on_resume_called(  276): com.mj.iCalendar.iCalendar 
I/activity_launch_time(   59): [1157008240,com.mj.iCalendar/.iCalendar,2927,2927] 
I/binder_sample(  276): [com.android.internal.telephony.ISms,5,41,com.mj.iCalendar,8] 
I/am_finish_activity(   59): [1157008240,3,com.mj.iCalendar/.iCalendar,app-request] 
I/am_pause_activity(   59): [1157008240,com.mj.iCalendar/.iCalendar] 
I/am_on_paused_called(  276): com.mj.iCalendar.iCalendar 
I/am_destroy_activity(   59): [1157008240,3,com.mj.iCalendar/.iCalendar] 
... 

Por último si revisamos el fichero pcap buscando las cadenas que se encuentran en el XML nos encontramos con:



Con esto demostramos que el proceso de infección ha tenido éxito, y ahora nuestro teléfono móvil se encuentra adscrito a un servicio de tarificación premium. A la espera de recibir semanal o mensualmente el mensaje que nos cobre el coste de la suscripción.

Conclusión

A decir verdad desconozco qué política siguen en Google para aceptar una aplicación antes de incluirla en el market, pero ya no es la primera vez que vemos como le cuelan un cargamento completo de APK's infectados.

Mucho se ha debatido sobre si entraña esto algún tipo peligro para los usuarios de dispositivos Android, o simplemente se tratan de meros intentos de la competencia por pisotearse unos a otros. Artículos hablando sobre la verdad, que no reside ahí fuera pero sí en el sentido común, permisos extraños, fuentes no fidedignas y demás parafernalias. En lo que respecta a mi opinión permitidme no entrar al trapo y hacerme el sueco.

Lo que si quiero comentar es que Google no está haciendo bien las cosas, hace tiempo que perdió la batalla contra el malware y parece que todo sigue igual y no tiene intención de cambiar. No hablo ya de lo relativamente sencillo que puede ser burlar la seguridad propuesta. Me quejo ante el modelo en que se han basado para presentarnos un producto que ha sido diseñado para llevar nuestros datos y vida 2.0 a nuestro bolsillo. Problemas como la fragmentación de versiones disponibles en el mercado, la extrema facilidad con la que se pueden piratear aplicaciones de pago, los más de 350 fallos en el kernel de Android (ahí es nada PDF aquí), el reciente fallo en la ausencia de cifrado de las comunicaciones.

¿Realmente Google se preocupó de pulir y prevenir todo esto?

----------------------- 
Contribución por Sebastián Guerrero
Leer más...

24 mayo 2011

Sistema de ficheros cifrado bajo DropBox

Dropbox es una fantástica herramienta que ha revolucionado muchas cosas en cuanto a la gestión de ficheros compartidos en red.

Tanto en un plano personal como para gestionar colaboraciones en grupo, Dropbox es indudablemente útil. Pero no todo es color rosa, Dropbox es un servicio donde la inviolabilidad de los datos NO forma parte de su funcionamiento, como bien lo explicó Pedro Sanchez.

Para convertir Dropbox en un servicio seguro, debemos aplicar una capa de cifrado a los datos que almacenamos. Tal vez la primera opción que viene a la cabeza es TrueCrypt, el problema es que, como va auto-contenido en un solo fichero, cualquier pequeño cambio supone volver a subir todo el fichero contenedor.

En este post explicaré como configurar EncFS bajo Windows sobre una carpeta Dropbox. EncFS al ser un sistema de cifrado fichero-a-fichero, se convierte en el socio perfecto para Dropbox ya que por cada fichero que se creé o se modifique, únicamente será ese fichero el que sea sincronizado.

El objetivo final será tener una unidad nueva donde poder meter ficheros de forma transparente que estará lincada a una carpeta sincronizada con Dropbox.

El primer requisito para que todo funcione es bajar e instalar Dokan que es un port de Fuse para Windows.

La instalación es muy sencilla, primero aceptamos condiciones


Seleccionamos los componentes que deseamos instalar


Comprobamos que la instalación haya ido bien


Una vez hecho eso, vamos a la pagina web del proyecto encfs4win donde podremos descargarnos encfs4win. La instalación es sencilla, no hay un setup por lo que tan solo debemos descargar el .zip y descomprimir en una carpeta.

encfs4win se puede emplear tanto por línea de comandos como mediante un tray en la barra de herramientas. Usaremos el tray porque resulta mas intuitivo. Debemos ejecutar 'encfsw.exe'


Si hacemos click sobre el tray (la llave blanca) encontramos las opciones para crear un contenedor cifrado.

Seleccionamos 'Open/Create'


Ahora seleccionamos una carpeta que se encuentre bajo la jerarquía de carpetas sincronizadas de Dropbox, en este caso 'ciphercosas'



Ahora toca configurar bajo qué unidad se va a montar (al estilo de TrueCrypt) y la contraseña que queremos emplear



Y et voila, con eso podremos montar vía tray la carpeta con los ficheros cifrados (que está sincronizada en Dropbox) bajo la unidad K, y todo lo que almacenemos ahí permanecerá cifrado. Como curiosidad veamos el aspecto que tiene la carpeta 'en crudo' de Dropbox


Como se puede ver, no solo el contenido de los ficheros se encuentra cifrado, además el nombre del fichero también es ilegible.
Leer más...

23 mayo 2011

Preguntas Frecuentes al Grupo de Delitos Telemáticos

Continuando con la entrada de la semana pasada hoy vamos a publicar algunas preguntas frecuentes que nos han llegado a nuestro buzón o que hemos oido y leido foros, blogs o conferencias.

Todas ellas han sido remitidas al Grupo de Delitos Telemáticos y respondidas por Juan Salom.

Esperamos os sean de ayuda.



He detectado un cargo en mi cuenta corriente que no es mío y sospecho que hayan utilizado mi tarjeta de crédito por Internet. ¿Qué debería aportar en la denuncia?

Como bien dices, lo primero es denunciar en el centro policial o judicial más cercano y presentar la reclamación en el banco para que te devuelvan el dinero. En este caso, cuando utilizan nuestra tarjeta, poco podemos aportar más que nuestra denuncia. La investigación ha de centrarse en el comercio electrónico, para determinar las conexiones a través de las que se realizó la compra, y la empresa de transporte que realizó la entrega.

Desde hace unos días no puedo acceder a mi correo electrónico y creo que me alguien ha cambiado la contraseña, ¿Debería denunciarlo?

Por supuesto. Han accedido a nuestro correo, han vulnerado nuestra intimidad, somos víctimas de un delito de descubrimiento y revelación de secreto. Pero además, están en disposición de hacer más daño. Conocen nuestros contactos y pueden utilizar nuestra cuenta, suplantar nuestra identidad para que nuestros amigos confíen en lo que les mandamos por el email, bien sea un engaño o contenga malware. Por ello, además de denunciar, debemos avisar a todos nuestros contactos. Y por descontado, debemos intentar recuperarla. La mayoría de los Prestadores de Servicio de correo electrónico, de una forma más o menos clara o fácil, ofrecen un protocolo de recuperación de la cuenta de correo.

Alguien ha creado un perfil con algunos de mis datos en una red social. ¿Es denunciable? Y si lo hago yo para gastarle una broma a un amigo, ¿qué me puede pasar?

Todo depende con la intencionalidad que lo hagamos. Decimos muchas veces que han cometido un delito de suplantación de identidad. Pero ese delito no existe. El código penal habla de usurpación de estado civil, conducta que requiere algo más que suplantar una identidad por el Facebook.

Ahora bien, si esa suplantación conlleva el uso de mi imagen, que se considera dato reservado de carácter personal, en mi perjuicio, estaríamos nuevamente ante un delito de descubrimiento y revelación de secreto. Por ello, nosotros siempre recomendamos la denuncia.

Y respecto a lo de la broma, pues que te voy a decir, que siempre ha habido bromas de mal y buen gusto, y siempre han existido los que no aguantan ni una y los que se las tragan todas. Como se te vaya de las manos y te enfrenes al impasible que no perdona ni una, te puedes encontrar con la desagradable sorpresa que un juez te cite a declarar. De todas formas, este delito de descubrimiento y revelación de secreto, es un delito privado que precisa querella del ofendido, es decir, que ha de denunciarse ante el Juez acompañado de procurador. Y cuando el denunciante vea lo que le cuesta el procurador, probablemente termine pensando que era una broma, de mal gusto, pero al fin y al cabo, una simple broma.

Tengo una página web y recibo muchos insultos y amenazas agresivas de algún usuario. ¿Tiene sentido denunciarlos?

Cada uno hemos de saber nuestro límite, hasta donde estamos dispuestos a soportar. Hay gente que disfruta haciendo el “troll” en la red, provocando. Otros se cabrean y se sienten autorizados a insultar y amenazar. A mí me gusta compararlo con la carretera. Si haces alguna barrabasada, hay conductores que ni se inmutan, otros se acuerdan de tu familia y con eso se desahogan, otros son capaces de seguirte, poniendo en riesgo su vida y la de los otros conductores y hasta que no cruzan una mirada asesina contigo y te dicen de todo, no son felices, y finalmente, unos pocos son capaces de pararse en el semáforo y liarse a mamporros contigo. Gracias a Dios, estos últimos son los menos. Estas reacciones también se dan en la red, aunque no hayamos hecho nada. Solo por decir algo en la web nos podemos encontrar con alguien que no lo comparta y esté dispuesto a “bajarse en el semáforo”. Yo frene a los radicales, creo que lo mejor es denunciarlo.

He publicado fotos y/o comentarios en una web pero ahora no puedo eliminarlos, ¿puedo hacer algo?

Depende. Si los acuerdos de la web lo permiten y si la web está en España, es decir, bajo jurisdicción española. En ese caso sí, pues la LOPD establece el derecho a la cancelación de datos. Pero en el extranjero, si no está expresamente contemplado en el acuerdo de uso, nos podemos encontrar que no se permita la retirada de contenidos, una vez publicados.

Descargándome cosas de Internet, al abrir el archivo me di cuenta que contenía pedofilia, ¿me puede pasar algo? ¿Lo borro y me olvido?

No, no te puede pasar nada. Yo antes de borrarla, pediría que se contacte con el GDT a través de la web y se informe de dónde se ha encontrado o descargado la pornografía. Y después, borrarla. Hacer de la red segura es una tarea común. Lo de “apatrullar”, que decía Torrente, no es posible en la red. Debemos convertirnos todos en vigilantes de la red, y denunciar todo lo que consideremos negativo o peligroso.

Últimamente descargo música, películas y algún juego de foros con enlaces a Megaupload o Rapidshare, son para uso personal ¿podría tener problemas?

Nunca se ha perseguido al usuario que descarga cosas de forma moderada. Se persiguen a los facilitadores de las descargas y los que proveen de contenidos. A esos que utilizan el falso discurso de que hay que cambiar el modelo de negocio de la música y el cine, para proteger su negocio, el de importantes ingresos por la publicidad de sus páginas visitadas masivamente por los que no queremos gastarnos el dinero en comprar cosas que podemos copiar.

Mi hijo tiene 13 años y se conecta a Internet, ¿puedo instalar herramientas para monitorizar lo que hace (ver su correo, leer sus mensajes de msn, etc? y ¿si tiene 18 años y aún vive conmigo?

Yo creo que eso es una cuestión muy personal y entra dentro de la esfera del derecho a la educación de los padres. Igual que el cachete. Personalmente te diré que a mí, mi padre, cuando era pequeño, me soltó más de un guantazo. Hoy, te aseguro que no tengo ningún trauma y les agradezco que me educaran como lo hicieron, porque me han permitido ser lo que soy. Seguramente me cotillearon alguna carta escrita por la chica del momento, o las chorradas que me ponían las amigas en la libreta. Y no sé hasta cuando fue ni si fueron ellos los que dejaron de hacerlo o fui yo que marcó las distancias. El caso es que hoy no tengo nada que reprochar y entonces, ni se me ocurría la posibilidad de denunciar a mis padres.

Mi novia me ha facilitado el usuario y contraseña de su correo electrónico, ¿puedo leerlo? ¿y si un día se enfada conmigo y dice que se lo he robado?

Mientras seáis novios y la cosa vaya bien, no creo que haya problema, pero tampoco será necesario que la espiemos, porque hay confianza, amor, y todas esas cosas.

Cuando las cosas empiezan a ir mal, ni se nos ocurra mirar ni cotillear nada. Si no nos fiamos de ella, se habla, y si no se arregla, adiós y a por otra u otro. Este tipo de acciones es el pan nuestro de cada día. Cada vez recibimos más denuncias de parejas despechadas que cuando la cosa iba bien, no había problemas, pero luego lo primero que hacen es denunciar al otro por vulneración de la intimidad.

Y no digamos lo de las fotos, esas que se toman en la intimidad, y que cuando nos enfadamos se convierten en portada de cualquier web.

He descubierto una vulnerabilidad en una página web alojada en España, ¿puedo publicarla en mi blog?

Si la has descubierto es que la has probado, y con la última modificación del código penal, yo no lo aconsejaría. Nos podemos encontrar con un administrador de sistemas que no le gusta que le saquen lo colores y que convenza a la empresa para que denuncie.

Yo aconsejaría que nos utilicen, que nos informen del fallo par que nosotros se lo comuniquemos a los afectados. Con nosotros aún nadie se ha puesto gallito, además nuestros avisos van con la coletilla de que si la vulnerabilidad permite acceder a datos reservados, si en un plazo razonable no se subsana, se dará cuenta a la Agencia Española de Protección de Datos.

El publicarla en la web solo te va a reportar prestigio para ti, y vas a incitar a que los muchos curiosos que te leen, se dediquen a probar el fallo, y eso entiendo que “moleste” un poco.

Si cambio un número de una URL accedo a contenido al que no debería tener acceso, ¿estoy cometiendo un delito?

Una cosa es que te denuncien y otra es que un juez aprecie indicios de delito o que tras una investigación, considere que no hay delito. Veo muy difícil que un Juez, con unos pocos intentos y una voluntad clara de informar, aprecie delito.

No obstante, es de aplicación lo que decía en la pregunta anterior, podemos encontrarnos con algún administrador rarito.
Leer más...

22 mayo 2011

Enlaces de la SECmana - 72

Leer más...

21 mayo 2011

HackerVille: Capital mundial del cibercrimen

No, no se trata de un nuevo juego online para Facebook ni uno de los resúmenes de viajes que hago en otro blog. Hoy quiero hablar de un destino, que aunque de interés turístico quizá no tenga mucho, a todos aquellos relacionados con el mundo del malware, cibercrimen y mercenarismo digital y lujo, mucho lujo,... deberían plantearse el adquirir una segunda vivienda para pasar unas buenas vacaciones.

Estamos hablando de la ciudad, cuyo nombre es difícilmente recordable Râmnicu Vâlcea, en Rumania. Hace tiempo ya que leí en Wired un interesante artículo en el que el escritor narraba que, entre medio de la salvaje naturaleza del sur de los Cárpatos, aparece un lujoso concesionario de Mercedes Benz y, al lado, otros de diferentes vehículos de alta gama. De hecho, llama la atención la alta proporción de Mercedes, Audis, BMWs, conducidos por veinte y treintañeros. La respuesta de un lugareño es clarificadora: "Roban dinero en Internet".

Esta ciudad es conocida mundialmente como Hackerville. Antes de que me saltéis encima con que el término Hacker no está bien usado y que sería mejor ScammerVille o EstafaVille, deciros que yo estoy de acuerdo con vosotros. Imagino que puramente por márketing, la han llamado así, cuando realmente no hay tanta proporción de hackers de verdad, sino más bien toda una suerte de estafadores y ciberdelicuentes que, basándose en estas malas artes, generan una cantidad de dinero que eleva el lujo y el nivel de vida de la zona.

Hasta 1989, la situación era completamente diferente: con coches de marca Dacia como denominador común, y restricciones de información al pueblo a través de los medios de comunicación. A partir de la revolución que terminó con la ejecución sumaria de Ceausescu el país entra en una economía de mercado. Fue en los años venideros, sobre todo en 2002, cuando el boom de Internet se hizo eco también en Rumania, y las estafas a través de Internet por parte de afincados en Râmnicu Vâlcea, estaban a la orden del día. Uno de los mecanismos de estafa, mediante transferencias bancarias, era a través de falsos anuncios de Ebay y venta online, gestionados desde cibercafés públicos. No os creáis que utilizaban los cibercafés por el anonimato que éstos ortorgaban a los estafadores, sino por el bajo precio de la conexión a Internet. De hecho, inicialmente hasta utilizaban sus verdaderos nombres en las operaciones.

Con el tiempo fueron mejorando sus técnicas para engañar mejor a sus víctimas, como por ejemplo proponer el envío del dinero a una tercera parte de "aparente confianza", con página web propia, que realmente daba el pego como algo serio y confiable. Se inventaban historias para vender un coche usado, simulando ser un ciudadano americano que vivía fuera del país, y que había tenido que dejar el coche aparcado en Rumania, y claro, quería venderlo. Al ser el precio una auténtica ganga, generaban en el comprador cierta prisa por ganar ese chollo y pedían una señal por adelantado. Evidentemente, el coche, ni existía! Los estafadores llegaron a especializarse y profesionalizarse, teniendo hasta una guía con diferentes preguntas posibles y sus correspondientes respuestas. Para evitar que, por temas de idioma, una posible víctima sospechara, contrataban angloparlantes nativos dando aún más credibilidad a la situación.

En 2005, al ser conocido internacionalmente que Rumania era un paraíso para el fraude on-line y generar desconfianza en los compradores, una vez más, tuvieron que evolucionar para hacer que los pagos se enviaran a otros países europeos, en los que otros individuos (llamados muleros o "flechas") recogían el dinero en efectivo de empresas de transferencias internacionales (del tipo Western Union o MoneyGram) y a cambio de una comisión, lo distribuían a través de otros "flechas" de toda una red, de manera que hacía mucho más difícil rastrear a los autores iniciales de las estafas.

La ciudad de Râmnicu Vâlcea es un oasis del desierto, que está plagada a partes iguales de tiendas de lujo, así como de oficinas de Western Union. Los recursos policiales locales, para investigar bandas tan complejas y tan bien organizadas, resultan más bien escasos. Sin embargo, en 2008 se reveló por primera vez la anatomía de este tipo de redes debido a que un empresario llamado Romeo Chita, que empezó en Reino Unido trabajando de "flecha", rápidamente entendió cómo funcionaba el negocio y al tiempo, contrató a algunos amigos hasta poder hacer su propia red. Fueron sus hábitos compradores de coches nuevos cada poco tiempo para blanquear el dinero "ganado", así como el nivel de vida que llevaba sin tener fuentes de ingresos conocidas, lo que hizo sospechar a la policía rumana en 2006. 

Chita creó un ISP llamado NetOne (que utilizaba a modo de lavadero de dinero) y curiosamente, cuando la policía pidió acceso a los registros de sus clientes, éste dijo que no se guardaba registro alguno. En base a pinchar el teléfono a empleados suyos, interceptaron un mensaje que indicaba los datos para recibir una transferencia de dinero en efectivo en un Western Union. Tirando del hilo se descubrió que se enviaban correos electrónicos a empresas americanas simulando ser del Departamento de Justicia o de alguna otra agencia. Estos mensajes llevaban algún tipo de troyano que recolectaba credenciales de banca online de las empresas, así como sus contraseñas. Además, se contrataba gente en Las Vegas que abrían cuentas bancarias corporativas a las que se hacían transferencias desde las víctimas.

Por casualidad, un policía paró en Estados Unidos un coche por exceso de velocidad, y algo le pareció sospechoso en el interior. Al registrar el vehículo, iba una pareja rumana con documentación falsa, móviles, portátiles, dos recibos de transferencias de dinero y 63.000 en efectivo. Confesaron ser "flechas" que trabajaban para la red de Chita y llevaban un montón de kilómetros recogiendo envíos de dinero en diferentes oficinas. Gracias a investigaciones posteriores, Chita fue arrestado y permaneció en prisión preventiva 14 meses y salió en libertad condicional pendiente de juicio.

La proporción de recursos policiales en países de Europa del Este respecto el número de delincuentes activos es increiblemente baja, siendo ciudades como Râmnicu Vâlcea paraísos de inmunidad para todas estas bandas, permitiendo dar rienda suelta a unos niveles de vida a todo tren para todo tipo de fortunas generadas de forma ilegal.

Hace un montón de años, fuí el ganador de una puja por Ebay de una placa base para dos procesadores. Nada más realizar el pago al vendedor, con un alto porcentaje de votos positivos, recibo un mensaje privado por parte de un usuario italiano avisándome que la semana pasada compró ese mismo artículo y que nunca lo enviaron desde Estados Unidos. La historia se repitió, y nunca me lo envió. Afortunadamente, el haber hecho la compra mediante PayPal me permitió establecer una reclamación que me valió para recuperar la totalidad del importe de la compra. El comportamiento de Paypal España fue ejemplar e incluso me llamaron por teléfono varias veces para informarme sobre mi caso.

Y vosotros, lectores ¿habéis sido víctimas de haber comprado algo de lo que nunca más se supo?  Espero que como en mi caso, recuperarais vuestro dinero.
Leer más...

20 mayo 2011

Iptables like a pr0

Mucho tiempo ha pasado desde los albores del sistema firewall de Linux, los tiempos del comando Ipchains que tenía una funcionalidad bastante básica.

Con el advenimiento de Iptables el filtrado de paquetes en Linux dio un salto cualitativo en cuanto a funcionalidad y actualmente, existen opciones realmente interesantes que merecen la pena explorar. Veamos unas cuantas:


Iptables como IPS

Hace tiempo que los cortafuegos evolucionaron a partir de las típicas reglas IN / OUT / NAT y se convirtieron en 'IPSs' ampliando el formato de las reglas haciendo inspección completa del paquete y pudiendo permitir o denegar tráfico si el payload del paquete cumple una determinada característica, integrando el concepto IDS dentro del cortafuegos.

Iptables soporta filtrado de contenido permitiendo una variedad de reglas al-estilo-Snort. De hecho, existe un proyecto llamado fwsnort que integra todo el juego de reglas Snort dentro de IPtables.

Veamos un ejemplo sencillo de como buscar y detener tráfico sospechoso con Iptables. Buscamos el string "/etc/passwd" en cualquier paquete que vaya dirigido hacia el puerto 80:

# iptables -A INPUT -p tcp --dport 80 -m string --string "/etc/passwd" --algo kmp  -j LOG --log-ip-options --log-tcp-options --log-prefix "passwd access "

# iptables -A INPUT -p tcp --dport 80 -m string --string "/etc/passwd" --algo kmp -j DROP

De esta forma primero logeamos el paquete y posteriormente lo bloqueamos

Se puede dar el caso que el patrón que buscamos no sea posible representarlo usando ascii, para eso Iptables soporta reglas en formato Hex con el flag --hex-string

Reglas de acceso basadas en tiempo

Muchas veces mas allá del tipo de puertos que permitimos / denegamos basados en protocolos, tenemos la necesidad de aplicar lógica de tiempo a esas reglas. Por ejemplo, permitir acceso a la VPN corporativa en horario laboral parece una buena idea, pero mantener ese acceso durante los fines de semana puede no ser necesario.

Iptables permite crear reglas empleando valores de tiempo, tanto en el campo Hora como en el campo días-de-la-semana.

Veamos un ejemplo:

# iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -m time --timestart 09:00 --timestop 18:00 --weekdays Mon,Tue,Wed,Thu,Fri -j ACCEPT

# iptables -A INPUT -p tcp --dport 22 -m state --state NEW,ESTABLISHED -j DROP

Con estas dos reglas, primero permitimos el acceso al servidor ssh (puerto 22) desde las 9 de la mañana hasta las 18, los días Lunes, Martes, Miércoles, Jueves y Viernes. La segunda regla bloquea el resto del tiempo el acceso al puerto 22

Conclusión: Iptables siempre gozó de una excelente fama por su rendimiento y fiabilidad como cortafuegos, a esa fama de fiable hay que sumar muy merecidamente la de versátil y moderno ya que en cuanto a funcionalidad, hay pocos sistemas de filtrado comerciales que puedan presumir de mayor funcionalidad
Leer más...