Sunday, December 21, 2008

Password Masking & JVM

Hoy le toca el turno a Java, pero antes voy a hacer un paréntesis
(
Hace algún tiempo si me preguntabas ¿cuál es el mejor lenguaje de programación? la respuesta que hubieras obtenido habría sido C. Esto sucedió mientras la gente que me rodeaba decía que el mejor lenguaje era Java y yo necio, decía y afirmaba que el mejor era C; y te has de estar preguntando ¿bueno, ahora piensas que el mejor es Java? Pues no, un día alguien o algo (realmente no sé que fue) me abrió los ojos, ¡el mejor lenguaje de programación es Ensamblador! XD jajaja. Por su puesto que no pienso así, lo que pasó cuando me abrieron los ojos fue que me dí cuenta de que realmente no puedo decir tal lenguaje es mejor que otro, simplemente unos te permiten hacer más fácil determinada tarea, o incluso aunque pueden hacer las mismas cosas que otros su ámbito es diferente.
)

Password Masking en la línea de comado.
http://java.sun.com/developer/technicalArticles/Security/pwordmask/ndo


Byte Code Engineering Library (BCEL)
http://jakarta.apache.org/bcel/manual.html

Thursday, November 13, 2008

Doug Lea's Malloc

Alguna vez te preguntaste ¿cómo es que funciona la llamada a malloc?. Dejame decirte que te haces muy buenas preguntas y las respuestas son MUY interesantes. =D

http://g.oswego.edu/dl/html/malloc.html
ftp://g.oswego.edu/pub/misc/malloc.c


#include <stdio.h>
#include
<stdlib.h>
#include
<string.h>

int main (int argc, char *argv[]){
char *p;
int size,malloc_size;

if(argc != 2){
printf(
"Uso: %s size\n",argv[0]);
exit(
-1);
}

size
= atoi(argv[1]);
printf(
"--------[ Probando para size: %d bytes\n",size);
p
=(char *)malloc(size);
memcpy(
&malloc_size,p-4,4);
malloc_size
&=~7; //Quitamos las banderas
printf("--------[ Malloc size: %d\n",malloc_size);
free(p);
return 0;
}


Obviamente, que al código le hace falta quitarle los bytes que utilizan los boundary tags.

Monday, October 20, 2008

La Música Mexicana trasciende fronteras

Cisco ships Mexican drug runner music on VPN CD
Cisco network’s new album

Actualización 01/11/2008

Estaba pensando, ¿Cisco podría ser acusado por piratería? xD

Monday, October 6, 2008

Hacking The System - Manipulando la Wikipedia

En la 2600 de la Primavera de 2008, apareció un artículo que llamó mi atención, se titula "Information Flow On Campus: A Closer Look At Wikipedia" escrito por Barrett Brown.

Lo que hizo Barrett fue analizar como es que funciona la Wikipedia, y dentro de esto analizó "el sistema social" bajo el cual se rige, lo cual en realidad es muy interesante ... así que comencemos.

Existen 2 grupos de usuarios en la Wikipedia.
  • Pasivos
  • Activos (Editores)
Dentro de los editores existen diversos tipos:
  • Editor Anónimo - cualquiera que realiza una modificación a un artículo sin crear una cuenta.
  • Editor Nuevo - alguien que ya creo la cuenta, y su historial de edición es muy bajo o nulo.
  • Editor Reconocido - alguien con una cuenta y que ya tiene un historial de edición considerable.
  • Administrador - rango más alto que se puede alcanzar dentro de la Wikipedia, para esto se tuvo que pasar previamente por los otros status.
¿Y para existe esta jerarquía?, pues en realidad es algo muy parecido a lo que pasa con PGP .... CREDIBILIDAD.

(La alternativa de PGP a las Autoridades Certificadoras (CA), esta basada en votos de confianza. Tratare de explicarme un poco más, así que ocupemos a los famosísimos personajes: Alice, Bob y Carol.

Bob necesita autenticar un mensaje enviado por Alice.

Bajo el esquema de la CA's, funcionaria de la siguiente forma:
  1. Alice crea una firma y la publica ante la CA [esto implica $].
  2. Bob obtiene la firma de Alice de la CA y realiza el proceso de autenticidad del mensaje.
[En este esquema tanto Alice como Bob, dan por hecho de que lo que diga la CA es verdadero y los dos confían "plenamente" en ella]

Bajo el esquema de PGP, sucedería lo siguiente:
  1. Alice crea una firma y la publica.
  2. Bob obtiene la firma de Alice. [Llegado a este punto, existe un pequeño problema, ¿cómo saber que la firma que Bob obtuvo es realmente la de Alice?, bajo el esquema de las CA's como ambos confían en la CA, Bob da por hecho de la firma que obtuvo de la CA es la de Alice]
  3. Entonces entra Carol a salvar el día, porque Alice conoce a Carol y Carol sabe que la firma que esta publicada a nombre de Alice es realmente de ella; y lo mismo sucede con Carol y Bob, i.e; Bob conoce a Carol y sabe que la firma que esta publicada a nombre de Carol es realmente de ella. Así que Carol le da un voto de confianza a Alice.
  4. Como es posible ver los votos de confianza que tiene una firma, Bob ve que tiene un voto de Carol y como confía en ella, aceptara que la firma que esta obteniendo es la de Alice. [Carol juega un tanto el papel de la CA])
Después del pequeño paréntesis continuemos -->

En la Wikipedia un artículo que esta editado por un Administrador, tiene mucha mayor credibilidad que sí hubiera sido editado por cualquier otro tipo de Editor.
¿Por qué?
Veamos lo que se tiene que hacer para llegar a ser administrador.
  1. Crear una cuenta (Editor Nuevo).
  2. Editar artículos poniendo referencias aceptadas como verídicas (eje. libros), que aprueben lo que se esta editando.
  3. Una vez que ya se ha realizado lo anterior muchas veces, se llega a Editor Reconocido.
  4. Y finalmente para ser Administrador se hace una votación (votos de confianza), en la que finalmente se aprueba que lo que este monito edita es verdad, al menos en la mayoría de los casos.
Y todo este rollo ¿¡¡para qué!!?, bueno Barrett termina con una conclusión interesante.

"Si yo fuera una organización como la CIA o al-Qaeda, preocupada por controlar la información publicada en la Wikipedia, esto es lo que haría.
Primero, contrataría de diez a treinta personas y las metería en la biblioteca. Su trabajo consistiría en introducir referencia de los libros a la Wikipedia, día tras día, hasta que sus cuentas se conviertan en Editor Reconocido o Administrador. Una vez que un grupo de administradores este bajo el control de esta organización, seria fácil manipular temas en especifico."

Saturday, September 20, 2008

Google Chrome

Reflexiones sobre Google Chrome y la seguridad

Actualización 01/11/2008

La alternativa a Google Chrome, es SRWare Iron (o simplemente Iron). =D

Saturday, August 23, 2008

Diseccionando un envío de Correo en Gmail

El envío del correo electrónico se lleva a cabo por medio del protocolo SMTP, sin embargo debido a cuestiones de seguridad, políticas, etc. se ha dividido el envío del correo electrónico, de la transmisión. Entiéndase como envío la comunicación entre el MUA -> MTA y como transmisión la comunicación entre MTA -> MTA.

De manera, que para cada uno de estos tipos de comunicación tenemos lo siguiente:

* Para la transmisión del correo se ocupa SMTP por el puerto 25 [RFC 2821].
* Para el envío del correo se ocupa SMTP por el puerto 587 [RFC 4409].

Para hacer la disección del envío de correo ocuparemos Gmail, por lo que la dirección del servidor SMTP que ocuparemos es smtp.gmail.com. (De aquí en adelante S-Servidor C-Cliente).

$ telnet smtp.gmail.com 587
S: 220 mx.google.com ESMTP m29sm12092147poh.3

Si vemos los servicios (extendidos) que nos ofrece este servidor obtenemos:
C: ehlo
S: 250-mx.google.com at your service, [w.x.y.z]
S: 250-SIZE 28311552
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 ENHANCEDSTATUSCODES

Lo que nos importa es la línea que dice "250-STARTTLS", ya que en este punto si introducimos cualquier comando de SMTP obtendremos.

S: 530 5.7.0 Must issue a STARTTLS command first m29sm12092147poh.3

Es decir, tenemos que iniciar una comunicación "segura", ocupando SMTP sobre TLS [RFC 2487], que tiene que ser algo como lo siguiente:

S: <waits for connection on SMTP port>
C: <opens connection>
S: 220 mail.imc.org SMTP service ready
C: EHLO mail.ietf.org
S: 250-mail.imc.org offers a warm hug of welcome
S: 250 STARTTLS
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
C: <continues by sending an SMTP command>
. . .
(El estándar específica que el primer comando que DEBERÍA enviar el cliente después de haber establecido la negociación de TLS, es un EHLO)

Para la comunicación con el servidor ocuparemos Ruby.

=begin
Al parecer estas líneas no son necesarias en Windows
require 'socket'
require 'openssl' -> Si ocupas Lnx, tienes que tener instalado libssl-ruby
=end

require 'base64'

smtpSocket = TCPSocket.new("smtp.gmail.com",587)
S: 220 mx.google.com ESMTP z15sm18510036pod.11\r\n

smtpSocket.puts "ehlo"
S: 250-mx.google.com at your service, [w.x.y.z]
S: 250-SIZE 28311552
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 ENHANCEDSTATUSCODES

smtpSocket.puts "starttls"
S: 220 2.0.0 Ready to start TLS\r\n

ssl=OpenSSL::SSL::SSLSocket.new(smtpSocket)
ssl.connect
ssl.puts "ehlo"
S: 250-mx.google.com at your service, [w.x.y.z]\r\n
S: 250-SIZE 28311552\r\n
S: 250-8BITMIME\r\n
S: 250-AUTH LOGIN PLAIN\r\n
S: 250 ENHANCEDSTATUSCODES\r\n

Y es en este punto donde encontramos algo interesante: "250-AUTH LOGIN PLAIN", esta línea nos dice la forma en la que podemos autenticarnos; toda esta autenticación se lleva en base a SASL (Simple Authentication and Security Layer) [RFC 4422]. ¿En algún lugar has escuchado SASL?, efectivamente es un framework para autenticación que es usado por varios protocolos y entre esos protocolos se encuentra LDAP y si alguna vez has ocupado Active Directory sabras que la autenticación (por default) se lleva a cabo ocupando Kerberos [RFC 4752]. En nuestro caso ocuparemos PLAIN [RFC 4616], que lo que nos dice es que tenemos que enviar un mensaje de la siguiente forma:

[authorization_identity] UTF8NUL authentication_identity UTF8NUL passwd

Como se especifica en el estándar no enviaremos el campo authorization_identity ("el cliente no provee una identidad de autorización [authorization identity] cuando quiere que el servidor derive una identidad de las credenciales proporcionadas"). De forma que nuestro mensaje queda:

\x00user\x00passwd

Pero antes, de poder enviarlo es necesario saber que tiene ir codificado en Base64.

#Continuando con el código de Ruby
autenticacion = "\x00" + "user" + "\x00" + "passwd"
autenticacion = Base64.encode64(autenticacion)
ssl.puts "auth plain" + autenticacion
S: 235 Accept

# Y ya que estamos adentro, ¿por qué no enviarnos un correo?
ssl.puts "mail from:<user@gmail.com>"
ssl.puts "rcpt to:<user@gmail.com>"
ssl.puts "data"
ssl.puts "From: <user@gmail.com>
To:<user@gmail.com>
Subject: Hola Mundo
Hola Mundo desde Ruby!"
ssl.puts "\r\n.\r\n"
ssl.puts "quit"

Referencias

[RFC 2821] Simple Mail Transfer Protocol, Abril 2001
[RFC 4409] Message Submission for Mail, Abril 2006
[RFC 2487] Secure SMTP over TLS, Enero 1999
[RFC 4422] Simple Authentication and Security Layer, Junio 2006
[RFC 4752] The Kerberos V5 (GSSAPI), SASL Mechanism, Noviembre 2006
[RFC 4616] The PLAIN SASL Mechanism, Agosto 2006

Advertencia

Antes de empezar a poner letras ... y más letras en este blog, he de hacer una pequeña ADVERTENCIA.

Puede que en algún momento que este en trance escriba sobre el "underground", así que, mi estimado lector si tu perteneces a algún grupo de este Universo y te ofenden mis comentarios, siente la completa libertad de apretar las maravillosas teclas Ctrl+W, Ctrl +C, Alt+F4 (o la combinación que aplique para tu browser) . O bien, si tienes un argumento lógico y racional ---> puedes intentar convencerme de que estoy equivocado.
¿Por qué esta advertencia?, porque no pertenezco a ese gran, fenomenal y maravilloso Universo y realmente no me gustaria ofender a alguien que sí forma parte de él. =D

$ sed -e "s/\(.\)\(.\)/\2\1/g" | tr [az] [za]

oLz tnreoi rztbmei npzilzcz c zuqliure zuq eess eitn zfoneidodp rom sic moneztirso ,lcrz,os iseq eup eued selree ts.o