Transcripciones de charlas de diferentes eventos de seguridad.

Hoy en día hay muchas charlas de seguridad, conferencias, congresos, reuniones, donde se expone y trata las últimas técnicas de ataque, defensa, tácticas de evasión… Casi siempre son interesantes, y muchas veces se tratan temas desde puntos de vista cuando menos, originales.

En la web www.privacy-pc.com publican, entre otras cosas, transcripciones de las charlas de los ponentes en distintos eventos. Como es muy complicado ir a todos o estar consultando continuamente las páginas web de los múltiples saraos (Defcon, Blackhat, Brucon, Shmoocon, TroopersHITB-AMS…), creo que es un buen recurso para tener a mano.

Como ejemplo de charlas diferentes de lo que suele ser habitual, os dejo esta, donde se hace una comparación entre lo que es, cómo actúa y cuál es el fin de un virus a nivel biológico respecto a su análogo de bits, con los respectivos métodos de identificación y demás por gente de Fortinet.

Saludos

Credenciales de acceso en claro en ficheros de configuración

Después de ver en twitter una serie de comentarios entre Lorenzo (@lawwait) y Borja (@Bberasatigui) sobre el comando unset histfile o export histfile=”/dev/null”, me vino a la cabeza la variable http_proxy. Se usa para poder salir por la consola de Linux por el proxy de turno. Para definirla, la sintaxis suele ser algo tal que así “export http_proxy=http://username:password@proxy.thing.com:8080/” Sí, uno sólo puede acceder al .bash_history de su propia sesión, no al del resto, al menos así debería ser. Pero, en un entorno de laboratorio, no se suele tener mucho cuidado en las configuraciones, permitiendo root por ssh o directamente usando siempre ese usuario para todo.

Sin embrago, hay casos en los que no depende de la sesión con la que estés interactuando con el sistema. Para poder usar las herramientas por consola de gestión de paquetes (aptitude, yum…) hay veces que no es suficiente con definir esta variable, se deben añadir los datos en algunos ficheros de configuración. En el caso de Ubuntu (supongo que debian también), /etc/apt/apt.conf o en el de RedHat/Fedora/CentOS /etc/yum.conf. Pero éstos no son los únicos ficheros, también te puedes encontrar estos datos de acceso del proxy dentro de .wgetrc por ejemplo. La sintaxis es la misma o muy parecida en todos.

http_proxy=proxy.host.com:8080
ftp_proxy=proxy.host.com:8080
proxy_user=MyUserName
proxy_passwd=MyPassword

Hay formas de dejar esto configurado y que sea algo más “seguro”, teniendo en cuenta que está una contraseña escrita en claro en un fichero editable 😦 que sería dar sólo permisos de lectura y escritura a root, dejando configurado un usuario único para ese cometido.

Es una forma extremadamente sencilla y fácil de averiguar las credenciales de alguien de la compañía, sin hashes, Jonh the ripper y demás molestias 🙂

En fin, ficheros a tener en cuenta a la hora de realizar una auditoría en una empresa. Como siempre, tener una buena política de usuarios implantada facilita mucho la labor, pero sin descuidar los entornos de prueba, laboratorios de desarrollo y demás, ya que parece que las buenas prácticas se olvidan aquí.

Saludos

RootedCON

Dentro de poco volveremos a disfrutar en Madrid de la Rooted. He asistido hasta ahora a todas las ediciones y este año no va a ser menos.

Una opción muy interesante del congreso son los llamados rootedlabs, creo que son una buena forma de tener un primer contacto con la seguridad en su lado más práctico. Son jornadas densas, con mucho temario por ver, pero su objetivo no es ser un curso o una guía, yo los veo como una introducción para que la curiosidad pique, para que a partir de lo que en ese día te enseñen, tu puedas ir tirando del hilo por ti mismo.

Por cierto, ya han publicado la agenda de ponencias para que se pueda consultar.

Nos vemos en la rooted.

Saludos

¿Twitter owned?

Levantarte un sábado por la mañana y leer esto, esto y esto más lo que vendrá en otros blogs, listas de correo, podcast y demás, hace que durante un tiempo  te hagas preguntas del estilo ¿Estará mi usuario afectado? ¿Cambio ahora la contraseña actual por otra? ¿Será esto útil o la intrusión no ha sido aún completamente erradicada? ¿Tengo algún otro servicio con el mismo usuario y contraseña que en twitter? Seguro que la mayoría estáis pensando si eso es así o no. Todos tenemos esos conceptos claros, pero no siempre los cumplimos y es ahora cuando nos entra por unos segundos el sudor frío.

El incidente aún se está investigando, por lo que habrá más datos más pronto que tarde. Lo que se debe sacar en claro de estas situaciones es que nadie está a salvo de una intrusión, por mucho empeño y cuidado que se ponga. Con respecto a las contraseñas, las buenas políticas son de sobra conocidas, pero a modo resumen:

  • No usar jamás la misma combinación de usuario/contraseña. En un caso como el de hoy, hace que en vez de estar preocupados por un único servicio online lo estemos por todos.
  • Que las contraseñas sean fuertes, mayúsculas, minúsculas, números, caracteres especiales, una longitud elevada… ayudan mucho en los ataques de fuerza bruta si en una intrusión se hacen con los hashes de la BBDD. Hay gestores de contraseñas estupendos que ayudan a generarlas y guardarlas de forma segura y ordenada como keepass, lastpass etc
  • Cambiarlas es una buena forma de minimizar riesgos cada cierto tiempo. Si alguien ha accedido a los hashes y la empresa no se ha dado cuenta, el atacante tiene mucho tiempo para romperlas sin que nadie se entere.

Todo lo anterior no garantiza nada, pero ayuda, salvo en el caso de que estemos dados de alta en alguno de los servicios que ofrecen las empresas que están aquí. Envían las contraseñas en claro cuando te das de alta o cuando olvidas las credenciales. Esto quiere decir que o bien las tienen guardadas en claro o usan con una función reversible. Hay más aparte de las que están ahí, si quieres y conoces alguna, puedes colaborar y añadirla a la lista.

Saludos

Actualización

La gente de Naked Security está haciendo un seguimiento bastante bueno sobre la intrusión, haciendo un artículo con varias preguntas y respuestas al respecto.

¿Dónde guardar las copias de seguridad?

Seguimos un poco con los temas de backup y recuperación de información. En el anterior artículo, nos centrábamos sobretodo en la ordenación de la información, cómo hacerlo, qué criterio seguir y demás. Ahora vamos a mirar un poco al sitio donde se almacena la información.

Es creencia popular, preguntad sino a cualquiera de vuestros familiares/amigos, que tener la información en un dispositivo externo (suele ser un disco duro) ya es una copia de seguridad. Muchas veces ese dispositivo es el que centraliza el almacenamiento de la información, el único donde se guarda… ¿Veis el fallo? Se ha asociado tanto la idea que el disco externo te saca de problemas, que mucha gente ya no usa otra cosa (el del propio equipo por ejemplo), se queda sólo con el externo, pensando que así ya está todo hecho. No ayuda el hecho de que ya no se usa sólo un único equipo, está el del trabajo, el portátil de casa, puede que el de la pareja, otro de sobremesa y claro ¿Cómo tener acceso a los datos en todos?

Por eso ahora, y de un tiempo a esta parte, proliferan las soluciones de almacenamiento en la nube (dropbox, sugarsync, skydrive, megaupload, fileshare y similares), buscando que la información esté disponible en cualquier momento, lugar y además sincronizada. Pero hay que tener cuidado, leer bien los términos y condiciones del servicio y, sobre todo, los casos en los que nos podemos encontrar… ¿Cuánta gente perdió datos con todo el embrollo de megaupload? Sí, no sólo se usaba para bajar pelis 😛

Como siempre, cada uno es un caso particular y único, no hay una receta milagro para todos, pero sí una serie de directrices que se pueden seguir para minimizar riesgos. Diferenciar entre datos importantes de los que no lo son. Esto es básico. De los primeros, tener copia en diferentes sitios y ubicaciones, siempre de forma ordenada, que las copias estén sincronizadas o al menos se sepa la fecha de creación y el contenido. Podría ser en un disco local propio, otro  externo y la nube. Es sólo un ejemplo. De los segundos, con tener copia en local y otra externa, sería suficiente. 

Son todo ideas obvias, que si se piensan, son muy lógicas, pero que no todo el mundo sigue en su día a día y, cuando uno se da cuenta de que algo no está, es justo cuando más lo necesita.

Aunque esto lo he escrito pensando en el usuario de casa, no son pocas las empresas que he visto con este mismo problema, no saber qué información es importante de la que no, hacer copias de seguridad de todo e invertir mucho dinero en soluciones de backup completamente sobredimensionadas por no tener ordenada y consistente su información, pero esto ya se tratará más adelante 🙂

Saludos

El problema de no saber cómo guardar los datos.

Que hoy día estamos saturados de información, no se puede negar, ya no sólo en nuestros respectivos trabajos, sino en nuestros propios hogares. Guardamos todo, fotos (móvil, cámara, la que nos mandan por email o whatsapp), pero también documentos, canciones, vídeos, proyectos, scripts para tareas concretas… Así hasta el infinito, y guardamos, con suerte, una copia de todo en un HD externo, la nube u otro sistema de almacenamiento que se os ocurra. Perfecto ¿no? Pues depende. ¿De qué? De que realmente sepamos qué tenemos, dónde se guarda y, sobre todo, cómo lo podemos localizar. Parece trivial ¿Verdad? Contestemos a las siguientes preguntas en caso de desastre. Imaginemos que perdemos el HD de nuestro equipo y necesitamos de forma urgente unos scripts que desarrollamos para unas tareas rutinarias, pero que nos llevaron nuestro tiempo, o las fotos de unas vacaciones, por ejemplo:

¿Qué tenemos? Hombre, la copia de seguridad, perfecto

¿Dónde? En el HD externo, la nube o lo que sea, perfecto

¿Cómo lo localizamos? Ummm pues esto depende… ¿Qué criterio usamos para guardarlo? ¿El nombre? ¿El proyecto para el que se desarrollaron? ¿El lenguaje usado (perl, batch, python, php…)?¿La función? ¿La fecha?

Parece que no va a ser sencillo. O se tiene un método claro sobre cómo ordenar la información, o para cada dato que guardemos, usaremos uno distinto. A los 5 minutos de almacenarlo, lo tendremos clarísimo, incluso a los pocos meses también, pero… ¿Cuándo han pasado uno o dos años? ¿Y si han pasado 5? Algo que todos hemos hecho en algún momento ha sido usar una línea temporal, por años (backup2005.zip) o por meses (backup200507.zip)… Esos ficheros ¿Qué contienen? ¿Recuerdas lo que pusiste en ese fichero? ¿Es un backup de todo hasta esa fecha? ¿Es de los datos del mes de julio del año 2005? ¿Tiene sólo documentos? ¿Hay alguien que recuerde lo que hizo en ese mes y ese año? Si se usa un proyecto concreto, está muy bien, pero cuando éstos se alargan mucho, 3 años, dentro de la carpeta de, por ejemplo, estanco de chucherías ¿Qué hay ahí dentro? ¿Cómo está ordenado? Se tiene el mismo problema de nuevo.

Estamos hablando de una cuestión de orden, sí, pero que no es trivial hoy, y en el mañana lo será menos aún ya que seguiremos guardando más y más información, posiblemente sin un criterio concreto que nos permita recuperarla. ¿Cómo podemos solventar esto? Cada tipo de archivo (documentos, fotos, películas, scripts desarrollados, proyectos…) tendrá su propia forma de recuperación.

¿Qué hacer entonces? Eso ya queda para el criterio personal de cada uno, simplemente quería hacer pensar acerca de la forma que tenemos de acceder a la información almacenada. Habrá formas mejores o peores, pero desde luego, lo importante es que cada uno sepa cómo encontrar lo que busca en el menor tiempo posible.

Saludos

El reto del físico a la comunidad hacker

¡Cuánto bombo ha habido con esto en los últimos días! Han aparecido múltiples noticias al respecto aqui, aqui, unos cuantos correos en la lista de correo de la rooted, también aqui… en fin, se ha hablado mucho de ello.

Mi conocimiento en esta materia es escaso, soy un simple aficionado, pero hay ciertas referencias que tengo en este campo que son de gran ayuda, Arturo Quirantes (@elprofedefisica) se define como aficionado, pero es un auténtico crack, Jorge Ramio y Alfonso Muñoz están entre ellas, y el primero ha escrito en naukas un artículo en el que da su particular visión de la patente y por otro lado Jorge y Alfonso firman un documento titulado Primeras impresiones sobre la solicitud de patente “Procedimiento de doble criptograma simétrico de seguridad de Shannon por codificación de información para transmisión telemática y electrónica” donde, como resúmen, no le ven mucho futuro.

Merece la pena leerlos con tranquilidad para saber realmente de lo que se está hablando.

Saludos