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...

    25 agosto 2011

    Create tu propio Infobel

    Hace unos años se vendía "Infobel", un CD con una base de datos que contenía los nombres, apellidos, dirección postal y teléfono fijo de todos los usuarios de telefonía fija de España y otras ediciones para otros paises de Europa. Esta base de datos se solía utilizar para automatizar contestadores con publicidad y otros fines similares de marketing, además se podían hacer búsquedas inversas. Es decir, dado un número de teléfono fijo, averiguar quién te estaba llamando.

    Como Infobel ya no existe por distintos problemas con la ley de protección de datos, a Yago se le ocurrió ver si éramos capaces de hacernos nuestra propia base de datos usando la página web de páginas blancas, ya que había visto que no usaban captchas.

    En ese momento me acordé del año pasado cuando Ron de SkullSecurity recorría automáticamente el directorio de Facebook y generaba un curioso diccionario de más de 100 millones de nombres únicos. Más tarde, en mayo de este año, un estudiante repetía la jugada con Google, descargando unos 35 millones de perfiles.

    Comentada la idea, me puse a mirar la web, eso sí, sin llegar a guardar los datos en ningún sitio, ya que eso requeriría dar de alta el archivo por contener datos de caracter personal.

    Lo primero que observé es que paginas blancas requiere que se introduzca como mínimo un nombre, apellido o razón social y una provincia.


    Si no se meten esos dos valores, mostrará un error similar al siguiente:


    Así que como un buen chico, metí Alejandro como prueba en "A Coruña", a ver los resultados que ofrecia.


    Vaya, ya tenía 589 Alejandros localizados en A Coruña, la lastima es que solo deja mostrar los 50 primeros, tal y como informa la propia web:


    Y una vez avanzas 5 páginas y obtienes los 50 registros, la web cambia y elimina el botón "Siguiente", evitando que obtengamos todos:


    Seguro que los más vivos ya os habréis imaginado por dónde van los tiros. ¡Estos datos los valida en el lado del cliente!, y tanto la provincia como el número de página son parámetros que se ingresan en la URL, es decir, que yo cambio de la URL el parámetro "nomprov" y elimino "A Coruña", buscará todos los Alejandros de España. Tal y como muestro para mayor claridad en la siguiente imagen con Hackbar:


    El número cambia de los tristes 589 a 29.952 ¡wow!

    De esta misma forma, modificando el parámetro "pg" de la URL puedo avanzar y obtener todos los resultados, ya que lo único que hace el botón de "Siguiente" es incrementar en uno ese valor.

    Bien, con estos dos "pequeños" fallos ya solo queda programar un algo que haga el trabajo sucio. Buscar muchos nombres y recorrer las páginas.

    Como diccionario de nombres en primera instancia se me ocurrió usar los que ya se habían sacado de Facebook, pero 100 millones de nombres, definitivamente, son DEMASIADOS nombres. Así que me acordé del Instituto Nacional de Estadística, que ofrece datos sobre frecuencia de nombres. Sumando los de hombre y mujer, conseguí 16.101 distintos, parecía mucho más acotado que los 100.000.000 de Ron.



    Una vez copiados del INE a un fichero, tocaba hacer el script, que pese a que es horrible, funciona:

    #!/bin/bash
    # Jun  12 02:41:36 CEST 2011 It's time to scrap!
    # $1 = archivo con nombres
    
    BURL="http://blancas.paginasamarillas.es/jsp/resultados.jsp?"
    
    for name in `cat $1`; do
    PARAM="no=$name&sec=15&tbus=0&idioma=tml_lang&pg=1&pext=null"
    count=`curl -s ${BURL}${PARAM}|grep Encontrados | tail -1 |sed -e 's|.*ng> \(.*\)<.*|\1|'`
    if [ -z $count ]; then echo "saltando: $name"; continue; fi
    echo "encontrados $count de $name"
    get=0
    fetch=$(( $count / 10 + 1 ))
    while [ "$fetch" -gt "$get" ]; do
    get=$(( $get + 1 ))
    echo "debug: obteniendo $get de $fetch de $name"
    PARAMS="no=$name&sec=15&tbus=0&idioma=tml_lang&pg=$get&pext=null"
    curl -s ${BURL}${PARAMS} | grep listatel | tee -a $1.out
    done
    done
    

    Fueron 10 minutos para hacerlo asi que no quiero oír quejas, el output además es aún peor:

    <a href="#" onclick="return imprimeAnuncio('resultados_imp.jsp?LO1=OURENSE&CALL=Galicia&PR=OURENSE&NUME=&TP=IG&NO=LUIS MANUEL GON&APE1=-&
    APE2=&CP=32005&tel=988 242 xxx&sec=28&vez=0&listatel=')" >
    <a href="#" onclick="return imprimeAnuncio('resultados_imp.jsp?LO1=LLEIDA&CALL=Castelló Aleu&PR=LLEIDA&NUME=&TP=IG&NO=BORRELL SENA SL&AP
    E1=-&APE2=&CP=25005&tel=973 830 xxx&sec=28&vez=0&listatel=')" >
    <a href="#" onclick="return imprimeAnuncio('resultados_imp.jsp?LO1=LLEIDA&CALL=Germans Recasens&PR=LLEIDA&NUME=&TP=IG&NO=CONSUELO SANCHE&
    APE1=-&APE2=&CP=25005&tel=973 248 xxx&sec=28&vez=0&listatel=')" >
    

    Por lo que luego hubo que hacerse otro para convertir la salida HTML en un CSV, esta vez en perl. Como los machos ;-)

    #!/usr/bin/perl
    while() {
    s/.*jsp?//;
    s/\&sec.*//;
    #print $_;
    ($loc) = $_ =~ m/.*LO1=(.*)\&CALL.*/;
    ($call)= $_ =~ m/.*CALL=(.*)\&PR.*/;
    ($pr) = $_ =~ m/.*PR=(.*)\&NUME.*/;
    ($tp) = $_ =~ m/.*TP=(.*)\&NO.*/;
    ($no) = $_ =~ m/.*NO=(.*)\&APE1.*/;
    ($ape1) = $_ =~ m/.*APE1=(.*)\&APE2.*/;
    ($ape2) = $_ =~ m/.*APE2=(.*)\&CP.*/;
    ($cp) = $_ =~ m/.*CP=(.*)\&tel.*/;
    ($tel) = $_ =~ m/.*tel=(.*)/;
    $tel =~ s/ //g;
    print "\"$loc\",\"$call\",\"$pr\",\"$tp\",\"$no\",\"$ape1\",\"$ape2\",\"$cp\",\"$tel\"\n"
    }
    done
    

    Cuando terminé y me sentía realizado, pensé que lo mismo la lista de nombres no era lo suficiente completa, así que se me ocurrió que cuando terminase (con 8 millones de resultados), podría hacer una lista de Apellidos de todos los datos obtenidos, y consultar nuevamente con ese otro nuevo diccionario.

    Sumando los resultados de ambas ejecuciones y eliminado los duplicados, finalmente quedarian (supongo)  unos 9.7 millones de registros.

    Una vez reportado y arreglado, esta es la historia.

    --

    garbanzosf
    Leer más...

    24 agosto 2011

    Deficiencias más comunes en los SGSI basados en ISO27001

    En este artículo se comparte con los lectores algunas de las deficiencias más frecuentes que se encuentran al momento de llevar a cabo revisiones del estilo “Análisis de brechas sobre ISO/IEC 27001:2005”.

    Como sabrán el estándar ISO/IEC 27001:2005 es el marco de referencia asociado a la implementación de sistemas de gestión de la seguridad de la información. Además, es el documento más recomendado al momento de llevar a cabo proyectos de seguridad para el cumplimiento de las principales leyes y regulaciones en materia de seguridad de la información.

    Las Organizaciones al momento de encarar proyectos asociados a la implementación de un SGSI, en primer lugar suelen requerir un “Análisis de Brecha” para conocer “Cómo están” y así poder identificar el esfuerzo, tiempo y recursos que deberán invertir para lograr su implementación y posterior certificación (si es requerido). Es en esta etapa en la cual se identifican las principales debilidades que se detallan a continuación y que resumen la postura de seguridad de una importante cantidad de empresas:
    1. Falta de Compromiso de la Alta Dirección
    2. Ausencia de una adecuada Gestión de Riesgos.
    3. Debilidades en la Gestión de Activos.
    4. Falta de Recursos
    5. Ausencia de Documentación
    6. Ausencia de Roles y Responsabilidades
    7. Resistencia al Cambio
    La numeración establecida no significa el orden de importancia de los distintos tópicos, dado que todos en mayor o menor medida impactan negativamente en la implantación de un Sistema de Gestión de la Seguridad de la Información.

    Principales Deficiencias

    Falta de Compromiso de la Alta Dirección (Req. 5)
    El estándar ISO/IEC 27001:2005 es un documento que principalmente establece la necesidad de compromiso por parte de la Alta Dirección para la adecuada definición de Alcance, Limitaciones, definición de los Roles y Responsabilidades en materia de seguridad y la Asignación de los Recursos requeridos. La formación, toma de conciencia y competencia del personal son otras responsabilidades de la Alta Dirección, junto con la participación en la revisión de la eficacia y eficiencia del Sistema de Gestión implantado. Todos estos aspectos en muchos casos, son difíciles de encontrar en las empresas. ¿Será éste el principal problema?

    “Cuando el proyecto lo impulsa únicamente TI o Seguridad, podríamos estar ante una Organización donde es muy probable que la Alta Dirección no esté comprometida”

    Ausencia de una adecuada Gestión de Riesgos (Req. 4.2.1)
    Otro tema fundamental al momento de implementar un Sistema de Gestión de la Seguridad es conocer los riesgos a los cuales se encuentra expuesta la Organización, y a través del análisis de los mismos establecer el tratamiento que se considere el más adecuado. Si bien es uno de los requisitos del estándar, es poco frecuente encontrar que hayan realizado alguna vez un análisis de riesgos. En algunos se encuentra por el tipo de actividad de la Organización, pero en muchos otros casos no se realiza. También se pueden encontrar casos en donde la Organización describe un “análisis de riesgos” y en realidad sólo han evaluado subjetivamente algunas pocas amenazas sobre los activos que más conocen, sin tener una idea clara de su valor y por otro lado sin conformar la totalidad de los activos de la Organización o al menos del proceso evaluado.

    “Saber qué nos podría pasar y el impacto que nos generaría es un elemento clave al momento de definir la estrategia de seguridad”


    Debilidades en la Gestión de Activos (A. 7.1.1)
    Un aspecto que resulta clave al momento de implantar un SGSI es el referido a los Activos de Información y el tratamiento que la Organización le da a los mismos. En principio el factor principal es contar con los activos de información más relevantes (o al menos los incluidos en el proceso que queramos analizar), algo que no es fácil de lograr y que en pocas ocasiones se encuentra. En algunos casos no existe tal inventario o es el resultado de varios inventarios, cada uno con distinto nivel de falta de información y actualización. En este sentido es importante contar con un único inventario, completo y actualizado. Algunos de los controles que se deberían realizar sobre la gestión tienen que ver con: A.7.1.2 Propiedad de los Activos, A.7.1.3 Uso Aceptable de los Activos.

    “Saber qué tenemos, para conocer qué nos podría pasar y en base al impacto que esto podría ocasionar, tomar las acciones que sean adecuadas”.

    Falta de Recursos (Req. 5.2.1)
    La provisión de recursos, aspecto fundamental para cualquier iniciativa que se quiera llevar adelante, pero en temas asociados con un SGSI resulta fundamental, y es tan importante que el estándar lo describe directamente en el punto asociado a las “Responsabilidades de la Dirección”. Esto es claramente así, si no contamos con los recursos necesarios, resultará muy difícil implantar el SGSI y luego llevar a cabo las actividades asociadas al mantenimiento y mejora del mismo. Es la Dirección la encargada de brindar los recursos necesarios. Para lograr el interés de la Dirección las áreas involucradas en los proyectos de SGSI recurren a distintos métodos, entre los que se pueden encontrar: charlas, talleres, relevamientos de seguridad, auditorias, etc. En muchos casos el interés (y los recursos) surge una vez que la Organización debe cumplir una determinada ley o regulación, como puede ser Sarbanes Oxley (SOX), PCI-DSS o lo referido con el cuidado de los Datos de Carácter Personal (Ley 25326 en Argentina o LOPD en España).

    “En Organizaciones donde la Dirección no está comprometida con la Seguridad de la Información, es frecuente encontrar muchas dificultades para la obtención de los recursos necesarios para el SGSI”.

    Ausencia de Documentación (Req 4.3.1)


    Si bien el estándar específica un apartado exclusivo orientado a los requisitos de documentación es poco frecuente encontrar que la Organización haya documentado en principio lo mínimo requerido por el estándar y además lo requerido para el correcto desarrollo de las actividades de negocio. En este sentido, en las Organizaciones que se encuentra mayor documentación es en aquellas que han tenido experiencias asociadas a la implementación de otros Sistemas de Gestión, como pueden ser de la Calidad o de cuidado del Medio Ambiente o también en aquellas que deben cumplir alguna regulación que exige la existencia de procedimientos operativos documentados (en un todo de acuerdo con lo requerido también en ISO/IEC 27001), por ej: PCI-DSS.

    Generalmente, la documentación se asocia con cuestiones burocráticas o de “pérdida de tiempo” y no con un estado de madurez superior al promedio, en el cual la Cía ha logrado identificar sus procesos y ha documentado las actividades principales de forma tal de lograr un mismo resultado sin que sea excluyente, en principio, el recurso humano que ejecuta la actividad. Es indiscutible que el orden y la visión en procesos en cualquier actividad, facilita la ejecución de controles que establecen un escenario con menor probabilidades de incidentes, errores y/o fallas. Pero a pesar de esto suele ser poco frecuente encontrarse con documentación asociada a cuestiones de seguridad en las Organizaciones.

    “La documentación de actividades o procesos clave genera la independencia requerida para no depender de quién realiza la actividad y a su vez es una herramienta que facilita la mejora”

    Ausencia de Roles y Responsabilidades (Req 5.2.2)
    Las personas que integran una Organización deben tener claro qué deben hacer para ayudar al logro de los objetivos de negocio establecidos. Esto parece ser algo muy fácil de lograr e identificar, pero en temas asociados a seguridad de la información es un aspecto difícil de encontrar con el mismo nivel de madurez que en otras posiciones. Muchas personas que trabajan en áreas de seguridad o sistemas no tienen claro que deben hacer para ayudar al logro de los objetivos de la Organización. Esto es una responsabilidad de la Dirección y el estándar lo identifica claramente en el requisito 5.2.2. Recursos Humanos es el área responsable de definir las descripciones de puesto en conjunto con los referentes de área que correspondan, pero es esta área la que debe documentar el puesto y describir claramente las responsabilidades en materia de seguridad tanto de este puesto como de cualquier otro puesto en la Organización. Esto último no se encuentra con frecuencia en las Organizaciones, sino que las personas entienden que la seguridad depende de un área específica o “de sistemas”, y no es frecuente que se identifique como una responsabilidad de todos los miembros de la Organización. En los casos en los cuales se encuentra un nivel de madurez superior es en aquellas industrias con fuerte regulación al respecto, como puede ser la industria financiera.

    “Las personas tienen que saber claramente cuáles son sus responsabilidades para el logro de los objetivos en materia de seguridad de la información”.

    Resistencia al Cambio
    Las personas se resisten a los cambios, esto no es una novedad, y obviamente no está fuera de las dificultades que vamos a enfrentar al momento de implantar un Sistema de Gestión de la Seguridad de la Información. Para ello debemos identificar los agentes del cambio que servirán de facilitadores para convertir la Política de Seguridad definida en algo tangible y objetivos cumplibles y evidenciables. Frases como “esto se viene haciendo así”, “no somos un banco”, “ya sabíamos esto” y un centenar de frases más, no son más que ejemplos de resistencia al cambio. Es importante tener en cuenta que la resistencia al cambio se debe reducir desde la Dirección de la Organización, es más, podríamos definirla en este artículo como una nueva "responsabilidad de la dirección", dado que es ésta la que tiene que marcar el camino, brindar los recursos y apoyar cada una de las iniciativas que permitan establecer el programa de seguridad que permita llevar a la realidad la Política de Seguridad de la Información.

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

    Contribución por Mariano M. del Río
    Leer más...

    23 agosto 2011

    Como suprimir el router de Telefónica en FTTH

    Qué contento que estaba yo cuando me pusieron fibra óptica en casa. Lo rápido que iba a poder descargar "distribuciones de linux", "wikipedias" y demás contenidos libres ahora. Cuando ví llegar a los instaladores de Telefonica con varias cajas blancas, rollos de fibra, cajas de herramientas, etc,… pensé que venían los Cazafantasmas.

    Como los chicos parecían majetes (y uno de ellos leía Security By Default -un saludo para Jose desde aquí-) estuve de lo más entretenido viéndoles hacer la instalación, tirar la fibra y ejecutar trabajo de precisión con los conectores necesarios. A mi pregunta, "cuál es el modelo del router para ir buscando por Internet cómo destriparlo?", me abren dos cajas y me explican que cuando tienes FTTH, necesitas dos equipos: Una unidad ONT Huawei HG 850, que hace bridge entre la conexión de fibra óptica y un cable ethernet; y un router inalámbrico, normal y corriente (de los típicos ADSL de Telefonica pero sin interfaz RJ-11) que tendrá la IP pública y hará "el routing" entre los PCs de dentro de la red e Internet.  

    Para activar la ONT, el instalador se conectó a uno de los puertos y ejecutó varios parámetros de inicialización según pude ver. Sin embargo, según me comentaron, la ONT no disponía de módulo de routing y era imprescindible disponer del otro dispositivo conectado en serie para poder tener acceso a Internet.

    Antiguamente, cuando funcionábamos con módem a través de RTB e incluso con ADSL normal mediante módems, ya era posible establecer una conexión PPPoE o PPPoA (dependiendo si era sobre Ethernet o sobre ATM) desde una máquina con Linux, teniendo la IP Pública un interfaz TCP/IP directamente en la máquina.
    Hay que decir que en el caso de una casa "normal" con varios dispositivos conectándose a internet directamente a través del router de forma directa, no es posible eliminar este último dispositivo. En mi caso, que lo que tengo es una máquina con muchas funcionalidades, que además separa entre sí varias redes a las que da el acceso a Internet y entre ellas, podemos intentar eliminar el dispositivo de routing intermedio sin problemas. Además, la configuración de NAT del router blanco tenía configurado como "DMZ host" la IP del servidor, de manera que todo el tráfico de red entraba directamente contra mi "gateway". La idea es eliminar el salto intermedio.

    Como bien podéis imaginar, según salieron por la puerta, lo primero que hice fue sentarme a trastear con los dos cacharros y ver si uno de ellos era susceptible de ser eliminado.

    Manos a la obra

    Al principio pensé que sería cuestión de 10 minutos mediante la instalación de los paquetes rp-pppoe y ppp para CentOS, crear una conexión PPPoE y a correr. La verdad es que no resultó tan sencillo como parece. La conexión PPPoE se resistía y me daba un montón de errores.

    La configuración utilizada en el fichero /etc/sysconfig/network-scripts/ifcfg-ppp0 era la que veis bajo estas líneas:

    USERCTL=yes
    BOOTPROTO=dialup
    NAME=DSLppp0
    DEVICE=ppp0
    TYPE=xDSL
    ONBOOT=YES
    PIDFILE=/var/run/pppoe-adsl.pid
    FIREWALL=NONE
    PING=.
    PPPOE_TIMEOUT=80
    LCP_FAILURE=3
    LCP_INTERVAL=20
    CLAMPMSS=1412
    CONNECT_POLL=6
    CONNECT_TIMEOUT=60
    DEFROUTE=yes
    SYNCHRONOUS=no
    ETH=eth0
    PROVIDER=DSLppp0
    USER=porsiacasoloquito@telefonicanetpi
    PEERDNS=no
    DEMAND=no
    

    Además, en los ficheros /etc/ppp/chap-secrets y /etc/ppp/pap-secrets será necesario añadir una entrada con la contraseña perteneciente al usuario.
    En la interfaz web del dispositivo intermedio (un Comtrend), el que hace el routing entre el PC y la ONT de fibra, en un primer vistazo inicial, no vi nada que permitiera ver qué estaba haciendo mal.


    Sin embargo, descargando un backup de la configuración de dicho router se pueden observar varias cosas interesantes.
    Se trata de un fichero XML que, permite ver que, para empezar, la clave de administración del router se encuentra en claro, para que el que tenga acceso a un fichero de backup, pueda además acceder al router después, además con un tag facilito <AdminPassword$gt; (un bonito detalle oye).

    <X_BROADCOM_COM_LoginCfg>
          <AdminPassword>LaPassEnClaroDeMiFraudeRouter</AdminPassword>
        </X_BROADCOM_COM_LoginCfg>
    

    Al analizarlo más en profundidad, y ya por pura curiosidad, encontré una sección que me dejó muy mosqueado:

    <url>https://main.acs.telefonica.net:7004/cwmpWeb/WGCPEMgt</url>
    <username>XXXXXX-696969R-1234A-aabbccddeeffgg</username>
    <password>123456789101112131451617181920</password>
    <periodicinformenable>TRUE</periodicinformenable>
    <periodicinforminterval>86400</periodicinforminterval>
    <periodicinformtime>2000-01-01T00:00:10+00:00</periodicinformtime>
    <connectionrequestusername>XXXXXX-696969R-1234A-aabbccddeeffgg</connectionrequestusername>
    <connectionrequestpassword>lalalaalalalalalalaalaalalalalalalalalaalalalala</connectionrequestpassword>
    

    Como la curiosidad mató al gato, intenté acceder a esta URL: Si accedo a esta URL https://main.acs.telefonica.net:7004/cwmpWeb/WGCPEMgt, el certificado está firmado por una CA de Telefónica (o eso dice), me pide usuario y contraseña, introduzco obedientemente los valores de los tags <username> y <password> (parecen valores en hexadecimal) y me aparece una página que dice:

    CPE Servlet responding
    Active session count = 213


    Analizando con TamperData, aparece una Cookie llamada "BIGipServerPool_HNM_Walled-garden" que imagino que la inyectará un balanceador F5 para fijar la persistencia de la sesión a través de un nodo de una granja de servidores web. ¿Para qué valdrá esto? Hay otros parámetros que con el mismo usuario tiene una password diferente, que al probarla no funciona. ¿Será que sirven para otorgar gestión remota al Router desde el portal Alejandra de Telefónica? No sé a vosotros, pero cada vez me da más mala espina este tipo de dispositivos que te entregan desde el proveedor con una configuración pre-establecida.

    Finalmente, en la sección de la conexión PPPoE, aparte del usuario y la contraseña necesarios, el parámetro VlanMuxID (6) hace sospechar que el tráfico podría ir en formato 802.1Q (o VLAN Tagging) en concreto con el Tag 6. Tendría además sentido el que, tanto en la intefaz web como en el fichero XML, apareciese el nombre del interfaz como ppp0.6. 

    <WANPPPConnection instance="2">
    <Enable>TRUE</Enable>
    <ConnectionType>IP_Routed</ConnectionType>
    <Name>pppoe_eth0.6</Name>
    <NATEnabled>TRUE</NATEnabled>
    <X_BROADCOM_COM_FirewallEnabled>TRUE</X_BROADCOM_COM_FirewallEnabled>
    <Username>porsiacasoloquito@telefonicanetpi</Username>
    <Password>lapassword</Password>
    <X_BROADCOM_COM_IfName>ppp0.6</X_BROADCOM_COM_IfName>
    <X_BROADCOM_COM_BcastAddr>255.255.255.255</X_BROADCOM_COM_BcastAddr>
    <X_BROADCOM_COM_VlanMux8021p>1</X_BROADCOM_COM_VlanMux8021p>
    <X_BROADCOM_COM_VlanMuxID>6</X_BROADCOM_COM_VlanMuxID>
    <DNSServers>80.58.61.250,80.58.61.254</DNSServers>
    <PortMappingNumberOfEntries>0</PortMappingNumberOfEntries>
    <X_BROADCOM_COM_FirewallException>nextInstance="12"
    </X_BROADCOM_COM_FirewallException>
    </WANPPPConnection>
    

    Me diréis: "Oye Lorenzo, en la imagen que has puesto arriba aparece claramente VlanMuxID 6". Pues sí, tenéis razón, pero yo no me dí cuenta hasta que bajé el backup de la configuración. -Mi cerebro debe procesar mejor los ficheros de configuración XML que las imágenes, no sé-

    Así pues, en vez de hacer la conexión PPPoE en modo untagged (el normal para un dispositivo de usuario en una red), habrá que crear primeramente un interfaz virtual "tagged".
    Para ello, en CentOS creamos el fichero /etc/sysconfig/network-scripts/ifcfg-eth0.6 con el siguiente contenido:

    DEVICE=eth0.6
    ONBOOT=yes
    BOOTPROTO=static
    VLAN=yes
    

    Haciendo la prueba levantando el interfaz, se ve que se levanta correctamente un interfaz sin IP llamado eth0.6 y que el módulo 8021q se encuentra cargado y utilizado

    [root@Carmen ~]# ifconfig eth0.6
    eth0.6    Link encap:Ethernet  HWaddr AA:AA:AA:AA:AA:AA  
              inet6 addr: fe80::fff:fff:ffff:d1fc/64 Scope:Link
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:99292 errors:0 dropped:0 overruns:0 frame:0
              TX packets:76372 errors:0 dropped:4 overruns:0 carrier:0
              collisions:0 txqueuelen:0 
              RX bytes:122826179 (117.1 MiB)  TX bytes:9347498 (8.9 MiB)
    
    [root@Carmen ~]# lsmod | grep -i 802
    8021q                  24413  0 
    garp                    7310  1 8021q 
    

    Ahora sólo queda modificar la configuración del fichero /etc/sysconfig/network-scripts/ifcfg-ppp0 para que el parámetro ETH que antes era "eth0" pase a ser "eth0.6".
    Levantando el interfaz se observa cómo se crea correctamente un interfaz nuevo llamado ppp0 con la IP pública que Telefonica me asigna.

    Ahora sólo queda modificar la configuración de algunas aplicaciones que se "bindeaban" en el interfaz pública directamente, anteriormente eth0, para que pasen a hacerlo al ppp0. Además hay que modificar la política de firewall/NAT, configuración de herramientas de análisis como Snort, ntop, y demás juguetitos para que monitoricen el nuevo interfaz.

    Si anteriormente, teníais configurado el NAT entrante del router para que determinados puertos fuesen redirigidos a puertos de algún PC interno, tened cuidado puesto que actualmente la máquina Linux "está" directamente en Internet. Si tenéis algún servicio mal configurado, que anteriormente no era un riesgo alto por no estar comunicado desde fuera, ahora sí que lo estará, así que revisad las reglas del firewall de la máquina.

    He de decir que en CentOS 4.X al levantar el interfaz ppp0 se provocaba un core dump que hacía que se reiniciara el servidor. Escribo ahora este post puesto que he migrado a Centos 6 y en la nueva máquina ya no da crashes como los anteriores. Previamente probé en una Fedora Core 13 y funcionaba también estupendamente.
    Leer más...

    22 agosto 2011

    Convergence ¿El futuro de SSL?

    Mucho se ha hablado sobre los 'males' que aquejan al protocolo SSL y en general al modelo PKI que subyace tras el.

    Desde entidades que emplean algoritmos de baja calidad, entidades que son hackeadas y emiten certificados fraudulentos o incluso bugs del protocolo en si.

    Pero hasta ahora, salvo vagas ideas, nadie ha cogido el toro por los cuernos y ha propuesto una alternativa. En la pasada BlackHat, el famoso investigador Moxie Marlinspike (autor de SSLstrip) se ha lanzado al ruedo con una propuesta alternativa al esquema actual.

    Frente al tradicional funcionamiento de las entidades certificadoras (CAs) donde un numero X de organizaciones se arrogan la capacidad de emitir certificados SSL y luego negocian con los desarrolladores de los navegadores que incluyan su 'certificado raíz', Moxie propone un modelo que me recuerda, en parte, al esquema GPG.

    La idea es que seas tú mismo quien decida si das o no das por bueno un certificado SSL, sea de una organización en concreto o incluso un certificado auto-firmado creado por alguien ajeno a las tradicionales entidades de certificación.

    Como es lógico, muy pocas personas tienen la perspectiva o capacidad para dilucidar si un certificado merece o no merece confianza, por lo que aparece la figura del 'notario' que es una persona / organización en la que tu decides confiar y delegas en el la confianza, por lo que todos los certificados que el de por buenos serán buenos para ti.

    De momento el proyecto ha liberado una extensión para Firefox y dos notarios activos. Se espera que si el proyecto cuaja, aparezcan mas notarios disponibles.

    Mi opinión personal es que la idea es bastante buena, el concepto de que los 'notarios' sean dinámicos, tengan que tener una fiabilidad adquirida por consenso y reputación y que en caso de que 'metan la pata', se le pueda retirar la confianza, supone un avance frente al modelo tradicional.

    Además no olvidemos que a partir de Windows Vista, Microsoft ha convertido la gestión de los certificados digitales en algo oscuro en el que es difícil intervenir

    No obstante, creo que Moxie se deja en el tintero otro punto importante a la hora de 'vender' el producto. Mas allá de que las entidades de certificación son 'hackeables' o que dado el número de certificados raíz aprobados en los navegadores, resulta creíble que algunas entidades de certificación 'colaboren' con gobiernos para vulnerar la privacidad, se deja el hecho de que hace tiempo que las CAs dejaron de tener escrúpulos a la hora de emitir certificados y dejaron a un lado su rigor para simplemente emitir certificados por 10 dólares. Sin verificar lo que hay detrás

    URL del proyecto: Convergence
    Leer más...

    21 agosto 2011

    Enlaces de la SECmana - 85


    Leer más...

    20 agosto 2011

    Vuestros "ETHERNET EXPOSED" - IV

    A este paso, vamos a tener que hacer la sección semanalmente, gracias a las contribuciones que nos estáis enviando últimamente. ¡Muchísimas gracias a todos! Vamos a mostrar más imágenes que nos habéis ido enviando estos últimos días, en las que se vean tomas de red ethernet en lugares poco frecuentes o curiosos.

    En algún que otro comentario, nos han pedido que escribamos acerca de posibles acciones a realizar tanto ofensivamente (si veo una toma de red y me enchufo ¿cómo empiezo?) como defensivamente (como evitar intrusiones mediante conexiones a tomas de red sin vigilancia o accesibles). Efectivamente, esta sección comenzó como preámbulo para eso mismo, y esperamos poder ofrecer dichos posts muy pronto, pero mientras, ¡comencemos!

    En primer lugar, Victor Gil nos envía una foto de un ETHERNET EXPOSED que se encontró en una farmacia de una cadena muy reconocida de Venezuela, llamada Locatel. Ésta en concreto es de una de las sucursales de Maracay:


    Podría ser que dicha toma "alimentase" de red al sistema que se encuentra en la parte superior de la imagen, quién sabe...

    La siguiente imagen nos la ha enviado Igor, y nos comenta que se encontró lo siguiente en el evento Euro Forensics en Turquía:


    Con lo fácil que hubiera sido dejarlo en la pared...o ¿qué esperaban? ¿Que los huéspedes terminasen la instalación? Bueno, el caso es que hay tenemos un nuevo punto de entrada.

    Finalmente, nuestro compañero Lorenzo nos envía estas fotos, capturadas nada más salir del ascensor de acceso al aparcamiento del Hotel Arts Vip Executive de Lisboa:


    Nos comenta lo siguiente: "Según bajo por el ascensor a la planta -2 del parking, se abren las puertas y encuentro ese cuadro. Bajo él un empalme de una conexión de red hecha entre un RJ45 y una roseta que viene de vaya usted a saber de dónde."

    Personalmente, creo que debería bajar el cuadro un poco más de donde está y así poder tapar esta "ñapa".

    ¿Te han sonado estas situaciones y escenarios? ¿Tienes localizadas tomas de red ethernet en algún lugar curioso? ¡No dudes en enviárnoslas a nuestra cuenta de contacto!

    ---------------
    [+] ETHERNET EXPOSED: Encuentra tomas de red al descubierto
    [+] Vuestros "ETHERNET EXPOSED" - I
    [+] Vuestros "ETHERNET EXPOSED" - II
    [+] Vuestros "ETHERNET EXPOSED" - III
    [+] Vuestros "ETHERNET EXPOSED" - IV
    [+] Vuestros "ETHERNET EXPOSED" - V
    Leer más...

    19 agosto 2011

    robots.txt, ése gran desconocido.

    Los que leáis a Chema en El Lado del Mal ya debéis saber lo poco que conocen algunos administradores de webs el fichero robots.txt, es más, con una pequeña búsqueda en Google (que no Bing), podemos encontrar sus posts que hablan de todo tipo de pifias, malas configuraciones o robots.txt's demasiado inflados de información.

    Éstos últimos pueden ser de gran utilidad para un auditor de seguridad o para el chico (¡o chica!) malo de turno.

    La razón es que, en ocasiones, se ponen rutas que nadie debería conocer en el robots.txt, con la confianza de que nadie a parte del bot de Google lo mirará. Por ejemplo, un panel de administración o un directorio con datos privados jamás deberían estar en un robots.txt.

    Claro, que a veces nos ponen los dientes largos pero luego el directorio no tiene permisos para que accedamos.

    Pues ésto precisamente es lo que permite verificar de forma automatizada la nueva herramienta CheckMyRobots.

    A veces el fichero robots.txt tiene tal cantidad de entradas Disallow que verificar a mano si son accesibles desde fuera se convierte en una tarea larga y tediosa.

    Para utilizar CheckMyRobots sólo tendremos que pasarle el sitio web que queremos analizar, y él solo leerá el robots.txt y recorrerá todas las entradas Disallow para comprobar su estado.

    Por ejemplo, si probamos con la web de RTVE:

    ./checkmyrobots.py www.rtve.es
    robots.txt fetched, parsing ...
    /buscadorWeb [302 - Moved Temporarily]
    /buscador [301 - Moved Permanently]
    /alacarta/*.xml$ [301 - Moved Permanently]
    ...
    /css/ [404 - Not Found]
    /rtve/components/parrilla/popup/ [404 - Not Found]
    ...
    /sinatra/swf/flvplayer/ [403 - Forbidden]
    /visor/flvplayer/ [404 - Not Found]
    /visordeportes/swf/flvplayer/ [403 - Forbidden]
    ...
    /television/entretenimiento/ [200 - OK]

    La información está recortada, pero podemos ver que nos muestra el directorio, el código HTTP y el motivo.

    Está escrito en Python, y ya podéis descargarlo desde el repositorio de SbD.
    Leer más...

    18 agosto 2011

    Concursos online, un peligro para nuestros datos

    Ultimamente no paran de aparecer concursos online de distintas marcas que nos invitan a participar eligiendo nuevos productos, participar en su promoción o desarrollando sobre sus plataformas.

    En general, sobretodo si se trata de grandes empresas en las que podemos tener depositada cierta confianza, no dudamos en participar, pues no hay mucho que hacer y el premio suele ser bastante interesante. Ahora bien, ¿en realidad nos merece la pena la posibilidad de ganar el premio frente a brindarle a estas compañías una gran cantidad de datos personales?

    Dejando de lado los términos y condiciones que podamos aceptar cuando vamos a participar en un determinado concurso, me voy a centrar en la seguridad de esos sistemas y la facilidad que pueden tener los delincuentes de acceder a toda la información que contienen.

    Disclaimer:
    No me hago responsable del uso que pueda darse de la información que se publica a continuación.
    Los ejemplos que se van a dar corresponden a concursos ya finalizados por lo que no supone un riesgo para los datos de los concursantes recogidos en los mismos.

    Antes de empezar, basta decir que podríamos suponer que al encontrarnos ante empresas de cierto tamaño y visibilidad los concursos gozarían de las medidas de seguridad necesarias para evitar el acceso a los datos o la manipulación de los mismos pero, viendo lo que ocurrió con Sony y todos los fallos 'de libro' que se descubrieron en muchos de sus servicios web, no podemos fiarnos de nadie.

    El concurso que voy a poner como ejemplo es el llevado a cabo por HP como promoción de sus impresoras e-print, Generación E-Print. En este concurso se pide a los usuarios que realizen una foto y la envíen a un email de contacto quedando registrada en el sistema y pudiendo ser votada con el objetivo de ganar una de las impresoras (o aparecer en el mural final).

    La vulnerabilidad se encontraba en el sistema de voto, siendo ésta un Blind-SQLi. Además, la explotación del mismo era extremadamente sencilla pues era un boolean 'de libro'.

    La url afectada era la siguiente:
    http://generacioneprint.es/votar.php?id=BSQLi&valor=X

    Por lo tanto, era trivial para una persona de moral relajada acceder a la base de datos del concurso y obtener los datos personales de todos los concursantes.

    Ahora bien, ¿era posible modificar el resultado del concurso?
    Sorprendentemente se podía alterar el resultado de forma trivial, pues no validaban el contenido de la variable 'valor' (correspondiente a la puntuación/estrellas que se le daba a la fotografía) permitiéndonos inyectar el valor que nos interesara (desde aumentar en miles los votos de una fotografía como el reducir el de otras introduciendo un número negativo). Como podemos ver, no había que recurrir a ningún método complejo para ser nosotros los ganadores del concurso.

    Cabe destacar que la página del concurso no dispone de ningún email o formulario de contacto, dificultando la notificación de estas vulnerabilidades. Intenté ponerme en contacto a través de Twitter (el que ponían en la página del concurso) pero no hubo respuesta:


    A pesar de que haya hablado únicamente de las vulnerabilidades descubiertas en el concurso de HP (por ser el único que no sigue activo), cabe destacar que actualmente todos los concursos con los que me he encontrado (y no son pocos) eran vulnerables a distintos ataques, pudiendo obtener finalmente todos los datos de los concursantes.

    Ya para terminar, muchos de los servicios web de estos concursos son realizados por terceros, lo cual sorprende que tengan vulnerabilidades tan 'de libro' (sobre todo teniendo en cuenta lo que habrán cobrado por el desarrollo). Un caso similar al de HP ha ocurrido con Microsoft, aunque en este caso he podido contactar con ellos y lo están solucionando (los demás pertenecían a empresas de otros sectores, como p.e Danone).

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

    Contribución gracias a Luis Delgado

    Leer más...