elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.

 

 


Tema destacado: (TUTORIAL) Aprende a emular Sentinel Dongle By Yapis


  Mostrar Temas
Páginas: [1]
1  Seguridad Informática / Seguridad / mitigar ataque Ddos htaccess en: 7 Diciembre 2016, 16:00 pm
Hola,
Se que es un tema muy extenso y no basta con  htaccess para hacer frente a un ataque DDOS pero como dice el titulo intentar mitigar

Mi idea es la siguiente:
Poner una denegación en htaccess si una ip se conecta mas de un numero de veces en un lapso de tiempo.

Código
  1. Order Deny,Allow
  2. Deny from xxx.xxx.xxx.xxx
  3.  


En mi proyecto tengo todo redireccionado a mi index.php a traves de htaccess
Código
  1. RewriteCond %{REQUEST_FILENAME} !-f
  2. RewriteCond %{REQUEST_FILENAME} !-d
  3. RewriteRule ^(.*)$ /index.php?otras_variables=$1 [NC,L,QSA]
  4.  

Para index.php he encontrado una solucion con esta libreria:
https://github.com/damog/planetalinux/blob/master/www/principal/suscripcion/lib/antiflood.hack.php
Que hace exactamente lo que yo quería (si alguien se conecta mas de lo establecido,  le manda un aviso que esta bloqueado y no sigue con la ejecución de los scripts).
Este script ya puedo modificarlo de tal manera que en vez de aviso lo pongo en una lista negra por htacces.

Ahora el problema es con los imagenes porque si alguien pide directamente una imagen
ej: https://mi_sitio.com/carpeta_imagenes/mi_imagen.png
Por un lado es un recurso valido (osea he dado permisos para .png en mi htaccess)
Pero por otro lado, como esto no pasa por index.php, ya no sirve el conteo que tengo en index.php con la librería "antiflood.php" que puse arriba.

Se también que habrán otros recursos .js .css etc ... pero por lo menos si alguien puede darme alguna pista para los imágenes ... el resto supongo que lo podre hacer por analogía.

Saludos y gracias
2  Seguridad Informática / Criptografía / Algoritmo inscripcion autenticacion en: 20 Noviembre 2016, 23:58 pm
Hola,

Después de muchísimas vueltas y reflexionando sobre los consejos que me dio kub0x en mis post anteriores  he pensado en el siguiente algoritmo de autenticación:

Inscripción:
  Cliente:

    - Escoge un nombre usuario
    - Proporciona su numero de teléfono móvil
    - Envía estos datos


 Servidor:
    - Crea una tarjeta de coordenadas con 20 de coordenadas aleatorias (como
      sugirió kub0x números entre 10.000 y 99.999)
          A      B     C    D
      1  --     --    --    --
      2  --     --    --    --
      3  --     --    --    --
      4  --     --    --    --
      5  --     --    --    --
           Escoge 3 de ellas al azar.
      Ej: A3,C5 y D4 (12345, 99876, 68872 )
      
      Suma los numeros pertenecientes a cada coordenada entre si
      A3 = 12345 = 1+2+3+4+5 = 15
      C5 = 99876 = 9+9+8+7+6 = 39
      D4 = 68872 = 6+8+8+7+2 = 31
      
      Concatena estos resultados en una variable "$base"
      $base = "153931";
      
    - Escoge 1 color al azar de los 7 básicos del arco iris
   
    - A cada color corresponde un array aleatorio de números   
   Ej: $rojo = [4,0,3,1,2,5] donde cada elemento del array representara la posición
       dentro de "$base"
      
    - Emplea este array como algoritmo para alargar la "base" para emplearlo como
       passphrase
      
   Ej: $rojo[0] = 4 representara el quinto elemento de $base (empezando con 1)
        que seria en este caso el 3
   entonces hace 153931 ^ 3 = 3647356987253491 y lo concatena como string en
        una variable $passphrase
      etc ... etc ver ejemplo PHP abajo      
      En el ejemplo he utilizado potencias ... pero se podrá usar lo que uno quiere
      
Código
  1. $passphrase = '';
  2. $base = "153931";
  3. $algoritmo = [4,0,3,1,2,5]; //$rojo
  4.  
  5. foreach($algoritmo as $posicion){
  6. if($base[$posicion] == "1"){
  7. $exponent = "10"; //para no dejarlo a la potencia 1
  8. }else{
  9. $exponent = $base[$posicion];
  10. }
  11. $passphrase .= bcpow($base,$exponent);
  12. }
  13.  
  14. //lo que daría como resultado la passphrase siguiente:
  15. //36473569872534917468973308479888166911376979002445509842001282099801485215668609954341030161369639802607001968497718642322204407729767913865136473569872534917468973308479888166911376979002445509842001282099801
      
      
      Esta sera la passphrase "P"   para ser empleada en el cifrado simétrico    
      36473569872534917468973308479888166911376979002445509842001282099801485215668609954341030161369639802607001968497718642322204407729767913865136473569872534917468973308479888166911376979002445509842001282099801
      
        Envía al usuario por SMS la tarjeta de coordenadas + La referencia a una de las tres coordenadas empleadas mas arriba ej: D3 y el color ej: rojo (verán mas abajo en la autenticación porque D3 y no D4 que se utilizo realmente )
      
   Lo que el usuario tendrá que memorar seria "D3" y "rojo" ... la tarjeta de coordenadas la imprime o la apunte (de todos modos aconsejado que la borre del móvil)
      
   En el servidor se guarda:
   Un hash (sha3) sobre la passphrase "P"
   La tarjeta de coordenadas y los datos del usuario cifrados (simétrico) usando la passphrase "P"
   Dos referencias a las coordenadas de la tajeta Ej: A3 y D4 (para este caso)
   Y un numero de referencia de 1 a 20  en vez de la tercera coordenada ej: 1 (verán mas abajo en la autenticación porque 1 en el caso actual)
   Guarda también el color que escogió (o un hash)
      
   Enviara al administrador la passphrase P cifrada con otro algoritmo (parecido  al de arriba) y este lo guardara en una maquina sin conexión a internet + otras medidas de seguridad (para comprobar manualmente en caso de perdida).      
      
      
      
      
Autenticacion:
   Cliente:

    - Introduce su nombre usuario
   
   Servidor:
    - Si el usuario es correcto    
    - Le pide escoger su color (que memorizo)
    - Si el color es correcto le manda el algoritmo utilizado Ej: $rojo = [4,0,3,1,2,5] ,
           las dos coordenadas que se usaron para construir la passphrase mas un numero explicado mas abajo
    - S le pide que sume de memoria (o en papel ideal seria que si lo suma en una calculadora que no sea la del  aparato con el que se esta conectando a internet)
   Normalmente no seria tan difícil sumar 5 números de memoria
   y apuntar solo el resultado en la casilla correspondiente (y no el valor de la coordenada)
   Ej:
   A3 = 12345 = 1+2+3+4+5 = 15
   C5 = 99876 = 9+9+8+7+6 = 39
      
   Para la tercera referencia (Que se supone que memorizo al inscribirse y recibio D3 en vez de D4 que se utilizo realmente )  solo recibe el numero 1
   Entonces se le pide a que al la coordenada que memorizo (D3) le suma 1 (en este caso ) lo que le dara D4 y que haga la suma como en las de arriba y apunte el resultado en la casilla
      
   secreto +1 = D3 +1 = D4 = 68872 = 6+8+8+7+2 = 31   
       (llamaremos secreto a la referencia D3 que el usuario tendra que memorizar)
      
   Si el secreto era D5, entonces D6 no existe (porque solo hay 20 coordenadas) y el siguiente sera A1 (algo parecido a los módulos) empezar desde el principio
   o si el numero que recibe el usuario sera mas grande por ej. 10 y el secreto es D3 entonces la coordenada correcta seria B3
   O sea si contando desde su secreto el nr que recibe llega al final D5 ... continua con el A1 A2 etc
       Ej:
       D5 + 1   = A1
       D3 + 6   = A3
       D3 + 10 = B3 ... etc

      
   El resto se hace automáticamente en el lado cliente y se regenera la passphrase P
   la cual se puede primero comprobar con su hash y si esto es ok se autentifica y se  desencriptan sus datos
      
   Si la autenticación es OK el servidor genera otros credenciales para la siguiente autenticación
   También controla la sesión en curso con combinaciones de tokens + tiempo + la passphrase correcta que no se utilizara otra vez para login
      
      
      
Resumiendo:


   - El usuario solo tendrá que memorar Un color (ej: rojo) y dos dígitos  ej: D3 (y no el contenido de la coordenada.  Solo la referencia)
   - Si alguien intenta mandar su usuario y su color pero no llega autenticarse se le notificara al usuario y si las dos coordenadas pedidas son correctas, (pero no la secreta) se pregunta al usuario y si no ha sido el, se le cambia la tarjeta de coordenadas obligatorio
   - La passphrase no se guarda en ningún lado (eventualmente el administrador las guarda en otra maquina con otro cifrado y sin conexión a internet para recuperación y comprobación de los datos manualmente en caso de perdida)
   Se le puede pedir al usuario al principio si acepta esto ... pero si no acepta ... pierde todo si se pierde la tarjeta de coordenadas o se olvida la que tiene como secreta
   - No revela los números de las coordenadas que tiene
   - La coordenada que tiene secreta siempre es otra (Aunque el memoriza la misma siempre)
   - Aunque se le robe la tarjeta de coordenadas no se podrá saber cual es la secreta (bueno ... digamos ... bastante difícil)
   - Siempre que se ha conectado de otra maquina se le avisa
   - No habrán nunca dos sesiones permitidas al mismo tiempo
   - Esto si, tiene que hacer unas sumas simples de memoria ( Eso le tendrá el cerebro entrenado :D )
   
   
   
   Bueno dicho esto, como muchas cosas, en teoría parece bien pero con mis escasos conocimientos de matemática no se si esto seria un sistema fiable por esto espero sus opiniones
   
   
   Cada paso se puede complicar de varias formas pero espero primero vuestras opiniones, criticas , mejoras ,puntos debiles etc.
   
   Como duda mas grande que tengo por ahora: ¿es la passphrase P fuerte desde el punto de vista criptografico ? (se pasa tambien por pbkdf2 )
   He olvidado decir :
   Para el cifrado simétrico he pensado en el AES-256 CBC siguiendo los consejos de @kub0x:
   Salt e IV aleatorios,
   pbkdf2 con iteraciones diferentes por cada algoritmo, usuario y autentificacion para la  "passphrase" ,
   cifrado AES-256 CBC padding: Pkcs7 ,
   hmac para el control de integridad
   
   
   Saludos y espero vuestras opiniones
      
      
      
      
      
      
      
3  Seguridad Informática / Criptografía / Duda secreto compartido Shamir en: 14 Noviembre 2016, 15:19 pm
Hola,

Estoy trabajando en un proyecto donde quiero tener un segundo factor de autenticación.
En un principio pensé en una pasarela SMS pero como casi seguro al principio no voy a ganar nada .... esto va a superar mis posibilidades financieras.

Así que la idea es emplear solo una vez para inscripcion un SMS y luego una tarjeta de coordenadas (estilo A1 = xxxx , A2 = yyyy etc )

Despues de mucha lectura ... encontre el "sistema de compartición de secretos de Shamir" que parece bastante robusto.

La idea que me surgió es la siguiente:
1. Emplear algún padding para no revelar la longitud de la clave ( el secreto )
Incluso, dicho padding, poder personalizarse para cada usuario con algo fácil a memorizar ( un color una foto etc )

Problema: Dicho secreto compartido sera difícil de memorizar o de escribir por el usuario (supongamos que con el padding lo aumentamos hasta 1024 bits o mas

Lo que he pensado es:  generar aleatoriamente dicha tarjeta de coordenadas que van a ser las coordenadas x e y de la gráfica del algoritmo de Shamir.

Entonces al usuario se le pide su contraseña mas dos coordenadas de su tarjeta (eventualmente mas una cosa para el padding) ... se pasa esto a una función js en el lado cliente y se envía al servidor una parte del secreto compartido ( el servidor teniendo la otra parte )

Mi pregunta es:
¿Supone esto (lo de las coordenadas en la tarjeta) alguna vulnerabilidad al sistema de Shamir? ( descartando que si le roban la contraseña y la tarjeta etc)

Saludos y Gracias
4  Seguridad Informática / Criptografía / [SOLUCIONADO] aes decrypt php en: 26 Julio 2016, 09:46 am
Hola,

Hace unos dias @kub0x me ayudo a entender ciertas cosas ( que desconocia sobre el cifrado ). El asunto era sobre CryptoJS AES  http://foro.elhacker.net/criptografia/dudas_con_iv_y_salt-t455043.0.html

En javascript hice las modificaciones que me aconsejo @kub0x es decir :

  - salt y IV aleatorios
  - generar una key en base al dicho salt y my passphrase con pbkdf2
  - cifrado AES CBC padding: Pkcs7
  - hmac para el control de integridad
  - convertidos a json chiper_text IV y salt y enviarlos al servidor

En PHP
  - descodificar json con json_decode()
  - pasar el salt y el IV por hex2bin()
  - regenerar la key con hash_pbkdf2()

y aquy me he quedado atascado. (por lo menos he comprobado que la key regenerada cpn hash_pbkdf2() en PHP es la misma que tenia en javascript )

El ejemplo menos seguro que tenia empleaba openssl_decrypt() para descifrar y despues de mucho darle la vuelta vi que openssl no accepta key-s hechas con pbkdf2

he intentado con mcrypt_decrypt(); y no me funciono ... tampoco se cual seria la equivalencia del Pkcs7 para mcrypt_decrypt() ya que este tiene MCRYPT_RIJNDAEL_128
he intentado tambien con MCRYPT_RIJNDAEL_256

En js tengo esto
Código
  1. var texto_plano = "texto plano";
  2. var passphrase = "clave secreta";
  3. var salt = CryptoJS.lib.WordArray.random(16);
  4. var iv = CryptoJS.lib.WordArray.random(16);
  5. var key = CryptoJS.PBKDF2(passphrase, salt, { hasher: CryptoJS.algo.SHA512, keySize: 4, iterations: 1 });
  6. var encripted = CryptoJS.AES.encrypt(texto_plano, key, {iv: iv});
  7.  
  8. var cp = {};
  9. cp.ct = CryptoJS.enc.Base64.stringify(encripted.ciphertext);
  10. cp.s = CryptoJS.enc.Hex.stringify(salt);
  11. cp.iv = CryptoJS.enc.Hex.stringify(iv);
  12. cp = JSON.stringify(cp);
  13.  

y en php: EDITADO PARA SER MAS CLARO

Código
  1. $passphrase = "clave secreta";
  2. $ct = base64_decode("UCWtekP0i5nAKf+xWOMdbA==");
  3. $salt = hex2bin("663b7713dffd2c32583c55cad92746bc");
  4. $iv = hex2bin("ac344b6013bbaa84e001d3324521e10d");
  5.  
  6. $key = hash_pbkdf2("sha512", $passphrase, $salt, 1, 32);
  7. $data = mcrypt_decrypt(MCRYPT_RIJNDAEL_128, $key, $ct, MCRYPT_MODE_CBC, $iv);
  8.  
  9. $js_key = "ad5db505d7f47a223181388d90d511ff";//solo para comprobar si son iguales
  10.  
  11. echo "$js_key <-> $key <br>$data ";
  12.  

Despues de intentar mas y mas cosas he editado y he copiado lo que me generaba CryptoJS  para que quede mas claro:

Ahora mis dudas van por este camino:

1. ¿Es correcto usar en PHP hext2bin() para el IV? (ya que en el manual de PHP indica string para mcrypt_decrypt )

2. ¿Que algoritmo seria correcto MCRYPT_RIJNDAEL_128 o 256? ( segun he leydo por aquy seria 128 el equivalente para AES 256 )

3. ¿Como se puede resolver la diferencia del padding? ( en CryptoJS puse Pkcs7 ... dicen que es mas seguro ... pero MCRYPT emplea zeropadding)

Encontre en el manual de PHP esto pero no se como adaptarlo a mi situacion:
Código
  1. $decrypted = mdecrypt_generic($td, base64_decode($enc_auth_token));
  2. $dec_s = strlen($decrypted);
  3. $padding = ord($decrypted[$dec_s-1]);
  4. $decrypted = substr($decrypted, 0, -$padding);
  5.  

Supongo por logica que el salt y el key generados por pbkdf2 son correctos ya que son iguales en js y en PHP


Gracias

[SOLUCIONADO] ultima edicion.

Al final lo resolvi con openssl_decrypt();
Código
  1. $data = openssl_decrypt($ct, 'aes-256-cbc', hex2bin($key), OPENSSL_RAW_DATA, $iv);

El error que hacia es que ponia la key como string y por esto no functionaba.

Tambien tuve que incrementar la longitud de clave a 64 ( o sea con los datos que puse  al principio no funciona ... tuve que generar otras).
No se si soporta mas grande de 64 (intentare ahora) ... incrementare tambien las iteraciones que deje solo 1 para las pruebas.

No se si alguien tiene otra solucion para mcrypt_decrypt() bienvenida sea pero yo lo marco como solucionado ya que es esto que buscaba descifrar de alguna manera en PHP.

Saludos
 
5  Programación / Desarrollo Web / javascript seguridad eval en: 25 Julio 2016, 00:00 am
Hola,

Ya he leído por todos los lados lo del "eval es evil" etc ... aunque la mayoría se resumen a decir que es malo pero no argumentan el porque.
Investigando mas y mas encontré también explicaciones como:
"que se puede ejecutar codigo arbitrario o de terceros".

Todavía estoy en fase de experimentos y he pensado en una minificacion javascript
De los que he probado me gusto UglifiJS2 http://lisperator.net/uglifyjs/
Pero me di cuenta que si empleo el packer http://dean.edwards.name/packer/
la minificacion es mucho mas efectiva ( sobre todo si antes de minificar voy a reunir todos los script en un unico fichero ) ya que el packer minifica todas las palabras que se repiten dentro del código ... incluido propriedades css ... palabras reservadas del proprio javascript ... etc ... o sea todo.

Lo que pasa con packer es que para restaurar los script en el cliente emplea eval()

Entonces mi pregunta seria:
¿Si empleo un chequeo de tipo suma hash antes del eval, reduce este el riesgo de seguridad que supone dicha "function del diablo" :D ?

Igual para los scripts recibidos como JSON la misma pregunta de antes.

Gracias

P.D.
Del lado servidor tengo:
https (TLS)
en apache securizando cabeceras (entre otras):
Código
  1. Header always set X-Frame-Options "SAMEORIGIN"
  2. Header always set X-Xss-Protection "1; mode=block"
  3. Header always set X-Content-Type-Options "nosniff"
  4. Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
  5.  

saneadas todas las variables de entrada (3 filtros )

6  Seguridad Informática / Criptografía / Dudas con IV y salt en: 12 Julio 2016, 21:15 pm
Hola,

Encontré por la web una librería javascript CryptoJS y quiero emplearla en un proyecto pero como no se muchas cosas de criptografia por esto pongo aquí mis dudas.

Hice pruebas y pude cifrar en el cliente con CryptoJS AES256 y escogiendo una passphrase la libreria genera IV y salt aleatorio.

La passphrase no se envia por la red sino via SMS

Pero el mensaje cifrado (chipertext) el  IV y el salt debo enviarlos por la red ( con https ) para poder desencriptarlo al otro lado.

Mi primera duda es la siguente:
¿compromete mucho la seguridad si un supuesto atacante ( aunque sea por https) accede al IV y al salt  sin tener (teroricamente al menos) acceso a la passphrase que va por otra via ?

La segunda duda:
¿Una passphrase de aproximadamente 100 caracteres sera razonablemente fuerte ?

Gracias

P.D
Estoy consciente que no existe seguridad 100% ... solo busco que sea bastante fuerte



A no ser que no he entendido bien ... despues de investigar un poco mas sobre el asunto, dicen por ahi que el IV y la sal son publicos ... y que lo que tiene mas importancia es la aletoriedad de los mismos.

asi que mi primera duda cambiaria en:

¿como puedo probar la calidad de la dicha aletoriedad?

La libreria de la cual dije en el principio es esta :
https://github.com/brainfoolong/cryptojs-aes-php

MOD EDIT: No hacer doble post.
7  Seguridad Informática / Seguridad / ¿Man in the middle ? en: 9 Julio 2016, 18:45 pm
Hola,

He visto por internet una manera de comprobar si hay alguen en el medio con tracert

Hiciendo tracert google.es  me salio:
 en primer lugar
192.168.1.1 que es el ip de mi ruter
en segundo lugar
192.168.144.1 que no se que es
luego lo de telefonica (unos cuatro ip-s) algo genero:
xxx.red-xx-xx-xx.staticip.rima-tde.net
y luego lo de google


Mi duda es con esta segunda ip 192.168.144.1 que no es de mi ordenador ( ademas esta en otro rango)
¿Es esto un man in the middle?

Gracias
Páginas: [1]
WAP2 - Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines