🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: es.comp.hackers
Article #38065

Re: Repost: Patrones de (in)seguridad

#38065
From: -={JPG}=-
Date: Thu, 07 Nov 2002 12:21
207 lines
13704 bytes
Hola,

:) Yo me hice un programilla, que posiblemente sacare a la luz para
demostrar la teoria de la posible seguridad del XOR. Todo depende del
enfoque que le des. Vamos a ver, la tecnica del XOR es un metodo de cifrado
asincrono, es decir, ambos lados conocen la clave. Muchos sistemas de
cifrado se basan en que la clave debe ser robusta con el fin de producir un
cifrado seguro... Planteemoslo desde otro punto de vista ;)

Supongamos un chat, o simplemente una shell remota. El comando que enviara
nuestro usuario sera distinto en muchas ocasiones, asi mismo, es imposible
predecir que mensaje enviara el usuario. Aqui tenemos algo medianamente
aleatorio, aun asi puede resultar predecible, ya que ciertos comandos se
emplean mas que otros. Pongamos en nuestro programa un buffer que vaya
guardando los datos recibidos previamente, y siendo el dato inicial la clave
conocida por ambas partes. Realmente lo que guardamos no sera la ultima
frase sino que: realizamos una suma, ocualquier otra operacion tonta entre
uno y otro caracter, y se lo agregamos delante a la frase guardada,
producimos un XOR con la frase nueva, y asi vamos generando algo que es
ligeramente mas aleatorio que el simple comando. De esta forma hemos
generado una clave pseudoaleatoria, es decir, a los ojos extra�os es
aleatoria, pero sabiendo que se esta "diciendo" es calculable. Evidentemente
la parte mas importante dle cifrado no es el cifrado en si, sino la
"aleatoriedad" de la clave, esa es nuestra principal fuerza. Ademas, lo de
agregarle un caracter al inicio hace que la clave para un XOR crezca
(deberas limitar la longitud para no provocar buffer overflow).

Personalmente las veces que lo he aplicado lo que hago es mantener dos
buffers, uno para el envio y otro para la rececpcion, asi evito posibles
desajustes como que se envien dos lineas a la vez... Ademas de esta forma lo
que recibimos no se cifra con la misma clave que lo que enviamos (Salvo al
principio)... Personalmente empleo sustitucion, asi como trasposicion...
Basicamente lo que hace el programa es cifrar la cadena del mensaje,
comando,...o lo que sea, mediante un XOR y los sistemas mencionados, de esta
forma el mensaje va cifrado, y la dificultad de hayar la clave es mas alta
que si siempre fuese la misma... Luego le a�ado un peque�o registro al
principio en el que se define un peque�o contador, con el fin de evitar que
alguien pueda inyectar datos en la conexion (Un sistema simple pero bueno,
a�ade una ligerar seguridad... y se agrega otro registro que hace referencia
a los bytes de basura (Bytes aleatorios agregados al final)... Estos bytes
de basura los ingreso, por ejemplo, para hacer menos evidente el mensaje si
se cifra algo como "ls" o "cd" ya que puede dar una orientacion para hacer
un XOR con ellos y de esta forma hayar parte de la clave empleada. Cuando
hemos concatenado estos datos, producimos una alteracion de su orden, y
aplicamos un XOR con la clave conocida por ambas partes (llamemoslo clave
estatica, mi clave inicial para la pseudo aleatoria se configura en un
fichero, y si no existe emplea una interna del programa) y sumamos a cada
byte su posicion realizamos alguna otra operacion simple (En mi caso suele
ser pasar la cadena a una cadena con valor hexadecimales, y juntar los pares
al inicio y los impares al final, y volverla a pasar a ASCII, ie 2E3FBC54 ->
23B5EFC4) y realizamos otro xor con la inversa de la clave guardada en el
buffer (si era hola -> aloh).

Para mi gusto son sistemas muy sencillos de implementar, y en principio son
sistemas de cifrado extremadamente sencillos, por lo tanto no consumen un
numero de recursos desmesurados y el cifrado es rapido... No estamos
basandonos tanto en el sistema de cifrado como en la aleatoriedad de la
cadena que ayuda al cifrado. Evidentemente se puede fortalezer mucho mas,
por ejemplo, el primer cifrado en vez de ser un XOR, aplicamos un XOR y
seguido 3DES, o simplemente 3DES, y en el segundo en vez de usar el XOR,
empleamos BLowfish.... Bueno la idea inicial era: Definir un sistema como
cifrado, por ejemplo BlowFish, y ese indica un punto de inicio, apartir de
el, se aplicaria ciclicamente 3DES -Blowfish, luego de Nuevo 3DES, y seguido
blowfish...etc...

Ventajas: Si quieres atacar la comunicacion debes por un lado, saber que
sistema se emplea para el cifrado en ese momento... Debes saber la frase
enviada previamente, y debes saber la clave comun. Otro de mis intereses,
era asociar esto a un sistema de cifrado asincrono, es decir, de clave
privada y publica, con el fin de emplearlo para que al iniciar session, se
produzca un trafico aleatorio seguro, con el fin de establecer un buffer mas
"aleatorio"... Pero todo se andara :)

Si tenemos en cuenta todo esto, si nuestro software cifra la comunicacion
mediante un XOR, no quiere decir que sea sencillo de romper... Lo que
tenemos que tener en cuenta es que existen sistemas esaticos (una clave que
siempre es la misma, o que ante una circunstancia siempre es la misma) que
si le damos dinamismo y aleatoriedad (realativa). Yo podria publicar el
codigo fuente de mi programa con el XOR, y posiblemente no serias capaz de
ver los datos que se envian y reciben, y mas aun si la comunicacion la
pillas ya iniciada (Es decir, el buffer ya no tienen nada que ver con el
inicial).

Lso sistemas de cifrado siempre se basan en codigo abierto, o deberian, y
esto se basa en un simpe hecho, si nuestro sistema de cifrado se basa en el
codigo, si alguien obtiene el codigo o parte de el, ya sea robandolo o por
ingenieria inversa, nuestro sistema se vuelve vulnerable, en cambio si
mantiene una seguridad alta aun conociendo el codigo, nuestro sistema sera
mas seguro... Aparte, ante debelidades del codigo, podemos encontrar gente
que nos ayude a mejorarlo.

Si hablamos de ocultar IPs dentro de un sistema de tipo chat, para mi gusto
lo mejor que podemos hacer es cojer la IP por ejemplo 212.134.225.34 y la
pasamos a formato largo y usamos una funcion HASH (No reversible), y a esta
le aplicamos un simple XOR con una clave que cambie cada dia, o simplemente
una funcion que nosotros mismos implementemos con la fecha y hora (o ambas),
de esta forma aunque rompan nuestro XOR, al haberlo programado con una
funcion no reversible, la unica forma de halarla es por fuerza bruta... Un
buen sistema seria SHA-1, y no emplear el hash entero, sino una parte del
mismo, de esta forma, aun usando fuerza bruta no obtendriamos la IP real...
Aun asi debe haber un registro activo, para evitar la repeticion de dos
cadenas, ya que si buscamos clones, no nos interesa ver clones donde no los
hay. Todo esto se asignaria directamente al conectar, y se guardaria en la
estructura del usuario.

Por poner un ejemplo: Yo la ip la tengo guardada en una estructura, no me
interesa que los demas la sepan, por lo tanto no tiene porque ser
reversible. Si yo cojo 8 bytes y a cada uno le miro cual es ru resto cuando
divido por 2 obtengo una cadena binaria. Lo unico que te dice esta cadena es
si el caracter es par o impar... Lo cual no es mucho, seria imposible darle
la vuelta a no ser de que uses intuicion y deseches posibilidades. Juntando
la IP con el nombre del dominio, es casi seguro que obtenemos los 8
caracteres, y sino juntamos el nombre de usuario y el nick. Resultado:
Obtenemos un caracter que podriamos considerar como "aleatorio" de la
cadena. Podemos obtener otro caracter aleatorio sumando todos los caracteres
de la cadena, de esta forma volvemos a obtener algo que es comun para muchos
caracteres. Si juntamos ambos simplificamos su descifrado, ya que sabriamos
cual es par y cual es impar, pero cual ha de ser la suma total... en cambio
si juntamos ambos caracteres mediante un XOR obtenemos uno propio para esa
cadena, pero que no devuelve informacion alguno de la misma. De esta forma
hemos obtenido el caracter X... En este caso podemos decir que X, al ser el
primer caracter hayado es el 1. Producimos 10 funciones de este tipo, y
directamente aplicamos substitucion en la IP en formato largo. De esta forma
obtenemos una cadena, propia... De la misma forma, podemos cojer solo los 4
primer bits de cada byte, al desehachar 4 bits, la cadena final cambia, y
tendremos una nueva cadena relacionada a la original pero que no es la
original, y como desconocemos los bits que faltan, podemos de nuevo intuir
que IP podria ser, pero no saberlo a ciencia cierta. Realmente si te pones a
pensarlo existen multitud de formas de dechar, o perder datos, que
convierten el cifrado en un unico sentido... De esta forma puedes
implementar sistemas de ocultacion de IP en servidores con bastante
eficacia. Simplemente no recurriremos al XOR sino mas a funciones tipo AND
para desechar datos.

Por otro lado, si queremos seguridad en nuestro propio servidor, es evidente
que el hecho de renombrar servicios, es algo muy util, ya que el atacante
puede buscar fallos para el servidor tal, cuando nuestro servidor nada tiene
que ver con el. En este caso suele ser bueno que busques fallos, ya que no
es bueno poner que tienes el X-FTPd en vez del Y-FTPd (el que tienes
realmente) si ambos comparten gran numero de fallos. Asi que no es bueno
simplemente cambiarlo, lo bueno es cambiarlo con cabeza.

Respecto a los puertos, si no necesitas un servicio es mejor tenerlos
cerrados, y si empleas un firewall es mejor tener un drop que un Reject
(Para mi gusto)... El reject envia un mensaje que indica que el servidor lo
ha rechazado, mientras que el drop no indica nada, ni si el servidor esta
activo. En ocasiones el reject puede ser util para realizar ciertas pruebas
propias, pero para mi gusto brinda mas seguridad el drop.

Para ser mas precisos vamos a plantear un caso real :)

Cojemos un equipo al azahar, y tratamos de establecer una conexion netBIOS,
curiosamente no podemos, pero recibimos un reject. Bien, ya tenemos un dato
importante: 1) Usa Firewall, 2) Emplea el filtrado de un router. Si no
recibimos nada: 1) No esta conectado. 2) No tiene el servicio activo 3)
Tiene un firewall. Lo siguiente que podriamos hacer es comenzar a escanear
puertos con el tan conocido nmap (o quizas queso), obtendremos cierta
informacion, posiblemente si lo que tiene es un firewall en su maquina
obtendriamos ciertos datos indicandonos que es un Windows, sino posiblemente
obtendriamos datos indicandonos un fingerprint del router. Podriamos probar
a enviar solo SYN, o enviar un SYN/ACK sin el SYN previo (Hay programas para
ello con el fin de rpobar firewalls), con lo que podriamos delimitar mucho
mas de que se trata. De esta forma los reject, ya suelen proporcionarnos
informacion del sistema...

Personalmente no usuaria el nmap, es mejor usar herramientas como las
mencionadas ya que un buen firewall deberia hacer un drop al ver un scaneo
de puertos, es decir, a cualquier conexion proviniente de un escaneo hacerle
un drop, aunque de con un servicio autorizado. Aqui volvemos a las mismas,
si no hace el drop, sino que hace un reject, nos da igual, nos envia
fingerprints que son utiles para detectar el sistema y obtener informacion
del mismo. El hecho de realizar rejects no seran lo mas seguro... Como si un
puerto esta abierto, por oculto que lo tengamos a scaneos de puertos, es una
via de facilitar datos al atacante.

Saludos

"Curro" <Curr0@QUITAESTOgmx.net> escribi� en el mensaje
news:Bgdy9.334824$nc1.2495545@telenews.teleline.es...
> "Lokutus" <Lokutus2222@hotmail.com> escribi� en el mensaje
> news:aq0rae$5avn1$1@ID-158003.news.dfncis.de...
> ...
> >  D - Patr�n "Seguridad por ocultaci�n."
> >
> >      Este patr�n de inseguridad es muy conocido  por  todos, :-),  si
> >      han sido capaces de romper el sistema de encriptaci�n  del  DVD,
> >      �por qu� algunos piensan que  nadie  se  va  a  enterar  que  un
> >      software usa encriptaci�n XOR?, �no entregando el c�digo  fuente
> >      quiz�?
> ...
>
> Aunque no soy ning�n experto, en este punto no estoy muy de acuerdo. Desde
> luego NO se debe basar toda la seguridad en la ocultaci�n, pero esta
> dificulta la recogida de informaci�n por parte de los intrusos para
explotar
> posibles vulnerabilidades.
>
> �Crees que no es bueno ocultar el tipo de servidor que "presta" un
servicio,
> o cambiarlo por uno distinto para despistar?
>
> �No te parece mejor tener los puertos "stealth" (ocultos) en vez de
> "cerrados"?
>
> Saludos
>
>
Technical Details
Message-ID: <mVsy9.360504$nc1.2579913@telenews.teleline.es>
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!fu-berlin.de!nsnmpen1-lo.nuria.telefonica-data.net!telenews.teleline.es!not-for-mail
References: <aq0rae$5avn1$1@ID-158003.news.dfncis.de> <Bgdy9.334824$nc1.2495545@telenews.teleline.es>

Show Full Headers
Complete Article Headers
X-Google-Language: SPANISH,ASCII
X-Google-Thread: f4463,a6fb2145ca5f7440
X-Google-Attributes: gidf4463,public
X-Google-ArrivalTime: 2002-11-07 04:21:39 PST
Path: arc1-ca.pugleaf.net!archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.cs.ubc.ca!fu-berlin.de!nsnmpen1-lo.nuria.telefonica-data.net!telenews.teleline.es!not-for-mail
X-Trace-PostClient-IP: 195.55.219.179
Reply-To: "-={JPG}=-" <jpg4u@hotpop.com>
From: "-={JPG}=-" <jpg4u@hotpop.com>
Newsgroups: es.comp.hackers
References: <aq0rae$5avn1$1@ID-158003.news.dfncis.de> <Bgdy9.334824$nc1.2495545@telenews.teleline.es>
Subject: Re: Repost: Patrones de (in)seguridad
Lines: 209
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <mVsy9.360504$nc1.2579913@telenews.teleline.es>
Date: Thu, 07 Nov 2002 12:21:38 GMT
NNTP-Posting-Host: 10.20.31.4
X-Complaints-To: usenet@teleline.es
X-Trace: telenews.teleline.es 1036671698 10.20.31.4 (Thu, 07 Nov 2002 13:21:38 MET)
NNTP-Posting-Date: Thu, 07 Nov 2002 13:21:38 MET
Organization: Terra Networks