Mensajes

Hay algunos proxy que incluyen tu IP en la cabecera HTTP al sitio. Por ejemplo páginas que te traducen el contenido a otro idioma, entre otros muchos.

Tambien todo el tráfico que no pase por el proxy.

Leaks de DNS.

etc.

Puedes usar Whonix pero da igual si usas el mismo pc/dispositivo, router, ISP, localización geográfica... No es para nada sencillo ser 100% anónimo.

Código (javascript) [Seleccionar] Expandir

var v = ["V",".","0",".","0",".","0",".","0",".","1"];
var x = parseInt(v[10]);
++x;
v[10] = x.toString();
alert(v.join(''));

1.Declaro array.
2.Obtengo el último elemento del array "1", lo convierto en int 1 (pasa de ser un texto(string) a un numero(int) y lo guardo en la variable x.
3.Aumento el valor de la variable x con el operador de pre-incremento.
4.Casteo el nuevo valor int 2 de x en string "2". Lo asigno al último elemento del array.
5.Lo muestro elminando las comas del array en el output.

Lo puedes hacer de muchas otras formas.

PD: Si quieres que aumente el penúltimo al llegar a 1000:

Código (javascript) [Seleccionar] Expandir

/* En vez de v[10] usa v[i]. */
var i = 10;
var v = ["V",".","0",".","0",".","0",".","0",".","1"];
var x = parseInt(v[i]);
++x;
if (x === 1000)
{
x = 1;
i -=2;
 
  if (i === 0)
  {
  i = 10;
  }

}
v[i] = x.toString();
alert(v.join(''));

Ahora lo que hace es que si el numero llega a 1000, se ponga a 0 y se moifique la versión anterior. Ejemplo V.0.0.0.0.999 le sumas 1 y pasa a ser V.0.0.0.1.0
En el segundo if si se llega a la V sez vuelve a empezar por el último dígito. También puedes añadir un nuevo punto y número al final. No sé si la implementación está bien, es por mostrar la lógica más que nada.

Tienes que añadirle un par de cosas más para que funcione exactamente como lo quieres. Si lo haces con funciones te es fácil acabar la implementación.

Con búsquedas avanzadas es bastante fácil encontrar webs vulnerables, por desgracia demasiado. Me acabas de recordar que tengo pendiente hacer un programa en java con librerías para automatizar navegadores y hacer búsquedas avanzadas para obtener webs vulnerables a sql injection y en caso de serlo que me las guarde en un txt  .

Oh, me encanta tu idea. Puedes usar los Dorks para sacar un montón de resultados y crawlear los sitios mientras vas testeando. Para probar en formularios puedes usar javascript con el método submit(). Puedes hacer una web desde la cual llames a Java utilizando una Interfaz O correr el javascript desde el propio Java usando WebKit con WebView, GetSettings y javascript enable usando LoadUrl para cargar tus documentos prediseñados con código HTML y javascript. O directamente zumbándole el javascript en la Url usando el Pseudo-Protocolo de javascript con load Url. Yo al estar 99% del tiempo en Android, es de las herramientas que más uso. Aunque perfectamente se puede crear un HTML sin limitaciones, cargar la web y poner la url del HTML en local. Así se ejecuta en el mismo contexto.

Las blind es cuando no te queda mas remedio que usarlas, yo lo que entiendo de las que se basan en retardos de tiempo es que si pones una función para que espere x segundos y se cumple es que esta ejecutando la sentencia introducida pero también tienes que tener en cuenta tu conexión y es difícil dominar esa técnica.

Ando a tope aprendiendo de SQLi! Tengo que buscar páginas legales para ir practicando.

Lo de poliglotas no lo había oído nunca xD, tengo que informarme sobre eso.

Un políglota es un script que contiene varias formas distintas de explotar una o más vulnerabilidades a la vez. Por ejemplo varias inyecciones HTML y XSS en un mismo script. Si el elemento es vulnerable a alguno de los métodos que contiene el script salta. Así puedes probar con un mismo script varios payloads a la vez. https://github.com/0xsobky/HackVault/wiki/Unleashing-an-Ultimate-XSS-Polyglot
En el foro de dudas generales, diría que es en el último de los libros del listado de hacking se usan poliglotas, y temas muy interesantes que no se tocan en otros libros. Es una joya.

Pues un foro que tenga XSS puedes armar el caos y si se te da bien la ingenieria social ni te cuento. Yo hace poco encontré algo curioso en una pagina y es que por ejemplo la url es así 'www.ejemplo/index.php?mensaje=hola'. Si cambias el parámetro GET por '?mensaje[]=hola' en la pagina te sale 'Array' tal cual, como interpretando código php pero no salta ningún Warning.

Ostrás. Lo busqué y parece que puede llegar a ser un fallo gordo: https://security.stackexchange.com/questions/127808/is-array-injection-a-vulnerability-and-what-is-the-proper-term-for-it nunca se me ocurriría probar algo así. lol.

Cual es el problema de que tengan el mismo tamaño? Qué indicas al atacante cual es el tamaño de la cadena original y el tamaño de la clave que tiene que probar? O cual? Yo creo que da igual una vez se rompa la correlación entre plaintext y ciphertext ya que pruebes lo que pruebes nunca sabes cual es el resultado correcto debido a que todas las combinaciones posibles. Es decir, un texto cifrado de 4 caracteres a descifrar te dará todas las palabras posibles de 4 caracteres, ya sea en español, inglés, etc.

PD: Pensando sobre la correlación podría usar 3 capas de cifrado al estilo tripleDes, pero sin necesidad de cambiar la clave por cada capa, ya que lo que importa es que no exista correlación para análisis estadístico. Se pueden hacer mucha cosas.

Leyendo parece que se esta hablando de un Verman (o algo asi porque deriva en este tema la barca hacia lados curiosos ). No se si se ha dicho ya, pero lo de usar claves igual de largas que el mensaje esta muy bien a nivel teórico pero no funciona a nivel práctico.
Verman ya mola y cualquier equivalencia usando ordenación o cualquier otra cosa similar esta bien pero ninguna de las opciones (verman original o derivados) mola tanto a nivel práctico. Como le tienes que pasar al receptor la secuencia de caracteres por una via segura, y es del mismo tamaño, Joder simplemente pásale el mensaje por esa vía segura.
Para que el cifrado sea util, el intringulis del asunto siempre está en lo mismo, conseguir pasar la pass simétrica, que debería ser pequeña, por un medio seguro dentro de un canal inseguro y que el mensaje que sale tenga suficiente entropia. Y ahi el poder de cómputo tiene al voz cantante.

Tal cual está ahora mismo es exactamente un Vernan. En Github tengo una implementación en PHP en la que explico exactamente esto. Que diseñando mi cifrado llegué a la misma conclusión y un diseño similar al de Vernan. En el PHP utilizo bloques de 7 bytes con diccionario de 127 caracteres. Coincido con todo lo que dices.

El tema está en el uso que se de al cifrado. Por ejemplo puedo mejorar la seguridad de una base de datos aplicándole el cifrado y por tanto la contraseña no necesita ser intercambiada. El problema que quiero solventar es el de la correlación para hacer el cifrado irrompible. Esto me permitiría operar con bases de datos alojados en servidores externos.

Uso práctico:
-Creo base de datos con datos de mi empresa.
-La cifro para poder hostearla en servicios externos y que no me suponga coste extra.
-Para operar descargo el archivo que desee. Lo descifro de forma local. Utilizo la información.
-Cifro con nueva contraseña al estilo One-Time-Pad y vuelvo a almacenar el contenido que utilicé en la base de datos.

Tienes un diccionario de 100 caracteres? Pues 100 combinaciones posibles para 1 valor.

no son un diccionario de 100 caracteres... son 16 rondas con un diccionario de 2¹²⁸ caracteres (cada vez diferente) ya que el hash no queda puro, se hacen 2 procesos luego con el... a demas aunque consiguieras alguna forma de retornar un hash a su valor original, y luego pudieras reversar las piezas del hash, ellas mismas están mezcladas con la data...


XD realmente revisaste como se hace un sha256 y que hace rijandel? (ojo aes no es 100% rijandel, es basado en)

entiendes como funciona la matematica en ese aspecto? XD en tal caso sería un algoritmo

tu algoritmo (si es el mismo que ya llevabas) va en camino a ser el de la maquina enigma...

antes de negarte estudia los algorimos, ve los puntos fuertes y debiles, a demas que puedes tomar de ellos... no puedes mejorar algo si no conocces los mejores... por otro lado aes no es el mas fuerte al igual que sha, solo son solidos matematica y algoritmicamente (justamente a lo que expones, ya que fue probado contra eso) y aplicables en logica pura electronica... pero tienes otros mucho mas fuertes en todo aspecto que no cumplieron las caracteristicas de velocidad y aplicabilidad

Yo te estaba hablando de mi algoritmo no de AES. Para usar Rijndael prefiero usar Serpent que es más seguro. Pero todos se basan en lo mismo.
Lo que te digo es que no tiene sentido que hashe la contraseña de mi cifrado porque el mismo depende de que el atacante no conozca la contraseña. Hashearla no sirve de nada.
Si conozco Rijndael, Serpent, DES, etc. Si conozco las propiedades matemáticas que dificultan el cálculo, si no, no haría un cifrado distinto.

En ciertos aspectos si tiene similitudes con Enigma. Por ejemplo se deben utilizar contraseñas distintas para cada cifrado. Uno de los mayores problemas que tuvo enigma fue que utilizaban una contraseña diaria, por lo que había días que los ingleses rompían el cifrado a primera hora de la mañana y podían obtener todas las comunicaciones en tiempo real de los alemanes para ese día. En mi caso el planteamiento se asemeja mucho a un One-Time-Pad (libreta de un solo uso). Con ajustes para eliminar la correlación del texto plano con el cipher text, la libreta de un solo uso es 100% irrompible. El mayor problema para su uso reside en el intercambio de claves y en que el cifrado guarda correlación. Utilizando un IV por cada cifrado generado y con algunos ajustes no sería extrictamente necesario cambiar la clave para cada cifrado. En la elección de Rijndael como estandar  aes había chanchullo ya que se uso hardware favorable y se priorizó velocidad sobre seguridad. Serpent era más seguro y en el propio hardware de la época la diferencia de velocidad era imperceptible. En cambio optaron por utilizar procesadores de pocos HZ para aumentar la diferencia de velocidad y así disponer de un cifrado que los gobiernos pudiesen romper.

no, existe probabilidad finita... ergo existe una potencial tal que...

y con la clave expandida por hash no? XD tu base es 8bit de largo en aes es 128 bits, aun así asumes que la tuya es imposible en base a computo...

por otro lado, recuerda que si el algoritmo es publico (y c omo programador sabes que a fin de cuentas siempre lo termina siendo asi sea a la fuerza) vienen los ataques estadisticos y allí es donde metodos con azar fallan porque a final de cuenta el azar es en la generacion pero si te dan cadenas continuas de unos o ceros van debilitando el algoritmo, por eso rijandel usa la tabla de intercambio estatica... porque la misma asegura que esto no pase...

No hace falta ni que el ordenador calcule. El algoritmo es tan simple que lo puedes calcular de cabeza. Tienes un diccionario de 100 caracteres? Pues 100 combinaciones posibles para 1 valor.
Cuando todos los algoritmos de uso frecuente se basan en capacidad de cómputo teórica... Puede que mañana se descubra una propiedad matemática que no se conocía, o una nueva forma de aplicar la tecnología y se puedan romper todos estos cifrados basados en que la capacidad de cómputo no es suficiente.

Muy buena pinta. Apuntados!

Yo tengo reportado algunos SQLi. Encontré bastantes usando Dorks con cse(custom search engines) de Google. Simplemente con la cadena mágica y también algunos metiendo comillas y guiándome por los errores de a base de datos. Pero los Blind SQLi ni que me maten, no los entiendo en absoluto. Entiendo el concepto pero no la metodología. Supongo que eso es práctica y ya.

Lo que más e encontrado son CSRF, supongo porque los entendí a la primera hace tiempo.

En el último año también he encontrado un montón de XSS de todo tipo. Sobre todo reflected.

Algunos de estos bugs en páginas de usuarios del foro. Siempre que veo algún link le suelo hacer pentest for fun.

Ando mirando también los poliglotas, hay cosas muy chulas.

Claro que es posible. Si yo cifro el texto "a" y el resultado es "b", si no sabes la clave que utilicé, jamás sabrás que cifré el texto "a". Es imposible aún con infinita capacidad de cómputo. Todas las posibilidades son igual de probables. Da igual que tengas infinita capacidad de cómputo.

DiccionarioEjemplo = "abcdefg";
a = 1, b = 2, ..., g = 7;
while (x > dicTamaño) DiccionarioEjemplo -= 7;
a + g = 8; /* a */
b + f = 8; /* a */
c + e = 8; /* a */
d + d = 8; /* a */
e + c = 8; /* a */
f + b = 8; /* a */
g + a = 8;/* a */

te recomiendo leer sobre como funcinoa rijandel (la base de aes) para no tener que depender de aleatorios... especialmente de aleatorios de "alto nivel"

No le veo mucho sentido hashear la password. Para eso cifro directamente con aes y no creo un cifrado.
No quiero que mi cifrado dependa de algoritmos que dada X potencia se puedan romper.