Article View: es.comp.hackers
Article #38065Re: Repost: Patrones de (in)seguridad
From: -={JPG}=-
Date: Thu, 07 Nov 2002 12:21
Date: Thu, 07 Nov 2002 12:21
207 lines
13704 bytes
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-mailReferences:
<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