news: Metasploit fue comprado por Rapid7
Leyendo el blog de Metasploit me encontré con que el excelente framework de exploits usado para penetration-tests fue adquirido por una compañía llamada Rapid7. Esta compañía (por suerte) se dedica a la seguridad, proveyendo su servicio a organizaciones para optimizar la seguridad de la red, seguridad de aplicaciones Web y seguridad en base de datos.

La pregunta que siempre surge cuando un software libre es comprado por una compañía es "qué va a pasar con la licencia?"...
Para dejarnos tranquilos (?!) el creador de Metasploit nos asegura desde el blog que la adquisición solo traerá buenas consecuencias, que Rapid7 no piensa cambiar la naturaleza open-source del proyecto, ni tampoco su licencia.

Entre las buenas noticias podemos decir que el creador (HD Moore) y uno de los desarrolladores (Egypt) ahora podrán dedicarse de tiempo completo al proyecto, estando Moore como Arquitecto en Jefe y Egypt como core developer. Además estarían contratando a un desarrollador de exploits, un diseñador de interfaces y un ingeniero QA.
Todo esto quiere decir que Metasploit se estará actualizando más seguido, agregando exploits, reparando bugs, y agregando nuevas funciones mucho más rápido que antes.

Esperemos que todo sea como dicen y que la compra no cague un excelente framework libre, estaremos viendo el progreso pronto.
KOOBFACE, el worm de Facebook
Hoy les traigo el review de una pieza magistral de malware: KOOBFACE. Esta singular software viene dando vueltas hace meses por distintas redes sociales de mucha importancia, siendo la más popular Facebook, gracias a la cual se ganó el nombre (koobface es un anagrama de facebook).

Actualmente este worm se dispersa, además de Facebook, por MySpace, hi5, Bebo, Twitter y Friendster, entre otros. Como suele suceder con la mayoría del malware importante, éste se dispersa por máquinas Windows, así que los *nixeros estamos a salvo =P

A lo largo del review voy a seguir la excelente explicación hecha por la gente de Trend Micro, llamada The Real Face of KOOBFACE.

KOOBFACE está formado por varios componentes, cada uno con una funcionalidad distinta. Estos componentes están dispersos en varios archivos que forman una bootnet (ver la imagen - cortesía de Trend Micro). La cantidad de componentes que forman esta botnet es increíble, haciendo del malware una pieza digna de investigar.



La forma de propagación no es nada del otro mundo. Uno recibe un mensaje en Facebook o alguna otra red social con un comentario llamativo que referencia un link a un "video" en "youtube". Digo "video", porque en realidad cuando seguimos el link llegamos a una página (llamada YuoTube...) que nos dice que nuestra versión de Flash está desactualizada y que para poder ver el video necesitamos instalar un ejecutable... ehhh alguien en su sano juicio no le daría instalar... ehhhh... mejor sigo con la explicación. Para el que tenga poca imaginación, aclaro que el ejecutable no es otra cosa que un downloader, el cual se encarga de descargarnos los componentes del KOOBFACE (si le dieron click están listos...).

La gente de Trend Micro dividió los componentes en las siguientes categorías:
- KOOBFACE downloader
- Componentes de propagación por redes sociales
- Componente Servidor Web
- Propagandeador e instalador de antivirus falso
- Rompedor de CAPTCHA
- Ladrón de datos
- Hijackers de buscadores Web
- Cambiador de DNS
como ven, son varias categorías, osea, el malware es bien completito, trae un poco de todo.
Cada uno de estos componentes es interesante, así que describo brevemente cada uno de ellos.

El downloader se encarga de determinar en qué redes sociales el usuario es miembro. Esto lo hace revisando las cookies del navegador. Una vez que sabe en qué redes el usuario tiene cuentas, se conecta al Command Y Control (C&C) y descarga los componentes que el C&C le indique.
KOOBFACE tiene la habilidad de armarse a medida para cada usuario, dependiendo de en qué redes sociales el usuario es miembro. Por ejemplo, si el usuario es miembro de Facebook y Twitter, el C&C le indica al downloader que se descargue las componentes de propagación para estas dos redes sociales.
Además de las componentes de propagación, el C&C le indica qué otras cosas le interesaría que la máquina del usuario haga, descargando alguno de los otros componentes.

Los componentes de propagación son los encargados de enviar los mensajes en las redes sociales, los cuales harán que otros usuarios se infecten si instalan el downloader. Estos componentes básicamente contactan el C&C, obtienen los mensajes y las URLs a postear, postean el mensaje y URLs en la página de cada red social, y también envían mensajes a la bandeja de entrada de otros usuarios.
Los componentes de propagación comprenden varios binarios, los cuales fueron construidos especialmente para manejar un site de red social en especial.
El gran enganche en la propagación está en que uno suele confiar en los links que envía un amigo y no piensa que puede tratarse de algo malicioso...

El componente Web server hace de nuestra máquina un lindo punto de distribución de malware. Una vez que el web server se instala en nuestra máquina, éste se registra en el C&C. El C&C le indica a nuestro nuevo, flamante e indeseado web server que actúe como proxy o como un redireccionador para distribuir otros componentes de KOOBFACE.
Este componente sirve las páginas falsas de YouTube, las cuales terminan en el downloader.

El propagandeador e instalador de antivirus falso se encarga de convencer al usuario de que su máquina está infectada lanzando ventanas de advertencia con links a antivirus falsos.

El rompedor de CAPTCHA usa una idea interesante, en vez de hacer el trabajo molesto de desenmarañar los CAPTCHAs para poder publicar cosas automáticamente, hacer que usuarios infectados resuelvan los CAPTCHA y usar el resultado obtenido!
Para hacer esto, el malware descarga la imagen con el CAPTCHA de alguno servidor C&C y amenaza al usuario a resolverlo con un mensaje inductor de pánico, el cual tiene un contador regresivo que reza "tiempo antes de apagar"... si el usuario no escribe lo que dice en el CAPTCHA KOOBFACE no apaga la máquina, sino que vuelve a reiniciar el contador. El contador está impuesto porque los CAPTCHAs tienen un tiemout, si no se resuelven en un dado tiempo, se genera un nuevo CAPTCHA.

Entrando en los componentes más riesgosos, nos encontramos con el ladrón de datos. El ladrón de datos roba IDs de Windows, perfiles de Internet, credenciales de e-mail, ftp y mensajeros instantáneos (GAIM, ICQ, Trillian, etc). Los datos robados son encriptados y enviados al C&C.

Los Hijackers de buscadores Web interceptan las búsquedas en Google, Yahoo, etc y las redirigen a dudosos sitios propios. Los sitios a donde vamos a parar nos muestran los resultados listando compañías que pagan a los administradores de KOOBFACE y no son sitios con buena reputación...

El cambiador de DNS modifica los servidores DNS utilizados por la máquina del usuario para que apunten a servidores DNS administrados por gente de KOOBFACE. Estos servidores interceptan los sitios que el usuario visita y envían en su lugar paginas con malware o phishing. Estos servidores DNS también bloquean el acceso a páginas de antivirus o de seguridad!


Como pueden observar, KOOBFACE puede hacer mucho y lo hace muy inteligentemente.
Para terminar, los de Trend Micro publicaron además una lista de las 8 cosas que seguramente no conoces acerca de KOOBFACE, es interesante como para enterarse rápidamente a qué nos enfrentamos.


Conclusiones

Como se habrán dado cuenta, KOOBFACE es una red compleja muy bien pensada y diseñada que abarca varias ramas de malwares y se propaga como chisme. Viene dando vueltas desde diciembre de 2008 (tal vez antes) y cada semana leo alguna noticia relacionada al tema, por lo que está muy activa actualmente.
La gran conclusión de todo esto es, NO INSTALES NADA QUE NO ESTES SEGURO!, no den click a lo pavo en todo lo que se quiera instalar. No le hagan caso a los alertas de antivirus falsos! No sigan cualquier link! Hotmail no se cierra! (uhh, eso pertenece a otro post...)
curiosidades: el origen del // en las URLs
Hoy me encontré con una noticia más que curiosa. Hace unos días le preguntaron a Sir Tim Berners-Lee, creador de la worl wide web (www), cuál era la razón de ser de las dos barras diagonales (//) que se sitúa en las URLs... y la respuesta fue: "no existe razón".

Para el que no entienda de qué estoy hablando, seguramente se dará una idea con el clásico ejemplo http://www.ejemplo.com. Como ven, las // aparecen en cada URL actual, no sólo para http, sino tambien para ftp://, smb://, etc, etc.

El mismo Tim pensando en retrospectiva no tiene mucha idea de porqué eligió poner dos barras en lugar de por ejemplo una, o ninguna, dado que no son necesarias.

Tim se disculpa por el sacrificio provocado por la necesidad de escribir dos caracteres inútiles y por toda la tinta malgastada en impresiones debido a ellas.

Este señor actualmente es el director del consorcio Worl Wide Web (W3C), que supervisa el desarrollo de la web, y es considerado el arquitecto de la www. Para el que quiera leer un poco más sobre el, siempre pueden encontrar su entrada en wiki, o bien en la misma página de la W3C.

Estas perdonado Tim! lo que inventaste es una genialidad, un componente vital en las comunicaciones, sin la www no podría aprender todo lo que aprendo, ni enterarme de todo lo que me entero.
Deshabilitar ejecución en directorios por política (Windows)

Ya se que van a pensar, desaparezco un buen tiempo y encima aparezco con otro post sobre aplicaciones MS... a mi también me da bastante cosa, pero el trabajo me lleva a esto, así que, a falta de tiempo para crear artículos sobre otros temas, comparto algo que me parece interesante para todos los que trabajan en seguridad.

En el entorno Windows XP (y Windows en general), deshabilitar la ejecución de programas se puede realizar utilizando políticas de grupo. Estas políticas se pueden configurar por máquina, o bien a través de Active Directory para aplicarlas a varias máquinas o usuarios. A través de estas políticas, como mostraré en un ejemplo, podemos desactivar la ejecución sobre particiones enteras, o también desactivar selectivamente *.exe, *.bat, etc.


Crear reglas basadas en path

Para aplicar la política en una dada máquina, se debe abrir el editor de políticas (“Start” -> “Run…” -> gpedit.msc). En el editor de políticas nos dirigimos a “Computer Configuration” -> “Windows Settings” -> “Security Settings” -> “Software Restriction Policies”. Si el directorio Software Restriction Policies se encuentra vacío, hacemos click derecho sobre este y elegimos crear un nuevo set de políticas. Una vez que tenemos la carpeta “Software Restriction Policies” poblada, nos dirigimos a “Additional Rules” como se muestra en la imagen.

Dentro de “Additional Rules” hacemos click derecho y elegimos “New Path Rule”, donde podremos ingresar el path a la carpeta donde desdeamos deshabilitar la ejecución. En la figura se muestra cómo deshabilitar la ejecución en el disco D:\, es decir, los usuarios no podrán ejecutar ninguna aplicación que se encuentre en este disco.

También es posible configurar directorios donde deseemos que esté permitida la ejecución. Esto lo hacemos de la misma forma que el caso anterior, pero en lugar de elegir Disallowed en el “Security Level”, elegimos “Unrestricted”.Eliminar una regla es tan simple como dar clic derecho sobre la regla y elegir Delete.

Los paths pueden contener expresiones regulares para hacer la restricción más fina. Si por ejemplo queremos restringir la ejecución de .exe pero no la de otros tipos de ejecutables (como los .bat o .com) en el D:\, podemos colocar la sentencia D:\*.exe en lugar de solo D:\


Otras formas de restringir ejecución

Además de deshabilitar ejecución por path, podemos deshabilitar ejecución por:- certificado: dependiendo de quién firme la aplicación, habilitamos la ejecución de la misma o no. Las aplicaciones pueden venir firmadas digitalmente, y agregando el certificado a nuestra lista podemos restringir o habilitar la ejecución de estos programas.

- hash: agregamos el hash de una aplicación a la lista y configuramos si esa aplicación puede ejecutarse o no.
- internet zone: podemos configurar qué sitios de internet tienen acceso a instalar aplicaciones en nuestra máquina.


Valores por defecto

Windows por defecto mantiene la política de permitir acceso irrestricto. La política por defecto se configura en “Software Restriction Policies” -> “Security Levels”. Los valores que se encuentran allí son “Unrestricted” y “Disallowed”. Para cambiar entre estos valores, simplemente damos clic derecho en uno de ellos y elegimos “Set as Default”.

NOTA: es importante destacar que si configuramos que el sistema por defecto no permita la ejecución de programas, deberemos configurar en Additional Rules todas los paths desde donde esté permitido ejecutar (por ejemplo, Program Files). En caso contrario, no podremos ejecutar ninguna aplicación.


Aplicando las políticas

Para aplicar las políticas recién configuradas, desde la línea de comandos ejecutamos “gpupdate /force”, o bien nos deslogueamos y volvemos a loguear.

Buena Referencia

Software Restriction Policies
Tunear logs de SQL Server
Hace un par de semanas vengo trabajando en crear logs de SQL Server que valgan la pena para así poder realizar trabajos de revisión y auditoría de lo que sucede en los servidores de base de datos de la empresa. El tema es que, aunque a uno le parezca totalmente simple activar los logs de un sistema tan utilizado y (supuestamente) fácil de administrar, esto no es así.
Por defecto SQL Server no loguea casi nada útil, solamente cuando ocurre un error grave o cuando se hace backup de la base de datos. Si piensan que su motor de base de datos está (como debería) logueando información para poder controlar las acciones... piensen de nuevo!, revisen los logs y diganme si encuentran algo en los logs que les sirva!

Por supuesto que el DBMS en cuestión cuenta con sistema de logueo de eventos, pero hay que activarlo a mano y conocer un poco sobre el funcionamiento de algunos store procedures creados para esto. Una de las primeras cosas que uno se encuentra cuando busca logs de SQL Server, es el modo de auditoría C2, pero existen otra forma más efectiva de loguear, la cual es usando los traces de SQL Server. A continuación explico un poco de estas dos modalidades de logueo.

Cabe destacar que activar sistemas de logueo siempre generan una sobrecarga en el sistema. Dependiendo lo que deseemos loguear, la sobrecarga será mayor o menor, pero es un punto a tener en cuenta.


Modo de auditoría C2

Este modo fue diseñado para poder cumplir con la clase C2 del Criterio de evaluación de confianza de un sistema computacional creado por el Department of Defence yankee (DoD). Cuando se activa esta modalidad de logueo, todos los eventos y todas las columnas pertenecientes a cada evento se loguearan. Como se podrán imaginar, este nivel de logging es extremo y poco útil para la mayoría de los sistemas. Revisar estos logs es para un monje Shaolin drogado, porque por más filtros que pongamos, seguiremos teniendo miles de entradas repetitivas e inútiles.
Para que se den una idea del nivel de logueo C2, lo probamos en una base de datos con relativo poco movimiento de datos y el log creció a más de 1GB en un par de horas! 1GB de texto! se imaginan lo que es??? pues mucho!

Si luego de toda esa introducción al modo audit C2 todavía tienen ganas de probarlo, lo pueden hacer ejecutando las siguientes sentencias T-SQL:
SP_CONFIGURE 'show advanced options', 1;
GO
RECONFIGURE
GO
SP_CONFIGURE 'c2 audit mode', 1;
GO
RECONFIGURE
GO
SP_CONFIGURE 'show advanced options', 1;
GO

Luego de ejecutar las sentencias anteriores, deberán reiniciar el motor de base de datos, así que haganlo en algún momento donde no tengan mucho movimiento de datos.
Para revisar que el modo quedó activado, pueden ejecutar la siguiente sentencia:
SELECT value FROM sys.configurations
WHERE name = 'c2 audit mode';
GO
Los logs se almacenan en el directorio \MSSQL\Data (osea, donde está instalado el SQL Server) y son archivos .trc de 200MB cada uno. Los archivos se van generando a medida que se van llenando, osea, se arranca con un archivo, cuando llega a 200MB, se cierra y se abre uno nuevo.
Recuerden lo que les dije al principio, estos logs son monstruosos, así que si tienen poco espacio en el disco, vigilenlos! Sino les comerá el disco y al almacenarse en la misma partición que la base de datos, puede que les genere un Denial of Service si el disco se llena!


SQL Traces

Para no volvernos locos con los logs generados por el modo C2, podemos customizar lo que deseamos loguear utilizando trazas (traces), las cuales creamos con una serie de store procedures que trae SQL Server. La explicación de cada uno de estos store procedures la pueden encontrar en la página oficial de MS, dependiendo la versión de SQL Server que tengan, puede variar un poco, pero hasta donde vi es bastante similar en todas las versiones. Yo voy a explicar el sistema para SQL Server 2005, pero no debería variar mucho para SQL Server 2008.

SQL Server basa su funcionamiento en eventos y por ello, los logs se arman en base a los eventos que queremos loguear. Por cada evento tenemos una serie de atributos que podemos loguear. Muchos atributos son comunes para todas los eventos, pero algunos son específicos para cierta clase de eventos. Nuestro trabajo trata sobre ver que eventos queremos loguear y qué atributo de cada evento deseamos... no es un trabajo fácil, porque existen como 200 eventos a loguear, y contamos con 64 atributos posibles, encontrar lo que realmente necesitamos llevará un tiempo de pruebas.

Para comenzar les puedo dar el formato de como crear una traza básica:
-- declaramos las variables necesarias
DECLARE @traceID int
DECLARE @maxFileSize bigint
DECLARE @traceFile nvarchar(245)
DECLARE @on bit
DECLARE @date nvarchar(25)

-- seteamos el tamanio para los archivos donde se almacenan los logs
set @maxfilesize = 200
-- seteamos la localización de los logs
set @date = convert(nvarchar(25), GETDATE())
set @date = REPLACE(@date,':','.')
set @date = REPLACE(@date,' ','_')
set @traceFile = N'D:\SQL_Traces\trace_'+@date+'.trc'


-- creamos la traza, obtienendo un id que se almacenara en @traceID. Indicamos que cuando se alcance el maximo del archivo, se cree otro archivo nuevo.
EXEC sp_trace_create @traceID OUTPUT, 2, @traceFile, @maxFileSize, NULL

-- decimos que queremos activar el evento
set @on = 1

-- activamos el evento 109 (auditar cuando se agrega un login a la base de datos) y queremos guardar las columnas 1 (el texto generado por el evento) y 11 (el nombre de login).
EXEC sp_trace_setevent @traceID, 109, 1, @on
EXEC sp_trace_setevent @traceID, 109, 11, @on

-- activamos el evento 110 (agregar un miembro a un rol) con las mismas columnas que antes.
EXEC sp_trace_setevent @traceID, 110, 1, @on
EXEC sp_trace_setevent @traceID, 110, 11, @on

-- iniciamos la traza
EXEC sp_trace_setstatus @traceID, 1
GO
Traté de comentar todo lo relevante en el código, pero es interesante destacar el significado de algunas líneas. Por un lado al principio decimos el tamaño máximo que debe alcanzar cada archivo de log (se utiliza el formato propietario .trc). Luego creamos un nombre para estos archivos. Como no deseamos pisar trazas anteriores, le agregué la fecha al nombre de archivo.
Una vez seteadas las variables, creamos la traza con el store procedure sp_trace_create, al cual debemos pasarle una variable donde nos retornará el id de la traza creada. Con el siguiente valor le podemos especificar opciones, yo coloqué 2 para indicar que una vez que se llena el archivo de log (osea, alcanzamos los 200MB), que se cree un nuevo archivo... es decir, vamos creando archivos de 200MB. Como se imaginarán, el siguiente parámetro especifica el nombre del archivo donde guardar las trazas, y el que se encuentra al lado es el tamaño de los archivos. Por último, como no nos interesan los valores stoptime y filecount, colocamos un NULL.
Ahora pasamos a setear los eventos que queremos loguear. Primero utilizamos una variable del tipo bit que nos servirá para decir que queremos poner en on el evento... esa variable la utilizaremos en el store procedure sp_trace_setevent. Las siguientes líneas simplemente activan los eventos agregar un login y agregar usuario a un rol utilizando la citada sp_trace_setevent. Para ambos casos logueamos las columnas 1 y 11, las cuales nos dicen el texto del evento (osea, lo que pasó) y el nombre del usuario de login que causó el evento. La lista completa de eventos que pueden loguear y las columnas que se pueden loguear, vean el mismo manual de sp_trace_setevent... armense de paciencia porque son muchos...
Por último, iniciamos la traza utilizando el store procedure sp_trace_setstatus, donde le damos el id de la traza que queremos activar, y le pasamos un 1 para indicar que iniciamos, si pusiéramos un 0 estaríamos deteniendo y con un 2 la eliminamos del sistema.

Muy bien, con todo lo anterior ya tenemos la traza en ejecución y logueando eventos. Qué pasa si queremos detenerla? utilizamos el citado sp_trace_setstatus. Como habrán visto, sp_trace_setstatus necesita dos parámetros, el id de la traza y el indicador de qué hacer con la traza (comenzar, detener, eliminar). Pues cómo obtenemos el id de la traza que deseamos? acuerdense que antes utilizábamos la variable @traceID, pero esa variable la perdemos una vez q termina la ejecución de las sentencias anteriores. No desesperen, hay una forma de hacer esto.
Dado que pueden haber varias trazas en ejecución al mismo tiempo, primero tenemos que buscar la que deseamos. Para esto podemos usar la sentencia:
select * from fn_trace_getinfo(0)
Esta sentencia nos devuelve todos los ids de las trazas existentes. Busquen la que desean detener mirando los atributos de cada una (pueden buscar el nombre del archivo donde se guardan los logs por ejemplo). Una vez que obtenemos el id de la traza simplemente ejecutamos:
EXEC sp_trace_setstatus elID, 0
si queremos solamente detenerla, o bien:
EXEC sp_trace_setstatus elID, 0
EXEC sp_trace_setstatus elID, 2
si queremos detenerla y eliminarla del sistema.

Lo último que me queda por decir acerca de las trazas es que estas se detienen cada vez que reiniciamos el motor de base de datos y no se arrancan solas. Si queremos que nuestra traza se inicie cada vez que iniciamos el motor de base de datos, podemos meter todo el código anterior en un store procedure de la base de datos master:
USE [MASTER]
GO

CREATE PROCEDURE usp_trace
AS

... TODO EL CODIGO ANTERIOR ...
Una vez creado el store procedure, debemos configurarlo para que se ejecute al inicio. Para esto, necesitamos oooootro store procedure llamado sp_procoption. Por suerte esto SP es muy simple, debemos pasarle el nombre del SP que queremos ejecutar, un valor indicando lo que queremos hacer (en nuestro caso que se ejecute al inicio del sistema) y el valor de la opción (true para activarlo). Asumiento el nombre del store procedure que utilice en el ejemplo (usp_trace), deberíamos ejecutar lo siguiente:
EXEC sp_procoption ups_trace, StartUp, True


Cómo leemos los archivos .trc?

Para variar, nuestros amigos de MS nos entregan un formato propietario el cual no se puede abrir con otra cosa que no sea el SQL Profiler, osea, un programa provisto por ellos...
El SQL Profiler es bastante completo y permite realizar distintos niveles de filtrado para poder visualizar la información que nos interesa, pero igualmente preferiría un formato de archivo visible con cualquier editor, o desde una base de datos.

Cabe destacar que es posible volcar los valores del log a una base de datos para que sean más fáciles de administrar, aunque ahora no recuerdo exactamente en donde estaba explicado, si lo encuentro en estos días, actualizo el artículo =)

También es interesante saber que las trazas se pueden crear desde el SQL Profiler, desde una GUI bien bonita... aunque siempre es mejor hacerlo a mano y estar seguro de qué se está activando. Además el SQL Profiler incurre en un overhead extra en el sistema para ejecutar las trazas...


Referencias

El gran artículo que me ayudó muchísimo a entender todo este sistema de log de eventos fue Get Compliant with SQL Server 2005 Audit, muchas gracias Larry Clark por tan buen artículo.
Por supuesto que el resto lo tuve que hacer solo mirando los manuales de MS que pueden encontrar en SQL Server Profiler Stored Procedures (Transact-SQL).
Lo más leido en Septiembre
Otro mes que vuela, uno nuevo que comienza. Desgraciadamente septiembre no trajo muchos artículos nuevos, llego bastante quemado del trabajo y no alcanza mucho el tiempo. Igualmente el blog recibió varias visitas a entradas antiguas, así que dejo la ya clásica (?!), lista de lo más leido en el mes.
Esto fué lo que los usuarios eligieron durante septiembre:

1. Crear máquina virtual en CentOS usando Xen. El mes pasado se posicionó segundo y este mes trepó al primer lugar. Parece que mi intuición viene bien, cada vez más gente busca probar Xen... seguramente KVM también este entre los más buscados.

2. Utilidad para hackear passwords de Windows y Linux. Con un nombre muy punch (como diría el sensey Javi), este artículo sigue atrayendo muchisima gente y seguramente lo siga haciendo por mucho tiempo... el sueño del pibe, hackear passwords...

3. Top Supercomputadoras. La verdad que me llamó mucho la atención ver este artículo tan arriba, tal vez le hice propaganda en algún lugar y no lo recuerdo. A mi me resultó muy interesante saber cuáles computadoras son las más poderosas actualmente. Tener una computadora de estas es el sueño del pibe...

4. Hacking Bluetooth: ni tan fácil, ni tan imposible. Lo dije el mes pasado y lo vuelvo a repetir, este es uno de mis artículos favoritos, me encanta que siga recibiendo muchas visitas y espero que sigan surgiendo cosas para hacer con bluetooth.

5. Programando tareas con cron. El más nuevito de la lista (data de agosto), lo cree porque en su momento visité varias páginas para utilizar cron, un demonio sencillo y extremadamente útil. Creo que debería estar en el bolsillo de todo administrador =)

Espero este mes contar con más tiempo y escribir varios de los artículos que tengo ganas, los cuales seguramente gustarán mucho, o al menos les resultarán interesantes. Stay tuned!