martes, 23 de diciembre de 2008
Más programas y sitios para aprender técnicas de hacking
Estos días he encontrado otros sitios con aplicaciones y retos hechos adrede para aprender sobre seguridad informática y técnicas de hacking. A través de iniqua me entero de la existencia de BadStore, o el Stanford SecuriBench. Viene también WebMaven, pero si vamos a la propia página del sitio nos dicen que es código inicial de WebGoat, y que nos cambiemos a este, entre otras recomendaciones. También me entero de la existencia del foro Heorot, que no es específico de seguridad web sino de pen-testing en general.
Y a través de equilibrioinestable, me entero de Bright Shadows, otro foro sobre hacking en distintos ámbitos.
Entradas en este blog relacionadas: Aprendiz de hax0r
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
miércoles, 17 de diciembre de 2008
Owasp Testing v3 y TV
Mira por dónde, si hace un par de días hablábamos del handbook de seguridad en navegadores web, hoy sale una lectura obligada para todo aquel que quiera estar al día en desarrollo seguro de aplicaciones y en hacking web: la guía de pen-testing de Owasp.
Promete: han ampliado el número de categorías, que pasa de 8 a 10, y el número de controles, que pasa de 48 a 66. Entre otras cosas chulas, nos han puesto artículos nuevos sobre testing de captchas, sobre autorización, XSS o web services (de acuerdo a la presentación).
Y además de la guía, hay otro recurso del que me gustaría hacerme eco: la Owasp.tv . Contiene videos con conferencias realizadas por los distintos chapters de Owasp, de momento, los de New York 2008. Esperemos que evolucione favorablemente :)
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
martes, 16 de diciembre de 2008
Handbook de seguridad en el navegador
Vía Blog de un informático, me entero de la existencia de este Browser Security Handbook, un manual recopilatorio de las medidas de seguridad existentes en los navegadores web más utilizados, creado por Michael Zalewski.
Pensado para desarrolladores y todos aquellos dedicados a la seguridad informática, describe conceptos básicos sobre navegadores (URLs, DOM, etc), las medidas de seguridad que tienen los distintos navegadores analizados, y mecanismos de seguridad experimentales o desfasados.
Tiene buena pinta :)
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
sábado, 13 de diciembre de 2008
Saber presentar en público
Acabo de ver una presentación de Gonzalo Álvarez Marañón sobre seguridad en aplicaciones de web. En menos de media hora, y sin que me haya enterado ni de que había pasado media hora, pudo explicar a su auditorio lo que es un XSS, un phising, un sql injection, o un ataque de envenenamiento de cookies. De forma muy sencilla, no con una presentación powerpoint sino con una aplicación web real: una tienda de jamones.
Nos pone la presentación en su blog el arte de presentar.
Altamente recomendable :)
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
martes, 9 de diciembre de 2008
Algo de lectura para cinco minutos
Acabo de echarle un vistazo al Insecure Magazine número 19, el cual podeis descargar de aquí. Este post es sólo para recomendaros leer el artículo "Eight holes in Windows login controls", y el de OWASP, pues habla de un par de proyectos que llaman la atención ;) Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
domingo, 30 de noviembre de 2008
En casa del herrero...
Hoy leo en Coding Horror el post “Coding: It’s just writing”. Nos recuerda que programar bien, tiene que ver tanto con hacer que un programa haga lo que debe, como con hacer que los demás lo entiendan
Nos mencionan el concepto de “Literate programming”, original de D. Knuth, con el siguiente párrafo, que escribió:
“Let us change our traditional attitude to the construction of programs: Instead of imagining that our main task is to instruct a computer what to do, let us concentrate rather on explaining to human beings what we want a computer to do.
The practitioner of literate programming can be regarded as an essayist, whose main concern is with exposition and excellence of style. Such an author, with thesaurus in hand, chooses the names of variables carefully and explains what each variable means. He or she strives for a program that is comprehensible because its concepts have been introduced in an order that is best for human understanding, using a mixture of formal and informal methods that reinforce each other.”
Slds!
P.D. También nos mencionan este otro post sobre borrar código (), muy bueno ;)
P.D. Relacionado: Enrique nos presenta el Tao del programador
Si te gustó esta entrada, quizás quieras suscribirte al blog por RSS...
miércoles, 26 de noviembre de 2008
MISSP en PYMES
¿Qué es un MISSP y por qué puede ser útil? Un Managed Internet Security Service Provider es un proveedor de servicios de internet (ISP), que complementa su oferta al cliente con servicios de seguridad gestionada, como firewalls en red, vpn, detección de spam, o detección de intrusiones.
La idea básica es proteger el acceso a Internet, tanto en tráfico entrante como saliente, desde la propia red del operador en vez de en las instalaciones del cliente. Típicamente será un servicio operado desde un Security Operation Center propiedad del ISP, que deberá contar con soluciones tecnológicas adecuadas y personal especializado.
No es un concepto nuevo, ni mucho menos. Pero tampoco lo conoce todo el mundo ;) . En el FAQ de Sans nos hacen una descripción de qué son, y comentan algunos factores a tener en cuenta antes de decidir si contratar, o no, servicios de estas características. Básicamente:
- si se dispone de la capacidad de generar firmas propias para los sistemas de detección de intrusiones, o si por el contrario, se depende del fabricante del IDS
- ¿se dispone de una variedad de soluciones, que permitan operar sobre entornos tecnológicos variados, o se utiliza una solución global para todo?
- ¿qué medidas de seguridad física se emplean en el SOC?
- ¿qué medidas se han aplicado con respecto a la tolerancia a fallos? ¿Cuál es el proceso de notificación de fallos? ¿Se revisa periódicamente el funcionamiento de los equipos? ¿Existe un sistema de centralización de logs, que permita revisar los mismos en caso de que un equipo se vea comprometido?
- ¿se confía el servicio a personal propio o subcontratado? ¿Se investiga a las personas que componen el equipo, antes de contratarlas? ¿Se realizan acuerdos de confidencialidad en todos los casos?
- ¿qué importancia da el proveedor a las certificaciones en seguridad? ¿El equipo que se ocupa del servicio recibe formación contínua, que le permita seguir al día?
Otras cuestiones interesantes no tienen que ver tanto con el propio servicio en sí, como con la manera en que el cliente utilizará este servicio. Es el propio usuario el que tiene un conocimiento exhaustivo de su propia organización, y podrá distinguir amenazas reales de las que no lo son. Su gestión de riesgos es el motor del resto de las tareas a realizar en materia de seguridad, no se debe olvidar esto nunca. Una pequeña o mediana empresa podría pensar que contratando un servicio de seguridad gestionado como este resuelve todas sus necesidades de seguridad. Sin embargo, lo que hace es externalizar los medios técnicos necesarios, pero sigue teniendo necesidades organizativas a las que prestar atención.
Así será necesario que se defina un plan de acción en caso de que se detecte un riesgo real, y esto es algo que sólo el personal interno de una organización puede realizar. Sólo los usuarios pueden priorizar adecuadamente sus riesgos, decidir cuál el plazo fijado para la resolución del problema detectado, o establecer cuáles son las medidas de mitigación y supervisión adecuadas a su entorno y a los medios de que dispongan. Y son ellos los que deben definir sus propios planes de contingencia y de continuidad de negocio. Por eso, por ejemplo, en Inteco existe un plan de impulso a la certificación e implantación de un SGSI en la PYME (hay que decir que una empresa que decida implantarlo, obtiene una subvención del Plan Avanza que cubre un elevado tanto por ciento de los costes de implantación).
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
martes, 18 de noviembre de 2008
Quinto S.I.R. de Microsoft
Sólo una notita rápida para dejar este enlace al último informe de tendencias malware elaborado por Microsoft, presentado hace unos días y que leo hoy.
Basado en datos obtenidos mediante sus productos y contrastados (o eso dicen, no lo sé) con terceras fuentes, nos cuentan algunas cositas sobre:
- Tendencias en publicación de nuevas vulnerabilidades
- Tendencias en explotación de vulnerabilidades sobre productos Microsoft
- Tendencias en explotación de vulnerabilidades en navegadores web
- Incidentes de seguridad
- Tendencias en malware
Slds!
Otros sitios que se hicieron eco de este informe:
Michael Howard nos cuenta también sus impresiones.
Sahw
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
martes, 11 de noviembre de 2008
WPA/TKIP roto
Hoy es uno de esos días en los que siento que el tiempo no da para todas las cosas que quiero hacer, incluyendo trabajo, tareas domésticas, vida social, etc... y además ser blogger. Os confieso, últimamente lo llevo mal, esto consume, realmente mucho mucho tiempo. Hoy por ejemplo me gustaría escribir algo para recordarlo yo en el futuro (este blog es también mi memoria) y para compartirlo con todos vosotros, sobre el problema encontrado en TKIP, el algoritmo de cifrado que se utiliza en el estándar de redes inalámbricas WPA.
Podría acortarlo, imitando al maestro Schneier (con todo el respeto, eh), que sólo nos dice: I haven't seen the paper yet. Impresionante: un post realizado con sólo seis palabras, se apunta los enlaces, los comparte con todo el mundo y triunfa más que los Chichos. Bate otro récord: el de tener más comentarios que palabras en el post.
En RaDaJo, un blog más que recomendable que tengo entre mis lecturas obligadas, se portan mucho mejor y nos dan todo lujo de detalles acerca del problema, quién lo ha descubierto (miembros del equipo de aircrack-ng: Eric Tews y Martin Beck), cuándo se conocerán todos los detalles técnicos (en la PacSec 2008 de Tokio, esta semana. ¿Habrá ido el Rey a verlo, o sólo es casualidad que esté por allí?) y qué medidas aplicar al respecto, que son:
- para usuarios finales: cambiar de TKIP a AES. Esto en algunos routers requerirá cambiar a WPA2, que obliga a tener algo más que TKIP. En otros se puede seguir utilizando WPA, pues permiten el uso de AES como algoritmo de cifrado.
- para empresas: si no se utilizar puede AES, aplicar medidas de monitorización, por ejemplo mediante un Wireless IDS.
Slds!
Algunos enlaces:
paper sobre el problema
Actualización 12/11/08: GigA también nos habla de ello, con más detalle técnico
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
sábado, 8 de noviembre de 2008
Una galleta
"¿Sabe Facebook demasiado sobre sus usuarios?". Es un tema del que se hablado muchas veces (yo mismo varias veces por aquí). Hace unos días por ejemplo, en El País. Aunque creo que lo han titulado mal, porque dicho así, parece que sea culpa de la aplicación el que los usuarios pongan la información ahí. Más bien habría que titularlo "¿Pones demasiadas cosas en Facebook?" (por decir uno, lo mismo en Orkut, Hi5, Tuenti...). El propio artículo va en esa línea.
Prácticamente todos nosotros tenemos cuenta en alguna, o varias de estas redes. No hay nada malo en ello. El problema está cuando no pensamos mucho no sólo en lo que ponemos, sino en quién podría verlo... . Y eso no siempre está tan claro. Se puede restringir quién ve tus cosas, claro. Pero esto también es confuso, por ejemplo, en Facebook está la regla que dice que mis fotos pueden verlas mis amigos y los amigos de mis amigos. ¿Quienes son los amigos de mis amigos?.
En mi caso, por ejemplo, entre mis amigos están algunos compañeros de trabajo, y uno de ellos en particular resulta que tiene agregado a mi propio jefe. ¿Y si me acaba pasando lo mismo que al "astuto" empleado que mencionan en El País? . Además ocurre que agregamos a casi todo el mundo: conocidos de tu ciudad de unas pocas noches de copas, antiguos compañeros de la facultad a los que no ves hace años, y con los que pudiste tener o no tener una relación particularmente estrecha, antiguos compañeros del cole, amigos de amigos con los que has coincidido unas cuantas veces... realmente podemos estar compartiendo nuestras intimidades con mucha gente.
Otro tema es que ponemos plugins en nuestro sitio de la red social, y al hacerlo damos consentimiento para poder utilizar algún dato de los que sabe el portal de marras sobre nosotros a alguien que no conoces. Claro... si no los utilizas, la verdad es que usar la red social que sea pierde algo de su gracia. Nos gusta decir a los demás qué pitufo somos, qué poder de "Heroes" es el que más nos pega, qué libros leemos y cuál estamos leyendo, cuál es nuestro famoso ideal o qué opinamos de Barack Obama o de la madre que parió al topo. Al usarlos, además de dar consentimiento para acceder a nuestros datos, podemos estar también abriendo una ventana para coger algún bichillo. Podría poner un par de ejemplos, pero me quedaría muy corto, mejor usa al oráculo.
Así que no es que la red social sepa demasiado sobre sus usuarios, sino que los usuarios se desmadran muchísimo a la hora de ceder sus datos. Y no se los dan sólo a la propia aplicación, que eso parece lo de menos. La cuestión es que se lo dan a otros sin mirar. Nos puede pasar a todos: mi propio perfil está todo lo restringido que puedo conseguir, pero siempre (SIEMPRE) podría cometer un error. Un despiste un domingo por la mañana lo tiene cualquiera, cuando has salido la noche anterior, hombre.
Y ahora quizás os preguntareis por qué titulo este post "una galleta". Pues porque hace falta que alguien se pegue una torta gorda con este tema. El artículo que menciono al principio dice que los españoles no tienen queja, de momento. Me empeño, y de vez en cuando advierto estas cosas a mis amigos... con el resultado de que me miran como diciendo "ya está otra vez el casco friki informático dando mal". Así que nada, mejor estar callado... que ya llegará la sangre, y la letra con sangre entra. Ocurrió con los sitios estos que supuestamente dicen quién no te admite o te ha eliminado: algunos de mi colegas aprendieron cuando a una amiga le robaron su cuenta de messenger.
Slds!
Algunos enlaces:
otro artículo reciente
algo de segu-info, y algo más
decálogo de normas para redes sociales (visto en blogantivirus)
también podemos poner información falsa (lo cuentan en el blog de S21sec)
guía legal sobre las redes sociales, menores de edad y privacidad en la red (de Inteco)
el malware asalta las redes sociales (en RedSeguridad)
Actualización lunes 10: D.Danchev también nos dice lo de las cuentas falsas, en este caso en Bebo. Y nos cuentan algo más sobre bichos en facebook, en Facebook worm drives by Google Reader and Picasa.
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
martes, 4 de noviembre de 2008
Puesta al día y algo sobre un gusano de MS08-067
Sigo con mi ciclo de puesta-al-día: hoy leo un poquito sobre malware variado alojado en webs del mundo mundial y el problemilla del MS08-067.
Por ejemplo en Websense nos explican que ahora, el malware en web no está sólo en javascript, sino que utiliza elementos HTML para almacenar contenido., y luego utilizar algún exploit de otro pack llamado The Poly Exploit. También sobre una cosita que afecta únicamente a blogs de Blogspot.
En F-Secure nos cuentan cómo bichitos antiguos siguen pululando por ahí, con posibilidades de infectar a gente, además. Y después rellenan contenido en su blog con la vulnerabilidad MS08-067, opinando que va a ser otro gusanito (de hecho nos dicen que ya es otro gusanito). En Hispasec nos llaman a la calma, indican que no se va a generar un problema de la magnitud que tuvo el gusano Blaster, que explotaba un problema de características similares. Mientras, en el blog de SDL de Microsoft Michael Howard parece enfadado, y no en mi opinión no le falta razón: no creo que se pueda pedir que funcione con carácter retroactivo, o dicho de otra forma, que sistemas operativos más antiguos tengan un nivel de seguridad tan bueno como el de los modernos. Podrán mejorar, pero no ser igual de buenos. Por tanto su SDL no ha fallado, todo lo contrario, parece que están haciendo las cosas bien.
Enlaces:
metasploit tiene plugin para esta vulnerabilidad
algo de Sans
algo en blog SWI de Microsoft
algo y algo más en Arbor Networks
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
domingo, 2 de noviembre de 2008
Tecnología para beneficio de todos
Este post NO habla de seguridad informática, sino de ONGs y de hackers. ¿Interesado?. Entonces sigue leyendo...
Llevo un tiempo que no puedo escribir ni leer tanto como me gustaría, y hoy que por fin he tenido la tarde libre para poder hacerlo, quería informarme de cómo funciona el famoso Clickjacking, ya sabéis, la vulnerabilidad descubierta por Jeremiah Grossman y Robert "Snake" Hansen, de la cual se conocen los detalles más o menos, desde hace un mes. Hay paper sobre el tema, por cierto.
El caso es que uno de los autores nos menciona también una de sus iniciativas, en este caso, de buen samaritano con los países más desfavorecidos. Su proyecto se llama Hackers for Charity, y tiene como misión proporcionar equipo informático para crear aulas, así como realizar proyectos de ámbito informático (desarrollo de software, por lo que he visto) que se implantarán en países de África. Una de las maneras que emplean para promocionar el proyecto y conseguir arañar unos cuantos dólares es el acceso exclusivo, o al menos en primicia, a contenido sobre seguridad informática, en el portal Informer, que tiene bastante buena pinta.
El suyo no es el único proyecto de este tipo que he conocido hasta ahora. Más cerquita, tenemos por ejemplo a Ingeniería Sin Fronteras, una ONG que tiene como fin la caridad mediante la realización, gratis, de todo tipo de proyectos de ámbito tecnológico, y esto incluye, por supuesto, los que tengan que ver con la informática.
Me parecen iniciativas increíblemente loables, de las que vale la pena hacerse eco.
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
sábado, 25 de octubre de 2008
Notas sobre problema en el TCP
La noticia ya es sabida, la anoto para recordar en el futuro... Después de haberse encontrado problemas con el DNS y con el protocolo BGP, y haberse puesto de moda el pre-aviso de vulnerabilidades con objeto de obtener algo de publicidad gratis mientras el descubridor da tiempo a los fabricantes a poner las medidas adecuadas en sus productos, ahora podríamos tener problemas con el mismo funcionamiento de TCP.
En este caso, fue una empresa llamada Outpost24 la que ha anunciado vulnerabilidades que implican la manipulación de la tabla de estados TCP (que registra en qué estado se encuentra una conexión TCP). De momento, no se han dado detalles acerca de cuál es el problema, parece tener que ver son las llamadas SYN cookies, un mecanismo que evita tener que mantener un registro del estado de una conexión, hasta que se termina el proceso de establecer la misma (el llamado TCP three-way handshake). Este mecanismo se utiliza para defenderse de los ataques SYN flood (es decir, evita que si un malote se dedica a lanzar únicamente paquetes de inicio de la conexión TCP, se desborde la tabla de estados TCP).
Se sabe que hay una herramienta llamada "socktress" que explotaría las posibilidades del problema, si bien no está disponible para descarga. Supuestamente, iban a darse más datos en las conferencias T2 de Helsinky, pero realmente no se ha ampliado información.
No creo que esto sea ninguna falsa alarma, porque las personas que han descubierto el asunto son auténticos TCP-ninjas, crearon por ejemplo el escáner Unicornscan. Espero a leer qué nos cuentan ;)
Algunos enlaces:
blog de uno de los autores
Algo de Fyodor
Entrada en Securityfocus
Algo de Hispasec
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
domingo, 19 de octubre de 2008
Estudio sobre botnets fast-flux
En este post hablamos de un estudio sobre redes de botnets que usan técnicas de fast-flux (tamaño, para qué se usan, características para detectarlas, etc) realizado mediante técnicas de data mining sobre resoluciones DNS.
El fast-flux es una técnica que consiste en cambiar periódicamente la resolución DNS de aquellas máquinas que participan en una botnet. Se pretende ocultar cuál es el servidor que aloja un sitio web parte de un phishing, o que sirve malware, colocando una red de máquinas que harán las veces de proxy. Estas máquinas, los bots de la botnet, redirigirán la solicitud que realiza cualquiera al sitio web controlado por el atacante, a los servidores centrales de la botnet.
En Sans Diary nos presentaban hace unos días un estudio realizado por Jose Nazario (véase también su worm blog) y Thorsten Holz, sobre el comportamiento de las redes botnet. Utilizan para ello los datos recogidos por el sistema ATLAS de Arbor Networks. En el estudio, identificaron dominios DNS que pudieran corresponder a redes fast-flux mediante estas técnicas:
- captura y análisis de spam
- listas negras de nombres DNS y análisis de malware
- a mano, es decir, por cualquier otro medio, como pueden ser datos presentados en informes de análisis antimalware
Se presentan algunas conclusiones interesantes. La difusión del concepto "fast-flux" tiene éxito: los creadores de estas redes han de ir "más lejos" (es un decir) para conseguir un registrador de dominios con el que no haya problemas para trabajar con este tipo de redes. Se usan más dominios de alto nivel que antes, y nos indican cuál es el dominio de alto nivel ("TLD", es decir, si son .com, .net, etc) que utilizan. Otros datos interesantes presentados: cuál es el tiempo de vida medio de un dominio fast-flux (el caso de Storm fue particular), cuál es el tamaño medio, en número de máquinas comprometidas, que tiene una botnet, cuántas de esas máquinas se están usando de forma activa como parte del fast-flux, o el propósito de las redes analizadas, obtenidos relacionando los datos de este estudio con estudios de otros. (No te voy a dar yo los datos: lee el paper ;) ).
El estudio deja fuera redes double-flux (es el caso en que también los servidores DNS forman parte de una botnet).
Por cierto, echadle un vistazo a las referencias, que están muy bien, destacando el proyecto FluXOR y trabajos relacionados con la detección de redes fast-flux.
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
miércoles, 15 de octubre de 2008
Mebroot
Poniéndome al día en noticias de seguridad informática que ha habido últimamente, he encontrado esta entrada en Sahw, sobre Mebroot, el primer malware instalado en el Master Boot Record que se ha conocido en mucho mucho tiempo.
Los equipos técnicos de F-Secure y de Symantec han colaborado en la investigación de este malware. Se puede ver una presentación sobre Mebroot realizada en las conferencias Virus Bulletin de este año, con algunos detalles interesantes (aunque me pierdo en la parte más técnica). Por ejemplo, que hubo algunos prototipos de software similar presentados en BlackHat en 2005 ("Bootroot") y en 2007 ("Vbootkit").
Según la propia presentación, es el primer rootkit, que se instala en el MBR, que además incluye un payload realmente malo en sus tripas, permitiendo descargar todo tipo de software malicioso, incluyendo troyanos bancarios. Se menciona Neosploit en la presentación, indicando la evolución de versiones de este paquete con Mebroot, entre Enero y Agosto 2008.
Algunos de sus puntos fuertes:
- no deja ningún ejecutable en el sistema de ficheros
- no utiliza ninguna clave del registro de Windows, ni tampoco ninguna manera estándar de lanzar la ejecución de un programa. Utiliza un buen número de funciones de la API de Windows no documentadas.
- no instala ningún tipo de módulo o driver nuevos en el sistema
- "huella" mínima en la memoria de la máquina infectada
- se ejecuta en los primeros estadios del arranque del sistema (está en el MBR)
- todas las operaciones de lectura y escritura en disco son difícilmente rastreables, también lo son sus comunicaciones por la red (por ejemplo, emplea un buen cifrado en todas estas comunicaciones)
- es capaz de protegerse frente a soluciones software que intente eliminarlo
Se utiliza la web para distribuirlo, es decir, un usuario se infecta porque ha visitado una sitio web comprometido previamente.
En fin, un nombre que nos deberá sonar, aunque sea sólo como culturilla general informática... porque dará mucho mucho mal.
Slds!
Algo más de información:
Symantec security response
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
miércoles, 8 de octubre de 2008
Still alive...
¿Muchos días sin escribir nada, verdad? Tranquilidad, no he perdido interés por el blog... un pico de trabajo me impide tenerlo atendido como se merece, pero en un par de días volveré a estar en plena forma :) . Mientras, dejo un enlace a un pequeño artículo de Eugene Kaspersky, sobre cibercrimen, que me ha gustado leer.
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
martes, 30 de septiembre de 2008
Certificaciones de desarrollo seguro
Leo hoy vía segu-info que ISC ha lanzado una nueva certificación de seguridad, en este caso, de desarrollo seguro, denominada Certified Secure Software Lifecycle Professional. Tengo que decir: ¡ya era hora!.
Ni una sola certificación de las demandadas habitualmente hasta la fecha es específica de desarrollo de aplicaciones, sino que todas son de redes, de sistemas propietarios (Microsoft, Cisco,...) o de gobierno TI (tipo CISA, CISM).
Había un hueco por cubrir, creo que eso está claro (y si me equivoco por favor deja caer un comentario), dado que ahora mismo, por ejemplo, los problemas en aplicaciones web son los más explotados, como dicen muchas estadísticas, por ejemplo el informe que nos hizo RedIris a principios de año, con los datos del 2007.
Parece ser que han dividido el temario en siete temas:
- conceptos de software seguro
- requisitos de seguridad en el software
- diseño de software seguro
- implementación/codificación segura
- chequeos de seguridad en el software
- aprobación del software
- implantación, operación y mantenimiento del software
Mientras, Microsoft ha anunciado que pondrá a disposición de los usuarios, para descarga, su SDL, según nos dicen en Securityfocus. Asimismo, también lanzará una certificación que acredite el conocimiento y experiencia en dicho SDL, dentro de su programa "SDL Pro Network", así como una metodología de análisis de amenazas (threat modeling) basado en este SDL, según nos dice Microsoft en su sitio web.
A mí me parece que ambas certificaciones prometen, la verdad. Pero espero que no se conviertan en otra medalla más, sino que sea algo realmente útil.
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
jueves, 25 de septiembre de 2008
La palabra "hacker"
Sobre el significado de la palabra "hacker" en los medios, y qué actitud adoptar frente a ello. ¿Aceptarlo o insistir aún más?
He leído estos días algo sobre eso de que han hackeado la cuenta de Sarah Palin, de que han hackeado el LHC (la web), y en fin, pues que tampoco es para darle tanto bombo y platillo.
Hombre, la verdad es que sí, que no es para darle bombo y platillo, como bien nos dicen en muchos sitios. Personalmente, el caso Palin me parece que es para sacarlo a los periódicos, por mema. La cosa es que esto me ha hecho reflexionar un poco, acerca de talibanizarse con el uso de la palabra "hacker".
Está muy bien y me parece loable, escribir para dejar bien claro cuándo una vulnerabilidad no es tal, pero ya es mejor dejar aparte el uso desde nuestro punto de vista inadecuado de algunas palabras. A la gente le da lo mismo el nivel técnico que tenga el problema que se haya explotado, porque la gente de a pie no tiene cultura de base al respecto.
Así, el significado de la palabra "hacker" se generalizó, no ahora sino hace mucho tiempo, lo mismo que hablamos de "médicos" y no siempre concretamos su especialidad o su nivel de sabiduría, usando la palabra "médico" por igual para referirse al que pasa consulta en un pueblo pequeño que el que hace operaciones de neurocirugía en el hospital más grande que se pueda imaginar. Absorbió también a todo aquello que los que entienden de seguridad informática no identifican con "hacking", sino con el cracking y otras muchas palabras que orbitan alrededor de la de "hacker". Por eso alguien se inventó esa cosa del "hacking ético" (sí, ya lo se, lo pongo en la cabecera del blog).
Sólo a la gente que se preocupa de temas de seguridad, le preocupa el significado original y genuino de la palabra "hacker", y a los demás pues no. Como muestra de que no hay cátedra al respecto, aunque sea sólo aquí en España, sólo hay que ir a donde se pone por escrito el significado de cada palabra: !al diccionario!, que es donde va a mirar la gente normal. Al diccionario, no a la wikipedia. He aquí:
No dice nada. La palabra ha evolucionado sola, y me parece que ya es hora de aceptar que se usará, ahora y siempre, esta palabra como lo que todo el mundo comprende. Podemos seguir eso de "Perdónalos, porque no saben lo que hacen". O podemos aceptar que el lenguaje ha evolucionado, aunque sea de una manera que no nos gusta un pelo. En cualquier caso, creo que ya vale de insistir en lo mismo.Por cierto, si a quien redacta una noticia se le pide un poco de investigación y hablar con propiedad... más importante todavía me parece que algunos conceptos comiencen a aparecer en los sitios más básicos. Señores de la RAE, elijan por favor significado para la palabra "hacker": ¿va a tener el genuino, el que tuvo en un principio y después fue deformado según su uso, o el digamos "deformado", pero que es el que entiende la gente de a pie?. Y no me digan que la palabra no es ya de uso común...
A todo esto, que yo sepa, no hay un equivalente en español para la palabra "hacker". ¿Me equivoco?.
Slds!
P.D. perdonadme que esta vez no ponga enlaces a otros blogs: no quisiera que nadie se diera por aludido. Respeto las opiniones de todo el mundo, y no quisiera que este post-reflexión que quiero compartir, fuera tomado como una crítica particular a nadie.
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
lunes, 22 de septiembre de 2008
Blog services
Para crear un blog (particularmente de seguridad informática) de calidad, hay más de una estrategia a seguir... este post habla de algunas que he encontrado últimamente, y que vale la pena promocionar.
Una de las cosas que todo buen blogger hace en primer lugar, es aprender de blogs con éxito cuáles son las razones por las que son visitados. Un novato cree que consiste en decirle a todo el mundo que tiene blog, pero en dos días entiende que eso no sólo no es suficiente por muchos amigos que tengas, y además es probable que el tema del que escribas les importe un carajo.
Así, pronto aprendes lo que hace de un blog, un buen blog: contenido de calidad. Sobre todas las cosas, eso: lo que escribas tiene que poder interesar a la gente. Es más, para mí, un blog sirve en primer lugar para saber si uno es capaz de escribir (bien) sobre un determinado tema, lo que significa conseguir que sea útil, divulgativo u original. Después, a mi modo de ver, que sea un blog temático ayuda, no me gustan los sitios que tan pronto me hablan de informática como me ponen las fotos de Angelina Jolie o la tía buena del momento. Publicitarlo también ayuda, y rápidamente se entera uno de lo que es un planet, de servicios como technorati y bitacoras.com.
Otra manera de hacer que tu blog resulte atractivo es proporcionar servicios a los demás. Por eso la gente comparte sus enlaces de delicious (que tanto nos recomienda lonifasiko) o indica en algún apartado dónde ha comentado últimamente, así da publicidad a otros blogs, cumpliendo con los mandamientos del buen blogger: hay que referenciar a otros de cuando en cuando (pondré algo de esto en breves, lo prometo). Pero no quiero centrarme en este tema, pues hay muchos otros sitios donde se puede encontrar información mejor que la yo pueda dar sobre cómo hacer un buen blog (a mí me gusta mucho DailyBlogTips).
El caso es que algunos llegan un poquito más allá, y por eso os escribo esta entrada: para dar publicidad a algunos que me han parecido originales, y que he visto en blogs sobre seguridad informática y/o de la información (que como decíamos antes, para mí no son lo mismo).
El primero es el bot de los compañeros de SecurityByDefault: puedes hablar con él tanto en gtalk como en messenger, y te dice cuáles son las últimas novedades en una lista de blogs seleccionados, entre otros servicios. Sencillamente agregar sbd.bot@gmail.com a gtalk, o sbd.bot@hotmail.com al messenger. Para utilizarlo, el comando "help" dirá cuáles son las opciones que permite utilizar. [Bueeeeeeeeeeeeeno, se me ve el plumero, ¿no?, ayer me preguntaban si me importaba que Informático y "Segurata" fuera uno de los blogs que presentan ;) Es por esa invitación que se me ha ocurrido escribir este post].
En otros sitios fomentan el encuentro de personas con intereses similares, creando foros y comunidades virtuales. Tenemos por ejemplo, en el blog Apuntes de seguridad de la información, un foro de seguridad en el que el autor participa, y enlaza en su sitio web con los últimos comentarios del foro. Otros sitios web crean comunidades virtuales, es el caso de logadmin, que hace poco anunció el lanzamiento de House of sysadmins. O, mirando a blogs de habla inglesa, la comunidad creada por el autor de Gnucitizen, House of hackers.
El último servicio blogger lo veía hace unos días en GobiernoTIC (un blog que acabo de descubrir), y me parece una idea increíble: tener una barra propia de búsquedas para Google, de forma que se puedan personalizar los resultados que presenta.
Parece una chorrada, pero si lo pensamos dos veces, puede ser bastante útil. En realidad, buscar bien en Google y similares no es tan fácil: no siempre sabemos expresar correctamente los términos de la búsqueda. Incluso, una vez hemos encontrado lo que buscábamos, ¿por qué no afinar la búsqueda, para obtener los mismos resultados o similares en otras ocasiones, descartando más fácilmente positivos del buscador que en realidad no nos valen?.
Resumiendo: tres tipos de servicios que se pueden dar en un blog, que van más allá de lo que la mayoría de la gente suele hacer, en este caso, blogs relacionados con la seguridad informática. Me ha quedado un post un poquito largo... si habéis llegado hasta el final, será porque os ha gustado :)
Slds!
Si efectivamente te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
SQL Smuggling
Visto en Yoire.com este paper sobre SQL inyection, titulado SQL Smuggling ("to smuggle" puede traducirse como "pasar de contrabando", o colarse sin ser visto) de la empresa Comsec: es un compendio de técnicas para camuflar ataques de SQL Injection, de forma que se puedan sobrepasar las defensas establecidas a nivel de aplicación o en un WAF.
Y hablando de todo un poco, veía esta entrada en Slashdot, sobre el ataque de inyección SQL que ha sufrido BussinessWeek, y que ha debido convertir su web en un nido de malware...
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
jueves, 18 de septiembre de 2008
Enlaces a P2P
Enlazar a redes P2P no es delito. Sin más comentarios. Espero que me perdonéis por no hacer un post más largo, con opinión, comentario, o similar, pero hoy, sencillamente, estoy que me caigo de cansancio...
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS... [bueno, por esta entrada particular quizás no, pero alguna de las anteriores puede que te parezca buena]
miércoles, 17 de septiembre de 2008
Micro y macro... seguridad
Curiosa e interesante comparación en el blog de Javier Cao, del mundo de la seguridad informática con el de la economía. O mejor dicho, de la seguridad de la información, pues no hay que confundir el continente con el contenido: queremos proteger, principalmente, el contenido, es decir la información, que es lo que vale.
Nos explica (resumiendo, leer su texto que es más amplio y está muy bien) dos conceptos:
Si la microeconomía habla de la economía en relación con acciones individuales (de un comprador, un fabricante, una empresa), la microseguridad nos hablaría de las acciones y decisiones en seguridad de la información en el día a día: tecnología que utilizamos para solucionar un problema, por ejemplo.
Si la macroeconomía se refiere al estudio de la economía de una región o un país, empleando magnitudes colectivas o globales, la macroseguridad tratará también de los problemas y decisiones en seguridad de la información a tomar a nivel global en una organización (empresa, institución, gobierno...). Objetivos, planificación, estrategias, estarían dentro de este concepto.
¿A qué es mejor dedicarse, o qué es más interesante? En este blog, mi intención es anotar y compartir lo que aprendo según esta definición de microseguridad (categoría "Aprendiz de hax0r") y lo que aprendo según esta definición de macroseguridad (categoría "Traje y corbata"). ¿Debería cambiar estas etiquetas a nombres más serios?.
Slds!
P.D. véase también el blog de Paloma Llaneza, para temas de macroseguridad. El contenido del post de Javier salió originalmente en el blog de Paloma Llaneza, que tiene artistas invitados en una categoría de entradas llamada "Aquí un amigo". Me parece una idea muy original :)
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
martes, 16 de septiembre de 2008
Gestión de riesgos y CVSS
En risktical.com nos hacen una interesante serie sobre gestión del riesgo y CVSS. Realmente, son los pensamientos del autor sobre por qué CVSS puede ser útil para quien haga un análisis de riesgos sobre una nueva vulnerabilidad, y cuáles son las diferencias con respecto al análisis completo. Particularmente, lo relaciona con una metodología de análisis de riesgos denominada FAIR.
Nos hace, entre otras reflexiones, una muy importante, para no confundir términos. Yo los confundía cuando empecé en estos temas, por lo que me parece interesante plasmarlo aquí. Y es que el resultado de la métrica no es una medida real del riesgo que una organización corre, pues hay otros factores a tener en cuenta para calcular la severidad real de una vulnerabilidad para una organización.
Con CVSS, la valoración de una vulnerabilidad no tiene en cuenta las salvaguardas que una organización ya tuviera desplegadas y que pueden servir para mitigar o incluso impedir un posible ataque. Tampoco la frecuencia con la que se tienen pérdidas debido a un ataque realizado con éxito, o el coste de las salvaguardas. Por tanto, es obvio que la medida final que se obtiene con CVSS no es lo mismo que el riesgo real que supone la vulnerabilidad medida. Y sin embargo, en CVSS Guide se indica que uno de los beneficios es obtener un nivel de riesgo priorizado.
Por tanto, CVSS debería ser usado como lo que es, es decir una métrica para valorar una vulnerabilidad por sí misma, y no el riesgo que supone para una organización. Hay que tener en cuenta, además, que el cálculo realizado por CVSS podría variar con el tiempo, pues uno de sus grupos de métricas, "temporal", refleja datos que pueden cambiar, por ejemplo, si hay un exploit efectivo disponible públicamente (en sitios como milw0rm). Por lo que la valoración de la vulnerabilidad en un momento dado, puede no ser la que haya que tener en cuenta finalmente para el análisis de riesgos. O podría requerirse una segunda iteración de este análisis.
Creo que podría ser interesante ver otros mapeos de CVSS con respecto a metodologías de análisis de riesgos.
Aquí van los enlaces a las cinco entradas de que consta la serie, como os digo, muy interesante:
Risk and CVSS - parte 1
Risk and CVSS - parte 2
Risk and CVSS - parte 3
Risk and CVSS - parte 4
Risk and CVSS - parte 5
Entradas relacionadas:
Measurable security: sobre CVSS y otros proyectos de FIRST
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
domingo, 14 de septiembre de 2008
Labo doméstico
Supongo que todos tenemos (o deberíamos tener) la necesidad de cacharrear, de probar cosas, de instalarnos la última distro, el último server, jugar con el último programa o la última herramienta de la que hemos tenido noticia, o probar la última técnica publicada en algún sitio. A mí me pasa, desde luego. Todo esto necesita para empezar tiempo, que es desde luego un bien escaso y además del tiempo, necesitamos algo de infraestructura en casa, si no tenemos la fortuna de que nos la den en el trabajo (cosa que le pasará a pocos, me parece a mí).
Hace unos días salió un hilo en la lista "pen-test" de Securityfocus, sobre los requisitos para montar un laboratorio doméstico. No puedo dejar de reproducirlo aquí en mi blog, pues me parece un tema de interés. Tener un labo de una vez por todas, siempre puesto, para llegar, y sin más, juguetear... qué gran tentación :) . Se propusieron varias opciones:
opción 1 - una única máquina con varios sistemas operativos instalados
Para los que se van a meter menos con temas de redes, y sólo desean tener instalados dos o tres sistemas operativos. Bien si sólo queremos experimentar un poco con aplicaciones, pero creo que se queda un poco pobre en general. Para ir jugando, nos recomiendan damnvulnerablelinux, las aplicaciones para aprender hacking de Foundstone (estos los conocía). También los livecd de De-ICE y un repositorio de software antiguo.
opción 2 - virtualización
En principio, la opción que yo veo como ideal, si no quieres gastar prácticamente nada de dinero. Requiere una o varias máquinas potentes, al menos, con una cantidad de memoria RAM considerable (yo pondría unos 4GB, para ir bien). Sin embargo es muy versátil, ya que puedes crearte redes de máquinas virtuales todo lo complejas que se desee. Hace poco tuve noticia de NetInVM, una red de máquinas virtuales con UML instalado (visto en RaDaJo), que tiene muy buena pinta. Otra opción es usar Netkit.
opción 3 - red doméstica
Para los más exigentes, sin duda. Ideal para todo tipo de pruebas (networking, kernel hacking...) que podrían salir mal por trabajar con máquinas virtuales, pero la opción más cara. Aunque digan por ahí que se puede conseguir con poco dinero, habría que preguntar cuánto dinero es poco dinero. Los requisitos que se detallan son bastante completos:
- dos PCs, configurados para arrancar desde discos duros extraíbles. Cada uno de estos discos tendría varios sistemas operativos, gestionando el arranque con un gestor como LILO o GRUB. Ambos tienen además tanto tarjetas ethernet como wireless, para poder montar todo tipo de escenarios.
- un portátil, que es de donde se lanzarían los ataques
- dos discos duros de gran capacidad compartidos en red (NAS) proporcionan almacenamiento extra a todos los equipos que se instalen. Todas las utilidades de hacking, datos que estas necesiten (diccionarios de contraseñas, por ejemplo), plantillas de configuraciones... serían algo así como nuestra caja de herramientas.
- para preparar redes con arquitecturas diferentes, hará falta al menos un router (se mencionaba un Cisco 2610), más de una tarjeta de red en alguno de los equipos, por si hace falta usarlo para montar un firewall o un IDS... en fin, esto irá en cada uno. Incluso más de una línea ADSL u otra conexión de banda ancha. Esto es lo que realmente vale dinero, me parece a mí.
Además, un pequeño detalle que no se menciona: ¡espacio!. Pues en alguna parte habrá que guardar tanto trasto... y, todo hay que decirlo, no todo el mundo lo tiene.
Conclusión...
¿Y por qué me ha venido a la cabeza escribir un post como este, indicando (con recursos de otros) cómo hacer un laboratorio propio? Pues porque he visto esta entrada en gurú de la informática, sobre honeyd, que llama mucho la atención. Nos explica cómo enmascarar el sistema operativo, para que tenga otro fingerprint. ¿No os apetece probarlo? ¿No apetece tener algo montado ya para probar cualquier cosa, y dejar de pensar "y si tuviera..."?. Por favor, sentíos libres para contar aquí con qué opción os quedais vosotros: la mía, de momento, es la opción 1, pues no hay presupuesto ni espacio para nada más.
Slds!
Actualización: Antonio en WanLinkSniper nos hablaba hace unos días de algo de esto: el concurso de redes domésticas de Cisco.
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
miércoles, 10 de septiembre de 2008
Estadísticas de seguridad web
Se acaban de hacer públicas las nuevas estadísticas de seguridad web que elabora el Web Application Security Consortium (WASC), pueden verse aquí. Son interesantes no sólo porque nos dicen cuáles son los ataques o problemas de seguridad web más comunes, sino porque también evalúan cuál es la manera más efectiva de detectarlos: análisis automáticos, pruebas de caja negra, o pruebas de caja blanca.
Algunas cosas ya las sabíamos, creo yo. Por ejemplo, que los análisis automáticos son representativos, o efectivos, primordialmente en aplicaciones "normales" abiertas a Internet. O que el XSS es el problema más detectado. Otros, sin embargo, no se mencionan tanto comúnmente, por ejemplo, de los datos analizados, puede verse que es mucho más probable detectar posibles fugas de información mediante pruebas de caja negra o blanca que mediante pruebas automáticas.
Se sigue verificando la regla de que las herramientas automáticas aún no pueden sustituir a la experiencia del pen-tester. En la detección de vulnerabilidades de nivel de riesgo bajo, las herramientas de análisis automático son más efectivas, pero cuando nos metemos con los problemas graves o sólo medianamente graves, hay que buscar a mano.
Lectura recomendable :)
Slds!
Si te gustó esta entrada, quizás quieras suscribirte al blog por email o por RSS...
lunes, 8 de septiembre de 2008
Confianza
Hurgando el viernes en el trabajo entre los enlaces a recursos que voy leyendo sobre todo esto del problema del DNS descubierto por Kaminsky (no pongo referencia, se ha hablado tanto que sobra) dediqué cinco minutos al sitio de web de Steve Friedl: unixwiz.net. Steve escribió un texto de gran claridad acerca del DNS y el famoso problema, que fue referenciado por el propio Kaminsky en su sitio. Es lo que llama un TechTip.
Bueno, pues hay otro de estos TechTip, escrito hace algunos años, bajo el enlace So you want to be a consultant... que está pero que muy bien. Son sus ideas acerca de cómo hacer las cosas bien cuando te dedicas profesionalmente a la consultoría informática, y me he sentido identificado con bastantes. Habla desde el punto de vista del profesional que trabaja por cuenta propia, no por cuenta ajena, pero la mayoría de los consejos son totalmente aplicables en cualquier caso.
Todos los consejos están orientados a conseguir que aquél que le contrata tenga lo que llama "The warm fuzzy feeling" (ni idea de cómo traducirlo en castellano sin que suene un poco ridículo o sea un chiste guarro) , es decir, una sensación de confianza plena no sólo en las capacidades técnicas de la persona que ha contratado, sino en la persona en sí misma, en que va a responder porque se va a dejar la piel para sacar adelante el proyecto que le hayan asignado. Y también para que uno esté a gusto con lo que hace.
Algunas frases son increíbles, y en general, los consejos son muy buenos. Uno de los que más me ha gustado es el de "Promotion&Advertising", que en realidad, se aplica a todo blogger... En esencia: que la mejor publicidad es la publicación de contenido original y técnico. Y que la habilidad de comunicar bien debe ser entrenada duramente, porque es difícil de alcanzar. Amén a eso. Es complicado y requiere mucho trabajo, es cierto, pero... en ello estamos :) . Las estadísticas de este blog están subiendo, lo que debe querer decir que vamos en el buen camino.
¡Muchas gracias a todos los que leéis Informático y "Segurata"!.
nota: hace años fue slashdoteado ;)
domingo, 7 de septiembre de 2008
HackStory
Por cultura general, esto es algo a lo que prestar atención: HackStory. Un wiki creado con la intención de recopilar todo lo posible sobre la historia del hacking.
Lo anuncia su autora, Mercè Molist, en su blog. Otros sitios se hacen eco, por ejemplo, Microsiervos o Yoire.
Ya había olvidado que quería referenciar directamente, en este blog, enlaces a sitios e información sobre el mundo del hacking. La categoría "Aprendiz de hax0r" también estaba para esto... para tener algo de información y aprender sobre los que realmente saben y son hackers de verdad.
Slds!
jueves, 4 de septiembre de 2008
Deep SQL Injection
Sólo un pequeño apunte, para dejar(me) un enlace a un paper de Ferruh Mavituna, sobre SQL Injection basado en tiempos, que fue lanzado mientras estaba aún en vacaciones...
Me encanta su trabajo, que sigo con atención desde el XSS Shell. Habrá que probar también BSQL Hacker, ¿no?.
Slds!
Actualización a los 5 minutos de poner este post: visto también en elladodelmal
miércoles, 3 de septiembre de 2008
¿Qué hace falta para ser un Tigre?
Mi amigo oben me pasa este enlace a "How to get a job with pen-testing team", una sátira, aguda y muy divertida, acerca de los tiger-team... ¡Buenísima!. Y ya que me he reído un rato, ¿cómo no compartirla con vosotros?.
Slds!
martes, 2 de septiembre de 2008
Nmap en BlackHat
Las últimas novedades de Nmap (versión 4.68 ahora mismo) fueron presentadas en las conferencias BlackHat. Daniel Miessler nos hace un pequeño resumen en su blog, y la ppt se puede descargar por ejemplo en insecure.org. Principalmente:
--reason: la razón por lo que te dice que un puerto está abierto o cerrado.
--top-port: escanear sólo los puertos más utilizados.
Hay que destacar además el nuevo motor para identificar el sistema operativo de la máquina escaneada, el lenguaje de scripting que incorporó en las últimas versiones, y además, la nueva interfaz gráfica, que puede generar un mapa de la red escaneada similar al que hace Cheops (nos indica dmiessler).
Nota final: en septiembre se espera el lanzamiento del libro "Nmap Network Scanning", que promete ser algo a tener en la estantería. Explicará no sólo las opciones de Nmap, sino como aplicarlas adecuadamente en la realización de tests de intrusión, realización de inventarios de red, detectar accesos wireless y proxies abiertos, etc.
lunes, 1 de septiembre de 2008
Captcha con más de una utilidad
Un captcha puede ser algo más que una medida de protección.
Mi amigo Francisco me escribió un comentario hace unos días, en la entrada en que hablaba de Ibercivis, mencionando otro proyecto interesante: reCAPTCHA, que merece entrada propia, creo yo. La idea de este proyecto también es hacer computación distribuida, con la diferencia de que no será el ordenador el que trabaje en el tiempo en que el usuario no le de caña, sino que sea el usuario el que trabaje directamente, pero sin que se note. ¿Cómo?. Pues usando el sistema de captchas para digitalizar libros escritos antes de que el uso de computadoras se hiciera popular.
Cada una de las imágenes mostradas como captcha en un sitio web (por ejemplo) es una palabra no reconocida adecuadamente por un sistema de reconocimiento óptico de caracteres. Si bien la digitalización de una palabra no es un gran esfuerzo, la combinación del pequeño esfuerzo de millones de personas es más que considerable.
Es un proyecto de la Universidad Carnegie-Mellon, realizado, además, utilizando únicamente software libre. Existen plugins y módulos para un buen número de lenguajes de programación y plataformas de creación de blogs y similares, como nos indican aquí.
En fin, que no hay excusa para no poner un buen captcha en una aplicación de web, cuando hay buenos sistemas para generarlos como el que estamos comentando. Al próximo que vea tan tuzo como para generar un colección de quince o veinte imágenes y que esas sean las únicas que usa su sitio web, permitiendo encima que se puedan descargar todas directamente del mismo sitio, le... le... [contenido violento censurado].
Escribían sobre este y otros proyectos de computación distribuida en Science Daily [gracias Francisco :) ]
Slds!
jueves, 14 de agosto de 2008
Monitorización DNS
Sobre la vulnerabilidad de envenenamiento de DNS caché (la de Kaminsky), se ha comentado mucho en qué consiste, cuánto ha sido explotada, etc. Pero se dice muy poco de un aspecto fundamental, acerca de las medidas a aplicar, que es cómo se monitoriza que el comportamiento de un DNS es el correcto, es decir, que no ha sido (o está siendo) atacado explotando este problema. Tampoco se está diciendo (ahora) nada sobre otro tema relacionado, que es cómo utilizar un servidor DNS para detectar malware y analizar su comportamiento.
Buscando información sobre el tema, encontré dos papers sobre cómo utilizar los datos de estadísticas y el propio tráfico del DNS para detectar redes de botnets, y en general, monitorizar el comportamiento del servicio. Son estos:
- Antoine Schonewille, Dirk-Jan van Helmond: "The Domain Name Service as an IDS" (este aparece también en Sergio Hernando)
- Bojan Zdrnja, Nevil Browlee and Duane Wessels: "DNS anomalies"
Son una lectura muy buena :) , y por unos días, lo único que voy a poner: ¡es tiempo para un merecido descanso veraniego!. En septiembre volveré con nuevos temas para este blog.
Slds!
miércoles, 13 de agosto de 2008
Video divulgativo
Los veía ayer a través de MundoBinario (a su vez, vía segu-info): sendas entrevistas en IDG a David Perry (Trend Micro) y Larry Bridwell (AVG). Realmente al segundo no lo referencia, pero sale en la misma noticia... a mí también me gustó, así que he decidido poner el segundo video ;)
Aquí va:
Aunque algunas cosas que dice pueden matizarse, me ha gustado porque creo que está muy bien que se divulguen, explicando sin lenguaje técnico, algunos cambios que se han producido en los dos últimos años, por ejemplo el más que significativo aumento de infecciones y ataques malware con sólo visitar una sitio web, o que se explique que la generación de malware es realmente una industria.
Slds!
P.D. ¡Echadle un vistazo al otro video también!
martes, 12 de agosto de 2008
Surf Jack
Leo hoy sobre un ataque con este nombre en el blog de EnableSecurity. Además, una de las charlas de DefCon de este año es sobre el mismo tema (aparentemente). Sitios que todos usamos, como Gmail, o aplicaciones de banca online, eran vulnerables, según nos indican.
El problema se puede resumir en que a pesar de usar HTTPS, no se activa el flag "secure" en las cookies... . Nos presentan un ensayo sobre el tema (¿por qué en español se insiste en decir "paper"?) y una herramienta que explota el problema.
Muy bueno :)
Recursos interesantes DNS de K.
Sólo poner dos sitios interesantes que hablan sobre el envenenamiento de caché DNS que tanto da que hablar:
(1) Unixwiz: an ilustrated guide to Kaminsky DNS vulnerability
(2) Blog de Evgeniy Polyakov, que nos presenta su propio trabajo sobre el tema, incluyendo un programa para hacer el envenenamiento en cuestión, cuando las actualizaciones correspondientes están aplicadas. Indica que cuesta unas 10 horas... buff. Algunos de los comentarios que aparecen son interesantes.
Slds!
lunes, 11 de agosto de 2008
OSSTM 3.0
Hace unos días veíamos en la lista de pentest, de Securityfocus, el anuncio del lanzamiento de OSSTMM 3.0, versión LITE. Es un pequeño avance de lo que será el OSSTM 3.0, cuando salga al público. Sin pagar, se entiende, los usuarios registrados han visto eso y más desde hace mucho.
Para el que no lo sepa, el OSSTM es una metodología de auditoría, que incluye entre otras cosas un listado super completo de pruebas a realizar, una definición de métricas (los llamados RAVs), o nos indica cómo presentar el informe que se genera como resultado.
Dicho formalmente (esto lo saco del mismo manual, apartado "Purpose"), la razón de ser de OSSTMM es proporcionar una metodología científica para la caracterización correcta de las medidas de seguridad de una organización, a través del examen y correlación de los resultados de una serie de pruebas que se demuestre sena consistentes y repetibles.
Como objetivo secundario, OSSTMM proporciona guías que permitan al auditor realizar una auditoría OSSTM, y existen para asegurar:
- que las pruebas fueron realizadas con la profundidad requerida
- que se incluyeron todas las fuentes de información necesarias
- que la auditoría realizada es conforme a la legislación vigente
- que los resultados pueden ser medidos
- que los resultados son consistentes, y si se repiten las pruebas, se obtendrán resultados similares
- que los resultados indican hechos derivados únicamente de las mismas pruebas realizadas
- ¿Cuándo va a salir la versión definitiva? Llevamos tanto tiempo escuchando sobre el advenimiento de la versión 3.0, que va a ser apropiado que "nazca" el 25 de diciembre...
- ¿De verdad habrá tanta diferencia con la versión 2, como para que sea necesario esperar tanto?
jueves, 7 de agosto de 2008
Más sobre la novedad del verano (el DNS...)
O sea, del problema en el DNS encontrado por Kaminsky. Ayer ya dió su charla en BlackHat, y están disponibles las transparencias en su web personal.
En el blog de F-Secure sale una foto de la sala en la que presentaba. Estaba hasta arriba, ¡cómo no!.
Además de hablar del problema en sí mismo, agradecer a mucha gente, etc, ahonda bastante en las consecuencias e implicaciones de la vulnerabilidad, como pueden ser la suplantación de sitios web financieros (bancos...), interceptación masiva de emails, ataques a los procesos de actualización de software, etc.
Recomendable ;)
lunes, 4 de agosto de 2008
Las auditorías de Nessus + Nmap
Acabo de leer un post en el blog de S21sec titulado “To exploit or not to exploit”, sobre una nueva certificación de InmunitySec. Me ha recordado otro tema del que llevaba tiempo queriendo decir algo, que es algo parecido a lo que se podría llamar “auditorías de Nessus y Nmap”.
Antaño se hacía mucho trabajo farsante (ahora también hay, mala hierba no muere, aunque creo que hay mucho menos), que consistía básicamente en lanzar una o dos herramientas (Nessus + Nmap, Retina, o la que fuera), esperar el tiempo que llevase la ejecución haciendo el vago, hacer un copy-paste de los resultados en el informe, y presentar eso tal cual, en inglés y todo. Y se llamaba a eso “auditoría” (en realidad eso correspondería a un análisis de vulnerabilidades mal hecho, claro, pero tampoco se hacía la distinción). Entonces, metodologías de auditoría como OSSTM estaban mucho menos desarrolladas, y en general, había menos conocimiento del que hay hoy día.
En trabajos más modernos, se añade un apartado para indicar las herramientas que se han utilizado, dando la sensación de que si hay muchas herramientas se ha trabajado mucho o que el equipo que ha hecho el trabajo sabe lo que se hace. ¿Será para que el cliente no crea que se le ha hecho una auditoría farsante?. ¿No está igual de mal utilizar sin ton ni son muchas herramientas, o decir que las has usado para que conste que has usado muchas?. En las ofertas de auditoría, también se añade un listado (largo) de herramientas...
Para mí, el número de herramientas utilizadas no dice absolutamente nada. Las herramientas a utilizar dependerán del alcance del trabajo. Además, usar tal o cual herramienta no garantiza que los resultados sean correctos, pues todas tienen sus falsos positivos.
Veamos un ejemplo: se desea realizar un análisis de vulnerabilidades en una red interna, direccionamiento clase A. Se da a un único técnico auditor una semana (5 días laborables) para hacer el trabajo, y 2 días más para hacer informe (¿a que es poco?). Nessus + Nmap nos da un total de 483 máquinas activas, con 4192 servicios accesibles, y 20091 positivos. Tenemos que distinguir el grano de la paja, así que, siguiendo los mandamientos, deberíamos lanzar más herramientas, a ver si coinciden en resultados con los que ya tenemos… (de hecho, si no recuerdo mal, el OSSTM dice que hay que usar varios escáneres de vulnerabilidades en paralelo, sí o sí). ¿Qué se hace luego? ¿Cotejarlos a mano? ¿Tenemos una manera automática y eficaz de comparar los resultados de Nessus, por ejemplo, con los de Retina?. Porque si no la tenemos, a ver cómo comparamos, en ese tiempo. En cualquier caso, podemos agregar los resultados de dos, tres, o cuatro escáneres a nuestro informe como anexos, pero sin un tratamiento de esa información servirán para hacer bulto, el cliente ni se los va a mirar. (Nota: El ejemplo es extremo, lo se. Se podría cambiar el enfoque, optando por trabajar sobre una muestra representativa de las máquinas y servicios a analizar, previo acuerdo con la organización auditada. Aunque a veces esto no es posible...).
En lugar de eso, será mucho mejor tratar la información obtenida con las pruebas automáticas hechas con nuestro Nessus+Nmap para obtener una valoración de los problemas encontrados y ver cuáles son más graves. Esta valoración deberá ser mejor y más elaborada que la que pueda dar la propia herramienta, y a ser posible, debe estar personalizada en función de la organización objetivo del análisis. También para clasificar los problemas encontrados en categorías, de forma que se sepa mejor a qué se enfrenta uno. Categorías mejor hechas que las que nos pueda presentar la herramienta utilizada. Habrá que ver si hay pruebas no realizadas por ese escaneo inicial que conviene hacer, ver qué falta... Después viene la parte de recopilar evidencias. No se puede señalar al cliente un problema sin una evidencia fuerte.
Para todo eso, a lo mejor no hace falta usar herramientas increíblemente sofisticadas, de las que hay que poner en ese apartado de “herramientas” en el informe. Es posible que los comandos básicos del sistema que uno utiliza, sean suficiente para verificar un problema determinado. ¿Se pone eso en el apartado de “herramientas”?. A lo mejor el personal de la organización auditada nos echa un cable, hemos sacado algo de información preguntando, por ingeniería social (o sea engañando), o la hemos encontrado en la papelera o en los recursos compartidos de alguien… la fuente del hallazgo ha de ponerse en el informe, claro. Pero seguro que de estas fuentes no se indica nada en el apartado “herramientas”.
Al final mejoraremos el informe de análisis de vulnerabilidades ampliando información sobre cada problema, por supuesto en el idioma del cliente. Nada de copy-paste o traducciones literales de fuentes por Internet, que se nota mucho… esta parte también lleva su trabajo. De la labor de consultoría que ha de acompañar al informe de vulnerabilidades, ni hablamos…
Así que después de todo, a lo mejor no hace falta mucho más que un único escáner de vulnerabilidades más complementos ocasionales para recopilar evidencias, para hacer un trabajo de análisis de vulnerabilidades competente. O a lo mejor sí. Hay muchas más cosas que hacer. Sin embargo, me da la sensación de que tanto clientes como compañeros de profesión (pre)juzgan la calidad del trabajo (y del profesional que lo ha realizado) no al leer el informe del mismo, conociendo así cómo se planificó el trabajo (bien o mal) y sus resultados, sino preguntando por las herramientas utilizadas.
Para mí, asumir una baja calidad en el trabajo realizado, antes de leer el informe, porque se haya utilizado sólo un número reducido de herramientas (o peor: porque sean software libre), denota que el que no tiene experiencia o no sabe es el que directamente hace la pregunta "¿Qué herramientas has utilizado?" y si le parecen pocas se permite decir “Uuuuuy”, pensando que tendrá delante una auditoría farsante. Es más, que todos menos él las hacen. Creo que eso es pasarse de listo. Esta es mi queja y el motivo de este post.
La labor principal es la búsqueda y documentación de vulnerabilidades, no es imprescindible entrar “hasta la cocina” o lanzar obligatoriamente muchas herramientas de análisis de vulnerabilidades. Con presentar evidencia suficiente ya vale, y cuanto más sencilla sea la manera de recopilarla, mucho mejor. Pero, eso sí, es un trabajo que requiere su tiempo...
¿Estoy diciendo una perogrullada? ¿O es bueno recordar esto?.
Slds!
P.D: Ante la cuestión planteada en el post que indico al principio de esta entrada en el blog, es decir, si un buen auditor necesita saber crear un exploit para una determinada vulnerabilidad y ejecutar así código en una máquina remota para realizar una buena auditoría, mi opinión es que no necesariamente. En el plazo previsto para hacer una auditoría puede que no de tiempo, para empezar (de hecho, seguro que no da). Y es probable que con herramientas sencillas más una pequeña colección de exploits (metasploit, por ejemplo) sea suficiente para recopilar la información que complete la obtenida con el escáner de vulnerabilidades, durante la realización de una auditoría.
jueves, 31 de julio de 2008
Pwnie Awards - nominados
Después de mencionar anteriormente los premios Pwnie Awards de las Blackhat, ¡pues no me voy a quedar sin postear también los que me llaman la atención!.
La categoría mass0wnage es la que tiene más candidatos interesantes, incluyendo las múltiples vulnerabilidades encontradas en Wordpress (que este año ha sido particularmente machacado), y el problemilla con los números aleatorios en Debian, entre otros (échale un vistazo). La de lamest vendor también tiene su aquél, con McAfee "Hacker Safe", que daba por seguros sitios con problemas, incluido el suyo propio, y algunos pensamientos de L.Torvalds. Entre los bugs que han hecho correr ríos de tinta (es un decir) está obviamente el problemilla con el DNS descubierto por Kaminsky, y a mi parecer es el seguro ganador.
Otra categoría que me ha llamado la atención es la del premio... ¡al fracaso épico!. ¿Por qué?. Porque entre los candidatos está Windows Vista, "por probar que la seguridad no vende". Hace unos días, tres de mis amigos [Eva, Sergio y Dani, ¡cómo os quiero! ;) ] se encargaron de que eso me quedara bien clarito... y de que me sintiera increíblemente frustado, precisamente con los mismos argumentos:
all customers care about is the annoyance of the UAC prompts, the confusing user interface and the insane hardware requirements¿cómo dar en cinco minutos la educación en seguridad informática necesaria para que este aspecto sea valorado? Arrrg. Es una verdadera pena.
Y la respuesta a mi pregunta de la vez anterior: ¿cuál es la mejor canción? NO es el Javascrippy... ¡Aquí va un avance de lo que se presenta!
Slds!!
miércoles, 30 de julio de 2008
Evilgrade - actualizaciones falsas
A cuento del asunto del DNS que estamos viendo este verano, y por el cual se han escrito líneas y líneas en páginas web, correos electrónicos, etc (voy leyendo muchas), hay que decir algo de una nueva herramienta: ISR-evilgrade.
Es una herramienta que utiliza envenenamiento de la caché DNS (cuya última novedad es el ataque de Kaminsky, como ya sabéis), entre otras técnicas, con un objetivo: suplantar al servidor que proporciona las actualizaciones automáticas de un producto o sistema. De esta manera, se puede proporcionar la ilusión de que un sistema está completamente actualizado, y sin embargo seguir siendo vulnerable.
Está desarrollada en Perl, y su autor es Francisco Amato, de Infobyte.
También visto en (amplían información):
blog de metasploit
securityfocus
kriptópolis
Suscribirse a:
Entradas (Atom)