30 de octubre de 2009

Kill a Zombie Day


Cómo ha cambiado la Seguridad Informatica, ¿verdad?, después de ver este vídeo seguro que habéis cancelado vuestros planes para Halloween. Como quiero que os lo paséis muy bien en este terrorífico dia aprovecho para dejaros un arma detecta zombies: OSAM autorun manager, recién salida del horno en su versión 5.0 hace un par de meses.

Por cierto, yo que soy un tipo más tradicional en la materia zombie siempre prefiero algo como esto:


Anyway, good hunting :)

27 de octubre de 2009

Spider Windows


¡Hola!, Hoy os presento una herramienta interesante, todos conocemos spiders web que buscan y rastrean información valiéndose del motor de Google, Yahoo, Bing, etc. La herramienta de hoy hace algo similar pero en la máquina que le digamos, que puede ser local o estar en la misma red. Se llama Spider Windows y es muy sencilla:


Spider Windows buscará números de tarjeta de crédito, de teléfono, DNI, etc. en la partición o unidad que le indiques, esto incluirá por supuesto ficheros ocultos. Esta búsqueda es configurable permitiendo añadir los patrones que queramos:

Con los resultados que encuentre generará un fichero de log con el PATH de los ficheros que contienen información sensible, este será depositado en la ubicación elegida, si es un servidor externo lo enviará valiéndose del protocolo SYSLOG. ¡Es sorprendente las cosas que uno almacena en su equipo!, yo me he encontrado con números de teléfono que ni recordaba andaban por ahí. En un ambiente un poco más profesional esto nos puede valer por ejemplo para saber que información sensible tenemos en una máquina, para ayudarnos en el cumplimiento de PCI-DSS, LOPD, etc. Si hacemos una auditoría con los patrones apropiados encontraremos qué información está expuesta para un usuario no-administrador en un servidor (por ejemplo).

Hay una alternativa Linux que incluye funcionalidades forenses detectando archivos borrados también, está incluida dentro de la distribución de Helix y se llama Spider Linux. Habrá que tenerla en cuenta también en el análisis de incidentes.

Salu2

24 de octubre de 2009

Sello Europeo de Privacidad

El proyecto para definir un programa de certificación de productos en lo que a seguridad y protección de datos a nivel europeo se refiere está a punto de terminar. A grandes rasgos este proyecto establece un proceso de certificación para que cualquier entidad que trabaje con sistemas o servicios que traten datos de carácter personal pueda certificar los mismos (sea una aplicación, sea un producto hardware, etc.), con un sello de confianza reconocido dentro de la Unión Europea, este proceso de certificación incluye:

- Evaluación del producto por expertos jurídicos.
- Auditoría del producto por expertos TI.
- Informe de conformidad con los criterios de evaluación del catálogo de criterios europeos.
- Aceptación del producto bajo el sello de privacidad europeo.

Como os podeis imaginar la definición y puesta en vigor del European Privacy Seal (Europrise) supondrá un valor añadido al que muchas empresas querrán subirse para certificar sus productos y servicios, exactamente igual como ya ocurrió con la ISO 9000 de calidad. En España el informe de auditoría y evaluación del producto técnica y legal será revisado por la Agencia de Protección de Datos de la Comunidad de Madrid, quien por ahora es la única entidad nacional que puede homologar el Europrise.

En la llamada "Sociedad de la Información" donde la penetración de las tecnologías en los ciudadanos es cada vez mayor, es absolutamente necesario la presencia de un producto como este que proporcione confianza a los ciudadanos en el uso de las TIC. Por si a alguien le quedan dudas por aquí tenéis el último barómetro de la Agencia Española de Protección de Datos de Septiembre 2009, en el figuran los siguientes datos:

- El 46% no conoce de la existencia de la AEPD.
- El 43% le preocupa bastane la protección de datos y el uso por terceras personas, al 30% mucho.
- El 56% considera que la privacidad de sus datos en Internet es baja o muy baja.
- Al 77% le da poca seguridad dar su número de tarjeta de crédito por Internet para hacer sus compras.

Contra estas cifras iniciativas como el Europrise son de agradecer, no obstante nunca podemos dejar las necesarias campañas de Sensibilización y Formación al ciudadano en lo que al buen uso y seguridad de Internet se refiere.

Si queréis profundizar en este tema el 3 de Noviembre se va a dar un seminario en la Casa de Correos en Madrid, la entrada es gratuita, solo limitada al número de plazas.

Buen fin de semana :)

22 de octubre de 2009

Secure Survey

En los últimos días me vino a la cabeza un interrogante sobre las numerosas encuestas que circulan por Internet, ¿cuan fiables son estas encuestas? Siempre acabo dando con la misma respuesta, “depende”. Pero nunca le había dado un par de vueltas, nunca hasta hoy. De todas formas parece que soy el único que se hace este tipo de preguntas (será el trabajo, que se yo), por que la práctica totalidad de medios de televisión y prensa del mundo despliegan estas encuestas incorporándolas a la versión escrita de sus periódicos, programas de radio y televisión. Esto puede ser un gran problema de credibilidad ya que aparecen al lado de otras en teoría “más fiables” como las que realiza el CIS dando lugar a la errónea suposición de que ambas tienen resultados con la misma confianza (cualquiera que sea esta).

Tras un pequeño vistazo a algunos medios digitales he podido encontrarme las siguientes cosas, corresponden al código con que se realizan las peticiones y se almacenan los votos:

onsubmit="javascript:{if ( hasCookie('haVotado') ) {alert('Tu voto ya ha sido registrado'); return false;} 
else {return true};}"
En este caso si el método ‘has cookie’ devuelve “true” votas, sino no. Delega el voto en un control sobre la cookie. En este otro caso:
OAS_version = 10;

OAS_rn = '001234567890'; OAS_rns = '1234567890';
OAS_rn = new String (Math.random()); OAS_rns = OAS_rn.substring (2, 11);
function OAS_NORMAL(pos) {
document.write('
 '!' + pos + OAS_query + '" TARGET=_top>'); 

Se hace la petición al servidor de aplicaciones (OAS = Oracle Application Server) a partir de una cadena que se almacena en la Cookie, en la misma se “ofusca” incrustando un valor aleatorio de semilla conocida a la petición. La construcción de esa cadena es perfectamente visible en el código javascript, luego todo es pasado en el GET y algunos atributos quedan ocultos en el POST que lee los valores de la Cookie:

Luego parece que esta encuesta también es manipulable, conociendo el mecanismo que genera las peticiones y con un http Fuzzer (como el que incorpora Acunetix) podemos generar votos automáticamente.

Indagando un poco más he encontrado encuestas que incluían CAPTCHA, pero este mecanismo tampoco es infalible como vimos aquí, luego, ¿Qué nos queda? Incluso para dar un servicio de apariencia tan sencilla como este es necesario un conjunto de medidas de seguridad donde por sí sola ninguna nos puede proporcionar confianza de que el voto no ha sido manipulado / generado automáticamente, no obstante en conjunto el riesgo se “mitiga”. Algunas de las que a mí se me ocurren son:

- No incluir en código JavaScript los métodos de comprobación de origen, es visible.

- No verificar el origen a partir de información depositada en el cliente, esta información puede ser manipulada.

- Incluir CAPTCHA.

- Incluir un mecanismo para verificar el origen por token (secreto) + IP + credenciales que identifiquen al equipo, para garantizar la integridad del origen de la petición (podemos utilizar hash también). Estas comprobaciones se harán en el servidor.

Bueno, en un entorno ideal se podría utilizar incluso la firma digital de los usuarios (¿DNI electrónico?) para realizar una encuesta. Claro está que para saber que opina la gente con respecto al partidazo del Atleti no aplica, pero para un referendum,,, quizás si.

Esto es todo por hoy, cuidado donde votáis y cual es el origen de vuestras encuestas :)

Salu2!

17 de octubre de 2009

Forensic Analysis of a Network Scan

¡Hola! Volvemos a la carga con una vieja asignatura que teníamos aparcada desde hace tiempo: Análisis Forense. En el día de hoy hemos cogido un sencillo reto “for beginners” de los muchos existentes en los “scan of the month” del honeynet Project. En el mismo nos proporcionan un fichero binario con un tcpdump de varios megas que incluye una serie de tráfico TCP/IP que deberemos analizar para averiguar que ocurrió, el reto incluye la respuesta a varias preguntas de creciente dificultad. En este “mini-reto” utilizaremos herramientas tan comunes como Wireshark (también vale Ethereal o el sniffer que a vosotros os guste) y nmap. Vamos para allá:

1.- What is a binary log file and how is one created?

Una teórica para empezar, un fichero binario no es más que un archivo generado por el NIDS (Network Intrussion Detection System) Snort que, apoyándose en las habituales librerías Libpcap / Winpcap es capaz de depositar el tráfico exactamente igual que circula por la red en un fichero. La presencia de copias exactas de los paquetes nos garantiza que nada es modificado, ¡el requisito más importante en cualquier investigación! Esto nos lleva a la siguiente cuestión.

2.- What is MD5 and what value does it provide?

Bueno, creo que esto lo sabéis todos ya, lo vimos en esta entrada. El MD5 no es más que un algoritmo de un solo camino que calcula un valor hash, ese valor es único para cada entrada, o eso se supone. Existe un verdadero debate (el cual me está dando una idea para una futura entrada) acerca de la validez de un hash como mecanismo que garantiza que una evidencia no ha sido comprometida, debate acrecentado a medida que se descubren colisiones en los principales algoritmos: MD5 y SHA1. Cuando nos descargamos los archivos del reto nos piden que confirmemos el hash, en este caso lo hemos hecho:

3.- What is the attacker’s IP address?

Se acabó la literature, tenemos que averiguar la dirección IP del atacante, para ello (y dado que no es un fichero grande) examinaremos todas las IP origen y destino con Wireshark. Rápidamente podemos observar que aparecen las siguientes IP source:

192.168.0.9, 192.168.09.9, 192.168.0.254, 192.168.0.199, 192.168.0.1

Y las siguientes IP de destino (IP.dst):

192.168.0.9, 192.168.0.99

En la siguiente captura hacemos filtrado para asegurarnos que no hay otras IP.dst:

De forma curiosa, la regla no filtra aquellos destinos inalcanzables (¡pero eso es una pista!), ahora bien, ¿Cómo sabemos la IP del atacante a partir de esta información? Deberemos examinar los paquetes, no obstante algo huele a chamusquina cuando el 99% del tráfico procede de 192.168.0.9 y tiene de destino 192.168.0.99. No obstante nos aseguramos comprobando el tráfico que sale de 192.168.0.99 y eliminando el que tiene de destino 192.168.0.9 (genera demasiado ruido), obteniendo que no hay tráfico de estas características. Lo cual quiere decir que no hay respuesta de 192.168.0.99 hacia otros destinos distintos de 192.168.0.9, en este caso la ausencia de evidencia es la evidencia de que el atacante (¿supuesto atacante?) proviene de 192.168.0.9, probablemente por que el resto de destinos no existían (¿IP spoofing?).

4.- What is the destination IP address?

Como hemos hecho nuestro trabajo bien en la anterior cuestión, sabemos que la IP que estaba respondiendo a todas las peticiones era la 192.168.0.9. Parece que vamos bien ;-)

5.- We scanned de honeypot using five different methods. Can you identify the five different scanning methods, and describe how each of five works?

Comienza a subir la dificultad del análisis, nos piden averiguar las distintas tácticas de escaneo utilizadas. Vayamos por partes, nada más comenzar la captura se observa un ping hacia 192.168.0.99, justo después (Time 10.346091) comienzan a hacerse peticiones de tipo SYN desde el puerto origen 52198 hacia puertos fuera del rango reservado, el host escaneado responde con trazas [RST, ACK], lo que significa que se ha llegado al puerto pero no hay nadie escuchando, este podría ser nuestro primer tipo de escaneo:

Correspondiente a un nmap –sS (TCP SYN Scan) 192.168.0.99, el cliente debería responder con un ACK pero no lo hace, se queda a medio camino (half-open scanning).

En el Time 148007 se vuelve a producir un ping hacia 192.168.0.99, en ese momento se arranca otro tipo de escaneo, el wireshark nos cambia los colores, lo que ayuda ya que es muy llamativo:

Parece que se están tratando de hacer fingerprinting del sistema operativo, es decir, detectar que tipo de máquina hay detrás, en este caso el escaneo se concentra en los puertos habituales de servicios Windows. Por ahora parece que no tiene suerte nuestro atacante :) sin embargo poco tiempo después, línea de tiempo 150563 comienzan a aparecer paquetes ACK duplicados (el Wireshark los pinta de un negro terrorífico), que tienen su cumbre en el 150626, donde se comienza a recibir [SYN-ACK] en servicios habituales de Windows, lo que parece un nmap –sX (Xmas scan) bastante exitoso:

Ahora bien, justo después (se puede apreciar en la imagen anterior) el atacante trata de establecer conexiones al puerto SSH, pero con todos los flags TCP sin determinar, esto significa que estamos delante de un “Null Scan”, también llamado nmap –sN, si pinchamos en cualquier paquete veremos esta información dentro de los flags del protocolo de control de transmisiones:

Terminamos con un último ataque, se llama decoy scanning y sirve para que el host remoto no sepa identificar (a priori) quien es el host destino, decoy significa señuelo en inglés y lo que hace es realizar la misma petición desde varias IP inexistentes como las que vimos en 3), está muy bien para pasar desapercibidos aunque obviamente no tiene sentido en un entorno como el que estamos viendo:

Puede reproducirse con nmap y la opción –D. Y con esto hemos repasado los escaneos que se han realizado, como vemos es importante conocer los tipos de escáneres que permiten las herramientas, para ello podemos acudir por ejemplo a las técnicas que explican en la página del escáner más famoso.

6) Which scanning tool was used to scan our honeypot? How were you able to determine this?

Bien, en el punto anterior vimos que opciones de nmap había que habilitar para cada ataque, pero eso no significa ni mucho menos que haya sido esta herramienta, ¿verdad? Necesitaremos utilizar un NIDS para analiza las trazas y verificar si detecta algún ataque y por parte de qué, para ello no hay nada como Snort, que nos devolverá algo parecido a esto:

[**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] - 22539

[**] [111:9:1] spp_stream4: STEALTH ACTIVITY (NULL scan) detection [**] - 3996

[**] [111:12:1] spp_stream4: NMAP FINGERPRINT (stateful) detection [**] - 9

[**] [1:628:1] SCAN nmap TCP [**] - 9

Luego ahí tenemos a nuestro principal sospechoso.

7) What is the purpose of port scanning?

Bueno, la razón de realizar un escáner de puertos es bastante sencilla. Identificar todos los servicios y puertos abiertos que el host “víctima” está ofreciendo. O dicho de otro modo, identificar los posibles puntos de entrada a su sistema. Es una definición algo tosca pero nos vale :)

8) What ports are open on our honeypot?

Tal y como vimos en 5) los mecanismos para establecer una conexión TCP/IP incluyen el famoso saludo “a 3 bandas” o 3-way handshake, de tal forma que cuando hay un puerto abierto y dependiendo del ataque lo podemos identificar de varias formas. A grandes rasgos para no extender la entrada en demasiado he recolectado todos los paquetes emitidos por 192.168.0.99 con [SYN,ACK], es decir donde hay servicios, con ello he identificado los puertos:

- 22 / SSH

- 53 / DNS

- 80 / HTTP

- 443 /HTTPS

- 111 / SUNRPC

- 32768 / FILENET

9) Bonus Question: What operating system was the attacker using?

Esta cuestión puede parecer a priori la más difícil de responder, obtener el sistema operativo origen a partir de unas trazas TCP/IP podría ser un problema si no fuese por herramientas como p0f, Ettercap o Network Miner, las mismas utilizan técnicas de fingerprinting pasivo a raíz de los valores TTL, el tamaño de la ventana, type of service, (TOS) etc. Se puede profundizar en estas técnicas aquí. Yo he escogido Network Miner, la cual nos podría haber facilitado el trabajo desde el principio (pero entonces no habría sido tan divertido ;-) ) ya que es una herramienta de análisis forense en red. Ella nos muestra que tanto host atacante como host atacado eran Linux:

Y esto es todo por hoy, el análisis forense es magnífico para repasar y profundizar en los habituales conocimientos de redes, sistemas operativos, etc.

Buen fin de semana :)

NdA: Estoy teniendo bastantes problemas para escalar las imágenes sin perder detalle, así que se ven bastante pequeñas, siento el inconveniente.

15 de octubre de 2009

Top 500 Worst Passwords of all time

Repasando la web "What's my pass?" descubro una cuanto menos curiosa lista de las passwords más habituales que todos (y digo todos sin excepción), alguna vez hemos utilizado, y cuando digo hemos estoy hablando en pasado por que espero que ninguno de vosotros estéis por ahí:

NOTop 1-100Top 101–200Top 201–300Top 301–400Top 401–500
1123456porschefirebirdprincerosebud
2passwordguitarbutterbeachjaguar
312345678chelseaunitedamateurgreat
41234blackturtle7777777cool
5pussydiamondsteelersmuffincooper
612345nascartiffanyredsox1313
7dragonjacksonzxcvbnstarscorpio
8qwertycamerontomcattestingmountain
9696969654321golfshannonmadison
10mustangcomputerbond007murphy987654
11letmeinamandabearfrankbrazil
12baseballwizardtigerhannahlauren
13masterxxxxxxxxdoctordavejapan
14michaelmoneygatewayeagle1naked
15footballphoenixgators11111squirt
16shadowmickeyangelmotherstars
17monkeybaileyjuniornathanapple
18abc123knightthx1138raidersalexis
19passicemanpornosteveaaaa
20fuckmetigersbadboyforeverbonnie
216969purpledebbieangelapeaches
22jordanandreaspiderviperjasmine
23harleyhornymelissaou812kevin
24rangerdakotaboogerjakematt
25iwantuaaaaaa1212loversqwertyui
26jenniferplayerflyerssuckitdanielle
27huntersunshinefishgregorybeaver
28fuckmorganpornbuddy4321
292000starwarsmatrixwhatever4128
30testboomerteensyoungrunner
31batmancowboysscoobynicholasswimming
32trustno1edwardjasonluckydolphin
33thomascharleswalterhelpmegordon
34tiggergirlscumshotjackiecasper
35robertbooboobostonmonicastupid
36accesscoffeebravesmidnightshit
37lovexxxxxxyankeecollegesaturn
38busterbulldogloverbabygemini
391234567ncc1701barneycuntapples
40soccerrabbitvictorbrianaugust
41hockeypeanuttuckermark3333
42killerjohnprincessstartrekcanada
43georgejohnnymercedessierrablazer
44sexygandalf5150leathercumming
45andrewspankydoggie232323hunting
46charliewinterzzzzzz4444kitty
47supermanbrandygunnerbeavisrainbow
48assholecompaqhorneybigcock112233
49fuckyoucarlosbubbahappyarthur
50dallastennis2112sophiecream
51jessicajamesfredladiescalvin
52pantiesmikejohnsonnaughtyshaved
53pepperbrandonxxxxxgiantssurfer
541111fendertitsbootysamson
55austinanthonymemberblondekelly
56williamblowmeboobsfuckedpaul
57danielferraridonaldgoldenmine
58golfercookiebigdaddy0king
59summerchickenbroncofireracing
60heathermaverickpenissandra5555
61hammerchicagovoyagerpookieeagle
62yankeesjosephrangerspackershentai
63joshuadiablobirdieeinsteinnewyork
64maggiesexsextroubledolphinslittle
65bitemehardcorewhite0redwings
66enter666666topgunchevysmith
67ashleywilliebigtitswinstonsticky
68thunderwelcomebitcheswarriorcocacola
69cowboychrisgreensammyanimal
70silverpanthersuperslutbroncos
71richardyamahaqazwsx8675309private
72fuckerjustinmagiczxcvbnmskippy
73orangebananalakersnipplesmarvin
74merlindriverrachelpowerblondes
75michellemarineslayervictoriaenjoy
76corvetteangelsscottasdfghgirl
77bigdogfishing2222vaginaapollo
78cheesedavidasdftoyotaparker
79matthewmaddogvideotravisqwert
80121212hooterslondonhotdogtime
81patrickwilson7777parissydney
82martinbuttheadmarlbororockwomen
83freedomdennissrinivasxxxxvoodoo
84gingerfuckinginternetextrememagnum
85blowjobcaptainactionredskinsjuice
86nicolebigdickcartereroticabgrtyu
87sparkychesterjasperdirty777777
88yellowsmokeymonsterforddreams
89camaroxavierteresafreddymaxwell
90secretstevenjeremyarsenalmusic
91dickviking11111111access14rush2112
92falconsnoopybillwolfrussia
93taylorbluecrystalnipplescorpion
94111111eaglespeteriloveyourebecca
95131313winnerpussiesalextester
96123123samanthacockfloridamistress
97bitchhousebeerericphantom
98hellomillerrocketlegendbilly
99scooterflowerthemanmovie6666
100pleasejackoliversuccessalbert

Como es lógico estas passwords pueden cambiar según el idioma, cultura, etc. Eso no quita que las políticas de seguridad que rigen vuestras compañías prohíba sistemáticamente este tipo de contraseñas "de diccionario".

Por cierto la página está cuanto menos curiosa, os recomiendo que le echeis un ojo.

Volvemos pronto,

Salu2