Continuando con la crónica de la BH Europa, un magistral Christopher Tarnovsky vino a presentarnos Hacking Smartcards, un trabajo de más de seis meses que ha comenzado a dar sus frutos durante este último mes y que ha expuesto en exclusiva para la Black Hat.

Para que todos nos hagamos una idea sobre que ha versado su trabajo o su impacto, comentar que en nuestra vida diaria vivimos con Smartcarts: monederos electrónicos, gestiones bancarias, soporte para albergar el certificado del DNI-e. Una Smartcard era uno de los dispositivos más seguros y donde fabricantes de tarjetas y entidades bancarias depositaban su confianza. Pues bien, este “monstruo” pensó lo que es obvio, en algún punto de la circuitería interna del chip existe un bus de datos donde la información viaja en claro antes de pasar al módulo de cifrado. Esta frase, que resulta muy fácil decir, es una tarea faraónica dado los millones y millones de transistores, puertas lógicas y buses que puede tener el integrado.

En el mundo existen prácticamente 3 fabricantes de estos tipos de tarjetas que implementan una unidad de proceso 6805 (ST), 8051 (NXP) o AVR (ATMEL). Su estudio ha sido orientado al fabricante INFINEON, aunque como él comentaba el ataque puede ser extendido a otros modelos. Las fases que ha seguido Christopher para llevar a cabo el Hack son:

Como era de esperar una de las conferencias de seguridad más importantes del mundo, la Black Hat, no ha defraudado en su vertiente europea. Un gran escenario, el Palau de Congresos de Catalunya, ha servido de perfecto telón de fondo para albergar a la crème de la crème de los profesionales de la seguridad mundial, es por eso que S2 Grupo no podía faltar. Nada más llegar, un dato aportado por la organización resulta a un servidor sensiblemente preocupante, la distribución de asistentes por países refleja un escaso interés por parte del auditorio español (empresas, entidades públicas, I+D) haci las seguridad y la protección de la información. Con una participación entorno a 500 personas, tan solo 28 españoles constaban como inscritos. Por el contrario colegas de la profesión con un importante número de horas de vuelo a sus espaldas el día anterior, como Estados Unidos, aportaban 58 asistentes. Vietnam, la India, Alemania, Argentina, Francia o Rusia hacían presencia de forma significativa.

El evento fue en su primer día inaugurado por Max Kelly, máximo responsable de seguridad del bien conocido portal social Facebook. Éste introdujo los valores de seguridad que son aplicados en su política y que muchos de nosotros en nuestras organizaciones deberíamos seguir. En primera instancia, según palabras de Max, Facebook persigue mediante su equipo legal a todo aquel atacante o intruso que realice acciones ilícitas contra sus sistemas, mediante la CAN-SPAM (15 USC 7701), Computer Security Fraud And Abuse Act (18 USC 1030) y evidentemente los Facebook’s Rights and Responsabilities. Para dar soporte a acciones técnicas se apoyan en la comunidad mundial de la seguridad White-Hats, analizando los ataques recibidos con el objetivo de conocer a tu enemigo. Por último hubo una frase de su presentación que debe incitar a la reflexión colectiva: Compliance isn’t security. Ahí queda eso.

Como entrantes, Joe Grand, presentador del programa de televisión de Discovery Channel Prototype This, presentó la charla Hardware is the new Software. Mientras los pentesters normalmente suelen dirigir sus acciones contra aplicaciones, servidores de correo o páginas web, el hardware es el gran olvidado. Joe comentó que hoy en día la preocupación por la seguridad a este nivel sigue avanzando en menor medida que la relativa al software, pudiendo comprometer los dispositivos mediante simples tipos de ataques que siguen funcionando desde hace años. Esto es debido a la escasa preparación en materias de seguridad de los diseñadores de hardware. Pero, ¿cómo adentrarse en este mundo? Entre otras, sugirió dos paginas donde fundamentalmente se puede adquirir material para ello, www.adafruit.com y www.makershed.com. Es necesario básicamente: ChipQuickSMD (kit de eliminación limpia de integrados), Picoscope (osciloscopio software), microscopio y un soldador claro.

Leía ayer en el blog de Jesús Pérez Serna que finalmente la Fundación Tripartita va a poner coto a las empresas que con las ayudas a la formación se dedican a realizar la adaptación de las empresas a la LOPD “a coste cero” [enlace directo], y al parecer hay bastante regocijo en el sector por ello. Esta situación me trae a la cabeza algo que leí o me contaron sobre la prohibición de vender foie de oca en algunos estados de los USA. Al parecer, los dueños de los restaurantes habían evitado esta prohibición regalando el preciado alimento, y cobrando una barbaridad por el pan. No sé si ven por dónde voy. Es difícil evitar que dentro de unas sesiones de formación una empresa “regale” un proyecto de adaptación a la LOPD. Pero ya lo veremos.

Quizá estén preguntándose: ¿cuál es el problema de las LOPD “a coste cero”? Pues el problema tiene principalmente dos vertientes: una más fácil de vender, y otra menos. La primera es evitar el fraude, palabra que en estos tiempos suena peor que nunca; si las subvenciones de la Fundación Tripartita son para la formación de los trabajadores, no es de recibo, ni ética ni legalmente que ese dinero se utilice para adaptar la empresa a la LOPD, porque es obvio que el beneficiario de las ayudas en ese caso no es el trabajador. La segunda, y aquí es donde viene la parte que es posible que levante algunas ampollas, es evitar el intrusismo por la vía del corporativismo y el “sindicalismo” mal entendido. El mismo propósito persiguen las certificaciones que se están promoviendo recientemente relacionadas con la protección de datos, pero de eso les prometo que hablaré otro día. Volvamos a lo nuestro.

La esteganografía —del griego steganos (oculto) y graphos (escritura)—, en términos informáticos, es la disciplina que estudia el conjunto de técnicas cuyo fin es la ocultación de información sensible, mensajes u objetos, dentro de otros denominados ficheros contenedores, normalmente multimedia: imágenes digitales, vídeos o archivos de audio, con el objetivo de que la información pueda pasar inadvertida a terceros y sólo pueda ser recuperada por un usuario legítimo.

A lo largo de la historia, se ha demostrado que la esteganografía ha estado presente desde antes del siglo XV y se encuentra en constante evolución. Ejemplos tales como la escritura con “tinta invisible” fabricada con vinagre, zumo de limón, leche, etc., o la ocultación de mensajes en libros como Sueño de Polífilo escrito por Francesco Colonna en el 1499, en el que se puede obtener la frase ‘Poliam frater Franciscus Columna peramavit‘ (’El hermano Francesco Colonna ama apasionadamente a Polia’) si se toma la primera letra de los treinta y ocho capítulos, ponen de manifiesto la presencia de la esteganografía en nuestro entorno desde tiempos antiguos.

Las técnicas esteganográficas han ido evolucionando de manera acorde al desarrollo tecnológico, y así por ejemplo durante la Segunda Guerra Mundial se utilizaban los periódicos para el envío de señales ocultas mediante la realización de marcas en ciertas letras, que aunque por si solas pasaban inadvertidas en conjunto trasmitían una información. Este ejemplo es una muestra de los sectores en los que habitualmente la esteganografía ha estado más presente, y que como podéis imaginar son el entorno militar, agencias de inteligencia o espionaje entre otros.

Existe una regla no escrita de la seguridad (como todas las demás) que dice que no se deben repetir contraseñas en diferentes sitios, servicios, cuentas de correo y demás. Es una de esas “normas” que nos gusta recordar de vez en cuando, y que hasta hace unos años era relativamente sencilla de cumplir.

Con poca memoria que tengan en esto de la informática, recordarán que hace menos de una década el número de claves que un usuario normal tenía que recordar se limitaba a una cuenta de correo o a lo sumo dos, y algún foro. Poco más; no hacía falta demasiada memoria para ello. Pero un buen día empezaron a surgir los foros, la web 2.0, y hoy en día cualquier persona que haga un uso habitual de Internet dispone de usuario en más de una docena de servicios y sitios diferentes: Facebook, Google, Hotmail, Tuenti, Delicious, Twitter, Ebay, Amazon, LinkedIn, Xing, Wordpress, GoDaddy, Meetic, Menéame, Flickr, etc. Ahora súmenle dos o tres foros, páginas de descarga de contenidos digitales, páginas de venta online, y sitios a los que acabamos accediendo un puñado de veces pero para los que solemos crear una cuenta de usuario, y tenemos una veintena de cuentas diferentes, y bastantes más en el caso de personas que hagan un uso “intensivo” de la red.

Hoy vamos a introducirnos en el fascinante mundo de las ACL (Access Control List) en Linux. En este punto ya habrá alguien que piense que eso es más viejo que el mismo Unix, pero mucha gente, entre que los que me incluyo, no tenia ni idea de que existían las ACL en Linux, y menos cómo usarlas. Empecemos, como siempre, con un poco de teoría cortesía de la Wikipedia:

Así pues, las ACL nos permiten determinar si una entidad puede acceder o no a un objeto, y qué acciones puede realizar contra dicho objeto. Bien, hasta aquí suena exactamente igual que los típicos controles de acceso de Linux, y es normal, dado que la instancia mas simple de una ACL son los permisos habituales de propietario/grupo/otros que tan bien conocemos. La diferencia radica en que con las ACL se puede hilar mucho más fino, especificando varios grupos y usuarios y detallando para cada uno sus permisos específicos.

Llegamos con esta entrada al ecuador de la lista de OWASP, tras el repaso a las cuatro primeras vistas en entradas anteriores (I, II, III, IV). En esta ocasión, el artículo del top 10 del catálogo de vulnerabilidades de OWASP del año 2010 se basa en el riesgo conocido como Cross Site Request Forgery, CSRF, que en castellano tiene la difícil traducción que podemos leer en el título de esta entrada. Este riesgo no aparecía recogido en la lista del año 2004, sin embargo en 2007 apareció en quinto lugar, posición que mantiene en esta nueva clasificación de riesgos del año 2010.

Las vulnerabilidades relacionadas con la falsificación de petición en sitios cruzados permiten a un atacante la posibilidad de enviar una petición a una aplicación Web vulnerable ejecutando una acción a través de la víctima. Veamos el siguiente ejemplo como demostración del tipo de situaciones en las que podemos encontrar un ataque de este tipo. Sea una aplicación que dispone de un frontal web, en el que un usuario autenticado dispone de un conjunto de puntos bonificables que puede transferir a otros usuarios de la propia aplicación a través de un formulario que ejecuta una acción del siguiente tipo:

Una vez recibida en el servidor, se le muestra la cantidad a transferir, el identificador del usuario y realiza el traspaso de puntos.

De vez en cuando surgen noticias -casi siempre, muy sensacionalistas- acerca de nuevas medidas de seguridad que suponen una “importante” violación de nuestra privacidad: desde la videovigilancia en las calles (un lugar especialmente privado por definición :) hasta la necesidad de descalzarnos en los aeropuertos (desde luego, una humillación a la que sólo unos pocos sobreviven). Qué quieren que les diga: frente a los que claman al cielo, yo suelo estar de acuerdo con estas medidas. ¡Toma GOTO! :)

Maticemos en primer lugar el “suelo estar”; mi opinión es que casi cualquier medida que aporte seguridad suele tener inconvenientes de uno u otro tipo, pero si “compensa” (es decir, si el incremento de seguridad efectivo es superior a las molestias causadas por esos inconvenientes) y entra dentro de lo “normal” (de lo razonable, aunque esto suela ser subjetivo), vale la pena implantarla. ¿Qué problema hay entonces? Bajo mi punto de vista, la discusión habría que trasladarla a tres asuntos: el primero, el de la eficacia -no me atrevo a hablar de eficiencia- (si la medida aporta realmente seguridad); el segundo, el del grado de abuso (el mal uso o abuso que se pueda hacer de la información recopilada con fines que nada tienen que ver con su objetivo principal, como espiar a tu pareja, curiosear, molestar al vecino, chantajear…) y, el tercero y último, el de la aceptabilidad, esa normalidad subjetiva a la que hacía referencia.

Si recuerdan el post sobre XSS de la serie que explica las vulnerabilidades TOP 10 en aplicaciones web de OWASP de este año, en éste les comentábamos los potenciales problemas de seguridad que podían enmascararse con el uso de los extendidos servicios de reducción de tamaño en las URL. Si todavía hoy alguien no los conoce, estos servicios se encargan de reducir el tamaño de una URL determinada a una nueva URL con una longitud predeterminada e inferior, en la que se mapea el enlace de forma que pueda ser utilizado en servicios como twitter que tienen un número limitado de caracteres; el incremento de popularidad de esta “nueva” red social ha hecho que este tipo de servicios se multipliquen como las setas. De esta manera, se facilita el incorporar enlaces largos en entradas de este tipo de servicios.

A modo de ejemplo, una url del tipo:

Se traduce con uno de estos servicios en:

(N.d.E. Para aquellos que no pueden vivir sin Internet durante las vacaciones —aquellos que las tengan—, aquí va una entrada sobre la securización de DMZ)

Generalmente, la arquitectura de seguridad de red en pequeñas empresas se basa en un elemento central de filtrado, habitualmente un firewall, y distintos segmentos de red conectados a él, principalmente, un segmento de red interna y un segmento DMZ para alojar servidores corporativos. En el caso de una empresa de tamaño medio o grande, la situación es bastante similar: uno o varios firewalls en alta disponibilidad separando distintos segmentos de red, aunque disponen de otros controles como NIDS, IPS, sistemas de monitorizacion, etc, y técnicos dedicados a la gestion de la seguridad.