Hoy, veo que ha salido la última versión de Mandigo (la 1.35), la pruebo y funciona tanto en Firefox como en Explorer. ¡Al fin!

¡Vuelvo a ser casi feliz!

Para quien no esté familiarizado, describo a continuación la técnica, bien explicada y masivamente difundida (demasiado, a buen seguro) por Chema Alonso:

Generalidades

Los ataques de inyección SQL se realiza mediante el envío de una sentencia SQL hacia un parámetro o campo de formulario que va a ser leído por una aplicación web para su procesamiento. En otras palabras, los atacantes intentarán completar una instrucción SQL especialmente “maligna” cuando ofrezcamos en una página web un formulario o un parámetro dentro del encabezado (del tipo, por ejemplo, http://midominio.com/listado.asp?id=23).

Esto es empleado, generalmente y menos mal, para cambiar datos en las bases de datos que almacenan la información que se presenta en la web. Y digo “menos mal” porque también podría ser utilizado para borrar una tabla, conseguir un usuario de la base de datos, etc.

Usualmente el fin consiste en cambiar de cara (defacement) de la web para colocar otro texto o imágenes identificando al hacker o con un mensaje alusivo. Estos delincuentes “menores” (ha habido ataques hace muy poco de este tipo que han limpiado webs tan concurridas como la Jazztel, Izquierda Unida y otras; han sido pillados -lee la crónica de Chema Al talego o a por talegos-) parece que pretenden ser los primeros en el top de Zone-h o cosas por estilo, no les da para mucho más. El problema es que los que están detrás sufrimos y mucho.

Técnica

La técnica no es muy complicada y suele ser parecida a la siguiente:

1. Lo primero es buscar una víctima, pero para eso qué mejor que Google, para eso está. Introducimos una cadena que pueda representar una vulnerabilidad (por ejemplo una búsquda del tipo “inurl:listado.asp?id” y a ver que nos dice el buscador (para comprender mejor esto recomiendo el libro “Hacking Google” de Johnny Long
2. Una vez localizada una posible víctima, se suele probar a ver si es vulnerable. Las pruebas suelen hacerse intentando romper una cadena y ver lo que canta.

La técnica se basa en romper la sentencia SQL que haya programado el desarrollador y anexar otra sentencia maliciosa.
Imaginemos que presentamos un formulario para buscar un nombre que presenta un campo llamado “apellido”. El valor introducido por el usuario lo tratamos por una página que tendrá una sentencia del tipo "SELECT * FROM usuario WHERE usr_apellido='" & apellido & "' ".
Si un hacker nos introduce “algo de SQL” en el campo “apellido” puede hacer romper la sentencia SQL y realizar otras acciones. En este ejemplo, se podría introducir algo similar a:
Apellido: kk' or 1=1 --
Con esto la sentencia quedaría:
"SELECT * FROM usuario WHERE usr_apellido='kk' or 1=1 -- ' "
Observad que esa condición (con el “or 1=1″) se cumple siempre y, por tanto, devolverá algún registro (seguramente el primero aunque no exista el apellido “kk”, ideal para romper formularios de validación). El doble guión medio es usado para que el resto de la sentencia se entienda como comentario (según MS SQL Server, en otros SQL es parecido) y no produzca errores.

3. Siguiendo así, seguramente probarán distintos valores para conocer nombres de campo, tablas, usuarios, etc. En esto les ayuda nuestro generoso sistema que le va diciendo dónde está el error, con su nombre de campo, tabla, etc. En el ejemplo del ataque sufrimos la semana pasada, el hacker incluso hizo:
   www.miweb.com/listado.asp?id=Convert(int,(select+user));--
   en la URL y nuestro sistema, amable de verdad, le contestó:
   Error de sintaxis al convertir el valor nvarchar 'usuario_de_la_bd' para una columna de tipo de datos int.
4. Siguiendo así, al final realizará una sentencia:
   UPDATE tabla SET campo='Hacked by SuperHackilistico'
   y todos los valores tendrán esa cadena, que a buen seguro se lucirá flamante en la página de inicio de nuestra web.

El problema

El problema está en el desarrollo, no en el sistema que alberga la web ni en el de base de datos. Hace tiempo la gente ni se planteaba hacer cosas así, por lo que se programaba sin seguridad de ese tipo, pero hoy en día es muy frecuente este tipo de ataques.

En concreto, el día 28 del mes pasado, recibía un mensaje de Jorge Chinea del INTECO-CERT advirtiendo lo siguiente:

Estimados colaboradores,

En los últimos días se han detectado ataques masivos contra sitios web con el objetivo de manipular su funcionalidad y contenido. Una vez comprometidas, las paginas Web manipuladas redirigirán a sus visitantes a sitios web maliciosos expresamente diseñados para descargar e instalar todo tipo de códigos maliciosos en el ordenador que podrán permitir al atacante su control.

Desde INTECO-CERT se alertó en anteriores ocasiones la existencia de este tipo de ataques para comprometer los sitios web. Se trata de ataques de tipo inyección SQL, aprovechando una vulnerabilidad en el Internet Information Server (IIS), provocada por una errónea programación del código ASP (Active Server Pages).

Estos ataques masivos están apoyados en herramientas automáticas con las que logran infectar gran número de sitios web en poco tiempo. El número total de páginas comprometidas a día de hoy ronda los 1’5 millones, aunque muchas de ellas ya han sido o están siendo corregidas.

Recomendamos a todos los webmasters que tengan sus páginas ASP alojadas en servidores IIS comprobar, lo antes posible, si sus páginas web han podido verse afectadas. Un síntoma claro de la infección puede ser la existencia de código javascript externo desconocido y que apunte a alguno de los dominios indicados en el siguiente listado (y que iremos actualizando):

-Listado de dominios maliciosos-

De cara a los usuarios finales, para evitar infecciones, aconsejamos seguir las recomendaciones básicas que siempre se deben adoptar ante incidentes de seguridad:

* Utilizar software de seguridad como antivirus, cortafuegos, antiespias, etc.
* Tener actualizadas todas las aplicaciones de nuestro sistema, sobre todo sistema operativo y navegador, con los últimos parches de seguridad.
* Utilizar por defecto cuentas limitadas de usuario -no de administrador- con lo que limitaremos en gran medida los efectos de una posible infección.

Usuarios con conocimientos técnicos más avanzados pueden optar por deshabilitar el javascript en el navegador de manera temporal o instalar alguna extensión, como NoScript, que permita tener un control más exhaustivo sobre la ejecución de secuencias de comandos.

Es evidente que los desarrolladores deben prestar más atención en el código y poner filtros que anulen algunos caracteres y sentencias peligrosas.

En nuestro caso, ahora lo hacemos de forma usual, pero es cierto que siempre quedan desarrollos antiguos no actualizados que pueden ser vulnerables.

Contramedidas

Ya que conocemos el problema, solo nos falta ponerle solución. Esta se encuentra “simplemente” en filtrar lo que nos venga a páginas que admiten parámetros (ya sea por GET o por POST). Y digo “simplemente” porque hay que completar código y eso a veces da más que pereza.

El mismo Jorge Chinea planteaba la cuestión de la forma siguiente:

Con respecto a los ataques masivos contra sitios Web de los últimos días hemos estado viendo diferentes soluciones:

1.- La solución definitiva, que sería revisar todas las paginas asp verificando la entrada de datos para que no permitan inyecciones de SQL.
2.- El parche para las inyecciones que modifican datos: Usar un usuario para las consultas genéricas de la base de datos con permisos de solo lectura en las tablas y otro para la administración de la web, añadir/modificar contenidos… Con esto ya no se podrían modificar datos en la web

Pero me parece mucho más elegante otra solución que se planteó en el mismo foro (denominado RESCATA -Red Nacional de Sensores Antivirus- en la que colaboro) ofrecida por Juan Cascón de Vocento-ABC y que incluyo a continuación:

Function ControlSQLInjection(texto)
  ' Autor: Juan Cascón:  xxx@abc.es
  on error resume next
    Dim res
    res = LCase(texto)
    res = Replace(res, "[", "[[" & Chr(0))
    res = Replace(res, "]", "[]]")
    res = Replace(res, "< ", "")
    res = Replace(res, ">", "")
    res = Replace(res, "script", "")
    res = Replace(res,"select","")
    res = Replace(res,"table","")
    res = Replace(res,"create","")
    res = Replace(res,"insert","")
    res = Replace(res,"update","")
    res = Replace(res,"delete","")
    res = Replace(res,"drop","")
    res = Replace(res,"exec","")
    res = Replace(res,"declare","")
    res = Replace(res,"alter","")
    res = Replace(res,"union","")
    res = Replace(res,"null","")
    res = Replace(res,"schema","")
    res = Replace(res,"execute","")
    res = Replace(res,"-","")
    res = Replace(res,";","")
    res = Replace(res,"""","")
    res = Replace(res, "[[" & Chr(0), "[[]")
    res = Replace(res, "'", "''")
    res = Replace(res, "%", "[%]")
    res = Replace(res, "_", "[_]")
    res = Replace(res, "#", "[#]")
    res = Replace(res, CHR(13), "")
    res = Replace(res, CHR(10), "")
    res = Replace(res, CHR(0), "")
    res = Replace(res, "=", "")
    res = Replace(res, "&", "")
    res = Replace(res, "$", "")
    res = Replace(res, "@", "")
    res = Replace(res, "(", "")
    res = Replace(res, ")", "")
    res = Replace(res, "\", "")
    res = Replace(res, ",", "")
    res = Replace(res, "\'", "")
    res = Replace(res, "+", "")
    ControlSQLInjection = res
End function

Invocando a esta función en cada recepción de datos de un formulario o enlace, podemos considerar que estamos protegidos frente a este tipo de amenazas.

Así que el otro día me puse y encontré uno que no está mal. Se llama Downloads Manager y permite lo que pretendía: establecer categorías, hacerlos públicos y privados y gestionar las descargas. Lo podéis encontrar en la página de Giulio Ganci.

Lo puse en marcha y, ya puestos, lo traduje. Y como no podía ser de otro modo, aquí dejo los archivos de traducción (mo y po).

Downloads Manager (fichero .mo)
Downloads Manager (fichero .po)

Gracias a Giulio Ganci, autor del plugin.

La razón de inscribirme es que tenía curiosidad en conocer el producto (MicroStrategy) mas que el propio concepto (“Introducción al Business Intelligence”). Y la verdad es que en ese sentido no ha estado mal el día.

Lo que no me acaba de convencer es esa tendencia actual (desarrollada y promovida por corrientes de lo que yo denomino MarkeTIC) de poner nombres grandilocuentes (por supuesto, anglosajones) a cosas que en informática y comunicaciones conocemos desde hace ya mucho tiempo con nombres más simples o incluso sin necesidad de ellos. Me refiero a que yo hace ya más de diez años ya hacía lo que denominamos ahora Business Intelligence (vaya nombrecito, por cierto) solo que le llamábamos informes basados en consultas (vale, a veces decíamos query) accesibles mediante herramientas externas contra objetos de datos (aquí si empleábamos la terminología OLAP). También creábamos tablas temporales o almacenes de datos vinculados (no les llamábamos Datawarehouse, claro) y, en el fondo, intentábamos el acceso, explotación y sacar conclusiones de los datos de forma no evidente (o sea, Data Mining)

Pero claro, así no vendíamos. Al fin y al cabo lo que hacíamos era informes sobre consultas (algunas de las cuales podía medirse en metros o más) y eso no era “inteligente”, por lo visto. Se ve que mi condición de viejo cascarrabias aflora a la menor oportunidad.

En cualquier caso he de reconocer que el tema ha avanzado sobremanera, sobre todo en comodidad y flexibilidad. En la presentación de hoy (más flojita, en mi opinión, la de la mañana sobre el aspecto usuario y mejor la de la tarde en desarrollo y administración) he visto claramente esa evolución, permitiendo que con dos clics tengamos esos informes que tanto gustan a nuestros gerentes y financieros. Y todo en Flash, claro…

Pues sí, buen producto. Por poner objeciones, que evidentemente las hay, nombraré la dificultad práctica que tiene para muchos el enlazar el propio MicroStrategy con los datos que a buen seguro procederán de un ERP o similar que los propios informáticos desconocerán en su estructura. Y es que veo que una vez identificados los objetos de negocio (basados en, como no, el propio modelo de negocio a analizar) la cosa está bastante tirada, pero la dificultad de ese paso previo a veces resultará insalvable. Claro que de eso viven muchos, cosa no fácil en estos tiempos.

Bueno, pues gracias a Belén Ortega de A Smart Data, como organizadora, y a Jordi Pujol, preventa de MicroStrategy, como interesante ponente.

Tras su primera instalación, allá por el año 2005, me costó personalizar como yo quería este sitio. Creo que lo que más me ayudó fue elegir un tema que conocí gracias a, como no, Calocén: el tema Mandigo. Bajo mi punto de vista, Mandigo es elegante, claro, cómodo y flexible, por lo que me enamoré de él y le he sido fiel hasta hoy.

Cada vez que sale una nueva actualización, tanto de WordPress como de Mandigo, suelo realizarla con cierta celeridad. Ya sabemos que muchas corrigen problemas de seguridad y, a veces, agregan funcionalidades interesantes. Esto fue lo realizado hace mes y medio con la actualización a WordPress 2.5 y algunas menores del tema que utilizo.

La semana pasada, mi menú de administración de este sitio mostró que había una nueva actualización de Mandigo (yo tenía la 1.32 y se me anunciaba la 1.33.1, había pasado por alto la 1.33 que había salido un día antes). Como tantas veces, reemplacé los ficheros mediante FTP y listo.

Como suelo utilizar Firefox, la cosa no presentó problemas. Ya estoy acostumbrado a que la apariencia visual del blog es mejor con Firefox que con IE, por lo que no me fijé en nada.

Ya en el puente (quien lo hubiera tenido) del primero de mayo, observé que desde el portátil, en mi casa, me sucedía algo extraño: cuando abría www.emperador.org, tras un poco de pereza, me daba un cuelgue impresionante de Internet Explorer, que se intentaba reiniciar, para repetir lo mismo. Lo achaqué a Windows Vista, que no habría asimilado bien mis cambios. Pero recibí alguna información de que esto también les sucedía a otras personas y me empecé a preocupar. Más aún cuando lo comprobé en el PC de casa y en el propio del trabajo, cuando lo abría con IE.

Lo primero que pensé fue en una noticia leída hacía poco sobre infección a través de un javascript. La noticia original no la recuerdo, pero luego la ví en Cientos de miles de páginas web infectadas de Panda y en su blog la noticia IFRAMES Attack!!!.

Lo cierto es que esto me puso las pilas y me dediqué a buscar, primero en los comentarios hechos y luego en los propios posts; nada. Como no encontré nada, busqué mediante consultas en todas las tablas de WordPress y tampoco. El siguiente paso, en los propios ficheros del software, tanto los que tenía colgados en la web, como los originales y descargas.

Me empecé a mosquear porque no lo encontré. Miré también si desactivando pluggins y demás elementos auxiliares de la bitácora la cosa marchaba, pero nada de nada. Entonces se me ocurrió (esto fue ayer) volver a la versión 1.32 de Mandigo, ya que también (se me olvidaba) había actualizado WordPress a la 2.5.1 y me había seguido fallando. Con esa versión del tema ya no petaba.

Misterios. La verdad es que sigo igual: si actualizo Mandigo de la 1.32 a cualquiera de las posteriores, Internet Explorer peta, pero del todo. Con la 1.32 no. He revisado casi todo el código del tema y no encuentro nada. Al final he decidido mandar un mensaje al autor, para ver si a alguien más le pasa.

Por cierto que mi antivirus me detectó lo que parecía ese virus el pasado 12 de marzo. Al final no se si tiene algo que ver o no.

Si a alguien le suena, recibiré encantado sus comentarios.

La cosa ha sido así: quería actualizar WordPress a la versión 2.5, tanto por seguridad y funcionalidades como por los problemas que tenía con la anterior versión (no conseguía ni de coña ponerla en castellano, además de otras cosas menores). Ya puestos, decidí, tal y como en su día lo hicieron los amigos de Camyna, hacer del blog mi sitio completo. Al fin y al cabo, únicamente no tenía incluidos mi presentación, las páginas estáticas de genealogía, el programa PHPGedView (de visualización de datos genealógicos) y poco más.

He pensado que todo (menos el mencionado PHPGedView) lo podía integrar en el blog mediante páginas estáticas y así realizaba una instalación desde cero de WordPress, que buena falta hacía.

Así que me he puesto manos a la obra y, con algunos problemas que luego comento, ya está casi todo hecho.

Los problemas fundamentales han sido en la codificación de caracteres de los post y comentarios. Parece ser que por mucho que he intentado, los símbolos de puntuación y caracteres regionales se han convertido en un galimatías. Ya sé que debería haber utilizado desde el principio los códigos HTML &…; pero todos sabemos que, como funciona bien sin ellos en gran parte de los casos, pues pasamos.

Por ello me he retrasado ya que he tenido que revisar los contenidos y modificarlos. Todavía no he terminado, pero ya se andará. De la misma forma, aún tengo que revisar las partes estáticas y el dichoso programa de genealogía que ahora no funciona.

En fin, que vivo y que tengo algunos apuntes que hacer y otros comentarios que contestar, así que poco a poco resucito.

Gracias por estar ahí.

Antonio

PD: Nuevos datos:
- dirección www.emperador.org
- RSS: www.emperador.org/index.php/feed/

Yo recuerdo mis primeros programas en BASIC (uno de ellos, un tablón, permití­a resolución de ecuaciones mediante triangulación de matrices; ¡vaya gustos!; creo que aún guardo algún listado). Aprendí­ algo aunque de lo que era máquina y sistemas, bien poco. Casi todo juegos y primeros pinitos en programación.

Luego los tiempos se hicieron más complejos.

Pues bien, ahora encuentro gracias al boletí­n de Informática 64 (o sea, Chema Alonso) un emulador de C64, en forma de pluging de Java, que es perfecto y que incluye incluso aquellos juegos que tanto nos engancharon y que me siguen pareciendo magistrales.

Si, como yo, fuiste de esos, entra en la página de Commodoregaming y disfruta. Si no lo fuiste, tú te lo perdiste.

No, me quiero referir a la costumbre en este país nuestro de que cuando algo trágico sucede, lo solucionamos con la creación de una comisión de investigación. Siempre tienen como misión esclarecer esos sucesos y nunca consiguen mas que confusión y demoras en decisiones que podrían ser vitales.

Tenemos muchos ejemplos políticos:

• Comisión de investigación del 11M
• Comisión de malos tratos a mujeres
• Reclamación de comisión de los apagones de Cataluña
• Del Yakovlev
• ¿Os acordéis del síndrome tóxico (colza)?

En fin, un sinfín.

Pero bueno, ¿a qué viene esto? Bueno, pues tiene su sentido, ya veréis. Es que a raíz de lo acaecido en nuestros sistemas hace un par de semanas (que podéis leer en que esto no es vida) se ha creado en mi empresa uno de ellos, denominado Comité Gestión CPI con el fin de “definir arquitectura, servicios, soluciones y calidad”. Y claro uno, sin ser malpensado, interpreta que esto es un Comité de Control de los Técnicos, claro está.

Es cierto que merecemos control, como todos, pero me gusta que las cosas sean más directas y efectivas.

Pero somos positivos y pensamos que éste sí dará mayores frutos que los políticos. Al fin y al cabo estamos en la empresa donde la eficacia está garantizada.

País…

Llevamos dos semanas en un sinvivir. Y todo por nuestra culpa: se nos ocurre montar los servicios de correo (unas 50.000 cuentas) en un cluster para tener “máxima disponibilidad”, “mayor eficacia” y, en fin, todo para bien. Lo hacemos conscientes de que a los usuarios debe ser transparente y solo mejorar. Pues la cagamos, bueno, no nosotros, los sistemas, pero es que estamos detrás, que le vamos a hacer.

El sistema pensado era chulo, de esos que te enorgullecen ya que no conoces a nadie que los tenga para montarlo y encima aúna todo para que funcione fenomenal. Ponemos tres pedazo-de-equipos accediendo a una cabina de discos en forma activo-activo, es decir, los tres acceden al mismo filesystem en lectura-escritura y unos balanceadores de carga previos reparten las tareas para que no se cansen. Todo demasaiao…

Pues eso, que todo funciona bien desde que empezamos la migración (hace más de tres meses) hasta finales de agosto. Todo se había trasferido, solo faltaban un par de cosillas que tocar para que se accediera al sistema configurado de forma balanceada. Lo hacemos el 27 de agosto y parece que, si bien presenta más carga de la esperada para esas fechas, funciona.

Pero es que faltaba septiembre con los usuarios ansiosos de leer todo su correo acumulado. El lunes 3 empieza a fallar, no está claro en qué pero seguro que no va bien. Vemos que hay una sobrecarga en los servidores que los hace casi inoperativos pero los servicios están correctos. A final de día observamos que el acceso a la cabina no es fluido y que al demorarse el acceso a los ficheros, los servicios se acumulan y la sobrecarga está servida.

A partir de allí empieza el sinvivir comentado y el cúmulo de desgracias de dos semanas. Montamos equipos nuevos para descargar de tareas (y ficheros accedidos) al cluster. Parece que mejora pero de vez en cuando todavía se cae lo que queda en los equipos del cluster. Trasferimos más dominios y cuentas a los dos nuevos montados: mejora pero, como las desgracias no van solas, uno de los servidores nuevos cae sin más explicaciones…

A todo esto, los usuarios, con toda razón, están que trinan. Y es que un día o dos con problemas de correo se llevan, pero casi diez, es imposible. A veces creo que los usuarios tenemos más paciencia que Job…

Dejamos la semana pasada con un sistema semiestable. El lunes comienzan los problemas que arrastramos hasta hoy. Hoy el acceso a la cabina de discos se ha hecho imposible aun sin servicios activos. Solo a las 18 horas hemos conseguido el acceso para recuperar lo que queda. Mientras tanto hemos montado dos nuevos servidores y puesto operativo el correo, aun perdiendo momentáneamente lo archivado (eso lo hacemos mañana). Ahora estamos copiando una buena cantidad de GB.

Así que esta es la vida. Ha habido días de dormir 3 o 4 horas y encima sin tener la certeza de que todo funcione bien…

Bueno, en el axioma de que ningún mal viene solo, se me rompe un disco duro de mi equipo (solo 200 GB de información, la mayoría inutil, claro) y a mi compañera Isabel el portátil. A recuperar y empezar…

No es mi mejor momento, en otra oportunidad estaré más en forma…

Antonio

PS: No se os ocurra montar un sistema de cluster en Linux contra cabina IBM DS4300 con sistema OCFS. Aunque tampoco tengo claro que todo eso sea lo que ha fallado. En fin…

Gracias a Javier que me ha metido de beta-tester en el nuevo servidor Apache que estamos instalando las cosas ya funcionan, aunque claro, otras han dejado de funcionar.

He aprovechado para incluir el último archivo GEDCOM en el que venía trabajando. Y es que tras haber completado buena parte de mi genealogía, decidí agregar ramas laterales con todos los datos que tenía a mi disposición. El asunto es inacabable pero al final conseguiré tener mucha más gente metida.

La forma de hacerlo es encontrar la primera persona portadora de un apellido y tirar hacia la actualidad por todas las ramas posibles. De momento solo lo he hecho con 2: Satué y Chicapar pero ya tengo preparados para meter los Sau y Santos.

En fin, el número de ancestros se ha ampliado aunque la cantidad de ramas incluidas en la web se ha reducido. Pero tiempo al tiempo…

Por último, sé que mucha gente utilizaba la zona de mi web de búsquedas de apellidos en Luceni. Esta zona ahora no funciona por lo comentado y he de reprogramarla. Como no es mucha cosa supongo que no tardaré.