0x22 años, el día 22 del mes 22/2

0x22 años, el día 22 del mes 22/2.

No podía faltar. Nuevamente surge una curiosa relación entre los números del día de mi cumpleaños que me obligan (es un decir) a escribir una reflexión sobre los guarismos. En esta ocasión, la cifra es dos.

Dos (2) es es el único número primo que es par, una rareza, y cualquier número se considera par si puede dividirse por 2; además, si sumas 2+2, multiplicas (2)(2), elevas 2 a la potencia 2 (2²), o calculas el factorial de 2 (2!), el resultado es el mismo. Mejor aún es que el 2 es la base de las computadoras, pues en computación todo lo expresamos en potencias de 2.

0x22 es un número hexadecimal que representa el 34 en decimal. Por si no lo han notado todavía, estoy cumpliendo 34 vueltas al sol, el día 22 del mes 22/2, o sea, el mes 11 (noviembre, 22 entre 2=11). Este sábado di una conferencia, y comentaba precisamente que tengo 22 años de experiencia en tecnologías de información; sí, tenía sólo 12 años cuando comencé a programar, y el aprendizaje también es experiencia. Otra referencia más al 2 es que mi hermana Julieta (la número 2 en orden de aparición) también cumple años este mismo día. Somos 2 los que festejamos simultáneamente. Feliz cumpleaños también para ti.

Tampoco hoy tengo un gran comentario, y para muchos es trivial lo que dije; pero no importa, es mi cumpleaños y estoy doblemente feliz de vivir.

:wq!

El Cazador de Virus: La Obscuridad de la Venganza

4564 6469 6520 6C69 7665 732E Eddie lives.

2E2E 736F 6D65 7768 6572 6520 ..somewhere.

696E 2074 696D 6521 0000 0000 in time!....

Cuando leí esto en mi editor hexadecimal, supe que lo había encontrado. Varias horas después de buscar a ese virus por todo el disco duro, por fin lo encontré. Ya antes había tratado con otros virus: Stoned, Ping-Pong, pero nada como Dark Avenger, hasta entonces. Y es que buscar a un virus polimórfico tiene su complejidad, y es tanto un arte como una carrera contra el tiempo; hay que encontrarlo antes de que destruya los datos del disco, pues después de varias ejecuciones del programa infectado, el virus escribe caracteres basura en el disco y lo deja inservible, desde el punto de vista de los datos y la información, y permanece en guardia, residente en la memoria, esperando que otro inocente ejecutable se cargara en la memoria para ser infectado por él.

La epidemia mundial de Dark Avenger era una realidad, y la ignorancia era generalizada como ocurre casi siempre en estos casos. No faltaba el irresponsable que decía que no pasaba nada o que ese nuevo virus era una mentira para sacar dinero, y que era comparable con una simple gripa, que sola desaparece. Pero la realidad era que el virus pasaba de una computadora a otra, de un diskette a otro, infectando archivos *.com y *.exe indiscriminadamente en cada copia, causando que en poco tiempo, en 1991, se diagnosticara la epidemia. Los brotes de Dark Avenger en las empresas crecerían del 10% al 60% en menos de un año (eso decían las revistas de computación de esa época, aunque en realidad no me consta), y se reportaron pérdidas millonarias atribuidas a ese virus creado en Bulgaria tan sólo dos años antes, en 1989. Si la gente se hubiera abstenido de copiar discos, quizá la epidemia se habría controlado o al menos retardado, pero la facilidad de introducir un diskette (o ahora, una memoria flash para USB, o pen-drive) en una computadora, luego en otra y luego en otra, donde a su vez han hecho lo mismo otros (no puedo resistirme a usar aquí la palabra "promiscuidad", so pena de ser bloqueado por algún filtro de contenido o por el mismísimo WebSense :D), propicia que la infección se propague más rápidamente.

Pero fue precisamente en 1991 cuando me tocó cazar a ese virus (tenía yo 16 años, y ya trabajaba: lo recuerdo porque no podía cobrar los cheques de mi sueldo, por no tener identificación oficial; tuve que hacerme amigo de la cajera del banco mientras convencía a la empresa de que me pagaran en efectivo :D). Volviendo a la cacería: Un antivirus en ese tiempo no era tan eficaz, pues el motor de mutación (mutation engine) de un virus polimórfico hace que el virus cambie su forma y, por consiguiente, su rastreo y erradicación sea más difícil. Así que la manera de localizarlo era identificando archivos ejecutables que hubieran aumentado de tamaño y buscando ciertas cadenas específicas en ellos, usando las herramientas de las que disponíamos en ese entonces, como Norton Utilities para MS-DOS (el primer Sistema Operativo que usé), o PC-Tools, entre otros. Para terror de algunos de mis lectores, en ese tiempo no teníamos conexiones a Internet como en la actualidad, sólo libros, así que ni pensar siquiera en googlear cualquier cosa. Todo era artesanal, como yo le llamo. El mayor artesano que conocí en ese tiempo fue Don Nico (así le llamábamos, era un señor como de 70 años, pianista, con coleta, mezclilla y chamarra de cuero, que viajaba en motocicleta y llevaba siempre sus diskettes en una bolsa de plástico, 'para no llamar la atención de los ladrones', me decía) y de él aprendí muchas de las técnicas ancestrales de seguridad computacional y administración de sistemas que todavía hoy conozco. Ese hombre sabía de todo y me inspiró mucho cuando me dijo una vez: "yo tengo mucha confianza en ti, porque a diferencia de los demás, a ti te gusta estudiar". Con esa frase me convertí en su padawan (no se rían, es en serio :D), en su aprendiz, y me dediqué a aprender y estudiar con él muchas técnicas de manipulación de archivos y direcciones de memoria, configuraciones avanzadas del Sistema Operativo, y muchas otras cosas que si las contara posiblemente perdería más de la mitad de mis lectores por su alto contenido técnico :D.

Dark Avenger, el Vengador Obscuro, no fue el único virus con el que tuve que lidiar en aquellos tiempos en que la ignorancia y la falta de información, aunados al descuido e irresponsabilidad, hacían de las suyas en el terreno de las infecciones virales de archivos de computadora. Después hubo muchos más, pero los softwares anti-virus comenzaron a ser cada vez más eficaces (aunque no necesariamente más eficientes), y poco a poco el arte del cazador de virus se fue olvidando (¿cuántos todavía recuerdan cómo rastrear cadenas en un mar de dígitos hexadecimales? Sin duda eran buenos tiempos). Algo que siempre me inquietó fue saber si el programador de Dark Avenger usaba una computadora como la mía, si él también tenía esos 256 Megabytes en RAM que yo tenía en mi 8088 a finales de los 80s.

La motivación de los programadores de virus siempre ha sido tema de debate: existen aquellos que justifican sus virus diciendo que es una forma de contrarrestar la piratería de software (el que copia ilegalmente un software, podría llevarse inadvertidamente algún virus), los que quieren vengarse de alguien o de la empresa que los despidió, o los que quieren obtener fama y reconocimiento a expensas de la destrucción de datos ajenos, e incluso los que no tienen ni la más remota idea de lo que están haciendo (script kiddies), y también los que lo hacen por diversión o por adquirir mayor conocimiento; lo malo de estos dos últimos es que muchas veces sus experimentos e investigaciones se les salen de control, y terminan "in the wild" (es decir, fuera del laboratorio) ocasionando desastres mayores.

Seguramente aún quedamos algunos que todavía conservamos algún trofeo de aquellas cacerías colgado en la pared. Yo, por ejemplo, aún tengo una reliquia: mi primer disco duro de 10 Megabytes (sí, leyó Ud. bien: 10 Megabytes, 10 MB) de 5¼", que guarda la única copia de Dark Avenger que conservo (eso quiere decir que no está erradicado :D). Hay veces, cuando me siento melancólico, que miro aquél viejo disco y recuerdo que aún hay mucho por aprender y experimentar en materia de seguridad y que he sido afortunado al haber tenido experiencias como aquélla con Dark Avenger y otros virus no menos peligrosos, pues me hicieron dar mis primeros pasos en la arena de la seguridad computacional; y, por supuesto, también me recuerda a Don Nico (Don Nicolás Flores), que siempre tenía algo qué enseñar a quien estuviera dispuesto a aprender y escuchar sus explicaciones sobre cómo y por qué hacía las cosas; sin duda, uno de mis mejores maestros.

¿"Eddie lives...somewhere in time!"? ...sí, en la obscuridad de mi viejo disco duro.

:wq!

Conferencia sobre NetBeans en FLISOL 2009 Monterrey

Este sábado fue el Festival Latinoamericano de Instalación de Software Libre 2009, y el evento en Monterrey fue todo un éxito. Debo reconocer en primer lugar el esfuerzo en la organización; en verdad fue un evento bien realizado, con una buena asistencia. Como comenté anteriormente, el anfitrión fue la Universidad Regiomontana (UR), en la Facultad de Ingeniería y Arquitectura (FACIYA). Yo tenía toda la intención de llegar desde temprano, pero en la mañana me conecté y entré al sitio de Flisol Monterrey, y descubrí que estaban haciendo un broadcasting, es decir, una transmisión en vivo del evento. Así que estuve siguiendo la primera parte del evento desde mi casa. Esa transmisión fue lo que llaman "la cereza del pastel", aunque como a mi no me gustan los pasteles, lo llamaría... no sé, mejor lo dejaré como un bonus ;-)

Las conferencias fueron muy buenas, y a pesar de recibir (indirectamente, nada personal) críticas hacia las certificaciones de seguridad (¿por qué medio mundo critica a alguien que se certifica?, ¿acaso no les gusta hacer exámenes?), el contenido fue de gran calidad. En cuanto a mi presentación, hablé sobre NetBeans y el crecimiento que ha tenido desde su primera aparición en Praga hasta nuestros días, y sobre todo, traté de hacer énfasis en la importancia de los desarrolladores en la aportación a la comunidad Open Source, pues quienes programan son precisamente los que mantienen vivo el crecimiento, por eso es que necesitamos que más se incorporen a la red de colaboradores del Open Source, especialmente los jóvenes universitarios que, con su entusiasmo y deseos de libertad, aportan mucho.

Para mi presentación instalé Linux Ubuntu en una memoria flash (pen-drive) USB, con OpenOffice 3.0, pues no tendría el descaro de presentarme al FLISOL con un Windows o con PowerPoint, ni Dios lo quiera ;). Lo único que lamento es no haber tenido tiempo suficiente para hacer una demostración con NetBeans IDE, para que vieran lo fácil que es programar con él. Es posible que el video de la conferencia esté disponible en los próximos días en YouTube, y si es así, pondré el enlace aquí mismo. La presentación pueden verla directamente al inicio de esta entrada.

Durante la conferencia me comprometí a iniciar un blog para hablar específicamente sobre NetBeans y Java, así que espérenlo muy pronto. El propósito es, como siempre, compartir un poco con la comunidad de quien también he aprendido.

En resumen, fue una buena experiencia compartir con la comunidad (principalmente universitaria) este sábado, y espero que esta experiencia se vuelva a repetir. Por cierto, gracias a quienes asistieron y permanecieron hasta mi conferencia, que fue la última del día (los agarré cansados, no pudieron correr :D).

Hasta luego.

:wq!

Hoy el tema es "libre"

Qué día. Aún estoy recuperándome del shock recibido esta mañana con la noticia de la adquisición de Sun Microsystems por Oracle, aunque muy en el fondo de mi corazón me parece bien que haya sido Oracle y no IBM. Me dá curiosidad ver qué hace Oracle con MySQL después de haber completado (commit;) la transacción (por decirlo en términos de bases de datos). La realidad es que Oracle había estado trabajando muchísimo con Sun desde hace varios años y sus productos se habían integrado muy bien en los ambientes de Sun (Oracle ejecutándose en Solaris, por ejemplo, o Java Stored Procedures), por lo que la integración de ambas compañías se vuelve, hasta cierto punto, natural. La verdad es que el shock fue porque he trabajado muy de cerca con tecnologías de Sun Microsystems desde hace 10 años (administrando, desarrollando, configurando, enseñando, investigando, etc.), y traigo (todavía) puesta la camiseta de Stanford University Network (SUN), por lo que cambiar de "color" de morado a rojo no será tan sencillo. Mientras tanto, una de las grandes preocupaciones de la comunidad será referente al código abierto de Sun (Java, OpenSolaris, NetBeans, MySQL, GlassFish, OpenOffice,...), que todos esperamos siga abierto y libre. Que así sea.

Y hablando de "temas libres", me complace anunciarles que el Festival Latinoamericano de Instalación de Software Libre (FLISOL) en Monterrey, edición 2009, se llevará a cabo el sábado 25 de abril (sí, claro, de 2009) en la Universidad Regiomontana, y me han invitado a dar una de las pláticas de ese día (les llaman "conferencia", pero siguiendo fiel a mi estilo, voy a "platicar"), mientras se lleva a cabo el installfest, que es algo así como una "fiesta de instalación de Linux" (mi hermana se escandaliza: "¿¡festival!?, ¿¡qué les pasa a ustedes, informáticos!?"), donde instalarán Linux Ubuntu en las computadoras que lleven; por cierto, la instalación es legal y gratuita, y también el registro al evento es gratis. Así que les recomiendo registrarse, asistir, llevar aquella computadora con poca memoria que usaban antes y que ahora sirve para detener la puerta, y además participar en alguno de los talleres o escuchar alguna conferencia (la mía, por ejemplo ;-)) o todas.

Si van, me saludan. Si no van... pues no. :-P

Hasta luego.

:wq!

Criptografía para románticos

Sí, también tengo un lado romántico; si no me creen, pregúntenle a mi esposa (no crean que es casualidad el hecho de llamarme Romeo :-D). Lo que pasa es que no uso con frecuencia mi romanticismo, que es diferente. Pero, ¿qué tiene qué ver la criptografía con el romance? Absolutamente todo. Yo mismo usaba la técnica del cifrado César hace muchos años para comunicarme con una novia que tuve: ella me escribía, o yo le escribía, pero siempre usando un sencillo algoritmo de sustitución de letras y una llave compartida previamente (me estoy refiriendo a una llave criptográfica, k=3, no sean mal pensados). La llave no era otra cosa sino un número que representa cuántas letras hay que desplazar. Por ejemplo, si ella quería escribirme: "necesito verte", simplemente cambiaba la 'n' por 'q' (3 letras después), la 'e' por 'h', y así sucesivamente hasta tener: "qhfhvlwr yhuwh", mensaje que se ingeniaba para mandarme por un medio no tan seguro (con alguna amiga). Yo recibía aquél papelito perfumado y procedía a decodificarlo, aplicando la llave con el algoritmo en sentido contrario: la 'q' por 'n' (3 letras antes), la 'h' por 'e', la 'f' por 'c', hasta tener el mensaje. Nuestro sistema funcionó correctamente y, dado que no nos descubrieron, puedo decir que nadie lo rompió nunca a pesar de su sencillez... el rompimiento fue otro. Así es la vida. ;-)

Ahora que me doy cuenta, creo que debí haber escrito todo esto usando algún cifrado, porque ahora que lo lea mi esposa se me va a armar tremendo lío. :-D

Sin embargo, ¿quién usa el cifrado César hoy en día? (En todo caso, les recomiendo usar cifrado Vigenère, que también es sencillo y prácticamente irrompible). Tal vez cifrar los mensajes mantenga fuera de la vista de los padres y otros curiosos las declaraciones de amor entre romeos y julietas, a menos que tengan un papá o mamá criptoanalistas... (hijos: si están leyendo esto y no quieren que me entere de algún mensaje que les intercepte, tendrán que ir investigando sobre criptografía de curva elíptica o, quizá para entonces, criptografía cuántica... o mejor aún, ¡cuéntenmelo todo!, ¿para qué se complican? :-D).

En fin, todo sea por conservar algo de intimidad y guardar secretos, pero siguiendo un principio básico en criptografía: estar de acuerdo. No vaya a pasar como aquella canción de Juan Luis Guerra que dice: "te mando señales de humo como un fiel apache, pero no comprendes el truco y se pierde en el aire". Ya me imagino, el cuate aquél mandando las señales con código morse ("y un código morse transmite el 'te quiero' de un ángel, se pierde en el aire"), y la amada ni en cuenta. ¡Que alguien le enseñe código morse, por favor!.

Aunque es cierto que un mensaje cifrado (encriptado, pues) hace evidente que hay un secreto guardado en el mensaje (es decir, si alguien ve un papel perfumado que dice: "qhfhvlwr yhuwh", va a saber que hay algo secreto y sentirá la curiosidad de saber qué es lo que dice), pero ¿qué tal si el mensaje es digital y contiene una fotografía o una canción en MP3? ¿qué tal si en la fotografía o en la canción va oculto un mensaje, imperceptible a simple vista o a simple oído? Eso ya no sería tan evidente. Esto es posible gracias a la esteganografía y otras técnicas de covert channels, pero de eso hablaré en otra ocasión; hoy no, porque la esteganografía no es tan romántica como la criptografía.

Bueno, los dejo con una frase de amor pseudo-geek, en cifrado César, que dice:

"dpru hv phprulcdu vx gluhfflrq ls, hq oxjdu gh xvdu gqv"

Hasta luego.

:wq!

Nota cultural: Para aquellos que siempre quisieron saber la secuencia que usó el fiel apache de la canción para transmitir "te quiero" en las señales de humo, la representación en Morse es: - . / --.- ..- .. . .-. --- (es cierto, por mis venas corre sangre de telegrafista: feliz día del telegrafista).

La comunicación es un asunto de capas

¿Alguna vez has tratado de entender cómo es ese asunto de las capas del modelo OSI o del conjunto de protocolos TCP/IP? Algunos maestros, en lugar de ayudar a comprenderlo sólo lograron confundir a más de cuatro, estoy seguro. Y al final sigue quedando la gran incógnita: ¿qué función tienen las capas en un modelo como OSI o TCP/IP? Esto lo escucho una y otra vez cada vez que doy un curso de redes y en realidad es algo muy simple. La gente encargada de definir el modelo pensó en una manera de representar que dentro de una comunicación intervienen una serie de elementos que, si bien son diferentes entre sí, se interrelacionan de una manera tal que pueden conseguir que una transmisión de datos se lleve a cabo. El concepto de capas es simplemente una forma de representar la individualidad de cada tarea en la comunicación y cómo se relaciona con otras tareas para lograr una colaboración de todo el conjunto.

En esta ocasión, como estoy de buen humor (como casi siempre ;)), les voy a platicar una alegoría para intentar explicar un aspecto fundamental en las comunicaciones entre dos equipos en una red de datos que usa TCP/IP. Después de contar la historia, trataré de aplicarla al concepto de comunicación del que estamos hablando, tengan paciencia.

La capa de Aplicación, en el origen
Yo vivo en Monterrey, México, y tengo un amigo, Guillermo Alegría (la versión mexicana de Bill Joy :D), que vive en la Ciudad de México. Mi amigo me ha pedido ayuda porque quiere aprender UNIX, así que pensé en enviarle unos manuales que tengo por ahí guardados.

La capa de Transporte, en el origen
Como son varios libros y quiero asegurarme de que mi amigo los reciba, he pensado que la mejor manera de enviarlos será uno a la vez, y una vez que tenga la confirmación de que recibió el primer libro, le envío el segundo y así sucesivamente (soy un poco desconfiado, por eso mejor me aseguro de que los va recibiendo, uno a la vez). Para que no se maltraten, envuelvo cada libro en un paquete.

La capa de Internet, en el origen
Por supuesto que para enviar un paquete necesito escribir el nombre y la dirección de Guillermo, y también la mía en caso de que mi amigo ya no viviera en ese domicilio y tuvieran que devolverme el paquete (no puedo darme el lujo de perder un libro de UNIX). Mi amigo vive en la célebre calle Chopo, en el número ocho, y así lo escribo en el paquete.

La capa de Enlace de Datos, en el origen
Llego a la empresa de mensajería, una de confianza. El encargado observa el paquete y me pregunta por qué medio quiero enviarlo: "¿Por avión o por carretera?" -me pregunta. Me interesa que mi amigo comience a estudiar cuanto antes, pero no tanto como para pagar la diferencia de un envío aéreo. "Por carretera" -le respondo.

El medio físico
Y ahí va el libro, viajando por carretera hasta la Ciudad de México. Diez horas de camino. En México encuentran mucho tráfico, como siempre, lo que retrasa el envío dos horas más. Ni hablar, todo sea en aras del saber.

La capa de Enlace de Datos, en el destino
Al fin la camioneta de reparto llega a Chopo 8, se aseguran de estar en el domicilio indicado y tocan el timbre. Mi amigo abre la puerta y se alegra de recibir el envío. A simple vista el paquete parece estar en buenas condiciones, de lo contrario, si llegara abierto por ejemplo, no lo aceptaría y me sería devuelto, o posiblemente sí lo recibiría, haciendo la observación pertinente al que lo entrega.

La capa de Internet, en el destino
Le preguntan a mi amigo: "¿Es usted Guillermo Alegría?", y él responde afirmativamente, por supuesto, y le entregan el paquete.

La capa de Transporte, en el destino
Le dan a firmar un acuse de recibo, porque recuerden que yo quería asegurarme de que recibiera el paquete, así que pedí que por cada paquete que él recibiera, firmara un recibo indicando que efectivamente tenía ya en su poder el paquete, así yo sabría que podría enviar el siguiente libro con mayor confianza. Mi amigo ya no puede esperar, le quita la envoltura al libro y observa que es el volumen 1, lo que quiere decir que seguramente deberá esperar más libros como ese. Si en el siguiente envío yo le mandara el volumen 3, seguramente él me mandaría a avisar que le faltó el volumen 2 y que no puede saltarse del 1 al 3, que necesita el 2. Al menos eso haría yo.

La capa de Aplicación, en el destino
Sentado cómodamente en su sillón, con un refresco y unas frituras, mi amigo Memo (es que así le decimos en México a los que se llaman Guillermo) se dispone a leer el libro de UNIX y se da cuenta de que podrá hacer muchas cosas ahora que aprenda a usarlo. Sólo espero que un día de éstos no me diga que ejecutó "rm -r /", siendo root. ;-)

¿Y qué tiene que ver esto con TCP/IP?
Mucho. TCP/IP es un conjunto de protocolos (reglas de comunicación) que tienen su propia función y que en conjunto pueden llevar a cabo la comunicación entre, al menos, dos dispositivos en una red. La división en capas nos ayuda a entender que en la capa de Aplicación se preparan los datos que serán enviados desde una Aplicación X a una Aplicación Y en otro dispositivo; como los datos que se envían seguramente son muchos, la capa de Transporte puede segmentar dichos datos en segmentos o datagramas que sean más fáciles de enviar, por tener un tamaño más manejable para los dispositivos de red. Como posiblemente sean varios segmentos de datos, se enumeran para que, una vez que lleguen a su destino, el destinatario (el que los recibe) sepa que han llegado todos los datos o si tal vez faltó alguno para pedir que se envíe nuevamente. Ahora bien, ninguna comunicación confiable será completa si no hay un adecuado direccionamiento, o si no se conoce el domicilio o dirección de quien recibirá los datos, y es precisamente la capa de Internet la encargada de identificar en cada paquete de datos la dirección de quien envía y de quien recibirá dichos datos. Una vez que ya se tienen listos los datos, en la capa de Enlace de Datos se prepara una trama (frame) para que los datos puedan ser enviados por algún medio físico, usando un cable, por ejemplo, o a través de ondas por el aire. Como cada medio es diferente y exige diferentes tipos de controles, las tramas se preparan para cada medio en particular, de acuerdo a los estándares.

Cuando los datos llegan al destinatario ocurre la operación contraria, pues las tramas llegan por un medio físico, y cada protocolo de cada capa va tomando la información que requiere de su contraparte que envió los datos. Por ejemplo, la capa de Enlace de Datos se asegura de que la trama realmente vaya dirigida a ese dispositivo físico de la red y pasa el paquete a la capa de Internet para que haga lo mismo; en la capa de Internet se verifica que la dirección de destino sea efectivamente la actual y se pasa a la capa de Transporte para que verifique a su vez que el segmento forma parte de la secuencia esperada y, en muchos casos, preparar una confirmación de haber recibido los datos, para que se envíen más. Al final, los datos son colocados en orden y pasados a la capa de Aplicación, que hará que sean presentados o recibidos por la Aplicación Y de una manera legible, ya sin todo el "empaque" que se colocó en los datos al ser enviados.

Obviamente esta es una explicación muy simplificada de lo que realmente ocurre. No hablé, por ejemplo, del famoso three-way handshake para TCP, por ejemplo, ni de otras características igualmente importantes, pero para eso hay muy buenos libros y otros recursos de consulta. Este es solamente mi sencilla aportación para tratar de explicar algo como a mi me hubiera gustado que me lo explicaran.

Fin de la transmisión.

:wq!

El colmo de un CISSP/CEH: que su blog sea catalogado como "malicious"

Después de haber pasado un inicio de semana en injusta ignominia, bloqueado por el Websense desde la red de la empresa donde trabajo, en la dudosa categoría de "Malicious Web Site", me he animado nuevamente a escribir, haciendo a un lado el oprobio y concentrándome en el propósito original de este blog, que es... ahora que lo pienso, no tengo otro propósito mas que escribir un poco de lo que sé y que creo que le pueda ser de interés a alguien.

Pero, ¿por qué "malicious"? Si yo no hago phishing, ni pharming, ni tampoco soy spammer ni cracker. Una cosa es que sepa cómo hacerlo, y otra muy diferente es que lo haga o que enseñe cómo se hace. En eso precisamente radica el Ethical Hacking, en conocer y usar adecuadamente y con responsabilidad las herramientas para encontrar huecos de seguridad y ofrecer alternativas de solución.

Hablando de Ethical Hacking, hace unos días terminé lo que fue mi última intrusión, hasta el momento, en un sistema ajeno con permiso del dueño. Seguramente no sería tan relevante, si no fuera por la manera que al final usé para poder ver información confidencial.

Para darles un poco más de contexto a mis lectores (¡ya son 5!), les diré que el Ethical Hacking, o Pen-Test (prueba de penetración), consiste en llevar a cabo una serie de pruebas controladas, automáticas o manuales, con diversas herramientas de hacking para intentar ganar acceso y comprobar qué tan vulnerable es una red o un sistema. Hay ethical hacking en prácticamente cualquier nivel: de sistemas operativos, redes, redes inalámbricas, aplicaciones web, sistemas criptológicos, bases de datos, etc. Pero lo más importante en cualquier prueba de penetración no es solamente encontrar las vulnerabilidades, sino proporcionar las soluciones, y eso es lo satisfactorio.

Ahí estaba yo, a la mitad de la noche, inspirado por el café, escribiendo un programa en Java... import java.net.*; import java.io.*; etc. Y es que después de dos escaneos sin vulnerabilidades relevantes, la única alternativa que veíamos (mi taza de café y yo) era hacerlo artesanalmente: programando mi propia herramienta. Los scanners me ayudaron en cierta manera para automatizar el proceso de descubrimiento e identificación, pero si quería llegar más lejos (o más adentro, según la perspectiva), tenía que hacerlo a mano, artesanalmente. El Diccionario de la Lengua Española define artesano como "quien hace por su cuenta objetos de uso doméstico imprimiéndoles su sello personal", por lo tanto como yo hago objetos (bueno, hago las clases y luego los objetos con new) y les imprimo mi sello personal, entro en la categoría artesanal. Además, yo siempre he dicho: "programar es un arte". Mi programa, hecho en 100% Java, funcionó y me permitió terminar la penetración en menos de lo que terminaba mi última taza de café.

El caso es que aproveché una vulnerabilidad de la aplicación en el manejo de sesiones. Externamente la aplicación se veía bien, con su forma de acceso por usuario y contraseña, pero al analizar las respuestas del servidor HTTP observé patrones que me ayudaron a formarme una imagen mental de lo que ocurre allá en el servidor. No puedo revelar más detalles de la intrusión, pero para cuando terminé mi café no sólo había encontrado la puerta para entrar, sino que ya tenía evidencia de información confidencial que usuarios de ese sitio habían subido, confiados de que sus documentos estarían seguros, pero el simple hecho de confiar a alguien más nuestra información, la hace potencialmente vulnerable.

Este tipo de ejercicios son muy enriquecedores por el conocimiento que proporcionan (sin mencionar la retribución económica), pero debo aclarar que sólo lo hago por la vía legal; una intrusión sin permiso no está en mis planes, ni tampoco está en mi código de ética.

Ya para concluir, si por alguna razón este sitio vuelve a ser bloqueado por nuestros amigos de Websense y están leyendo estas líneas gracias a una traducción de Google (¿sería buena idea escribir esto en inglés?), lamento informarles que en este sitio no enseño técnicas para hacking, ni tampoco publico exploits, y los únicos consejos que publico son con el ánimo de incrementar la cultura de la seguridad de la información... y compartir una que otra taza de buen Java.

:wq!

CISSP: Certified Information Systems Security Professional, por (ISC)².
CEH: Certified Ethical Hacker, por EC-Council.