La posibilidad de backdoors en productos de software y hardware: la ruleta

Esa sensación de que algo no anda bien
Desde ayer u hoy (según tu zona horaria), el consenso general en foros y chats entre gente del ambiente de seguridad IT por todo el mundo es que si corrés un producto de software o hardware, relativamente popular (digamos por arriba de las decenas de miles de usuarios), y si el producto es un componente de infraestructura (sistemas operativos, bases de datos, software de CRM/ERP, gestión documental, servidores, SANs, switches de core, firewalls, dispositivos de threat management, appliances de correo/antivirus, etc. etc), cuanto más caro sea, mejor (o peor en realidad); y si además el producto fue fabricado en algún país con leyes poco favorables a la privacidad de datos, las chances se dan a favor de que en algún momento, alguien descubra que la mayoría corrieron o corren un backdoor y/o vulnerabilidades críticas explotables remotamente, como máximo, o como mínimo backdoors y/o vulnerabilidades explotables localmente (con previo acceso físico y/o acceso con permisos bajos, de usuario). Ellas codeadas por el mismo fabricante, con las consiguientes dificultades que ello implica (legales, prácticas, de management, de seguridad, etc. etc.).

La posibilidad de permanecer indiferente está siendo desafiada ahora mismo por una certeza probabilística, "tienen que estar backdoreados", "alguno debe estar backdoreado", y el premio va a ser grande, en reconocimiento de la comunidad de seguridad y en negocios + éxito económico para quienes descubran primero cuales son los productos de soft y hard que tienen backdoors funcionales (o inclusive, si en versiones viejas los tuvieron).

Ni hablar de que los "chicos malos" del ambiente de seguridad IT de siempre (desde los script kiddies hasta - especialmente - las grandes organizaciones criminales ), son los primeros que se anotaron en una tarea, que si bien puede ser desafiante desde lo económico (por la inversión necesaria en I+D), puede devolver ganancias extraordinarias si pueden descubrir un mínimo de uno o dos productos de soft/hard backdoreados o con vulnerabilidades plantadas.

Ya hay evidencia más que suficiente de lo fiable de estas previsiones, devenidas de las experiencias de los últimos tres años: caros appliances de threat management con backdoors, hardware de storage con backdoors, etc.

Cómo sabemos que es un backdoor

¿Cómo sabemos que es un backdoor y no una "característica oculta al cliente" (por más anti-ético que esto sea igualmente)?

Cuando es un backdoor en toda la regla, los usuarios legítimos del sistema (incluídos los de mayor privilegio: los administradores), no tienen ninguna evidencia en el sistema de que este ha sido accedido y/o sus recursos han sido utilizados por un tercero no autorizado.

No hay logs, los procesos no figuran en la lista del sistema, el tráfico de red originado desde estas sesiones se oculta, no hay evidencia de accesos realizados en ninguna interfaz gráfica, los rastros de archivos temporales en el sistema están ocultos, sino es que directamente se borran automáticamente al terminar la sesión iniciada desde el backdoor.

Inclusive tenemos el caso de una línea completa de hardware - sumamente costoso - de storage SAN que corre una copia completa del sistema operativo que corre la SAN (justo al lado del sistema operativo que usan los administradores de la SAN), copia que estaba oculta - hasta hace muy poco - y era totalmente desconocida para los dueños de esas SAN, y clientes de una empresa de las "grandes", que figura entre varias de las cuales escuché opiniones como "son de confianza", "son de prestigio mundial, no se van a ensuciar así", etc.

La gran ruleta

En fin, solo queda sentarse a esperar a ver cual de todos los jugadores del tablero de la seguridad IT a nivel mundial hace el primer descubrimiento, si es que llegan a hacerlo, ya que sabemos que están compitiendo contra los mejores hackers del mundo, aquellos que pueden hackear millones de sistemas simultáneamente y no ser detectados más que unas pocas veces (sobran dedos, etc.), de entre millones de trabajos exitosos (y que pasaron completamente desapercibidos), simplemente por eso les vale la pena el desafío.

¿Quiénes serán los primeros? Algun/os bancos importantes? Tal vez alguna empresa de energía? Filtraciones masivas de información estatal, provincial, judicial, fiscal, militar, etc.?

Seguramente cualquiera que esté usando software o hardware construído en países con leyes poco favorables a la protección de datos privados es ahora mismo un lugar más en una gran ruleta, que ya empezó a girar. A alguno le va tocar.

La posibilidad de backdoors en Linuxes comerciales

Una hipótesis

Similar al caso de varias empresas (la de las ventanas es la última), y el que se vean obligadas a colaborar con cualquier pedido para "facilitar futuros accesos que puedan ser solicitados" a sus servicios y productos, encontramos que los Linux comerciales que tienen sus empresas creadoras con sede en países que tienen leyes desfavorables para la privacidad de datos  podrían estar igual, potencialmente backdoreados.

Muchos creen que no se puede, sin embargo se olvidan que quien controla la infraestructura de actualización de paquetes, controla qué se instala en el sistema operativo.

Los updates "oficiales" de los Linux comerciales se hacen contra un grupo de IPs puntuales, que son el front-end de una infraestructura mayor que brinda updates de paquetes a todo el mundo vía Internet.

En el caso de un Linux no comercial como Debian, los servidores de actualización pueden estar en cualquier IP y país. Si queremos que los updates se hagan eligiendo al azar servers de Brasil, China, Chile, Uruguay, etc. y solamente saltando entre esos servers, se puede hacer fácilmente.

De todos modos, al estar tan replicados los servers de update de Debian a nivel internacional sería muy difícil lograr ubicar un software de backdoor o alguna vulnerabilidad crítica en algun paquete de Debian, sin que eventualmente sea detectado. Como ya pasó antes:

Random Number Bug in Debian Linux

Debian Bug Leaves Private SSL/SSH Keys Guessable

En una infraestructura privada de update de paquetes las cosas son muy diferentes, cada una de las IP de front-end puede redirigir el tráfico hacia cualquier servidor interno de la infraestructura, que puede estar ubicado en cualquier país, inclusive esos que tienen "issues" con la privacidad últimamente, de hecho, muchas infraestructuras privadas de actualización están totalmente localizadas fronteras adentro de estos países con "issues".

Problemas posibles

Una infraestructura privada de actualización de paquetes va a tener problemas para desplegar un software de backdoor a nivel global, ¿cuales? el que casi seguramente dicho acto será detectado en algún momento, por varios motivos técnicos, pero si en cambio se ataca a un solo cliente, a unos cuantos servidores puntuales de entre millones, la chance de ser detectados por comparaciones y análisis - de paquetes, de fechas de update, de conexiones realizadas, de tráfico que atravesó la red en X cantidad, en X fecha, para X IPs hacia Y IPs para unos servers sí, pero para otros no, para una empresa sí, para otra empresa no, etc. -  es mínima, casi nula inclusive.

El ataque dirigido

Es decir, tiene mucho más sentido un ataque dirigido, después de todo los Linux comerciales pueden efectivamente tener en algun lugar un código identificador únido (similar a un user id), y se lo puede emparejar con otros datos importantes: Nombre y ubicación del cliente*, IPs usuales desde donde se producen las conexiones a la infraestructura, etc.

* Al hablar de "cliente" aquí, me estoy refiriendo a "Empresa SRL", "Banco de la Región SA", "Ministerio de lo Quesea de la Pcia. de LoQueSea", "Subsecretaría de LoQuesesa", "Administración Federal de Manejo de lo Quesea", etc. y sus datos puntuales: dirección y código postal, teléfono, datos de contacto con el cliente (telefóno directo de un contacto, mail del contacto, horarios de disponibilidad), etc.

[Las IPs de origen de las conexiones suelen ser estáticas, por ser servidores. De todos modos, un identificador único va a permitir asociar un server/workstation que se conecta desde una conexión dinámica a los datos de un cliente específico, por cierto.]

Si se apunta a un cliente específico a backdorear, cuando el cliente se conecta para actualizar su instalación, es redireccionado a un server "especial" de actualización, donde el primer paquete que va a pedir actualizar va a ser el mismo cliente de actualización. Luego de terminar de instalar el nuevo cliente de actualización, este ya contiene un poco del código necesario para hacer que aunque se descargue un software X y sus chequeos de integridad fallen, igualmente se instale, sin informar de ninguna manera al cliente (sin dejar rastros de los fallos de chequeos de integridad de los paquetes a nivel de logs, etc.etc.). Y un componente más: la posibilidad de bajar e instalar un paquete transparentemente, sin que dicha descarga/instalación sea visible de cualquier manera para el usuario, y sin que quede tampoco registro alguno de esa tarea a nivel de logs o interfaces gráficas.

En criollo, el usuario no se va a dar cuenta de nada, a menos que esté monitoreando directamente lo que hay en la memoria del sistema operativo, los procesos activos y al mismo tiempo el tráfico de red, justo en el momento que supuestamente se descarga e instala 2 mb de paquetes (y ocupan 4 mb en storage local), pero en realidad bajan 2.4 mb (y en realidad ocupan 6 mb en storage local).

Luego de esto, en la siguiente actualización (que va a ser disparada casi de inmediato, o quedará scheduleada para la siguiente iteración de actualizaciones), si este cliente target se conecta, no accederá a ningun servidor estándar de la infraestructura de actualización (que contiene paquetes libres de todo backdoor), sino a un servidor "especial" que puede llegar a contener "actualizaciones" que serán instaladas transparentemente sobre las versiones actuales, inclusive sin llegar a modificar las versiones del software que se puede ver desde las herramientas estándares. Esas "actualizaciones" pueden contener el software que sea, desde un backdoor que habilite un servicio "fantasma" con SSH corriendo en un puerto alternativo (no el 22), hasta un túnel HTTP, DNS, o de cualquier protocolo que tenga comunicación a Internet.

El trabajo

Desde ese punto lograr la comunicación desde Internet hasta dentro del server es trivial y los métodos son comunes: port knocking, que el backdoor solo responda si hay intentos de conexión desde un rango de IPs específico (esto evitaría esos servicios "fantasma" sean visibles para escáneres como Nmap y similares), que los servicios "fantasma" solo se activen (sean arrancados y se carguen a memoria), en un rango horario limitado (de 4 a 5 de la mañana), cada X cantidad de días, y solo si encuentran una respuesta en servers de C&C (comando y control), prosigan con más actividades, etc. etc.

La transferencia - masiva si es necesario - de datos salientes se gestiona igualmente por métodos comunes: en gral. se va a buscar algún protocolo encriptado que tenga tráfico saliente y se lo va a usar, para evitar que los dispositivos de threat management que puedan estar inspeccionando el tráfico de protocolos encriptados, se suele recurrir a técnicas diversas (en gral. esteganografía en lo que haya "en movimiento" en el tráfico: audio, video, documentos, etc.). Eso claro, si es que los mismos dispositivos de threat management no tiene backdoors intercontruídos que simplemente se accedan y permitan desactivar contramedidas y detecciones varias, antes de iniciar el tráfico de datos saliente masivo.

Si hace falta, la transmisión de datos masiva - GBs de datos - se puede realizar por etapas o aleatoriamente, enviando unos pocos GBs de datos de a poco, durante días o semanas, hasta completar el trabajo.

Si el grado de securización de la infraestructura es bajo y/o manejable, ello inclusive podría llegar a acelerar los tiempos prescindiendo de diversas tareas de ocultamiento y prevención de detecciones.

La despedida

Una vez terminado el interés en el objetivo, la misma infraestructura de actualización puede fácilmente devolver a los paquetes instalados a su estado anterior, y dejar efectivamente cero rastro de la intrusión dentro del server. A lo sumo, el tráfico saliente - y en protocolos y puertos totalmente autorizados a hacerlo - del server es lo único podría permitir pinpointear una intrusión de este tipo, luego de eliminado todo rastro de los binarios que la permitieron.

Luego de esto, al revisar el server no se va a detectar ninguna diferencia entre los binarios instalados y los oficiales, son los mismos.

El trabajo puede durar desde pocos minutos a varias semanas, inclusive intercalando ataques con períodos "limpios", offline, donde los servers atacados son limpiados y devueltos a su estado original, para luego ser atacados de vuelta.

Contramedidas?

Si hubiera otro tipo de medidas de seguridad para prevenir el uso de binarios alterados, un HIDS (HostIDS), fácilmente podría ser pinpointeado por un componente de software "fantasma" antes de instalar nada más que el update del cliente de actualización que arrancara totalmente autorizado (y no va a disparar ninguna alarma porque es una versión nueva justamente, y es esperable que los nuevos binarios en disco disparen alarmas en el HIDS, que rápidamente van a ser descartadas como "falsas alarmas", si que directamente ya no hay reglas que impiden que el HIDS dispare alarmas cuando se actualiza el cliente de actualización), y luego efectivamente desactivado, inclusive para ello hiciera falta "actualizar" los binarios y librerías del HIDS.

Conclusiones

Es decir, quien controla la infraestructura de actualización y además cuando los servidores de actualización son privados, y no hay acceso público o semipúblico que permita controlar qué hay en esos repositorios en cualquier momento y además controla el código fuente del cliente de actualización, está en perfecta posición para montar una infraestructura de backdoring y troyanización perfectamente efectiva, pudiendo entrar, instalar, borrar y luego salir de cualquier server conectado a Internet, sin que los administradores (de sistemas, redes, seguridad, etc.), a cargo de los servidores lleguen a darse cuenta siquiera de que hubo algún acceso no autorizado.

La confusión: bajo nivel jerárquico no implica bajo nivel de expertise técnico

Miraba la noticia del link de abajo y pensaba, "es un malentendido, capaz se confundieron con el tipo". Es decir, lo subestimaron en vez de evaluar objetivamente el nivel de amenaza que representa un especialista de alto nivel técnico, muy experimentado. Es un error organizacional bastante común, muy explotado por los mejores hackers (esos que no salen por ningún diario).

Explico: cuando un administrador de sistemas experimentado de buen nivel empieza a trabajar en una organización muchas veces arranca en posiciones de bajo nivel jerárquico, más allá del nivel de remuneración y el nivel técnico del laburo que haga.

El bajo nivel jerárquico del administrador en una organización puede ser malentendido por las personas en otros cargos jerárquicos superiores de áreas no informáticas (gerenciales típicamente), como "este tipo/a no tiene suficiente currículum / experiencia / conocimiento para hacer el trabajo de sus jefes técnicos, el de los  líderes técnicos, ni el de otros puestos importantes"

La realidad es que mucho laburo se acepta de lo que hay disponible, y las mejores posiciones, las mejor pagas, con mayor responsabilidad ya suelen estar ocupadas cuando un nuevo administrador llega a una organización.

¿Eso significa que la persona no podría hacer el trabajo de cualquiera de sus compañeros de equipo y jefes técnicos hasta el nivel más alto? En muchos, casos probablemente la respuesta es "no":

Un buen administrador de sistemas, experimentado y capaz probablemente podría sentarse en la silla del jefe, tanto como la del líder técnico, tanto como la de otros administradores (DBA, Networking, Seguridad, etc.), sin mucho problema y haciendo un trabajo bastante bueno, inclusive mejorando sustancialmente las decisiones de la persona que esté ocupando la posición en ese momento; tal vez, simplemente llegó luego de que se "repartieron" todos los puestos importantes.

Entonces, cuando ves un/a adm. de sistemas, redes, DBA, un developer con mucha "calle", etc. trabajando en una posición de bajo nivel jerárquico, ello no implica que la persona no pueda agarrar todos los sistemas de la organización (redes, servidores, bases de datos, etc.etc.), y administrarlas y gerenciarlas él/ella mismo/a.


http://www.washingtonpost.com/world/national-security/edward-snowden-bradley-manning-and-the-risk-of-the-low-level-tech-savvy-leaker/2013/06/11/f5e3ad72-d2c7-11e2-a73e-826d299ff459_story.html

Appliances de red seguros ¿son seguros? ¿lo podés verificar?

En otra disclosure de archivos del espionaje, hay un detalle importante: un hardware (Cryptofax), bastante caro, exclusivo y destinado a manejar comunicaciones seguradas y confidenciales, aparentemente viene "pinchado" de fábrica, incluyendo un backdoor.

Da para pensar cuanto hardware caro, sofisticado y destinado a manejar comunicaciones seguras fabricado por estos muchachos (o mandado a fabricar), incluirá backdoors.

Uds. saben cuanto hardware de este tipo hay instalado como firewalls/appliances diversos, en los bordes de las redes de bancos, financieras, empresas diversas, conectados directamente a Internet, e incluso en los peores casos, con conectividad abierta e irrestricta, para que el hardware se pueda conectar a ciertos servidores "seguros" en Internet para "actualizarse", y claro, para esto utiliza un protocolo propietario y comunicaciones encriptadas.

Ahora, hasta donde podés estar seguro de que ese appliance conectado a Internet que tenés en la red del banco - por ejemplo - está "actualizando algo" o en realidad alguien está usando el backdoor para acceder a la red interna del banco (del ejemplo), y hacer cosas que no tenés idea de cuales pueden ser (ni predecir si va a ser contraproducente o no para el banco).

http://www.guardian.co.uk/world/2013/jun/30/nsa-leaks-us-bugging-european-allies

El peligro de los sistemas de escaneo de matrículas y otras bases de datos no autorizadas

Los sistemas de escaneo de matrículas permiten construir bases de datos que sirven para dibujar el recorrido de un vehículo dentro de una zona geográfica donde haya una cierta mínima cantidad de cámaras de vigilancia conectadas al sistema de captura/escaneo/identificación de matrículas.

De ese modo, se puede lograr metadatos sumamente valiosos, y la infraestructura tecnológica necesaria para obtenerlos es relativamente barata y accesible en Argentina.

El problema está en que son una área gris para regular: es una base de datos que guarda información públicamente disponible (la matrícula, está a la vista de cualquiera en la calle), pero acumula metadatos extremadamente sensibles: debido a que el Estado tiene la información y la capacidad de asociar los datos de la patente (propietario, modelo, etc.), a las rutas habituales que recorre un vehículo que tiene determinada matrícula.

En Argentina el área gris se da en que este tipo de base de datos "derivada" no está totalmente regulada por la legislación, a lo sumo podría ser desafiada legalmente en algún momento, si es que los datos de tránsito/recorrido se llegaran a usar como prueba en un juicio.

Igualmente, esa noción es preferentemente evitada a como dé lugar, y los metadatos de recorrido se utilizan principalmente para la investigación y la obtención de otros medios de prueba de delitos, menos polémicos y/o con potencial para ser cuestionados legalmente; sino inclusive desatar una polémica en la opinión pública que lleve a regular un área gris que hoy no está regulada.

Ejemplos de posibles problemas:

La mayoría de estas bases de datos de uso "interno" en las fuerzas de seguridad son accedidas por operadores que no son especialistas, y muchos procedimientos rígidos y estrictos de securización del acceso deben seguirse para poder garantizar que el acceso a los metadatos del seguimiento de matrículas permanecen disponibles solo para aquellos específicamente designados, autorizados - y eventualmente auditables - para ello, y no se hacen disponibles para terceros ojos interesados, y peor aún, terceros interesados de los que no se tiene conocimiento y a los que nadie va a auditar.

El problema está dado en que las bases de datos actuales están inmersas en sistemas altamente conectados, y una base de datos de la que pocos o casi nadie tiene conocimiento se presta especialmente al acceso no autorizado, justamente porque muchos usuarios de las redes y sistemas que podrían llegar a estar conectados con la base de datos, no tienen real noción de la importancia de equivocarse y/o saltarse mínimas reglas de securización.

Por ejemplo, son clásicos ejemplos de des-securización de instalaciones y redes informáticas seguras los siguientes:

- Puertos USB disponibles en las terminales de acceso a la base de datos, donde cualquier persona puede conectar:

* Llaveros USB: que podrían contener troyanos construídos para trabajar en redes desconectadas (con "air gap", que no tienen ningun enlace de red con Internet) e ir montando una infraestructura de "dropboxes" de datos (donde van a guardar la información robada, que será transferida al llavero la próxima vez que se conecte), sino directamente ir instalando backdoors que intentan conectarse a Internet.

* Dispositivos USB con conectividad vía 3G o Wifi: de ese modo, una supuesta red segura se convierte inmediatamente en una red conectada a Internet, con el sinnúmero de posibles problemas que esto acarrea.

etc.

- Que se permita el acceso a las instalaciones con smartphones: las posibilidades de hacking son desde pocas a totales en el caso de un ataque dirigido que esté usando smartphones como "posta" para lograr sortear el "air gap" que mantiene a la red segura de la base desconectada.

- Que no haya ningún tipo de vigilancia, registro automático constante de vídeo para los operadores: Una medida de seguridad extremadamente simple de usar (prácticamente todos los supermercados de tamaños medio en adelante la implementan en sus cajas de cobro), si está ausente, genera la posibilidad deshusada de invalidar todas las demás medidas, por ejemplo: simplemente porque si algún operador perdió o le robaron las credenciales (idealmente 2-factor: credenciales-smartcards/contraseña), de ese modo si alguien más - inclusive otro operador autorizado - utiliza el acceso, no hay forma de individualizar a la persona que impersonó al operador.

etc.etc.

Conclusiones

Es decir, el potencial para el mal uso de bases de datos con metadatos sensibles es grande, y los problemas no tienen antecedentes - todavía - simplemente porque muy poca gente - ciudadanos comunes y "civiles" no vinculados a fuerzas de seguridad principalmente - está al tanto del potencial de este tipo de herramientas en los habituales juegos políticos, económicos, socio-económicos, etc.

En cuanto "jugadores" suficientemente motivados y bien financiados requieran acceder - legal o ilegalmente - a los metadatos, es posible que veamos aparecer los primeros casos - públicos - de mal uso de esas bases de datos.

Si en Argentina es casi una costumbre el que aparezcan expedientes completos - privadísimos y de acceso muy restringido - fotocopiados fuera de los juzgados, es de esperar que dado el valor superlativo de los metadatos (en comparación con un "simple" expediente por ejemplo), eventualmente dé lugar a que importantes intereses se muevan hacia intentar accederlos ilegalmente, lo que efectivamente va a ser mucho más sencillo si los ciudadanos ignoran totalmente el peligro y el valor real de esas bases de datos.

Links:
License-plate readers let police collect millions of records on drivers

¿Conviene guardar información sensible de organizaciones en Internet?

En vista de las noticias (ver el link al final de este artículo)  - altamente fidedignas por cierto - de acceso masivo a información privada (les dejo la política del tema para leer/discutir en otros posteos), la pregunta a hacer desde el punto de vista de seguridad de la información (que incluye a la seguridad informática), es si una organización que requiere asegurar - garantizar contra toda duda - la privacidad de sus datos debería optar por usar  y guardar información sensible en los diferentes servicios (correo, espacio de almacenamiento en Internet, aplicaciones, virtualización de infraestructura, etc.), en la nube que ofrecen muchos proveedores sospechados.

La información sensible es por ejemplo, la que maneja un estudio de abogados que tiene la representación de una persona con actividad política intensa (un diputado, senador, concejal, ministro, etc.).

Ese tipo de actividades puede convertir al representado en una persona de interés a monitorear por algún posible elemento oponente, y por ende sus comunicaciones privadas (correos electrónicos, documentos de texto, hojas de cálculo, etc.), podrían ser un objetivo de vigilancia, y el acceso ilegal a ellas podría ocurrir con más facilidad si su información sensible se guarda en "la nube" y/o en servicios de "nube" en Internet.

Costos

El costo de mantener la información sensible segura es un tema diferente a la necesidad de mantener la información segura.

Un servicio de nube puede ser más barato, más fácil de mantener seguro por casi nada de costo (el proveedor mantiene la seguridad), etc. Una infraestructura propia va a ser más cara en muchos casos (hay que comprar servidores, pagar sueldos, etc. etc.), pero en muchos casos, solamente con una infraestructura propia se podrá responder a requerimientos, reglamentaciones, disposiciones internas y leyes que dictaminen que los datos guardados por una organización deben ser privados.

En Argentina, la Ley 25.326 prescribe que los particulares que formen bases de datos que no sean para un uso exclusivamente personal deberán registrarlas (artículo 24), a la vez explicita  ciertos derechos de las personas que figuran en la base de dato y obligaciones de quien/es crearon la base de datos, algunas de esas obligaciones podrían no poder estar cubiertas en caso de accesos no autorizados de terceras partes a la base de datos. 

Por qué registrar una Base de Datos (sitio 
http://www.jus.gob.ar/datos-personales/registro/por-que-registrar-una-base.aspx


Ley 25.326
http://www.infoleg.gov.ar/infolegInternet/anexos/60000-64999/64790/norma.htm

"La Ley 25.326 y la difusión masiva de datos personales"
www.bcra.gov.ar/pdfs/eventos/Delitos_Pres_Pablo_Segura.pdf‎


Conclusiones

Claro que la respuesta a la pregunta del título es "NO".

Si tu organización maneja información sensible, lo ideal es que tengas infraestructura propia, ejemplos de org. que manejan información sensible: un banco, una aseguradora, un supermercado, una clínica, una obras social, un consultorio médico, un estudio de abogados / contadores / escribanos.

Ciertamente, la noticias de los últimos días vuelven irrecomendable - desde el punto de vista del profesional IT - el uso de cualquier servicio en la nube para guardar información sensible (APIs, mails, storage, servidores virtuales, etc.). La lista de clientes/organizaciones que no deberían usar servicios en la nube prácticamente incluye a cualquier organización que no sea un pequeño comercio (las grandes empresas tampoco deberían guardar sus datos en la nube).

Links:

Edward Snowden: the whistleblower behind the NSA surveillance revelations

The 29-year-old source behind the biggest intelligence leak in the NSA's history explains his motives, his uncertain future and why he never intended on hiding in the shadows

http://www.guardian.co.uk/world/2013/jun/09/edward-snowden-nsa-whistleblower-surveillance

Firewalling y ciberguerra

Firewalling y ciberguerra

Guerra informática (cyberwar)
http://es.wikipedia.org/wiki/Guerra_inform%C3%A1tica

Hace un tiempo, varios países grandes están construyendo grandes infraestructuras de firewall alrededor de sus redes principales, de modo que si fuera necesario, podrían clausurar el acceso desde Internet hacia cualquier host dentro de sus redes nacionales.

Muchos autores de artículos y blogs expresan constantemente un único punto de vista no técnico respecto de este tema, cuyo foco es la masiva capacidad de auditoría y censura de las comunicaciones que se obtiene al armar esas infraestructuras.

Por ejemplo:
"China levanta su ‘Gran Cortafuegos’ para proteger al régimen de la Red"
http://internacional.elpais.com/internacional/2012/10/26/actualidad/1351278234_650074.html

Aparte de lo anterior (y su nivel de veracidad, cualquiera sea), hay otro punto de vista, también obvio pero con un foco técnico: la "cyberguerra".

Los ataques a infraestructuras informáticas auspiciados por países están en auge desde hace bastantes años, simplemente que luego de los incidentes de 2007 y 2008:

http://en.wikipedia.org/wiki/2007_cyberattacks_on_Estonia
http://en.wikipedia.org/wiki/Cyberattacks_during_the_2008_South_Ossetia_war


http://www.telegraph.co.uk/news/worldnews/europe/georgia/2539157/Georgia-Russia-conducting-cyber-war.html
http://bits.blogs.nytimes.com/2008/08/11/georgia-takes-a-beating-in-the-cyberwar-with-russia/

se hizo evidente para la opinión pública y al poco tiempo se hicieron públicos diversos esfuerzos de orden nacional en muchos países para construir infraestructuras de firewalling alrededor de sus redes y con motivos de peso, como se puede advertir en la escalada de incidentes hasta el presente:

http://en.wikipedia.org/wiki/Cyberwarfare#Incidents

Los ataques a infraestructuras informáticas son frecuentes y habituales, ya sea en operaciones directas, solo involucrando cyberataques o como apoyo para otras acciones militares y/o de inteligencia.

Los ataques "indirectos" también son otra gran motivación para el montaje de infraestructuras de firewalling de borde alrededor de redes nacionales:

http://en.wikipedia.org/wiki/Stuxnet
http://en.wikipedia.org/wiki/Flame_(malware)
http://en.wikipedia.org/wiki/Duqu


Plazos
Es importante considerar también que la mayoría de los riesgos residen en el largo plazo. Los ataques a infraestructuras informáticas que pudieron ser rastreados hasta naciones estado particulares (al menos con un alto grado de fiabilidad), por ejemplo:

http://en.wikipedia.org/wiki/Flame_(malware)#Origin

tienen la particularidad de haber sido planificados, deployados sus recursos y efectivamente realizados a lo largo de varios años, desde el momento de la decisión, hasta la disponibilidad de la decisión de "atacar o no atacar":

"Several other details have been uncovered which suggest there was possibly at least one further spyware module based on the same platform in 2007-2008, and several other programs whose functionality was unclear between 2008 and 2010."

---

"Varios otros detalles fueron descubiertos los cuales sugieren que había posiblemente al menos un futuro módulo spyware  basado en la misma plataforma en 2007-2008, y varios otros programas cuya funcionalidad no estaba clara entre 2008 y 2010"

Fuente:
http://www.securelist.com/en/analysis/204792208/Stuxnet_Duqu_The_Evolution_of_Drivers


Hardware de Networking
El hardware de networking es un punto clave a analizar en este tema. 

Si bien hay varios modos de filtrar el tráfico de un equipo de networking y lograr determinar si incluye algun tipo de backdoor (simples puertos abiertos, alguna irregularidad en el manejo de algun protocolo de comunicaciones salientes que pudiera "pinpointear" OTRO protocolo de comunicaciones subyacente embebido, etc.); está el problema de que es muy difícil detectar si hay algun mecanismo subyacente de comunicaciones subrepticias si es que este está inserto directamente en el hardware mismo.

Justamente es la razón explicada para banear productos Huawei y ZTE en EE.UU.

"The task of finding and eliminating every significant vulnerability from a complex product is monumental. If we also consider flaws intentionally inserted by a determined and clever insider, the task becomes virtually impossible."

-------------

"La tarea de encontrar y eliminar cada vulnerabilidad significativa de un producto complejo es monumental. Si también consideramos las fallas intencionales insertadas por un infiltrado determinado y astuto, la tarea se vuelve virtualmente imposible."


Fuente:
http://intelligence.house.gov/sites/intelligence.house.gov/files/documents/Huawei-ZTE%20Investigative%20Report%20(FINAL).pdf


Un artículo relacionado (más legible) aquí:
"Congress accuses Chinese tech giants of un-American activities
Huawei and ZTE "cannot be trusted," says House Intelligence Committee."
http://arstechnica.com/tech-policy/2012/10/congress-accuses-chinese-tech-giants-of-un-american-activities/


Así, el incidente en progreso en relación a Huawei y Cisco está fundado en esa idea:

"Huawei ofrece acceso al código fuente de sus equipos en Australia"
http://www.europapress.es/portaltic/empresas/noticia-huawei-ofrece-acceso-codigo-fuente-equipos-australia-20121024115252.html

"Chinese Huawei, ZTE face new hurdles in U.S. market"
http://english.sina.com/business/2012/1008/514156.html

Claro, que no se puede evitar considerar el punto de vista económico donde otras acciones parecen apuntar más bien a una guerra económica encubierta como "preocupaciones de seguridad".

"China Unicom replaces Cisco devices over security concerns"
http://www.morningwhistle.com/html/2012/Company_Industry_1026/214830.html


Sin embargo, hay bastantes fundamentos lógicos en la idea detrás de la proscripción de compra de equipamiento de networking Huawei y ZTE en EE.UU:

http://www.heritage.org/research/reports/2012/10/china-cyber-threat-huawei-and-american-policy-toward-chinese-companies


Conclusiones
Como se puede ver la construcción de infraestructuras masivas periféricas de firewalling de alta resiliencia a ataques externos es una - relativamente - nueva necesidad para asegurar el correcto funcionamiento de los servicios informáticos a nivel nacional, más aún dada la posibilidad de atacantes hostiles financiados - sino plenos miembros de sus fuerzas de seguridad/militares - por un país, ya sean ataques subrepticios o directos.

La naturaleza típica de "caja negra" del equipamiento de networking y firewalling existente vuelve igualmente dicha seguridad parcialmente relativa, ya que dicho equipamiento podría contener insertas diferentes mecanismos de backdooring:

http://en.wikipedia.org/wiki/Backdoor_(computing)

y ello especialmente si hablamos de espionaje informático y operaciones subrepticias de infiltración (de equipamiento con backdoors) y sabotaje (en base a criterios preventivos: "si fuera necesario", "cuando sea necesario", etc.)  a largo plazo auspiciadas por naciones estado.

El - de vuelta, relativamente - nuevo escenario se configura en una escalada de riesgo de ataques informáticos, mucho mayor que cualquier amenaza preexistente, especialmente de particulares y organizaciones criminales, de una escala muy significativamente menor en relación con hostiles vinculados y respaldados por naciones estado.

Doble zero day de un año de duración

Siempre que converso sobre seguridad IT le digo a quien quiera escuchar que los especialistas de AR son de lo mejor que se encuentra en la red. Son así los "buenos" (AKA "security engineer") y también los "malos" ("black hat dude").

Respecto del zero day de Java (son dos en realidad), que estuvo asolando la red desde abril de 2011, sin que nadie se entere hasta hace unos días, encontré un informe muy bueno de Esteban Guillardoy (una "java guy" de Immunity Inc. en AR). Programador Python de título y fama, también, según leo en:

http://www.linkedin.com/in/eguillardoy


La cosa es que escribió este informe:
http://immunityproducts.blogspot.com.ar/2012/08/java-0day-analysis-cve-2012-4681.html

Donde se puede leer exactamente cómo funcionan estos zero days.


Sigo leyendo las noticias de hace un par de días con pro-pánico mensajes de "desactiven Java ya!!!!", pero al día de hoy ya tenemos solución en puerta y parches de Oracle disponibles, pasen, vean, descarguen e instalen..nos vemos en 6 meses de vuelta! ...broma :-)

http://www.oracle.com/technetwork/java/javase/7u7-relnotes-1835816.html


El racconto de ley: desde el 28 de Julio de 2011 existe este zero day (no sé si da llamarlo un "zero day" a algo que lo habrán explotado hasta reventar los servers), y en el mismo artículo podemos entrever cómo los kits se estuvieron "moviendo" en el inframundo del black hat hacking, probablemente proveyendo el zero day a los miembros de un círculo "de confianza", luego a los "de confianza" del círculo y así sucesivamente.

Obviamente la disciplina del secreto funcionó muy bien (durante un año++ completo), "saltando" la existencia del zero day por la "fuerza bruta" al haber tal cantidad de explotaciones que llamaba a los gritos a las empresas de seguridad para que prestaran recursos a investigar esa tormenta silenciosa de explotaciones.

El comentario y los detalles de los kits aca:
"Esteban Guillardoy, a developer at the security firm Immunity Inc., said the underlying vulnerability has been around since July 28, 2011."

http://krebsonsecurity.com/2012/08/java-exploit-leveraged-two-flaws/

Siempre que estoy en presencia de algun aspirante a security engineer que dice "estamos seguros porque está todo parcheado al día", me acuerdo de estas noticias y bue, no comment (no, no puedo sacarle el "aspirante" a quien se exprese de esa forma, sin alguna excusa razonable, como por ej. estar fuertemente medicado, etc.).

Layered Security please (for $DEITY sake), do the needful.
http://en.wikipedia.org/wiki/Layered_security

Malware y ataques destructivos y dirigidos

Finalmente luego de un par de décadas desde los viejos Stoned y especialmente el Michellangelo

http://en.wikipedia.org/wiki/Stoned_(computer_virus)
http://en.wikipedia.org/wiki/Michelangelo_(computer_virus)

Que atacaban la integridad de las computadoras en sí afectando el MBR de los discos, la vieja "moda" de infectar estaciones de trabajo para que definitivamente se "rompan" está volviendo.

http://en.wikipedia.org/wiki/Shamoon
http://es.wikipedia.org/wiki/Flame_(malware)

El nivel de sofisticación de lo último que se va encontrando en malware es razón suficiente para ser alarmante ya que las contramedidas usuales en funcionamiento son efectivamente consideradas y superadas por el malware, por ejemplo: se usa certificados robados y los drivers a instalar en Windows están firmados correctamente, por lo que el virus los instala sin problemas en el sistema luego de obtener permiso de Administrador.

Kits y Presupuesto
Una clave del problema actual son los kits disponibles en el mercado negro de malware en la red, del que son habitues los hackers y script kiddies locales. En gral. los kits tienen un costo no fácilmente pagable por un script kiddie, sin embargo, los trabajos por encargo no son desconocidos para los hackers locales ni carecen de antecedentes en la justicia (es decir, fueron delitos reales, detectados, investigados, algunos sancionados inclusive).

Un ejemplo de compra de kits para hacking en el bajo mundo en Argentina lo vemos en los delitos practicamente constantes (pero que se detectan y llevan a la justicia más o menos cada 6 meses), de robo de credenciales para homebanking.

Habiendo un trabajo por encargo de por medio, tenemos el issue de la financiación, es decir, el hacker va a tener acceso a un presupuesto que le va a permitir pagar por un kit.

Antecedentes:
Un prejuicio habitual entre los no expertos en seguridad IT es que los Kits son mayormente "assembles" (rejuntes), de código, impredecibles y mayormente inutiles. Claro, es una posibilidad, sin embargo la tecnología de Kits es muy vieja en el mercado negro y de vez en cuando algun kit en venta resulta ser muy bueno.

http://en.wikipedia.org/wiki/Virus_Creation_Laboratory


Multiplicando la capacidad de ataque
Los kits representan una particular amenaza, ya que potencian radicalmente la capacidad de un grupo pequeño de atacantes o inclusive de individuos.

Sin kits, un atacante debe investigar y desarrollar un malware suficientemente potente para ser efectivo y lograr el objetivo. Por ejemplo, borrar o destruir un par de miles de discos rígidos de las pcs de los empleados de una organización.

El kit dispara los tiempos: la compra de un kit le permite a un individuo y/o a un grupo pequeño de atacantes dirigir una ofensiva contra una infraestructura altamente protegida con probabilidades altas de éxito y con tiempos de preparación del ataque muy reducidos (días a semanas).

* Un kit aparece en el mercado y contiene vectores de ataque que van a funcionar por plazos muy cortos, de días a semanas como máximo. Se vende muy caro cuando es nuevo y va bajando de precio a medida que pasan los días (y el kit se vuelve potencialmete menos efectivo y/o totalmente inutil).

* Sin embargo, habiendo la suficiente motivación, el acceder a un kit precipita un ataque efectivo y altamente destructivo contra una organización, con la cualidad intrínseca de ser imprevisible.

* Es decir, hace 10 días atrás no existía el kit (ni los medios técnicos que posee), y no era viable atacar a ciertas organización, 10 días después, el kit es accesible y un grupo de hostiles puede pagar (a un hacker o varios), para que realicen un ataque dirigido.


Romper, no afectar
Hace tiempo, los virus no eran dirigidos, no se buscaba afectar a una empresa u organización en particular, hoy es muy distinto. Habiendo la suficiente motivación política (y tal vez ni siquiera económica), un grupo de interés puede buscar atacar e intentar destruir la infraestructura informática de una organización.

Por ejemplo:
"Saudi Aramco Oil Producer's 30,000 workstations victim of Cyber Attack"
http://thehackernews.com/2012/08/saudi-aramco-oil-producers-30000.html


Romper estaciones de trabajo, no servers ni redes y el MTTR
La actual motivación para atacar fuerte, rápida y decisivamente al mayor número de estaciones de trabajo de una organización "target" es simple: las infraestructuras centrales, redes y servidores están altamente fortificadas y aseguradas casi de seguro y hay un punto clave aquí: el MTTR.

*MTTR
http://en.wikipedia.org/wiki/Mean_time_to_repair

El MTTR de los puntos centrales de una infraestructura informática, servidores y redes, es casi siempre el más bajo posible de obtener con los recursos de la organización. Por ejemplo:

a) un ataque puede borrar completamente un server, luego, usando backups el server es restaurado en muy poco tiempo

b) un ataque puede hacer un takedown completo y muy rápido de un centro de datos, luego, es rápidamente reeemplazado por un centro de datos secundario.

[ Ejemplo de ataque para b): se puede realizar usando vulnerabilidades zero day de routers, y sobreescribiendo los firmwares de todo el equipamiento de networking de "core" de la infraestructura, fácilmente "ubicable" gracias a tener "a mano" la ubicación lógica de los routers con recursos como trazadores y análisis de configuraciones de ruteo (gateways, etc.)]

Si bien atacar los puntos centrales de una organización permanece como un objetivo muy deseable en los ataques dirigidos de la actualidad, es mucho más fácil y mucho más probable de ser efectivo directamente al afectar a un grupo masivo de estaciones de trabajo.

La motivación de "romper estaciones de trabajo" implica un impacto variopinto:
 - hace falta tiempo para reconstruir, digamos 2000 estaciones de trabajo;
 - hace falta tiempo para recuperar los datos privados, es casi seguro que si el malware logró permiso de administrador en una estación de trabajo el tiempo suficiente, los datos locales fueron destruídos efectivamente;
- hace falta tiempo - mucho en gral. - para recuperar los datos desde backup centralizado para todas las estaciones de trabajo afectadas por el ataque (típicamente la infraestructura de recuperación de backups va a ser saturada muy rápido, ya que suele prever una carga probable máxima mucho menor a la requerida para tolerar un uso masivo y repentino).
- La cantidad de información no backupeada en las estaciones de trabajo suele ser masiva (típicamente ubicada en directorios no añadidos a los sets de backup locales ni remotos), lo que implica que al perderse, la organización va a perder una fuerte capacidad operativa durante un tiempo considerable.
- etc. etc.

Es decir,

* el MTTR de la estaciones de trabajo es potencialmente mucho mayor en la organización, que el MTTR de los núcleos informáticos (centros de datos, servidores, redes, etc.).

* la cantidad de recursos organizacionales dedicados a proteger las estaciones de trabajo suele ser los mínimos posibles para la mayoría de las estaciones de trabajo (haciendolas potencialmente más vulnerables), mientras que los núcleos informáticos tienen cuantiosos recursos invertidos en protección (backup, redundancia, disaster recovery, etc.).

Es decir,

Los ataques dirigidos masivamente contra estaciones de trabajo no son una coincidencia o simplemente "el camino de menor resistencia" (al menos no solamente eso), sino que estamos en presencia de ataques calculados y pensados, con un alto nivel de motivación potencial dada por la altas chances de éxito en la búsqueda de afectar la infraestructura.

Arquitectura propietaria: servers Windows y antivirus+antimalware

Corriendo servers Windows, la política por default típica - del planeta? - implica correr necesariamente, obligadamente software antivirus y antimalware de nivel industrial en el server.

Hay diferentes enfoques que plantean lo contrario, principalmente adheridos a las posibilidades de "aislar" el server de cualquier comunicación con Internet. Sin embargo, inclusive dado un escenario perfecto de aislamiento de alto grado, muy propio de infraestructuras de alta seguridad, existe malware relativamente accesible en Internet que permite realizar ataques dirigidos muy eficaces usando jump-points como >

- USB keys: la víctima conecta USB keys a máquinas internas, el malware extrae la información, la guarda en la USB key, luego, cuando la víctima conecta el USB key en su PC hogareña, el malware se conecta a Internet y envía la información robada.

http://www.infosecurity-magazine.com/view/26761/indian-navy-secrets-stolen-and-sent-to-china/
http://www.indianexpress.com/news/china-hackers-enter-navy-computers-plant-bug-to-extract-sensitive-data/968897/0
http://www.theregister.co.uk/2008/07/01/japan_sensitive_usb_drive_lost/

- o inclusive infectando files que se transfieren habitualmente vía correo electrónico (fotos, etc.)

Etc.

Los motivos para instalar software antivirus y antimalware en un server Windows no faltan, más allá de cualquier aislamiento de seguridad lógico (vía routing, FW rules, filtering L7, etc.), o físico (que la red del servidor esté físicamente desconectada de cualquier red con conexión a Internet).

La policy de seguridad por default debe ser siempre instalar soft antivirus y antimalware en Windows Server.

Videos Ekoparty

Memory log > Videos de Ekopartys anteriores

http://vimeo.com/ekoparty/videos/sort:date

La última:

Ekoparty 2010 - 16 al 17 sept. 2010 - Bs.As. Argentina

http://www.ekoparty.org

Corriendo Nikto

Nikto es un scanner open source (GPL) que permite realizar test exhaustivos contra webservers que permiten detectar múltiples problemas incluyendo alrededor de 3500 archivos/CGIs potencialmente peligrosos y problemas específicos por versión de webserver en alrededor de 250 de ellas. Los ítems y plugins se actualizan regularmente y se puede actualizar el programa sin limitaciones (esto 28 de agosto de 2009).

Es particularmente interesante para los novatos el que Nikto detecte múltiples potenciales problemas en sus reportes de corrida contra X webserver, al mismo tiempo que otros programas,  comerciales incluso y bastante caros, detectan unas pocas o mucho menos vulnerabilidades que Nikto, para entender esto hay que sopesar algunas "advertencias" de Nikto que no son necesariamente vulnerabilidades. Para más datos leer la información disponible en el sitio.

Correr Nikto básicamente consiste en tener instalado Perl, que está en el 99% de las distros Linux y versiones de Unix del planeta...luego de eso queda bajar Nikto (así figura en el sitio):

"Posted by sullo | 10/06/2007 
Download
Version 2.03 .gz or .bz2 | Plugins & DBs"
 

Una vez descomprimido, vemos que las fechas de acceso de los archivos disponibles hoy (agosto-09), fueron modificados en sept. 2008 por última vez, lo que es interesante recordar cuando lo utilicemos para escanear por posibles problemas relativos a las vulnerabilidades más nuevas (falsos positivos, total indetección, etc.). Igualmente hay que sopesar esa evaluación contra la disponibilidad de los updates de Nikto y el que la lista de correo muestra actividad en el desarrollo (...tal vez habría que testear sitios con Nikto también desde una versión SVN reciente - para comparar outputs - pero antes habría que darse una vuelta por los threads de la lista para estudiar los cambios no documentados sobre la versión estable publicada...).

Correr Nikto es fácil, interpretar los informes es la parte complicada normalmente, pero brinda una linda salida HTML que se puede utilizar como base de informes regulares; incluso gracias a su interfaz de línea de comandos, se puede llegar a "cronearlo" (CRON), para que corra regularmente y envíe sus datos.

Los paranoicos a los que nunca les pasa nada pueden llegar a hablar de integrar en el CRON algun script que "grepee" el informe regular de Nikto buscando cadenas alarmantes relevantes (incluído el mail de alerta urgente), de las que podríamos llegar a hacer una buena lista, simplemente accediendo a los plugins (o al SVN de Nikto en su defecto). Algun avezado paranoico ha llegado a optimizar esto incluyendo la ejecución de Nikto+script de grepeo como reacción en un Nagios ante un cambio en el rendimiento de un website...en fin las posibilidades son muchas.

La documentación de Nikto: aquí 

Libros en los que pueden leer sobre Nikto: aquí (y pueden buscar con Google dentro de esos libros en la red...)

Una corrida típica de Nikto sería así:

./nikto.pl -h www.sitio-a-escanear.com -Format html -output informe.html

Desde el backstage de la SSHN4

Bueno, la SSHN4 (Seminario Security Hacking NEA 4ta. Edición), se mueve, la gente lo mueve. Esperemos el reconocimiento al esfuerzo de este año para superar por lejos la 3ra. edición y un par de glitches que tuvo (si recuerdan, critiqué el tema personalmente y ahora, dada la oportunidad, me puse a ver que podía hacer para que mejore).

Este año estuve colaborando con la organización, un aporte mínimo mío - en serio, no más de 5 hs. hasta ahora creo - a las sustancialmente mayores horas de esfuerzo de Seba del Prado, Pedro Cacivio y varias personas de Instel, para que la edición correntina de la SSHN salga "posta".

Recuerdo mucho una frase que leí ayer por el tema de Suse Studio: "Que tipos despreciables, quieren cobrar por el laburo que hacen" (es una ironía), y esperemos de nuevo que no sea ese el espiritu que mueva la opinión de la gente por el costo que tiene la entrada (30 mangos), también por eso quería contar un poco como es el backstage de la SSHN4.

Durante un par de charlas organizativas se tocó un tema importante en este tipo de eventos, personalmente trato de apuntar a mostrar y demostrar al público un alto nivel de detalles técnicos durante las charlas, creo que es la forma en que la audiencia profesional IT recepciona con mayor aceptación cualquier charla de temas IT...sin embargo mi punto de vista tiene un límite práctico: no toda la audiencia son profesionales de alto nivel de cualificación, hay muchos estudiantes, autodidactas en distintas fases de aprendizaje, público en general, etc.
En ese caso, la charla con mucho detalle técnico no "aclara" sino "oscurece"; así que conversando decidí presentar un tema simple en apariencia, pero que demuestra de modo amigable conceptos clave del hacking típico, el que supuestamente toda la gente de IT debería conocer, pero no siempre lo hacemos.

Las otras charlas de la SSHN4 también portan el espirítu de mostrar de modo simple temas complejos, para que todos vayamos, nos sentemos, escuchemos, y entendamos, no solo algunos pocos "gurues" o tipos que "saben un montón" (que también van a entenderlo).
Les recomiendo a los IT pro de alto nivel técnico y experiencia ir con ganas de hacer preguntas difíciles a los ponentes cuando llegue el momento, puede que se sorprendan gratamente por el nivel de las respuestas, ya que muchos ponentes tuvieron que hacer un esfuerzo considerable para simplificar su forma típica de explicar diversos temas, y cuando responden las preguntas, se van "de 1ra. a 6ta." en un tirón normalmente.

Hay varias charlas que pueden parecer ya rutinarias para los asistentes a otras charlas de Instel, pero que se renovaron y mantuvieron porque tienen buena acogida del público, y eso es importante (más teniendo en cuenta que tiene costo la entrada); hay otras charlas este año tocando temas interesantes, de las que puede rescatar importantes comentarios sobre tematicas de la seguridad IT actual.

Para los que recuerden ediciones anteriores y otros eventos en que escucharon a algunos ponentes locales, les recuerdo que el tiempo pasa y los muchachos siguen mejorando, algunos novatos de antes ya están maduros al día de hoy - hay un pibe, Seba del Prado que la tiene con la Wifi Security, ahora sabe un par de cosas ;-) - y tienen mucho que decir, y ahí tienen sus charlas, recomiendo obviar por esta vez las típicas subestimaciones basadas en haberlos escuchado "alguna vez", lo de la 2da. oportunidad aparte de linda frase está bueno como un modo entender que las cosas son dinámicas, todo cambia, y puede mejorar.

Entre varias visitas, destaco la presencia de Leonardo Pigner, un groso hacker para acortar las referencias; que es co-fundador de BASE4 Security, una empresa de seguridad IT en Bs.As., y también es uno de los fundadores de la conferencia de seguridad y hacking más grande de latinoamérica, la Ekoparty - www.ekoparty.com.ar.

Pueden ver algunas referencias de Leonardo en su perfil Linkedin y en su blog:

http://www.linkedin.com/in/lpigner
http://kungfoosion.blogspot.com/

Personalmente estuve conversando con otros grosos hackers del ambiente nacional, y la gente de la SSHN4 también, sin embargo no dan los recursos locales todavía para traer a toda la gente que tiene ganas de venir, pero que de momento, no pueden donar su tiempo sin alguna retribución que no hubiera sido posible brindar si se quería mantener accesible el costo de la entrada.

Recomiendo mucho aprovechar la data que tiró Sebastian del Prado en la lista de la Comunidad TIC e ir buscando en Google, nombre y apellido de los ponentes, ya que se van a encontrar con lindas sorpresas detrás de los nombres que muchos podemos no conocer.

Para cerrar, quiero contar que organizar estos eventos conlleva un buen número de horas de trabajo, se gasta plata de bolsillo propio, no se gana plata - al menos por ahora (aunque se gane unos mangos, no representa "buena plata" frente a la cantidad de horas trabajadas), la gente que lo hace se suma a otros, los invitados vienen de afuera a invertir su tiempo - y plata incluso - y no se van a llevar miles de nada, vienen a colaborar hasta donde pueden con la gente de IT local.
Hay diversas motivaciones personales y grupales, obviamente algunas económicas (no se puede vivir del aire, pese a los rumores al contrario), otras profesionales, y otras más, de fondo siempre, mucha - pero mucha - buena onda con la seguridad IT y ganas de hablar un poco de lo que nos gusta, seguridad, hacking, etc. ...en conjunto todo tira a "estar", acá, en el NEA, a crear un ambiente IT local groso y si llegara a salir eso, todos van - vamos - a salir ganando, por eso creo que es bueno apoyar estos eventos, llámese SSHN4 y otros anteriores Flisol, Whyfloss, etc. etc.

Ezines recomendadas: Tuxinfo e Insecurity

Que tal, les recomiendo bajar y leer estas e-zines.

Tuxinfo tiene mucha información técnica interesante mezclada con largas notas comentando eventos de software libre de todo el país (menos interesante si querés leer contenido técnico).Lo más interesante igualmente puede llegar a ser el ir viendo donde y qué personas están trabajando/usando software libre y en qué nivel, lo que es un indicador de como avanza constantemente el paradigma de software opensource en Argentina.

Insecurity es un lindo e-zine, básicamente es un compilado de temas y howtos que se pueden conseguir sin problemas en la red navegando foros y listas de correos de hacking y cracking. Lo interesante es que estén disponibles así, ordenados y explicados en español, mucho screenshot y explicaciones para novatos pero con buena profundidad técnica.

Recomiendo mucho la nota del nro. 3 "Jugando con cryptcat I y II", explicando en español y en simples palabras como obtener acceso vía shell (cmd.exe) a una máquina Windows (desde otro Windows) en Internet, y que utiliza herramientas simples que se pueden conseguir en 5 minutos y ejecutar desde cualquier Pc con conexión a Internet (no hace falta bootear un Backtrack). Básicamente usa Winrar, wget.exe, cryptcat y un par de tools más para mostrarnos y explicarnos como se accede a una pc en Internet sin otra tarea de parte del usuario que ejecutar un .exe.

Incluye explicaciones extra de temáticas "complicadas" (según novatos y "expertos" que lo quieren mostrar como cosas difíciles de hacer), como un método para (re)localizar las pcs con IPs dinámicas una vez obtenido el shell (cmd), incluso llega a mostrar como armar una botnet usando este boceto...así de fácil es, hay que saberlo.

A los sysadmins les queda la tarea para el hogar: cómo detectar en un análisis forense este tipo de trabajos luego de que alguien entró y salió, dejando un rastro cero (0), aparte de las conexiones efectuadas (que deberían quedar logeadas en un firewall bien montado). Por cierto que las conexiones vía cryptcat sí quedan registradas en muchos IDS/IPS actuales muchachos (los equipos con filtrado capa 7 ni siquiera dejan pasar este tipo de conexiones, no importa el encriptado...), aunque zafe de algunos antivirus todavía, hagan el update al 2005-09 gente (en cambio radmin, vnc y rdp pasan por muchos firewalls en conexiones salientes por ejemplo - por configuracion por default...).

Esta nota es interesante de leer porque le puede abrir los ojos a más de uno con respecto a que tan simple es hackear hoy en día, y también sirve para demostrar que novatos (script kiddies) con ninguna formación técnica pueden llegar a obtener niveles de acceso extraordinarios con respecto a lo que se podía lograr hace algunos años atrás; aunque la técnica del "troyanizado" de shells funciona desde los tiempos de los BBS/dial-up y el pkzip/pkunzip igualmente... 80's, 90's, casi puedo volver a escuchar los Guns, Metallica, New-Kids y Technotronic - más de uno su Mozart/Beethoven - de las sesiones nocturnas de esa época.

Los links prometidos (en google hay más):

Insecurity:
http://hispasystem.wordpress.com/2008/03/26/descargas-ezine-insecurity/

Tuxinfo:
http://www.tuxinfo.com.ar/

Framework para asesoría de seguridad - ISAAF

Que tal, típicamente las asesorías de seguridad recaen en la experiencia de los especialistas para asegurar su correcta implementación y para implementar métricas objetivas con las cuales evaluar los resultados del trabajo.

ISSAF es un framewok que busca estandarizar procedimientos y permitir a especialistas y clientes medir fehacientemente resultados y tener datos concretos de qué se evalúa y cómo.

Es importante ya que los costos típicos de consultoría de seguridad son altos y entre los clientes usuales sin perfil técnico informático está afianzado el mito de que no puede determinarse con exactitud qué cosas se "tocan" en un trabajo así y mayormente se termina confiando en la experiencia del consultor de seguridad a la vez que el trabajo de seguridad realizado queda "fuera de alcance" del personal IT local, que por ende no puede evaluar el trabajo y finalmente, los directivos no tienen más que confiar en un tercero externo en cuanto a que tan bien se realizó el trabajo, cuantas cosas y cuales fueron testeadas, etc. etc.

ISSAF puede ser adoptada por una organización como una forma de guía para llevar control sobre asesorías de seguridad recibidas de terceros; igualmente puede ser adoptada por especialistas para ir trabajando sobre una metodología neutral - no propia, como es común - y pública, lo que conlleva el beneficio de poder mostrar e incluso vender distintos niveles de asesorías por especialidad.

Al momento muchas asesorías se cotizan en el mercado con categorizaciones sin mucho detalle de que trabajo incluyen, por ejemplo "estándar", "empresarial", "premium", etc. Utilizando ISSAF se puede controlar - como contratante de los servicios - o implementar - como prestador de los servicios - técnicas puntuales empleadas y por áreas concretas, algunas por ejemplo:

SWITCH SECURITY, ROUTER SECURITY, FIREWALL SECURITY,INTRUSION DETECTION SYSTEM SECURITY, VPN SECURITY,STORAGE AREA NETWORK (SAN) SECURITY, etc. etc.

En un área particular, por ejemplo Storage Area Network (SAN) Security se puede ir viendo algunos ítems puntuales a evaluar :

"1.6 SAN Attack Points" : Out of band management, LAN connection, Control terminals interfaces, Inter switch links, Remote sites, Hosts/servers, LAN interfaces, etc.

Lo que en efecto elimina mucho del "misterio" que pueda ver un cliente en cuanto a la asesoría realizada sobre la infraestructura SAN.

Es necesario aclarar que el framework establece también lineamientos típicos relativos a registro de datos, resultados y conclusiones; y es interesante apuntar que las recomendaciones de hardening se deben ir dando punto por punto dentro de cada área y con detalles de procedimientos técnicos puntuales.

El framework crece continuamente y es enriquecido por la experiencia de muchos especialistas en seguridad IT que colaboran para mejorarlo, sin embargo ya provee una base concisa sobre la cual ir aplicando diferente material preexistente, por ejemplo, en el caso de SANs existen varios papers importantes (y decenas de artículos), de vulnerabilidades infraestructurales típicas y sus soluciones.

Todo el material de ISSAF (incluyendo procedimientos concretos y herramientas a utilizar), está públicamente disponible y el proceso de aporte de nuevos contenidos está disponible en la web vía wiki.

Hay varios frameworks de seguridad al momento, de distintos entes y organizaciones, este sería un ejemplo concreto más que nada, pero hay que reconocer la tendencia en la industria de la seguridad IT que lleva a este tipo de servicios a ajustarse lo más posible a una metodología concreta y concisa, tal que permita a los clientes evaluar el trabajo realizado y determinar - o al menos estimar - el ROI resultante de su inversión en asesoría de seguridad IT.

Referencias
Information Systems Security Assessment Framework (ISSAF)
http://www.oissg.org/information-systems-security-assessment-framework-issaf.html

El framework en sí:
http://www.oissg.org/wiki/index.php/ISAAF-PENETRATION_TESTING_FRAMEWORK

Separar seguridad organizacional de seguridad informática

Sigo leyendo blogs sobre "seguridad", y aunque algunos comenzaron con cierto sentido, cada vez más leo polémicas autogeneradas mezclando tópicos poco relacionados.

La seguridad en general, aplicada a la empresa y/u organizaciones es un tema bastante amplio de momento (muchas opiniones y "tendencias", pocos procedimientos concretos), con diversas normativas, estándares, certificaciones e incluso legislación mandatoria en algunos países. En cambio, la seguridad informática pasa por cuestiones muy puntuales, y ello puede verse reflejado en la IMPLEMENTACION de las políticas de seguridad IT que resultan luego de recorrer el camino propuesto por X metodología; algunos ejemplos:

- protocolos permitidos de tráfico entrante y saliente,
- existencia de antivirus corporativo,
etc. etc.

La seguridad en general en cambio tiene un ámbito global en la organización, y aunque algunos tipos de organización ya tienen altos estándares de seguridad organizacional hace décadas (militares, inteligencia, centros de investigación empresariales y estatales, etc.); la seguridad institucionalizada recien está haciendo su ingreso a las empresas en general en la actualidad.

Se mezcla mucho la seguridad informática con seguridad en la organización en general y la consecuente problemática de convencer a los "jefes" (directorio, presidente, gerentes, asamble de accionistas, etc.), para gastar tiempo y cuantiosos recursos en hacer lo que será casi de seguro una reingeniería de la organización para adecuarla a las mejoras que brinda adecuarse a un estándar de seguridad determinado.

Es cierto que la seguridad informática en sí no tiene eficacia cabal hasta que no está inserta en una política de seguridad organizacional total; sin embargo no hace falta polemizar más de lo debido sobre si servirá de algo o no estudiar qué protocolos pueden pasar por qué puertos (por ejemplo). Después de todo, no podemos (por ejemplo) calificar como un "avance" la finalización de la redacción de un manual de procedimientos de DR (Disaster Recovery), si mientras tanto todos los protocolos pasan tranquilamente por los puertos salientes a Internet sin regular si es necesario o no para el tráfico que pasa por allí.

Convengamos que no debería costar un esfuerzo adicional significativo que el trabajo IT esté ajustado a mínimos parámetros y procedimientos para mejorar la seguridad ya que es parte de la responsabilidad como empleados del personal IT.

Después de todo siempre se habla de la seguridad "como proceso continuo", "adopción paulatina", "securizar progresivamente", etc. Parte de ese proceso puede ser iniciar ya mismo (a falta de la posibilidad de iniciar una securización cabal), los pasos técnicos OBVIOS Y FACTIBLES para incrementar los niveles de seguridad informática, adoptar la seguridad IT en lo técnico de inmediato si es posible y avanzar desde allí hacia la securización total de la organización.

Usemos el sentido común y securicemos desde allí.

Ley de Delitos Informaticos - Reforma del Código Penal - Argentina

Este posteo lo hago porque estuve buscando un buen artículo, suficientemente sintético y abarcativo como para poder explicar rápida y cabalmente en qué consiste la nueva ley de delitos informáticos sancionada en Argentina.

Lo difícil para muchos IT Pro es escuchar "ley" y obtener ganas de sentarse a leer "versículo por versículo" el texto de la ley y peor aún, hacer el intento de analizarla correctamente.

Este texto que sigue a continuación y del que copio fielmente algunas partes para dejarlo disponible para futuras consultas, es una explicación concisa y un análisis bastante bueno de los cambios que introduce la ley en materia de delitos informáticos para la Argentina y se puede interpretar rápidamente algunas consecuencias que tendrá en el desempeño habitual del trabajo IT.

- "el 4 de Junio de 2008, fue sancionada la Ley 26.388 de Delitos Informáticos"

- "La Ley 26.388 no es una ley especial, que regula este tipo de delitos en un cuerpo normativo separado del Código Penal (CP) con figuras propias y específicas, sino una ley que modifica, sustituye e incorpora figuras típicas a diversos artículos del CP actualmente en vigencia, con el objeto de regular las nuevas tecnologías como medios de comisión de delitos previstos en el CP."

-"Delitos informáticos penados y penas instituidas
A lo largo de su articulado tipifica, entre otros, los siguientes delitos informáticos:
• Pornografía infantil por Internet u otros medios electrónicos (art. 128 CP);
• Violación, apoderamiento y desvío de comunicación electrónica (art. 153, párrafo 1º CP);
• Intercepción o captación de comunicaciones electrónicas o telecomunicaciones (art. 153, párrafo 2º CP);
• Acceso a un sistema o dato informático (artículo 153 bis CP);
• Publicación de una comunicación electrónica (artículo 155 CP);
• Acceso a un banco de datos personales (artículo 157 bis, párrafo 1º CP);
• Revelación de información registrada en un banco de datos personales (artículo 157 bis, párrafo 2º CP);
• Inserción de datos falsos en un archivo de datos personales (artículo 157 bis, párrafo 2º CP; anteriormente regulado en el artículo 117 bis, párrafo 1º, incorporado por la Ley de Hábeas Data);
• Fraude informático (artículo 173, inciso 16 CP);
• Daño o sabotaje informático (artículos 183 y 184, incisos 5º y 6º CP)."

- "Las penas establecidas son:
a) prisión;
b) inhabilitación (cuando el delito lo comete un funcionario público o el depositario de objetos destinados a servir de prueba);
c) multa (ej. art. 155)."

- "el artículo 10 de la ley sancionada dice: Incorpórase como segundo párrafo del artículo 183 del Código Penal, el siguiente:
“En la misma pena incurrirá el que alterare, destruyere o inutilizare datos, documentos, programas o sistemas informáticos; o vendiere, distribuyere, hiciere circular o introdujere en un sistema informático, cualquier programa destinado a causar daños”.

Fuente:
"La incorporación de los delitos informáticos al Código Penal argentino"
http://www.delitosinformaticos.com/06/2008/delitos/la-incorporacion-de-los-delitos-informaticos-al-codigo-penal-argentino

Security Hacking NEA 3, algunos comentarios

El fin de semana asistí a la Security Hacking Nea 3 un evento sobre seguridad informática según se publicitó. Luego de escuchar dos charlas y bastante de la tercera terminé de cerrar algunas conclusiones que quiero compartir:


Con respecto al evento en sí;
Creo que la mayor parte de la decepción se debe a dos cosas: falta de estructura de las charlas y cómo fue publicitado el evento. Casi todos fuimos a un evento de "seguridad IT" y nos encontramos con un evento de hacking, es decir una ocasión donde las demostraciones eran eminentemente prácticas y de seguridad IT hay muy poco ( sí, de los procedimientos reales que se utilizan en seguridad IT también hubo muy poco realmente, si alguien pregunta puedo dar bastantes ejemplos de la falta de profundidad de la práctica mostrada en el evento), y para los que entendemos del tema seguridad IT, donde humildemente me incluyo, se dijeron muchas cosas inexactas y no en el mejor lugar ni ocasión.


Con respecto a la falta de estructura de las charlas;
Estuve en las primeras tres y a ellas me refiero, creo que los que estuvieron los dos días dejaron más o menos claro que así también se dieron las demás. Lo que vi es básicamente esto:

a) hablo de este tema,
b) cuento cosas (algo técnico, algo que de "miedo", y algo mas o menos impresionante para los novatos o asistentes no IT).
c) demostración de algunas técnicas mencionadas, unidas al punto b)

Lo que no ví fue que los oradores supieran marcar cada etapa, ya aceptado el hecho que en un evento de hacking planteado como éste no hay mucha profundidad técnica que esperar, y cada parte de la charla se diluía en "cositas para mostrar" más que en un tema concreto que exponer, desarrollar y luego concluir con algunas reflexiones.

Me quedo con la charla de Bluetooth, ya que el speaker manejó las limitaciones en conocimiento con habilidad de orador, aún siendo debutante en el tema, y, qué bárbaro con respecto a las otras dos, dió una conclusión concreta, concisa y acertada técnicamente al tema tratado.


Con respecto a lo técnico hay mucho qué decir,
Me voy a inclinar por comentar en detalle y explicando cómo me habría parecido de buen nivel la respuesta que se dió cuando un asistente preguntó qué tipo de resguardo tenía ante una intrusión y/o robo de datos de parte de la ley argentina y luego, cómo debía proceder en ese caso.

La respuesta fue simple y directa, "NO HAY NADA QUE HACER...." y luego se continuó durante 15 min. más, contando sin precisar ningún procedimiento técnico concreto, la técnica de cadena de proxys y algunas cosas más para ofuscar / impedir / dificultar la localización del origen del ataque y así al atacante en sí.

De las implicaciones del comentario sobre lo legal hay mucho que discutir así que a lo básico: si bien hay leyes argentinas muy, muy limitadas, sí existe jurisprudencia,también limitada; pero se ha visto en los últimos años que ello marca el camino a seguir de la justicia argentina en cuanto a la regulación de delitos IT durante un tiempo: ir tratando cada tema caso por caso.

Eso quiere decir que si el evento de seguridad (intrusión/robo de datos) fue significativo en alguna magnitud mesurable (TCO, ROI, daños colaterales varios, etc. etc.), la empresa/organización debería asesorarse antes de descartar cualquier acción legal.

Incluso no actuar legalmente en absoluto en algunos tipos de empresas y organizaciones puede acarrear serias consecuencias (sí, acá en Argentina), en cuanto a terceros: acciones legales secundarias (léase "demanda"), que sí podrían tener resultados mucho más concretos ($$$) sobre la responsabilidad de quienes no actuaron en absoluto; hablando de lo interno, dos palabras: "sumario administrativo".

Todo ello, más allá de que se pueda lograr o no algun resultado efectivo con respecto al atacante y las consecuencias de su ataque (ya que en el hipotético caso planteado en la pregunta, las consecuencias del evento de seguridad son plenamente verificables).

De la parte técnica sobre este comentario digo, si se habló 15 minutos comentando cómo hacer una cadena de proxys y la cuestión de las jurisdicciones legales, bien podría
haberse hablado un momento de que cualquier evento relevante de seguridad IT debe ser investigado. "Relevante" consiste básicamente en si con costo/beneficio adecuado vale la pena investigar el hecho, acá tiene mucho que ver la cualificación del personal IT propio y de, generalmente, conseguir un buen consultor de seguridad (conocimientos y ética). Luego de esto y habiendo valorado si vale la pena investigar seriamente, y según la cualificación del personal IT, se puede continuar con personal interno y/o externo.

En el caso de un robo de datos puntualmente, si se puede obtener alguna información de lo que publicita (mediante avisos, sitio web, búsquedas laborales, nuevos productos, etc.), el supuesto receptor (empresa/organización/individuo), de los datos robados, allí se puede hacer inferencias lógicas sobre la ubicación interna o no de los datos robados y, si se confirma que son datos privados que on debían divulgarse, luego incluso se podría llegar al personal con acceso autorizado a ellos, mediante diversas vías: permisos de acceso físico(llaves) y/o lógicos (contraseñas, permisos de usuario, política de redes y seguridad, etc.).

Aunque luego no hubieren resultados estrictamente legales con respecto al origen del incidente de seguridad (el hacker preso concretamente), sí se podría tratar las cuestiones internas de la empresa/organización que sufrió el incidente intentando subsanar los puntos de fallo en su política de seguridad (si la tuviera o no). Y esto constituye básicamente el grueso del valor del ROI de una investigación en un evento de este tipo.

No digo que en evento en vivo se pueda elaborar una respuesta tan detallada como la escribí acá, que es bastante general y no abarca el espectro téorico total de cómo enfocar un incidente de seguridad, pero entiendo que "NO, NO HAY NADA QUE HACER" es muy implacable como respuesta y no cabe en una cuestión tan sensible como una intrusión y/o un robo de datos.

Conclusion
Destaco otra vez, que en un evento de hacking normalmente no se espera un enfoque muy profundo a nivel técnico en seguridad IT, la próxima tal vez se podría publicitar así, y muchos irían sabiendo exactamente qué van a escuchar.

Sería muy interesante que para una cuarta edición se pulieran algunos detalles, y constructivamente espero haber aportado algunas ideas y/o motivación para ello.