AV-Comparatives - Resultados de abril

En teoría, este post tendría que haber salido el 16 del mes pasado. No se muy bien por qué, pero aquí me lo he encontrado en borradores. Aiinss... Si ya me parecía raro que saliera en ese estado desde el Android.

************

Revisando los tweets he visto que AV-Comparatives ha publicado un informe mensual de "pruebas dinámicas" (dynamic-tests tal y como lo describen ellos mismos). Si os digo la verdad, la primera vez que entré en este sitio creo recordar que sólo mostraban 2 informes semestrales sobre los antivirus que probaban. Y, las pocas veces que he vuelto a entrar (contadas con los dedos de una mano) me he ido encontrando con más cosas.

Por ejemplo, si hacemos click sobre el gráfico que aparece en el centro de la página que he enlazado, se accede a un gráfico interactivo en el que se pueden seleccionar los rangos de fechas en los que... ¿han hecho las pruebas? No lo tengo del todo claro. Pero esa es la impresión que me han dado.

También se puede acceder a los informes en .pdf que enlazan justo un poco más abajo del enlace al gráfico interactivo.

No se. He visto este tweet y me ha dado por escribir sobre esto. Ya se que no es nada del otro mundo, pero, si alguno de vosotros no conocía este sitio, pues algo ya habré conseguido. ¿No?

Facebook a bolsa

Jo tengo mucha información al respecto, pero, según he podido leer:

Demandan a los bancos que apoyaron la salida a bolsa de Facebook, ¿cuál es vuestro veredicto? http://t.co/KNowAk6a -- GlobbTV (@GlobbTV)

Sin haber visto el enlace, yo pregunto: Si alguien pone sus ahorros en acciones de telefónica y ésta cae, ¿De quién es la responsabilidad? Tengo entendido quite Facebook subió un montón los primeros días (mejor, los primeros 30 segundos) y que ahora está cayendo en picado. Y eso que son 4 líneas mal contadas que he leído sobre el tema.

Para mí es responsabilidad del que ha decidido ponerlas. Las acciones no son unos productos desconocidos. Todo el mundo sabe que se puede ganar o perder. No como esos productos que no entiende ni el comercial del banco, de los cuales ser han dado muchos casos de noticia.

Y vosotros, ¿Qué opináis?

Nmap 6

Pequeña reseña: he podido leer en la lista de distribución de la Rooted que han liberado la versión 6 de esta popular herramienta de escaneo de puertos.

Lo he leído hace escasos 10 minutos mientras desayunaba. Y Espoo que ahora mismo estoy en la parada del autobús.

Bueno. Habrá que montar las VMs para probarla. Que, por cierto, por su las moscas: cómo la uséis es vuestra responsabilidad.

Para su descarga.

Inyección SQL persistente

Aunque hace apenas unos días me llegó el libro de SQL Injection de Informática64, apenas lo he podido empezar. Es posible que esto que empecé a escribir hace 3 semanas más o menos esté reflejado ahí dentro, pero, de ser así, no he llegado a ese punto.

****

Desde hace muchos, muchos años, se conoce la problemática del manejo de datos en las aplicaciones cuando se trata de bases de datos. Todos, espero, sabemos que si no controlamos la entrada de esos datos, puede tener consecuencias insospechadas.

Por ejemplo, si queremos utilizar un campo en nuestra aplicación para buscar... digamos, descripciones de casas, podríamos tener algo así

SELECT * FROM CASAS WHERE desc=$miEntradaDeBusquedaDeCasas;

Si no controlásemos esa búsqueda, y nos pusieran algún carácter inesperado, nos podríamos encontrar con esto

$miEntradaDeBusquedaDeCasas=$_POST['textDescCasas'];

Donde

$_POST['textDescCasas'] es %piscina';--

con el siguiente resultado

SELECT * FROM CASAS WHERE desc='%piscina';-- ';

También conocemos los distintos tipos de XSS: los persistentes y los no persistentes.

Si nos quedamos con los persistentes, sabremos que estos se ejecutarán a perpetuidad. Vamos, hasta que se elimine ese registro de la base de datos.

Ahora, lanzo la pregunta: ¿Qué sucedería si controlases las inyecciones sólo a la hora de recoger los datos del teclado y recibirlos, pero se guardasen en la base de datos? Lo que podría pasar es que si no se controlan esos datos, y los usas en otras consultas, los resultados no serían los esperados. Se podría hacer que la aplicación rompa cada vez que se acceda a ese registro.

Un ejemplo podría ser algo parecido a lo que voy a mostrar a continuación.

$miEntradaDeBusquedaDeCasas = "IT'S A DESCRIPTION";
INSERT INTO CASAS (DESC) VALUES(?);
bind(1,miEntradaDeBusquedaDeCasas);//sí, me lo he inventado un poco, pero para el caso de ejemplo...
$descripciones = getRows("SELECT desc FROM CASAS");
foreach($descripciones as$ descripcion){
   SELECT * FROM CASAS2 WHERE desc='.$descripcion['DESC'].';
}

La última consulta se acabaría obteniendo:

SELECT * FROM CASAS2 WHERE desc='IT'S A DESCRIPTION';

Para el que le cueste verlo:

SELECT * FROM CASAS2 WHERE desc='IT'S A DESCRIPTION';

Por lo tanto, al ejecutar esa consulta, el motor de bases de dato no sería capaz de tratarlo. Esa cadena "S A DESCRIPTION'" sobraría. Lo peor de todo es que se encuentra insertada en una tabla. Cada vez que se encuentre ese registro y lo usemos de esta manera, nos saltará el error.

Algo parecido a esto es lo que me he encontrado recientemente en un programa. Y ha sido muy, muy curioso. Además, me he echado unas buenas risas. No creo que este concepto sea nuevo, pero, como digo, sí muy curioso, al menos para mí. Lo que nos enseña que también tenemos que tener cuidado con lo que tenemos guardado, y no sólo con lo que nos acaban de introducir por teclado.

Diccionario informático I

De todos es sabido que muchas veces los informáticos utilizamos palabras, frases, verbos que en un contexto normal no cuadran, o, incluso, no existen. Es posible que alguno de vosotros seáis de los que no estáis en el mundillo, por lo que voy a crear está sección para vosotros. Como sé que me voy a dejar definiciones en el tintero, voy a hacerlo por entregas (indefinidas). Aquí tenéis las primeras definiciones:

Bicho: A veces también expresado como bichito. Por no enumerar los distintos tipos que hay, generalizaremos como malware.

Bug: ¿Insecto?. ¿Bicho? No. Un bug, /bag/, es un error en el software. Por si las moscas: incluir aquí el sistema operativo.

Debug: No. No es solucionar los bugs. Significa ejecutar un programa, viendo las líneas de código fuente por donde va pasando. La ejecución del programa es mucho más lenta porque somos nosotros quienes decidimos cuándo pasar a la siguiente línea.

Ir a pedales: Ir más lento que el caballo del malo. "Este equipo/programa va a pedales". Es como decir "este p**o coche va pisando huevos".

Parchear: Poner un parche a un programa. Como tal, es posible provoque otro bug, para el cual hará falta hacer otro parche o modificar el ya existente y, éste, a su vez, como tal...

Parche: Parte de código que se supone que va a solucionar un bug. Cuando se habla de parche, suele ser un fichero ejecutable que se lanza para que modifique el software ya instalado y así solucionar el bug encontrado. No es muy común hablar de parche cuando se soluciona el problema directamente sobre el código fuente de dicho software.

Petar: En España... romper, estropear, cargarse,etc, et. Sólo cabría decir "he petado el equipo".

Pantallazo: a)Screenshot. Hacer una copia en imagen de lo que esta mostrando la pantalla. Después... harás con ella lo que más gustes. Lo normal será pegar esa imagen en algún sitio ¿por qué si no ibas a presionar la tecla impr pa o print screen o cualquier forma similar que te ponga el teclado? b) ...azul. Famosa pantalla de Windows en la que este ha dado un casque tan gordo que no te queda otra que reiniciar. También conocido como Blue Screen Of Death.

Troyanizar: Verbo que hace referencia a inocular un troyano en un equipo.

Troyano: De la familia de los bichos.

Troubleshoot: Aunque no es común que lo utilicemos en español, significa disparar a bocarrajo a los problemas. Pero, como digo, en español no se utiliza. Es inglés, bastante.

De momento dejo estos. De hecho, he puesto más de los que se me habían ocurrido en un primer momento. No voy a negar que algunos eran muy básicos, pero se me habían ocurrido las... ¿gracias? (harán mucha, poca o ninguna, pero me he reído cuando las escribía).

Si se me ocurren más que no hagan falta hacer escenarios, haré otra entrega.

Borrado en discos II

Tal y como conté en la anterior entrega, este post lo monté cuando estaba en el FTSAI (allá por finales de 2009 hasta mediados de 2010).. Por desgracia, no he visto el momento de publicarlos. No me acuerdo si era porque no estaba muy seguro de hacerlo, o quería buscar más información. No me acuerdo. Pero he dado cuenta de que ahora sí que lo puedo hacer.

Por supuesto he hecho un pequeño repaso de lo contado y corregido errores tipográficos, he arreglado expresiones...
*****
Después de la primera parte sobre borrado en discos duros, en esta entrega vamos a hablar de lo opuesto. Voy a dos ejemplos como los anteriores.

Ejemplo 1:

Estás trabajando con un fichero de suma importancia. Es muy, muy secreto y no quieres nadie lo vea una vez has terminado de trabajar con él. Así, una vez  has acabado coges y lo eliminas. Te aseguras que no está en la papelera de reciclaje y... Mierda que está ahí. Vacías la papelera y ya no está. Lo has eliminado del... ¿todo?

Ejemplo 2:

Tienes unos discos duros con información sensible. Ya no los necesitas, así, te vas a ganar un dinerillo vendiéndolos. Así que, antes de nada, les pasas un buen formateo. ¿Buen formateo?

Como hemos visto en la anterior entrega, estos datos que creemos estar seguros de que no se encuentran en la superficie del disco, siguen ahí. Por lo tanto, alguien podría recuperar esos datos. Y en los casos que nos ocupan no queremos que se pueda hacer eso bajo ningún concepto. ¿Qué se puede hacer al respecto? Puedes wipear el disco. Algo, todo sea dicho, que no he hecho en la vida. Wipear (de wipe) es un borrado seguro. Según nos contaron en el FTSAI, para que un borrado se considere seguro hay que sobreescribir como mínimo 7 veces en cada uno de los sectores. ¿¿¡¡¡Cómo...!!!?? Sí. Vamos a ver.

Hay que tener en cuenta que existen técnicas que permiten recuperar datos aunque se hayan sobreescrito. Según nos contaron se hace por estadística teniendo en cuenta el estado actual, se podría ver si el último estado bueno era un 0 (cero) o un 1 (uno) porque habría una pequeña diferencia de haber tenido el otro estado. Si no me acuerdo mal lo denominaron "momento magnético". Ahora me encuentro con un problema porque... las fuentes que he ido encontrando en Google indican todo lo contrario. Que las posibilidad de la que hablo es un mito. Por eso no lo puedo demostrar aquí. :(.  Aún así, me fío más de lo que me han dicho (a ver si es que entendí una cosa y era la otra, que puede ser) en el FTSAI que lo que he encontrado, que casi es un copy and paste de los unos y los otros.(1, 2 y 3 ).

 También hay que tener en cuenta que hay organismos que no les vale con hacer "sólo" esas 7 pasadas. Pero es algo que nos contaron, luego, no puedo poner referencias al respecto.

Lo dicho, lo mejor es usar un wiper, que hará  un borrado, en teoría, seguro.¿Ejemplos que he encontrado? Uno, otro, otro (Data Sanitazer) y otra lista más .

De todas formas, ya sabéis que podéis comentar lo que creáis conveniente sobre esto. Incluso, si tenéis información sobre las contradicciones con las que me he encontrado, me parecería genial que me las dijerais.

La RootedCon 2012

Estos días he estado en la RootedCon. Ha estado genial!!

Se entraba sobre las 9 y pico todos los días, a media mañana un descanso para almorzar unas conchas Codan, con un zumito y un poco de agua marca Rooted... Y a seguir!!

Cosas curiosas:
- parecía que se colaron de alguna manera en los móviles con el Evernote. Aparecía el título por defecto asiduo así como "nota de la Rooted". En la lista de distribución se dice que si tienes un evento, te pone ahí el título. Pero la creencia de que hubo un problema de seguridad estuvo Chula.
- Se dijo la frase típica de "en un congreso de hacking... ¿Como se os ocurre hacer _poner_acción_deseada? Pusieron un mueble con cables para cargar los móviles... Y de paso, copiaban sus datos son que la gente se enterase.

Y, después, a la fiesta no pude ir. :(

Allí he encontré con algunos de los profesionales famosos, como Chema Alonso, Lorenzo Martínez... Román, de la organización y co-fundador de la Rooted... Nico, co-fundador de ka NoConName...

Las ponencias muy chulas. Estuve twiteando mucho. Al menos el primer día. Los otros dos, sólo podía hacerlo al principio y al final de cada ponencia, por eso de economizar batería. La falta de enchufes es lo que tiene.

Y... Poco más os voy a contar ahora. Recomiendo encarecidamente que no os perdáis ninguna, si podéis.

Por favor, contadme: ¿Estuvisteis por allí? ¿Tenéis planeado ir a la NoConName de este año?