Security Art Work

Las APTs (Advanced Persistent Threats) conforman uno de los principales riesgos a los que se enfrentan hoy en día las empresas, organizaciones y estados. Su objetivo principal es sustraer de forma silenciosa, la mayor cantidad de información de sus víctimas, tratando de pasar totalmente desapercibidas (en algunas ocasiones persisten meses incluso años sin ser identificadas). Famosas fueron las campañas China APT-1, que hace sobre un año destapó “supuestamente” Mandiant o la Rusa con nombre en clave “Red October” detectada por Kaspersky.

A grandes rasgos estas amenazas presentan tres fases en cuanto a su despliegue y funcionamiento:

1º Fase de Análisis. Donde el atacante trata de obtener la mayor información posible de la organización víctima: direcciones de correo, usuarios, roles del personal, estructura jerárquica (aquí la web corporativa ayuda mucho…), etc. De esta fase hay una cosa curiosa y es que normalmente los objetivos más perseguidos no son los directores generales, altos cargos o personal de gran poder sino sus secretari@s. Esto es debido a que estos últimos son en última instancia los empleados que manejan la información más crítica, ya que son los encargados de leer el correo electrónico de su superior, contestar en su nombre o acceder en su lugar a recursos especialmente sensibles.

[Read more…]

Recientemente adquirí un servidor dedicado que utilizo para, entre otras cosas, compartir ficheros entre amigos. En principio, la compartición de ficheros se iba a hacer mediante HTTPS, por lo que el servidor SSH no tenía ninguna configuración fuera de lo normal. Bastó con algunos cambios de la configuración por defecto para tener algo un poco más robusto:

Port X
Protocol 2
ServerKeyBits 4096
LoginGraceTime 30s
PermitRootLogin no
MaxAuthTries 3
MaxSessions 2
PubkeyAuthentication yes
HostbasedAuthentication no
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
AllowUsers usuario

Sé que me he dejado varias cosas importantes, como toda la gama de los forwardings, y que cambiando el puerto en el que escucha el demonio SSH no se soluciona nada (seguridad por oscuridad)… excepto todos los intentos realizados por bots, que creedme, son bastantes.

[Read more…]

Sin duda todos nuestros lectores, sobre todo los que ya tengan una edad, habrán leído el artículo An evening with Berferd, donde Bill Cheswick narra las actividades de un intruso (Berferd) en 1991 y la gestión del incidente realizada desde AT&T, incluyendo una paciente vigilancia de todo lo que hacía Berferd. Obviamente, nosotros somos más de andar por casa y no tenemos la paciencia necesaria para jugar con un atacante durante días o meses, pero también nos pegamos con algún que otro intruso (seguramente no será Berferd, le vamos a llamar Vicente) que por las noches trata de colarse en las máquinas de un cliente al que, por motivos lógicos de confidencialidad, denominaremos ACME :) Ahí va el resumen, con nuestra visión, de la respuesta al incidente… Por supuesto, toda esta historia está basada en hechos ficticios, por lo que cualquier parecido con la realidad es pura coincidencia…

DÍA 1

A las 21:40 se recibe una alerta en nuestro sistema: un amigo, con una dirección IP de un operador al que vamos a llamar OPERATOR genera una alarma crítica en nuestro SOC: un ataque a ACME mediante Acunetix, que se ha bloqueado en el IPS del cliente y teóricamente no ha ido a más, pero que debe considerarse severo. En ese momento se revisa la actividad adicional de esa IP en ACME y el resto de clientes y vemos que ha generado alguna alerta menos crítica (en ACME, parece que este es su único objetivo) y que no requería acción inmediata, pero vamos, que el tío está metiendo caña… se bloquea de inmediato todo el tráfico entrante desde esa dirección y en paralelo comprobamos que la IP es de una línea ADSL, que se geolocaliza en la misma ciudad que ACME, y que detrás de esa IP hay un router Cisco con el telnet abierto (muy curioso, ¿no? ;)

En fin, un ataque que no ha ido a más, bloqueado ya en la infraestructura y que al día siguiente requerirá los formalismos correspondientes (correo a OPERATOR, denuncia de los hechos, etc.). A otra cosa. Pero no; dos minutos después del bloqueo de la IP, aparece un ataque similar: alguien que lanza otra vez Acunetix contra ACME y genera otra alerta crítica… De nuevo iteramos el proceso: bloqueo del tráfico entrante y obtención de información… Ummm, una línea ADSL de OPERATOR con un router Cisco delante, el puerto 23 abierto y (vaya, vaya) geolocalizada donde ACME… ¿Casualidad? Seguro que no: parece que tenemos un amigo interesado en ACME, al que como hemos dicho llamaremos Vicente (Vicentín más tarde, que al final llegamos a coger confianza con él ;)

En fin, nosotros repetimos la respuesta y Vicente el ataque. Esto se pone interesante… Bloqueo de nuevo y otra vez cambio de IP de Vicente: de nuevo un ADSL de OPERATOR geolocalizada en la misma ciudad que ACME, aparentemente con un router Cisco delante y el telnet abierto. Hasta cuatro veces repetimos el proceso y hasta cuatro veces Vicentín hace lo propio: se cambia de IP para seguir “zumbándole” a ACME. Desde luego mañana a denunciar, pero esto no tiene buena pinta… Al final, parece que Vicentín se ha cansado o simplemente que se le han acabado las direcciones dinámicas desde las que atacar… Mañana será otro día para todos, pero esta noche habrá que estar alerta…

DÍA 2

Día tranquilo; Vicentín parece que se ha olvidado de ACME y no da señales de vida… Vemos que no hay nada significativo fuera de las alertas ya identificadas ayer, recopilamos todos los logs, escribimos la denuncia, y a última hora nos vamos a Comisaría a presentarla. Tras un rato de papeleos tenemos ya todo firmado y estamos saliendo… es justo entonces cuando Vicente parece que nos esté viendo: vuelve a la carga contra ACME. Nos llegan las alertas por SMS y viendo sus actividades, confirmamos que sigue el mismo modus operandi que ayer: Acunetix a lo bruto, sin ningún tipo de discreción… Nuestra gente sigue el mismo procedimiento: bloquear cada IP y recopilar evidencias, pero Vicente cambia de direccionamiento como quien cambia de zapatos. Además todas las direcciones son ADSL de OPERATOR geolocalizadas en la misma zona, pero lamentablemente de rangos completamente diferentes, por lo que no lo tenemos tan fácil como bloquear unas clases C para quitarnos a nuestro amigo de encima…

La situación nos empieza a resultar especialmente incómoda, sobre todo por el sentimiento de indefensión. Tenemos a un tipo intentando colarse en ACME pero lo más que podemos hacer oficialmente es bloquearle la IP. Hablamos con soporte legal para que nos den más alternativas y lo único que nos pueden decir es que acudamos a Juzgado de Guardia para acelerar unas horas los trámites de la denuncia (ojo, una aceleración de “unas horas” para unos trámites que pueden durar semanas). Algunos amigos de FFCCSE de forma extraoficial nos confirman lo que ya sospechábamos: que aparte de denunciar y poner la otra mejilla, no se puede hacer nada, y encima alguien nos comenta, también extraoficialmente, que la gran OPERATOR atiende los requerimientos judiciales cuando ella considera, porque claro, para eso es OPERATOR, más allá del bien y del mal. Nos suena, ¿verdad? En cualquier caso, el segundo día hemos vuelto a cortar a Vicente, o se ha quedado otra vez sin IP disponibles… o simplemente se ha cansado de ACME y ahora está con otro objetivo…

DIA 3

Ampliamos denuncia en Juzgado de Guardia aportando las nuevas evidencias, sobre todo las direcciones IP que recopilamos durante la noche de ayer. Durante el día seguimos dándole vueltas a la situación y a la cara de imbéciles que se nos queda sin poder hacer nada más que filtrar una dirección IP tras otra. ¿Cambiará Vicentín de IP automáticamente? ¿Lo hará para seguir atacando a ACME, o ésta será una de múltiples tareas? ¿Utilizará sistemas intermedios o tira directamente desde la IP de su casa? ¿Por qué siempre a la misma hora? ¿Es cuando llega a casa o cuando se queda solo en la oficina? ¿Nos estará distrayendo con este ataque tonto mientras utiliza otro vector de entrada a ACME? Para descartar esto último y con el modo paranoia ON, se moviliza un equipo auxiliar al GIR que tiene por objeto revisar todos y cada uno de los sistemas de ACME, empezando por los que están en DMZ y siguiendo por los internos. Tras varias horas de trabajo, ni rastro: no hay nada anormal más allá de lo que hemos visto. Vicente sólo dispara a un objetivo, lo hace sin esconderse y aunque le filtremos, él cambia de IP y en segundos o minutos sigue su trabajo…

Por supuesto, a su hora habitual, Vicente vuelve a la carga por tercer día consecutivo. Seguimos metiendo las IP de la línea ADSL en nuestra lista negra y mirando cómo cambia de dirección cada poco tiempo, hasta cuatro o cinco veces. No podemos hacer más, nos dicen. Situación estúpida donde las haya, pero es todo a lo que podemos aspirar, aunque ya empiezan a surgir en el equipo malas ideas (que como somos buena gente, no llegamos a ejecutar -aunque no por falta de ganas-). Y también por tercer día consecutivo, tras varios cambios de direccionamiento, Vicentín se cansa y deja de atacar… Mañana más.

Introducción

Hace tiempo que se han puesto de moda las cámaras de videovigilancia conectadas por IP. Estas cámaras permiten su visualización desde cualquier parte del mundo. Esto se traduce en un problema: El Gran Hermano.

Mucha gente adopta esta medida de vigilancia por su facilidad de instalación y uso. Además de esto, la comodidad de estar fuera de casa y poder controlar todo lo que ocurre en el hogar.

Pero, ¿qué ocurre cuando no sólo lo instala un particular en su casa, sino que también lo hacen las compañías? Por poner varios ejemplos; una tienda, un restaurante ó cafetería, el hall de un hotel…

Como bien expresó Antonio Villalón en su post, nos quejamos del tío Sam, nos sorprendemos cuando salen a la luz ciertas noticias… pero no pensamos en que cuando vamos de compras o a una cafetería estamos siendo controlados en todo momento.

[Read more…]

[Read more…]

Siguiendo con la tecnología punta, que comencé con aquellas placas de la Nixdorf 820/15 en mi artículo anterior, y como parece que resultó interesante, hoy quiero mostrar otro proyecto que pone en evidencia la evolución de la electrónica en un lapso de tiempo no muy largo, pero que ha posibilitado los avances y la miniaturización de los equipos hasta extremos que solo las películas de James Bond podían imaginar.

La situación era la siguiente: 1984, en una compañía que fabrica ropa, principalmente la ropa tejana, con un mercado muy competitivo en el que aparecen nuevas marcas continuamente y en el que los costes de producción deben limitarse al máximo para sobrevivir en el mercado, nos encontramos con que los muestrarios de prendas para la temporada del año siguiente se han de fabricar con 12 meses de antelación. Ello supone comprar o fabricar el tejido necesario que, muchas veces viene de sitios como la India, Paquistán, etc (años 80 ojo) y ello conlleva adquirir compromisos de consumo y fabricación de dichos tejidos, que al final han de gustar o no gustar a los clientes de las tiendas de moda que van a marcar lo que “se lleva” en la temporada.

Pues bueno, en esta situación, el fabricante prepara el muestrario de prendas, lo distribuye a sus vendedores que viajan a lo largo del país y van recogiendo pedidos sobre blocs de papel diseñados para ello. En el fin de semana, los vendedores -o estudiantes contratados por ellos- , codifican los pedidos con las series, modelos, tejido, color y conjunto de tallas que el cliente ha pedido. El objetivo es tenerlo listo para enviarlo por correo (no hay mensajeros) a la oficina más cercana (la de Valencia en este caso) y allí se introducirán en el sistema (IBM/38) de la época y una vez depurados los errores de codificación y de catálogo (no todas las combinaciones de serie-modelo-tejido-color y talla eran aceptables), se obtiene la información necesaria para ver qué es lo que “se lleva” o “no se lleva” en la temporada siguiente, o sea, que tejido y en qué cantidades habrá que pedir para atender los pedidos. Este proceso tomaba entre dos y tres semanas y era crítico para la buena planificación de recepción de materias primas, planes de fabricación, gestión de almacenes y distribución del producto a los clientes antes de comenzar la temporada dichosa.

En esta situación, el equipo de Informática de la empresa, se puso a indagar en la tecnología disponible para acortar en lo posible la gestión de esos pedidos que marcaban la temporada y el coste de la misma. En estos años, trabajábamos con los “nuevos” PCs de IBM, con pantalla verde, dos unidades de diskette de 5-1/4 pulgadas y los más afortunados tenían un disco duro de 16 o 32 MB, menos fiable que una cafetera, pero que daba su servicio con la primera hoja de cálculo “Lotus 123” y algún “Writer” como editor de texto.

Buscando en el mercado, el director del departamento encontró el EPSON PX-8, un ordenador “portátil” de la época en el que había una pantalla líquida con 8 líneas de 80 caracteres y una unidad de micro-casete que podía almacenar datos. El problema era como meter y mantener el catálogo de productos dentro de este equipo con apenas 128K de memoria y sin disco duro y como gestionar pedidos de productos con hasta 17 tallas posibles en cada línea. Aún así, el director de la compañía, con gran visión de negocio, dio el visto bueno para el proyecto y los técnicos nos atrevimos con él, teniendo yo la satisfacción personal de ser el responsable del proyecto desde el lado móvil, y compartiendo con el equipo de programación de sistemas el desarrollo de los procesos.

Los programas iban en una EP-ROM de 32 K y el catálogo se actualizaba en la transmisión de cada noche, sobre memoria. Los pedidos se recogían en el casete. La idea era dotar al EPSON PX-8 de un catálogo que el programa gestionase mostrando las combinaciones de serie-modelo, etc. válidas y depurando así el pedido en el momento de su captura. El vendedor debía usar el PX-8 en lugar del block de papel. Esto fue duro, muy duro, y el soporte recayó en mi persona, con lo que el manual de usuario (en papel claro está), las sesiones de entrenamiento, la puesta a punto del software, etc. fueron un proyecto muy interesante y una gran experiencia para mí.

Los pedidos se recogían en el PX-8, se imprimían en una impresora EPSON de papel térmico y se le entregaba una copia al cliente, que recibiría el pedido en el formato “oficial” después por correo, tal como lo generaba el sistema central.

Durante la noche, los pedidos recogidos en la jornada de trabajo, eran transmitidos por teléfono analógico, conectando un acoplador acústico al teléfono del hotel (lo llamábamos “zapatófono” y si miráis las fotos veréis porqué), en el que se encontrase el vendedor ese día y donde muchas veces, la centralita del mismo introducía ruidos y provocaba errores en la transmisión, por lo que les tuvimos que dotar de un amplificador de sonido que sustituía al micrófono del teléfono, abriéndolo y cambiando su micro por el nuestro. El problema vino cuando muchas veces, después de un largo día de trabajo, el vendedor olvidaba recuperar el amplificador y se llevaba en su lugar el micro del teléfono del hotel. El nuevo inquilino de la habitación notaría una buena mejora en la comunicación, pero el vendedor se había quedado sin su ayuda.

Otro problema tedioso que se repetía cada día, sobre todo en determinados vendedores, era el saber enchufar los dispositivos entre sí, no doblando las patillas de los micro-conectores al equivocar la entrada elegida o la posición correcta para conectar, y presionar la clavija intentando que entrase. El intercambio de cables con clavijas “espatarradas” era continuo. En vista de ello, se me ocurrió una solución, busqué un maletín grande y ligero en el que diseñé una espuma interior con los conductos requeridos para mantener los cables y dispositivos conectados. El alimentador del EPSON, la impresora y el cable de comunicación con el zapatófono, quedaban fijos dentro de la maleta y así se solucionó, solo que, las protestas de los vendedores por llevar la maleta con ellos y custodiarla, arreciaron, pero al final, el éxito del proceso calmó los ánimos.

Para la transmisión, se conectaba el PX-8, vía acoplador acústico y se enviaban los pedidos al sistema central de la red Mark III de General Electric, donde se recogían y a primera hora del día siguiente (7 de la mañana) se transmitían al sistema 38 de nuestro centro. Allí se hacía el proceso estadístico y se presentaba a la dirección los resultados de la campaña de ventas, decidiendo entonces que productos iban a venderse y que otros debían desecharse del catálogo. Pasamos de tres semanas de latencia de los pedidos, a tres días, eso sí con un gran esfuerzo y un “Smart Computer” de los años 80. El impacto en los vendedores de la competencia (se conocían todos y se encontraban en los mismos hoteles) fue genial, mostrando su asombro por la osadía de nuestros vendedores haciendo trabajar aquella cosa de EPSON. Tengamos en cuenta que la informática casera de la época era el Sinclair ZX y algún Amstrad asequible, los Pcs de IBM y los Apple eran carísimos.

Os adjunto unas fotos del sistema, el zapatófono y el “Smart Maletín”. Ah por cierto, luego se instaló en las oficinas de Francia, Inglaterra y Alemania, todo un éxito para la época.

Recientemente revisando los resultados de salida que Nessus sacaba tras una auditoría de vulnerabilidades a un servidor FTP nos dimos cuenta de lo siguiente:

En principio nada destacable, ninguna vulnerabilidad relevante, pero como siempre, procedemos a una revisión manual de los resultados.

El caso es que si examinamos el banner de salida de este servidor nos muestra lo siguiente:

[Read more…]

Como muchos ya sabéis se ha publicado la nueva versión de la ISO/IEC 27001:2005 bajo el nombre ISO/IEC 27001:2013.

En esta revisión la norma ha sufrido grandes cambios destacando por ejemplo la flexibilidad a la hora de elegir metodologías de análisis de riesgos o mejora continua, la estructura de documentación, nuevos controles, nuevos conceptos, etc. pero sobre todo en su estructura pasando a utilizar el modelo del “anexo SL” del que ya habló nuestro compañero Alberto Olmos en estas entradas: Sistemas de Gestión Integrados: anexo SL (I), Sistemas de Gestión Integrados: anexo SL (II).

Una vez publicada la nueva norma, se ha abierto un periodo (presumiblemente de dos años) durante el cual las organizaciones que deseen seguir certificadas deberán adecuar sus SGSI a la nueva versión. Esta “actualización” podrá consolidarse durante una auditoría de seguimiento, de recertificación, o incluso mediante una auditoría extraordinaria si se considera oportuno.

Muchos se preguntan qué va a suponer este proceso de actualización y si van a tener que rehacer todo el sistema de gestión. La respuesta no es sencilla: depende (si no esté post no sería tan largo). Si bien a nivel técnico no parece que la actualización vaya a suponer ningún trauma, en lo que respecta a la organización del SGSI sí que existen muchas consideraciones a tener en cuenta por lo que analicémoslo por partes.

[Read more…]