Security By Default

Optimización de Mod_SSL

noreply@blogger.com (Yago Jesus) — Thu, 02 Sep 2010 06:08:00 +0000

Afortunadamente, cada vez mas se está tomando en cuenta que determinados procesos realizados a través de la web estén lo suficientemente protegidos como para evitar que puedan ser comprometidos por cualquiera que comparta el canal donde estemos realizando la operación. Con el advenimiento del 'siempre conectado', las redes wifi abiertas, disponibilidad de internet en hoteles y un largo etc se ha hecho necesario que cualquier proceso de identificación esté cifrado bajo SSL.

El 'problema' de usar SSL es que implementarlo de forma masiva supone dimensionar correctamente la carga extra computacional que conllevan las operaciones de cifrado. Evidentemente existen soluciones como los 'aceleradores criptográficos' que aligeran bastante la carga, no obstante, mod_ssl se puede 'tunear' de forma que sea mas óptimo. Con idea de hacer una pequeña checklist de tips para optimizar mod_ssl encontré un artículo bastante bueno que merece la pena resumir y traducir. Evidentemente estamos hablando de optimizar no de fortificar (difiere en el sentido que el objetivo no es proteger el webmail de Barack Obama, el objetivo es llegar a un compromiso de seguridad / desempeño a gran escala)

Longitud de clave en los certificados: Tal vez de los tips mas obvios: dimensiona la longitud de la clave en tu certificado en función de lo que vayas a proteger. Es obvio que un tamaño de 1024 en un banco suena a poco (máxime cuando ya se empieza a desaconsejar ese tamaño de clave), por otra parte, si lo que pretendes proteger es el acceso a un foro, una longitud de 2048 le dará una carga extra de trabajo a tu/s servidores que puedes ahorrarte.

Elección de algoritmos de cifrado y hash: La elección de tus algoritmos de cifrado puede suponer un desempeño de hasta tres veces mas óptimo si, por ejemplo, empleas RC4 en vez de AES-256. Obviamente RC4 es un algoritmo, a estas alturas, muy cuestionado y se debería usar para procesos donde la información NO sea crítica.

Para configurar mod_ssl empleando RC4-SHA como primera opción y AES128-SHA como segunda, debemos configurar las siguientes directivas:

SSLCipherSuite RC4-SHA:AES128-SHA:ALL:!ADH:!EXP:!LOW:!MD5:!SSLV2:!NULL

SSLHonorCipherOrder on

Es importante definir la directiva SSLHonorCipherOrder para especificar que, 'quien manda', es el servidor y no el cliente (lo habitual es que sea el cliente quien defina la suite de algoritmos)

Elección del tipo de cache para sesiones SSL: Normalmente cuando se carga una web, debido a lo ricas en contenido que suelen ser, no se hace en un simple GET, lo normal es lanzar varias peticiones en paralelo contra el servidor. La forma en la que funciona Apache, con sus procesos 'forkeados' provoca que al servir una pagina web en varias peticiones paralelas bajo SSL se necesite una forma en la que cada proceso tenga acceso a la sesión SSL ya negociada (evitando así un montón de nuevas negociaciones SSL), para eso implementa un sistema de 'cache' que admite diferentes tipos de almacenamiento (dbm y shm). shm es notablemente mas rápido así que esa debería ser la elección.

Para configurar mod_ssl empleando caché de sesiones con shm configuramos la directiva así:

SSLSessionCache shm:/usr/local/apache/logs/ssl_gcache_data(512000)

A la hora de elegir la ruta del fichero-cache hay que tener la precaución de que el fichero tenga los permisos correctos y no sea 'leible' por cualquier usuario.

Activación de OCSP Stapling: Este tip será probablemente del que menos beneficio vamos a obtener. Para dar contexto al tema, digamos que cuando un servidor web te ofrece un certificado SSL, tu navegador debería contactar con el servidor OCSP de la CA que emitió ese certificado y preguntar si ha sido revocado. En la práctica casi nadie lo hace (Firefox tiene la opción pero está desactivada por defecto). Como es de imaginar, si añadimos el punto extra de tener que contactar con el servidor OCSP y pedir una validación, esto nos va a suponer un buen número de segundos extra hasta que la negociación SSL inicial se completa. Para mitigar esto surge OCSP Stapling que, básicamente, lo que hace es almacenar una petición OCSP reciente y anidarla en la negociación SSL, de forma que el cliente, como parte de la información que le suministra el servidor, conoce que ese certificado ha sido validado hace relativamente poco tiempo, ahorrando de esa forma que el cliente tenga que lanzar la petición por su cuenta.

Para configurar OCSP Stapling debemos añadir las siguientes directivas:

SSLUseStapling on

SSLStaplingCache "shmcb:logs/stapling_cache(128000)"

Una vez hecho esto y re-iniciado el servidor web, es muy deseable comprobar con el comando:

openssl s_client -host www.miweb.com -port 443 -tls1 -tlsextdebug -status

que obtenemos una respuesta positiva y que las peticiones al servidor OCSP están funcionando. Así mismo con el comando:

openssl s_client -debug -tls1 -host www.miweb.com -port 443

podemos ver si la elección del algoritmo de cifrado está funcionando correctamente.

[*] El artículo original en inglés con mas tips e ideas

Rooted CON 2011: Solicitud de ponencias

noreply@blogger.com (José A. Guasch) — Wed, 01 Sep 2010 06:14:00 +0000

Ya está aquí, ya llegó, ¡comienza la cuenta atrás! Tras meses y meses de casi-absoluto silencio, el congreso Rooted CON vuelve con nueva web, y con el comienzo del proceso de solicitud de ponencias (también conocido como Call-For-Papers o CFP).

Hace unas semanas se dejaba ver una nueva actualización en la web, que indicaba las fechas en las que se celebraría la segunda edición de Rooted CON, 3, 4 y 5 de Marzo de 2011, tras el éxito de la primera edición de este año que nos dejó tanto material. Con casi 500 asistentes, en Rooted CON 2010 pudimos disfrutar de tres días repletos de ponencias interesantes, nuevas herramientas, caras conocidas, leyendas del hacking en España, conchas Codan, entusiasmo y pasión por la seguridad informática, y como no, esta próxima edición no nos la podemos perder.

A continuación copypasteo el Call for Papers; ya sabéis, si este verano os ha cundido en cuanto a temas interesantes que poder mostrar al mundo o tenéis en mente algo que podría dar mucho que hablar, no dudéis en completar el formulario de inscripción de ponencias... ¡y a por todas!

-------------- Solicitud de Ponencias | Call For Papers /RootedCON 2011 --------------

Acerca de Rooted CON

Rooted CON es un Congreso de seguridad informática que se celebrará en Madrid (España) los días 3, 4 y 5 de marzo de 2011, cuyo espectro de asistentes oscila desde estudiantes a fuerzas del estado y servicio secreto, pasando por profesionales del mercado de la seguridad, juristas e, incluso, entusiastas de la tecnología (y de otras cosas).

Tipo de charlas

El Congreso se estructura en charlas y ponencias de dos tipos principales:

Rápidas: con una duración de unos 20 minutos.
Estándares: con un máximo de 50 minutos de duración.

De acuerdo con las propuestas que se reciban, se determinarán las cantidades de charlas de cada tipo a confirmar; no existe un formato rígido de congreso sino que la agenda se estructura de acuerdo a la demanda y oferta que se vaya recibiendo.

Temas relevantes

Se consideran temas y charlas interesantes, pero no exclusivamente limitadas a:

Hacking, cracking, phreaking, virii, WiFi, Voz sobre IP, GSM...
Ingeniería inversa, debugging, hooking, fuzzing, exploiting,...
Herramientas o técnicas defensivas y ofensivas punteras.
Seguridad en "la nube", seguridad y hacking en entornos virtuales, productos y servicios en "la nube", ...
Técnicas de criptografía, esteganografía, canales subliminales, ...
Ciencia forense, investigación y técnicas antiforense.
Redes, protocolos y hacking de capas 2 y 3, encapsulación, ...
Se valorarán especialmente temas y propuestas que no se presentaran en la edición anterior de Rooted CON.

Procedimiento para enviar propuestas

Solamente se admitirán propuestas recibidas a través del formulario de inscripción, que puede accederse en la URL:

https://www.rootedcon.es/cfp2011-esp/ (español)
https://www.rootedcon.es/cfp2011-eng/ (inglés)

Cualquier otro formato, medio o comunicación que no sea a través del citado formulario, no se considerará a efectos de ponencias presentadas y, por supuesto, no será tenido en cuenta o valorado.

Agenda e hitos relevantes

01 Septiembre 2010 - se abre el proceso de inscripción de ponencias ("Call for Papers").
31 de Diciembre 2010 - fecha final de presentación de propuestas.
Enero de 2011 - selección de ponentes y charlas.
Febrero de 2011 - material y documentación entregada a la organización.
3,4 y 5 de Marzo 2011 - Rooted CON 2011

Qué está incluido como ponente

Todos los ponentes recibirán las siguientes coberturas:

Cena con el resto de ponentes la noche previa al congreso.
Alojamiento por cuenta de la Organización
Gastos del desplazamiento.
Acceso libre a todas las conferencias.
Acceso a la fiesta de cierre y tickets para copas gratis.
Patrocinadores y Colaboradores

Rooted CON siempre está buscando patrocinadores de calidad para la organización del Congreso, por lo que si existe un interés, por favor, pónganse en contacto con:

patrocinadores-AT-rootedcon.es

Toda ayuda, ideas, propuestas o colaboraciones que se nos hagan llegar, serán tenidas en cuenta y valoradas por parte de Rooted: dependemos de vosotros para que este Congreso sea uno de los más originales que se realicen.

Contacto

Para consultas, dudas o cualquier tipo de sugerencia:

info-AT-rootedcon.es

Nuestros enlaces

Web: http://www.rootedcon.es
Twitter: @rootedcon
Facebook: http://bit.ly/fbookrooted
LinkedIn: http://bit.ly/linkedinrooted
Lista de correo Rooted: rootedcon@listas.rooted.es

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

[+] Página oficial del congreso Rooted CON

[+] Seguimiento en SecurityByDefault de Rooted CON 2010: [1] [2] [3]

Comunidad @ SbD

noreply@blogger.com (Yago Jesus) — Tue, 31 Aug 2010 06:19:00 +0000

Hace ya mas de 2 años desde que empezó la andadura de este blog, un día hablando de la cantidad de horas que 'perdíamos' hablando sobre temas técnicos se nos ocurrió que podría ser interesante exponerlos en un blog, buscamos un nombre y empezamos. No teníamos ninguna 'meta' definida, simplemente tratar de hablar sobre temas en los que trabajamos / habíamos trabajado, temas de interés y respetar siempre la máxima de contenido original.

Después de dos años es sorprendente como ha crecido el blog, la gente que nos lee, comenta y aporta. Incluso (y pese a que esto de los rankings es como las encuestas electorales), según Wikio somos el blog número 45 en la clasificación de 'Tecnología' mes Julio (y en alguna ocasión hemos estado en el puesto 36). Tenemos casi 1500 followers en nuestra cuenta de Twitter, un montón de gente que ha añadido a nuestros bots de Gtalk / MSN / Facebook y otros tantos que están en nuestros grupos de Facebook y Linkedin.

Últimamente como habréis observado están apareciendo por el blog bastantes colaboraciones por parte de algunas personas, lo cierto es que ha sido una de las cosas mas gratas que nos ha reportado el blog: ver como la gente tiene ganas de implicarse. Algunas veces han sido personas que conocíamos previamente, en otros casos nos han llegado por mail.

El objetivo de este post es tratar de hacer oficial los canales y las formas en las que, si te apetece y quieres, puedes colaborar con nosotros. Estamos abiertos a todo tipo de colaboraciones, si dominas un tema y te apetece escribir un artículo, genial !. En concreto estamos interesados en aportaciones sobre cosas novedosas y temas que tengan cabida en el blog. Si, por ejemplo, has desarrollado alguna herramienta / exploit / técnica y quieres darla a conocer, bienvenida sea.

Creemos firmemente (como incuestionablemente ha quedado claro en la rootedcon) que la comunidad hispanohablante de seguridad goza de un estupendo nivel y hay muchísima gente capaz de asombrarnos con un montón de conceptos interesantes.

Incluso también estamos abiertos a colaboraciones por parte de empresas. Es un tema delicado y como en todo, prima el sentido común. Por ejemplo, alguien que trabaje en 'Menganitos Abogados' empresa con tradición y experiencia en auditorías en LOPD podría estar interesado en contarnos tips sobre ese tipo de auditorias. Evidentemente si 'Menganitos Abogados' vende un pack de 'Auditoria LODP + seguimiento por 4.000 Euros' NO estamos interesados en que nos hables de tus competitivos precios, mas bien lo que buscamos sería un artículo tipo 'Checklist para auditores LOPD' y si lo quieres firmar como 'Menganitos Abogados' no hay ningún problema. ¿Se entiende, verdad?

En principio, la forma mas rápida y eficaz para contactar con nosotros es vía nuestro mail contacto@securitybydefault.com, no obstante, si te quieres dirigir personalmente a alguno de nosotros por algún otro medio, también es valido.

¡¡ Ánimo y muchas gracias a todos por hacer de SbD lo que es !!

Ayudando a creadores de malware despistados

noreply@blogger.com (Lorenzo Martínez) — Mon, 30 Aug 2010 04:32:00 +0000

Poniéndome al día en un montón de RSS acumulados, encontré una noticia que me abrió los ojos ante cómo funcionan (o no) ciertas mentes humanas.

En Windows, cuando una aplicación ha ejecutado alguna instrucción no autorizada, el sistema operativo reacciona cerrando la aplicación mostrando una ventana con un mensaje que permite notificar a Microsoft sobre qué ha sucedido en dicha aplicación. La idea es ayudar al equipos de desarrolladores de Microsoft para mejorar las capacidades del sistema operativo y de la integración con las aplicaciones (ya las desarrollen ellos mismos también o por parte de terceros), así como sugerir a los usuarios si algún parche corrige la causa del "cuelgue".

Gracias a esto, según Rocky Heckman, arquitecto senior de seguridad de Microsoft, a lo largo del día, reciben un montón de estas notificaciones, con parte del código (un dump de cierta porción de memoria) que generó el error. El tema está en que muchas de estas notificaciones corresponden a acciones por parte de desarrolladores de virus/malware (con prisa, -podríamos añadir-) que en fase de creación de sus nuevas obras de arte, lógicamente hacen pruebas sobre sus propias máquinas. Al no estar depurado el comportamiento del software, lo normal es que se generen "crashes" de aplicación sobre el sistema operativo y al pulsar el botón "Enviar Informe" de la ventana que se abre (sin leer el texto de la misma), se enviará información preciosa de la creatividad del revolucionario troyano beta directamente a Microsoft. ¿Paradójico no? Precisamente el fabricante del sistema operativo de cuyas vulnerabilidades se quieren aprovechar, reciben información de primera mano directamente de parte de su creador.

Y es que estas cosas pasan cuando no "escuchamos" TODO lo que nuestro sistema operativo nos dice… Pero venga va, ¿quién se lee siempre el texto completo de un EULA cuando lo está instalando? Si el mensaje es muy largo o muy "repleto de letras y líneas" directamente buscamos el botón "Aceptar" y que continúe lo antes posible.

Y pensar que el propio Windows proporciona la posibilidad de deshabilitar la solicitud y envío de informe de errores a Microsoft... Cuántos leaks podrían haberse evitado por parte de estos despistados desarrolladores de malware sobrados de creatividad e ilusión si, en Windows 2000/2003 o XP, hubieran ido al menú contextual de "Mi PC" -> "Propiedades" -> "Informe de Errores" y hubieran configurado convenientemente esta opción para evitar la notificación de errores a los de Redmond.

En caso de que nuestros desarrolladores despistados de malware usen Windows Vista o Windows 7, la forma de deshabilitar la notificación de errores es diferente.
Para ello, ejecutaremos "gpedit.msc" en Inicio -> Ejecutar para abrir la "Configuración de Políticas Locales". En "Administración de Plantillas" -> "Componentes de Windows", modificaremos "Deshabilitar Informes de Error de Windows" a "Habilitado"

Enlaces de la SECmana - 34

noreply@blogger.com (Alejandro Ramos) — Sun, 29 Aug 2010 08:09:00 +0000

Herramienta de análisis de PDF: Open PDF Analysis Framework.
Ni tanques ni armas de destrucción masiva, se confirma que en 2008 un pendrive puso en jaque al Pentágono.
Dragonjar comenta un repositorio de herramientas de seguridad.
Firefox anuncia que añadirá HTTP Strict Transport Security en su versión 4.
Otra herramienta para automatizar Nessus y OpenVAS, Seccubus publica la versión 1.5.1
HBGary libera una herramienta gratuita de análisis forenses FGET, para la extracción de información de sistemas Windows remotamente.
EvtxParser soporta el análisis de ficheros de eventos de Windows Vista y superiores.
Como funciona las App Path del registro de Windows.
(Humor) Gandalf el hacker hace fuerza bruta en la Tierra Media.
Como navegar sin dejar trazas.

Montando nuestro propio proxy web

noreply@blogger.com (Contribuciones) — Sat, 28 Aug 2010 06:00:00 +0000

Seguro que todos hemos usado alguna vez un proxy a través de una web, caracterizados por ser cómodos y funcionar bien. Sin embargo muchas veces para poder usar el servicio plenamente hay que pasar por caja, además de que estamos haciendo uso de algo que nosotros no administramos, por lo que no sabemos si nos están monitorizando, ni qué datos se guardan. La solución a todo esto es montarnos nuestro propio proxy web, y lo podemos hacer programándolo nosotros mismos o usando alguno ya hecho.

PHProxy es un proxy web de código abierto escrito en PHP, y aunque el proyecto está inactivo desde 2007, han surgido otros proyectos que lo mantienen actualizado y lo han mejorado, al final de la entrada están los enlaces.

Tienen la ventaja de que se pueden montar en casi cualquier alojamiento que soporte PHP, incluidos los gratuitos. Una vez subido el funcionamiento es muy sencillo, y hay a nuestra disposición bastantes opciones de navegación y de ofuscación / codificación.

Además, si nuestro servidor admite HTTPS podemos cifrar el tráfico en ese tramo, lo que nos añade una capa de privacidad muy interesante.

Todos los proyectos son muy personalizables, y tienen más opciones que se pueden administrar de forma muy sencilla modificando el código fuente. Si quereis probarlo sin instalarlo, a poco que busqueis en google encontrareis varias páginas donde está disponible (muchas veces personalizado, y/o con publicidad).

Enlaces a los proyectos:

[+] PHProxy

[+] phpr0xy

[+] a2freedom

Artículo por Alberto Ortega Llamas.

Muy pronto... wargame de SecurityByDefault

noreply@blogger.com (Alejandro Ramos) — Fri, 27 Aug 2010 05:02:00 +0000

Desde hace unas semanas se ha estado modelando un proyecto por parte del equipo de Security by Default, algo que teníamos pensado desde hacía tiempo y que consideramos que podría ser interesante.

Como ya sabéis nos hemos encargado de realizar el concurso de hacking de la Campus Party España los dos últimos años, además de la Campus Party Europe que se celebró este mes de Abril. Hemos compartido buenos momentos y conocido a grandes personas. Esto nos ha hecho meditar y querer llegar a toda la gente que se ha quedado con ganas de probar sus habilidades en nuestros retos y que no pudieron asistir a estos eventos. Así que finalmente y con la ayuda de Panda Security lanzaremos un concurso online.

Esta vez estáis todos invitados a lo que será el juego oficial de Security By Default y del que esperamos sea el comienzo de un encuentro anual, para todos los amantes de la seguridad como somos nosotros mismos. En este sentido queremos que os sintáis participes de este proyecto y sean cuales sean tus habilidades, seas capaz de aprender, entender y compartir tus capacidades con todos los participantes.

Es hora de desempolvar todas esas herramientas porque os enfrentareis a una tanda de pruebas que os harán reír, sufrir y llorar (el orden no es necesariamente así). Por ahora sólo os diremos que os enfrentáis a pruebas de Web, Redes, Trivia, Crypto y Binarios.

El concurso estará un periodo de tiempo en funcionamiento y si eres el más rápido de todos serás el ganador de un estupendo iPad cedido por nuestro patrocinador. Pero si terminas entre los finalistas no te irás con las manos vacías ya que tendrás también tu premio (que todavía no está decidido).

Os seguiremos informando con el tiempo suficiente para que canceléis todos vuestros planes y podáis dedicaros de pleno al concurso. Pero no os despistéis porque la fecha está mas próxima de lo que pensáis... Mientras podéis releer el blog para ir ampliando vuestra fuente de conocimiento que os hará falta :)

Como bloquear el acceso a Internet al Internet Explorer

noreply@blogger.com (Alejandro Ramos) — Wed, 25 Aug 2010 05:25:00 +0000

Si estás cansado de recomendar el uso de navegadores alternativos a familiares y amigos que delegan en ti "el correcto funcionamiento de su equipo", si te has hartado con la vulnerabilidad de los LNK, o si directamente no te gusta Internet Explorer, puedes bloquear su acceso a Internet y evitar que se utilice para navegar.

Existen múltiples formas de llevar a cabo esta tarea, detallo los pasos de la que más me gusta.

EVITAR CONECTIVIDAD

1.- Configurar el navegador para que utilice un proxy incorrecto: por ejemplo, 127.0.0.1 con el puerto 80, así ni Internet Explorer ni otras aplicaciones que puedan hacer uso de su configuración, tendrán acceso a la red de forma descontrolada. Esta medida es un arma de doble filo, ya que hay muchas aplicaciones que consultan estos datos para tratar de actualizarse o hacer otro tipo de peticiones automáticas. Por lo que hay que considerar que puede tener impacto su implantación.

La configuración de sobra conocida en Herramientas -> Opciones de Internet -> Conexión -> Configuración de LAN.

2.- Restringir la modificación de la configuración del proxy: mediante una política que prohíba su alteración: Inicio->Ejecutar->gpedit.msc

Cambiar "Deshabilitar el cambio de configuración proxy" y "Deshabilitar el cambio de valores de Configuración automática" a Habilitado en las directivas de la Configuración de Usuario -> Plantillas Administrativas -> Componentes de Windows -> Internet Explorer

ELIMINAR EL ACCESO A LA APLICACIÓN

1.- Eliminar el acceso al navegador: evitando que este sea ejecutado por el usuario. Para restringir su uso se puede configurar el control de acceso mediante los Programas Predeterminados del Panel de Control.

Eliminado el permiso al desmarcar la casilla "Habilitar el acceso a este programa" que se muestra junto a Internet Explorer.

Análisis de la gestión de contraseñas en la UCM

noreply@blogger.com (Contribuciones) — Tue, 24 Aug 2010 05:03:00 +0000

En este pequeño artículo voy a exponer cómo se podría realizar un ataque contra los sistemas de recuperación de contraseñas de la UCM pudiendo llegar a obtener el control de la cuenta atacada.

La clave del ataque se encuentra en resetear la contraseña del objetivo, por lo que éste no podrá acceder a los servicios que utilicen dichos credenciales. Por lo tanto, cabe destacar que el acceso que se consigue no es transparente y seguramente tengamos limitado el intervalo de actuación.

¡Comencemos!

Disclaimer:

No me hago responsable del mal uso que pueda darse a esta información. En ningún momento la intención del artículo es el incitar a que se produzcan ataques sobre las cuentas de los alumnos de la UCM, más bien su finalidad es la de concienciar al alumno/universidad de lo fácilmente explotables que son estos sistemas si no se toma, por ambas partes, todas las medidas de seguridad.

1. Campus Virtual (https://cv.ucm.es/CampusVirtual/CambioPropia.do)

Para poder resetar la contraseña del Campus Virtual lo único que se nos pide, en realidad en un primer acercamiento, es el DNI del alumno.

La primera pregunta que me hago cuando me encuentro con éste tipo de sistemas es: ¿será vulnerable a un ataque por Fuerza Bruta (de ahora en adelante FB)? En este caso sí, lo cual posibilita la realización de un ataque aleatorio.

A pesar de lo "cantoso" que es un ataque de FB, podemos utilizarlo para realizar un filtrado de los DNIs pertenecientes a alumnos de la UCM y posteriormente realizar un ataque sobre sus cuentas (o utilizar dicha información para cualquier otro propósito).

¿Y si no queremos realizar un ataque de FB? En el caso de que sea un ataque dirigido hacia un objetivo específico todo se simplifica pues podríamos saber ya desde un principio su DNI o, en caso contrario, buscarlo en Google (CV, listas públicas, etc) o bien acudiendo al registro.

Otra opción podría ser el atacar a un grupo de personas (por ejemplo una clase, etc), y entonces podríamos sacar partido, p.e si se trata de enfermería (entre otras), a las listas que publica la UCM con los turnos de las prácticas en los hospitales universitarios, las cuales contienen nombres, apellidos y DNIs completos!

Bien, ya tenemos el DNI del objetivo pero aun queda un segundo paso, el desafío.

¿Qué es el desafío? Bueno pues no es más que la típica pregunta secreta de siempre. Es un buen sistema si la implementación es correcta y los usuarios están lo suficientemente concienciados como para no facilitar el proceso.

¿Implementación? Me refiero a que el sistema no sea vulnerable a un ataque por FB, por desgracia, es el caso. ¿Concienciación? La mayoría de las veces el ataque se reducirá a un listado de palabras muy común, ¿por qué? pues porque muchos usuarios no se toman en serio éste tipo de peticiones al realizar el registro y nos encontramos que la pregunta y la respuesta es la misma o que la pregunta es del tipo ¿mi fecha de nacimiento?, ¿el nombre de mi perro?, ¿mi color favorito?, etc, teniendo respuestas muy fáciles de sacar.

Por lo tanto, si unimos una mala implementación con unos usuarios que se toman poco en serio los desafíos, nos encontraremos con cuentas extremadamente vulnerables, siendo ambos los culpables.

En sí el sistema no es un desastre, a pesar de que esté mal implementado.

Como opinión personal decir que estos sistemas encargados de manejar reseteos de credenciales tan críticos, como los del Campus Virtual de la universidad, los eliminaría y obligaría a rellenar una instancia y evitando que se pueda hacer online (como hacen en la UAH).

¿Cómo se podría hacer sin realizar modificaciones en los datos que se piden? En primer lugar sería eliminar cualquier intento de FB restringiendo el número de peticiones por IP e implementando un sistema de bloqueo preventivo de la cuenta (ya sea un bloqueo temporal o que haya que acudir a la escuela/facultad a restablecer el servicio).

En segundo lugar sería evitar las dos fases del proceso (DNI y desafío) uniéndolas en uno mismo y en caso de error devolviendo un mensaje del tipo “DNI/Desafío incorrecto” evitando dar información de qué dato es el incorrecto. Por desgracia en este caso no se puede pues el desafío no es una pregunta establecida, sino personalizada por usuario, por lo que se obtiene tras validar el DNI.

2. Activar cuenta (https://idm.ucm.es/cgi-bin/idmActivarAuth.pl)

Éste ataque solo se puede llevar a cabo sobre una cuenta que no haya sido activada, por lo que los objetivos han de ser alumnos de nuevo ingreso, lo cual es perfecto para éstas fechas.

¿Cómo podemos obtener el DNI de un alumno de nuevo ingreso? El formulario de consulta de las notas de las pruebas de acceso es vulnerable a FB por lo que podemos realizar utilizar dicho servicio para realizar el filtrado. Para activar la cuenta se nos pide el DNI del alumno y el código de activación. Para obtener el DNI bastaría con utilizar cualquiera de los métodos anteriormente comentados. Con respecto al código de activación, si atendemos a la ayuda del sistema de recuperación de contraseña veremos que éste sigue una estructura fija dependiente de la diplomatura/licenciatura que eligió el alumno en primera opción y el código postal del mismo. La estructura en sí es la siguiente:

XXX‐XXXXX (CESTUDIO‐CPOSTAL).

Podemos utilizar las redes sociales para obtener ambos datos y reducir mucho el ataque de FB (pues nuevamente es vulnerable a este ataque).

Para la diplomatura podríamos tener suerte y que la haya añadido ya a su perfil de, por ejemplo, Tuenti. En tal caso, bastaría con utilizar los filtros del buscador para averiguarla (a pesar de tener el perfil privado hay demasiada información pública). Si no tenemos suerte deberíamos de añadir esta parte al ataque de FB (serían 103 combinaciones).

Para el código postal bastaría con delimitar su ciudad (al igual que anteriormente, es información accesible por cualquier miembro de la red social), localizar el identificador postal de la misma (se podría utilizar la página de Correos) y añadir al ataque 103 combinaciones de la terminación.

De ésta forma podemos ver que el código de activación podría quedar con una estructura similar a:

‐ Solo hemos obtenido la ciudad: XXX‐28XXX

‐ Hemos tenido suerte con la diplomatura/licenciatura: 050‐28XXX

Como hemos podido ver, el eslabón más débil es el código de activación siendo recomendable que éste no siguiera un patrón, sino que fuera aleatorio y se le entregara al futuro alumno (por ejemplo en la carta de admisión) o que éste tuviera que ir a recogerlo a la secretaría de su centro.

¡Hasta aquí todo! Ya para terminar...

A lo largo del artículo se ha explicado cómo podrían ser atacados los credenciales de la UCM. En muchos casos se ha explicado como atacar a un objetivo aleatorio para demostrar que las cuentas son vulnerables sin tener que conocer al alumno en cuestión. A pesar de esto, el tener un objetivo simplifica mucho el proceso, llegando a ser preocupante el tiempo que se tarda en conseguir acceso a su cuenta.

Como he dicho antes de empezar, no me hago responsable del uso que se haga de ésta información, la intención del artículo es concienciar a los usuarios y obligar a las universidades a prestar verdadera atención a todos los servicios que ofrecen y que éstos han de estar bien implementados pues los datos que manejan no son ninguna tontería.

(Artículo cortesía de Luis Delgado J @ldelgadoj )

Top módulos recomendados para Apache

noreply@blogger.com (Lorenzo Martínez) — Mon, 23 Aug 2010 04:32:00 +0000

Una de las características fundamentales de Apache es la ventaja que aporta el poder añadir/habilitar dinámicamente cuantos módulos necesitemos. Digamos que Apache es la base de la pizza sobre la que añadimos los ingredientes a nuestro gusto y necesidades (estoy escribiendo este post cerca de la hora de comer y los ejemplos que se me ocurren son los que son…)

En varios de nuestros blogs favoritos, ya hay buenas guías de securización de Apache, en las que nos hablan de cómo hemos de asignar los permisos, configuración de accesos, ocultar la información mostrada en banners, etc, etc,…

Así pues, únicamente he querido centrarme en hacer una recopilación de aquellos módulos que he utilizado en Apache y que me han valido para dotarlo de un mejor rendimiento, así como de un mejor nivel de protección ante las amenazas a las que el servidor web se encuentra expuesto.

Aceleración

mod_gzip/mod_deflate: En general, casi todos los clientes web son capaces de "hablar" HTTP recibiendo los datos comprimidos por parte del servidor. La idea es configurar el servidor web para que sea capaz de servir los datos comprimidos, ahorrando parte del ancho de banda disponible acelerando el tráfico web. Tanto mod_gzip como mod_deflate son capaces de comprimir los datos servidos.

mod_cache: Es sobre todo útil cuando se usa a la vez que mod_proxy (se verá más adelante). La idea es que Apache cachee los datos que ya ha servido, y no tenga que procesar las peticiones de nuevo. Este módulo depende a su vez de mod_disk_cache y mod_mem_cache para cachear la información en un espacio de disco o en memoria predefinidos para ello. En el caso de usarse con mod_proxy, la idea es que el servidor web final tenga una carga inferior para los contenidos más utilizados, estando estos cacheados en el servidor Apache que actúa como proxy intermedio.

Confidencialidad y autenticación

mod_ssl: El tráfico web HTTP va en claro o sin cifrar. Si queremos ser capaces de hacer que el servidor web trabaje sirviendo datos cifrados desde extremo a extremo mediante HTTPS, debemos habilitar mod_ssl. De esta forma incluso podremos exigir a nuestros clientes la autenticación mediante certificados SSL X.509 de cliente (soportados mediante SSL v3).

mod_auth_*: Si queremos que ciertas partes de los datos que servimos vía web requieran otro tipo de autenticación basado en usuario y contraseña, Apache nos provee de una infinidad de módulos para esta funcionalidad. El más básico es mod_auth. Podemos exigir autenticación Básica y Digest comparando los pares usuario/contraseña (o hash de la misma) contra un fichero, por convención llamado .htaccess, y permitir o no el acceso a los datos. Sin embargo, muchas veces se quiere utilizar para autenticar otros servidores de autenticación centralizada como pueden ser Radius, LDAP, Directorio Activo o una base de datos mysql por ejemplo. Para ello contamos con: mod_auth_radius, mod_auth_ldap o mod_auth_mysql por ejemplo.

Protección ante ataques

mod_security: Tanto de forma embebida en el servidor web final, como en conjunción con mod_proxy para proteger ante accesos internos, mod_security es la alternativa libre en cuanto al software de Cortafuegos de Aplicación Web (o WAF) de los que hemos hablado varias veces en SbD. La idea es blindar el servidor web ante las peticiones que puedan ser ataques de tipo Inyección SQL o XSS, entre otros...

mod_proxy: Una de las mejores maneras de aislar un servidor del mundo exterior es poner un proxy inverso de por medio. De esta manera, publicamos un servidor Apache en este caso hacia fuera y las peticiones se las lleva éste, como se hace en un sistema de correo con un relay que comprueba el spam y los virus. Así, si queremos incluso balancear tráfico entre diferentes servidores web finales, Apache con mod_proxy hará las peticiones hacia los internos. Como se comentó anteriormente, si además utilizamos mod_cache, podremos acelerar la aplicación web al cachear en el proxy inverso según que tipo de contenidos. Lo mismo ocurre con mod_security, al recibir Apache las peticiones, efectuará las que considere sanas hacia el servidor web final, no dejando pasar las demás.

mod_evasive/mod_qos/mod_limitipconn/mod_antiloris: Dotar de la mayor disponibilidad posible el sistema es una de las labores de varios módulos diferentes. El más completo de todos es mod_evasive, aunque los otros módulos expuestos son buenas alternativas si sólo queremos limitar la Calidad de Servicio del servidor Apache mediante el ancho de banda y/o número de conexiones desde una determinada IP. Con mod_evasive incluso se puede reaccionar de forma dinámica cuando se detecte un ataque, bloqueando vía IPTables la IP atacante, avisos por correo o syslog, etc,... La idea principal de estos módulos es evitar los ataques de denegación de servicio debido al consumo de los recursos disponibles en el servidor. mod_antiloris está especificado para evitar ataques con la herramienta Slowloris. Lo he probado en una red local y efectivamente lo que antes bloqueaba mi Apache, al aplicarlo, permite que se siga utilizando por otras IPs.

Enlaces de la SECmana - 33

noreply@blogger.com (Alejandro Ramos) — Sun, 22 Aug 2010 05:37:00 +0000

Versión 0.20 de VERA, herramienta de visualización gráfica de la ejecución dinámica de una aplicación
Exploit para el kernel de FreeBSD 7.x y 8.x
Manual de foro del elhacker.net para crear un juego con troyano en Ubuntu con Metasploit
Alta disponibilidad... a veces. ADIF retrasa 40 trenes en Galicia por un error informático.
Salsa rosa hacker sensacionalista, sobre el ""nuevo"" bug en Linux. Mail de Brad Spengler dando un poquito de cera a Rutkowska
Presentación de la RECON "Reverse Engineering over Acrobat Reader using Immunity Debuger"
Abierto el proceso de inscripción para la No cON Name 2010 en Barcelona.
¡El poder 2.0! Un "hacker" consigue acceso a la cuenta de Axl Rose (líder de los Guns 'N' Roses) y anuncia la falsa cancelación de su próximo Tour.
El servidor de Adobe, Coldfusion, recibe un mazazo esta semana en forma de grave vulnerabilidad.
En el aniversario del trágico accidente del JK 5022 Barajas, salta la noticia de que un ordenador de Spanair que anotaba los fallos en los aviones tenía troyanos.
Publicadas las novedades de VirusTotal en hispasec.

Cifrado en Windows con AxCrypt

noreply@blogger.com (Alejandro Ramos) — Sat, 21 Aug 2010 05:25:00 +0000

En todas las listas y foros de seguridad en los que estoy, esta es una pregunta que en algún momento se ha tratado: "¿Qué aplicación puedo utilizar para mandar archivos cifrados, sin necesidad de que el receptor tenga nada instalado?"

Una de las respuestas posibles es la solución OpenSource AxCrypt, un software ligero que se integra en el menú contextual de Windows y permite cifrar un fichero o directorio creando un paquete ejecutable auto-descifrable (Encrypt to EXE) utilizando AES-128. A modo de orientación, estos son los tamaños que ha generado de un documento PDF de 6.3Mb:

Nombre	Tamaño
Doc.pdf (original)	6.332.876
Doc-pdf.exe	6.480.302
Doc-pdf.axx	6.333.166

La aplicación únicamente se puede acceder desde este menú donde se encuentran todas las opciones, incluidas el cambio de idioma al Español.

Entre sus principales ventajas se encuentra un uso muy sencillo, basta con pulsar con el botón derecho sobre el contenido que se desea cifrar y asignarle una contraseña, que posteriormente será compartida mediante otro canal, como por ejemplo vía telefónica.

Una vez enviado el ejecutable generado, muestra una pantalla que solicita la contraseña y desempaqueta los archivos.

Otra característica importante y útil es la inclusión de borrado seguro o wipe (Shred and Delete), con la que rápidamente se eliminan ficheros y directorios asegurando que no podrán serán recuperados.

No es la única herramienta que hace estas funciones, incluso el propio WinRAR permite generar SFX cifrados con las mismas características, pero por su integración en el sistema operativo, su sencillez y su precio, posiblemente sea una de las mejores opciones.

Ojeada a la seguridad de Jolicloud

noreply@blogger.com (Contribuciones) — Fri, 20 Aug 2010 05:30:00 +0000

Jolicloud es uno de los últimos gritos en cuanto a cloud computing se refiere. Se define como un sistema operativo ideado para netbooks, que nos facilita la gestión de nuestros datos y los servicios que usamos en Internet. Al final, es un sistema operativo que centraliza diferentes servicios externos y facilita su uso. Dicho así parece atractivo, pero por otro lado algo que se basa tanto en la nube necesita unas medidas de seguridad extra, y si no las tiene puede jugarnos una mala pasada.

Hasta hace poco sólo se podía probar mediante invitación, pero en estos momentos está disponible la primera versión del sistema, y cualquiera puede crearse una cuenta y empezar a usarlo.

Puesto que ya está abierto al público, es el momento de ver cómo se han hecho las cosas. Vamos a crearnos una cuenta, y arrancamos la Live CD para probar. Además, vamos a monitorizar el tráfico que genera.

Lo primero que nos pide Jolicloud cuando termina de arrancar es que nos conectemos a Internet para poder iniciar sesión en el ordenador. Una vez preparados iniciamos sesión y vemos qué y cómo ha enviado los datos al servidor:

El nombre de usuario y la contraseña se envían en una petición POST HTTP en claro. ¿SSL? ¿Para qué?

Después de que nuestros credenciales hayan viajado legibles por medio mundo, estamos dentro de nuestro ordenador, con nuestras aplicaciones en local, y un montón de accesos directos a servicios online (Dropbox, Gmail, Facebook, Twitter ...). Vamos a descargar nuestra primera aplicación, que va a ser VLC:

La petición vuelve a ser en claro, indicando la aplicación y la acción a realizar.

Son pocas las peticiones que realiza el propio Jolicloud a sus servidores (y menos mal), el resto están gestionadas por el servicio en cuestión, ya que realmente lo que nos facilita el sistema es un acceso directo a la página web o la aplicación oficial del servicio.

Que cada uno saque sus propias conclusiones.

Artículo por Alberto Ortega Llamas.

Analizando cabeceras HTTP 'just for fun'

noreply@blogger.com (Yago Jesus) — Thu, 19 Aug 2010 04:49:00 +0000

Para cualquier persona 'normal' navegar implica abrir un navegador, poner una URL y visualizar la web, lo que sucede entre el navegador y el servidor web para llegar a ese punto normalmente es una conversación HTTP orientada 'a maquinas'.

Aun así resulta curioso dedicar un rato a ojear en modo crudo el flujo del protocolo HTTP para descubrir cosas extrañas.

Primer caso: 'Cookies antediluvianas'

Ignoro el porqué de este tipo de cookies, pero como ya me las he encontrado en varios servidores, supongo que alguna razón de ser habrá, el caso es que ojeando por ejemplo la red social profesional www.linkedin.com nos encontramos con esta extraña cookie (click en la foto para ampliar):

s_leo_auth_token="delete me"; Version=1; Max-Age=0; Expires=Thu, 01-Jan-1970

Una cookie que lleva 'expirada' desde 1970

Otro caso de cookies caducadas http://es.yahoo.com

En este caso, del año pasado. Sin duda, alguna razón debe haber, tal vez sea un método de prueba del servidor web para validar que tienes activada la creación de cookies

Segundo caso: Una de Pareidolias

Este ejemplo está cogido con alfileres y sin duda es pura sugestión mental del 'querer ver'. El caso de www.bing.com que en su política P3P (una especie de información donde se indica el uso que se va a hacer de la información obtenida) se puede leer en el banner 'STA LOC CURA'

Tercer caso: El site de contactos y experimentos

Para el que no lo sepa, www.adultfriendfinder.com es un sitio web de contactos, donde 'Papa y Mama' buscan amiguitos mientras sus hijos montan orgías en Tuenti. En el caso de adultfriendfinder lo extraño que se puede ver es en el header ETAG. Si ojeamos la wikipedia podemos ver que ETAG se emplea para optimizar el uso de la cache de un site web, y sobre el header ETAG: 'is an opaque identifier assigned by a web server to a specific version of a resource' vamos que cada servidor web asigna el valor como quiere, lo normal es encontrarse números grandes o strings sin sentido, en el caso de adultfriendfinder nos encontramos como valor 'TESTBED'

Según la wikipedia un 'TESTBED' es un entorno controlado para hacer pruebas científicas reproducibles (is a platform for experimentation of large development projects. Testbeds allow for rigorous, transparent, and replicable testing of scientific theories, computational tools, and new technologies).

Cuarto caso: Headers para 'Hackers'

El caso mas obvio de modificación con intención de que alguien lo vea lo podemos encontrar en Wordpress.com, que añade el siguiente Header:

X-hacker: If you're reading this, you should visit automattic.com/jobs and apply to join the fun, mention this header.

Una curiosa y divertida forma de reclutar personal

Auditando la seguridad de dispositivos de red con nipper

noreply@blogger.com (José A. Guasch) — Wed, 18 Aug 2010 04:36:00 +0000

Todo administrador de redes debería tener esta herramienta dentro de su arsenal, y si no, ahora ya no podrá poner excusas cuando le pidan el estado de seguridad de los dispositivos de red de su empresa. Nipper, Network Infraestructure Parser es una herramienta de auditoría de seguridad de dispositivos de red, tanto routers, como switches o firewalls.

Con nipper únicamente necesitaremos el fichero de configuración del dispositivo que queremos analizar, que servirá como parámetro de entrada de la herramienta (--input) e indicar el nombre que queremos dar al fichero-informe que nos devolverá como salida (--output):

nipper --TIPO_DISPOSITIVO --input=CONFIGURACION.conf --output=SALIDA.html

Nipper es capaz de analizar/parsear las configuraciones de los siguientes elementos de red:

3Com SuperStack 3 Firewall
Bay Networks Accelar
CheckPoint Firewall Module
CheckPoint Management Module
Cisco IOS-based Router
Cisco IOS-based Catalyst Switch
Cisco PIX-based Firewall
Cisco ASA-based Firewall
Cisco FWSM-based Router
Cisco CatOS-based Catalyst
Cisco NMP-based Catalyst
Cisco Content Services Switch
HP ProCurve Switches
Juniper NetScreen Firewall
Nokia IP Firewall
Nortel Passport Device
Nortel Ethernet Routing Switch 8300
SonicWall SonicOS Firewall

Al ejecutar esta herramienta, en cuestión de unos pocos segundos tendremos como resultado un informe en el que tendremos un resumen de las configuraciones de nuestro dispositivo así como una relación de vulnerabilidades en base a lo analizado. Seguridad sobre contraseñas, servicios que se recomienda deshabilitar, fallos o ausencias de parámetros de configuración, opciones de logging y monitorización, vulnerabilidades asociadas a la versión del sistema operativo...todo vendrá descrito tanto con recomendaciones como con los riesgos asociados a las vulnerabilidades detectadas.

Con nipper se acompaña un fichero nipper.ini que nos permitirá describir los parámetros de configuración y valores por defecto tanto para el análisis como para los resultados descritos en el informe generado. Se recomienda echarle un vistazo para así tener claro todo lo que se analizará, y dejar bien establecidas las métricas que más se adapten a nuestro entorno.

En caso de que tengáis un dispositivo de los listados anteriormente a mano, únicamente tendréis que obtener su configuración. También existe la posibilidad de configurar nipper para que acceda al dispositivo y obtenga su configuración por SNMP (para más información, teclear nipper --help=SNMP)

¿Que no disponéis de un dispositivo, pero queréis probar la herramienta? Muy sencillo, en nuestra fuente inagotable de ficheros de configuraciones, listados de contraseñas, conversaciones privadas, salidas de keyloggers, como es pastebin, podréis probar nipper descargando cualquiera de los ficheros que aparecen como resultados de la siguiente petición en google (es que el motor de búsqueda en pastebin, como que no es tan bueno...¿verdad?):

inurl:pastebin "Building Configuration..."

Actualmente nipper ya no es gratis: la última versión disponible (y comercial) podréis encontrarla en titania.co.uk (en este enlace podréis revisar las licencias...), pero no todo está perdido. En este otro enlace podréis encontrar las últimas versiones disponibles de nipper como Open Source (0.12.6). Creedme, aunque se trate de una versión que se ha dejado de mantener, es más que suficiente si no podéis ~~sacarle~~ convencer a vuestra empresa que obtenga una licencia de este producto.

Existe un proyecto denominado nipper-ng que intenta mantener el producto actualizado y open source, pero de momento está bastante muerto y tiene pinta de seguir así por un tiempo (únicamente podemos encontrar la última librería disponible, 0.12.6 subida al SVN), crucemos los dedos para que esto cambie pronto.

De todas formas, contamos con otras alternativas para, por lo menos, auditar la seguridad de dispositivos Cisco, como son RAT/NCAT. ¿Alguna recomendación más para este tipo de tareas?

Vigilando la casa cuando no estás

noreply@blogger.com (Lorenzo Martínez) — Tue, 17 Aug 2010 04:32:00 +0000

Vacaciones! qué palabra tan maravillosa. Por fin podemos recoger el petate y largarnos fuera de la ciudad en la que hacemos nuestra vida cotidiana, a pegarnos vuelta y vuelta en la playa o disfrutar de lo sano de la montaña.

El problema es que no todo el mundo coge las vacaciones en las mismas fechas. Las bandas organizadas suelen "trabajar" justo cuando nosotros descansamos. Por ello, aparte de tachar de la checklist cortar el agua, el gas y regar las plantas,… deberíamos considerar la protección o vigilancia de nuestra casa para no encontrarnos una desagradable sorpresa al volver.

Una herramienta que permite tener la casa controlada en todo momento es Motion. Simplemente es necesario un ordenador con Linux (Redhat, Debian o cualquiera compilando el tar.gz) o FreeBSD, así como una o varias webcams USB o netcams accesibles vía TCP/IP, ya sean con cable o inalámbricas. Gracias a Motion, al estar activo, por cada cámara configurada, empezará a comparar los fotogramas actuales con los inmediatamente anteriores, de manera que si se detecta que ha habido un número determinado (configurable) de pixels en una de ellas, se considerará como que ha habido movimiento y se grabará a disco.

Fundamentalmente tiene un único fichero de configuración por cada cámara en el que se podrán indicar entre otras cosas:

El/los dispositivo/s en sí: Un /dev/videoX en el caso de una cámara V4L (Video 4 Linux) o la URL (con el usuario y la contraseña) del streaming de la netcam que se desea.

Por cada cámara, es posible ajustar parámetros del estilo de la saturación, brillo, contraste, etc,…

Es necesario también definir el umbral de píxels que queremos permitir por cambio de imagen en cada cámara: lo que definiríamos como "he detectado un movimiento, así que graba a disco!". Esto es imprescindible puesto que las condiciones de luz y calidad de cada cámara no tienen por qué ser las mismas por lo que tiene sentido personalizarlo en cada caso. Igualmente para no tener muchos falsos positivos conviene afinar la configuración de este tipo de parámetros.

Importante es también especificamos la ruta dónde queremos guardar los ficheros, ya sean fotogramas sueltos o hacer que grabe en video una secuencia completa de movimiento según sea detectado, así como el formato de los nombres de los ficheros. Es posible configurar una base de datos MySQL o PostgreSQL para guardar todas las imágenes y videos generados.

Podemos hacer además que cuando se detecte un movimiento se ejecute un comando determinado. Una buena idea podría ser utilizar Tweetme! para avisarnos vía twitter estemos dónde estemos que algo ha pasado.

Si queremos monitorizar de forma continua lo que detecta cada cámara, al levantar el servicio Motion, podremos acceder a un puerto (configurable) que nos muestre por streaming lo que la cámara está viendo en cada momento.

Es útil hacer que se guarde un snapshot cada X segundos, que permita acceder a la última imagen disponible de cada cámara vía web. En mi caso dispongo de una aplicación para iPhone llamada "Webcams" que permite en un momento dado conectarse para ver cómo están tus cámaras (y aquellas webcams públicas que configures)

Hay diferentes GUIs para poder acceder a la estructura de directorios y previsualizar qué ha ocurrido en nuestra ausencia. Llevo utilizando Motion desde 2003 con la GUI MotionCGI aunque el proyecto no esté mantenido actualmente, he ido efectuando yo mis propias modificaciones en la instalación para que sea válido.

Felices y tranquilas vacaciones!

Fortificación de MySQL - 2/3

noreply@blogger.com (Alejandro Ramos) — Mon, 16 Aug 2010 06:08:00 +0000

Continuamos con la segunda entrada sobre fortificación de MySQL.

7.- Uso de los mínimos privilegios: aplicable a versiones anteriores del motor 5.x. Las bases de datos se han de almacenar propiedad del usuario mysql u otro creado para tal propósito sin privilegios de administración del sistema operativo.

Para comprobar los permisos:

shell> ls -l /var/lib/mysql

Todos los directorios deberían mostrarse como usuario mysql y grupo mysql, con permisos 700 o lo que es lo mismo: "drwx------". Para modificar el usuario y grupo de un directorio y posteriormente sus permisos:

shell> chown mysql:mysql /var/lib/mysql/mibbdd
shell> chmod 700 /var/lib/mysql/mibbdd

El servicio ha de ser ejecutado con este usuario, que además no puede tener permisos para conectarse localmente. En sistemas Unix, el usuario ha de tener como shell el binario /sbin/nologin

Para comprobar la shell:

shell> grep mysql /etc/passwd

mysql:x:27:491:MySQL Server:/var/lib/mysql:/bin/bash

Para cambiar la shell:

shell> chsh -s /sbin/nologin mysql

En el caso de Windows, el usuario ha de estar incluido en los Deny log on locally y ejecutado como usuario NETWORK_SERVICE

8.- Permisos de administración en usuarios: la base de datos dispone de usuarios al igual que el sistema operativo, root es el administrador y únicamente debería ser utilizado para tareas de gestión como altas y bajas de otros usuarios, modificación de permisos, etcétera. Es importante que no se use al usuario root para el acceso a datos. Al igual que los usuarios que tratan datos (selects, inserts o updates) no han de tener habilitados permisos especiales, ya que en caso de encontrarse una inyección de código podrían ejecutarse tareas con privilegios mayores.

Para consultar la lista de usuarios y sus permisos:

mysql> use mysql;
mysql; select * from user;

Para ver los permisos de un usuario en concreto:

mysql> show grants for ‘root’@’localhost’;

El siguiente ejemplo muestra la modificación del usuario "miuser" en la base de datos "mibbdd", dejando únicamente INSERT, SELECT, UPDATE y DELETE:

mysql> show grants for miuser@localhost;
+--------------------------------------------------------------------------------------+
| Grants for miuser@localhost                                                         |
+--------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'miuser'@'localhost' IDENTIFIED BY PASSWORD '6212cdea5883c099' |
| GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, REFERENCES, INDEX,
 ALTER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, CREATE VIEW, SHOW VIEW,
 CREATE ROUTINE, ALTER ROUTINE ON `mibbdd`.* TO 'miuser'@'localhost' |
+--------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

mysql> revoke all privileges on mibbdd.* from 'miuser'@'localhost';
Query OK, 0 rows affected (0.11 sec)

mysql> show grants for miuser@localhost;
+--------------------------------------------------------------------------------------+
| Grants for miuser@localhost                                                          |
+--------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'miuser'@'localhost' IDENTIFIED BY PASSWORD '6212cdea5883c099' |
+--------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> grant select,insert,update,delete on mibbdd.* to 'miuser'@'localhost';
Query OK, 0 rows affected (0.00 sec)

mysql> show grants for miuser@localhost;
+--------------------------------------------------------------------------------------+
| Grants for miuser@localhost                                                          |
+--------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'miuser'@'localhost' IDENTIFIED BY PASSWORD '6212cdea5883c099' |
| GRANT SELECT, INSERT, UPDATE, DELETE ON `mibbdd`.* TO 'miuser'@'localhost'           |
+--------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)

9.- Eliminación de visualización de base de datos: con esta medida se pretende que los usuarios no puedan conocer que otras bases de datos se encuentran en el servidor, eliminando el acceso comando SHOW DATABASES. Para aplicar esta opción, se puede arrancar el servicio mysqld con el parámetro "--skip-show-database" o añadir al archivo de configuración este mismo nombre:

[mysqld]
skip-show-database

Si por algún motivo se desea asignar este privilegio a un usuario, se puede llevar a cabo mediante el GRANT correspondiente.

10.- Configuración de los registros: siempre y cuando el sistema no haga demasiadas peticiones, se pueden almacenar todas las peticiones que reciba el servicio. Esta opción no es recomendable si la base de datos tiene mucho tráfico ya que genera mucha carga e información en disco. Para activarla, modificar el archivo my.cnf con:

[mysqld]
log=/var/log/mylogfile

Este fichero log, al igual que el de registro, como el de errores, el archivo binario, o el de consultas lentas solo han de tener permisos para los usuarios mysql y root. Puede causar problemas importantes de confidencialidad si otros usuarios del sistema tienen acceso.

11.- Almacenar los datos de la base de datos en una partición distinta al sistema operativo: evitando que la base de datos sufra pérdidas por ataques de denegación de servicio que llenen el disco duro libre del sistema operativo.

[mysqld]
datadir=/path/dir

12.- Eliminación del historial del cliente de MySQL: que almacena los comandos ejecutados por el cliente mysql y puede facilitar información crítica. Para configurarlo, añadir la siguiente línea al /etc/profile:

declare -r MYSQL_HISTFILE=/dev/null

Además es recomendable crear un enlace de los ficheros a /dev/null también.

shell> ln -s /dev/null $HOME/.mysql_history

13.- Comprobación de contraseñas almacenadas en texto claro: que se guardan en la variable de entorno MYSQL_PWD y en el archivo de configuración, bajo la directiva password.

Para evitar que se use la variable de entorno añadir al archivo /etc/profile:

declare -r MYSQL_PWD

En el archivo de configuración comprobar que no existe la linea "password":

[client]
password=TuContraseña

Referencias:

Enlaces de la SECmana - 32

noreply@blogger.com (Alejandro Ramos) — Sun, 15 Aug 2010 04:53:00 +0000

Como buena sección dentro de un programa, se merece una entrada con algo de ritmo:

<música-tecno-de-fondo> En-en-en-la-la-ces de la sec-sec-sec-mana </música-tecno-de-fondo>

Parche para Aircrack y soporte al ataque de migración de modo WPA en Cisco.
SecurityGarden es un portal que recopila herramientas. Esperemos que pronto tengan versión en inglés o español
Con la aplicación web mxtoolbox se ejecutan pruebas de configuración DNS y correo electrónico sobre dominios. Otra opción interesante es el procesamiento de las cabeceras de un correo electrónico para su visualización en formato inteligible.
PhreakVids colecciona una lista de videos de Phreaking
Asegurando memcache en 2 minutos (más los que lleve leerse la entrada)
Solución a una de las pruebas del CTF de Defcon 18 por parte del grupo PainSec.
Liberada la aplicación para el análisis de código PHP RIPS 0.32 de FluxReiners, conocidos en todos los concursos de hacking.
Maracon, una backdoor que se inyecta en WARs
Análisis en profundidad del troyano para Android Trojan-SMS.AndroidOS.FakePlayer.a por Jaime Blasco
KiTTY (Windows), una alternativa muy interesante a PuTTY.
Smashing the Stack in 2010 (PDF)

Cuando 'Privado' significa 'casi privado'

noreply@blogger.com (Yago Jesus) — Sat, 14 Aug 2010 06:08:00 +0000

Desde hace algún tiempo los navegadores han incorporado un método de navegación al que han denominado privado en el que se supone que toda actividad que se realice desde ese modo, debe quedar entre tu y tu conciencia.

Como viene siendo habitual cualquier axioma que implique 'certeza absoluta' suele permanecer así hasta que alguien lo mira con cierto detenimiento.

En el caso de los Navegadores y su modo privado, así ha sido. Los cuatro grandes de la navegación: Internet Explorer, Firefox, Chrome y Safari implementan el modo privado de una forma inconsistente y que permite obtener mas datos de los debidos.

El estudio disponible aquí (y bastante denso, muy de corte universitario) se puede resumir en lo siguiente:

Un navegador debería tener como 'metas' los siguientes puntos:

Al navegar de forma privada y luego / antes de forma normal en un site web, este no debería poder distinguir entre uno y otro visitante (Consideraciones de IP aparte)
Un servidor web no debería poder distinguir al mismo usuario si este se conecta al servidor web empleando dos sesiones privadas diferentes. (Es decir, se conecta en modo privado, cierra, abre el navegador en modo privado y vuelve a conectar)
Un servidor web no debería poder distinguir si un usuario está usando el modo privado durante la navegación

Como se puede ver en el estudio publicado, esas tres máximas de la privacidad son subvertidas de diferentes formas.

Ejemplos de 'leaks' que no deberían estar ahí:

Algunos navegadores almacenan tanto en el lado 'publico' como 'privado' la actividad SSL basada en certificados digitales, es decir, aquellos que se han generado durante la navegación
Igualmente, algunos navegadores almacenan en modo publico / privado certificados 'self signed' (no validados por CAs de confianza) permitiendo acceder a ellos en ambos modos
Ficheros descargados durante la navegación privada
Conexiones Netbios: Explorer permite y entiende links tipo \\unamaquina\unrecurso, si un usuario en modo privado realiza una petición de ese tipo, estará enviando junto al intento de conexión mucha información.
Ciertas extensiones como 'No Script' que almacenan y manejan listas blancas / negras de hosts, no tienen en consideración el modo privado, por lo que tratan y almacenan los datos de forma indistinta en lado privado / lado normal

Como nota curiosa, los investigadores de la universidad de Stanford diseñaron un tipo de ataque basado en 'CSS History Hacking' (ver nuestra maquina de Zoltar) por el cual eran capaces de averiguar si alguien estaba usando el modo privado / no privado durante la navegación. Contrataron dos campañas de anuncios, una de ellas para un sitio 'de mayores' y otra en una tienda de regalos. Empleando su sistema de tracking para usuarios con navegación privada, llegaron a la conclusión de que el porcentaje de uso en un sitio 'porno' era bastante superior que en el de una tienda normal.

Retos forenses, practicar para avanzar.

noreply@blogger.com (Alejandro Ramos) — Fri, 13 Aug 2010 05:16:00 +0000

Los análisis forenses son un tipo de trabajo que requiere personal altamente cualificados y preparado para que su ejecución sea satisfactoria y su resultado favorable.

Pese a que existe mucha literatura en libros y blogs lo mejor es practicar con casos lo más reales y variopintos posibles que hagan enfrentarse a cada uno de los problemas que vayan surgiendo. De esta forma será difícil olvidar lo que se sudó y cuando una situación similar se presente, será sencillo dar con la solución.

Con este propósito distintas organizaciones, blogs y compañías publican concursos y retos de análisis forense en los que se puede participar. Generalmente se descarga una imagen o archivo y se solicita la solución en un documento técnico y otro ejecutivo.

A continuación hemos recopilado algunos de los más populares, en muchos casos ya resueltos... ¡¡pero no hagáis trampa!!

I Reto de La Comunidad DragonJAR
II Reto de La Comunidad DragonJAR (aún no disponible)
Reto Forense Episodio III, de RedIris y UNAM-CERT
Puzzles de Forensics Contest, muy recomendable, así como las herramientas que se han desarrollado para los distintos retos.
Retos de Computer Forensics de SANS, además de disponer del SANS Investigative Forensic Toolkit (SIFT)
Las nuevas pruebas de Honeynet y las viejas, no aptas para iniciados.
Preguntas teóricas de ValCom.
DFRWS lo hace entretenido, en su forense del 2010 con una imagen de un móvil. También disponible el del 2009, 2008, 2007 y 2006,
Cyber Forensics Challenge de NYU-Poly.

A las BlackBerry le huele el aliento, pero todos la besan

noreply@blogger.com (Alejandro Ramos) — Thu, 12 Aug 2010 06:02:00 +0000

No, la imagen no es de la ferretería-café de Luke, hace referencia al culebrón que tienen montados los canadienses de RIM y sus BlackBerry con la seguridad en sus dispositivos móviles o mejor dicho, en el diseño de la arquitectura de comunicaciones y la centralización de sus sistemas en países no controlados por gobiernos que desean controlar (y espiar) las comunicaciones.

Ya hace cuatro años se podían ver análisis profundos de esta plataforma en la Blackhat, y algún ataque en Defcon. Pero las alertas empezaron a sonar cuando la mismísima NSA le prohibió al recién elegido honoluluense utilizar el terminal BlackBerry que tanto le gustaba y que le deberían "arrancar de las manos" como si fuese el rifle Winchester de Charlton Heston.

Aunque al final, he can, y se salió con la suya. Imagino que por la falta de imaginación y las esperpénticas alternativas de las que se hablaba.

Desde ese momento no se pone en duda la seguridad de los servicios de Blackberry, más bien lo que desean los gobiernos es poder acceder a la información que transmiten.

El siguiente capítulo es en el 2008 cuando la India exige a RIM las claves para descifrar tráfico y mensajes electrónicos, aunque finalmente no lo ven necesario. Por lo menos, hasta la semana pasada, donde sus antiguos miedos volvieron a surgir levantando nuevamente la reclamación.

Otro asalto exactamente igual ésta ocurriendo con Arabia Saudí, Emiratos Arabes e Indonesia este mes de Agosto, y del que esperamos noticias, ya que por el momento solo se ha acordado instalar un servidor en Arabia Saudí, evitando más conflictos en este país.

El último golpe que ha recibido Research In Motion es el gobierno Alemán que no permite a sus ministros el uso de esta tecnología (tal y como hizo la NSA) sustituyendola por el terminal movil SiMKo 2 (la M bien podría ser de Merkel, por la publicidad que les hace). Aunque aquí no parece haber discusión.

¿Qué opináis? No, aún no, primero deberíamos entender bien cómo funciona su sistema, aquí unos enlaces por dónde empezar:

Pirateando al pirata: Televisión de pago "by the face"

noreply@blogger.com (Contribuciones) — Wed, 11 Aug 2010 05:13:00 +0000

La información descrita a continuación está pensada con fines académicos.

Si haces mal uso de ella, será tu responsabilidad, no nuestra.

Cardsharing es el método por el cual receptores independientes obtienen acceso simultáneo a una red de televisión de pago, usando una tarjeta de abonado de acceso condicional legítima. Típicamente, la tarjeta legítima está adjunta a un ordenador personal o Dreambox el cual está conectado a Internet, y está configurado para proporcionar la palabra de control legítimamente descifrada a otros receptores que piden información. Esta palabra de control descifrada es entonces usada para descodificar un servicio de acceso condicional codificado, como si cada uno de los otros receptores estuviera usando su propia tarjeta de abonado. (http://en.wikipedia.org/wiki/Card_sharing)

Para poder comenzar necesitaremos de una antena de satélite en nuestro domicilio. La mayoría de viviendas ya tienen una preinstalada, y si nos encontramos en Europa puede estar orientada a cualquiera de los tres satélites Hispasat 30º Oeste (1B, 1C y 1D) o a los ocho de Astra 19’2 Este (1B, 1C, 1E, 1F, 1G, 1H y 2C). En nuestro caso usaremos este ultimo ya es donde están los servicios que queremos visualizar. Si necesitas instalar una tu mismo (recomendado) por unos 30€ puedes tener una antena con un plato de 80cm, LNB universal y herrajes. Si quieres facilitarte la vida puedes comprarte una antena motorizada.

No es nuestra intención centrarnos en la orientación de la misma ya que hay bastante documentación sobre esto. Sí recomendaremos una aplicación disponible para Android y iPhone que nos hará la vida más fácil para instalar correctamente la antena.

El software mostrado en el video anterior, DishPointer, podréis encontrarlo en esta dirección, y una pequeña guía en este enlace.

Una vez finalizamos con la antena necesitaremos instalar un descodificador. Normalmente se utilizan los famosos clones de Dreambox. Este ultimo se utiliza frecuentemente por fabricar hardware de bajo coste (Procesador PowerPC ~250Mhz, 96Mb RAM, 32 Mb Flash) corriendo un sistema operativo GNU/Linux, con la flexibilidad que esto nos aporta para poder actualizarlo, usar firmwares personalizados, etc. También es posible utilizar descodificadores basados en tarjetas PCI (ya hablaremos más adelante sobre estas en hacking de satélites donde se usará una tarjeta Hauppauge WinTV HVR 4000).

Con el equipo necesario ya podemos empezar a entender un poco más como funciona el Cardsharing y cuales son sus protocolos:

Radegast : De los primeros protocolos, bastante inseguro.
Gbox : Usado sobre todo en PC.
Mbox : Es algo más nuevo y aporta mejoras de otros protocolos.
Newcamd : Uno de los más usados por la mayoría de servidores sobre todo los que no son GNU/Linux (tipo Mvision).
CCcam : Sin duda el más famoso y potente.

Aunque hay bastantes más (Sbox, Evocamd, MGcamd, RQCam, IncubusCam, SCam, VizCam, Hypercam, etc) estos son los más usuales. Podemos ver un ejemplo sencillo de conexión, donde en resumidas cuentas el CCcam Server dispone de la tarjeta de Abonado y mediante Internet comparte esta como una tarjeta virtual en el cliente Dreambox 500. Otros protocolos permiten usar nuestro cliente también como servidor de claves para poder distribuir el servicio ya que normalmente y de forma recomendada un servidor de claves suele tener de media unos 15/20 clientes.

Toda esta información nos permite conocer a grandes rasgos como están montadas estas redes de pago por visión. Como es habitual se suelen montar por personas no muy cualificadas que desconocen como implementar las medidas de seguridad necesarias para evitar que se usen bajo su consentimiento. La gran mayoría de ellos siguen funcionando con claves por defecto, sin cifrar las comunicaciones y sin monitorizar a los clientes.

Por lo tanto solo necesitamos conocer que satélite utiliza el servidor de claves que normalmente va asociado a los servicios que ha contratado. Acceder a la configuración del Servidor/Cliente añadir/copiar el usuario de acceso, instalar la lista de canales o realizar una búsqueda bajo dicho satélite y listo. ¿Como podemos encontrar estos servidores? Una forma rápida es usando Shodan (Compute Search Engine):

Realizamos una búsqueda con el banner “dreambox” y probamos con algunos de los resultados con la clave por defecto root/dreambox. En unos pocos intentos conseguimos acceso a varios de ellos como el siguiente:

Una vez dentro podemos ojear un poco que proveedores de TV están configurados e incluso con este firmware ver online o mediante VLC un canal seleccionado como vemos en la siguiente imagen.

Ahora solo queda ver la configuración del Cliente y en este caso vamos a copiarla. Hay que tener en cuenta que dependiendo del protocolo solo podremos usar una sesión por lo que dejaríamos sin servicio al otro descodificador, pero bueno solo es una prueba para ver que funciona correctamente. Accedemos mediante telnet/ssh según este habilitado con la clave por defecto y accedemos al fichero de configuración:

En este cliente no se están usando saltos, el host xxxx.dyndns.org es el servidor y el usuario/clave ‘dec400aa’. Por lo que solo tendriamos que configurarlo en nuestro decodificador en el fichero de configuración Cccfcam.cfg que normalmente se encuentra en /var/etc, reiniciar el servicio. Tener la antena orientada al satélite correcto, una lista de canales o buscar directamente los mismos de forma automática y a disfrutar de los mismos.

Si eres de los que no se quiere complicar la vida, ya hay sitios que ofrecen servidores de forma libre, aunque normalmente son servidores que han sido pwneados y que suelen publicados cuando hay eventos importantes (Futbol, Baloncesto, NFL..), algunas :

Entrada escrita por ReverseSkills

No todo son md5 o sha1 en este mundo

noreply@blogger.com (Alejandro Ramos) — Tue, 10 Aug 2010 05:39:00 +0000

Estamos acostumbrados a que todas las aplicaciones web utilizan siempre los mismos tipos de hash y que sea lo que sea lo que rompamos, al final se podrá utilizar los tropecientos gigas de tablas rainbow para obtener la contraseña en "un rato".

Desgraciadamente para unos y afortunadamente para otros, esto no siempre es así y últimamente los productos más conocidos utilizan distintos algoritmos para generar sus hash.

Sirva también como ejemplo para todos aquellos que desarrollan aplicaciones web o almacenan usuarios y contraseñas en bases de datos y ficheros a los que en algún momento alguien podría acceder.

En la siguiente tabla se muestra algoritmos y aplicaciones representativas de lo comentado anteriormente:

Aplicación	Algoritmo
e107	md5(md5($pass)
EyeOS v1.8.5.3	md5($pass.md5($pass))
Invision Power Board 2.x.x	md5(md5($salt).md5($pass)
Joomla 1.5.15 (default salted)	md5($pass.$salt)
MediaWiki >= 1.1.0	md5($salt.md5($pass)
osCommerce	md5($salt.$pass)
phpBB > 3.0.0RC5	phpass($pass)
SMF 2.0.x / 1.1.x	sha1($username,$pass)
vBulletin	md5(md5($pass).$salt)
WordPress > 2.5	phpass($pass)

Para ejecutar fuerza bruta sobre estos hashes se han diseñado múltiples herramientas en las que profundizaremos en otra entrada y que pueden hacer uso de las GPU de la tarjeta gráfica o no, como son hashcat, oclhashcat (GPU), Lightning Hash Cracker (GPU), PasswordsPro, Extreme GPU Bruteforce (GPU) o IGHASHGPU (GPU).

Mediante un pequeño script en php me he creado algunos de estos hashes para probar la herramienta hashcat y tomar algunas mediciones, usando como parámetros el hash de "12345", con el salt "abcdefghij" (para aquellos algoritmos que lo necesiten) y el nombre de usuario "admin":

<?php
require 'PasswordHash.php';
$pass="12345";
$salt='abcdefghij';
$username='admin';
$t_hasher = new PasswordHash(8, FALSE);
$hash = $t_hasher->HashPassword($pass);
echo 'md5(md5($pass): '.md5(md5($pass))."\n";
echo 'md5(md5($salt).md5($pass): '.md5(md5($salt).md5($pass))."\n";
echo 'md5($pass.$salt): '.md5($pass.$salt)."\n";
echo 'md5($salt.md5($pass): '.md5($salt.md5($pass))."\n";
echo 'md5($salt.$pass): '.md5($salt.$pass)."\n";
echo 'sha1($username,$pass): '.sha1($username.$pass)."\n";
echo 'md5(md5($pass).$salt): '.md5(md5($pass).$salt)."\n";
echo 'phpass($pass): '.$hash."\n";
?>

Una alternativa al script es utilizar la magnífica página: Hash Generator.

La ejecución se realizó mediante un ataque de fuerza bruta de 1 a 5 caracteres con un juego de caracteres amplio:

./hashcat-cli.bin -a 3 --bf-cs-buf \
 'ABCDEFGHIJKLMNÑOPQRSTUVWXYZ-_@\!$abcdefghijklmnñopqrstuvwxyz01234567890' \
--bf-pw-min=1 --bf-pw-max=5 -m MODO -n 4 ARCHIVO

Los resultados muestran una orientación de que algoritmos serán más lentos de atacar:

Algoritmo	hash/sec	Tiempo	Hash
md5(md5($pass)	3.48M	6m27s	1f32aa4c9a1d2ea010adcf2348166a04
md5($pass.md5($pass))	no sop
md5(md5($salt).md5($pass)	2.32M	8m52s	380208ca0107157c64d25b23ee588d5d
md5($pass.$salt)	4.28M	5m22s	bdb0f53fdd087dd9be9ca316a22ae83f
md5($salt.md5($pass)	2.81M	7m15s	99c2ec6d581dae0c04a02124790273fb
md5($salt.$pass)	4.22M	5m10s	f304c3e7226f0284f0d5f7c4a384e6e2
phpass($pass)	4.51k	6745m	$H$9abcdefghHix3FIPIQhE2AkCoctFaC/
sha1($username,$pass)	3.83M	5m43s	d4e8e6deaa7b1f8381e09e3e6b83e36f0b681c5c
md5(md5($pass).$salt)	2.94M	7m36s	b5e8fe63ed242468b7834289f3024955

Lo que lleva que el que mejor aguanta el ataque es PHPASS, desarrollado por la gente de OpenWall (conocidos por ser los creadores de john the ripper), aunque desgraciadamente esta función no está disponible nativamente en PHP y será necesario instalar la clase.

Fortificación de MySQL - 1/3

noreply@blogger.com (Alejandro Ramos) — Sun, 08 Aug 2010 22:15:00 +0000

MySQL se ha convertido en el motor de bases de datos más usado y potente del mundo opensource. Pero debido a la versatilidad que ofrece, la configuración por defecto en los paquetes de distribución y el suyo propio no considera todos los aspectos de seguridad que se han de contemplar en un entorno controlado.

Las siguientes entradas pretenden enumerar brevemente cuales son los puntos más importantes que se deberían revisar en una implantación segura de esta aplicación.

El archivo de configuración de MySQL se encuentra en el archivo: "C:\Program Files\MySQL\MySQL Server 5.x" en el caso de Windows o /etc/mysql/my.cnf en el caso de sistemas Linux.

1.- Restringir o deshabilitar el acceso mediante red: si el servicio se encuentra en el mismo equipo que la aplicación que realiza las consultas no es necesario que mysql escuche peticiones en todos los interfaces de red. Una de las medidas más importantes es dejar únicamente el puerto abierto en aquellas IPs donde sea estrictamente necesario. Para efectuar este cambio y que solo se pueda conectar localmente, en la sección [mysqld] indicar:

[mysqld]
bind-address=127.0.0.1

Si por el contrario queremos deshabilitar por completo el acceso mediante un socket de red, basta con añadir la directiva skip-network:

[mysqld]
skip-networking

Por último, si se ha de utilizar el servicio en remoto, todos los usuarios de las aplicaciones que conecten deben estar limitados mediante su dirección de origen (host). Desde el prompt de mysql:

mysql> GRANT SELECT, INSERT ON basededatos.* TO 'usuario'@'host';

2.- Eliminar el acceso a la tabla "user" de la base de datos a todos los usuarios excepto los de administración: de esta forma otros usuarios del motor no podrán consultar las contraseñas y accesos que contiene MySQL.

Para ver los privilegios de un usuario:

mysql> SHOW GRANTS FOR 'usuario'@'host';

Para eliminar privilegios:

mysql> REVOKE ALL PRIVILEGES, GRANT OPTION FROM usuario;

3.- Deshabilitar el uso de LOCAL INFILE: mediante estos permisos se pueden leer ficheros del sistema operativo desde la base de datos, algo común cuando se explota una inyección de código SQL. Para deshabilitar esta función se configura la variable local-infile a 0:

En MySQL anterior a 5.5

[mysqld]
set-variable=local-infile=0

Para MySQL 5.1 o superior:

[mysqld]
local-infile=0

4.- Cambio de nombre de usuario root y su contraseña: al igual que en los sistemas operativos, se recomienda que el administrador de la base de datos no sea el usuario root y mantenga una contraseña segura. Si MySQL es una versión superior a 5.0.2

mysql> RENAME USER root TO r00tz

En caso de que la versión de MySQL sea inferior:

mysql> use mysql;
mysql> update user set user="nuevousuario" where user="root";
mysql> flush privileges;

Para modificar la contraseña de un usuario se puede utilizar el comando mysqladmin o se puede hacer mediante SQL:

mysql> use mysql;
mysql> SET PASSWORD FOR 'username'@'%hostname' = PASSWORD('newpass');

5.- Eliminar la base de datos "test": que se distribuye con el servicio y no es necesaria. Para hacerlo directamente en SQL:

mysql> drop database test;

O mediante línea de comandos:

shell> mysqladmin -u username -p drop test

6.- Eliminación de cuentas obsoletas y acceso anónimo: que son creadas en algunas instalaciones de MySQL, para comprobar si existen este tipo de usuarios:

mysql> select * from mysql.user where user="";

Si se muestran usuarios, se pueden eliminar mediante DROP USER (en MySQL 5)

mysql> DROP USER "";

Si la versión de MySQL es inferior a 5.0:

mysql> use mysql;
mysql> DELETE FROM user WHERE user="";
mysql> flush privileges;

Referencias:

Enlaces de la SECmana - 31

noreply@blogger.com (Alejandro Ramos) — Sun, 08 Aug 2010 05:00:00 +0000

Hoy domingo, ¿cómo de ético es que me coma unos churros y me quede toda la mañana encerrado con el aire acondicionado mientras leo? Para que luego digan que en verano la cosa no se mueve... aqui van unos cuantos enlaces:

El conjunto de herramientas BinPack que se ha liberado en Las Vegas.
El INTECO publica el informe: "Implicaciones de seguridad en la implantación de IPV6 (PDF)"
La herramienta proXPN, basada en OpenVPN, permite hacer un túnel que permitirá navegar anónimamente y sin que puedan interceptar nuestras conexiones.
Backtrack libera la R1 de su versión 4, con nuevo kernel, escritorio, mejor soporte hardware, y todas esas cosas que tienen las versiones nuevas. Recordad que no es la única distribución de seguridad: WeakNet acaba de ser publicada.
Seguro que casi todo ya habéis leído otro ejemplo de que un dedo no hace mano sin sus hermanos, con la vulnerabilidad en la AEAT escrito por reversemode en 48bits.
¿Interesado en el desarrollo de exploits? ¡fácil! Aquí puedes ver por dónde empezar: From 0x90 to 0x4c454554, a journey into exploitation.
Con el jailbreak disponible para la última versión del firmware de iPad/iPhone/iPod Touch, finalmente se confirmó que aprovechaba principalmente una vulnerabilidad del navegador Safari en la librería de PDFs. Los PDFs vulnerables se pueden encontrar en este directorio.
Ataque de ClickJacking aprovechando la semana de los tiburones de Discovery Network.
Informe de la compañía AVG con el análisis de la botnet "Mumba", la cual tenía infectados más de 50.000 PCs.
Durante unas horas se descubrió una vulnerabilidad en reCAPTCHA, el sistema de CAPTCHA comprado por Google, aprovechando un fallo encontrado utilizando la función de audio. Fue rápidamente solventado. Después, en la Defcon 18, se presentó la conferencia "decoding reCAPTCHA", cuyo material tenemos ya disponible.
La guardia civil desmantela una red de estafa a compañías telefónicas (¿alguien dijo Robin Hood?)
Presentación que hizo el Maligno en la Defcon 16 de la última (y no tan privada) versión de Foca.