01 septiembre 2011

Kernel.org Comprometido


Noticia de alcance: uno (o varios) de los servidores de Kernel.org (el sitio de referencia para descargar el Kernel de Linux) han sido comprometidos

Según se puede leer en la propia web:


-Los atacantes consiguieron hacerse con el control de la cuenta root (máximos privilegios y acceso total) en uno de sus servidores

-El acceso inicial parece que se realizó mediante claves SSH legítimas que fueron robadas de usuarios que tenían acceso al sistema

-Una vez dentro, emplearon un exploit para conseguir acceso como root

-Aparentemente 'troyanizaron' el servicio OpenSSH, tanto el servidor como los clientes (con lo que no es descartable que, todo aquel que haya hecho una conexión ssh DESDE el servidor comprometido haya comprometido el host al que conectaba)

-A la máquina se le añadió un troyano para asegurar el acceso

En principio los administradores de Kernel.org aseguran que resulta poco probable (según ellos imposible) que alguien haya podido introducir código malicioso en alguna versión del kernel que haya estado accesible para descarga

El motivo por el que aseguran la integridad del kernel es debido a la forma en la que funciona GIT, que incorpora mecanismos criptográficos de validación (hashes) en los ficheros que gestiona por lo que, a priori, cualquier modificación 'extraña' hubiese sido detectada.

Aun así, la información es provisional ya que están en proceso de investigación del incidente.
Leer más...

31 agosto 2011

Compromiso de la autoridad certificadora Diginotar

Acabamos el verano con una noticia que vuelve a sacudir nuestra vida cotidiana. En este caso, la publicación de la noticia de que una de las autoridades certificadoras, Diginotar, había emitido un certificado el 10 de Julio de 2011, para todos los subdominios de google.com, que podría permitir a algunos usuarios descifrar las comunicaciones de otros usuarios con los servicios "del gigante" (plus, docs, mail...). Alguien accedió, y consiguió emitir este certificado.

Si bien todavía los detalles del ataque no se saben a ciencia cierta, si que se evidenció en varias ocasiones como esta empresa holandesa habría sufrido varias intrusiones en sus sistemas, por varios grupos de hackers, crackers, defacers, etc. Ya en marzo informamos del caso Comodo y la historia de la CA comprometida se repite ahora con Diginotar. Al parecer, estuvimos (o estamos en medio) de una moda en la que los principales objetivos son CAs que si bien en la mayoría de los casos no sean muy conocidas, si que están en la lista de permitidas por navegadores, algo suficiente para poder "liarla parda" en caso de acceder a su plataforma de emisión de certificados y generarlos a nuestro antojo. Como se muestra en este post de F-Secure, Diginotar llevaba sufriendo intrusiones desde el 2009 por diferentes grupos. Quizás el ver que era un deface les hizo pensar que de ahí no fueron a más. MAL.



Ya Moxie Marlinspike se aventuró a exponer este gran problema al que nos enfrentamos, y en el que en un principio, estamos atados de pies y manos, y nos propuso Convergence debido a estos últimos acontecimientos en lo que llevamos de año. Ahora mismo lo que podemos hacer de momento es limpiar todo rastro de Diginotar de nuestros repositorios de autoridades de certificados.

Los fabricantes se han aventurado a publicar sus avisos de seguridad para que sepamos que están al tanto de este incidente:

De Apple todavía no tenemos noticias a fecha de redacción de este post, aunque de momento si os podemos recomendar que accedáis a vuestro repositorio de certificados (Keychain Access)  y elimineis el certificado de Diginotar.

Seguimos al tanto de todo lo que se siga comentando acerca de este tema, no descartamos un próximo hackeo memorable a Diginotar CA, la verdad es que se lo merece.


Leer más...

30 agosto 2011

Nueva revisión de Amispammer

Aprovechando los últimos días de vacaciones de verano, me dispuse a tachar de mi lista de "To Do" una de las cosas que tenía pendientes hacía bastante tiempo: una nueva revisión de la herramienta Am I Spammer.

Esta herramienta, que hemos presentado hace tiempo en Security by Default, y que está incluida en varias distribuciones Linux como Debian y Ubuntu, ayuda a identificar si una dirección IP, o todas las que pertenecen a registros MX de un dominio, aparecen en una o varias listas negras de reputación. De esta manera, amispammer permite alertar a los administradores de sistemas de que el tráfico de correo electrónico desde esa(s) IPs presentará un servicio degradado al aparecer en alguna de estas listas negras, que los servidores de correo, relays o sistemas antispam con los que interactúen, marcarán como maliciosas antes de recibir/enviar sus correos.

Fue precisamente a la hora de paquetizar la herramienta en Debian, cuando se me hicieron varias sugerencias respecto a posibles mejoras a tener en cuenta. Así pues, la lista de cambios realizados a amispammer en esta ocasión han sido:

  • Utilizar Getopt::Std en vez de "getopt.pl", puesto que esta última librería se mantiene en Perl únicamente por compatibilidad con Perl 4 y actualmente se encuentra sin mantenimiento.
  • Cuando se ejecuta amispammer, por defecto se generan muchos hilos simultáneamente y en algunas versiones de Linux, durante un momento puntual, consume excesivos recursos de sistema. Convendría reducir la prioridad del proceso para mitigar ese consumo excesivo de recursos de la máquina que lo ejecuta. Para ello, en vez de utilizar "renice" como comando de sistema operativo (para entornos UNIX únicamente), ahora utilizo "setpriority" del proceso como función nativa de perl, haciendo extensible esta funcionalidad cuando amispammer se ejecuta en entornos Windows igualmente.
  • Si se ejecutaba amispammer sin parámetros, se entiende que la dirección IP a analizar es la propia IP pública desde la que se está ejecutando amispammer. Para identificar dicha dirección, anteriormente se hacía web-scraping mediante una consulta web a www.cualesmiip.es. En una versión posterior, se utilizaba http://checkip.dyndns.org. Así, se parseaba el resultado que devolvía la petición web y se obtenía la IP pública. Sin embargo, aunque parecía que el diseño de cualesmiip.es y/o el de checkip.dyndns.org nunca en la vida iba a cambiar, en ambas ocasiones, la función auto_get_ip dejó de funcionar gracias a que la ley de Murphy se aplicó en el formato de ambas webs. Así pues, en esta última revisión se utiliza el módulo perl Net::Address::IP::Local, que provee la IP pública de la máquina, sin apoyarse en cualesmiip.es ni checkip.dyndns.com, corrigiendo así este bug. 

La nueva versión de amispammer para Debian deberá esperar unos días hasta que sea aceptada, probada y actualizada. Avisaremos por el twitter de @secbydefault y actualizaré este post cuando la nueva versión esté disponible en Debian y Ubuntu de forma paquetizada. No obstante, esta nueva versión puede ser descargada del repositorio de herramientas de SbD y/o de la página del proyecto.
    Como siempre, si tenéis nuevas sugerencias con nuevas fucnionalidades o fuentes para añadir a amispammer, soy todo oídos!
    Leer más...

    29 agosto 2011

    Gmail Security Center

    Gmail, el servicio sobre el que pivotan otros tantos servicios de Google y que mucha gente emplea como 'cuenta principal' y tienen asociada a servicios como Twitter, Facebook o cosas mas serias como bancos, compañías telefónicas, servicios de hosting, etc.

    Se podría decir que para mucha gente es su activo mas valioso en su 'ciber-vida', por lo que protegerlo debería de ser algo importante.

    Hace algún tiempo liberamos una pequeña guía de seguridad para Gmail y hoy vamos a presentar una herramienta que permita monitorizar el uso de una cuenta en Gmail.

    Como probablemente todo el mundo sepa, Gmail tiene de serie un histórico de uso que permite comprobar el uso reciente de la cuenta


    El problema es que solo registra los 10 últimos accesos, por lo que, o tomas la sana costumbre de revisar esa información casi a diario, o probablemente perderás información. No existe forma de consultar un histórico de actividad mas allá de esos 10 últimos accesos.

    Dándole un par de vueltas a esto se me ocurrió crear una herramienta que hiciese tres cosas:
    • Poder generar un histórico de accesos a la cuenta virtualmente 'infinito' para consultar los accesos según fuese necesario
    •  Ampliar la información que ofrece Gmail, no solo con IP / País sino también ciudad e ISP
    • Tener la posibilidad de enviar alertas en función de la nueva actividad que se generase en esa cuenta (accesos)
    Y la solución a esos problemas la he llamado 'Gmail Security Center' y está basada en este excelente ejemplo sobre como usar el módulo 'mechanize' en Python que he modificado para acceder a la información de actividad, añadido soporte para enviar 'tweets' para las alertas en tiempo real e incorporado el uso de Geolocalización .

    # This Python file uses the following encoding: latin-1
    
    import mechanize
    import cookielib
    import re
    import sys
    import getpass
    import time
    import GeoIP
    import commands
    import tweepy
    
    #Twitter Auth
    
    CONSUMER_KEY = ''
    CONSUMER_SECRET = ''
    ACCESS_KEY = ''
    ACCESS_SECRET = ''
    
    auth = tweepy.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
    auth.set_access_token(ACCESS_KEY, ACCESS_SECRET)
    api = tweepy.API(auth)
    
    #Geoip
    
    gi = GeoIP.open("GeoLiteCity.dat",GeoIP.GEOIP_STANDARD)
    
    # Browser
    br = mechanize.Browser()
    
    # Cookie Jar
    cj = cookielib.LWPCookieJar()
    br.set_cookiejar(cj)
    
    # Browser options
    br.set_handle_equiv(True)
    #br.set_handle_gzip(True)
    br.set_handle_redirect(True)
    br.set_handle_referer(True)
    br.set_handle_robots(False)
    
    # Follows refresh 0 but not hangs on refresh > 0
    br.set_handle_refresh(mechanize._http.HTTPRefreshProcessor(), max_time=1)
    
    # User-Agent (this is cheating, ok?)
    br.addheaders = [('User-agent', 'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008071615 Fedora/3.0.1-1.fc9 Firefox/3.0.1')]
    
    # The site we will navigate into, handling it's session
    br.open('http://gmail.com')
    
    # Select the first (index zero) form
    br.select_form(nr=0)
    
    # User credentials
    
    print "Gmail Security Center [ Security By Default http://www.securitybydefault.com ]"
    
    login = raw_input("Login:")
    password = getpass.getpass("Password: ") 
    
    br.form['Email'] = login
    br.form['Passwd'] = password
    
    # Login
    br.submit()
    
    req = br.click_link(text='Información detallada')
    br.open(req)
    
    ips = []
    
    while 1==1:
    
        html = br.response().read()
    
        ipscitas = re.findall('(?:[\d]{1,3})\.(?:[\d]{1,3})\.(?:[\d]{1,3})\.(?:[\d]{1,3})', html)
    
        if ipscitas:
            
            for resultado in ipscitas:
            
                if not ips.count(resultado):
    
                    ips.append(resultado)
                    
                    command_str = 'whois %s | grep "desc"' % resultado
            
                    whoisret= commands.getoutput(command_str)
            
                    whoisret = whoisret[1:-1].split('\n')
            
                    m =re.search("(escr|descr):          (.+)",  whoisret[0])
            
                    isp= m.group(2)
            
                    gir = gi.record_by_name(resultado)
            
            
                    if gir != None:
                
                        print resultado, gir['country_name'],  gir['city'], gir['region_name'], isp
                        
                        twittersend = resultado + " " + str(gir['country_name']) + " " + str(gir['city']) + " " + str(gir['region_name']) + " " + isp
                        
                        try:
                            api.send_direct_message(screen_name= '@YJesus', text = twittersend )
                            
                        except :
                    
                            pass
        
        br.reload()
    
        time.sleep(900)
    


    Para poder usarlo, primero debéis tener instalado en el sistema el módulo 'mechanize', lo mas fácil para instalar ese y otros módulos ajenos al core de Python es usar el comando -como root- 'easy_install' disponible en el paquete python-setuptools (al menos en Fedora)

    # easy_install mechanize

    Una vez instalado ese módulo, hay que dar soporte GeoIP instalando la librería en C de Maxmind y su bind a python (información para hacerlo aquí) y descargar una base de datos actualizada

    Finalmente, viene la parte mas engorrosa de todo el asunto y es que Twitter, cuando forzó a usar OAuth en todo aquello que tuviese que interactuar con el, hizo que enviar tweets desde una aplicación fuese un proceso bastante laborioso. Aquí hay un tutorial bastante bueno sobre como registrar una aplicación hecha en Python para poder usar Twitter

    De lo que se trata es de poder rellenar los siguientes campos en el script:

    CONSUMER_KEY = ''
    CONSUMER_SECRET = ''
    ACCESS_KEY = ''
    ACCESS_SECRET = ''

    Una vez hecho eso, el script monitorizará la actividad de la cuenta GMail y cuando vea nueva actividad enviará alertas parecidas a esta:

    Que serán cómodamente recibidas y procesadas vía Twitter, adicionalmente se puede sacar un histórico volcando la salida del script a un fichero
    Leer más...

    28 agosto 2011

    Enlaces de la SECmana - 86



    Leer más...

    27 agosto 2011

    Top 5 errores de seguridad en el mundo IT

    Lo cierto es que ya estamos acostumbrados -y casi inmunizados- a los clásicos listados de errores típicos en materia de seguridad: No parchear sistemas, no realizar una buena monitorización etc etc ...

    Es difícil aportar algo nuevo a esta clase de 'rankings', no obstante he encontrado este artículo de Network World en el que se aborda la problemática desde un punto de vista de enfoque que me ha gustado bastante. Me tomo la licencia de transcribir el artículo con mi propia interpretación

    Error 1: Pensar que la mentalidad empresarial de la organización es la misma que hace cinco años 

    Hace cinco años el tipo de dispositivos que accedían a una red corporativa se limitaban a los equipos plataformados de la compañía, sean equipos de sobremesa o portátiles.

    Actualmente eso no es así, cada vez más se imponen los 'smartphones' como elementos empresariales, y ahora asistimos a la moda de los tablets. En definitiva, un montón de nuevos equipos que ni de lejos han sido diseñados para ejercer sobre ellos el tipo de control que se puede tener sobre el típico equipo Windows dentro de un dominio.

    Sumemos a este escenario la cantidad de aplicaciones 'Cloud' de uso ampliamente difundido, y tenemos un escenario bastante complejo de gestionar que requiere una estrategia mucho mas moderna.

    Error 2: No saber establecer las relaciones correctas entre el equipo de seguridad y el resto de áreas IT

    El ya clásico tira-y-afloja entre la división de seguridad y el resto de departamentos. Para cualquiera que haya trabajado en una empresa IT le sonarán altamente familiares las discusiones entre lo que quiere el grupo de desarrollo, los plazos del grupo de marketing, el coste que impone el grupo financiero y las objeciones del equipo de seguridad.

    Tener muy clara y definida la 'cadena de decisión' es clave.

    Error 3: No comprender que la virtualización requiere nuevas estrategias de seguridad

    Es obvio que según se van integrando las tecnologías de virtualización el enfoque debe cambiar. Se ha puesto muy de moda el introducir servicios ya paquetizados en formato vmware -por ejemplo- que supuestamente son 'plug&play', pero en lo que pocas veces se piensa es en como se parchean estos equipos y como se gestiona su seguridad

    Error 4: No estar preparados para una fuga de datos

    Probablemente siempre se tiene claro que documentos son considerados sensibles dentro de una organización pero ¿y si aparecen fuera de la organización? Tener mecanismos para identificar accesos a documentos y disponer de una trazabilidad al respecto es clave

    Error 5: Complacencia con los proveedores

    Muy típico en España, una vez la organización establece su red clientelar de 'partners' pocas veces existe un espíritu crítico para revisar lo que nos están vendiendo. Hay que tener claro que la solución ofertada por un proveedor X no tiene porque ser la mas correcta aunque en anteriores ocasiones nos haya suministrado aplicaciones interesantes.

    Hay que mantenerse alerta y al tanto de lo que hay en el mercado de una forma global, no solo a través de los ojos de nuestros partners.
    Leer más...

    26 agosto 2011

    ¡Mamá, quiero ser pentester!

    El trabajo de un Penetration Tester (pentester a partir de ahora) es posiblemente uno de los más mitificados en el mundo de la seguridad.

    En la última Defcon ha habido una ponencia llamada "Mamma Don't Let Your Babies Grow Up to be Pen Testers - (a.k.a. Everything Your Guidance Counselor Forgot to Tell You About Pen Testing)" que precisamente pretende desmitificar con un poco de humor muchos aspectos de éste trabajo y plantear cosas que muchas personas, antes de empezar a trabajar como pentester, seguramente no se hayan planteado.

    Algunas cosas interesantes que se comentan son las siguientes.

    - Expectativas
    • MS Windows mola (aunque ésto es bastante personal)
    • GUI > línea de comandos
    • Ganar millones

    - Realidad

    • GNU/Linux mola (de nuevo, bastante personal)
    • Línea de comandos > GUI
    • No es una mina de dinero

    La autorización del pentest es sagrada, de ninguna manera se pueden sobrepasar los límites. Y por supuesto, los usuarios puede que estén avisados de que se está haciendo una auditoría.

    Puede darse la posibilidad de que haya una máquina vulnerable, en la que ejecutando un comando se pueda conseguir root, pero no tienes autorización para hacerlo. ¿A que ya no es tan atractivo?

    Deadlines y expectativas del cliente para nada realistas (bueno, ésto no es exclusivo de los pentesters).

    Cuando tienes éxito, significa que otro ha errado en su trabajo, ya sea el sysadmin, el administrador de seguridad, el desarrollador de alguna aplicación, ...

    Después del pentest hay que documentar todo el trabajo, algo que puede gustarte, o no.

    Las cosas cambian, o como ellos dicen, "Scanned today Hacked tomorrow". Es posible que el trabajo perdure lo que dura el pentest.

    Aún con ésto, la conclusión que dan sobre éste trabajo es muy positiva, ¡y no es para menos!

    Es probable que personas no relacionadas con el mundo de la seguridad informática o aún poco cercanas vean al pentester como a Trinity cuando en Matrix II lanza un Nmap para luego explotar un fallo de SSH que le permite dejar sin luz a toda la ciudad. Nada más lejos de la realidad.

    Para los interesados, aquí está la presentación que utilizaron en la ponencia.
    Leer más...