Bajo el Radar: [PDF, 2167 kB] - Linux Magazine

PORTADA Evitando Detección
Técnicas para sortear los sistemas IDS e IPS
Las herramientas de detección de intrusos tipo Snort sirven de ayuda a la hora de seguir el rastro a los intru-
sos, pero no debemos sentirnos demasiado cómodos. Mostraremos algunas de las técnicas y herramientas
usadas por los atacantes para evitar que sus intrusiones sean detectadas.
POR KURT SEIFRIED
Acabamos de instalar y configurar
nuestro sistema de detección de
intrusos con la intención de proteger
nuestra red frente a ataques, y ya
estamos listos para empezar a recibir
alertas que nos informen sobre cualquier
actividad que parezca mínimamente sospechosa
¿Estamos ya seguros? ¿De verdad
lo creemos? Los expertos en seguridad
invierten mucho tiempo y dinero
estudiando técnicas que les permitan
evadir los sistemas de detección de intrusiones
(Intrusion Detection System o
ISD) porque saben que los atacantes
están ahí afuera haciendo exactamente
lo mismo.
Las herramientas IDS e IPS (sistemas
de prevención de intrusiones, o Intrusion
Prevention Systems en inglés) no carecen
de problemas. Los sistemas de detección
de intrusiones basados en host
(HIDS) deben ser instalados y ejecutados,
como su nombre indica, en el host
que deseamos controlar. Esto estaría
muy bien si tuviéramos el control total
del equipo y pudiéramos instalar nuestro
sistema HIDS en él. (Buena suerte al
intentarlo con todas las impresoras
conectadas a la red, los escáneres, las
fotocopiadoras, los sistemas punto de
venta, los escáneres inalámbricos para
inventariado, etc.)
Cuando se trabaja en redes con
muchos equipos, los administradores
suelen desplegar herramientas IDS basadas
en red. Estos sistemas incorporan
sofisticados mecanismos de prevención
de intrusiones (IPS) capaces de abortar
ataques, por ejemplo, enviando paquetes
TCP de reinicio para cerrar las conexiones
problemáticas.
Por desgracia, incluso estas herramientas
de detección de ataques de nivel
empresarial pueden plantear alguna que
otra complicación. Por ejemplo, el bloqueo
del ataque puede llegar demasiado
tarde para que sea realmente efectivo;
los sistemas IPS tienen que estar normal-
22 Número 69 WWW.LINUX- MAGAZINE.ES
mente en línea para que puedan bloquear
los ataques antes de que consigan
pasar, o bien tienen que ser algo más
agresivos en el bloqueo de tráfico
“malo”.
Ambas soluciones llevan asociadas
nuevos problemas – la primera alternativa
introduce una latencia y un punto de
fallo adicional en nuestra red, mientras
que la segunda produce falsos positivos
que pueden bloquear el tráfico web legítimo.
Los atacantes con experiencia pueden
aprovechar estos problemas para colarse
dentro de la red de seguridad. En este
artículo repasaremos algunas de las
herramientas y técnicas que suelen usar
para seguir ocultos incluso de los IDS
mejor configurados.
Evasión vs. Ataque
Los intrusos disponen básicamente de
dos opciones cuando quieren permanecer
ocultos. Pueden esconderse usando
© piai - Fotolia.com

técnicas de ocultación, o bien pueden
intentar enmascarar sus actividades creando
algún tipo de encubrimiento (como
el caso del hombre que contrató un montón
de señuelos usando Craigslist [2] con
el objetivo de robar un furgón blindado).
En general, esconderse suele funcionar
mejor que enmascarar, especialmente
frente a los sistemas IPS que bloquean
ataques – claro está, a menos que deseemos
atacar al sistema IDS de forma
(in)directa inundando al administrador
con mucha información (no hay nada
como pasar de 100 alertas diarias a 100
alertas por minuto).
Básicamente, estas estrategias pueden
reducirse a dos alternativas: o bien nos
ocultamos entre las sombras para poder
fisgonear, o bien creamos algo parecido a
una estampida de ganado y vamos tras
ellos aprovechando el ruido y el descontrol
generado.
Alteración de Paquetes
La modificación o alteración de paquetes
constituye una técnica clásica para la
evasión de sistemas IDS e IPS, y por clásico
nos referimos a 1998. Primero se
publicó Fragrouter [3], al que luego le
siguió Fragroute [4] (observe la “r” que
falta). El Fragrouter original disponía de
un número reducido de opciones – principalmente
relacionadas con el particionamiento
de datos en fragmentos de 8,
16 y 24 bytes, con opciones para duplicar
paquetes y enviarlos de forma desordenada
(lo que en 1999 era más que suficiente
para sortear muchos sistemas
IDS). Naturalmente, la mayoría de los
desarrolladores de IDS corrigieron sus
productos, por lo que los autores de Fragrouter
se vieron obligados a mejorarlo,
hasta transformarlo en Fragroute. Fragroute
funciona como un proxy a nivel
de red; toma un flujo de paquetes TCP
correctamente formados y los altera de
tal forma que hace tambalear algunos
equipos y sistemas IDS.
Fragroute puede retener, eliminar y
duplicar paquetes (tanto el primero, el
último, como cualquiera escogido al
azar), creando “basurilla” con niveles
diferentes de carga, opciones IP no válidas
y valores TTL modificados. De
manera alternativa, puede fragmentar
paquetes en tamaños arbitrarios, añadir
opciones IP y modificar los valores ToS
(tipo de servicio o Type of Service en
inglés). Si de verdad queremos hacer la
vida miserable a
los sistemas IDS
más frágiles,
podremos reordenar
los paquetes
de forma aleatoria
o en orden inverso
(lo que podría
saturar los buffers disponibles en el IDS
para el almacenamiento y reensamblado
de datos). Básicamente, con Fragroute es
posible generar cualquier cosa defectuosa
que aún puede ser considerada
como dato y que un equipo puede reestructurar
y procesar.
Los intrusos también pueden usar el
escáner de seguridad Nmap (Figura 1)
para fragmentar paquetes. Nmap nos
permite establecer un MTU pequeño
(unidad máxima de transmisión, o Maximum
Transmit Unit en ingles). Para
divertirnos podemos probar un MTU de
“1” (un byte de datos para cada paquete
TCP); aunque esto produce una transmisión
muy lenta y conlleva un enorme
consumo de ancho de banda, resulta sorprendente
ver con qué frecuencia tumbamos
(o como poco tambaleamos) a los
servidores remotos y los sistemas IDS/
IPS escaneados.
Disponemos además de otras técnicas
también clásicas de alteración de paquetes,
como enviarlos con sumas de comprobación
incorrectas, o modificar aleatoriamente
algunos de los bits de la
cabecera (activando, por ejemplo, los
campos para paquetes urgentes entre
otras opciones TCP). Podemos usar
herramientas como hping [5] para generar
paquetes completamente personalizados
y, si queremos integrar el trabajo
con un lenguaje de programación como
Python, la herramienta Scpay [6] puede
resultar interesante.
La forma más simple y efectiva de tratar
los ataques basados en el envío de
paquetes modificados es poner un cortafuegos
que sea capaz de reensamblarlos.
El iptables de Linux puede hacer esto si
activamos los módulos de seguimiento
de conexiones, ya que éstos reensamblan
paquetes de forma automática. Usando
el parámetro fragment reassemble de la
opción scrub del PF de OpenBSD, haremos
que se reserve memoria para un
buffer donde se almacenarán los paquetes
entrantes y se reensamblarán en
paquetes completos y bien formados
antes de su reenvío al interior de la red.
WWW.LINUX- MAGAZINE.ES
Evitando Detección PORTADA
Figura 1: Opciones de evasión de nmap.
Ambas herramientas introducen algo
de latencia adicional, pero evitan que los
paquetes fragmentados con secciones
solapadas atraviesen la red. La idea
general es poner un sistema operativo
con una pila TCP robusta delante del
resto de los sistemas que tengan pilas
TCP más débiles.
De la misma forma que las herramientas
de modificación de paquetes han
mejorado con los años, la mayoría de los
sistemas IDS e IPS también han evolucionado.
El mejor ejemplo de esto es el proyecto
de código libre Snort, que tiene un
preprocesador llamado Stream5 (sucesor
del preprocesador Stream4). Stream5
dispone de un reensamblador y detector
de anomalías de paquetes TCP bastante
avanzado capaz de localizar muchos
tipos de alteraciones en las conexiones y
en los paquetes. Los desarrolladores de
soluciones propietarias también han
sabido actualizarse. Deberemos mirar la
documentación de nuestra solución y
asegurarnos de tener instaladas las últimas
actualizaciones.
Alteración del Protocolo
Dado un protocolo de red ¿qué constituye
tráfico “correcto” y “válido”? Una
respuesta puede ser: todo lo que el
cliente o el servidor al que estemos
conectado acepte. Muchas veces lo que
dice el estándar no es tan importante
cuando se trata de realizar una implementación
concreta de ese protocolo.
Esto dificulta mucho la creación de software
de calidad para el análisis de protocolos.
Si seguimos las especificaciones,
pronto veremos que los desarrolladores
de software (incluidas las empresas más
grandes) aceptan muchas veces datos
mal formados como si fueran válidos (es
una forma educada de decir que nunca
siguen las especificaciones).
El mejor ejemplo es el capturador y
analizador de paquetes Wireshark (antes
conocido como Ethereal), que contiene
cientos de analizadores de protocolos y
203 entradas en la base de datos de vulnerabilidades
de seguridad CVE – la
Número 69
23

PORTADA Evitando Detección
mayoría de las cuales son debidas a estos
mismos analizadores de protocolos.
Existen herramientas que nos permiten
capitalizar estas características que
no cumplen con el estándar del protocolo
para sortear los sistemas IDS e IPS.
Ya en el número 53 [7] de Linux Magazine
vimos 10 tipos diferentes de fuzzers,
de los que cinco eran para redes. De ellos
el mejor es Peach Fuzzing Platform [8],
que actualmente se encuentra en
desarrollo (con una última actualización
a finales de diciembre de 2010). Algunas
de las otras herramientas de alteración
de protocolos no han tenido continuidad.
Por ejemplo, de SPIKE no ha salido
ninguna versión nueva desde hace años.
Apuntando a la Web
No es sorprendente saber que el vector
de entrada de muchas de las intrusiones
es la web. Muchos servicios y dispositivos
ofrecen ahora capacidades web
(impresoras, escáneres, servidores y dispositivos
empotrados). De hecho, casi
todo lo que no está basado en web se
encuentra tras un cortafuegos, con lo
que los servidores web se sitúan en los
primeros puestos de las listas de objetivos
de los atacantes.
La web presenta algunas oportunidades
interesantes para el atacante: casi
todos los servidores web soportan uno o
varios lenguajes de programación
(scripts CGI, PHP, SQL, etc.). Esto da al
atacante muchas más oportunidades de
interactuar con el sistema de formas no
previstas, y que pueden ocasionar más
de un desbordamiento de buffer – inyección
de SQL, vulnerabilidades XSS
(Cross-Site Scripting), etc..
La parte cliente proporciona además
un conjunto de tecnologías software
increíblemente complejas y potencialmente
problemáticas. Los principales
navegadores web (Internet Explorer,
Firefox, Opera, Safari y Chrome) tienen
todos una larga historia de fallos de
seguridad. Además, hay que considerar
al omnipresente Flash, que se encuentra
instalado en virtualmente toda máquina
Windows y en muchas de las máquinas
Linux. (Si queremos ver vídeos, hay
muchas probabilidades de que necesitemos
Flash – al menos hasta que HTML5
sea más popular). Flash tiene un triste
registro de vulnerabilidades. No hace
mucho, por ejemplo, apareció un nuevo
ataque y se publicó el código que explo-
taba la vulnerabilidad. Adobe tardó
entre 2 y 3 semanas en corregir el
problema.
Aunque todavía no es muy conocido,
los atacantes disponen de una
forma muy simple de sortear completamente
los sistemas IDS e IPS.
Se trata de usar sesiones web
HTTPS cifradas para lanzar ataques
contra servidores y clientes. A
menos que dispongamos de un
balanceador de carga HTTP y nuestro
sistema IDS/ IPS esté situado entre el
balanceador y el servidor, no habrá una
manera fácil de analizar el contenido
enviado al servidor web.
En el lado del cliente, si somos suficientemente
paranoicos, podemos comprar
algún producto tipo Packet Forensics
[9], que nos permite descifrar sesiones
HTTPS al vuelo instalando un certificado
personalizado en el cliente que
deseamos proteger. Hay que tener en
cuenta, sin embargo, que este producto
está orientado principalmente para ser
usado por las fuerzas de seguridad que
quieren explotar un solo servidor web, y
no está realmente diseñado para proteger
sistemas clientes (al menos hasta
donde yo se, y es que esta empresa es
algo reservada). Lo peor de que un atacante
use HTTPS es que el protocolo
HTTPS es legítimamente necesario en
muchos sitios, por lo que es complicado
bloquearlo, ya que podría cabrear a
muchos usuarios.
Otra alternativa que tienen los intrusos
para sortear nuestro sistema de detección
es usar algún tipo de ataque que
codifique la información. Hay varias técnicas
que permiten codificar peticiones y
respuestas HTTP. Normalmente enviamos
al servidor texto plano, pero podemos
indicar un Content-Type diferente,
que puede tener varios valores, como
UTF-8 o UTF-7. Lo que es más, podemos
codificar el texto usando notación porcentual
(por ejemplo, un espacio es
“%20”), hexadecimal, decimal y por
nombres. Podemos
además usar dobles
comillas y una variedad
de código de páginas
para otros idiomas
(ver la tabla “Nombres
de Dominio Internacionales”).
También es
posible mezclar un
poco las cosas (mien-
24 Número 69 WWW.LINUX- MAGAZINE.ES
Figura 2: Algunos ejemplos con porcentajes, dobles
porcentajes, Unicode, UTF-8 y varias codifica-
ciones.
tras el servidor o el cliente lo acepte y
decodifique, es, en todo caso “legítimo”).
Ya que no hay forma de diseñar expresiones
regulares o patrones que nos permitan
filtrar toda posible codificación
que el atacante puede usar, necesitaremos
normalizar el tráfico antes de escanearlo
en búsqueda de potenciales problemas.
Esto significa que, para toda
cabecera HTTP que examina nuestro
IDS/ IPS, primero debemos detectar si los
datos están codificados y luego ver el
tipo de codificación, normalizarlos y
finalmente escanearlos. Debemos hacer
esto para cualquier dato susceptible de
ser codificado en más de un nivel, o que
permite usar simultáneamente varios sistemas
de codificación en una misma
cadena.
El escáner de seguridad Nikto2 [10]
hace uso de la librería libwhisker [11] e
incorpora una serie de trucos de cifrado
anti-IDS, como por ejemplo la inserción
de directorios autoreferenciados (“/ ./ ”)
o la inserción de parámetros falsos en la
URL, como tabuladores, retornos de
carro o valores binarios en vez de espacios.
Si el intruso se enfrenta a un servidor
Windows, puede probar cambiando
de forma aleatoria las mayúsculas y
minúsculas (ya que la mayoría de los
servidores web de Windows no diferencian
entre mayúsculas y minúsculas
cuando procesan las peticiones) y cambiar
las “/ ” por “\”. O, simplemente,
puede insertar caracteres UTF-8 aleatorios;
por desgracia con esto solo ya es
Nombres de Dominios Internacionales
Quizás pensemos que simplemente podemos hacer filtros
basados en los nombres de dominios, poniendo a los chicos
malos en una lista negra. Desafortunadamente, con los
IDN (nombres de dominios internacionales, o International
Domain Names [12] en inglés) podremos tener múltiples
representaciones para un mismo dominio usando IDN,
UTF-7 y Punycode. Deberíamos comprobar si nuestro software
gestiona correctamente nombres IDN y representaciones
Punycode.

posible causar problemas (y es que parece que hay programadores
que no son muy buenos tratando cadenas Unicode)
(Figura 2).
JavaScript y Flash
Si lo que queremos es sortear sistemas IDS e IPS, JavaScript
y Flash son un auténtico sueño hecho realidad. Los dos son
lenguajes Turing-completos, por lo que en principio no hay
forma de saber si el código que vamos a ejecutar es malicioso
o no. La única forma posible de identificar este código
es ejecutarlo y tratar de pillarlo en el momento que haga
algo sospechoso.
JavaScript (al igual que la mayoría de los lenguajes interpretados)
es bastante prolijo o verboso y suele incluir
muchos espacios en blanco. Los diseñadores de páginas web
y los usuarios desean que las páginas carguen rápidamente,
y los scripts llenos de largas palabras y muchos espaciados
ocupan más espacio, ralentizando la carga de las páginas
web. Para resolver esto, muchos sitios se han visto obligados
a comprimir sus JavaScripts para reducir el tamaño de los
ficheros a descargar. La forma más simple de compresión
consiste en eliminar todos los espacios en blanco sobrantes,
aunque, claro está, esto por sí solo no va a reducir de
manera significativa el tamaño total del fichero.
Por suerte hay alternativas más avanzadas; una muy
conocida es la herramienta “Packer” [13] de Dean Edwards
(ver Figura 3). Lo que hace Packer es crear una función
envoltorio que descomprime datos, luego comprime el contenido
de nuestro JavaScript y lo convierte a una cadena de
texto que se incluye, junto con la función descompresora, en
un nuevo fichero. Packer puede reducir los nombres de las
variables (al ordenador no le importa si la variable se llama
“nombre_de_usuario” o sólo “a”) y codificar los datos en
Base62 (con lo que se usarán sólo los caracteres a-z, A-Z y 0-
9). Otra alternativa es el compresor YUI [14] – el compresor
JavaScript y CSS de Yahoo!. Al igual que Packer, esta herramienta
puede acortar el tamaño de las variables, eliminar los
espacios en blanco e incluir ciertas macros de optimización.
Ambas herramientas son compresores JavaScript bien documentados
y “políticamente correctos”.
Hay formas menos educadas (léase: maliciosas) de realizar
esta compresión. Una de ellas requiere usar ciertos trucos
basados en unescape(), el cual permite al intruso mezclar
varias codificaciones usando, por ejemplo, caracteres
codificados con el código porcentual dentro del flujo de
datos. El problema es que muchos sitios (incluido Google)
usan unscape() para empaquetar datos, de tal forma que
caracteres como < y > puedan ser filtrados en los formularios
de entrada, haciendo por tanto mucho más difícil distinguir
los usos lícitos de los maliciosos.
Las aplicaciones Flash una vez escritas son compiladas en
ficheros .SWF y alojadas en los servidores web. Sin
embargo, al igual que otros ficheros binarios con estructuras
conocidas, son fáciles de descompilar y volver a su versión
en código fuente. Por eso, al igual que se comprimen los
JavaScript (por rendimiento), muchos sitios ofuscan los
ficheros Flash para evitar su desensamblado.
Los programas de ofuscación normalmente renombran
todas las variables usando nombres aleatorios, cifrando cier-

PORTADA Evitando Detección
tos datos delicados como contraseñas y
cadenas de texto, aleatorizando ciertas
instrucciones y modificando el flujo de
control del programa para dificultar su
análisis mediante el decompilador. Estas
herramientas proporcionan a los intrusos
una forma de ocultar las intenciones de
una aplicación Flash aparentemente inocente.
De forma realista, lo mejor que se
puede hacer para detectar ficheros Flash
dañinos es buscar una copia del fichero
malicioso y enviarlo a una empresa antivirus
para que añadan su firma a la base
de datos.
PDF y Adobe Reader
PDF es una tecnología aún menos segura
que JavaScript y Flash. No es sólo que el
formato PDF tiene una larga lista de problemas,
es que podemos incrustar casi
cualquier contenido que queramos en un
fichero PDF (incluido JavaScript y
Flash). También podemos ofuscar los
ficheros PDF de modos que nos hacen
dudar del equipo de desarrollo de Adobe
Reader. Algunas de las técnicas de ofuscación
de PDF [15] incluyen:
Llamar a OpenAction sobre objetos
creados.
Usar codificaciones especiales para
sustituir ciertos caracteres (representaciones
nombradas).
Partir una cadena usando la barra
invertida, creando un carácter por
línea.
Convertir cadenas a hexadecimal y
añadir caracteres de espacio dentro de
la cadena.
Cifrar (otra vez para proteger el contenido).
Podemos además comprimir el PDF
usando /FlateDecode, crear un montón
¿Legítimo?
Hay que tener en cuenta que un atacante no necesita seguir
técnicas de intrusión convencionales para atacar nuestra
red. Incluso si logramos bloquear todo dato codificado,
cifrado, comprimido y cualquier otro oculto, los atacantes
más inteligentes pueden en ocasiones atacar la red
enviando peticiones completamente legítimas.
Por ejemplo, consideremos el caso de una web de reservas
aéreas que permite al visitante buscar un vuelo y reservar
un asiento determinado. El sistema mantiene la reserva del
asiento por un periodo determinado mientras el usuario
introduce su número de tarjeta de crédito entre otros datos.
Un atacante puede, simplemente, establecer varios cientos
de conexiones y apartar todos los asientos libres, y volver a
seleccionarlos en otra sesión cuando el sistema los libere
transcurrido un tiempo. Identificar este tipo de ataque en
un sistema IDS o IPS es prácticamente imposible.
de anotaciones de documento
aleatorias y,
luego, usar getAnnots()
[16] para obtener un
array de anotaciones y
crear un conjunto mayor
de documentos. Otra
cosa que podemos hacer
es crear una lista de
cadenas debidamente
modificadas, para luego
usar la función replace() JSMin y Packer.
y transformarlas en algo
malicioso que pueda ser ejecutado a través
de la función eval().
¡Ah! También podemos codificar
JavaScript dentro del PDF usando notación
octal (por ejemplo, “\72” para el
carácter “:”); podemos codificar uno o
varios caracteres y PDF los gestionará sin
problemas.
En resumen: un intruso puede usar la
notación octal sobre varios caracteres del
código JavaScript, romper la bomba
lógica en pedacitos aparentemente inocuos,
reemplazar algunas subcadenas
por otras de apariencia más segura (que
luego serán reemplazaras usando expresiones
regulares), y ocultar las cadenas
codificadas dentro de las anotaciones del
documento (que curiosamente algunos
sistemas no van a escanear, ya que se
consideran “seguras”).
Esto significa que si queremos escanear
adecuadamente un documento PDF,
necesitaremos extraer toda la cadena,
ejecutar sobre ella las expresiones regulares
contenidas en el documento, concatenarlas,
y luego escanear el resultado
final buscando algo sospechoso.
Conclusiones
Los atacantes con determinación (también
conocidos como
APT en sus siglas en
inglés – “Advanced
Persistent Threat” o
“Amenaza Persistente
Avanzada”) tienen
acceso al mismo hardware
y herramientas
software que usamos
para defender nuestras
redes. No es que los
vendedores de soluciones
IDS e IPS hagan
algún tipo de estudio
en profundidad de sus
clientes antes de ven-
26 Número 69 WWW.LINUX- MAGAZINE.ES
Figura 3: Un sencillo programa JavaScript comprimido usando
der sus productos. Los chicos malos terminarán
encontrando algún fallo en las
herramientas que usamos.
Mi consejo es que se bloquee todo dato
mal formado que sea posible (por ejemplo,
fragmentos TCP con solapamiento,
algunos tipos de codificación, etc.) y
registremos el resto. Si un atacante aún
así consigue penetrar en la red, al menos
el fichero de registro nos puede ayudar a
averiguar cómo lo hizo. ■
RECURSOS
[1] OSSEC: http:// www. ossec. net/
[2] Enmascarando ataques usando
Craigslist: http:// arstechnica. com/ old/
content/ 2008/ 10/
bank-robber-crowdsources-disguise-t
o-craigslist-floats-away. ars
[3] Fragrouter: http:// archive. ubuntu.
com/ ubuntu/ pool/ universe/ f/
fragrouter/
[4] Fragroute: http:// monkey. org/
~dugsong/ fragroute/
[5] hping: http:// www. hping. org/
[6] Scapy: http:// www. secdev. org/
projects/ scapy/
[7] Fuzzing; Linux Magazine Nº53 Edición
en Castellano, pags. 8-9: http://
www. linux-magazine. es/ issue/ 53/
008-009_Inseguridades53. pdf
[8] Plataforma Peach Fuzzing: http://
peachfuzzer. com/
[9] Análisis Forense de Pacquetes: http://
www. wired. com/ threatlevel/ 2010/ 03/
packet-forensics/
[10]Nikto2: http:// cirt. net/ nikto2
[11]libwhisker: http:// www. wiretrip. net/
rfp/ lw. asp
[12]Nombres de dominios internacionalizados:
http:// en. wikipedia. org/ wiki/
Internationalized_domain_name
[13]Packer: http:// dean. edwards. name/
packer/
[14]Compresor YUI: http:// developer.
yahoo. com/ yui/ compressor/
[15]Ofuscador PDF: http:// blog.
didierstevens. com/ 2008/ 04/ 29/
pdf-let-me-count-the-ways/
[16]Ofuscación de PDF usando getAnnots():
http:// blog. fireeye. com/
research/ 2010/ 01/ pdf-obfuscation.
html